Comments 19
Спасибо за подробную статью!
Вопрос: есть ли ограничения на объем памяти для DMA, на количество дескрипторов? Каким параметром этот объем настраивается в существующх драйверах?
В реализации EMAC для sun4i в Linux 5.x есть баг - состояние deadlock при таймауте. Позже приложу свой патч.
Обещанный патч:
commit a98d9f107405dc5a20d1bd289a10612125007068 (emac-timeout)
Author: Ruslan Zalata <rz@fabmicro.ru>
Date: Wed Jun 22 19:17:38 2022 +0000
sun4i-emac: Fix spin_lock deadlock issue in emac_timeout
diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c b/drivers/net/ethernet/allwinner/sun4i-emac.c
index 621ce742ad2..ba6e6d37cd8 100644
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -521,6 +521,8 @@ static void emac_timeout(struct net_device *dev, unsigned int txqueue)
if (netif_msg_timer(db))
dev_err(db->dev, "tx time out.\n");
+#if(0) /* Below code has spin_lock deadlock in emac_init_device() !!! */
+
/* Save previous register address */
spin_lock_irqsave(&db->lock, flags);
@@ -533,6 +535,12 @@ static void emac_timeout(struct net_device *dev, unsigned int txqueue)
/* Restore previous register address */
spin_unlock_irqrestore(&db->lock, flags);
+#endif
+ spin_lock_irq(&db->lock);
+ emac_reset(db);
+ spin_unlock_irq(&db->lock);
+ emac_init_device(dev);
+ netif_wake_queue(dev);
}
/* Hardware start transmission.
не планируете в mainline отправить?
Данный патч это быстрый хак и проверка, такое в mainline не примут. Проблему нужно решать где-то в другом месте, но мне честно гворя не хватает для этого квалификации.
Вообще я несколько раз предпринимал попытки отправлять свои патчи в mainline - опыт исключительно негативный. Товарищ Maxime Ripard не пропускает, заваливает совершенно дурацкими требованиями. Типа устаревшего API - "hwmon уже не айс, переписывайте под IIO". Если ему нужно пусть и переписывает, а у меня работы полно другой, да и весь софт у нас написан с использованием hwmon.
Да, есть такое. Сам сделал regmap для OneWire уже несколько лет назад. До сих пор мой же драйвер единственный, кто его использует. При чём не только меня, но и мантейнера OneWire не хватило не то, чтобы убедить мантейнера подсистемы Power в откровенной глупости данного требования. Впрочем, если отвечать четко на ваше замечание, то IIO действительно выглядит более логично, чем сборная солянка которой сегодня является HWMON. Впрочем, это Open Source. В списках рассылки осталось и то хорошо. Никто не может вас заставить сделать что-то, а с сообществом вы и так поделились.
По поводу sunxi - что-то мне подсказывает что emac_reset и netif_wake_queue конкурируют за один ресурс и разбираться надо с ними. Возможно блокировать очередь на время сброса или ещё как-то. Увы, у меня нет железа, да и отпуск... Впрочем... Ничего в нашем мире исключать нельзя.
К IIO у меня есть серъезная претензия - все драйвера в IIO работают методом poll-а в момент обращения к драйверу и не пригодны для захвата данных (т.е. для настоящего Industrial I/O) по определению - при захвате большого блока данных имеем страшный оверхед и нерегулярность сэмплирования. Для того, что бы IIO имел право называться "Industrial I/O" необходимо реализовать API аналогичный ALSA с кольцевыми буферами и DMA. Патч с такой трансформацией IIO предлагали сотрудники Analog Device несколько лет назад, но его не неприняли. Таким образом IIO сейчас такое же унылое говно как и HWMON, но более сложное в использовании. Я посмотрел на это дело и не понял зачем мне IIO если HWMON справляется с поставленой задачей с меньшими усилиями.
Спасибо, интересно.
Только не ясно зачем совершенно все собирать руками?
Можно взять buildroot и собрать систему с его помощью, именно такую какую захочется.
Конфиг для Orange PI Zero в нем уже есть.
И можно просто сфокусироваться на разработке драйвера в ядре скипнув кучу черновой работы с риском наделать ошибок в процессе.
хорошая статья, спасибо. Про net_device_ops и phydev будет во второй части, я так понимаю? Там где про первую загрузку, хорошо бы добавить пример вывода в консоль. Без этого бывает трудно понять, где была допущена ошибка.
Для сборки драйвера достаточно ввести команду make
Вообще, лично на мой вкус, проще собирать in-tree. Но, в любом случае надо Makefile написать как минимум следующего содержания:
obj-m += net.o
А можно тестовой программой на определенный mac адрес пакет отправить?
Очень!
А raspberry pi zero подойдёт?
Самого главного не понял: есть какой-то отдельный класс сетевого драйвера со стандартизированным интерфейсом и есть шаблон его написания? Или это какой-то вариант символьного драйвера? Или что-то ещё?
Разработка драйвера сетевого адаптера для Linux. Часть 1