device qualifier descriptor request on rpi linux for USB 2.0 FS only device

[metebalci]

I am working on a USB 2.0 FS device implementation on STM32H5. Setup/Enumeration works but Linux (Rpi 3B+ raspian) requests device qualifier descriptor and even if I send request error (stall) it keeps repeating the request and the enumeration is not completed. Windows works. If I send a device qualifier descriptor with other speed configurations=0, then Linux also works. USB 2.0 spec says FS only device should return a request error for such a request but I dont get why Linux insists requesting this. Is this a known issue, problem with RPi or Linux or am I missing something ?

[zilp]

Are you responding with STALL in the SETUP transaction or in the following IN or OUT transaction(s)?

[metebalci]

Are you responding with STALL in the SETUP transaction or in the following IN or OUT transaction(s)?

In the following IN. As far as I understand that is how request error should work ? I am not very sure why first IN is responded with NAK, might be because I am logging things to console but I think I tried without and the result was the same.

I attached captures. One with returning device qualifier where enumeration succeeds. The other two are with stall, also showing it is in IN trx.

[zilp]

In the following IN. As far as I understand that is how request error should work ? I am not very sure why first IN is responded with NAK, might be because I am logging things to console but I think I tried without and the result was the same.

Yeah, that should be OK.

My guess would be that the device descriptor specifies something that's incompatible with FS and Linux tries to work around that by forcing HS, maybe?

[abyrvalg]

What do you have in device descriptor bcdUSB? 2.0? Try changing it to 1.1

[metebalci]

What do you have in device descriptor bcdUSB? 2.0? Try changing it to 1.1

Yes I know it works with 1.1 as it does not request the device qualifier descriptor. I wonder why this happens with 2.0. I will try to find a USB 2.0 FS device if I can and compare.

[metebalci]

My guess would be that the device descriptor specifies something that's incompatible with FS and Linux tries to work around that by forcing HS, maybe?

That would make sense but I think there is nothing related to speed in the descriptors. I will check other devices if I can find one and maybe another non-rpi linux.

[zilp]

That would make sense but I think there is nothing related to speed in the descriptors.

Yeah, but stuff like packet sizes also depends on speed.

I will check other devices if I can find one and maybe another non-rpi linux.

I wouldn't really expect them to be patching the USB stack for raspian.

[metebalci]

Yeah, but stuff like packet sizes also depends on speed.

I am using 64 bytes so it should work with FS, and actually also interestingly the device I mention below uses 16 and although an HS device should use only 64, Linux still requests device qualifier from that one. It seems the driver is not checking that.

Meanwhile I found the issue. I checked another device, luckily I found a USB 2.0 FS device (a midi interface) quickly and it seems Linux requests the device qualifier descriptor 3 times (even after STALL is returned to the first and to the second). So after replying STALL to each then it gives up and continues to other things. I was only responding to the first one (not on purpose, it was a mistake anyway). So, now always replying STALL and it continues requesting other things.

[zilp]

I am using 64 bytes so it should work with FS, and actually also interestingly the device I mention below uses 16 and although an HS device should use only 64, Linux still requests device qualifier from that one. It seems the driver is not checking that.

But that would be the correct behaviour?! I mean, the "normal" device descriptor is not relevant for HS operation anyhow, so it would be perfectly fine to specify 16 bytes there, while still supporting HS operation!? But if the "FS decriptor" specified a packet size not allowed with FS, then one possible workaround for that would be to probe for HS and use that if it isn't broken, and give up if that's not supported ...

Meanwhile I found the issue. I checked another device, luckily I found a USB 2.0 FS device (a midi interface) quickly and it seems Linux requests the device qualifier descriptor 3 times (even after STALL is returned to the first and to the second). So after replying STALL to each then it gives up and continues to other things. I was only responding to the first one (not on purpose, it was a mistake anyway). So, now always replying STALL and it continues requesting other things.

Well, it was a workaround for something else then that confused you ;-)

[metebalci]

I am using 64 bytes so it should work with FS, and actually also interestingly the device I mention below uses 16 and although an HS device should use only 64, Linux still requests device qualifier from that one. It seems the driver is not checking that.

But that would be the correct behaviour?! I mean, the "normal" device descriptor is not relevant for HS operation anyhow, so it would be perfectly fine to specify 16 bytes there, while still supporting HS operation!? But if the "FS decriptor" specified a packet size not allowed with FS, then one possible workaround for that would be to probe for HS and use that if it isn't broken, and give up if that's not supported ...

I should first say I did not read all the spec word by word, not yet at least. I also did not look at HS specific things in detail yet. I saw the packet sizes are given in control transfer packet size constraints, not exactly sure why there is such a constraint (LS should be 8 bytes, FS any of 8,16,32,64 and HS 64 bytes), but I think they are not meant to be used as LS, FS, HS distinction. LS, FS is already distinguished by the pullups and I think HS support is first checked by this device qualifier descriptor. I dont know if HS signalling (chirps?) is tried before this or it is not tried at all if there is no valid device qualifier (and then there is a other speed configuration descriptor).

I dont know what happens when the device is really HS and does everything properly, but reports MaxPacketLen0 as 16 bytes. Partly the issue with the enumeration is I think the spec does not normatively say how it should be done (and fail). Then the host controllers might behave differently, maybe to support some historically bad behaving devices also, not sure.

I just saw in Linux kernel source code (drivers/usb/core/message.c) this comment:

Code: [Select]

/* The USB spec says configuration 0 means unconfigured.
 * But if a device includes a configuration numbered 0,
 * we will accept it as a correctly configured state.
 * Use -1 if you really want to unconfigure the device.
 */

Sounds very strange to me.

[metebalci]

Related to what just said, for example, I accidentally set the max packet len to 256 for FS device also in bulk transfer endpoint (I thought it could be higher than 64) but the spec says it can be maximum 64. So when connected to Linux, the enumeration actually completes, but Linux logs:

Code: [Select]

config 1 interface 0 altsetting 0 endpoint 0x1 has invalid maxpacket 256, setting to 64
so it implicitly sets the packet len to 64 rather than failing the enumeration.

[zilp]

I should first say I did not read all the spec word by word, not yet at least. I also did not look at HS specific things in detail yet. I saw the packet sizes are given in control transfer packet size constraints, not exactly sure why there is such a constraint (LS should be 8 bytes, FS any of 8,16,32,64 and HS 64 bytes), but I think they are not meant to be used as LS, FS, HS distinction. LS, FS is already distinguished by the pullups and I think HS support is first checked by this device qualifier descriptor. I dont know if HS signalling (chirps?) is tried before this or it is not tried at all if there is no valid device qualifier (and then there is a other speed configuration descriptor).

It's not about whether they *should* be used for distinction, it's just about whether they *are* used to handle broken devices. Though I was confusing non-EP0 packet size limits with EP0 size limits, because on non-EP0, HS allows larger packets than FS (by one byte ...).

Partly the issue with the enumeration is I think the spec does not normatively say how it should be done (and fail). Then the host controllers might behave differently, maybe to support some historically bad behaving devices also, not sure.

The host controller really doesn't have anything to do with that, that's all done by the USB stack of the OS. But, yeah, whenever you see USB host software do something weird (like trying to read the qualifier descriptor three times in a row), you can bet there is some broken device out there that that weird behaviour is a workaround for.

I just saw in Linux kernel source code (drivers/usb/core/message.c) this comment:

Code: [Select]

/* The USB spec says configuration 0 means unconfigured.
 * But if a device includes a configuration numbered 0,
 * we will accept it as a correctly configured state.
 * Use -1 if you really want to unconfigure the device.
 */

Sounds very strange to me.

Well, apparently, there are devices out there that have a configuration with number 0 in their descriptors, which isn't allowed by the standard (because 0 should indicate an unconfigured device). This is how Linux makes those broken devices work.

[metebalci]

The host controller really doesn't have anything to do with that, that's all done by the USB stack of the OS. But, yeah, whenever you see USB host software do something weird (like trying to read the qualifier descriptor three times in a row), you can bet there is some broken device out there that that weird behaviour is a workaround for.

It seems this try 3 times thing is a common thing, I see it in various places, might be written in the spec as well.

Well, apparently, there are devices out there that have a configuration with number 0 in their descriptors, which isn't allowed by the standard (because 0 should indicate an unconfigured device). This is how Linux makes those broken devices work.

Some workarounds I understand but hard to understand how some mistakes are made, how they managed to make a device with configuration value 0 is an interesting one.

[metebalci]

I dont know if HS signalling (chirps?) is tried before this or it is not tried at all if there is no valid device qualifier (and then there is a other speed configuration descriptor).

I just read the parts relevant to HS handshake in the spec. So the HS handshake actually happens during reset (after the normal FS reset), so definitely before requesting the device qualifier descriptor. So the question is why the host even requests this descriptor if HS handshake cannot be done, it is obvious the device is not HS and it will not return a device qualifier descriptor.

[abyrvalg]

There are cases when HS device can’t respond to HS chirp (extremely bad cable, FS hub etc), but the OS finds it out and says something like “This device can work faster when plugged into HS port” (seen that on Windows at least).

And the recipe to make a device with config value 0 is simple: instead of reading the official spec and torturing the device with official USB Command Verifier tool, people ask on SO and use some obscure libs.

[zilp]

It seems this try 3 times thing is a common thing, I see it in various places, might be written in the spec as well.

That wouldn't really make a whole lot of sense as the device isn't even allowed to give different responses to repeat requests. And in the case of transmission errors, the device shouldn't respond with a STALL.

My guess is that the repeat requests are actually subtly different to work around some device bugs.

Some workarounds I understand but hard to understand how some mistakes are made, how they managed to make a device with configuration value 0 is an interesting one.

Presumably by testing it with some system that didn't care and not reading the specs? I mean, that's how broken devices get created, isn't it?

I just read the parts relevant to HS handshake in the spec. So the HS handshake actually happens during reset (after the normal FS reset), so definitely before requesting the device qualifier descriptor. So the question is why the host even requests this descriptor if HS handshake cannot be done, it is obvious the device is not HS and it will not return a device qualifier descriptor.

Yeah, indeed, I was confused about the details--it's been a while ...

But the purpose is to detect when a device might be limited in functionality because of slow link speed, either because of a bad connection, as abyrvalg mentioned, or because it's connected to a non-HS port.

[metebalci]

There are cases when HS device can’t respond to HS chirp (extremely bad cable, FS hub etc), but the OS finds it out and says something like “This device can work faster when plugged into HS port” (seen that on Windows at least).

Good point, I see.

[metebalci]

But the purpose is to detect when a device might be limited in functionality because of slow link speed, either because of a bad connection, as abyrvalg mentioned, or because it's connected to a non-HS port.

Yes I understand, that makes sense.