linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 03/10] pwm: Add device tree support
Date: Thu, 15 Mar 2012 10:29:45 +0000	[thread overview]
Message-ID: <20120315102944.GB3138@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <201203150840.42659.arnd@arndb.de>

On Thu, Mar 15, 2012 at 08:40:42AM +0000, Arnd Bergmann wrote:
> On Wednesday 14 March 2012, Thierry Reding wrote:

> > +static struct pwm_chip *of_node_to_pwmchip(struct device_node *np)
> > +{

> > +	return ERR_PTR(-EPROBE_DEFER);
> > +}

> EPROBE_DEFER doesn't exist yet in my kernel, and I wonder if it's actually
> safe to be used this way, because it can result in arbitrary drivers using
> this to be put on the defered probe list. It certainly sounds like the
> right thing to do in the long run though.

Similar code is going in for regulators in 3.4 along with the core
-EPROBE_DEFER change (though not OF specific) and I sent a similar patch
for GPIOs too, hopefully Grant will ack it in time for it to make it in.

My theory is that since you need to explicitly know that the thing
you're requesting is there in order to request it (eg, have a PWM number
or DT link) the overwhemlingly common case for a failure to request will
be that the provider didn't register yet which is exactly the case where
deferral is desired.  It therefore seems sensible to have the framework
default the drivers to retrying rather than have almost every individual
driver look at the failure, figure out if it was a missing provider, and
then retry.  Drivers that have a good reason to fail can always check
for -EPROBE_DEFER and override it.

The result should be that we can take advantage of probe deferral over
large areas of the kernel without having to go and explicitly modify so
many drivers - if the frameworks like GPIO, clk and regulator can do
this that ought to cover 90% of the cases where probe deferral will be
needed without having to do anything more than have good error handling
paths on probe which is a good idea anyway.
-------------- 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/20120315/09137da3/attachment.sig>

  reply	other threads:[~2012-03-15 10:29 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-14 15:56 [PATCH v4 00/10] Add PWM framework and device tree support Thierry Reding
2012-03-14 15:56 ` [PATCH v4 01/10] PWM: add pwm framework support Thierry Reding
2012-03-14 20:52   ` Lars-Peter Clausen
2012-03-14 20:57     ` Thierry Reding
2012-03-16  7:19   ` Shawn Guo
2012-03-16  7:28     ` Thierry Reding
2012-03-20  1:55   ` Stephen Warren
2012-03-20  5:59     ` Thierry Reding
2012-03-14 15:56 ` [PATCH v4 02/10] pwm: Allow chips to support multiple PWMs Thierry Reding
2012-03-14 20:42   ` H Hartley Sweeten
2012-03-14 20:49     ` Thierry Reding
2012-03-15  0:42       ` H Hartley Sweeten
2012-03-14 15:56 ` [PATCH v4 03/10] pwm: Add device tree support Thierry Reding
2012-03-14 20:11   ` Sascha Hauer
2012-03-14 20:46     ` Thierry Reding
2012-03-15  8:40   ` Arnd Bergmann
2012-03-15 10:29     ` Mark Brown [this message]
2012-03-15 12:44       ` Arnd Bergmann
2012-03-20  2:12   ` Stephen Warren
2012-03-20  5:51     ` Thierry Reding
2012-03-14 15:56 ` [PATCH v4 04/10] ARM: tegra: Fix PWM clock programming Thierry Reding
2012-03-20  2:15   ` Stephen Warren
2012-03-14 15:56 ` [PATCH v4 05/10] ARM: tegra: Provide clock for only one PWM controller Thierry Reding
2012-03-20  2:18   ` Stephen Warren
2012-03-20  8:44     ` Thierry Reding
2012-03-20 15:27       ` Stephen Warren
2012-03-14 15:56 ` [PATCH v4 06/10] pwm: Add NVIDIA Tegra SoC support Thierry Reding
2012-03-16  8:00   ` Shawn Guo
2012-03-16  8:21     ` Thierry Reding
2012-03-20  2:35   ` Stephen Warren
2012-03-14 15:56 ` [PATCH v4 07/10] pwm: tegra: Add device tree support Thierry Reding
2012-03-20  2:42   ` Stephen Warren
2012-03-20  8:48     ` Thierry Reding
2012-03-20 15:33       ` Stephen Warren
2012-03-20 15:44         ` Thierry Reding
2012-04-04  7:04     ` Shawn Guo
2012-04-04 18:33       ` Stephen Warren
2012-03-14 15:56 ` [PATCH v4 08/10] pwm: Add Blackfin support Thierry Reding
2012-03-14 15:56 ` [PATCH v4 09/10] pwm: Add PXA support Thierry Reding
2012-03-15  0:13   ` Ryan Mallon
2012-03-15  6:56     ` Thierry Reding
2012-03-15  9:05       ` Sascha Hauer
2012-03-15  9:21         ` Thierry Reding
2012-03-15  9:45           ` Sascha Hauer
2012-03-16  8:12   ` Shawn Guo
2012-03-16  8:29     ` Thierry Reding
2012-03-14 15:56 ` [PATCH v4 10/10] pwm-backlight: Add rudimentary device tree support Thierry Reding
2012-03-15  8:48   ` Arnd Bergmann
2012-03-20  2:59   ` Stephen Warren
2012-03-20  8:39     ` Thierry Reding
2012-03-20 15:27       ` Stephen Warren
2012-03-20 15:43         ` Thierry Reding
2012-03-20 15:56           ` Stephen Warren
2012-03-20 16:08             ` Mark Brown
2012-03-14 23:19 ` [PATCH v4 00/10] Add PWM framework and " H Hartley Sweeten
2012-03-15  6:41   ` Thierry Reding

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=20120315102944.GB3138@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 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).