devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Srinivas KANDAGATLA <srinivas.kandagatla@st.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
	Pawel Moll <Pawel.Moll@arm.com>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Rob Landley <rob@landley.net>,
	Mauro Carvalho Chehab <m.chehab@samsung.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC] media: rc: OF: Add Generic bindings for remote-control
Date: Fri, 27 Sep 2013 14:26:12 +0100	[thread overview]
Message-ID: <52458774.1060909@st.com> (raw)
In-Reply-To: <20130927113458.GB18672@e106331-lin.cambridge.arm.com>

On 27/09/13 12:34, Mark Rutland wrote:

>> > +	- rx-mode: Can be "infrared" or "uhf". rx-mode should be present iff
>> > +	  the rx pins are wired up.
> I'm unsure on this. What if the device has multiple receivers that can
> be independently configured? What if it supports something other than
> "infrared" or "uhf"? What if a device can only be wired up as
> "infrared"? 
> 
> I'm not sure how generic these are, though we should certainly encourage
> bindings that can be described this way to be described in the same way.
> 
>> > +	- tx-mode: Can be "infrared" or "uhf". tx-mode should be present iff
>> > +	  the tx pins are wired up.
> I have similar concerns here to those for the rx-mode property.
> 
Initially rx-mode and tx-mode sounded like more generic properties
that's the reason I ended up in this route. But after this discussion it
looks like its not really generic enough to cater all the use cases.

It make sense for me to perfix "st," for these properties in the st-rc
driver rather than considering them as generic properties.

> I think what we actually need to document is the process of creating a
> binding in such a way as to encourage uniformity. Something like the
> following steps:
I agree, It will help.. :-)
> 
> 1. Look to see if a binding already exists. If so, use it.
> 
> 2. Is there a binding for a compatible device? If so, use/extend it.
> 
> 3. Is there a binding for a similar (but incompatible) device? Use it as
>    a template, possibly factor out portions into a class binding if
>    those portions are truly general.
> 
> 4. Is there a binding for the class of device? If so, build around that,
>    possibly extending it.
> 
> 5. If there's nothing relevant, create a binding aiming for as much
>    commonality as possible with other devices of that class that may
>    have bindings later.

Thanks for this little guide...

--srini

  reply	other threads:[~2013-09-27 13:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-27  9:33 [PATCH RFC] media: rc: OF: Add Generic bindings for remote-control Srinivas KANDAGATLA
     [not found] ` <1380274391-26577-1-git-send-email-srinivas.kandagatla-qxv4g6HH51o@public.gmane.org>
2013-09-27 11:34   ` Mark Rutland
2013-09-27 13:26     ` Srinivas KANDAGATLA [this message]
2013-09-27 13:57       ` Mauro Carvalho Chehab
2013-09-30  8:27         ` Srinivas KANDAGATLA
2013-10-01 14:49           ` Mauro Carvalho Chehab
2013-10-02 16:22             ` Srinivas KANDAGATLA
2013-10-02 17:33               ` Mauro Carvalho Chehab
2013-10-02 17:44                 ` Stephen Warren
2013-09-27 13:47     ` Mauro Carvalho Chehab
     [not found]       ` <20130927104719.6637368f-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2013-09-30 16:51         ` Mark Rutland
2013-10-09 12:17           ` srinivas kandagatla
2013-10-18 11:37             ` Mark Rutland
2013-10-18 12:23               ` srinivas kandagatla

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=52458774.1060909@st.com \
    --to=srinivas.kandagatla@st.com \
    --cc=Pawel.Moll@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    --cc=mark.rutland@arm.com \
    --cc=rob.herring@calxeda.com \
    --cc=rob@landley.net \
    --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;
as well as URLs for NNTP newsgroup(s).