linux-kernel - Re: [PATCH 0/3] capebus moving omap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 1 Nov 2012 16:49:23 -0700
From:	Russ Dill <Russ.Dill@...com>
To:	balbi@...com
Cc:	Pantelis Antoniou <panto@...oniou-consulting.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"Cousson, Benoit" <b-cousson@...com>,
	Tony Lindgren <tony@...mide.com>, linux-kernel@...r.kernel.org,
	Koen Kooi <koen@...inion.thruhere.net>,
	Matt Porter <mporter@...com>, linux-omap@...r.kernel.org,
	Kevin Hilman <khilman@...com>, Paul Walmsley <paul@...an.com>
Subject: Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2

On Thu, Nov 1, 2012 at 3:05 PM, Felipe Balbi <balbi@...com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/