Использование legacy-драйверов на FDT-платформе

Я, конечно, понимаю, что рассово-правильно - переписать драйвер

Ученик Поттеринга ? зачем переписывать, у этого драйвера есть биндинг для gpiolib

http://lxr.free-electrons.com/source/drivers/input/keyboard/adp5589-keys.c#L388

есть универсальный драйвер gpio-matrix-keypad c биндингами device tree

http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/...

Не, поттеренгизмом не страдаю, но количество Поттеренгов в мейнстриме вынуждает адаптироваться - под нужный мне SoC в новых ядрах доки и примеры исключительно FDT-ориентированные. Хотя желание вернуться к классическому описанию всё растёт.

По поводу биндигов 1) Может я сильно заблуждаюсь, но там сначала надо экспортировать в gpiolib пины, для чего передать драйверу platform_data, для чего инициализировать драйвер и железку, для чего получить доступ к шине I2C... Или есть вариант из device tree секции gpiolib сделать эту инициализацию? 2) Я правильно понял, что Вы предлагаете перенести логику обработки матрицы из специализированной микросхемы в ядро? У меня не так много свободных ресурсов...

Спасибо

Не совсем, у тебя gpiolib будет выступать в качестве обёртки над микрухой и суть форвардить с/на неё всё что валится в обе стороны. Да, появляется некоторый оверхэд на gpiolib, но он не настолько уж и большой.

UPD: не совсем точно выразился. В FDT ты пишешь то, что у тебя есть gpio клавиатура которая обрабатывается драйвером gpio-matrix-keys, после чего указываешь, что у тебя ещё есть gpio-expander которым притворяется твоя микруха, которая висит на i2c шине и экспортит gpiochip. Обобщили интерфейс таксказать. platform data ты будешь указывать в gpio-matrix-keys объявлении.

Примерно где-то так. На мой взгляд, с FDT стало значительно проще, ибо котлеты отдельно, мухи отдельно.

Посмотрел в исходники matrix-keymap - он не делает поллинг, а работает по прерываниям, так что действительно должно быть более менее прилично. Впрочем, на мои вопросы это не отвечает - решение для частного случая, хотелось бы понять, есть ли более общие методы.

Я правильно понял, что для подвешивания чипа на I2C мне надо написать что-то вроде

	i2c@0 {
		adp8859: gpio-controller@34 {
			compatible = «ad,adp8859-keys»;
			reg = <0x34>;
			gpio-controller;
			gpio-ranges = xxx
		};
	};

и драйвер сам проинициализируется а потом его можно будет использовать для экспорта GPIO, даже несмотря на то, что он не имеет биндингов? Завтра попробую, но что-то сомневаюсь и не понимаю, как оно должно работать с учётом того, что adp8859-keys для инициализации нужна специфическая platform-data.

По поводу биндигов

В общем зря я тут поттерингом назвал - драйверы тухлые и так просто там не сделать.

как вариант - засунуть в late_initcall (или другой initcall) - буквально в любом месте в си-файле пишешь late_initcall(имя_функции) - функция добавляется в таблицу функций (линкером), потом на одной из стадий вызывается (после драйверо, фс, инита итд, там около 9 уровней). ну тут какое дело - или ты юзаешь апстрим и переписываешь драйвера, или тратишь время на эмуляцию того, что апстрим выкинул

как вариант - засунуть в late_initcall

О, вот за эту наводку большое спасибо!
late_initcall вызывается сразу после machine_desc.init_late, то есть всё ещё раньше, чем обработается DeviceTree, а вот late_initcall_sync помог - так работает.