[PATCH v1 01/12] input: matrix-keypad: update devicetree binding doc

[Gerhard Sittig]

On Fri, Jun 28, 2013 at 08:50 -0600, Stephen Warren wrote:
> 
> [ ... just one reference in arch/powerpc/boot/dts/ac14xx.dts ... ]
> > 
> > Don't worry about the 'AC14xx' board too long, its using the
> > keypad matrix driver is new in mainline, and still can get
> > adjusted without too much problems before more wide spread use.
> > "Getting it right" is what I'm currently heading for, while
> > nothing is set in stone yet.
> 
> Given the "ABI-ness" of DT, I'm not convinced we don't have to worry
> about the AC14xx. I think we'll have to continue supporting that
> property, even if there's a newer/better/more-flexible way of
> representing the information too.

Don't get me wrong, I wasn't putting this lightly.  From first
hand experience I can tell that none of those boards in the field
use current or even recent mainline kernels.  All of them are
running an older version which predates the introduction of
'AC14xx' support in kernel.org sources.  Extending official
support and "doing it the right way" is what I'm currently
working on, before those boards may switch to running mainline
kernels and compatibility with the first version that was used
will become an issue.  So to put it into other words:

_If_ the 'AC14xx' board is the _only_ entity which references the
property, then there's no problem at all.  Incompatible changes
for _this_one_board_ are acceptable since at the moment the
current implementation is not used in the field.

Of course I agree that breaking any other board isn't acceptable,
which is why I followed the approach of strictly keeping
backwards compatible behaviour even in those spots where a
different approach or a different default would have looked more
desireable.

Which is why I'm still reluctant to more intrusively change the
general working of the keypad matrix driver in contrast to
introducing strictly local changes which only optionally add
additional features which explicitly must get enabled before
changed behaviour will occur.  So I need some more time to think
of which parts to change in which ways and how to make sure that
nothings breaks ...


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de