From: marek.vasut@gmail.com (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 11/13] [ARM] pxa/balloon3: PCF857x GPIO expander and LEDs
Date: Fri, 30 Jul 2010 15:16:07 +0200 [thread overview]
Message-ID: <201007301516.07235.marek.vasut@gmail.com> (raw)
In-Reply-To: <20100730130755.GL6845@dream.aleph1.co.uk>
Dne P? 30. ?ervence 2010 15:07:55 Wookey napsal(a):
> +++ Marek Vasut [2010-07-30 14:36 +0200]:
> > Dne P? 30. ?ervence 2010 14:36:09 Marek Vasut napsal(a):
> > > > > > 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.
> > > > > >
> > > > > > 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?
> > > >
> > > > That was how this list suggested we deal with the unprobe-able build
> > > > variation, I beleive.
> > >
> > > We have loadable kernel modules ever since ... long time ago. Maybe
> > > that's more like the way to go.
>
> But that makes it impossible to have a 'balloon' kernel that works on
> different hardware builds. So far we have been able to have one kernel
> build that works on all the different build variants by using that
> macro to avoid doing things which will hang forever when hardware is
> missing. Having to have a pile of different defconfigs for different
> build options helps no-one (and we don't like defconfigs anymore
> anyway :-)
>
> More generic kernels is good, and ther has been much work on that sort
> of thing recently.
Maybe we should figure out a more generic way of doing this so it can be
reusable on other machines too. Eric ? Maybe the Device tree would help here?
>
> > > > > (especially if the driver can simply fail to probe).
> > > >
> > > > No. Clearly anything that is probe-able should be probed. I thought
> > > > thtat this wouldn't be as I2C devices are pretty dumb, but I guess we
> > > > know its address here so we can try it and if no response then it's
> > > > not there.
> > >
> > > Yes, this one is probeable.
> >
> > Re-adding Eric as he was dropped. Cheers
>
> OK. Just to be clear I am not objecting to any of the stuff Marek is
> posting here. It's great to have some of it upstream at last.
>
> Once we have most of the basic support in we can consider the best
> ways of dealing with the odd configuration issues of balloon variants
> and add-on boards. (I'm not sure what you lot are going to think of
> our Samosa bus - hopefuly it's not too ugly these days as we did make
> it into a proper bus)
>
> So, I am acking these patches.
>
> Wookey
next prev parent reply other threads:[~2010-07-30 13:16 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-29 3:16 [PATCH 01/13] [ARM] pxa/palm: Introduce Palm27x Marek Vasut
2010-07-29 3:16 ` [PATCH 02/13] [ARM] pxa/palm: Flip Palm LD,TX,T5,Z72 to Palm27x Marek Vasut
2010-08-04 3:14 ` Eric Miao
2010-07-29 3:16 ` [PATCH 03/13] [ARM] pxa/palm: Add core pmic support for Palm27x Marek Vasut
2010-07-29 10:03 ` Mike Rapoport
2010-08-04 3:16 ` Eric Miao
2010-07-29 3:16 ` [PATCH 04/13] [ARM] pxa/palm: Modularize rest of code in Palms Marek Vasut
2010-08-04 3:26 ` Eric Miao
2010-07-29 3:16 ` [PATCH 05/13] [ARM] pxa/spitz: Rework spitz Marek Vasut
2010-08-04 5:27 ` Eric Miao
2010-07-29 3:16 ` [PATCH 06/13] [ARM] pxa/spitz: Formating and naming fixes Marek Vasut
2010-08-04 5:27 ` Eric Miao
2010-07-29 3:16 ` [PATCH 07/13] [ARM] pxa/z2: Fix flash layout typo Marek Vasut
2010-08-04 5:36 ` Eric Miao
2010-07-29 3:16 ` [PATCH 08/13] [ARM] pxa/balloon3: Machine file cleanup Marek Vasut
2010-07-29 3:16 ` [PATCH 09/13] " Marek Vasut
2010-07-29 3:16 ` [PATCH 10/13] [ARM] pxa/balloon3: PCMCIA Support Marek Vasut
2010-07-29 10:10 ` Wookey
2010-07-30 4:41 ` Marek Vasut
2010-07-30 5:02 ` Eric Miao
2010-07-30 5:12 ` Marek Vasut
2010-07-30 5:19 ` Eric Miao
2010-07-29 3:16 ` [PATCH 11/13] [ARM] pxa/balloon3: PCF857x GPIO expander and LEDs Marek Vasut
2010-07-29 10:00 ` Wookey
2010-07-30 4:44 ` Marek Vasut
2010-07-30 5:09 ` Eric Miao
2010-07-30 5:19 ` Marek Vasut
2010-07-30 5:21 ` Eric Miao
2010-07-30 9:39 ` Wookey
2010-07-30 12:36 ` Marek Vasut
2010-07-30 12:36 ` Marek Vasut
2010-07-30 13:07 ` Wookey
2010-07-30 13:16 ` Marek Vasut [this message]
[not found] ` <Prayer.1.3.3.1007301954290.28463@hermes-2.csi.cam.ac.uk>
2010-07-30 19:34 ` [Balloon] " Marek Vasut
2010-07-29 3:16 ` [PATCH 12/13] [ARM] pxa/balloon3: Add NAND driver Marek Vasut
2010-07-29 3:16 ` [PATCH 13/13] [ARM] pxa/balloon3: Add MAX1586 PMIC support Marek Vasut
2010-07-29 10:04 ` [PATCH 01/13] [ARM] pxa/palm: Introduce Palm27x Mike Rapoport
2010-07-29 15:54 ` Marek Vasut
2010-07-29 16:16 ` Mike Rapoport
2010-08-04 3:07 ` Eric Miao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201007301516.07235.marek.vasut@gmail.com \
--to=marek.vasut@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).