| Message ID | 20200723073744.13400-1-krzk@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | memory: Cleanup, improve and compile test memory drivers | expand |
On Thu, Jul 23, 2020 at 09:37:21AM +0200, Krzysztof Kozlowski wrote: > Dear All, > > The drivers/memory directory contains generic code (of_memory.c) and a > bunch of drivers. Changes to generic code were coming usually through > different trees with the driver code. > > Over last days, memory drivers grew in numbers but not necessarily in > quality. They lacked compile testing and code cleanup. Also lacked > maintainer. > > I would be happy to take care about this part. No objection from me, thanks for steping up to do this. > If there are no objections, the patches could go either to Linus or to > arm-soc (most of drivers are ARM specific). None from me! thanks, greg k-h
On Thu, Jul 23, 2020 at 9:37 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > Dear All, > > The drivers/memory directory contains generic code (of_memory.c) and a > bunch of drivers. Changes to generic code were coming usually through > different trees with the driver code. > > Over last days, memory drivers grew in numbers but not necessarily in > quality. They lacked compile testing and code cleanup. Also lacked > maintainer. > > I would be happy to take care about this part. > > If there are no objections, the patches could go either to Linus or to > arm-soc (most of drivers are ARM specific). > > Driver-specific changes in the patchset were only compile-tested. Tests > are welcome. The generic code was tested on ARMv7 Exynos based boards > with a exynos5422-dmc memory controller driver. Overall this looks great, I had a look through the patches and commented on the few things that seemed slightly odd though harmless. Thanks for picking up the subsystem. How do you want to proceed in the long run? I suppose you can send a pull request to soc@kernel.org to be picked up for the coming merge window as the normal way, since you are not yet listed as the maintained until the end of the series. Afterwards you could either send the pull requests to Linus directly, or send them to the soc team (or to Greg) as well, the way we handle a couple of other subsystems like drivers/reset and drivers/tee that usually only have a handful of patches per release. Arnd
On Thu, Jul 23, 2020 at 11:31:02AM +0200, Arnd Bergmann wrote: > On Thu, Jul 23, 2020 at 9:37 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > Dear All, > > > > The drivers/memory directory contains generic code (of_memory.c) and a > > bunch of drivers. Changes to generic code were coming usually through > > different trees with the driver code. > > > > Over last days, memory drivers grew in numbers but not necessarily in > > quality. They lacked compile testing and code cleanup. Also lacked > > maintainer. > > > > I would be happy to take care about this part. > > > > If there are no objections, the patches could go either to Linus or to > > arm-soc (most of drivers are ARM specific). > > > > Driver-specific changes in the patchset were only compile-tested. Tests > > are welcome. The generic code was tested on ARMv7 Exynos based boards > > with a exynos5422-dmc memory controller driver. > > Overall this looks great, I had a look through the patches and commented > on the few things that seemed slightly odd though harmless. > > Thanks for picking up the subsystem. How do you want to proceed > in the long run? I suppose you can send a pull request to soc@kernel.org > to be picked up for the coming merge window as the normal way, since > you are not yet listed as the maintained until the end of the series. > > Afterwards you could either send the pull requests to Linus directly, > or send them to the soc team (or to Greg) as well, the way we handle > a couple of other subsystems like drivers/reset and drivers/tee that > usually only have a handful of patches per release. Most of the drivers are for ARM architecture so arm-soc seems like the way to do it. However BT1_L2_CTL and JZ4780_NEMC are MIPS specific and maybe more would come in the future. Are you fine taking them as well? Best regards, Krzysztof
On Thu, Jul 23, 2020 at 11:52 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > On Thu, Jul 23, 2020 at 11:31:02AM +0200, Arnd Bergmann wrote: > > On Thu, Jul 23, 2020 at 9:37 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > Afterwards you could either send the pull requests to Linus directly, > > or send them to the soc team (or to Greg) as well, the way we handle > > a couple of other subsystems like drivers/reset and drivers/tee that > > usually only have a handful of patches per release. > > Most of the drivers are for ARM architecture so arm-soc seems like the > way to do it. However BT1_L2_CTL and JZ4780_NEMC are MIPS specific and > maybe more would come in the future. Are you fine taking them as well? Yes, that's not a problem at all. Most other architectures are ramping down anyway, both on the maintainership side and on newly supported hardware, so we are picking those up where necessary. I also merged a couple of drivers for the MIPS based Baikal SoCs recently. Arnd
Dear All, The drivers/memory directory contains generic code (of_memory.c) and a bunch of drivers. Changes to generic code were coming usually through different trees with the driver code. Over last days, memory drivers grew in numbers but not necessarily in quality. They lacked compile testing and code cleanup. Also lacked maintainer. I would be happy to take care about this part. If there are no objections, the patches could go either to Linus or to arm-soc (most of drivers are ARM specific). Driver-specific changes in the patchset were only compile-tested. Tests are welcome. The generic code was tested on ARMv7 Exynos based boards with a exynos5422-dmc memory controller driver. Best regards, Krzysztof Krzysztof Kozlowski (23): memory: omap-gpmc: Remove unneeded asm/mach-types.h inclusion memory: omap-gpmc: Remove unused file-scope phys_base and mem_size memory: omap-gpmc: Include <linux/sizes.h> for SZ_16M memory: ti-aemif: Rename SS to SSTROBE to avoid name conflicts memory: Enable compile testing for most of the drivers memory: of: Remove unused headers memory: of: Remove __func__ in device related messages memory: of: Correct indentation memory: of: Remove unneeded extern from function declarations memory: emif-asm-offsets: Add GPLv2 SPDX license header memory: emif: Put constant in comparison on the right side memory: emif: Fix whitespace coding style violations memory: emif: Silence platform_get_irq() error in driver memory: ti-emif-pm: Fix cast to iomem pointer memory: renesas-rpc-if: Simplify with PTR_ERR_OR_ZERO memory: brcmstb_dpfe: Constify the contents of string memory: brcmstb_dpfe: Remove unneeded braces memory: mtk-smi: Add argument to function definition memory: omap-gpmc: Enclose macro statements in do-while memory: omap-gpmc: Fix whitespace issue memory: pl172: Add GPLv2 SPDX license header memory: tegra: tegra210-emc: Fix indentation MAINTAINERS: Add Krzysztof Kozlowski as maintainer of memory controllers MAINTAINERS | 7 +++++ drivers/memory/Kconfig | 31 +++++++++++-------- drivers/memory/brcmstb_dpfe.c | 5 ++- drivers/memory/emif-asm-offsets.c | 10 +----- drivers/memory/emif.c | 23 ++++++-------- drivers/memory/mtk-smi.c | 2 +- drivers/memory/of_memory.c | 28 ++++++++--------- drivers/memory/of_memory.h | 21 +++++++------ drivers/memory/omap-gpmc.c | 21 ++++++------- drivers/memory/pl172.c | 5 +-- drivers/memory/renesas-rpc-if.c | 4 +-- drivers/memory/tegra/tegra210-emc-cc-r21021.c | 2 +- drivers/memory/ti-aemif.c | 16 +++++----- drivers/memory/ti-emif-pm.c | 2 +- 14 files changed, 84 insertions(+), 93 deletions(-)