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 for Android: free password hash cracker in your pocket

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

Message-ID: <CA+Bv8Xb_W-VfNM1WfT5YyKMnOUYBp6qg7_CEFvPq3690dbWY3w@mail.gmail.com>
Date:	Fri, 2 Nov 2012 09:44:31 -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 Fri, Nov 2, 2012 at 4:00 AM, Felipe Balbi <balbi@...com> wrote:
> Hi,
>
> On Fri, Nov 02, 2012 at 02:42:51AM -0700, Russ Dill wrote:
>> >> 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.
>
> read them and match to their reset values, perhaps ?

So its ok for it to not work on warm reset? Also, I'm pretty sure [
random, 0xff, 0x00, 0xff ] describes quite a few chips.

>> 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.
>
> not *every* I2C address. What you say is wrong, a ->detect() method will
> only run for those addresses which the device can actually assume.

OK, that's still a potentially large number of addresses.

>> >> 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.
>
> of course not :-) But the whole discussion has been about not knowing
> which capes (and thus which devices) are attached to the bone.

Eh? Finding out which bone is connected is pretty easy, they all have
an EEPROM with identifying information. That isn't the problem that
capebus is solving, capebus is solving the problem of enumerating that
hardware.
--
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/