Support for USB 1.0 and 1.0 in UsbRev enum

[sourcebox]

The UsbRev enum only has support for specification 2.0 and 2.1. Unless there's a reason not to add older revisions, 1.0 and 1.1 should also be supported.

[ryan-summers]

What were the diffs between 1.0 and 2.0? Does this stack actually conform with USB 1.0 and USB 1.1?

[sourcebox]

What were the diffs between 1.0 and 2.0? Does this stack actually conform with USB 1.0 and USB 1.1?

Good question. I can't tell you the differences in detail, and it's debatable if anyone will ever do a USB 1.0 device these days. But USB 1.1 is what many full speed devices still use. And most MCUs only support FS without external PHY. So 1.1 should be an option and if something is not conform with it in the stack, then it has to be fixed.

From whar I see on various sources, the difference between 1.x and 2.x in terms of compatibility is primarily the electrical specification.

[jannic]

I don't know if there's a practical difference between setting bcdUSB to 1.1 or 2.0 for a full-speed device. But I'd give the firmware author the choice. Even if setting it to 2.0 is fully spec conformant, as a firmware author you may need to be compatible with a broken USB driver that requires 1.1.

[jannic]

But beware: The enum is not marked as non_exhaustive, so adding a new variant is a breaking change.

[ianrrees]

To me, the usb-device API feels a bit unstable at the moment, and AFAIK it hasn't been confirmed to conform to specs. So, I'm in favour of adding useful variants to the enum, without marking non_exhaustive, but maybe we try to lump the change in with other breaking changes (eg #153 is one I'd like to move on)

[jannic]

Indeed, there's already been a breaking change since the last release: #144

So now it's probably a good time to apply this breaking change es well.

[ryan-summers]

Sounds good, thanks for the discussion. Agreed in that if users choose to use this version, it's at their own design. If it causes problems, we can always remove it later :)