Вызов hcd->driver->hub_control()

Хочу вызвать вот этот участок кода с нужными мне аргументами https://github.com/torvalds/linux/blob/07c4b9e9f71aa4bc74009f710fc5a745e10981bf/drivers/usb/core/hcd.c#L682
Как это проще всего сделать? Судя по коду для этого есть интерфейс USB Request Block, но я в ядерной разработке так себе, мне бы пример, а желательно вообще из юзерспейса через write() в блочный девайс или что-то в этом роде
vikaig
Как это проще всего сделать? Судя по коду для этого есть интерфейс USB Request Block
Думаешь у нас тусуются разработчики, имеющие отношение к URB? … думаю вряд ли, они обычно тусуются на других форумах. Но имеются отдельные любопытные, имеющие отношение к анализу дампов (usbdump, usbmon) блоков запроса USB, но их в большей степени интересует расшифровка этих запросов.
А потому интересно узнать, что тебя больше интересует разработка или обработка?
Если разработка, то маловероятно, что кто то что то посоветует конкретное. Начни с азов: USB Request BlockБлоки запроса USB
А если обработка, то в этом случае структура/формат URB запросов хорошо документировано, но это похоже тебе не нужно.
Ошибки не исчезают с опытом - они просто умнеют
vikaig, не дает мне покоя любопытство - если не секрет, что такое специфическое изобретаешь. Для стандартного вроде все имеется ... и вряд ли это связано с драйверами. USB/IP, что то связанное с пробросом, но здесь тоже имеется готовый инструмент, да и причем тут URB ... а потому и интересно - что же это такое будет.
Но, скорее всего, как всегда - думаешь о сложном, а окажется что то простое.
Ошибки не исчезают с опытом - они просто умнеют
vasek
vikaig
Как это проще всего сделать? Судя по коду для этого есть интерфейс USB Request Block
Думаешь у нас тусуются разработчики, имеющие отношение к URB? … думаю вряд ли, они обычно тусуются на других форумах. Но имеются отдельные любопытные, имеющие отношение к анализу дампов (usbdump, usbmon) блоков запроса USB, но их в большей степени интересует расшифровка этих запросов.
А потому интересно узнать, что тебя больше интересует разработка или обработка?
Если разработка, то маловероятно, что кто то что то посоветует конкретное. Начни с азов: USB Request BlockБлоки запроса USB
А если обработка, то в этом случае структура/формат URB запросов хорошо документировано, но это похоже тебе не нужно.
Вроде форум по линю и раздел по разработке, так что как ни странно именно это и ожидал...
Интересует меня только разовая отправка управляющей команды драйверу USB хост контроллера чтоб проверить ее результат, сама разработка как-такова меня не интересует, задача чисто разовая, нужно просто проверить пропадет ли питание на USB порте при отправке команды ClearPortFeature(USB_PORT_FEAT_POWER), именно эту управляющую команду я нашел в документации к ядру по управлению энергопотреблением USB устройств, через sysfs ее как я понял нельзя отправить
vikaig
нужно просто проверить пропадет ли питание на USB порте при отправке команды
В принципе выражение отключить питание шины/порта USB не верное, фактически такое не возможно в принципе - под этим обычно понимается отключить устройство от шины/порта USB (програмно), но питание на шину подается всегда - просто прекращается общение устройства с шиной и это устройство как бы не видимо, оно отсутствует в выоде lsusb.
После того как выполнено подключение устройства к шине/порту USB, в дальнейшем это устройство постоянно находится в режиме ожидания.
Одни устройства периодически отправляют сигналы (запросы) хосту, а тот отвечает, даже если ничего не происходит, например, мой USB 3G modem при бездействии с периодичностью в 30с шлет запрос на hub, а тот отвечает, привожу URB запросы
ffff9a4f76193840 2330901147 S Bo:2:003:1 -115 14 = 7ec02109 3e000887 7231df56 427e
ffff9a4f76193840 2330901235 C Bo:2:003:1 0 14 >
ffff9a4f74253c00 2330901627 C Bi:2:003:1 0 23 = 7eff7d23 c0217d2a 3e7d207d 287d207d 207d2543 27ba7e
ffff9a4f74253c00 2330901649 S Bi:2:003:1 -115 4096 <
А вот USB мышь ничего не отправляет в режиме бездействия, отправляет данные только при наличии событий/движений мыши
ffff9a4f749fd240 2042930506 C Ii:1:003:1 0:8 6 = 0100ff0f 0000
ffff9a4f749fd240 2042930594 S Ii:1:003:1 -115:8 6 <
ffff9a4f749fd240 2042938415 C Ii:1:003:1 0:8 6 = 0100ff1f 0000
ffff9a4f749fd240 2042938496 S Ii:1:003:1 -115:8 6 <
Но это все упрощенно, в действительности все намного сложнее.Инициатором обмена всегда выступает хост. Устройство не может начать передачу данных по собственной инициативе. Хост поочередно (с интервалом в несколько милисекунд) опрашивает все подключенные устройства. Каждый раз, при опросе, устройство может получить данные от хоста и отправить данные хосту.
Да и забыл отметить, что устройство в целях эконмии энергии переводится в другой режим энергопотребления, но способно быстро приступить к своим прямым обязанностям.

И если нужно смореть состояние USB устройства, то оно имеет, как бы это сказать, только 2 состояния
- подключено, прошло энумерацию, и видно в выводе lsusb
- не подключено, программно (физически воткнуто в порт), не видно в выоде lsusb.

PS - Многое забыл, писал по памяти, возможно что то и на путал/ошибся ...
Ошибки не исчезают с опытом - они просто умнеют
да я тоже так думал, но вот один человек утверждает, что пока он не заменил на ThinkPad свою древнюю убунту с древним ядом 2.6.34 на свежую версию, то у него в режиме сна не было питания на USB портах, а теперь на 5.4.0 присутствует, то есть таки есть какое-то управление
Вот подумай, чтобы отключить питание какого то устройства, нужно физически разорвать цепь питания ... вопрос - неужели в цепи питания порта USB имеется какое то устройство, скажем просто, стоит рэле устройство, которое при подаче определенного сигнала разрывает цепь? - нет такого устройства.
А вот энергосбережение, разные состояния, имеется. Точно не помню, забылось, но раньше было подругому - в файлах устройств USB (в /sys/.../) был параметр autosuspend и что то еще там (не помню), который мог принимать несколько значений, а потом это изменилось, точнее упростилось (если не ошибаюсь, то сейчас всего 2 значения on и auto ) - лень копаться в архивах ............. а вообще лучше в этой части почитать power-management

PS - а вообще если есть желание узнать наверняка, то рекомендую обратиться к спецификации USB - правда она на английском и более 1000 страниц, но есть русский перевод (не полный) части, касающейся электрической части - там все подробно расписано.
Ошибки не исчезают с опытом - они просто умнеют
Поднял старые записи
БЫЛО в части power/level
This file contains one of three words: "on", "auto",or "suspend".  You can write those words to the file to change the device's setting.
"on" means that the device should be resumed and autosuspend is not allowed.  (Of course, system suspends are still allowed.)
"auto" is the normal state in which the kernel is allowed to autosuspend and autoresume the device.
"suspend" means that the device should remain suspended, and autoresume is not allowed.  (But remote wakeup may still be allowed, since it is controlled separately by the power/wakeup attribute.)

СТАЛО в части power/level
This file contains one of two words: "on" or "auto". You can write those words to the file to change the device's setting.
 "on" means that the device should be resumed and autosuspend is not allowed.  (Of course, system suspends are still allowed.)
 "auto" is the normal state in which the kernel is allowed to autosuspend and autoresume the device.
(In kernels up to 2.6.32, you could also specify "suspend", meaning that the device should remain suspended and autoresume was not allowed. This setting is no longer supported.)

Обрати внимание - раньше был параметр "suspend" - который означал, что устройство должно оставаться приостановленным, а автоматическое возобновление запрещено. Этот параметр больше не поддерживается

EDIT 1 - по дефолту стоит auto, например для устройств на usb3 (usb mouse)
cat /sys/bus/usb/devices/usb3/power/level
auto
Ошибки не исчезают с опытом - они просто умнеют
Ну и если по существу вопроса (решил освежить в памяти эти запросы)
status = hcd->driver->hub_control (hcd,
            typeReq, wValue, wIndex,
            t0x0002buf, wLength);

применительно к запросу Get Status поля запроса будут следующие
- bmRequestType (битовая маска) = 10000001
- bRequest = 0x00
- wValue = 0x0000
- wIndex = 0x0000
- wLength = 0x0002
В ответ хост должен вернуть 2 байта в следующем формате:
бит 0 - Self Powered (режим питания устройства: 0 - питание от шины, 1 - от внешнего источника)
бит 1 - Remote Wakeup (реакция на сигнал пробуждения: 0 - устройство игнорирует сигнал пробуждения, 1-  устройство реагирует на этот сигнал)
бит 2 -15 - зарезервировано (не используются и должны содержать нули)
... и в итоге, получив это ответ, не возможно, точнее нет такого понятия есть питание или нет питания, что еще раз доказывает, что если устройство подключено и прошло энумерацию, то оно постоянно находится в дежурном режиме и в любой момент готово принять запрос от хоста или передать ему. А вот в случае отсутствия питания, не возможно ни отправить запрос, ни получить ответ.
Ошибки не исчезают с опытом - они просто умнеют
Потратил всего пол часа времени и вышло это:
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/usb.h>
#include <linux/usb/hcd.h>

static int __init mod_init(void) {
    printk("mod_init();\n");

    mutex_lock(&usb_bus_idr_lock);

    struct usb_bus *bus;
    int id;
    idr_for_each_entry(&usb_bus_idr, bus, id) {
        struct usb_device *hub_dev = bus->root_hub;

        printk("USB Bus: %d\n", bus->busnum);
        printk("Vendor Id: %x, Product Id: %x\n",
            hub_dev->descriptor.idVendor, hub_dev->descriptor.idProduct);

        usb_lock_device(hub_dev);

        int port;
        struct usb_device *dev;
        usb_hub_for_each_child(hub_dev, port, dev) {
            printk("Child Vendor Id: %x, Product Id: %x\n",
                dev->descriptor.idVendor, dev->descriptor.idProduct);

            int ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
                USB_REQ_CLEAR_FEATURE, USB_RT_PORT, USB_PORT_FEAT_POWER, port,
                NULL, 0, 1000
            );

            if (ret < 0) {
                printk("ret < 0: %d", ret);
            }
        }

        usb_unlock_device(hub_dev);
    }

    mutex_unlock(&usb_bus_idr_lock);
    return 0;
}

static void __exit mod_exit(void) {
    printk("mod_exit();\n");
}

module_init(mod_init);
module_exit(mod_exit);

MODULE_LICENSE("GPL");
Только вот у меня usb_control_msg() возвращает -EPIPE:
[108766.034483] mod_init();
[108766.034485] USB Bus: 1
[108766.034486] Vendor Id: 1234, Product Id: 2
[108766.034487] Child Vendor Id: 4123, Product Id: 2345
[108766.036371] ret < 0: -32
[108766.036375] Child Vendor Id: 3534, Product Id: 56
[108767.059848] ret < 0: -110
[108767.059853] USB Bus: 2
[108767.059857] Vendor Id: 1654, Product Id: 5
В документации написано "The pipe type specified in the URB doesn’t match the endpoint’s actual type.", есть у кого идеи как исправить?
 
Зарегистрироваться или войдите чтобы оставить сообщение.