On Mon, Nov 06, 2017 at 03:42:04PM +0100, Benjamin Gaignard wrote: > 2017-11-02 12:10 GMT+01:00 Mark Brown <broonie@xxxxxxxxxx>: > > On Thu, Nov 02, 2017 at 11:44:07AM +0100, Greg KH wrote: > >> On Tue, Oct 31, 2017 at 07:11:53PM +0000, Mark Brown wrote: > > > >> > There was a discussion a while ago in the context of I2C/SPI MFDs > >> > which concluded that if you need a bus and it's going to be effectively > >> > noop then you should just use the platform bus as anything else will > >> > consist almost entirely of cut'n'paste from the platform bus with some > >> > light sed usage and code duplication is bad. It's not super lovely as > >> > it's not actually a memory mapped device but it's the best idea we've > >> > got. > > > >> Ugh, I hate that. What's wrong with using a "virtual" device instead? > > > > It was the duplication, initially everyone was making buses. > > > >> I can create a "virtual" bus for things like this if they really want a > >> "simple" bus, abusing platform for this is the major reason I hate the > >> platform bus code... > > > > In the MFD case they're physical devices, they're just usually on the > > wrong side of an I2C or SPI link. Plus MFD already handles platform > > devices for things that are memory mapped so it's a bit of a more > > natural fit there. > > What I can do is to register an ion bus (like cec one for example), > add one ion parent device so heaps will appear in /sys/bus/ion/ion* > and /sys/devices/ion/ion* > > Does that could sound good enough ? I would like to see that... thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel