Re: [PATCH] Revert "usb: gadget: composite: fix OS descriptors w_value

Re: [PATCH] Revert "usb: gadget: composite: fix OS descriptors w_value

[Vodicka, Michal]

> Hmm, very odd. How are you testing this on the host side?

We just attach the device and check the registry values created by OS
for our device. As
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_XXXX&PID_YYYY&MI_NN\<device_instance>\Device Parameters.
When it works our extended properties are created there.

We check the communication using USB analyzer which clearly shows
wValue bytes are in opposite order than documented. This is SETUP
packet captured:

Offset  0   1   2   3   4   5   6   7
0x000   C1  A1  02  00  05  00  0A  00

As you can see, this is interface request and out interface number was
2 which is in the low byte of wValue.

> Could it be that you are running into the WinUSB bug described here:

No. The mentioned bug is in wIndex and out problem is wValue. Also,
MSOS descriptors are read before WinUsb is even run.

Background: we have a composite device which uses MSOS descriptors with
extended properties. It worked well on all tested Win10 and Win11
installations for two years until we applied your original fix which
switches wValue bytes. Then extended properties stopped work. We looked
for the culprit and found this. I understand MS documentation says
interface number is in high byte of wValue but the real implementation
uses low byte for it as was verified using USB analyzer.

Question for you:

> I had issues with getting Windows to accept the OS descriptors when
> the function I wanted to use with WinUSB was not the first (=
> interface 0) function in a composite device together with HID and
> mass storage.

What Windows version were you using and have you used USB analyzer to
check the communication?

Michal

Re: [PATCH] Revert "usb: gadget: composite: fix OS descriptors w_value

[Peter Korsgaard]

On 9/11/24 03:32, Vodicka, Michal wrote:
>> Hmm, very odd. How are you testing this on the host side?
> 
> We just attach the device and check the registry values created by OS
> for our device. As
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_XXXX&PID_YYYY&MI_NN\<device_instance>\Device Parameters.
> When it works our extended properties are created there.
> 
> We check the communication using USB analyzer which clearly shows
> wValue bytes are in opposite order than documented. This is SETUP
> packet captured:
> 
> Offset  0   1   2   3   4   5   6   7
> 0x000   C1  A1  02  00  05  00  0A  00
> 
> As you can see, this is interface request and out interface number was
> 2 which is in the low byte of wValue.

OK, annoying. I am traveling for conferences this/next week so I cannot 
verify here, but presumably you are correct. Do you perhaps have a more 
complete capture you can share?


> 
>> Could it be that you are running into the WinUSB bug described here:
> 
> No. The mentioned bug is in wIndex and out problem is wValue. Also,
> MSOS descriptors are read before WinUsb is even run.

Ahh yes, indeed.


> What Windows version were you using and have you used USB analyzer to
> check the communication?

It's been a while, but I believe Windows 10. In the end I ended up 
shuffling the interfaces around so the one with the MSOS descriptors was 
interface 0 for better compatibility, so it is possible that something 
went wrong with my interface != 0 tests.

If so, then I am fine with reverting, but we should probably add a 
comment explaining that the documentation is wrong.

-- 
Bye, Peter Korsgaard

RE: [EXT] Re: [PATCH] Revert "usb: gadget: composite: fix OS descriptors w_value

[Vodicka, Michal]

> OK, annoying. I am traveling for conferences this/next week so I cannot verify here, but presumably you are correct. Do you perhaps have a more complete capture you can share?

Sure. First, get MSOS feature descriptor:

SETUP packet requesting header:
C0 A1 00 00 04 00 10 00

Data IN response:
28 00 00 00 00 01 04 00
01 00 00 00 00 00 00 00

SETUP packet requesting full descriptor:
C0 A1 00 00 04 00 28 00

DATA IN response:
28 00 00 00 00 01 04 00 
01 00 00 00 00 00 00 00
02 01 57 49 4E 55 53 42 ..WINUSB
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

This is wIndex 4 and device request. There is no problem as interface/wValue is 0.

Now the property:

SETUP packet requesting header:
C1 A1 02 00 05 00 0A 00

DATA IN response:
8E 00 00 00 00 01 05 00
01 00

SETUP packet requesting full descriptor:
C1 A1 02 00 05 00 8E 00

DATA IN response (3 packets):
00 00 28 00 44 00 65 00  ..(.D.e.
76 00 69 00 63 00 65 00  v.i.c.e.
49 00 6E 00 74 00 65 00  I.n.t.e.
72 00 66 00 61 00 63 00  r.f.a.c.
65 00 47 00 55 00 49 00  e.G.U.I.
44 00 00 00 4E 00 00 00  D...N...

7B 00 43 00 46 00 34 00
39 00 33 00 45 00 31 00
41 00 2D 00 41 00 32 00
37 00 32 00 2D 00 34 00
32 00 32 00 42 00 2D 00
41 00 33 00 36 00 34 00
2D 00 39 00 36 00 37 00
42 00 34 00 39 00 42 00

32 00 36 00 42 00 35 00
37 00 7D 00 00 00

I omitted ACSII value for our interface GUID as it is not important here. 

The important part is wIndex 5 (request number), device request (0xC1) and our interface number 2 at offset 2 which is LOW byte of wValue. There is the problem. Captured at Win10 23H2 but it behaves the same way at least 2 years, probably always.

> It's been a while, but I believe Windows 10. In the end I ended up shuffling the interfaces around so the one with the MSOS descriptors was interface 0 for better compatibility, so it is possible that something went wrong with my interface != 0 tests.

It would be interesting if you can reproduce it but I presume it was a different problem. I tested it at my old Win7 machine and it behaves the same way as at Win10/11 i.e. interface number is in the low byte. Also, Linux implementation had it correctly for a long time and maybe somebody did it for a reason even when MS documentation claims opposite.

> If so, then I am fine with reverting, but we should probably add a comment explaining that the documentation is wrong.

Yes. Note the documentation is from 2007 which is before Win7 release where it was used for the first time.

Michal

Re: [PATCH] Revert "usb: gadget: composite: fix OS descriptors w_value

[Greg KH]

On Fri, Sep 13, 2024 at 05:39:21PM +0200, Peter Korsgaard wrote:
> On 9/11/24 03:32, Vodicka, Michal wrote:
> > > Hmm, very odd. How are you testing this on the host side?
> > 
> > We just attach the device and check the registry values created by OS
> > for our device. As
> > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_XXXX&PID_YYYY&MI_NN\<device_instance>\Device Parameters.
> > When it works our extended properties are created there.
> > 
> > We check the communication using USB analyzer which clearly shows
> > wValue bytes are in opposite order than documented. This is SETUP
> > packet captured:
> > 
> > Offset  0   1   2   3   4   5   6   7
> > 0x000   C1  A1  02  00  05  00  0A  00
> > 
> > As you can see, this is interface request and out interface number was
> > 2 which is in the low byte of wValue.
> 
> OK, annoying. I am traveling for conferences this/next week so I cannot
> verify here, but presumably you are correct. Do you perhaps have a more
> complete capture you can share?
> 
> 
> > 
> > > Could it be that you are running into the WinUSB bug described here:
> > 
> > No. The mentioned bug is in wIndex and out problem is wValue. Also,
> > MSOS descriptors are read before WinUsb is even run.
> 
> Ahh yes, indeed.
> 
> 
> > What Windows version were you using and have you used USB analyzer to
> > check the communication?
> 
> It's been a while, but I believe Windows 10. In the end I ended up shuffling
> the interfaces around so the one with the MSOS descriptors was interface 0
> for better compatibility, so it is possible that something went wrong with
> my interface != 0 tests.
> 
> If so, then I am fine with reverting, but we should probably add a comment
> explaining that the documentation is wrong.

Ok, Michal, can you add some text tothe changelog and send a v2 for
this?

thanks,

greg k-h

Re: [PATCH] Revert "usb: gadget: composite: fix OS descriptors w_value

[Elson Serrao]

On 10/4/2024 6:33 AM, Greg KH wrote:
> On Fri, Sep 13, 2024 at 05:39:21PM +0200, Peter Korsgaard wrote:
>> On 9/11/24 03:32, Vodicka, Michal wrote:
>>>> Hmm, very odd. How are you testing this on the host side?
>>>
>>> We just attach the device and check the registry values created by OS
>>> for our device. As
>>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_XXXX&PID_YYYY&MI_NN\<device_instance>\Device Parameters.
>>> When it works our extended properties are created there.
>>>
>>> We check the communication using USB analyzer which clearly shows
>>> wValue bytes are in opposite order than documented. This is SETUP
>>> packet captured:
>>>
>>> Offset  0   1   2   3   4   5   6   7
>>> 0x000   C1  A1  02  00  05  00  0A  00
>>>
>>> As you can see, this is interface request and out interface number was
>>> 2 which is in the low byte of wValue.
>>
>> OK, annoying. I am traveling for conferences this/next week so I cannot
>> verify here, but presumably you are correct. Do you perhaps have a more
>> complete capture you can share?
>>
>>
>>>
>>>> Could it be that you are running into the WinUSB bug described here:
>>>
>>> No. The mentioned bug is in wIndex and out problem is wValue. Also,
>>> MSOS descriptors are read before WinUsb is even run.
>>
>> Ahh yes, indeed.
>>
>>
>>> What Windows version were you using and have you used USB analyzer to
>>> check the communication?
>>
>> It's been a while, but I believe Windows 10. In the end I ended up shuffling
>> the interfaces around so the one with the MSOS descriptors was interface 0
>> for better compatibility, so it is possible that something went wrong with
>> my interface != 0 tests.
>>
>> If so, then I am fine with reverting, but we should probably add a comment
>> explaining that the documentation is wrong.
> 
> Ok, Michal, can you add some text tothe changelog and send a v2 for
> this?
> 

HI Michal

I am facing a similar issue where the Windows host is unable to fetch OS descriptor from the device running v6.9 kernel with Android mainline. Tested your patch and it fixes the issue.

Host Machine: Windows10 22H2
Composite device: NCM+Android Debugger (ADB)
Issue: Windows host is unable to fetch the OS descriptor for ADB interface and hence ADB functionality is failing.

Also checked the USB analyzer output and it shows wValue bytes in opposite order than documented i.e interface number is in the lower bytes (for Extended Properties OS Desc)

Thanks
Elson 

Re: [PATCH] Revert "usb: gadget: composite: fix OS descriptors w_value

[Elson Serrao]

On 10/16/2024 4:55 PM, Elson Serrao wrote:
> 
> 
> On 10/4/2024 6:33 AM, Greg KH wrote:
>> On Fri, Sep 13, 2024 at 05:39:21PM +0200, Peter Korsgaard wrote:
>>> On 9/11/24 03:32, Vodicka, Michal wrote:
>>>>> Hmm, very odd. How are you testing this on the host side?
>>>>
>>>> We just attach the device and check the registry values created by OS
>>>> for our device. As
>>>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_XXXX&PID_YYYY&MI_NN\<device_instance>\Device Parameters.
>>>> When it works our extended properties are created there.
>>>>
>>>> We check the communication using USB analyzer which clearly shows
>>>> wValue bytes are in opposite order than documented. This is SETUP
>>>> packet captured:
>>>>
>>>> Offset  0   1   2   3   4   5   6   7
>>>> 0x000   C1  A1  02  00  05  00  0A  00
>>>>
>>>> As you can see, this is interface request and out interface number was
>>>> 2 which is in the low byte of wValue.
>>>
>>> OK, annoying. I am traveling for conferences this/next week so I cannot
>>> verify here, but presumably you are correct. Do you perhaps have a more
>>> complete capture you can share?
>>>
>>>
>>>>
>>>>> Could it be that you are running into the WinUSB bug described here:
>>>>
>>>> No. The mentioned bug is in wIndex and out problem is wValue. Also,
>>>> MSOS descriptors are read before WinUsb is even run.
>>>
>>> Ahh yes, indeed.
>>>
>>>
>>>> What Windows version were you using and have you used USB analyzer to
>>>> check the communication?
>>>
>>> It's been a while, but I believe Windows 10. In the end I ended up shuffling
>>> the interfaces around so the one with the MSOS descriptors was interface 0
>>> for better compatibility, so it is possible that something went wrong with
>>> my interface != 0 tests.
>>>
>>> If so, then I am fine with reverting, but we should probably add a comment
>>> explaining that the documentation is wrong.
>>
>> Ok, Michal, can you add some text tothe changelog and send a v2 for
>> this?
>>
> 
> HI Michal
> 
> I am facing a similar issue where the Windows host is unable to fetch OS descriptor from the device running v6.9 kernel with Android mainline. Tested your patch and it fixes the issue.
> 
> Host Machine: Windows10 22H2
> Composite device: NCM+Android Debugger (ADB)
> Issue: Windows host is unable to fetch the OS descriptor for ADB interface and hence ADB functionality is failing.
> 
> Also checked the USB analyzer output and it shows wValue bytes in opposite order than documented i.e interface number is in the lower bytes (for Extended Properties OS Desc)
> 

HI Michal,Greg

Since there has been no update for quite some time, would it be okay if I upload v2 with the feedback given ? This bug is impacting ADB enumeration on Qualcomm platforms, so would like to proceed with this fix.

Thanks
Elson

RE: [EXT] Re: [PATCH] Revert "usb: gadget: composite: fix OS descriptors w_value

[Vrastil, Michal]

Hi Elso,
Yes, feel free to proceed with the updated patch. I was swamped by other work and never got to finish this, unfortunately.
Thank you and best regards,

Michal Vraštil
Manager, Firmware Engineering, Extended Access Technologies, Biometric BU
Mobile: +420608977018
michal.vrastil@hidglobal.com

HID Czech s.r.o., Thámova 183/11 , 186 00 Praha 8
www.hidglobal.com


-----Original Message-----
From: Elson Serrao <quic_eserrao@quicinc.com> 
Sent: Tuesday, November 12, 2024 7:11 PM
To: Vrastil, Michal <michal.vrastil@hidglobal.com>; Greg KH <greg@kroah.com>
Cc: Vodicka, Michal <michal.vodicka@hidglobal.com>; balbi@kernel.org; linux-usb@vger.kernel.org; Vrastil, Michal <michal.vrastil@hidglobal.com>; stable@kernel.org
Subject: [EXT] Re: [PATCH] Revert "usb: gadget: composite: fix OS descriptors w_value

[Some people who received this message don't often get email from quic_eserrao@quicinc.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

CAUTION: This email is external. Do not click links or attachments that are unexpected or from unknown senders. If unsure, click the Report Phishing Button in Outlook.

On 10/16/2024 4:55 PM, Elson Serrao wrote:
>
>
> On 10/4/2024 6:33 AM, Greg KH wrote:
>> On Fri, Sep 13, 2024 at 05:39:21PM +0200, Peter Korsgaard wrote:
>>> On 9/11/24 03:32, Vodicka, Michal wrote:
>>>>> Hmm, very odd. How are you testing this on the host side?
>>>>
>>>> We just attach the device and check the registry values created by 
>>>> OS for our device. As 
>>>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_XXXX&PID_YYYY&MI_NN\<device_instance>\Device Parameters.
>>>> When it works our extended properties are created there.
>>>>
>>>> We check the communication using USB analyzer which clearly shows 
>>>> wValue bytes are in opposite order than documented. This is SETUP 
>>>> packet captured:
>>>>
>>>> Offset  0   1   2   3   4   5   6   7
>>>> 0x000   C1  A1  02  00  05  00  0A  00
>>>>
>>>> As you can see, this is interface request and out interface number 
>>>> was
>>>> 2 which is in the low byte of wValue.
>>>
>>> OK, annoying. I am traveling for conferences this/next week so I 
>>> cannot verify here, but presumably you are correct. Do you perhaps 
>>> have a more complete capture you can share?
>>>
>>>
>>>>
>>>>> Could it be that you are running into the WinUSB bug described here:
>>>>
>>>> No. The mentioned bug is in wIndex and out problem is wValue. Also, 
>>>> MSOS descriptors are read before WinUsb is even run.
>>>
>>> Ahh yes, indeed.
>>>
>>>
>>>> What Windows version were you using and have you used USB analyzer 
>>>> to check the communication?
>>>
>>> It's been a while, but I believe Windows 10. In the end I ended up 
>>> shuffling the interfaces around so the one with the MSOS descriptors 
>>> was interface 0 for better compatibility, so it is possible that 
>>> something went wrong with my interface != 0 tests.
>>>
>>> If so, then I am fine with reverting, but we should probably add a 
>>> comment explaining that the documentation is wrong.
>>
>> Ok, Michal, can you add some text tothe changelog and send a v2 for 
>> this?
>>
>
> HI Michal
>
> I am facing a similar issue where the Windows host is unable to fetch OS descriptor from the device running v6.9 kernel with Android mainline. Tested your patch and it fixes the issue.
>
> Host Machine: Windows10 22H2
> Composite device: NCM+Android Debugger (ADB)
> Issue: Windows host is unable to fetch the OS descriptor for ADB interface and hence ADB functionality is failing.
>
> Also checked the USB analyzer output and it shows wValue bytes in 
> opposite order than documented i.e interface number is in the lower 
> bytes (for Extended Properties OS Desc)
>

HI Michal,Greg

Since there has been no update for quite some time, would it be okay if I upload v2 with the feedback given ? This bug is impacting ADB enumeration on Qualcomm platforms, so would like to proceed with this fix.

Thanks
Elson

RE: [EXT] Re: [PATCH] Revert "usb: gadget: composite: fix OS descriptors w_value

[Vodicka, Michal]

Hi Elson,

Sure, please finish it if you can. I had something urgent to do, postponed it and finally forgot...

Thanks,

Michal

-----Original Message-----
From: Elson Serrao <quic_eserrao@quicinc.com> 
Sent: Tuesday, November 12, 2024 7:11 PM
To: Vrastil, Michal <michal.vrastil@hidglobal.com>; Greg KH <greg@kroah.com>
Cc: Vodicka, Michal <michal.vodicka@hidglobal.com>; balbi@kernel.org; linux-usb@vger.kernel.org; Vrastil, Michal <michal.vrastil@hidglobal.com>; stable@kernel.org
Subject: [EXT] Re: [PATCH] Revert "usb: gadget: composite: fix OS descriptors w_value

[Some people who received this message don't often get email from quic_eserrao@quicinc.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

CAUTION: This email is external. Do not click links or attachments that are unexpected or from unknown senders. If unsure, click the Report Phishing Button in Outlook.

On 10/16/2024 4:55 PM, Elson Serrao wrote:
>
>
> On 10/4/2024 6:33 AM, Greg KH wrote:
>> On Fri, Sep 13, 2024 at 05:39:21PM +0200, Peter Korsgaard wrote:
>>> On 9/11/24 03:32, Vodicka, Michal wrote:
>>>>> Hmm, very odd. How are you testing this on the host side?
>>>>
>>>> We just attach the device and check the registry values created by 
>>>> OS for our device. As 
>>>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_XXXX&PID_YYYY&MI_NN\<device_instance>\Device Parameters.
>>>> When it works our extended properties are created there.
>>>>
>>>> We check the communication using USB analyzer which clearly shows 
>>>> wValue bytes are in opposite order than documented. This is SETUP 
>>>> packet captured:
>>>>
>>>> Offset  0   1   2   3   4   5   6   7
>>>> 0x000   C1  A1  02  00  05  00  0A  00
>>>>
>>>> As you can see, this is interface request and out interface number 
>>>> was
>>>> 2 which is in the low byte of wValue.
>>>
>>> OK, annoying. I am traveling for conferences this/next week so I 
>>> cannot verify here, but presumably you are correct. Do you perhaps 
>>> have a more complete capture you can share?
>>>
>>>
>>>>
>>>>> Could it be that you are running into the WinUSB bug described here:
>>>>
>>>> No. The mentioned bug is in wIndex and out problem is wValue. Also, 
>>>> MSOS descriptors are read before WinUsb is even run.
>>>
>>> Ahh yes, indeed.
>>>
>>>
>>>> What Windows version were you using and have you used USB analyzer 
>>>> to check the communication?
>>>
>>> It's been a while, but I believe Windows 10. In the end I ended up 
>>> shuffling the interfaces around so the one with the MSOS descriptors 
>>> was interface 0 for better compatibility, so it is possible that 
>>> something went wrong with my interface != 0 tests.
>>>
>>> If so, then I am fine with reverting, but we should probably add a 
>>> comment explaining that the documentation is wrong.
>>
>> Ok, Michal, can you add some text tothe changelog and send a v2 for 
>> this?
>>
>
> HI Michal
>
> I am facing a similar issue where the Windows host is unable to fetch OS descriptor from the device running v6.9 kernel with Android mainline. Tested your patch and it fixes the issue.
>
> Host Machine: Windows10 22H2
> Composite device: NCM+Android Debugger (ADB)
> Issue: Windows host is unable to fetch the OS descriptor for ADB interface and hence ADB functionality is failing.
>
> Also checked the USB analyzer output and it shows wValue bytes in 
> opposite order than documented i.e interface number is in the lower 
> bytes (for Extended Properties OS Desc)
>

HI Michal,Greg

Since there has been no update for quite some time, would it be okay if I upload v2 with the feedback given ? This bug is impacting ADB enumeration on Qualcomm platforms, so would like to proceed with this fix.

Thanks
Elson

Re: [PATCH] Revert "usb: gadget: composite: fix OS descriptors w_value

[Peter Korsgaard]

On 11/12/24 19:11, Elson Serrao wrote:

> Since there has been no update for quite some time, would it be okay if I upload v2 with the feedback given ? This bug is impacting ADB enumeration on Qualcomm platforms, so would like to proceed with this fix.

Yes please!

-- 
Bye, Peter Korsgaard

[PATCH] Revert "usb: gadget: composite: fix OS descriptors w_value

[Vrastil, Michal]

This reverts commit ec6ce7075ef879b91a8710829016005dc8170f17.

Fix install of WinUSB dsriver using OS descriptors.
Without the fix the drivers is not installed correctly
and the property 'DeviceInterfaceGUID' is missing on host side.

The original change was based on assumption that the interface number
is in the high byte of wValue but it is in the low byte, instead.
Unfortunately, the fix is based on MS documentation which is also wrong.

The actual USB request for OS descriptors (using USB analyzer) looks
like:

Offset  0   1   2   3   4   5   6   7
0x000   C1  A1  02  00  05  00  0A  00

C1: bmRequestType (device to host, vendor, interface)
A1: nas magic number
0002: wValue (2: nas interface)
0005: wIndex (5: get extended property i.e. nas interface GUID)
008E: wLength (142)

The fix was tested on Windows 10 and Windows 11.

Fixes: ec6ce70 ("usb: gadget: composite: fix OS descriptors w_value logic")
Signed-off-by: Michal Vrastil <michal.vrastil@hidglobal.com>
---
 drivers/usb/gadget/composite.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 17ae3b394469..a3106b179562 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1925,7 +1925,7 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl)
 			buf[5] = 0x01;
 			switch (ctrl->bRequestType & USB_RECIP_MASK) {
 			case USB_RECIP_DEVICE:
-				if (w_index != 0x4 || (w_value & 0xff))
+				if (w_index != 0x4 || (w_value >> 8))
 					break;
 				buf[6] = w_index;
 				/* Number of ext compat interfaces */
@@ -1941,9 +1941,9 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl)
 				}
 				break;
 			case USB_RECIP_INTERFACE:
-				if (w_index != 0x5 || (w_value & 0xff))
+				if (w_index != 0x5 || (w_value >> 8))
 					break;
-				interface = w_value >> 8;
+				interface = w_value & 0xFF;
 				if (interface >= MAX_CONFIG_INTERFACES ||
 				    !os_desc_cfg->interface[interface])
 					break;
-- 
2.43.0

Re: [PATCH] Revert "usb: gadget: composite: fix OS descriptors w_value

[Greg KH]

On Wed, Sep 04, 2024 at 03:01:39PM +0000, Vrastil, Michal wrote:
> This reverts commit ec6ce7075ef879b91a8710829016005dc8170f17.
> 
> Fix install of WinUSB dsriver using OS descriptors.
> Without the fix the drivers is not installed correctly
> and the property 'DeviceInterfaceGUID' is missing on host side.
> 
> The original change was based on assumption that the interface number
> is in the high byte of wValue but it is in the low byte, instead.
> Unfortunately, the fix is based on MS documentation which is also wrong.
> 
> The actual USB request for OS descriptors (using USB analyzer) looks
> like:
> 
> Offset  0   1   2   3   4   5   6   7
> 0x000   C1  A1  02  00  05  00  0A  00
> 
> C1: bmRequestType (device to host, vendor, interface)
> A1: nas magic number
> 0002: wValue (2: nas interface)
> 0005: wIndex (5: get extended property i.e. nas interface GUID)
> 008E: wLength (142)
> 
> The fix was tested on Windows 10 and Windows 11.
> 
> Fixes: ec6ce70 ("usb: gadget: composite: fix OS descriptors w_value logic")
> Signed-off-by: Michal Vrastil <michal.vrastil@hidglobal.com>
> ---
>  drivers/usb/gadget/composite.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You have marked a patch with a "Fixes:" tag for a commit that is in an
  older released kernel, yet you do not have a cc: stable line in the
  signed-off-by area at all, which means that the patch will not be
  applied to any older kernel releases.  To properly fix this, please
  follow the documented rules in the
  Documentation/process/stable-kernel-rules.rst file for how to resolve
  this.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

Re: [PATCH] Revert "usb: gadget: composite: fix OS descriptors w_value

[Sergei Shtylyov]

On 9/4/24 6:01 PM, Vrastil, Michal wrote:

> This reverts commit ec6ce7075ef879b91a8710829016005dc8170f17.
> 
> Fix install of WinUSB dsriver using OS descriptors.

   Installation. And driver. :-)

> Without the fix the drivers is not installed correctly
> and the property 'DeviceInterfaceGUID' is missing on host side.
> 
> The original change was based on assumption that the interface number
> is in the high byte of wValue but it is in the low byte, instead.
> Unfortunately, the fix is based on MS documentation which is also wrong.
> 
> The actual USB request for OS descriptors (using USB analyzer) looks
> like:
> 
> Offset  0   1   2   3   4   5   6   7
> 0x000   C1  A1  02  00  05  00  0A  00
> 
> C1: bmRequestType (device to host, vendor, interface)
> A1: nas magic number
> 0002: wValue (2: nas interface)
> 0005: wIndex (5: get extended property i.e. nas interface GUID)
> 008E: wLength (142)
> 
> The fix was tested on Windows 10 and Windows 11.
> 
> Fixes: ec6ce70 ("usb: gadget: composite: fix OS descriptors w_value logic")

   12 hex digits should be specified here...

> Signed-off-by: Michal Vrastil <michal.vrastil@hidglobal.com>
[...]

MBR, Sergey

Re: [PATCH] Revert "usb: gadget: composite: fix OS descriptors w_value

[Peter Korsgaard]

>>>>> "Vrastil," == Vrastil, Michal <michal.vrastil@hidglobal.com> writes:

 > This reverts commit ec6ce7075ef879b91a8710829016005dc8170f17.
 > Fix install of WinUSB dsriver using OS descriptors.
 > Without the fix the drivers is not installed correctly
 > and the property 'DeviceInterfaceGUID' is missing on host side.

 > The original change was based on assumption that the interface number
 > is in the high byte of wValue but it is in the low byte, instead.
 > Unfortunately, the fix is based on MS documentation which is also wrong.

 > The actual USB request for OS descriptors (using USB analyzer) looks
 > like:

 > Offset  0   1   2   3   4   5   6   7
 > 0x000   C1  A1  02  00  05  00  0A  00

 > C1: bmRequestType (device to host, vendor, interface)
 > A1: nas magic number
 > 0002: wValue (2: nas interface)
 > 0005: wIndex (5: get extended property i.e. nas interface GUID)
 > 008E: wLength (142)

 > The fix was tested on Windows 10 and Windows 11.

Hmm, very odd. How are you testing this on the host side? Could it be
that you are running into the WinUSB bug described here:

https://github.com/pbatard/libwdi/wiki/WCID-Devices#defining-a-device-interface-guid-or-other-device-specific-properties

IMPORTANT NOTE 1: There is a bug/limitation in WinUSB that will force
the wIndex of any Interface Request to the interface num ber. This means
that, if you are using WinUSB to verify the content of your Extended
Properties Feature Descriptor, you won't be able to retrieve it (unless
it is only defined for interface #5).  If you use WinUSB on Windows to
validate your descriptors, our advice then is to have your device
firmware answer both Device and Interface requests when the Extended
Properties Feature Descriptor is queried, so that you can use a Device
Request rather than an Interface Request to validate that your
descriptor is set properly.

For reference, the latest xusb sample application from libusb has a -w
switch that will force the wIndex = 0x0005 to use the Device mode.


 > Fixes: ec6ce70 ("usb: gadget: composite: fix OS descriptors w_value logic")
 > Signed-off-by: Michal Vrastil <michal.vrastil@hidglobal.com>
 > ---
 >  drivers/usb/gadget/composite.c | 6 +++---
 >  1 file changed, 3 insertions(+), 3 deletions(-)

 > diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
 > index 17ae3b394469..a3106b179562 100644
 > --- a/drivers/usb/gadget/composite.c
 > +++ b/drivers/usb/gadget/composite.c
 > @@ -1925,7 +1925,7 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl)
 >  			buf[5] = 0x01;
 >  			switch (ctrl->bRequestType & USB_RECIP_MASK) {
 >  			case USB_RECIP_DEVICE:
 > -				if (w_index != 0x4 || (w_value & 0xff))
 > +				if (w_index != 0x4 || (w_value >> 8))
 >  					break;
 >  				buf[6] = w_index;
 >  				/* Number of ext compat interfaces */
 > @@ -1941,9 +1941,9 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl)
 >  				}
 >  				break;
 >  			case USB_RECIP_INTERFACE:
 > -				if (w_index != 0x5 || (w_value & 0xff))
 > +				if (w_index != 0x5 || (w_value >> 8))
 >  					break;
 > -				interface = w_value >> 8;
 > +				interface = w_value & 0xFF;
 >  				if (interface >= MAX_CONFIG_INTERFACES ||
 >  				    !os_desc_cfg->interface[interface])
 >  					break;
 > -- 

 > 2.43.0



-- 
Bye, Peter Korsgaard