public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Mark Brown <broonie@kernel.org>
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	Tomasz Figa <t.figa@samsung.com>, Olof Johansson <olof@lixom.net>
Subject: Re: [PATCH] regulator: Start using standard gpios property and deprecate some custom properties
Date: Mon, 16 Dec 2013 11:40:23 -0800	[thread overview]
Message-ID: <20131216194023.GE26293@atomide.com> (raw)
In-Reply-To: <20131216183615.GK3185@sirena.org.uk>

* Mark Brown <broonie@kernel.org> [131216 10:37]:
> On Fri, Dec 13, 2013 at 12:07:14PM -0800, Tony Lindgren wrote:
> > We can start moving regulators to using the standard gpios property instead
> > of various custom GPIO related properties. The reason for doing this is that
> > at least regulator-fixed can currently cause silent bugs if "gpios" property
> > is used instead of "gpio" property.
> 
> If the issue is typos then I'm not convinced that for singular GPIOs
> it's going to be helpful, either way is prone to typos.  If the problem
> is error reporting then that seems like a more important thing to fix.

Are you serious? A typo here in the binding leads to silent errors where
nothing happens with the GPIO. That's just totally messed up considering
we use "gpios" instead of "gpio" everywhere else. So both "gpio" and
"gpios" should be parsed for sure.
 
> > Fix the issue by trying to use "gpios" where possible in the drivers that
> > can already use it, and if that fails, then try to use the deprecated custom
> > property for getting the GPIO.
> 
> Please split stuff like this up per driver rather than just sending a
> jumbo patch for the subsystem, it makes it much easier to review
> especially when they're not all doing exactly the same thing.

OK I'll just do patch for the fixed regulator.
 
> > -  - ti,dvs-gpio: GPIO specifier for external DVS pin control of LP872x devices.
> > +  - gpios: GPIO specifier for external DVS pin control of LP872x devices.
> 
> This is definitely a step backwards, it's changing from a named property
> which does a specific thing to a property with no useful semantics in
> the name.  That would be a step backwards for both legibility and
> extensibility, if support for any other GPIO controlled features is
> added then adding them into the sam property is going to be unpleasant
> and lead to the usability failures so typical of the older device tree
> bindings.  The the binding document says to use a name prefix, not to
> call everything just "gpios".

OK let's drop that change and just fix the fixed regulator.
 
> To be honest I'm also struggling to summon up the enthusiasm for the
> churn in the bindings, especially without going through and updating all
> the boards (and all the other GPIO properties in various DTs).  It seems
> like there's stuff missing in the helpers here, if we really wanted to
> force the properties to have -gpios on the end of their names then we
> should've had that being added by the helpers.

Sounds like exposing an infinite number of random *-gpio and *-gpios
bindings is a topic for another discussion. Anyways it's already totally
out of control so what do I care.

Regards,

Tony

  reply	other threads:[~2013-12-16 19:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-13 20:07 [PATCH] regulator: Start using standard gpios property and deprecate some custom properties Tony Lindgren
2013-12-16 18:36 ` Mark Brown
2013-12-16 19:40   ` Tony Lindgren [this message]
2013-12-16 20:11     ` Mark Brown
2013-12-16 21:05       ` Tony Lindgren
2013-12-16 21:40         ` Mark Brown
2013-12-16 23:06           ` Tony Lindgren
2013-12-16 23:37             ` Mark Brown
2013-12-17 15:37               ` Tony Lindgren
2013-12-19 13:26                 ` Mark Brown

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=20131216194023.GE26293@atomide.com \
    --to=tony@atomide.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=t.figa@samsung.com \
    /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