> From: Greg KH <greg@xxxxxxxxx> > Platform drivers are the "catch all" for where you have to talk to tiny > hardware-specific devices. That's normally not an i2c controller. I always thought of these as hardware specific devices, as the FPGA images are hardware specific. Yes, the top level is currently a "real" driver, and the MFD drivers are all platform drivers (as required by the MFD infrastructure). Certainly we integrate with standard subsystems in those drivers (off the top of my head: i2c, gpio, spi, mdio, led, watchdog, and reboot notifier). > So you are creating platform devices for a dynamic device that is on > another bus? Please no, that is an abuse of the platform device code. > That's the biggest reason NOT to use MFD for your code. I was not aware of the alternatives. I inherited the first set of drivers from a proof of concept implementation, and just went with it. Originally, all of this code was in user space, with no integration with standard kernel infrastructure. Movement to standard kernel integration started with the 4.9.168 kernel in the SONiC 201811 branch. > Just make normal drivers for these, no need for MFD at all, why do you > want to use that api here? I will need to read up on the auxiliary bus code and see what it takes to move to it, or another bus driver implementation. > Do you have a pointer to the source for these? That might make it > easier to discuss than general concepts here. The first subset of drivers (meant for out-of-tree builds for OpenBMC) are publicly available in github.com:cisco-open/cisco-8000-kernel-modules. This set accesses the FPGA through an i2c bus, and provides only a subset of drivers that are explicitly needed by OpenBMC. Note that the same FPGA will be accessed via PCI by an X86 processor in the same chassis running a different kernel instance from the OpenBMC ARM instance. The top level in this case is cisco-fpga-bmc.ko. There is a "library" of shared functions in libcisco.ko, including the code to walk the FPGA, discover the IP blocks, and setup the struct mfd_cell array (other common code shared between the blocks include routines to integrate with the reboot notifier, and some arbitration code between the ARM and X86 processors when accessing the same i2c IP block).. The IP blocks being used with OpenBMC include cisco-fpga-gpio.ko cisco-fpga-i2c.ko cisco-fpga-i2c-ext.ko cisco-fpga-info.ko cisco-fpga-msd.ko cisco-fpga-xil.ko Note that there are two different i2c implementations provided in this repository, and there are two more that will eventually be published here. They each have different register specifications and have different capabilities. For example, one type is meant for small SMB accesses, as might be the case with a sensor. Another is meant for larger read/writes, such as might be the case with an eeprom. Another provides for automatic polling of transceivers and providing quick access to the shadow data so read from the transceivers. etc. Walking the FPGA to setup the struct mfd_cell array is within https://github.com/cisco-open/cisco-8000-kernel-modules/blob/main/drivers/cisco/mfd.c One other thing to note, which may be a bit weird, is how we setup regmap. As previously indicated, each IP block (with its own MFD instantiated platform driver) can be accessed in multiple ways, e.g. PCI, I2C, SLPC, and P2PM. The parent driver provides a function for the child device to create a new child specific regmap. As you will see in https://github.com/cisco-open/cisco-8000-kernel-modules/blob/main/drivers/cisco/cisco-fpga-bmc.c there are read/write functions that are used in the child's regmap registration. Similar is done for PCI, SLPC, and P2PM, although those drivers are not in this repository yet. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
