linux-kernel - Re: [patch 2.6.24-rc4-mm 4/6] gpiolib: create empty drivers/gpio

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] [day] [month] [year] [list]

Message-Id: <20071210165217.5CB6616AF7A@adsl-69-226-248-13.dsl.pltn13.pacbell.net>
Date:	Mon, 10 Dec 2007 08:52:17 -0800
From:	David Brownell <david-b@...bell.net>
To:	khali@...ux-fr.org
Cc:	linux-kernel@...r.kernel.org, eric.y.miao@...vell.com,
	akpm@...ux-foundation.org
Subject: Re: [patch 2.6.24-rc4-mm 4/6] gpiolib:  create empty drivers/gpio

> > Add an empty drivers/gpio directory for gpiolib based GPIO expanders.
> > We already have three of them (two I2C, one SPI), and there are dozens
> > of similar chips that only exist for GPIO expansion.
> > 
> > This won't be the only place to hold such gpio_chip code.  Many external
> > chips add a few GPIOs as secondary functionality, and platform code
> > frequently needs to closely integrate GPIO and IRQ support.
> > 
> > This is placed *early* in the build/link sequence since it's common for
> > other drivers to depend on GPIOs to do their work, so they need to be
> > initialized early in the device_initcall() sequence.
>
> Note that I foresee potential problems with this. These GPIO drivers
> need I2C or SPI to be initialized before they can load. However on some
> systems, I2C or SPI buses are hanging off GPIOs, meaning that these
> GPIOS need to be initialized before I2C or SPI, respectively.

In those cases the I2C (or SPI) bus will normally be hanging off
some arch/XX/mach-YY/gpio.c platform code, which will usually be
set up so it's "always there".  (As noted by the docs in patch 3/6
of this series.)  Such code often initializes very early, sometimes
even before IRQs are enabled or kmalloc works.

Bitbanging through an I2C or SPI expander would be possible, but
doesn't seem especially practical.  :)


>	I can
> imagine weird setups where for example an SPI bus would be driven by an
> I2C-based GPIO chip, or vice-versa. I sure hope that nobody does this,
> but you never know... And I'm not sure how we would possibly support
> this.

It's just a routine case of init this before that.  Again, the
dependency issue is noted in the docs in patch 3/6 of this series.
Linking these expanders early reduces such problems, it can never
get rid of them.

It's really no different than needing to hold off initialization
of any other device until the I2C based GPIOs are ready, like the
leds-gpio example [1] I posted some time ago.

- Dave

[1] http://marc.info/?l=linux-kernel&m=119370944606415&w=2
    See evm_led_setup(), setting up the leds-gpio device as a
    child of the GPIO expander; and evm_u18_setup(), setting
    up a switch attribute as a child of a different expander.
--
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/