Message-ID: <20131202130330.GA6203@amd.pavel.ucw.cz>
Date:	Mon, 2 Dec 2013 14:03:30 +0100
From:	Pavel Machek <pavel@....cz>
To:	Mark Rutland <mark.rutland@....com>
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

Hi!

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

gpio-button can be used for both power button and arrows... So yes,
driver could do the decision, but you 

Yes, dt "autorepeat" attribute is there to set up the defaults, so
that the device does not have to look at the list of keycodes.

(And it is still not linux specific).

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

If you pretend that other operating systems do not exist, why bother
with "linux," prefix at all...

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

I think that would be pretty bad. Also we would be expected to handle
"bsd,keyboard-autorepeat" and
"windows-phone,please-do-not-autorepeat".

And there's nothing really wrong with current "autorepeat" solution we
are using, is it?

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

We already have few drivers that use DT to do this, using different
variants of "[linux,][no]autorepeat". Yes, we could move the
complexity from DT to drivers, but that does not seem like a win.

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

Input already has controls you can use.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/

Powered by blists - more mailing lists