On 05/08/2012 11:25 PM, Dmitry Torokhov wrote:

On Mon, Apr 30, 2012 at 10:00:42AM -0600, Stephen Warren wrote:

quoted

On 04/29/2012 10:19 PM, Dmitry Torokhov wrote:

quoted

On Thu, Apr 26, 2012 at 09:05:18AM -0600, Stephen Warren wrote:

quoted

On 04/26/2012 02:19 AM, Dmitry Torokhov wrote:

quoted

When platform keymap is not supplied to matrix_keypad_build_keymap()
and device tree support is enabled, try locating specified property
and load keymap from it. If property name is not defined, try using
"linux,keymap".

Based on earlier patch by Viresh Kumar [off-list ref]

I think this series looks mostly OK. A few comments below.

We don't actually have the KBC driver hooked up on any boards yet, so I
can't actually test this yet.

How will the linux,fn-keymap handling work? It looks like this code is
allocating a keymap data structure with one additional row to represent
fn-not-pressed vs. fn-pressed.

No, it loads 2x rows (therefore giving you twice original keymap size).

Yes, I mean an extra row signal, so therefore twice as many rows.

quoted

quoted

I assume this will work without issue
even though the second half is not filled in. Won't this allow the
linux,keymap property entries to pass validation "if (row >= rows)" for
one more row than it should?

Maybe... I think we should revisit this when you actually have
linux,fn-keymap. Probably will need to export matrix_keypad_parse_

Would it be better to just drop the support for the linux,fn-keymap
property, until the full support is there? That wouldn't lose any
functionality, but would avoid this potential error-checking issue.

Fair enough, how about the version below?

Yes, I think that will work.

I would expect that when linux,fn-keymap support gets added, perhaps the
"keymap_rows *= 2" would move into the DT keymap parsing code, since
only it will know whether its going to parse the second property. But I
don't think that influences the current patch.