Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2

[Russ Dill]

On Thu, Nov 1, 2012 at 3:05 PM, Felipe Balbi <balbi@xxxxxx> wrote:
> 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.

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
flexible. One devices read may be another devices write. A detect
method that only performs reads could easily toggle a gpio that resets
the board, rewrite and eeprom, or set the printer on fire. If you
browse through various detect functions, yes, some of them key off an
ID, but a lot of them just check various registers to see if certain
bits are zero, or certain bits are one. A lot of IÂC devices I've
dealt with have no good way of probing them, especially GPIO chips
(you'll notice none of the IÂC GPIO expanders have detect functions)

On top of all this the detect routine does not tell you if the alert
pin is connected to some IRQ, or in the case of a GPIO expander, what
those GPIOs are connected to, etc, etc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/