Re: [Balloon] [PATCH 11/13] [ARM] pxa/balloon3: PCF857x GPIO…

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Marek Vasut
Date:  
To: Eric Miao
CC: Wookey, Balloon, linux-arm-kernel
Subject: Re: [Balloon] [PATCH 11/13] [ARM] pxa/balloon3: PCF857x GPIO expander and LEDs
Dne Pá 30. července 2010 07:09:00 Eric Miao napsal(a):
> On Fri, Jul 30, 2010 at 12:44 PM, Marek Vasut <> wrote:
> > Dne Čt 29. července 2010 12:00:41 Wookey napsal(a):
> >> +++ Marek Vasut [2010-07-29 05:16 +0200]:
> >> > Add supported for PCF8574A GPIO expander and LEDs attached to it.
> >>
> >> This IO board is an add-on used in some ballon configurations, not
> >> part of the core board. There needs to be some way of selecting this
> >> support when the loon is used in this configuration. We have the
> >> balloon_has() macro which is used for dealing with the different
> >> builds of the board itself. Perhaps it should be extended to deal with
> >> add-on board functionality too?
> >>
> >> More obvious is using the CONFIG system to just enable this if
> >> CUED_IO_BOARD is configured.
> >
> > You can just disable the PCF driver if you want to save space. In case
> > you won't have the CUED board connected, the driver will just fail to
> > probe so it's ok I believe.
> >
> > The macro could be extended, but do we want such a weird stuff in kernel?
> > (especially if the driver can simply fail to probe).
>
> Are we able to detect this expansion board at run-time and registers
> i2c/led-gpio if present. The thing I'm worried more on space is the
> gpio_leds will be registered there even without the expansion board,
> but what if someone tries to read/write to those LED controls?


They won't register because the GPIOs won't be there.
>
> >> Wookey
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> >
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel