On Tue, Sep 02, 2014 at 09:00:10AM +0100, Lee Jones wrote: > On Mon, 01 Sep 2014, Johan Hovold wrote: > > No, no. USB is not a function of the MFD device, it's the transport. > > Thus there should be no USB MFD-cell. No subdriver can work without it. > > > > And the USB id belongs in the MFD-driver in the same way that an > > i2c id (address) does. > > > > Just like an MFD device with i2c as a transport, this driver would > > function as an arbiter to a shared resource (i.e. the register space). > > The reason it seems much more USB-centric than an i2c-mfd driver is that > > that transport API is simpler and some code have also already been > > generalised (e.g. regmap), whereas we appear to have only two USB > > mfd-drivers thus far. > > > > The viperboard is perhaps a bad example in so far that it has pushed the > > transport details down into the subdrivers (and thus into gpio, i2c and > > iio subsystems) instead of handling it one place. > > Thanks for your explanation. I take your point about the USB ID and I > did say I was guessing that the USB part should exist as a child > device. > > So after your comments I decided to do a little investigation. It > appears that this MFD driver is _just_ using the common API which all > other devices utilising USB comms are forced to use. Is that correct? Yes, it's using the low-level USB API, but there's a lot of higher-level interfaces in place for (fairly) standard things such as the USB class drivers or the USB serial subsystem. > If so, I have a question. Is there no way to hide more of the USB > specifics inside a better, simpler API? It looks like the drivers > which use USB are subjected to a lot (too much) of what might be > considered internals. Or is it just that the client has to tinker > with too many dials to get anything sensible out? *shudders* Unfortunately, anything that does not already have a driver is likely to use some vendor-specific protocol and therefore must use the low-level API. > > I haven't looked at the details of the protocol for the device in > > question, but it might even be possible to use regmap here (as I > > mentioned in my comments on v1). > > Obviously that would be preferred. Simple register-based USB MFD devices (e.g. only using control transfers) are conceivable though, and if we start seeing a lot of those (which I doubt) perhaps that part could be refactored as a regmap bus. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
