On Fri, 17 Apr 2020 17:31:49 +0200 Marek Vasut <marex@xxxxxxx> wrote: > On 4/17/20 5:29 PM, Christophe Kerello wrote: > > > > > > On 4/16/20 9:53 PM, Boris Brezillon wrote: > >> On Wed, 15 Apr 2020 17:57:27 +0200 > >> Christophe Kerello <christophe.kerello@xxxxxx> wrote: > >> > >>> The driver adds the support for the STMicroelectronics FMC2 EBI > >>> controller > >>> found on STM32MP SOCs. > >>> > >>> Signed-off-by: Christophe Kerello <christophe.kerello@xxxxxx> > >>> Tested-by: Marek Vasut <marex@xxxxxxx> > >>> --- > >>> Changes in v2: > >>> - call 2 APIs to manage FMC2 enable/disable instead of ops > >>> - call 2 APIs to manage FMC2 NWAIT shared signal instead of ops > >>> > >>> drivers/bus/Kconfig | 11 + > >>> drivers/bus/Makefile | 1 + > >>> drivers/bus/stm32-fmc2-ebi.c | 1091 > >>> ++++++++++++++++++++++++++++++++++++++++++ > >> > >> Hm, I see that other memory bus controller drivers are placed under > >> drivers/memory/, any reason for choosing drivers/bus/? If that's where > >> we want to have all generic memory bus controllers to live it might be > >> worth moving existing drivers to the drivers/bus/ directory at some > >> point. > >> > > > > Hi Boris, > > > > I see this controller as an external bus interface as we are able to > > attach different devices on it, like a PSRAM, an ethernet controller, a > > FPGA, a LCD display, ... > > > > When I had a look at bus/Kconfig file, I have found similar drivers > > (like IMX_WEIM or QCOM_EBI2 drivers). These drivers are able to connect > > devices like NAND Flash, SRAM, ethernet adapters, FPGAs and LCD displays > > as it is written in the Kconfig file. > > > > But, after checking memory/Kconfig file, it is also possible to find > > similar drivers (like ATMEL_EBI driver that is inspired by the WEIM bus > > driver). > > > > So, I will follow the recommendation and I will move it to > > drivers/memory folder if it is the place where this driver should be. > > The EBI isn't a memory bus, you can very well have a non-memory device, > like an external parallel bus memory controller on it. So why should it > be in drivers/memory ? Just like most of those so-called memory bus controllers we have under drivers/memory/ => they are most of the time used to interact with memories but can also be used for other things (Christophe listed a few uses cases). And I'm not pushing one way or the other, all I said was that we should makes things consistent instead of having half of those controller drivers in drivers/memory/ and the other half in drivers/bus/.
