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: <20131002143340.18639f1a@samsung.com>
Date:	Wed, 02 Oct 2013 14:33:40 -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 Wed, 02 Oct 2013 17:22:06 +0100
Srinivas KANDAGATLA <srinivas.kandagatla@...com> escreveu:

> On 01/10/13 15:49, Mauro Carvalho Chehab wrote:
> >>> > > 
> >>> > > 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".
> >>> > > 
> >> > Ok.
> >>> > > 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.
> >> > 
> >> > ST IRB block has one IR processor which has both TX and RX support and
> >> > one UHF Processor which has RX support only. However the register map
> >> > for all these support is in single IRB IP block.
> >> > 
> >> > So the driver can configure the IP as TX in "infrared" and RX in "uhf".
> >> > This is supported in ST IRB IP.
> >> > 
> >> > This case can not be represented in a single device tree node with
> >> > l1-protocol and direction properties.
> >> > 
> >> > IMHO, having tx-mode and rx-mode or tx-protocol and rx-protocol
> >> > properties will give more flexibility.
> >> > 
> >> > What do you think?
> > Yeah, if they're using the same registers, then your proposal works
> > better.
> > 
> > I would prefer to not call it as just protocol, as IR has an
> > upper layer protocol that defines how the bits are encoded, e. g.
> > RC5, RC6, NEC, SONY, ..., with is what we generally call as protocol
> > on rc-core. 
> > 
> > A proper naming for it is hard to find. Well, for IR/UHF, it is actually
> 
> Yes I agree.
> 
> > specifying the medium, but for Bluetooth, HDMI-CEC, it defines a
> > protocol stack to be used, with covers not only the physical layer of
> > the OSI model.
> > 
> > Perhaps the better would be to call it as: tx-proto-stack/rx-proto-stack.
> > 
> How are we going to address use case highlighted by Mark R, like N
> Connections on a single IP block?
> 
> This use-case can not be addressed with tx-mode and rx-mode or
> tx-proto-stack/rx-proto-stack properties.
> 
> So the idea of generic properties for tx and rx sounds incorrect.
> 
> IMHO, Best thing would be to drop the idea of using tx-mode and rx-mode
> as generic properties and use "st,tx-mode" and "st,rx-mode" instead for
> st-rc driver.
> 
> What do you think?

Well, from userspace PoV, it should have just one devnode for each
TX/RX.

So, if the device has N TX and/or RX simultaneous connections, it should
be exposing N device nodes, and the DT should for it should have N entries,
one for each.

A completely independent issue is how the driver will prevent to have
two simultaneous access to the same resource.

As on any other type of resource, there are several alternatives:

	- block the reads/writes, if some I/O operation is pending;
	- return -EAGAIN where the API allows (non-block calls),
	  and the error is temporary;
	- return -EBUSY if the resource is more "permanently" allocated.

So, if the very same registers are used by more than one TX/RX unit,
then the driver should for example have a mutex/semaphore to lock such
I/O while another I/O operation is undergoing.

That solution is the same used by I2C devices: the I2C bus has a lock,
serializing the access to all devices on that bus.

There is another possible scenario: a device that have more than one
connection, and that userspace could setup what connection is active,
putting all the other ones inactive.

On such scenario, we would need to add more bits at RC API, in order
to allow userspace to enumerate the possible RX/TX connections,
and to change it at runtime.

If we had such scenario, then the DT representation for it could be
different. So, instead of having a single TX/RX mode/protocol-stack,
we would have a connections table. Also, each entry would likely need
a name, in order to allow userspace to distinguish between the diferent
entries that are wired on a given board.

Anyway, we don't have such scenario yet. So, let's not overdesign the
API, thinking on a possible scenario that may never happen.

> 
> Thanks,
> srini
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 

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/