On 2/14/19 10:12 AM, masonccyang@xxxxxxxxxxx wrote: > Hi, Hi, >> "Marek Vasut" <marek.vasut@xxxxxxxxx> >> 2019/02/13 下午 08:37 >> >> On 2/13/19 1:16 PM, Mark Brown wrote: >> > On Wed, Feb 13, 2019 at 04:25:32PM +0800, masonccyang@xxxxxxxxxxx wrote: >> > >> >> From current mainline branch, MFD seems support the device which is on >> >> the same hardware bus(i.e, I2C, SPI, MMIO and SPMI)for multi-function >> >> by Read/Write the common same registers. >> > >> > That's most MFDs but there are some that do some level of enumeration >> > (even if it's just looking at the device ID that got registered) to >> > decide what subdevices get registered, that's what people are suggesting >> > here I think. >> >> Right. Although I think some of the code could be shared between the SPI >> and HF modes. > > If it is right that MFD is based on the same hardware bus for multi > function > device,i.e,. based on SPI/I2C/PCI bus to register device by > mfd_add_devices(). > > For a multi function device works on different hardware bus, it has nothing > to do with mfd-core.c(MFD framework) even though their driver are in > drivers/mfd directory, i.e,. mcp-core.x, sm501.c. > > Since RPC-IF works on different hardware bus for SPI bus or CFI > HyperFlash bus, > is it a good idea to implement MFD framework for RPC-IF ? > Or we just separate RPC-IF driver by spi mode and cfi mode ? > > any comments/opinions on RPC-IF/MFD-framework is welcome! Mark mentioned it before, you can use the MFD for MMIO too. The goal here is to have some common code which is shared by the SPI and HF part of the driver, and then a separate SPI handling code and HF handling code. The common code should determine which part to activate based on the DT. -- Best regards, Marek Vasut
