xHCI vs legacy usb host controllers (OHCI, UHCI, and EHCI)
Hi, Is it necessary to use xHCI driver for USB 3.0 host controller? I am trying to support Transdent PNU3 (having usb 3.0 controller) in my h/w running 2.6.16 kernel. Is it not possible to use other legacy host controllers (ohci/uhci/ehci) already available in 2.6.16 kernel ? Will usb 3.0 not fallback to usb 2.0 with legacy drivers ? I do not want to put my effort back-porting xhci to old kernel until it is absolutely necessary. thanks... -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: default/target product id /vendor id for usb devices
I have a new usb dongle Huawei E3531 trying to support in my h/w having old kernel version 2.6.16. I use usb_modeswitch to change the mode from usb storage to modem manually. As I do not have udev rule support in my h/w, I need an alternative way of mode switching during plugin time automatically. For that I have added the default device and vendor id in unusual_devs.h with UNUSUAL_DEV() macro to ignore the storage driver in the first place and added the target device and vendor id in the option.c to get the option driver loaded on related interface. Below is the default and target entries mention in the usb_modeswitch help. /root # usb_modeswitch -h Usage: usb_modeswitch [params] [-c filename] -v, --default-vendor NUM vendor ID of original mode (mandatory) -p, --default-product NUM product ID of original mode (mandatory) -V, --target-vendor NUM target mode vendor ID (optional) -P, --target-product NUM target mode product ID (optional) -C, --target-class NUMtarget mode device class (optional) On Wed, Feb 18, 2015 at 1:09 PM, Clemens Ladisch clem...@ladisch.de wrote: temp sha wrote: Can any one brief me about the concept of default/target product id /vendor id ? These are not terms that have a well-known meaning. Where did you hear them? And what is the actual problem you're trying to solve? Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: default/target product id /vendor id for usb devices
Look closely in the kernel output and you'll see that no ids change, but that the old device has disconnected and a new device has connected. sorry I could not get it completely. what is this new device/ old device ? there is only one device USB dongle. changing usb mode can change the product id as well ? does it mean product id is related with usb's mode of operation rather than actual physical h/w. if yes then what about default and target vendor ids seen in the usb_modeswitch help cmd? does this also depend on mode of operation sometimes ? thanks On Wed, Feb 18, 2015 at 5:53 PM, Peter Stuge pe...@stuge.se wrote: temp sha wrote: Yes running usb_modeswitch manually works, but once mode switch is done product id is getting changed from 0x1446 to 0x1506. Look closely in the kernel output and you'll see that no ids change, but that the old device has disconnected and a new device has connected. looking into the help I found 0x1446 is default product id wheres 0x1506 is the target product id. but could not get the idea behind this concept. The USB modem normally appears as a storage device with the Windows software, so that Windows users can easily install it. The driver needs to tell the modem to switch from appearing as a storage device to appearing as an actual modem. usb_modeswitch does that. Yes I do have hotplug but I am trying alternative ways also. eg as I said skipping usb-storage loading initially by adding the product id in the unusual_devs.h and giving opportunity to probe option driver first. That does not work. The modem needs to be instructed by software to switch modes. as there are two product ids for usb devices I am bit confused which once need to be used in unusual_devs.h and the driver option. Now you know that what usb_modeswitch calls target device is the actual modem. That's the only device that matters for the modem driver. One could of course argue that the kernel should do modeswitching. But sometimes it's preferable to have access to the storage device. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: default/target product id /vendor id for usb devices
Thanks Peter and Clemens for your detailed explanations now I got it. On Wed, Feb 18, 2015 at 6:48 PM, Peter Stuge pe...@stuge.se wrote: temp sha wrote: Look closely in the kernel output and you'll see that no ids change, but that the old device has disconnected and a new device has connected. sorry I could not get it completely. what is this new device/ old device ? A USB device as seen by the kernel is a software concept according to the USB specification and is really unrelated to physical objects. Many physical objects which connect via USB only ever appear in one way, the same way every time, but many also change how they appear, depending on a number of different factors, including being told by software such as a Windows driver or usb_modeswitch to change their appearance and behavior. USB is not a serial port with power. It is a highly structured bus, much more similar to a network. there is only one device USB dongle. changing usb mode can change the product id as well ? does it mean product id is related with usb's mode of operation rather than actual physical h/w. Sure. The physical object is irrelevant to software. What matters is how the object appears and behaves via USB. This is the definition of a USB product. Most of the time it is actually adhered to by vendors. if yes then what about default and target vendor ids seen in the usb_modeswitch help cmd? does this also depend on mode of operation sometimes ? I tried to explain that in the previous email: looking into the help I found 0x1446 is default product id wheres 0x1506 is the target product id. but could not get the idea behind this concept. The USB modem normally appears as a storage device with the Windows software, so that Windows users can easily install it. By this I mean that the storage device is a virtual CD with a Windows driver stored on it. The driver needs to tell the modem to switch from appearing as a storage device to appearing as an actual modem. usb_modeswitch does that. A USB device can not change descriptors (with vid+pid) and behavior on the fly, so the device then disconnects from the host, changes its behavior and reconnects with different descriptors and different behavior. Only then can the kernel modem driver use the modem. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: default/target product id /vendor id for usb devices
Yes running usb_modeswitch manually works, but once mode switch is done product id is getting changed from 0x1446 to 0x1506. looking into the help I found 0x1446 is default product id wheres 0x1506 is the target product id. but could not get the idea behind this concept. Yes I do have hotplug but I am trying alternative ways also. eg as I said skipping usb-storage loading initially by adding the product id in the unusual_devs.h and giving opportunity to probe option driver first. as there are two product ids for usb devices I am bit confused which once need to be used in unusual_devs.h and the driver option. thanks. On Wed, Feb 18, 2015 at 5:07 PM, Clemens Ladisch clem...@ladisch.de wrote: temp sha wrote: I have a new usb dongle Huawei E3531 trying to support in my h/w having old kernel version 2.6.16. I use usb_modeswitch to change the mode from usb storage to modem manually. As I do not have udev rule support in my h/w, I need an alternative way of mode switching during plugin time automatically. Does it work if you run usb_modeswitch manually? If you don't have udev, what _do_ you have? hotplug? Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
default/target product id /vendor id for usb devices
Hi, Can any one brief me about the concept of default/target product id /vendor id ? Or any link explaining the same. Thanks -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
need an additional option to access first check-in of a file
Hi All, Not sure where I should post this as this is a Git infra related suggestion. I think we should have an additional option first/oldest along with Newer/Older in Git. This will be helpful in browsing the first check-in of a file. Thanks.
unable to execute hotplug script
Hi All, I am trying to enable hotplugging for usb on my h/w based on 2.6.16 kernel. The hotplug kernel module is enabled and I have registered a user script test.sh with the proc file system. /root # echo /bin/test.sh /proc/sys/kernel/hotplug --- /root # cat /proc/sys/kernel/hotplug /bin/test.sh --- /root # cat /bin/test.sh #!/bin/sh echo my hotplug script --- I observed that even on plug-in and plug-out my usb device, the hotplug script test.sh is not getting executed though I see that kobject_uevent() of kobject_uevent.c is getting called with proper uevent_helper and subsystem values. Those are /bin/test.sh and usb respectively in this case. Is there any thing I am missing here ? (udev is not supported in my device.) Thanks in advance. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unable to execute hotplug script
i was sure that script did not run because I verified the same with touch command. #!/bin/sh echo my hotplug script touch test file test did not get created. Thanks. On Wed, Feb 11, 2015 at 9:59 PM, Bin Liu binml...@gmail.com wrote: Hi, On Wed, Feb 11, 2015 at 10:07 AM, temp sha temp@gmail.com wrote: Hi All, I am trying to enable hotplugging for usb on my h/w based on 2.6.16 kernel. I am not sure if you still can get support for such old version. The hotplug kernel module is enabled and I have registered a user script test.sh with the proc file system. /root # echo /bin/test.sh /proc/sys/kernel/hotplug --- /root # cat /proc/sys/kernel/hotplug /bin/test.sh --- /root # cat /bin/test.sh #!/bin/sh echo my hotplug script but I am sure this is not the right way to debug a bash script. See below. --- I observed that even on plug-in and plug-out my usb device, the hotplug script test.sh is not getting executed though I see that kobject_uevent() of How do you know the script is not executed? because you did not see 'my hot plug script' printout? I don't know much about /proc/.../hotplug, but I believe it executes script callbacks without stdin/out, so there should have no console to display the echo messages. I guess you could direct the echo messages to a file in your script to debug it, for example echo my hot plug script /tmp/hotplug-debug.log Regards, -Bin. kobject_uevent.c is getting called with proper uevent_helper and subsystem values. Those are /bin/test.sh and usb respectively in this case. Is there any thing I am missing here ? (udev is not supported in my device.) Thanks in advance. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: difference in option.ko and sierra.ko Linux drivers
You mean to say only Sierra has its own proprietary commands and no one else ? What is so special about Sierra that requires a dedicated driver in Linux while rest of all vendors share the same option driver ? Does Sierra do something unique and different from rest of all vendors? Thanks On Fri, Jan 30, 2015 at 12:19 AM, Dan Williams d...@redhat.com wrote: On Thu, 2015-01-29 at 06:23 -0800, Greg KH wrote: On Thu, Jan 29, 2015 at 02:50:13PM +0530, temp sha wrote: Can any one let me know the difference in option and sierra kernel modules ? looks like both drivers support GSM modem. And from the source code perspective both look similar. I am able to load sierra module for my Huawei USB dongle E156 and able to connect to internet using pppd. Is it OK to use sierra driver for Huawei in case there is no technical issue? If yes why there are two different modules? They support two different chipsets and control them differently. If the sierra module works for your hardware, great! Please send us a patch that adds the device id to the driver and we will be glad to merge it into the kernel tree. I'd really, really rather not have non-Sierra devices controlled by 'sierra'. There are some Sierra-specific things the driver does, like interface enumeration, enabling/disabling power state and NMEA ports using Sierra-proprietary commands, and a few other things. Since PPP-using Huawei devices are usually done by 'option', I'd prefer to have them added there, and if there is some issue, then I'd prefer to have that issue fixed in option. Dan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
difference in option.ko and sierra.ko Linux drivers
Can any one let me know the difference in option and sierra kernel modules ? looks like both drivers support GSM modem. And from the source code perspective both look similar. I am able to load sierra module for my Huawei USB dongle E156 and able to connect to internet using pppd. Is it OK to use sierra driver for Huawei in case there is no technical issue? If yes why there are two different modules? Thanks -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
