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@xxxxxxxxxx> 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@xxxxxxxxxx > 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