From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/1] gpio: drop CONFIG_OF_GPIO in the definition of the struct gpio_chip
Date: Mon, 13 Feb 2012 19:26:02 -0600 [thread overview]
Message-ID: <4F39B82A.3040404@gmail.com> (raw)
In-Reply-To: <4F392537.8070505@atmel.com>
On 02/13/2012 08:59 AM, Nicolas Ferre wrote:
> On 02/13/2012 03:33 PM, Rob Herring :
>> On 02/13/2012 08:12 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 08:00 Mon 13 Feb , Rob Herring wrote:
>>>> On 02/13/2012 03:23 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>> this will allow to avoid the ifdef CONFIG_OF_GPIO in gpio drivers
>>>>>
>>>>
>>>> So would always enabling CONFIG_OF on at91 and then only 1 sub-arch is
>>>> paying the price for additional space. Then we would only have ifdefs in
>>>> the truly cross-platform gpio drivers.
>>> we talk about 12bytes and here it's force to put a ifdef in the gpio drivers
>>> in platform_device we don't do so. So why should be do it here??
>>
>> But you are affecting everyone. I'm not saying we shouldn't do this. I'm
>> just highlighting the reason this is a problem and gpio is just one
>> instance. I think sub-arches should either always select OF or not.
>> Trying to do both is just going to be a pain to maintain.
>
> (nothing related to the particular case discussed here, but...)
>
> Rob,
>
> It may be a pain to maintain (and I can tell it is), but we do not have
> the choice: the AT91 family is simply too widely spread in terms of
> number of SoC and release date of those SoC. We must maintain all of
> them working while we are doing the effort to switch most of the
> material to DT. As this work takes time I fear that the transition
> period will last for a long time.
>
> Older SoCs will surely never be converted to device-tree as both the
> lack of workforce, customer habits and amount of boards existing and
> working correctly in mainline will go against this.
I'm not saying convert all the boards to DT, just unconditionally enable
the config option. The only impact with that is kernel size, but I
haven't quantified how much of an increase that is though. Is it a big
deal if the boards are only minimally being maintained compared to the
maintenance?
Rob
prev parent reply other threads:[~2012-02-14 1:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-13 9:23 [PATCH 1/1] gpio: drop CONFIG_OF_GPIO in the definition of the struct gpio_chip Jean-Christophe PLAGNIOL-VILLARD
2012-02-13 10:18 ` Nicolas Ferre
2012-02-13 10:37 ` Jean-Christophe PLAGNIOL-VILLARD
2012-02-13 14:00 ` Rob Herring
2012-02-13 14:12 ` Jean-Christophe PLAGNIOL-VILLARD
2012-02-13 14:33 ` Rob Herring
2012-02-13 14:59 ` Nicolas Ferre
2012-02-14 1:26 ` Rob Herring [this message]
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=4F39B82A.3040404@gmail.com \
--to=robherring2@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).