> Further, it is critical to enable hardware vendors to avoid writing > any code for which there are existing drivers. Which is why you don't want to create a new bus type for it. > Capebus seems to me to provide this solution fairly well. I don't > believe the SFI approach covers the most critical aspects of hotplug > behaviour. I think you missed the point - it just an example of doing this not one I'd suggest using directly. > >> > your ->detect() method should take care of that. > >> > >> There isn't some magical serial number in I²C devices that a > >> ->detect() method can read and the implementation of I²C is somewhat > > > > It doesn't matter. > > > > What you are basically talking about is > > > > > > cape layer > > - wtf is this > > - how do I plumb it > > > > - create device nodes with correct name for > > binding, address etc on the right bus > > > > > > i2c layer > > - ooh a new i2c device > > - probe as indicated by device name > > - attach correct driver > > Many of the devices cannot be probed. Look more closely at the code I pointed you at. I wonder if have a differing understanding of the word "probe" in this situation. In the Linux space the driver bindings call the matching probe function based upon the device structure. In Linux the probe method does not mean "scan the bus and enumerate/detect the devices" If an i²c bus is thrown a device which has an address and a matching name the only thing it will attempt to do is to call the probe method of the device driver matching that name on the given i²c address. In other words its a "probe" in the sense of "I've been told there is one of your widgets here, please take a look" not a "probe" in the sense of "scan 255 i²c addresses and poke randomly at them" SFI for example creates entries for things like "type foo pressure sensor at 0x68 on bus 3" and the core kernel i²c code will only call the "foo" drivers probe method and only on bus 3 and only for address 0x68. In your case you want to use your DT fragments or any other descriptor format to do exactly the same. Not create a new bus but add a bunch of devices to the existing busses. It's like hot plugging a PCI card - you don't create a new PCI bus, you add a device to the existing bus. In the PCI case the device has properties that uniquely identify it from hardware level. In the i²c case the properties come from your DT fragment or similar. The rest is the same. > I know I *am* the slow person in the room, but doesn't this approach > require the code to be compiled into the kernel to support the devices > ahead of time? While I think it might be reasonable to have hardware The specific implementation in SFI does but thats a property of SFI. I'm not trying to push SFI itself anywhere except over the edge of a very tall cliff. The point is that you can take a description of things like i²c devices and have then properly identified on the existing busses using the existing bus architecture just fine. > developers provide DT fragments in their EEPROMs, there's no way to > get them to submit code patches in order to get their hardware to > work. They need to ship hardware that works with pre-existing > software, since there will be hundreds of boards created by people > with little to no previous Linux experience (akin to Arduino). I seem > to be missing how that approach would get us there. That is what I assume and what I believe can be provided without inventing imaginary bus types. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
