linux-kernel - Re: [PATCH 4/5 v2] input: tc3589x-keypad: support probing from device tree

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]

Date:	Mon, 2 Dec 2013 12:08:45 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	Pavel Machek <pavel@....cz>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Lee Jones <lee.jones@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 4/5 v2] input: tc3589x-keypad: support probing from
 device tree

On Mon, Dec 02, 2013 at 11:54:42AM +0000, Pavel Machek wrote:
> On Mon 2013-12-02 11:37:20, Mark Rutland wrote:
> > On Sun, Nov 17, 2013 at 06:28:52PM +0000, Pavel Machek wrote:
> > > 
> > > > > Thus I guess we should not use the name, which has the most adopters
> > > > > in kernel (or out of kernel). Instead the most fitting name should
> > > > > be used. Current suggestions (taken from kernel) are:
> > > > > 
> > > > > * <<vendor>>,no-autorepeat
> > > > > * keypad,autorepeat
> > > > > * linux,keypad-no-autorepeat
> > > > > * linux,input-no-autorepeat
> > > > > * linux,no-autorepeat
> > > > > * autorepeat
> > > > > 
> > > > > I do not really care, which one is chosen, except for two things:
> > > > > 
> > > > > * <<vendor>> seems wrong. This is not vendor specific.
> > > > > * I would prefer "input-" over "keypad-", since then the same name
> > > > >   can be used for single keys, buttons, etc.
> > > > 
> > > > Both of those sound valid to me, but I think it may make sense to keep
> > > > the "linux," prefix. As I understand it this is really telling the Linux
> > > > input subsystem to react to a device acting in a certain way, rather
> > > > than describing or configuring the device in a certain way.
> > > 
> > > I'd say it is very much configuring device in certain way, and yes, other
> > > operating systems will want to do autorepeat, too.
> > 
> > Nothing is handled differently at the device with respect to this flag.
> > The Linux input subsystem behaves differently. Thus this is
> > configuration of the Linux input subsysytem, not the device.
> 
> This flag says "this is device where autorepeat makes sense". It does
> make sense for qwerty keyboard, it does not make sense for power
> button. There's nothing Linux specific here.

If you follow that argument, you don't need the property at all. We know
whether something is being handled as a keyboard or a power button, from
the rest of the data in the DT and how the driver is handling the
device. From that you can figure out if it's sensible to handle the
device as autorepeat or not.

> 
> > > I believe we don't want to end up with
> > > 
> > > linux,input-no-autorepeat
> > > bsd,keypad-autorepeat
> > > windows-phone,disable-autorepeat
> > 
> > I do not see a problem with this. This is only as bad as the current
> 
> Not a problem? DTS bloat? Code bloat for the drivers? (Because that
> way, we'll need to handle "windows-phone,disable-autorepeat" DTS for
> compatibility one day).

I would be extremely surprised if we ever discovered
"windows-phone,disable-autorepeat" in a DT ;)

I believe that namespacing the property is sensible for the moment, as
it currently is Linux specific. It also doesn't erroneously imply that
this is a hardware property. If another OS happen to pick it up, then
living with a "linux," prefix isn't that horrendous.

> 
> > situation, but has the benefit that the madness is constrained to
> > particular vendor prefixes, which we can uniquely identify and handle
> > differently if required.
> 
> Madness? We want to avoid madness and improve current situation where
> different driver use different attributes.

Then why not have a way of figuring this out automatically, and get rid
of the madness of having this in the DT at all? It's not a property of
the device, and it doesn't even make sense as a piece of static
configuration -- what if I prefer my keyboard to not autorepeat, but my
board vendor has decided autorepeat should be on?

Thanks,
Mark.
--
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/