On 3/27/2012 9:15 PM, Stephen Warren wrote:

quoted

quoted

 static int __devinit tegra_kbc_probe(struct platform_device *pdev)

...

quoted

quoted

+	if (pdev->dev.of_node) {
+		/* FIXME: Add handling of linux,fn-keymap here */
+		err = matrix_keypad_of_build_keymap(&pdev->dev, KBC_ROW_SHIFT,
+				input_dev->keycode, input_dev->keybit,
+				"linux,keymap");

Where do input_dev->keycode/keybit get allocated? As far as I can tell,
matrix_keypad_of_build_keymap() just writes to those and assumes they're
already allocated.

If i am not reading the code incorrectly, keycode is allocated memory with
kbc. And then we do this:

	input_dev->keycode = kbc->keycode;

keybit is again present as part of struct input_dev.
Am i missing something.

quoted

quoted

diff --git a/drivers/input/of_keymap.c b/drivers/input/of_keymap.c

...

quoted

quoted

+int matrix_keypad_of_build_keymap(struct device *dev, unsigned int row_shift,

...

quoted

quoted

+		keymap[MATRIX_SCAN_CODE(row, col, row_shift)] = code;
+		__set_bit(code, keybit);

How bit are keymap and keybit?

Couldn't get this one. :(
Can you please elaborate the question a bit?

I think we need range-checking here to
make sure that row/col/row_shift/code are valid and in-range.

I picked this directly from matrix_keypad_build_keymap() as is.
Anyway there is no loss in improving it. :)

What kind of range-check you are looking for?
Currently we do following

		unsigned int row = KEY_ROW(key);
		unsigned int col = KEY_COL(key);
		unsigned short code = KEY_VAL(key);

All these macros '&' 'key' with 0xFF, 0xFF and 0xFFFF.
Which is also kind of range checking.

-- 
viresh