Hello @all.
Some PC have two ore more USB-Controllers. Per one USB-Controller you have a range of 1 to 127 addresses.
This means: If you have two contollers you have a rage of 2 * 1 to 127 = 254 functions and with 10 controllers 10 * 1 to 127 = 1270 functions. It’s true?
How does the WDF handle the devices if you have several controllers? Can you although add only 127 Devices or more?
xxxxx@siemens.com wrote:
Hello @all.
Some PC have two ore more USB-Controllers. Per one USB-Controller you have a range of 1 to 127 addresses.
This means: If you have two contollers you have a rage of 2 * 1 to 127 = 254 functions and with 10 controllers 10 * 1 to 127 = 1270 functions. It’s true?
How does the WDF handle the devices if you have several controllers? Can you although add only 127 Devices or more?
Yes, this is supported, will work.
– pa
> This means: If you have two contollers you have a rage of 2 * 1 to 127 = 254 functions and with 10
controllers 10 * 1 to 127 = 1270 functions. It’s true?
Yes, surely.
How does the WDF handle the devices if you have several controllers? Can you although add only
127 Devices or more?
Why do you think that the limit of 127 is global? it is obviously per-controller. Different USB buses on different controllers have nothing in common.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
I think so, because I don’t found any information abaut the handling of several controllers in the WDF. Only the number 127 is reading everywhere.
The consequence is that I can have a situation with two functions with the same address on different controllers?
It is so, I should make the device address available for upper Layers. If I have more then one Devices with the same address, then I have a problem. And I should implement a own function handling. Or I make a combination of controller-number and bus-address. But then I should search how I get the controller-number 
>make a combination of controller-number and bus-address.
…or just use PnP device interfaces to avoid all of this.
I think that the USB device address is volatile, and can change if you plug another device to the same tree.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>…or just use PnP device interfaces to avoid all of this.
I must admit that I don’t now details of the PnP device interfaces. I must find out first what is special on this interface.
I think that the USB device address is volatile, and can change if you plug another device to the same tree.
realy? That’s a major difficulty. I see, I need a better book
> I must admit that I don’t now details of the PnP device interfaces.
IoRegisterDeviceInterface
IoSetDeviceInterfaceState
SetupDiGetClassDevs
SetupDiGetDeviceInterfaceDetail
This is the way to properly name and enumerate the same devices.
Note that the numbers will not give you anything anyway - you cannot correspond the decimal number to the actual device box connected, unless you will have some LED on the device and the “identify device” button in the UI app which will cause the LED to blink.
So, forget device numbers for USB, use PnP naming described above.
Same is true on PCI, since the way of corresponding the PCI numbers to the physical slot positions on the motherboard is mobo-specific and undocumented.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
This is a kmdf driver so the following APIs
IoRegisterDeviceInterface
IoSetDeviceInterfaceState
Should not be used. Instead use WdfDeviceCreateDeviceInterface in your EvtDriverDeviceAdd routine
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: Maxim S. Shatskih
Sent: Wednesday, May 20, 2009 6:14 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] (USB) What addressrange is supported by WDF, if you have several USB-Controllers?
> I must admit that I don’t now details of the PnP device interfaces.
IoRegisterDeviceInterface
IoSetDeviceInterfaceState
SetupDiGetClassDevs
SetupDiGetDeviceInterfaceDetail
This is the way to properly name and enumerate the same devices.
Note that the numbers will not give you anything anyway - you cannot correspond the decimal number to the actual device box connected, unless you will have some LED on the device and the “identify device” button in the UI app which will cause the LED to blink.
So, forget device numbers for USB, use PnP naming described above.
Same is true on PCI, since the way of corresponding the PCI numbers to the physical slot positions on the motherboard is mobo-specific and undocumented.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
FIRST of all, the device address is an item that’s essentially private between the host controller and the device. Its only use is to allow the host controller to address the device, and it’s meaningless outside that context. Today, you plug your device into the third slot of the second hub, the device gets ID 34. Tomorrow, you do the same thing (same device, same slot, same hub) your device gets ID 67. What good is that to you. Do as Max suggested: “So, forget device numbers for USB, use PnP naming described above.”
SECOND, I don’t believe that device addresses can change when another, unrelated, device is plugged into the system. How and why would that happen… the whole bus get’s reset, everything stops, and each device is re-enumerated? That would be terribly disruptive to traffic on the bus. Nah, I’ve never seen it and I until somebody shows me in the spec that it’s allowed I won’t believe it is.
Peter
OSR
xxxxx@siemens.com wrote:
I think so, because I don’t found any information abaut the handling of several controllers in the WDF. Only the number 127 is reading everywhere.
WDF doesn’t care about this, nor do USB device drivers. That device
number is simply not visible once you get above the host controller.
Remember that USB device drivers are in a stack – that’s how these
trees are kept straight. A driver for a device in host controller #2
will be in a completely different stack from a device in host controller
#3, so their requests go to different instances of the host controller
driver, each of whom is keeping their own DMA lists completely
independent of any other host controller.
The consequence is that I can have a situation with two functions with the same address on different controllers?
Yes, but so what? Your driver never sees this number, and doesn’t use
it when addressing the device.
It is so, I should make the device address available for upper Layers. If I have more then one Devices with the same address, then I have a problem. And I should implement a own function handling. Or I make a combination of controller-number and bus-address. But then I should search how I get the controller-number
Why do you think you need this?
I think that the USB device address is volatile, and can change if you plug another device to the same tree.
Only if there is a re-enumeration, and that will cause your driver to be
unloaded and reloaded.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.