On Tue, 15 Mar 2022, Frank Zago wrote: > Hello Lee, > > >> Changes from v2: > >> - bug fixes > >> - more robust USB enumeration > >> - Changed to an MFD driver as suggested > > > > Perhaps you should have engaged with me before potentially wasting > > your valuable time. > > > > MFD is designed to take a parent platform driver and split it out into > > various sub-systems. If you don't use the MFD Core API (which is the > > case here) it is not an MFD. MFD is not a dumping ground for > > collections of random device drivers. > > > > I have no problem with you placing registration and core code inside > > MFD (that *is* what it was designed for), but the leaf 'functionality' > > should be placed in more appropriate locations. > > > > I2C => drivers/i2c > > SPI => drivers/spi > > GPIO => drivers/gpio (or perhaps drivers/pinctrl) > > USB => drivers/usb > > UART => drivers/tty/serial > > > > Etc ... Find places for everything. > > > > Anything left over, give to Greg (drivers/misc). :) > > > > AFAICS that works if the driver is built-in, but not as a module. How did you reach that conclusion? I expect most of the drivers in MFD and their children to be modules. `git grep module_.*_driver -- drivers/mfd/` > I'd prefer that driver to be a module if desired, and have all its files in the same > place instead of scattered in various directories. The design and organisation of the kernel does not work like that. > I can try drivers/misc if it's a better place. I suspect you'll receive the same advice from Greg and Arnd. -- Lee Jones [李琼斯] Principal Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
