We add the ostd setting for mt8195. It introduces a KE for the
previous SoC which doesn't have ostd setting. This is the log:
Unable to handle kernel NULL pointer dereference at virtual address
0000000000000080
...
pc : mtk_smi_larb_config_port_gen2_general+0x64/0x130
lr : mtk_smi_larb_resume+0x54/0x98
...
Call trace:
mtk_smi_larb_config_port_gen2_general+0x64/0x130
pm_generic_runtime_resume+0x2c/0x48
__genpd_runtime_resume+0x30/0xa8
genpd_runtime_resume+0x94/0x2c8
__rpm_callback+0x44/0x150
rpm_callback+0x6c/0x78
rpm_resume+0x310/0x558
__pm_runtime_resume+0x3c/0x88
In the code: larbostd = larb->larb_gen->ostd[larb->larbid],
if "larb->larb_gen->ostd" is null, the "larbostd" is the offset(e.g.
0x80 above), it's also a valid value, then accessing "larbostd[i]" in the
"for" loop will cause the KE above. To avoid this issue, initialize
"larbostd" to NULL when the SoC doesn't have ostd setting.
Fixes: fe6dd2a401 ("memory: mtk-smi: mt8195: Add initial setting for smi-larb")
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20211108082429.15080-1-yong.wu@mediatek.com
Link: https://lore.kernel.org/r/20211124085042.9649-3-krzysztof.kozlowski@canonical.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Memory controller drivers for v5.16
1. Renesas RPC: fix unaligned bus access and QSPI data transfers in
manual modes.
2. Renesas RPC: select RESET_CONTROLLER as it is necessary for
operation.
3. FSL IFC: fix error paths.
4. Broadcom: allow building as module.
* tag 'memory-controller-drv-5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl:
memory: fsl_ifc: fix leak of irq and nand_irq in fsl_ifc_ctrl_probe
memory: renesas-rpc-if: RENESAS_RPCIF should select RESET_CONTROLLER
memory: brcmstb_dpfe: Allow building Broadcom STB DPFE as module
memory: samsung: describe drivers in KConfig
memory: renesas-rpc-if: Avoid unaligned bus access for HyperFlash
memory: renesas-rpc-if: Correct QSPI data transfer in Manual mode
dt-bindings: rpc: renesas-rpc-if: Add support for the R8A779A0 RPC-IF
Link: https://lore.kernel.org/r/20211010175836.13302-1-krzysztof.kozlowski@canonical.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Memory controller drivers for v5.14 - Mediatek
Add MT8195 support to the Mediatek SMI memory controller driver. This
brings also several cleanups and minor enhancements before adding actual
new device support.
* tag 'memory-controller-drv-mtk-5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl:
MAINTAINERS: Add entry for MediaTek SMI
memory: mtk-smi: mt8195: Add initial setting for smi-larb
memory: mtk-smi: mt8195: Add initial setting for smi-common
memory: mtk-smi: mt8195: Add smi support
memory: mtk-smi: Use devm_platform_ioremap_resource
memory: mtk-smi: Add clocks for smi-sub-common
memory: mtk-smi: Add device link for smi-sub-common
memory: mtk-smi: Add error handle for smi_probe
memory: mtk-smi: Adjust some code position
memory: mtk-smi: Rename smi_gen to smi_type
memory: mtk-smi: Use clk_bulk clock ops
dt-bindings: memory: mediatek: Add mt8195 smi sub common
dt-bindings: memory: mediatek: Add mt8195 smi binding
Link: https://lore.kernel.org/r/20211010175836.13302-2-krzysztof.kozlowski@canonical.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The error handling code of fsl_ifc_ctrl_probe is problematic. When
fsl_ifc_ctrl_init fails or request_irq of fsl_ifc_ctrl_dev->irq fails,
it forgets to free the irq and nand_irq. Meanwhile, if request_irq of
fsl_ifc_ctrl_dev->nand_irq fails, it will still free nand_irq even if
the request_irq is not successful.
Fix this by refactoring the error handling code.
Fixes: d2ae2e20fb ("driver/memory:Move Freescale IFC driver to a common driver")
Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
Link: https://lore.kernel.org/r/20210925151434.8170-1-mudongliangabcd@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
fix debugfs_simple_attr.cocci warning:
drivers/memory/tegra/tegra210-emc-core.c:1665:0-23: WARNING:tegra210_emc_debug_min_rate_fops
should be defined with DEFINE_DEBUGFS_ATTRIBUTE
Commit 6fc5f1adf5 ("memory: tegra210-emc: replace
DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE") fixed the same
warning, but didn't fix all matches in this file at once.
Signed-off-by: Kai Song <songkai01@inspur.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20211005043514.9650-1-songkai01@inspur.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
HyperFlash devices in Renesas SoCs use 2-bytes addressing, according
to HW manual paragraph 62.3.3 (which officially describes Serial Flash
access, but seems to be applicable to HyperFlash too). And 1-byte bus
read operations to 2-bytes unaligned addresses in external address space
read mode work incorrectly (returns the other byte from the same word).
Function memcpy_fromio(), used by the driver to read data from the bus,
in ARM64 architecture (to which Renesas cores belong) uses 8-bytes
bus accesses for appropriate aligned addresses, and 1-bytes accesses
for other addresses. This results in incorrect data read from HyperFlash
in unaligned cases.
This issue can be reproduced using something like the following commands
(where mtd1 is a parition on Hyperflash storage, defined properly
in a device tree):
[Correct fragment, read from Hyperflash]
root@rcar-gen3:~# dd if=/dev/mtd1 of=/tmp/zz bs=32 count=1
root@rcar-gen3:~# hexdump -C /tmp/zz
00000000 f4 03 00 aa f5 03 01 aa f6 03 02 aa f7 03 03 aa |................|
00000010 00 00 80 d2 40 20 18 d5 00 06 81 d2 a0 18 a6 f2 |....@ ..........|
00000020
[Incorrect read of the same fragment: see the difference at offsets 8-11]
root@rcar-gen3:~# dd if=/dev/mtd1 of=/tmp/zz bs=12 count=1
root@rcar-gen3:~# hexdump -C /tmp/zz
00000000 f4 03 00 aa f5 03 01 aa 03 03 aa aa |............|
0000000c
Fix this issue by creating a local replacement of the copying function,
that performs only properly aligned bus accesses, and is used for reading
from HyperFlash.
Fixes: ca7d8b980b ("memory: add Renesas RPC-IF driver")
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Link: https://lore.kernel.org/r/20210922184830.29147-1-andrew_gabbasov@mentor.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
This patch fixes 2 problems:
[1] The output warning logs and data loss when performing
mount/umount then remount the device with jffs2 format.
[2] The access width of SMWDR[0:1]/SMRDR[0:1] register is wrong.
This is the sample warning logs when performing mount/umount then
remount the device with jffs2 format:
jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x031c51d4:
Read 0x00034e00, calculated 0xadb272a7
The reason for issue [1] is that the writing data seems to
get messed up.
Data is only completed when the number of bytes is divisible by 4.
If you only have 3 bytes of data left to write, 1 garbage byte
is inserted after the end of the write stream.
If you only have 2 bytes of data left to write, 2 bytes of '00'
are added into the write stream.
If you only have 1 byte of data left to write, 2 bytes of '00'
are added into the write stream. 1 garbage byte is inserted after
the end of the write stream.
To solve problem [1], data must be written continuously in serial
and the write stream ends when data is out.
Following HW manual 62.2.15, access to SMWDR0 register should be
in the same size as the transfer size specified in the SPIDE[3:0]
bits in the manual mode enable setting register (SMENR).
Be sure to access from address 0.
So, in 16-bit transfer (SPIDE[3:0]=b'1100), SMWDR0 should be
accessed by 16-bit width.
Similar to SMWDR1, SMDDR0/1 registers.
In current code, SMWDR0 register is accessed by regmap_write()
that only set up to do 32-bit width.
To solve problem [2], data must be written 16-bit or 8-bit when
transferring 1-byte or 2-byte.
Fixes: ca7d8b980b ("memory: add Renesas RPC-IF driver")
Cc: <stable@vger.kernel.org>
Signed-off-by: Duc Nguyen <duc.nguyen.ub@renesas.com>
[wsa: refactored to use regmap only via reg_read/reg_write]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/20210922091007.5516-1-wsa+renesas@sang-engineering.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
To improve the performance, We add some initial setting for smi larbs.
there are two part:
1), Each port has the special ostd(outstanding) value in each larb.
2), Two general settings for each larb.
a. THRT_UPDATE: the value in bits[7:4] of 0x24 is not so good.
The HW default is 4, and we expect it is 5, thus, add a flag to update
it. This is only a DE recommendatory value, not a actual issue.
The register name(THRT_CON) means: throttling control, and the field
RD_NU_LMT means: Read Non-ultra commands limit.
This change means update the Read non-ultra command from 4 to 5 here.
b. SW_FLAG: Set 1 to the FLAG register. this is only for helping
debug. We could confirm if the larb is reset from this value is 1 or 0.
In some SoC, this setting maybe changed dynamically for some special case
like 4K, and this initial setting is enough in mt8195.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Link: https://lore.kernel.org/r/20210914113703.31466-13-yong.wu@mediatek.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
In mt8195, there are some larbs connect with the smi-sub-common, then
connect with smi-common.
Before we create device link between smi-larb with smi-common. If we have
sub-common, we should use device link the smi-larb and smi-sub-common,
then use device link between the smi-sub-common with smi-common. This is
for enabling clock/power automatically.
Move the device link code to a new interface for reusing.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Ikjoon Jang <ikjn@chromium.org>
Link: https://lore.kernel.org/r/20210914113703.31466-8-yong.wu@mediatek.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
