mbox series

[v2,00/29] *memory: Cleanup, improve and compile test memory drivers

Message ID 20200724074038.5597-1-krzk@kernel.org (mailing list archive)
Headers show
Series *memory: Cleanup, improve and compile test memory drivers | expand

Message

Krzysztof Kozlowski July 24, 2020, 7:40 a.m. UTC 
Dear All,

Changes since v1:
1. Few new patches,
2. Please see individual logs (per patch).


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, I will collect the patches and push them
through arm-soc maintainers.

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 (29):
  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: jz4780-nemc: Do not enable by default on every compile test
  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 pointer definition
  memory: omap-gpmc: Return meaningful error codes in
    gpmc_cs_set_timings()
  memory: omap-gpmc: Remove GPMC_SET_ONE_CD_MAX macro for safety
  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
  memory: fsl_ifc: Fix whitespace issues
  memory: da8xx-ddrctl: Remove unused 'node' variable
  memory: Describe the MEMORY Kconfig entry
  memory: samsung: exynos-srom: Describe the Kconfig entry

 MAINTAINERS                                   |   7 +
 drivers/memory/Kconfig                        |  47 ++++--
 drivers/memory/brcmstb_dpfe.c                 |   5 +-
 drivers/memory/da8xx-ddrctl.c                 |   2 -
 drivers/memory/emif-asm-offsets.c             |  10 +-
 drivers/memory/emif.c                         |  23 +--
 drivers/memory/fsl_ifc.c                      |  30 ++--
 drivers/memory/mtk-smi.c                      |   2 +-
 drivers/memory/of_memory.c                    |  28 ++--
 drivers/memory/of_memory.h                    |  21 +--
 drivers/memory/omap-gpmc.c                    | 155 +++++++++++-------
 drivers/memory/pl172.c                        |   5 +-
 drivers/memory/renesas-rpc-if.c               |   4 +-
 drivers/memory/samsung/Kconfig                |   7 +
 drivers/memory/tegra/tegra210-emc-cc-r21021.c |   2 +-
 drivers/memory/ti-aemif.c                     |  16 +-
 drivers/memory/ti-emif-pm.c                   |   2 +-
 17 files changed, 208 insertions(+), 158 deletions(-)

Comments

Arnd Bergmann July 24, 2020, 1:51 p.m. UTC | #1 
On Fri, Jul 24, 2020 at 9:41 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> Dear All,
>
> Changes since v1:
> 1. Few new patches,
> 2. Please see individual logs (per patch).
>
>
> 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, I will collect the patches and push them
> through arm-soc maintainers.
>
> 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.

Looks all good. Can you send a pull request for the patches that you don't
expect to need testing for, while you still wait for more feedback on the
others?

As the merge window (and my vacation) is getting closer, I would like to
have most of the patches for v5.9 queued up.

       Arnd

     Arnd
Krzysztof Kozlowski July 24, 2020, 2:03 p.m. UTC | #2 
On Fri, Jul 24, 2020 at 03:51:04PM +0200, Arnd Bergmann wrote:
> On Fri, Jul 24, 2020 at 9:41 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > Dear All,
> >
> > Changes since v1:
> > 1. Few new patches,
> > 2. Please see individual logs (per patch).
> >
> >
> > 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, I will collect the patches and push them
> > through arm-soc maintainers.
> >
> > 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.
> 
> Looks all good. Can you send a pull request for the patches that you don't
> expect to need testing for, while you still wait for more feedback on the
> others?
> 
> As the merge window (and my vacation) is getting closer, I would like to
> have most of the patches for v5.9 queued up.

Sure, I'll prepare a pull.

Thanks!

Best regards,
Krzysztof