On Thu, May 01, 2014 at 03:36:29PM -0700, Maxime Ripard wrote: > But it actually doesn't work in a case where you can't really predict > what is on the other side of the bus. Either because, on the board > you're using the pins are exposed and it's pretty much up to the user > to know what to put on it. That could be handled by DT overlays > though. Right, that's a completely unrelated issue. > What never works is where the device on the other side is so generic > that you really can't tell what it does. Think of a microcontroller > that would behave as a SPI slave. It's behaviour and what it does is > pretty much dependant of what we flashed on it, and suddenly the > compatible string is not the proper reprensentation anymore. That sounds like another situation for overlays, really the thing that's compatible here is going to be the whole assembly rather than just the device in isolation (or you're in a similar situation to the one you're in with FPGAs where you have a driver implementing an application like a loadeer > i2c-dev works great in these cases, because you always have access to > all the bus, and all the devices, except if the device is already used > by someone. The patch I suggested is an attempt to mimic this. It seems better to implement something like this at the device model level, provide a way to have a default UIO driver for anything on a given bus. I don't see anything bus specific apart from saying what the default driver to use is and it avoids the icky code fiddling about with what devices are bound and the races that might be involved duplicated in individual buses.
Attachment:
signature.asc
Description: Digital signature
