linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@prisktech.co.nz (Tony Prisk)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] PWM: vt8500: Update vt8500 PWM driver support
Date: Mon, 22 Oct 2012 20:36:22 +1300	[thread overview]
Message-ID: <1350891382.3592.22.camel@gitbox> (raw)
In-Reply-To: <20121022072448.GB30026@avionic-0098.mockup.avionic-design.de>

On Mon, 2012-10-22 at 09:24 +0200, Thierry Reding wrote:
> On Mon, Oct 22, 2012 at 08:09:07PM +1300, Tony Prisk wrote:
> > On Mon, 2012-10-22 at 19:51 +1300, Tony Prisk wrote:
> > > > 
> > > > >  	chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
> > > > >  	if (chip == NULL) {
> > > > >  		dev_err(&pdev->dev, "failed to allocate memory\n");
> > > > > @@ -123,26 +144,32 @@ static int __devinit pwm_probe(struct platform_device *pdev)
> > > > >  	chip->chip.ops = &vt8500_pwm_ops;
> > > > >  	chip->chip.base = -1;
> > > > >  	chip->chip.npwm = VT8500_NR_PWMS;
> > > > > +	chip->clk = of_clk_get(np, 0);
> > > > 
> > > > I thought this was supposed to work transparently across OF and !OF
> > > > configurations by using just clk_get() or devm_clk_get()? I guess that
> > > > if the driver depends on OF, then this would be moot, but we should
> > > > probably stick to the standard usage anyway.
> > > > 
> > > > Furthermore, of_clk_get() doesn't seem to be managed, so you'd need to
> > > > add explicit clk_put() in the error cleanup paths. One more argument in
> > > > favour of using devm_clk_get() instead.
> > > 
> > > Hmm good point. I stuck with of_ functions because its an OF only driver
> > > and it seemed 'backward' to mix old code with new. It does pose the
> > > question of 'why have of_clk_get() if existing functions work better'.
> > 
> > Was about to fix this but noticed why it wasn't like this to start
> > with :)
> > 
> > struct clk *devm_clk_get(struct device *dev, const char *id);
> > struct clk *of_clk_get(struct device_node *np, int index);
> > 
> > devm_clk_get requires me to 'get' the clock by name. arch-vt8500 (and I
> > believe a lot of other arch's) don't enforce names for clocks defined in
> > devicetree, therefore there is no way for me to know what name the clk
> > has unless I include in the binding that the clock must be named 'xxx'.
> 
> I thought clk_get() was supposed to return the first clock specified in
> DT if you pass NULL as the consumer name. I haven't tested this though.
> And I haven't looked at the code.
> 
> > of_clk_get retrieves it by the dt-node + index, so it doesn't care as
> > long as its the 1st clock listed.
> 
> So the usual way to do this, I believe, is:
> 
> 	clocks = <&clk_foo>;
> 	clock-names = "foo";
> 
> Then use:
> 
> 	clk = devm_clk_get(&pdev->dev, "foo");
> 
> And as I said above, I was under the impression that the default would
> be to use the first clock if NULL was specified instead of "foo".
> 
> Thierry

clock-names is an optional property (as defined in
bindings/clock/clock-bindings.txt) so relying on it is .. well,
unreliable.

What you say makes sense, but it means the binding document has to make
an optional property into a required property simply to use an 'old'
function when a new function would 'work' (granted not as well, as you
pointed out) without requiring the optional property.

Your subsystem - your rules. Let me know if I've managed to sway you or
not :)

Regards
Tony P

  reply	other threads:[~2012-10-22  7:36 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-19 10:38 [PATCH 1/3] ARM: dts: Update board files for pwm support Tony Prisk
2012-10-19 10:38 ` [PATCH 2/3] PWM: vt8500: Update vt8500 PWM driver support Tony Prisk
2012-10-22  6:34   ` Thierry Reding
2012-10-22  6:51     ` Tony Prisk
2012-10-22  7:09       ` Tony Prisk
2012-10-22  7:24         ` Thierry Reding
2012-10-22  7:36           ` Tony Prisk [this message]
2012-10-22  8:04             ` Thierry Reding
2012-10-22  8:13               ` [PATCH v2] pwm: " Tony Prisk
2012-10-22  8:40                 ` Thierry Reding
2012-10-22 18:10                   ` [PATCH v3] " Tony Prisk
2012-10-23 22:14                     ` Thierry Reding
2012-10-24  3:46                       ` Tony Prisk
2012-10-24  5:41                         ` Thierry Reding
2012-10-24 17:35                           ` Tony Prisk
2012-10-24  3:48                       ` Tony Prisk
2012-10-23  8:41               ` [PATCH 2/3] PWM: " Tony Prisk
2012-10-23  9:22                 ` Thierry Reding
2012-10-23  9:31                   ` Russell King - ARM Linux
2012-10-23  9:56                     ` Thierry Reding
2012-10-22  7:11       ` Thierry Reding
2012-10-22 11:50         ` Arnd Bergmann
2012-10-22 12:07           ` Thierry Reding
2012-10-22 13:52             ` Arnd Bergmann
2012-10-22 15:08               ` Thierry Reding
2012-10-22 17:49                 ` Tony Prisk
2012-10-19 10:38 ` [PATCH 3/3] DOC: PWM: Adding binding document for via,vt8500-pwm Tony Prisk
2012-10-22  6:35   ` Thierry Reding
2012-10-22  6:53     ` Tony Prisk
2012-10-19 22:37 ` [PATCH 1/3] ARM: dts: Update board files for pwm support Tony Prisk

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=1350891382.3592.22.camel@gitbox \
    --to=linux@prisktech.co.nz \
    --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).