Re: [PATCH 14/23] memory: ti-emif-pm: Fix cast to iomem pointer

Re: [PATCH 14/23] memory: ti-emif-pm: Fix cast to iomem pointer

[Arnd Bergmann]

On Thu, Jul 23, 2020 at 9:39 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> Cast pointer to iomem memory properly to fix sparse warning:
>
>     drivers/memory/ti-emif-pm.c:251:38: warning: incorrect type in argument 1 (different address spaces)
>     drivers/memory/ti-emif-pm.c:251:38:    expected void const volatile [noderef] __iomem *addr
>     drivers/memory/ti-emif-pm.c:251:38:    got void *
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
>  drivers/memory/ti-emif-pm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/memory/ti-emif-pm.c b/drivers/memory/ti-emif-pm.c
> index 9c90f815ad3a..6c747c1e98cb 100644
> --- a/drivers/memory/ti-emif-pm.c
> +++ b/drivers/memory/ti-emif-pm.c
> @@ -248,7 +248,7 @@ MODULE_DEVICE_TABLE(of, ti_emif_of_match);
>  static int ti_emif_resume(struct device *dev)
>  {
>         unsigned long tmp =
> -                       __raw_readl((void *)emif_instance->ti_emif_sram_virt);
> +                       __raw_readl((void __iomem *)emif_instance->ti_emif_sram_virt);
>

Maybe this shouldn't even be __raw_readl(), but instead READ_ONCE()?

The other accesses in this file don't use MMIO wrappers either but just treat
it as a pointer. The effect would be the same though.

      Arnd

Re: [PATCH 14/23] memory: ti-emif-pm: Fix cast to iomem pointer

[Krzysztof Kozlowski]

On Thu, Jul 23, 2020 at 10:48:19AM +0200, Arnd Bergmann wrote:
> On Thu, Jul 23, 2020 at 9:39 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > Cast pointer to iomem memory properly to fix sparse warning:
> >
> >     drivers/memory/ti-emif-pm.c:251:38: warning: incorrect type in argument 1 (different address spaces)
> >     drivers/memory/ti-emif-pm.c:251:38:    expected void const volatile [noderef] __iomem *addr
> >     drivers/memory/ti-emif-pm.c:251:38:    got void *
> >
> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> > ---
> >  drivers/memory/ti-emif-pm.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/memory/ti-emif-pm.c b/drivers/memory/ti-emif-pm.c
> > index 9c90f815ad3a..6c747c1e98cb 100644
> > --- a/drivers/memory/ti-emif-pm.c
> > +++ b/drivers/memory/ti-emif-pm.c
> > @@ -248,7 +248,7 @@ MODULE_DEVICE_TABLE(of, ti_emif_of_match);
> >  static int ti_emif_resume(struct device *dev)
> >  {
> >         unsigned long tmp =
> > -                       __raw_readl((void *)emif_instance->ti_emif_sram_virt);
> > +                       __raw_readl((void __iomem *)emif_instance->ti_emif_sram_virt);
> >
> 
> Maybe this shouldn't even be __raw_readl(), but instead READ_ONCE()?

Won't readl() be enough? Indeed it looks problematic.

> 
> The other accesses in this file don't use MMIO wrappers either but just treat
> it as a pointer. The effect would be the same though.

I think all the reads and writes are with readl() and writel().

Best regards,
Krzysztof

Re: [PATCH 14/23] memory: ti-emif-pm: Fix cast to iomem pointer

[Arnd Bergmann]

On Thu, Jul 23, 2020 at 11:02 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Thu, Jul 23, 2020 at 10:48:19AM +0200, Arnd Bergmann wrote:
> > On Thu, Jul 23, 2020 at 9:39 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > >
> > > Cast pointer to iomem memory properly to fix sparse warning:
> > >
> > >     drivers/memory/ti-emif-pm.c:251:38: warning: incorrect type in argument 1 (different address spaces)
> > >     drivers/memory/ti-emif-pm.c:251:38:    expected void const volatile [noderef] __iomem *addr
> > >     drivers/memory/ti-emif-pm.c:251:38:    got void *
> > >
> > > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> > > ---
> > >  drivers/memory/ti-emif-pm.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/memory/ti-emif-pm.c b/drivers/memory/ti-emif-pm.c
> > > index 9c90f815ad3a..6c747c1e98cb 100644
> > > --- a/drivers/memory/ti-emif-pm.c
> > > +++ b/drivers/memory/ti-emif-pm.c
> > > @@ -248,7 +248,7 @@ MODULE_DEVICE_TABLE(of, ti_emif_of_match);
> > >  static int ti_emif_resume(struct device *dev)
> > >  {
> > >         unsigned long tmp =
> > > -                       __raw_readl((void *)emif_instance->ti_emif_sram_virt);
> > > +                       __raw_readl((void __iomem *)emif_instance->ti_emif_sram_virt);
> > >
> >
> > Maybe this shouldn't even be __raw_readl(), but instead READ_ONCE()?
>
> Won't readl() be enough? Indeed it looks problematic.

readl() won't work on big-endian kernels, since this is a byte comparison.

> > The other accesses in this file don't use MMIO wrappers either but just treat
> > it as a pointer. The effect would be the same though.
>
> I think all the reads and writes are with readl() and writel().

I actually see only one other access:

        copy_addr = sram_exec_copy(emif_data->sram_pool_code,
                                   (void *)emif_data->ti_emif_sram_virt,
                                   &ti_emif_sram, ti_emif_sram_sz);

and this one ends up in a memcpy() that does not perform any byte
swapping or barriers.

     Arnd

Re: [PATCH 14/23] memory: ti-emif-pm: Fix cast to iomem pointer

[Krzysztof Kozlowski]

On Thu, Jul 23, 2020 at 11:14:02AM +0200, Arnd Bergmann wrote:
> On Thu, Jul 23, 2020 at 11:02 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Thu, Jul 23, 2020 at 10:48:19AM +0200, Arnd Bergmann wrote:
> > > On Thu, Jul 23, 2020 at 9:39 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > >
> > > > Cast pointer to iomem memory properly to fix sparse warning:
> > > >
> > > >     drivers/memory/ti-emif-pm.c:251:38: warning: incorrect type in argument 1 (different address spaces)
> > > >     drivers/memory/ti-emif-pm.c:251:38:    expected void const volatile [noderef] __iomem *addr
> > > >     drivers/memory/ti-emif-pm.c:251:38:    got void *
> > > >
> > > > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> > > > ---
> > > >  drivers/memory/ti-emif-pm.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/memory/ti-emif-pm.c b/drivers/memory/ti-emif-pm.c
> > > > index 9c90f815ad3a..6c747c1e98cb 100644
> > > > --- a/drivers/memory/ti-emif-pm.c
> > > > +++ b/drivers/memory/ti-emif-pm.c
> > > > @@ -248,7 +248,7 @@ MODULE_DEVICE_TABLE(of, ti_emif_of_match);
> > > >  static int ti_emif_resume(struct device *dev)
> > > >  {
> > > >         unsigned long tmp =
> > > > -                       __raw_readl((void *)emif_instance->ti_emif_sram_virt);
> > > > +                       __raw_readl((void __iomem *)emif_instance->ti_emif_sram_virt);
> > > >
> > >
> > > Maybe this shouldn't even be __raw_readl(), but instead READ_ONCE()?
> >
> > Won't readl() be enough? Indeed it looks problematic.
> 
> readl() won't work on big-endian kernels, since this is a byte comparison.

Ah, right.

> 
> > > The other accesses in this file don't use MMIO wrappers either but just treat
> > > it as a pointer. The effect would be the same though.
> >
> > I think all the reads and writes are with readl() and writel().
> 
> I actually see only one other access:
> 
>         copy_addr = sram_exec_copy(emif_data->sram_pool_code,
>                                    (void *)emif_data->ti_emif_sram_virt,
>                                    &ti_emif_sram, ti_emif_sram_sz);
> 
> and this one ends up in a memcpy() that does not perform any byte
> swapping or barriers.

At least the barrier would come through mutex in sram_exec_copy() and
later spin locks for page table manipulation.

Anyway, I do not have the HW to test the changes or to confirm whether
this is real issue.  I guess the driver author/owner should follow up on
this report.

Best regards,
Krzysztof

Re: [PATCH 18/23] memory: mtk-smi: Add argument to function definition

[Arnd Bergmann]

On Thu, Jul 23, 2020 at 9:39 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> Fix checkpatch warning:
>     WARNING: function definition argument 'struct device *' should also have an identifier name
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>

Is this a bug in checkpatch? I don't see why it should warn about this,
as there is no function definition here.

Your change is clearly harmless, but I wonder if we should fix
checkpatch instead.

      Arnd

> ---
>  drivers/memory/mtk-smi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index 109c7e51d551..c21262502581 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -60,7 +60,7 @@ struct mtk_smi_common_plat {
>
>  struct mtk_smi_larb_gen {
>         int port_in_larb[MTK_LARB_NR_MAX + 1];
> -       void (*config_port)(struct device *);
> +       void (*config_port)(struct device *dev);
>         unsigned int                    larb_direct_to_common_mask;
>         bool                            has_gals;
>  };
> --
> 2.17.1
>

Re: [PATCH 18/23] memory: mtk-smi: Add argument to function definition

[Krzysztof Kozlowski]

On Thu, Jul 23, 2020 at 10:50:08AM +0200, Arnd Bergmann wrote:
> On Thu, Jul 23, 2020 at 9:39 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > Fix checkpatch warning:
> >     WARNING: function definition argument 'struct device *' should also have an identifier name
> >
> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> 
> Is this a bug in checkpatch? I don't see why it should warn about this,
> as there is no function definition here.
> 
> Your change is clearly harmless, but I wonder if we should fix
> checkpatch instead.

Good point. If this were not a warning, I would ignore it. However still
the common practice is to add arguments to such type definitions as it
helps to describe the type.

Best regards,
Krzysztof

Re: [PATCH 19/23] memory: omap-gpmc: Enclose macro statements in do-while

[Arnd Bergmann]

On Thu, Jul 23, 2020 at 9:39 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> do-while is a preferred way for complex macros because of safety
> reasons.  This fixes checkpatch error:
>
>     ERROR: Macros starting with if should be enclosed by a do - while
>         loop to avoid possible if/else logic defects
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>

This is an improvement, but the macro still has other issues that
are just as bad as the one you address:

- Using the # operator to avoid the "" in the invocation seems confusing
- it implicitly uses the 'cs' and 't' variables of the calling function instead
  of passing them as arguments.
- it calls 'return -1' in a function that otherwise uses errno-style
  return codes, so this gets interpreted as EPERM "Operation not
  permitted".

I would probably just open-code the entire thing and remove the
macro like:

ret = 0;
ret |= set_gpmc_timing_reg(cs, GPMC_CS_CONFIG2,  0,  3, 0, t->cs_on,
GPMC_CD_FCLK, "cs_on");
ret |= set_gpmc_timing_reg(cs, GPMC_CS_CONFIG2,  8,  12, 0,
t->cs_rd_off, GPMC_CD_FCLK, "cs_rd_off");
ret |= set_gpmc_timing_reg(cs, GPMC_CS_CONFIG2,  16,  20, 0,
t->cs_wr_off, GPMC_CD_FCLK, "cs_wr_off);
...
if (ret)
     return -ENXIO;

Of maybe leave the macro, but remove the if/return part and use
the "ret |= GPMC_SET_ONE(...)" trick to avoid some of the problems.

      Arnd

Re: [PATCH 19/23] memory: omap-gpmc: Enclose macro statements in do-while

[Krzysztof Kozlowski]

On Thu, Jul 23, 2020 at 11:09:40AM +0200, Arnd Bergmann wrote:
> On Thu, Jul 23, 2020 at 9:39 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > do-while is a preferred way for complex macros because of safety
> > reasons.  This fixes checkpatch error:
> >
> >     ERROR: Macros starting with if should be enclosed by a do - while
> >         loop to avoid possible if/else logic defects
> >
> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> 
> This is an improvement, but the macro still has other issues that
> are just as bad as the one you address:
> 
> - Using the # operator to avoid the "" in the invocation seems confusing

I guess it was useful for debugging.

> - it implicitly uses the 'cs' and 't' variables of the calling function instead
>   of passing them as arguments.

Actually another reason to convert it to just a function.

> - it calls 'return -1' in a function that otherwise uses errno-style
>   return codes, so this gets interpreted as EPERM "Operation not
>   permitted".

The users of this macro also do it (gpmc_cs_set_timings()) so this
wrong practice is consistent with the driver. :)

> 
> I would probably just open-code the entire thing and remove the
> macro like:
> 
> ret = 0;
> ret |= set_gpmc_timing_reg(cs, GPMC_CS_CONFIG2,  0,  3, 0, t->cs_on,
> GPMC_CD_FCLK, "cs_on");
> ret |= set_gpmc_timing_reg(cs, GPMC_CS_CONFIG2,  8,  12, 0,
> t->cs_rd_off, GPMC_CD_FCLK, "cs_rd_off");
> ret |= set_gpmc_timing_reg(cs, GPMC_CS_CONFIG2,  16,  20, 0,
> t->cs_wr_off, GPMC_CD_FCLK, "cs_wr_off);
> ...
> if (ret)
>      return -ENXIO;a

I like this approach because it also removes the 'return' from macro
which is not desired.

> 
> Of maybe leave the macro, but remove the if/return part and use
> the "ret |= GPMC_SET_ONE(...)" trick to avoid some of the problems.

I could probably then keep it as a function.  This would be the safest
and remove most of the problems here.

Best regards,
Krzysztof

Re: [PATCH 20/23] memory: omap-gpmc: Fix whitespace issue

[Arnd Bergmann]

On Thu, Jul 23, 2020 at 9:39 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:

> @@ -1756,7 +1756,7 @@ static int gpmc_calc_common_timings(struct gpmc_timings *gpmc_t,
>  /* TODO: remove this function once all peripherals are confirmed to
>   * work with generic timing. Simultaneously gpmc_cs_set_timings()
>   * has to be modified to handle timings in ps instead of ns
> -*/
> + */

This still doesn't follow the normal coding style for multi-line comments.

I don't think it's worth fixing, but if you think it should be changed, then
make it

     /*
      * mult-line comment
      * ...
      */

     Arnd

Re: [PATCH 20/23] memory: omap-gpmc: Fix whitespace issue

[Krzysztof Kozlowski]

On Thu, Jul 23, 2020 at 11:11:08AM +0200, Arnd Bergmann wrote:
> On Thu, Jul 23, 2020 at 9:39 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> 
> > @@ -1756,7 +1756,7 @@ static int gpmc_calc_common_timings(struct gpmc_timings *gpmc_t,
> >  /* TODO: remove this function once all peripherals are confirmed to
> >   * work with generic timing. Simultaneously gpmc_cs_set_timings()
> >   * has to be modified to handle timings in ps instead of ns
> > -*/
> > + */
> 
> This still doesn't follow the normal coding style for multi-line comments.
> 
> I don't think it's worth fixing, but if you think it should be changed, then
> make it
> 
>      /*
>       * mult-line comment
>       * ...
>       */

Sure, thanks for feedback.

Best regards,
Krzysztof

Re: [RFC PATCH 00/23] memory: Cleanup, improve and compile test memory drivers

[Arnd Bergmann]

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

Re: [RFC PATCH 00/23] memory: Cleanup, improve and compile test memory drivers

[Krzysztof Kozlowski]

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

Re: [RFC PATCH 00/23] memory: Cleanup, improve and compile test memory drivers

[Arnd Bergmann]

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

Re: [PATCH 16/23] memory: brcmstb_dpfe: Constify the contents of string

[Florian Fainelli]

On 7/23/20 12:37 AM, Krzysztof Kozlowski wrote:
> The string itself can be made const for safety.
> 
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>

Acked-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian

Re: [PATCH 16/23] memory: brcmstb_dpfe: Constify the contents of string

[Markus Mayer]

On Thu, 23 Jul 2020 at 10:11, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On 7/23/20 12:37 AM, Krzysztof Kozlowski wrote:
> > The string itself can be made const for safety.
> >
> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>

Acked-by: Markus Mayer <mmayer@broadcom.com>

Re: [PATCH 17/23] memory: brcmstb_dpfe: Remove unneeded braces

[Florian Fainelli]

On 7/23/20 12:37 AM, Krzysztof Kozlowski wrote:
> Single statement blocks don't need braces.  Fixes checkpatch warning:
> 
>     WARNING: braces {} are not necessary for single statement blocks
> 
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>

Acked-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian

Re: [PATCH 17/23] memory: brcmstb_dpfe: Remove unneeded braces

[Markus Mayer]

On Thu, 23 Jul 2020 at 10:11, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On 7/23/20 12:37 AM, Krzysztof Kozlowski wrote:
> > Single statement blocks don't need braces.  Fixes checkpatch warning:
> >
> >     WARNING: braces {} are not necessary for single statement blocks
> >
> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>

Acked-by: Markus Mayer <mmayer@broadcom.com>

Re: [PATCH 23/23] MAINTAINERS: Add Krzysztof Kozlowski as maintainer of memory controllers

[Florian Fainelli]

On 7/23/20 12:37 AM, Krzysztof Kozlowski wrote:
> The specific drivers in drivers/memory usually go via architecture (e.g.
> ARM SoC) maintainers but the generic parts (of_memory.[ch]) lacked any
> care.
> 
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>

Acked-by: Florian Fainelli <f.fainelli@gmail.com>

What does this mean for specific drivers? For instance I tend to send
updates to brcmstb_dpfe.c through the Broadcom ARM SoC pull requests,
shall I continue to do this, or are you going to send memory controller
subsystem pull requests including that file in the future?
-- 
Florian

Re: [PATCH 23/23] MAINTAINERS: Add Krzysztof Kozlowski as maintainer of memory controllers

[Krzysztof Kozlowski]

On Thu, Jul 23, 2020 at 10:12:36AM -0700, Florian Fainelli wrote:
> On 7/23/20 12:37 AM, Krzysztof Kozlowski wrote:
> > The specific drivers in drivers/memory usually go via architecture (e.g.
> > ARM SoC) maintainers but the generic parts (of_memory.[ch]) lacked any
> > care.
> > 
> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> 
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> 
> What does this mean for specific drivers? For instance I tend to send
> updates to brcmstb_dpfe.c through the Broadcom ARM SoC pull requests,
> shall I continue to do this, or are you going to send memory controller
> subsystem pull requests including that file in the future?

If that's okay, I intend to take the drivers patches as well. I will
rephrase the commit message.

Thanks for the feddback.

Best regards,
Krzysztof