обновление драйвера mtd со старым ядром

Есть ли способ обойти эту проблему, потому что я не хочу менять ядро, но хочу обновить код драйвера mtd как можно лучше с самой версией 2.6.10?

Как правило, все коммиты в Linux пытаются быть атомарными частями, которые реализуют часть функциональности. Любой, кто немного программировал, знает, что некоторые изменения очень изолированы, а другие являются системными. Т.е. у вас есть конкретные функциональные изменения и инфраструктурные изменения. Если вы хотите получить все изменения 3.11.1, вам необходимо получить 3.11.1. Вам нужно решить, какие изменения инфраструктуры вы не хотите.

На infradead.org есть несколько бэкпортов UbiFs, например Бэкпорт UbiFs 2.6.32 содержит исправления для уровня MTD примерно до Linux 3.0. Принятие этих изменений и применение их к вашему дереву должно быть менее проблемой. Linux 2.6.34 и 2.6.32 имеют лучшие обратные порты; если бы вы могли перейти на эту версию, вам нужно было бы сделать меньше. Достаточно просто перенести все изменения, относящиеся к драйверу или набору микросхем. Иногда происходят изменения в инфраструктуре, которые делают обратный порт сложным или невозможным. Например, функцию нельзя вызывать из контекста прерывания в старом ядре, но можно в более новой версии. Ознакомьтесь с некоторыми из репозиториев git на сайте infradead. Возможно, вам подойдет один из них.

Как правило, я просматриваю изменения и выбираю обратный порт только для тех, которые мне нужны. Вы можете получить исправления для одного файла с помощью git format-patch verA..verB file, а затем применить их с помощью git am. Довольно просто применить 10-20, а затем выполнить сборку/регрессионный тест. Поскольку вам приходится выбрасывать патчи, все сложнее и сложнее будет объединять более поздние патчи.

Также я хотел знать, где найти журналы изменений для кода mtd с 2.6.10 на 3.11.1 (я не смог найти его, и история изменений в этих файлах не обновляется для изменений)

Просто перейдите в каталог и используйте git log --follow .; вам нужны параметры --follow для случаев, когда файлы были перемещены; по крайней мере, я думаю, что это сработает. Если нет, вы можете использовать git, чтобы проверить версию непосредственно перед перемещением с *SHA_ID~1* и использовать отсоединенный заголовок, чтобы получить историю перед перемещением.