usb: gadget: composite: Return bcdUSB 0x0310

usb: gadget: composite: Return bcdUSB 0x0310

[John Youn]

Hi,

I'd like to request the following be applied to stable trees 3.2+.

1a85329171094951956a37acc8abb7e51c1e742e ("usb: gadget: composite:
Return bcdUSB 0x0310")

The USB 3.1 specification replaces the USB 3.0 specification and all new
devices that are running at SuperSpeed or higher speeds must report a
bcdUSB of 0x0310.

Thanks,
John

Re: usb: gadget: composite: Return bcdUSB 0x0310

[Greg Kroah-Hartman]

On Fri, Apr 08, 2016 at 04:19:40PM -0700, John Youn wrote:
> Hi,
> 
> I'd like to request the following be applied to stable trees 3.2+.
> 
> 1a85329171094951956a37acc8abb7e51c1e742e ("usb: gadget: composite:
> Return bcdUSB 0x0310")
> 
> The USB 3.1 specification replaces the USB 3.0 specification and all new
> devices that are running at SuperSpeed or higher speeds must report a
> bcdUSB of 0x0310.

That doesn't seem very "backwards compatible" of the spec to me, what
happens if you return a 3.0 string, when you really are only handling
3.0 things like we do in older kernels?

thanks,

greg k-h

Re: usb: gadget: composite: Return bcdUSB 0x0310

[John Youn]

On 4/8/2016 5:58 PM, Greg Kroah-Hartman wrote:
> On Fri, Apr 08, 2016 at 04:19:40PM -0700, John Youn wrote:
>> Hi,
>>
>> I'd like to request the following be applied to stable trees 3.2+.
>>
>> 1a85329171094951956a37acc8abb7e51c1e742e ("usb: gadget: composite:
>> Return bcdUSB 0x0310")
>>
>> The USB 3.1 specification replaces the USB 3.0 specification and all new
>> devices that are running at SuperSpeed or higher speeds must report a
>> bcdUSB of 0x0310.
> 
> That doesn't seem very "backwards compatible" of the spec to me, what
> happens if you return a 3.0 string, when you really are only handling
> 3.0 things like we do in older kernels?
> 
> thanks,
> 
> greg k-h
> 

Hi Greg,

I believe there would be no backward-incompatible change as all 3.0
things are now part of the 3.1 spec, and the new stuff in 3.1 (such as
SuperSpeedPlus) are exposed through new descriptors. And I don't
believe anything currently looks at bcdUSB 3.0 vs 3.1 (unlike with USB
2.x). But I can't say for sure.

This is only needed because the CV tool has started requiring this and
I believe the compliance process will also start requiring it for all
new devices. We plan to certify new devices with kernels as old as
3.18, hence this backport.

If you like, I can solicit comments on this from the linux-usb list.

Thanks,
John

Re: usb: gadget: composite: Return bcdUSB 0x0310

[Greg Kroah-Hartman]

On Mon, Apr 11, 2016 at 02:28:08PM -0700, John Youn wrote:
> On 4/8/2016 5:58 PM, Greg Kroah-Hartman wrote:
> > On Fri, Apr 08, 2016 at 04:19:40PM -0700, John Youn wrote:
> >> Hi,
> >>
> >> I'd like to request the following be applied to stable trees 3.2+.
> >>
> >> 1a85329171094951956a37acc8abb7e51c1e742e ("usb: gadget: composite:
> >> Return bcdUSB 0x0310")
> >>
> >> The USB 3.1 specification replaces the USB 3.0 specification and all new
> >> devices that are running at SuperSpeed or higher speeds must report a
> >> bcdUSB of 0x0310.
> > 
> > That doesn't seem very "backwards compatible" of the spec to me, what
> > happens if you return a 3.0 string, when you really are only handling
> > 3.0 things like we do in older kernels?
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Hi Greg,
> 
> I believe there would be no backward-incompatible change as all 3.0
> things are now part of the 3.1 spec, and the new stuff in 3.1 (such as
> SuperSpeedPlus) are exposed through new descriptors. And I don't
> believe anything currently looks at bcdUSB 3.0 vs 3.1 (unlike with USB
> 2.x). But I can't say for sure.
> 
> This is only needed because the CV tool has started requiring this and
> I believe the compliance process will also start requiring it for all
> new devices. We plan to certify new devices with kernels as old as
> 3.18, hence this backport.

For "new" devices, why are you using such an old and obsolete kernel as
3.18?

For an "old" device, a bcdUSB of 3.0 should just be fine, right?

> If you like, I can solicit comments on this from the linux-usb list.

Please do, you need the maintainer of the subsystem to agree to this at
the least :)

thanks,

greg k-h