On Mon, 08 Nov 2021, Greg KH wrote: > On Mon, Nov 08, 2021 at 11:04:31AM +0000, Lee Jones wrote: > > On Mon, 08 Nov 2021, Kumaravel.Thiagarajan@xxxxxxxxxxxxx wrote: > > > > > Dear Lee Jones, > > > > > > I am Kumaravel Thiagarajan from Microchip, India and I am new to Linux Kernel development. > > > > > > I am currently working on linux kernel driver for one of our PCIe based devices whose BAR 0 maps interface registers for a gpio controller, an OTP memory device controller and an EEPROM device controller into the host processor's memory space. > > > > > > Based on earlier inputs from Linus Walleij, I have developed this as a multi-function device driver - First MFD driver (drivers/mfd) gets loaded for the PCIe device and then it spawns two child devices for OTP/EEPROM and GPIO separately. > > > > You may wish to speak with Greg about your architectural decisions. > > > > He usually dislikes the creation of platform devices from PCI ones. > > Yes, that is NOT ok. > > Platform devices are only for devices that are actually on a platform > (i.e. described by DT or other firmware types). This is probably a bit of an over-simplification. Lots of legitimate platform devices are actually described by DT et al. However, it is true that devices which reside on definite buses; PCI, USB, PCMIA, SCSI, Thunderbolt, etc should not spawn their children off as platform devices. > PCI devices are NOT > platform devices, please use the correct apis for this instead (i.e. the > aux bus) Grep for "auxiliary_device". -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog