From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] RFC: pinctrl: grab default handler with bus notifiers
Date: Tue, 13 Nov 2012 15:35:50 +0900 [thread overview]
Message-ID: <20121113063546.GD18224@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <50A15A54.3090803@wwwdotorg.org>
On Mon, Nov 12, 2012 at 01:21:40PM -0700, Stephen Warren wrote:
> On 11/11/2012 05:22 AM, Linus Walleij wrote:
> > Another solution that was discussed was whether to move
> > the default pinctrl handle and state grab to the device
> > core as an optional field in struct device itself, but
> > I'd like to first propose this less intrusive mechanism.
> I think doing that approach makes a lot more sense; wouldn't it
> completely avoid the issues with deferred probe that this notifier-based
> method can't solve? It would also be very much in line with e.g.
> dev_get_regmap() - if every resource that a driver required were handled
> like that, then deferred probe could be significantly isolated into the
> driver core rather than in every driver...
I have to say that I agree with this, notifiers seem to make life more
complicated for limited gain. Otherwise I guess we could enhance
notifiers so that they're able to trigger deferrals?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121113/1dba210d/attachment.sig>
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: 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>,
Linus Walleij <linus.walleij@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: Tue, 13 Nov 2012 15:35:50 +0900 [thread overview]
Message-ID: <20121113063546.GD18224@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <50A15A54.3090803@wwwdotorg.org>
[-- Attachment #1: Type: text/plain, Size: 946 bytes --]
On Mon, Nov 12, 2012 at 01:21:40PM -0700, Stephen Warren wrote:
> On 11/11/2012 05:22 AM, Linus Walleij wrote:
> > Another solution that was discussed was whether to move
> > the default pinctrl handle and state grab to the device
> > core as an optional field in struct device itself, but
> > I'd like to first propose this less intrusive mechanism.
> I think doing that approach makes a lot more sense; wouldn't it
> completely avoid the issues with deferred probe that this notifier-based
> method can't solve? It would also be very much in line with e.g.
> dev_get_regmap() - if every resource that a driver required were handled
> like that, then deferred probe could be significantly isolated into the
> driver core rather than in every driver...
I have to say that I agree with this, notifiers seem to make life more
complicated for limited gain. Otherwise I guess we could enhance
notifiers so that they're able to trigger deferrals?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-11-13 6:35 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 [this message]
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
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=20121113063546.GD18224@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.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 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.