linux-kernel - Re: [PATCH RFC] media: rc: OF: Add Generic bindings for remote-control

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <20130927105716.64349f02@samsung.com>
Date:	Fri, 27 Sep 2013 10:57:16 -0300
From:	Mauro Carvalho Chehab <m.chehab@...sung.com>
To:	srinivas.kandagatla@...com
Cc:	Mark Rutland <mark.rutland@....com>,
	"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	Pawel Moll <Pawel.Moll@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Rob Landley <rob@...dley.net>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC] media: rc: OF: Add Generic bindings for remote-control

Em Fri, 27 Sep 2013 14:26:12 +0100
Srinivas KANDAGATLA <srinivas.kandagatla@...com> escreveu:

> 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.

Well, for sure the direction (TX, RX, both) is a generic property.

I'd say that the level 1 protocol (IR, UHF, Bluetooth, ...) is also a
generic property. Most remotes are IR, but there are some that are
bluetooth, and your hardware is using UHF.

Btw, we're even thinking on mapping HDMI-CEC remote controller RX/TX via
the RC subsystem. So, another L1 protocol would be "hdmi-cec".

Yet, it seems unlikely that the very same remote controller IP would use
a different protocol for RX and TX, while sharing the same registers.

So, for example, a hardware with "hdmi-cec" and "infrared" will actually
have two remote controller devices. Eventually, the "infrared" being
just RX, while "hdmi-cec" being bi-directional.

So, IMHO, this could be mapped as "l1_protocol" ("infrared", "uhf", ...)
and another one "direction" ("rx", "tx", "bi-directional").

> 
> > 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


-- 

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/