HI, On Thu, Nov 01, 2012 at 03:59:50PM +0200, Pantelis Antoniou wrote: > Hi Alan, > > On Nov 1, 2012, at 3:51 PM, Alan Cox wrote: > > >> What they want, and what every user wants, is I plug this board in, and > >> the driver make sure everything is loaded and ready. No, the end users > >> don't want to see any of the implementation details of how the bitfile > >> is transported; the driver can handle it. > > > > That doesn't necessarily make it a bus merely some kind of hotplug > > enumeration of devices. That should all work properly both for devices > > and busses with spi and i²c as the final bits needed for it got fixed > > some time ago. > > > > In an ideal world you don't want to be writing custom drivers for stuff. > > If your cape routes an i²c serial device to the existing system i²c > > busses then you want to just create an instance of any existing driver on > > the existing i²c bus not create a whole new layer of goop. > > > > It does need to do the plumbing and resource management for the plumbing > > but thats not the same as being a bus. > > > > Alan > > > Fair enough. But there's no such thing a 'hotplug enumeration > construct' in Linux yet, and a bus is the closest thing to it. It does > take advantage of the nice way device code matches drivers and devices > though. > > I'm afraid that having the I2C/SPI drivers doing the detection won't > work. The capes can have arbitrary I2C/SPI devices (and even more > weird components). There is no way to assure for example that the I2C > device responding to address 'foo' in cape A is the same I2C device > responding to the same address in cape B. your ->detect() method should take care of that. -- balbi
Attachment:
signature.asc
Description: Digital signature
