Re: [patch/rfc 2.6.25-git] gpio: sysfs interface

[David Brownell]

On Monday 28 April 2008, Trent Piepho wrote:
> We have a flash chip with a hardware write protected boot block controlled by
> a gpio.  If we want to flash this block, we need a way to change the gpio. 
> patching the mtd driver to do this automatically would require maintaining an
> out-of-tree patch, I like to avoid those.  We'd also rather mtd didn't
> automatically un-write-protect the boot block; kinda defeats the purpose.
> 
> The device may have a daughtercard installed in it.  There is a gpio used as a
> presence detect.  We want to be able, from userspace (any maybe kernel too),
> to print out "card installed" or "no card installed".  There is also certain
> stuff that should run if the card is present when the machine boots.
> 
> We have some PCA9557 I2C gpio expanders that encode a device version number. 
> We want to print this number out in userspace (e.g.  show it in the web
> interface, various other application specific interfaces, etc.).  Maybe the
> kernel will need to know too, we'll see what happens when there is a version
> two.  The daughter card also has a PCA9557 expander, but of course it might
> not be connected, the pca9557 driver can probe the bus for this.

Good examples.  Note that the "daughtercard installed" cases generalize
somewhat ... it's not uncommon to do like DRAM sticks do with SPD EEPROMS,
and have a cheap EEPROM identifying characteristics of that card, since
different cards need different initialization/setup.

However, I think a slightly more common practice in current embedded
Linux systems is to build custom kernels that know which daughtercard(s)
are available.  That's mostly what gets pushed upstream, anyway...

ISTR that Gumstix distro kernels use a more retro scheme to identify what's
in the card stack:  they poke at various peripheral addresses to see if the
device on a given card is there.  In the PC space, that's what "ISA Legacy
Drivers" do, albeit at the level of individual peripherals, not cards.

- Dave

--
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/