mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
	Pawel Moll <Pawel.Moll@arm.com>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	MyungJoo Ham <myungjoo.ham@samsung.com>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>
Subject: Re: [RFC PATCH 5/6] extcon-gpio: Describe devicetree bindings
Date: Mon, 16 Sep 2013 15:21:47 +0100	[thread overview]
Message-ID: <20130916142147.GF30650@e106331-lin.cambridge.arm.com> (raw)
In-Reply-To: <20130912165304.GA12202@roeck-us.net>

On Thu, Sep 12, 2013 at 05:53:04PM +0100, Guenter Roeck wrote:
> On Thu, Sep 12, 2013 at 05:41:00PM +0100, Mark Rutland wrote:
> > On Fri, Aug 30, 2013 at 05:29:37AM +0100, Guenter Roeck wrote:
> > > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> > > ---
> > >  .../devicetree/bindings/extcon/extcon-gpio         |   23 ++++++++++++++++++++
> > >  1 file changed, 23 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio
> > > 
> > > diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio b/Documentation/devicetree/bindings/extcon/extcon-gpio
> > > new file mode 100644
> > > index 0000000..091ddc6
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/extcon/extcon-gpio
> > > @@ -0,0 +1,23 @@
> > > +Device-Tree bindings for extcon/extcon-gpio driver
> > 
> > Bindings shouldn't refer to Linux-specifics like particular drivers.
> > What class of hardware are you actually trying to describe?
> > 
> Agreed. Question is where to put the bindings, as they are not really 
> specific to the extcon driver. The extcon driver merely implements 
> the bindings. This is why the "compatible" statement reads "gpio-connector"
> and not "extcon-something".
> 
> The bindings describe a connector managed through gpio pins.

Ok, then that's what the binding document should state.

> 
> > > +
> > > +Required properties:
> > > +	- compatible = "gpio-connector";
> > > +	- presence-detect-gpios - presence detect gpio pin
> > > +
> > > +Optional properties:
> > > +	- debounce-interval - debounce interval in milli-seconds
> > > +	- state-on - on (connected) state
> > > +	- state-off - off (disconnected) state
> > > +	  Depending on the type of connector or cable, states may
> > > +	  for example be reported as "connected"/"disconnected"
> > > +	  or "inserted"/"removed".
> > 
> > I don't understand what the state-* properties describe. Do these
> > provide semantic information to drivers? What is the full set of valid
> > values?
> > 
> That is merely text which is ultimately passed on to the user.
> Guess 'semantic information' might be a way to phrase it.

Where do these end up appearing to the user? Through names in the
filesystem? That's an ABI, which should be thoroughly described...

If it's arbitrary, why is it necessary at all? Surely sensible names for
the state of the connector can be coded in the driver for the device
attached to said connectors (which can be consistent and later changed
if necessary)...

> 
> > > +
> > > +Example node:
> > > +
> > > +	some-connector {
> > > +		compatible = "gpio-connector";
> > > +		presence-detect-gpios = <&gpio1 7 1>;
> > > +		debounce-interval = <1>;
> > > +		state-on = "connected";
> > > +		state-on = "disconnected";

I don't think that's a valid dts. I assume the second is meant to be
"state-off"?

> > > +	};
> > 
> > I'm not sure how much value this adds to bindings over describing the
> > gpios directly. This seems to add a layer of indirection because of
> > Linux internals.
> > 
> Not sure I understand what you mean with "describing the gpios directly".
> Can you elaborate and/or provide an example ?

Take a look at the MMC bindings [1], specifically the cd-gpios and
wp-gpios properties. I don't see why the connection of the GPIO needs to
be described by a wrapper device that doesn't really exist, when it can
be described directly.

> 
> How would you describe the use of gpio pins used to detect board presence ?
> That doesn't seem very Linux specific to me.

As above, with cd-gpios.

Thanks,
Mark.

[1] Documentation/devicetree/bindings/mmc/mmc.txt

  reply	other threads:[~2013-09-16 14:22 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-30  4:29 [PATCH 0/6] extcon-gpio: Add devicetree support Guenter Roeck
2013-08-30  4:29 ` [PATCH 1/6] extcon-gpio: Do not unnecessarily initialize variables Guenter Roeck
2013-09-11  1:16   ` Chanwoo Choi
2013-08-30  4:29 ` [PATCH 2/6] extcon-gpio: If the gpio driver/chip supports debounce, use it Guenter Roeck
2013-09-11  1:16   ` Chanwoo Choi
2013-09-11  1:57     ` Guenter Roeck
2013-09-11  2:03       ` Chanwoo Choi
2013-09-11  2:16   ` [PATCH v2 2/6] extcon-gpio: Use gpio driver/chip debounce if supported Guenter Roeck
2013-09-11  2:29     ` Chanwoo Choi
2013-09-11  2:39       ` Guenter Roeck
2013-08-30  4:29 ` [PATCH 3/6] extcon-gpio: Add support for active-low presence detect pins Guenter Roeck
2013-09-11  2:14   ` Chanwoo Choi
2013-09-11  2:25     ` [PATCH v2 " Guenter Roeck
2013-09-11 23:57       ` Chanwoo Choi
2013-09-12  0:23         ` Guenter Roeck
2013-08-30  4:29 ` [RFC PATCH 4/6] extcon-gpio: Add devicetree support Guenter Roeck
2013-09-12 16:45   ` Mark Rutland
2013-09-12 17:00     ` Guenter Roeck
2013-08-30  4:29 ` [RFC PATCH 5/6] extcon-gpio: Describe devicetree bindings Guenter Roeck
2013-09-12 16:41   ` Mark Rutland
2013-09-12 16:53     ` Guenter Roeck
2013-09-16 14:21       ` Mark Rutland [this message]
2013-09-16 15:19         ` Guenter Roeck
2013-09-18 15:38           ` Mark Rutland
2013-09-19 16:42             ` Mark Brown
2013-09-19 18:28               ` Guenter Roeck
2013-09-19 18:35                 ` Mark Brown
2013-08-30  4:29 ` [RFC PATCH 6/6] extcon-gpio: Describe possible properties to support multi-type cables Guenter Roeck

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=20130916142147.GF30650@e106331-lin.cambridge.arm.com \
    --to=mark.rutland@arm.com \
    --cc=Pawel.Moll@arm.com \
    --cc=cw00.choi@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=ian.campbell@citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=myungjoo.ham@samsung.com \
    --cc=rob.herring@calxeda.com \
    --cc=swarren@wwwdotorg.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

all inboxes | Powered by JetHome®