kernel/drivers/memory, branch linux-5.14.y

memory: fsl_ifc: fix leak of irq and nand_irq in fsl_ifc_ctrl_probe

2021-11-17T10:04:24Z

[ Upstream commit 4ed2f3545c2e5acfbccd7f85fea5b1a82e9862d7 ] 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: d2ae2e20fbdd ("driver/memory:Move Freescale IFC driver to a common driver") Signed-off-by: Dongliang Mu Link: https://lore.kernel.org/r/20210925151434.8170-1-mudongliangabcd@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin

memory: renesas-rpc-if: Correct QSPI data transfer in Manual mode

2021-11-17T10:03:36Z

commit fff53a551db50f5edecaa0b29a64056ab8d2bbca upstream. 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: ca7d8b980b67 ("memory: add Renesas RPC-IF driver") Cc: Signed-off-by: Duc Nguyen [wsa: refactored to use regmap only via reg_read/reg_write] Signed-off-by: Wolfram Sang Tested-by: Lad Prabhakar Link: https://lore.kernel.org/r/20210922091007.5516-1-wsa+renesas@sang-engineering.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman

Merge tag 'memory-controller-drv-tegra-5.14-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/drivers

2021-06-17T00:36:30Z

Memory controller drivers for v5.14 - Tegra SoC, part two Second set of changes for Tegra SoC memory controller drivers, containing patchset from Thierry Reding: "The goal here is to avoid early identity mappings altogether and instead postpone the need for the identity mappings to when devices are attached to the SMMU. This works by making the SMMU driver coordinate with the memory controller driver on when to start enforcing SMMU translations. This makes Tegra behave in a more standard way and pushes the code to deal with the Tegra-specific programming into the NVIDIA SMMU implementation." This pulls a dependency from Will Deacon (ARM SMMU driver) and contains further ARM SMMU driver patches to resolve complex dependencies between different patchsets. The pull from Will contains only one patch ("Implement ->probe_finalize()"). Further work in Will's tree might depend on this patch, therefore patch was applied there. On the other hand, this ("Implement ->probe_finalize()") patch is also a dependency for ARM SMMU driver changes for Tegra. These changes, bringing seamless transition from the firmware framebuffer to the OS framebuffer, depend on earlier Tegra memory controller driver patches. * tag 'memory-controller-drv-tegra-5.14-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl: (37 commits) iommu/arm-smmu: Use Tegra implementation on Tegra186 iommu/arm-smmu: tegra: Implement SID override programming iommu/arm-smmu: tegra: Detect number of instances at runtime dt-bindings: arm-smmu: Add Tegra186 compatible string memory: tegra: Delete dead debugfs checking code iommu/arm-smmu: Implement ->probe_finalize() memory: tegra: Implement SID override programming memory: tegra: Split Tegra194 data into separate file memory: tegra: Add memory client IDs to tables memory: tegra: Unify drivers memory: tegra: Only initialize reset controller if available memory: tegra: Make IRQ support opitonal memory: tegra: Parameterize interrupt handler memory: tegra: Extract setup code into callback memory: tegra: Make per-SoC setup more generic memory: tegra: Push suspend/resume into SoC drivers memory: tegra: Introduce struct tegra_mc_ops memory: tegra: Unify struct tegra_mc across SoC generations memory: tegra: Consolidate register fields memory: tegra30-emc: Use devm_tegra_core_dev_init_opp_table() ... Link: https://lore.kernel.org/r/20210614195200.21657-1-krzysztof.kozlowski@canonical.com Signed-off-by: Olof Johansson

Merge tag 'memory-controller-drv-pl353-5.14' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/drivers

2021-06-12T15:53:06Z

Memory controller drivers for v5.14 - PL353 Bigger work around ARM Primecell PL35x SMC memory controller driver by Miquel Raynal built on previous series from Naga Sureshkumar Relli. This includes bindings cleanup and correction, converting these to dtschema and several cleanyps in pl353-smc driver. * tag 'memory-controller-drv-pl353-5.14' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl: dt-binding: memory: pl353-smc: Convert to yaml MAINTAINERS: Add PL353 SMC entry memory: pl353-smc: Declare variables following a reverse christmas tree order memory: pl353-smc: Avoid useless acronyms in descriptions memory: pl353-smc: Let lower level controller drivers handle inits memory: pl353-smc: Rename goto labels memory: pl353-smc: Fix style dt-binding: memory: pl353-smc: Fix the NAND controller node in the example dt-binding: memory: pl353-smc: Drop unsupported nodes from the example dt-binding: memory: pl353-smc: Fix the example syntax and style dt-binding: memory: pl353-smc: Describe the child reg property dt-binding: memory: pl353-smc: Drop the partitioning section dt-binding: memory: pl353-smc: Document the range property dt-binding: memory: pl353-smc: Rephrase the binding Link: https://lore.kernel.org/r/20210611140659.61980-2-krzysztof.kozlowski@canonical.com Signed-off-by: Olof Johansson

memory: pl353-smc: Declare variables following a reverse christmas tree order

2021-06-10T15:15:16Z

This is a purely cosmetic change. Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/r/20210610082040.2075611-15-miquel.raynal@bootlin.com Signed-off-by: Krzysztof Kozlowski

memory: pl353-smc: Avoid useless acronyms in descriptions

2021-06-10T15:15:16Z

APER does not mean anything, while it seems legitimate to call this clock the AXI peripheral clock. Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/r/20210610082040.2075611-14-miquel.raynal@bootlin.com Signed-off-by: Krzysztof Kozlowski

memory: pl353-smc: Let lower level controller drivers handle inits

2021-06-10T15:15:16Z

There is no point in having all these definitions at the SMC bus level, these are extremely tight to the NAND controller driver implementation, are not particularly generic, imply more boilerplate than needed, do not really follow the device model by receiving no argument and some of them are actually buggy. Let's get rid of these right now as there is no current user and keep this driver at a simple level: only the SMC bare initializations. The NAND controller driver which I am going to introduce will take care of redefining properly all these helpers and using them directly. Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/r/20210610082040.2075611-13-miquel.raynal@bootlin.com Signed-off-by: Krzysztof Kozlowski

memory: pl353-smc: Rename goto labels

2021-06-10T15:15:16Z

A goto label is better named do_something: than out_something_to_do: Use the former wording and really describe what the jump involves. Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/r/20210610082040.2075611-12-miquel.raynal@bootlin.com Signed-off-by: Krzysztof Kozlowski

memory: pl353-smc: Fix style

2021-06-10T15:15:15Z

Use proper spacing. Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/r/20210610082040.2075611-11-miquel.raynal@bootlin.com Signed-off-by: Krzysztof Kozlowski

memory: emif: remove unused frequency and voltage notifiers

2021-06-10T07:24:46Z

The driver defined several functions related to handling of frequency and voltage changes: - freq_post_notify_handling - freq_pre_notify_handling - volt_notify_handling All these are static, not used inside or outside of driver, and marked as unused with comment: "TODO: voltage notify handling should be hooked up to regulator framework as soon as the necessary support is available in mainline kernel. This function is un-used right now.". These have been added with commit a93de288aad3 ("memory: emif: handle frequency and voltage change events") in 2012 and are unused since then. Additionally mentioned regulator and clock hooking did not happen since then. If it did not happen for nine years, let's assume it will not happen suddenly now. Remove all unused functions which also allows removal of "t_ck" static variable "t_ck" and "addressing" member of private structure. No functionality is lost. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20210527154101.80556-1-krzysztof.kozlowski@canonical.com