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
| ||
|
Date: Fri, 2 Nov 2012 11:21:04 +0000 From: Alan Cox <alan@...rguk.ukuu.org.uk> To: Russ Dill <Russ.Dill@...com> Cc: balbi@...com, Pantelis Antoniou <panto@...oniou-consulting.com>, "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 > >> 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. A bus is the wrong construct. You need something to add devices onto the busses. You can do that. The Intel SFI layer on phones for example enumerates devices through a firmware table set and creates them on the right actual physical bus not on their own fake one. It's not hotplug in the sense that the phone happens be a fixed configuration but it does support hotplug behaviour because the order of the drivers and enumeration is undefined (and both orders work). > >> > >> 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 It doesn't matter. What you are basically talking about is cape layer - wtf is this - how do I plumb it - create device nodes with correct name for binding, address etc on the right bus i2c layer - ooh a new i2c device - probe as indicated by device name - attach correct driver Architecturally its possible you want to make some caps MFDs if they have their own bus heirarchies etc but generally I doubt it. Take a look at arch/x86/platform/mrst/mrst.c. It's a specific example of a platform which parses tables and attaches devices to the right physical bus in a manner they can be reliably probed even when the device has no sane autodetect. Alan -- 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/
Powered by blists - more mailing lists