From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] RFC: pinctrl: grab default handler with bus notifiers
Date: Fri, 16 Nov 2012 09:09:55 -0700 [thread overview]
Message-ID: <50A66553.3050705@wwwdotorg.org> (raw)
In-Reply-To: <CACRpkdYd6B-fTfUg18q5BjZRbY7sUAUNXA_7VPBs9SQoug9Q4w@mail.gmail.com>
On 11/16/2012 04:36 AM, Linus Walleij wrote:
> On Thu, Nov 15, 2012 at 7:23 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 11/15/2012 07:03 AM, Linus Walleij wrote:
>
>>> OK I'll have to come up with a patch to the device core
>>> instead... it'll be much simpler anyway and if both of you guys
>>> can back it I guess Greg might be OK with it too.
>>
>> I did have one thought here; how will this interact with hogs? If a
>> device's pinctrl configuration must be pinctrl_get()'d before the device
>> is probed, then a pinctrl device with hogs will never get probed because
>> it won't be registered to provide the pinctrl node parsing.
>
> Catch 22 :-(
>
> Yeah we need to come up with something there.
>
>> Solutions might include:
>>
>> a) Some special case where if the pinctrl driver only can't probe due to
>> missing pinctrl from its own node, don't defer the probe, but defer the
>> pinctrl_get().
>>
>> b) Separate out DT node parsing from device instantiation, so that the
>> driver can always parse the DT, without needing the context of a
>> specific pinctrl device to do so.
>
> But this mechanism can't be device tree-specific, we have some
> of olschool pdata users and ACPI probing around the corner.
>
> I will likely just cook up something like seeing if the
> dev_name() for provider and consumer is the same and
> in that case avoid deferral.
Well, the DT parsing is all about creating the mapping table from the
DT. Without DT, this doesn't need to happen, since the board file
already contains the complete mapping table. So, this isn't so much a
special case for DT, but rather simply a step we don't need to take for
DT, if you get what I mean (and that's all true irrespective of the
change we're discussing here).
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>,
Linus Walleij <linus.walleij@stericsson.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Stephen Warren <swarren@nvidia.com>,
Anmar Oueja <anmar.oueja@linaro.org>, Felipe Balbi <balbi@ti.com>,
Benoit Cousson <b-cousson@ti.com>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Mitch Bradley <wmb@firmworks.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>, Kevin Hilman <khilman@ti.com>,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
Rickard Andersson <rickard.andersson@stericsson.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Russell King <linux@arm.linux.org.uk>
Subject: Re: [PATCH] RFC: pinctrl: grab default handler with bus notifiers
Date: Fri, 16 Nov 2012 09:09:55 -0700 [thread overview]
Message-ID: <50A66553.3050705@wwwdotorg.org> (raw)
In-Reply-To: <CACRpkdYd6B-fTfUg18q5BjZRbY7sUAUNXA_7VPBs9SQoug9Q4w@mail.gmail.com>
On 11/16/2012 04:36 AM, Linus Walleij wrote:
> On Thu, Nov 15, 2012 at 7:23 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 11/15/2012 07:03 AM, Linus Walleij wrote:
>
>>> OK I'll have to come up with a patch to the device core
>>> instead... it'll be much simpler anyway and if both of you guys
>>> can back it I guess Greg might be OK with it too.
>>
>> I did have one thought here; how will this interact with hogs? If a
>> device's pinctrl configuration must be pinctrl_get()'d before the device
>> is probed, then a pinctrl device with hogs will never get probed because
>> it won't be registered to provide the pinctrl node parsing.
>
> Catch 22 :-(
>
> Yeah we need to come up with something there.
>
>> Solutions might include:
>>
>> a) Some special case where if the pinctrl driver only can't probe due to
>> missing pinctrl from its own node, don't defer the probe, but defer the
>> pinctrl_get().
>>
>> b) Separate out DT node parsing from device instantiation, so that the
>> driver can always parse the DT, without needing the context of a
>> specific pinctrl device to do so.
>
> But this mechanism can't be device tree-specific, we have some
> of olschool pdata users and ACPI probing around the corner.
>
> I will likely just cook up something like seeing if the
> dev_name() for provider and consumer is the same and
> in that case avoid deferral.
Well, the DT parsing is all about creating the mapping table from the
DT. Without DT, this doesn't need to happen, since the board file
already contains the complete mapping table. So, this isn't so much a
special case for DT, but rather simply a step we don't need to take for
DT, if you get what I mean (and that's all true irrespective of the
change we're discussing here).
next prev parent reply other threads:[~2012-11-16 16:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-11 12:22 [PATCH] RFC: pinctrl: grab default handler with bus notifiers Linus Walleij
2012-11-11 12:22 ` Linus Walleij
2012-11-12 20:21 ` Stephen Warren
2012-11-12 20:21 ` Stephen Warren
2012-11-13 6:35 ` Mark Brown
2012-11-13 6:35 ` Mark Brown
2012-11-15 14:03 ` Linus Walleij
2012-11-15 14:03 ` Linus Walleij
2012-11-15 14:26 ` Thomas Petazzoni
2012-11-15 14:26 ` Thomas Petazzoni
2012-11-15 17:24 ` Linus Walleij
2012-11-15 17:24 ` Linus Walleij
2012-11-15 18:27 ` Stephen Warren
2012-11-15 18:27 ` Stephen Warren
2012-11-15 18:23 ` Stephen Warren
2012-11-15 18:23 ` Stephen Warren
2012-11-16 11:36 ` Linus Walleij
2012-11-16 11:36 ` Linus Walleij
2012-11-16 16:09 ` Stephen Warren [this message]
2012-11-16 16:09 ` Stephen Warren
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=50A66553.3050705@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.