On Wed, 19 Jun 2019, masonccyang@xxxxxxxxxxx wrote: > > > > Looks like a flash device to me. > > > > > > More like a multi-protocol flash controller, with the real flash > chip connected > > > to it. > > > > Right, this has been my point from the start. > > > > It's a flash controller. Sure, you can access it in different ways, > > but it's still *just* a flash controller and thus not a true MFD. > > > > Surely this whole thing, including the shared portion should live in > > one of the memory related subsystems? > > > > This is not the first device people have tried to shove in MFD, that > > is really *just* an <X> device, able to be controlled via different > > protocols. > > > > MFD is for registering child devices of chips which offer genuine > > cross-subsystem functionality. It is not designed for mode selecting, > > or as a place to shove shared code just because a better location > > doesn't appear to exist. > > > > Also, ramming it into drivers/platform/<vendor> is not correct either, > > since this is not a platform controller driver either. > > > I will patch RPC-IF back to SPI only and > rebase onto previous patches as bellow: This sounds more like the easy way out, rather than the right thing to do. Just because this isn't an MFD, doesn't mean it's not suitable for inclusion into the kernel. Take a look at drivers/memory/Kconfig, and see if any of those devices sound familiar. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog