NIIBE Yutaka wrote:
> Could you please take a deep breath, Alan?
It is me who need a deep breath. :-> Sorry, Alan.
My analysis was wrong, because I confused between requesttype and
request. Thanks David who pointed out in private mail.
Here again.
In drivers/usb/core/hub.c, there are functions clear_port_feature and
set_port_feature:
/*
* USB 2.0 spec Section 11.24.2.2
*/
static int clear_port_feature(struct usb_device *hdev, int port1, int
feature)
{
return usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
USB_REQ_CLEAR_FEATURE, USB_RT_PORT, feature, port1,
NULL, 0, 1000);
}
[...]
/*
* USB 2.0 spec Section 11.24.2.13
*/
static int set_port_feature(struct usb_device *hdev, int port1, int
feature)
{
return usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
USB_REQ_SET_FEATURE, USB_RT_PORT, feature, port1,
NULL, 0, 1000);
}
What I want is do something like these from user space with
USB_PORT_FEAT_POWER. That is, the control message with:
bRequest: USB_REQ_SET_FEATURE
bRequestType: USB_RT_PORT
wValue: USB_PORT_FEAT_POWER
wIndex: <PORT>
In drivers/usb/core/hub.h, there is definition of USB_RT_PORT:
#define USB_RT_PORT (USB_TYPE_CLASS | USB_RECIP_OTHER)
It's OTHER. So, it must be possible to do that from user space.
I found that my experiment a mistake with libusb.
For usb_control_msg of libusb, the order of requesttype and request is
differentwith kernel's one. I called with requesttype=USB_REQ_SET_FEATURE,
that was reason of my confusion.
I will be back with user space implementation.
--
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
