LINUX.ORG.RU

usb_control_msg() выдает EPIPE

 ,


0

2

Когда я писал эмуляцию PL2303 на STM32, как-то не напрягался, что при открывании порта в dmesg вылезает ошибка: pl2303_set_line_request - failed: -32. Оно даже работало в прошивке-7 под виртуалбоксом. Однако, оказалось, что оно не работает (видимо, из-за этой ошибки) в прошивке-10 и в андроиде.

Ошибка возникает на запрос SET_LINE_CODING, который приходится обрабатывать «в два присеста», т.к. STM32 на первое прерывание получает лишь код контрольного сообщения, а во втором прерывании уже выдает данные для настройки линии. В этом-то и загвоздка: ошибка у меня в коде может быть как в первой половинке, где я просто отправляю ZLP, так и во второй, где уже вызывается обработчик.

Удручает, что wireshark вообще никаких ошибок не показывает! Лог от «настоящего» китайского PL2303 ничем не отличается от моей эмуляции. Т.е. что-то происходит еще в ядре, и до wireshark не доходит.

Что это может быть, а, железячники?

Ну и в догонку такой вопрос: иной раз дескрипторы получаются очень большими, и приходится их в несколько присестов отправлять. Я пробовал собрать CDC, пересылая конфигурационный дескриптор так же, как пересылаю HID дескриптор, но в wireshark вижу «mailformed»...

☆☆☆☆☆

Сам себе и отвечаю. Вменяемых инструкций по этому поводу я не нашел, поэтому действовал «методом Монте-Карло». В итоге вот что обнаружилось: в обработчике второго прерывания нужно выкинуть CLEAR_DTOG и заменить SET_STALL_TX на SET_VALID_TX. Тогда работает без ошибок в логах ядра. Игровых приставок под рукой нет, но есть устройства на ондроеде. Там все работает. Сейчас все куски подправлю и сделаю коммиты.

Но второй вопрос остается: как правильно отсылать длинные дескрипторы.

Eddy_Em ☆☆☆☆☆ ()