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

[Russ Dill]

On Fri, Nov 2, 2012 at 1:57 AM, Felipe Balbi <balbi@xxxxxx> wrote:
> Hi,
>
> On Thu, Nov 01, 2012 at 04:49:23PM -0700, Russ Dill wrote:
>> 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
>
> look at what other drivers do. You can read a revision register, you can
> write a command and see if the device responds as expected, it doesn't
> matter.

Since a "revision" register isn't required by the IÂC spec, it isn't
implemented on a huge number of chips. Also, having a few dozen probe
routines come though and write to random address of every single IÂC
device can a) take a really long time, and b) have quite a few
unintended side effects.

>> 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
>
> how ? It's just a read.

Because the IÂC spec is incredibly flexible. For a lot of devices,
reading from a register is done by writing the register address, and
then reading the contents. For devices that don't implement registers
in that way (such as many eeproms), this is just a write.

>> 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)
>
> it doesn't mean it can't be done.

Really? Please, do tell how you would write a detect function for a
PCA9534. It has 4 registers, an input port registers, an output port
register, a polarity inversion register, and a configuration register.
And don't forget, since we are probing, every detect routine for every
IÂC driver will have to run with every IÂC address on every bus,
possibly with both address formats.

>> 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.
>
> so what ? All you want to do with detect is figure out if the far end is
> who you think it is, not what it's doing.

If we already knew who was there, we wouldn't need a detect routine.
--
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/