[1/2] USB: gadget: f_hid: Add Get-Feature report

While the HID gadget implementation has been sufficient for devices that only
use INTERRUPT transfers, the USB HID standard includes provisions for Set- and
Get-Feature report CONTROL transfers that go over endpoint 0. These were
previously impossible with the existing implementation, and would either send
an empty reply, or stall out.

As the feature is a standard part of USB HID, it stands to reason that devices
would use it, and that the HID gadget should support it. This patch adds
support for (polled) device-to-host Get-Feature reports through a new ioctl
interface to the hidg class dev nodes.

Signed-off-by: Vicki Pfau <vi@endrift.com>
---
 drivers/usb/gadget/function/f_hid.c | 121 ++++++++++++++++++++++++++--
 include/uapi/linux/usb/g_hid.h      |  38 +++++++++
 include/uapi/linux/usb/gadgetfs.h   |   2 +-
 3 files changed, 154 insertions(+), 7 deletions(-)
 create mode 100644 include/uapi/linux/usb/g_hid.h

В Mon, 25 Jul 2022 17:58:26 -0700
Vicki Pfau <vi@endrift.com> пишет:

> While the HID gadget implementation has been sufficient for devices that only
> use INTERRUPT transfers, the USB HID standard includes provisions for Set- and
> Get-Feature report CONTROL transfers that go over endpoint 0. These were
> previously impossible with the existing implementation, and would either send
> an empty reply, or stall out.
> 
> As the feature is a standard part of USB HID, it stands to reason that devices
> would use it, and that the HID gadget should support it. This patch adds
> support for host-to-device Set-Feature reports through a new ioctl
> interface to the hidg class dev nodes.
> 
> Signed-off-by: Vicki Pfau <vi@endrift.com>

Won't it break the logic of the existing software that works with /dev/hidgX?
Will it work if I want my gadget to work the old way?
It is important that the old behavior is the default without having to use
the new ioctls. As for these ioctls, since this is an addition to the new API,
they should be documented. I think it's also worth adding these ioctls
to the userspace example:
  - Documentation/usb/gadget_hid.rst
  - Documentation/usb/gadget-testing.rst

But it seems to me that extending the HID functionality to meet
the specifications is definitely a good idea :)

On 7/26/22 02:51, Maxim Devaev wrote:
> В Mon, 25 Jul 2022 17:58:26 -0700
> Vicki Pfau <vi@endrift.com> пишет:
> 
>> While the HID gadget implementation has been sufficient for devices that only
>> use INTERRUPT transfers, the USB HID standard includes provisions for Set- and
>> Get-Feature report CONTROL transfers that go over endpoint 0. These were
>> previously impossible with the existing implementation, and would either send
>> an empty reply, or stall out.
>>
>> As the feature is a standard part of USB HID, it stands to reason that devices
>> would use it, and that the HID gadget should support it. This patch adds
>> support for host-to-device Set-Feature reports through a new ioctl
>> interface to the hidg class dev nodes.
>>
>> Signed-off-by: Vicki Pfau <vi@endrift.com>
> 
> Won't it break the logic of the existing software that works with /dev/hidgX?
> Will it work if I want my gadget to work the old way?

For existing software to use SET_FEATURE at all it has to use an alternative mode, which seems to have only been added somewhat recently. That mode also appears to preclude use of INTERRUPT transfers at all, unless there's some way to set up two hidg nodes that map to the same interface, with one for INTERRUPT and one for SET_FEATURE. If this breaks that, I suppose that's a regression, but this is meant to augment the original, long-standing mode so you can mix INTERRUPT and SET/GET_FEATURE transfers, as there is no way to do that yet. Honestly, the alternate mode seems more like a workaround, as far as I can tell, and not an ideal implementation. I'm not sure when it was added, but as I was originally authoring this against 5.13 and didn't see it until I went to rebase onto master, it can't have been that long ago. So if it breaks any software (which I don't believe it does), it would only affect very new software.

As I alluded to, I'd thought about perhaps adding a second node per interface so one would act as INTERRUPT transfers and the other as SET/GET_FEATURE transfers, but I already had this code half written and wanted to get feedback first, especially since what I have now works (although it's not well-tested after rebasing).

> It is important that the old behavior is the default without having to use
> the new ioctls. As for these ioctls, since this is an addition to the new API,
> they should be documented. I think it's also worth adding these ioctls
> to the userspace example:
>   - Documentation/usb/gadget_hid.rst
>   - Documentation/usb/gadget-testing.rst

Yup, I should probably do that. Forgot about that before sending the patch, though I'm hoping to be told if my approach was even worthwhile before I write that, but I can work on that soon either way.

> 
> But it seems to me that extending the HID functionality to meet
> the specifications is definitely a good idea :)

On Mon, Jul 25, 2022 at 05:58:25PM -0700, Vicki Pfau wrote:
> --- /dev/null
> +++ b/include/uapi/linux/usb/g_hid.h
> @@ -0,0 +1,38 @@
> +/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
> +/*
> + * g_hid.h -- Header file for USB HID gadget driver
> + *
> + * Copyright (C) 2022 Valve Software
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

This whole license "boilerplate" is not needed, and should be removed
(especially things like addresses, that's crazy).

Only thing that is needed is the SPDX line.

> + */
> +
> +#ifndef __UAPI_LINUX_USB_G_HID_H
> +#define __UAPI_LINUX_USB_G_HID_H
> +
> +#include <linux/types.h>
> +
> +struct usb_hidg_report {
> +	__u16 length;
> +	__u8 data[512];

Why 512?

> +};
> +
> +/* The 'g' code is also used by gadgetfs and hid gadget ioctl requests.
> + * Don't add any colliding codes to either driver, and keep
> + * them in unique ranges (size 0x20 for now).
> + */
> +#define GADGET_HID_WRITE_GET_REPORT	_IOW('g', 0x42, struct usb_hidg_report)

This should be in the same .h file so that we don't get confused and
accidentally use the same ioctl.

> +
> +#endif /* __UAPI_LINUX_USB_G_HID_H */
> diff --git a/include/uapi/linux/usb/gadgetfs.h b/include/uapi/linux/usb/gadgetfs.h
> index 835473910a49..9754822b2a40 100644
> --- a/include/uapi/linux/usb/gadgetfs.h
> +++ b/include/uapi/linux/usb/gadgetfs.h
> @@ -62,7 +62,7 @@ struct usb_gadgetfs_event {
>  };
>  
>  
> -/* The 'g' code is also used by printer gadget ioctl requests.
> +/* The 'g' code is also used by printer and hid gadget ioctl requests.

Yeah, put the definition here.

thanks,

greg k-h

В Tue, 26 Jul 2022 21:26:05 -0700
Vicki Pfau <vi@endrift.com> пишет:

> On 7/26/22 02:51, Maxim Devaev wrote:
> > В Mon, 25 Jul 2022 17:58:26 -0700
> > Vicki Pfau <vi@endrift.com> пишет:
> >   
> >> While the HID gadget implementation has been sufficient for devices that only
> >> use INTERRUPT transfers, the USB HID standard includes provisions for Set- and
> >> Get-Feature report CONTROL transfers that go over endpoint 0. These were
> >> previously impossible with the existing implementation, and would either send
> >> an empty reply, or stall out.
> >>
> >> As the feature is a standard part of USB HID, it stands to reason that devices
> >> would use it, and that the HID gadget should support it. This patch adds
> >> support for host-to-device Set-Feature reports through a new ioctl
> >> interface to the hidg class dev nodes.
> >>
> >> Signed-off-by: Vicki Pfau <vi@endrift.com>  
> > 
> > Won't it break the logic of the existing software that works with /dev/hidgX?
> > Will it work if I want my gadget to work the old way?  
> 
> For existing software to use SET_FEATURE at all it has to use an alternative mode, which seems to have only been added somewhat recently. That mode also appears to preclude use of INTERRUPT transfers at all, unless there's some way to set up two hidg nodes that map to the same interface, with one for INTERRUPT and one for SET_FEATURE. If this breaks that, I suppose that's a regression, but this is meant to augment the original, long-standing mode so you can mix INTERRUPT and SET/GET_FEATURE transfers, as there is no way to do that yet. Honestly, the alternate mode seems more like a workaround, as far as I can tell, and not an ideal implementation. I'm not sure when it was added, but as I was originally authoring this against 5.13 and didn't see it until I went to rebase onto master, it can't have been that long ago. So if it breaks any software (which I don't believe it does), it would only affect very new software.
> 
> As I alluded to, I'd thought about perhaps adding a second node per interface so one would act as INTERRUPT transfers and the other as SET/GET_FEATURE transfers, but I already had this code half written and wanted to get feedback first, especially since what I have now works (although it's not well-tested after rebasing).

I'm a little confused here about what you call an alternative mode.
Are we talking about use_out_ep=1 (default behavior with INTERRUPT)
or use_out_ep=0 (SETUP/SET_REPORT)? The last mode was added by me
to ensure strict compatibility with Apple UEFI and strange BIOS,
and this mode is actually actively used. It is important to me
that it is not broken, but unfortunately I cannot test your patch
on my kernel, as I temporarily do not have access to testing equipment.

On 7/28/22 01:08, Greg Kroah-Hartman wrote:
> On Mon, Jul 25, 2022 at 05:58:25PM -0700, Vicki Pfau wrote:
>> --- /dev/null
>> +++ b/include/uapi/linux/usb/g_hid.h
>> @@ -0,0 +1,38 @@
>> +/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
>> +/*
>> + * g_hid.h -- Header file for USB HID gadget driver
>> + *
>> + * Copyright (C) 2022 Valve Software
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> 
> This whole license "boilerplate" is not needed, and should be removed
> (especially things like addresses, that's crazy).
> 
> Only thing that is needed is the SPDX line.

I was just copying the header from g_printer.h and changing as needed. It hasn't been touched since 2017, so if that's no longer the convention you might want to update it too.

> 
>> + */
>> +
>> +#ifndef __UAPI_LINUX_USB_G_HID_H
>> +#define __UAPI_LINUX_USB_G_HID_H
>> +
>> +#include <linux/types.h>
>> +
>> +struct usb_hidg_report {
>> +	__u16 length;
>> +	__u8 data[512];
> 
> Why 512?

I was reading the specs and one of them said the maximum report length for USB 3 (I believe) was 512 bytes (in contrast with USB 2's 64). I can try to find where it said this, or add a define for max report length.

> 
>> +};
>> +
>> +/* The 'g' code is also used by gadgetfs and hid gadget ioctl requests.
>> + * Don't add any colliding codes to either driver, and keep
>> + * them in unique ranges (size 0x20 for now).
>> + */
>> +#define GADGET_HID_WRITE_GET_REPORT	_IOW('g', 0x42, struct usb_hidg_report)
> 
> This should be in the same .h file so that we don't get confused and
> accidentally use the same ioctl.

The same .h file as which? g_printer.h and gadgetfs.h are separate files.

> 
>> +
>> +#endif /* __UAPI_LINUX_USB_G_HID_H */
>> diff --git a/include/uapi/linux/usb/gadgetfs.h b/include/uapi/linux/usb/gadgetfs.h
>> index 835473910a49..9754822b2a40 100644
>> --- a/include/uapi/linux/usb/gadgetfs.h
>> +++ b/include/uapi/linux/usb/gadgetfs.h
>> @@ -62,7 +62,7 @@ struct usb_gadgetfs_event {
>>  };
>>  
>>  
>> -/* The 'g' code is also used by printer gadget ioctl requests.
>> +/* The 'g' code is also used by printer and hid gadget ioctl requests.
> 
> Yeah, put the definition here.

Should I move the g_printer.h definitions here at the same time? Maybe stub out g_printer.h and make it include gadgetfs.h?

> 
> thanks,
> 
> greg k-h

On 7/28/22 01:59, Maxim Devaev wrote:
> В Tue, 26 Jul 2022 21:26:05 -0700
> Vicki Pfau <vi@endrift.com> пишет:
> 
>> On 7/26/22 02:51, Maxim Devaev wrote:
>>> В Mon, 25 Jul 2022 17:58:26 -0700
>>> Vicki Pfau <vi@endrift.com> пишет:
>>>   
>>>> While the HID gadget implementation has been sufficient for devices that only
>>>> use INTERRUPT transfers, the USB HID standard includes provisions for Set- and
>>>> Get-Feature report CONTROL transfers that go over endpoint 0. These were
>>>> previously impossible with the existing implementation, and would either send
>>>> an empty reply, or stall out.
>>>>
>>>> As the feature is a standard part of USB HID, it stands to reason that devices
>>>> would use it, and that the HID gadget should support it. This patch adds
>>>> support for host-to-device Set-Feature reports through a new ioctl
>>>> interface to the hidg class dev nodes.
>>>>
>>>> Signed-off-by: Vicki Pfau <vi@endrift.com>  
>>>
>>> Won't it break the logic of the existing software that works with /dev/hidgX?
>>> Will it work if I want my gadget to work the old way?  
>>
>> For existing software to use SET_FEATURE at all it has to use an alternative mode, which seems to have only been added somewhat recently. That mode also appears to preclude use of INTERRUPT transfers at all, unless there's some way to set up two hidg nodes that map to the same interface, with one for INTERRUPT and one for SET_FEATURE. If this breaks that, I suppose that's a regression, but this is meant to augment the original, long-standing mode so you can mix INTERRUPT and SET/GET_FEATURE transfers, as there is no way to do that yet. Honestly, the alternate mode seems more like a workaround, as far as I can tell, and not an ideal implementation. I'm not sure when it was added, but as I was originally authoring this against 5.13 and didn't see it until I went to rebase onto master, it can't have been that long ago. So if it breaks any software (which I don't believe it does), it would only affect very new software.
>>
>> As I alluded to, I'd thought about perhaps adding a second node per interface so one would act as INTERRUPT transfers and the other as SET/GET_FEATURE transfers, but I already had this code half written and wanted to get feedback first, especially since what I have now works (although it's not well-tested after rebasing).
> 
> I'm a little confused here about what you call an alternative mode.
> Are we talking about use_out_ep=1 (default behavior with INTERRUPT)
> or use_out_ep=0 (SETUP/SET_REPORT)? The last mode was added by me
> to ensure strict compatibility with Apple UEFI and strange BIOS,
> and this mode is actually actively used. It is important to me
> that it is not broken, but unfortunately I cannot test your patch
> on my kernel, as I temporarily do not have access to testing equipment.

use_out_ep=0 is the alternate mode I was talking about. It didn't exist in 5.13, so as I said I wasn't aware of it until I rebased. As the device I'm using is still stuck on that old kernel (for now) and I don't know if I have any USB gadget capable devices on new kernels, I was unable to test it, and would very much like to make sure it doesn't regress before a patch is merged. I wasn't intending to break it, but I figured I'd get feedback I'd need to change before this was merged so if you could test it to ensure it doesn't regress any behavior that would be much appreciated and help me out. I will probably wait until then before submitting a v2.

On Thu, Jul 28, 2022 at 11:07:20AM -0700, Vicki Pfau wrote:
> 
> 
> On 7/28/22 01:08, Greg Kroah-Hartman wrote:
> > On Mon, Jul 25, 2022 at 05:58:25PM -0700, Vicki Pfau wrote:
> >> --- /dev/null
> >> +++ b/include/uapi/linux/usb/g_hid.h
> >> @@ -0,0 +1,38 @@
> >> +/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
> >> +/*
> >> + * g_hid.h -- Header file for USB HID gadget driver
> >> + *
> >> + * Copyright (C) 2022 Valve Software
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License as published by
> >> + * the Free Software Foundation; either version 2 of the License, or
> >> + * (at your option) any later version.
> >> + *
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >> + * GNU General Public License for more details.
> >> + *
> >> + * You should have received a copy of the GNU General Public License
> >> + * along with this program; if not, write to the Free Software
> >> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> > 
> > This whole license "boilerplate" is not needed, and should be removed
> > (especially things like addresses, that's crazy).
> > 
> > Only thing that is needed is the SPDX line.
> 
> I was just copying the header from g_printer.h and changing as needed. It hasn't been touched since 2017, so if that's no longer the convention you might want to update it too.

Good point, I will look into that.

> >> + */
> >> +
> >> +#ifndef __UAPI_LINUX_USB_G_HID_H
> >> +#define __UAPI_LINUX_USB_G_HID_H
> >> +
> >> +#include <linux/types.h>
> >> +
> >> +struct usb_hidg_report {
> >> +	__u16 length;
> >> +	__u8 data[512];
> > 
> > Why 512?
> 
> I was reading the specs and one of them said the maximum report length for USB 3 (I believe) was 512 bytes (in contrast with USB 2's 64). I can try to find where it said this, or add a define for max report length.

Either is fine, magic values like this should always be documented
somehow.

> >> +};
> >> +
> >> +/* The 'g' code is also used by gadgetfs and hid gadget ioctl requests.
> >> + * Don't add any colliding codes to either driver, and keep
> >> + * them in unique ranges (size 0x20 for now).
> >> + */
> >> +#define GADGET_HID_WRITE_GET_REPORT	_IOW('g', 0x42, struct usb_hidg_report)
> > 
> > This should be in the same .h file so that we don't get confused and
> > accidentally use the same ioctl.
> 
> The same .h file as which? g_printer.h and gadgetfs.h are separate files.

Whatever the uapi .h file is, should have the list of ioctls, not
scattered around the core kernel files.

> 
> > 
> >> +
> >> +#endif /* __UAPI_LINUX_USB_G_HID_H */
> >> diff --git a/include/uapi/linux/usb/gadgetfs.h b/include/uapi/linux/usb/gadgetfs.h
> >> index 835473910a49..9754822b2a40 100644
> >> --- a/include/uapi/linux/usb/gadgetfs.h
> >> +++ b/include/uapi/linux/usb/gadgetfs.h
> >> @@ -62,7 +62,7 @@ struct usb_gadgetfs_event {
> >>  };
> >>  
> >>  
> >> -/* The 'g' code is also used by printer gadget ioctl requests.
> >> +/* The 'g' code is also used by printer and hid gadget ioctl requests.
> > 
> > Yeah, put the definition here.
> 
> Should I move the g_printer.h definitions here at the same time? Maybe stub out g_printer.h and make it include gadgetfs.h?

Move them in the first patch in the series would be great.  And no need
for stubbed out .h file, that's not needed for internal .h files.

thanks,

greg k-h

On 7/29/22 00:47, Greg Kroah-Hartman wrote:
> On Thu, Jul 28, 2022 at 11:07:20AM -0700, Vicki Pfau wrote:
>>
>>
>> On 7/28/22 01:08, Greg Kroah-Hartman wrote:
>>> On Mon, Jul 25, 2022 at 05:58:25PM -0700, Vicki Pfau wrote:
>>>> --- /dev/null
>>>> +++ b/include/uapi/linux/usb/g_hid.h
>>>> @@ -0,0 +1,38 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
>>>> +/*
>>>> + * g_hid.h -- Header file for USB HID gadget driver
>>>> + *
>>>> + * Copyright (C) 2022 Valve Software
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify
>>>> + * it under the terms of the GNU General Public License as published by
>>>> + * the Free Software Foundation; either version 2 of the License, or
>>>> + * (at your option) any later version.
>>>> + *
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>>> + * GNU General Public License for more details.
>>>> + *
>>>> + * You should have received a copy of the GNU General Public License
>>>> + * along with this program; if not, write to the Free Software
>>>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>>>
>>> This whole license "boilerplate" is not needed, and should be removed
>>> (especially things like addresses, that's crazy).
>>>
>>> Only thing that is needed is the SPDX line.
>>
>> I was just copying the header from g_printer.h and changing as needed. It hasn't been touched since 2017, so if that's no longer the convention you might want to update it too.
> 
> Good point, I will look into that.
> 
>>>> + */
>>>> +
>>>> +#ifndef __UAPI_LINUX_USB_G_HID_H
>>>> +#define __UAPI_LINUX_USB_G_HID_H
>>>> +
>>>> +#include <linux/types.h>
>>>> +
>>>> +struct usb_hidg_report {
>>>> +	__u16 length;
>>>> +	__u8 data[512];
>>>
>>> Why 512?
>>
>> I was reading the specs and one of them said the maximum report length for USB 3 (I believe) was 512 bytes (in contrast with USB 2's 64). I can try to find where it said this, or add a define for max report length.
> 
> Either is fine, magic values like this should always be documented
> somehow.
> 

I can't actually find where this is specified anymore, so I'm going to bump it down to 64 (as defined by bMaxPacketSize0 in the HID 1.11 spec) and define it as a constant.

>>>> +};
>>>> +
>>>> +/* The 'g' code is also used by gadgetfs and hid gadget ioctl requests.
>>>> + * Don't add any colliding codes to either driver, and keep
>>>> + * them in unique ranges (size 0x20 for now).
>>>> + */
>>>> +#define GADGET_HID_WRITE_GET_REPORT	_IOW('g', 0x42, struct usb_hidg_report)
>>>
>>> This should be in the same .h file so that we don't get confused and
>>> accidentally use the same ioctl.
>>
>> The same .h file as which? g_printer.h and gadgetfs.h are separate files.
> 
> Whatever the uapi .h file is, should have the list of ioctls, not
> scattered around the core kernel files.

There are three uapi .h files in quesiton: gadgetfs.h, g_printer.h and (now the new) g_hid.h. These all have distinct purposes and there's no natural "here are the ioctls for USB gadgets" file. I could make a gadget.h or g_ioctl.h file and move all the ioctls there, but that would still involve a new file (and possibly including it in the existing gadgetfs.h and g_printer.h files to maintain API compat).

> 
>>
>>>
>>>> +
>>>> +#endif /* __UAPI_LINUX_USB_G_HID_H */
>>>> diff --git a/include/uapi/linux/usb/gadgetfs.h b/include/uapi/linux/usb/gadgetfs.h
>>>> index 835473910a49..9754822b2a40 100644
>>>> --- a/include/uapi/linux/usb/gadgetfs.h
>>>> +++ b/include/uapi/linux/usb/gadgetfs.h
>>>> @@ -62,7 +62,7 @@ struct usb_gadgetfs_event {
>>>>  };
>>>>  
>>>>  
>>>> -/* The 'g' code is also used by printer gadget ioctl requests.
>>>> +/* The 'g' code is also used by printer and hid gadget ioctl requests.
>>>
>>> Yeah, put the definition here.
>>
>> Should I move the g_printer.h definitions here at the same time? Maybe stub out g_printer.h and make it include gadgetfs.h?
> 
> Move them in the first patch in the series would be great.  And no need
> for stubbed out .h file, that's not needed for internal .h files.

Is this internal? It's in the uapi so it's public to the kernel itself. Removing, e.g., g_printer.h if it was emptied out (though it looks like it'd still have two defines in it if the ioctls were moved) would break API compat and existing software would need to fix their code. Obviously it doesn't break ABI so maybe that's acceptable.

> 
> thanks,
> 
> greg k-h

В Thu, 28 Jul 2022 11:11:31 -0700
Vicki Pfau <vi@endrift.com> пишет:

> On 7/28/22 01:59, Maxim Devaev wrote:
> > В Tue, 26 Jul 2022 21:26:05 -0700
> > Vicki Pfau <vi@endrift.com> пишет:
> >   
> >> On 7/26/22 02:51, Maxim Devaev wrote:  
> >>> В Mon, 25 Jul 2022 17:58:26 -0700
> >>> Vicki Pfau <vi@endrift.com> пишет:
> >>>     
> >>>> While the HID gadget implementation has been sufficient for devices that only
> >>>> use INTERRUPT transfers, the USB HID standard includes provisions for Set- and
> >>>> Get-Feature report CONTROL transfers that go over endpoint 0. These were
> >>>> previously impossible with the existing implementation, and would either send
> >>>> an empty reply, or stall out.
> >>>>
> >>>> As the feature is a standard part of USB HID, it stands to reason that devices
> >>>> would use it, and that the HID gadget should support it. This patch adds
> >>>> support for host-to-device Set-Feature reports through a new ioctl
> >>>> interface to the hidg class dev nodes.
> >>>>
> >>>> Signed-off-by: Vicki Pfau <vi@endrift.com>    
> >>>
> >>> Won't it break the logic of the existing software that works with /dev/hidgX?
> >>> Will it work if I want my gadget to work the old way?    
> >>
> >> For existing software to use SET_FEATURE at all it has to use an alternative mode, which seems to have only been added somewhat recently. That mode also appears to preclude use of INTERRUPT transfers at all, unless there's some way to set up two hidg nodes that map to the same interface, with one for INTERRUPT and one for SET_FEATURE. If this breaks that, I suppose that's a regression, but this is meant to augment the original, long-standing mode so you can mix INTERRUPT and SET/GET_FEATURE transfers, as there is no way to do that yet. Honestly, the alternate mode seems more like a workaround, as far as I can tell, and not an ideal implementation. I'm not sure when it was added, but as I was originally authoring this against 5.13 and didn't see it until I went to rebase onto master, it can't have been that long ago. So if it breaks any software (which I don't believe it does), it would only affect very new software.
> >>
> >> As I alluded to, I'd thought about perhaps adding a second node per interface so one would act as INTERRUPT transfers and the other as SET/GET_FEATURE transfers, but I already had this code half written and wanted to get feedback first, especially since what I have now works (although it's not well-tested after rebasing).  
> > 
> > I'm a little confused here about what you call an alternative mode.
> > Are we talking about use_out_ep=1 (default behavior with INTERRUPT)
> > or use_out_ep=0 (SETUP/SET_REPORT)? The last mode was added by me
> > to ensure strict compatibility with Apple UEFI and strange BIOS,
> > and this mode is actually actively used. It is important to me
> > that it is not broken, but unfortunately I cannot test your patch
> > on my kernel, as I temporarily do not have access to testing equipment.  
> 
> use_out_ep=0 is the alternate mode I was talking about. It didn't exist in 5.13, so as I said I wasn't aware of it until I rebased. As the device I'm using is still stuck on that old kernel (for now) and I don't know if I have any USB gadget capable devices on new kernels, I was unable to test it, and would very much like to make sure it doesn't regress before a patch is merged. I wasn't intending to break it, but I figured I'd get feedback I'd need to change before this was merged so if you could test it to ensure it doesn't regress any behavior that would be much appreciated and help me out. I will probably wait until then before submitting a v2.

I will get access to the USB analyzer and test environment in about a month,
if that suits you. You can write directly to my email after a month,
I will help you with testing.

On 7/31/22 01:14, Maxim Devaev wrote:
> В Thu, 28 Jul 2022 11:11:31 -0700
> Vicki Pfau <vi@endrift.com> пишет:
> 
>> On 7/28/22 01:59, Maxim Devaev wrote:
>>> В Tue, 26 Jul 2022 21:26:05 -0700
>>> Vicki Pfau <vi@endrift.com> пишет:
>>>   
>>>> On 7/26/22 02:51, Maxim Devaev wrote:  
>>>>> В Mon, 25 Jul 2022 17:58:26 -0700
>>>>> Vicki Pfau <vi@endrift.com> пишет:
>>>>>     
>>>>>> While the HID gadget implementation has been sufficient for devices that only
>>>>>> use INTERRUPT transfers, the USB HID standard includes provisions for Set- and
>>>>>> Get-Feature report CONTROL transfers that go over endpoint 0. These were
>>>>>> previously impossible with the existing implementation, and would either send
>>>>>> an empty reply, or stall out.
>>>>>>
>>>>>> As the feature is a standard part of USB HID, it stands to reason that devices
>>>>>> would use it, and that the HID gadget should support it. This patch adds
>>>>>> support for host-to-device Set-Feature reports through a new ioctl
>>>>>> interface to the hidg class dev nodes.
>>>>>>
>>>>>> Signed-off-by: Vicki Pfau <vi@endrift.com>    
>>>>>
>>>>> Won't it break the logic of the existing software that works with /dev/hidgX?
>>>>> Will it work if I want my gadget to work the old way?    
>>>>
>>>> For existing software to use SET_FEATURE at all it has to use an alternative mode, which seems to have only been added somewhat recently. That mode also appears to preclude use of INTERRUPT transfers at all, unless there's some way to set up two hidg nodes that map to the same interface, with one for INTERRUPT and one for SET_FEATURE. If this breaks that, I suppose that's a regression, but this is meant to augment the original, long-standing mode so you can mix INTERRUPT and SET/GET_FEATURE transfers, as there is no way to do that yet. Honestly, the alternate mode seems more like a workaround, as far as I can tell, and not an ideal implementation. I'm not sure when it was added, but as I was originally authoring this against 5.13 and didn't see it until I went to rebase onto master, it can't have been that long ago. So if it breaks any software (which I don't believe it does), it would only affect very new software.
>>>>
>>>> As I alluded to, I'd thought about perhaps adding a second node per interface so one would act as INTERRUPT transfers and the other as SET/GET_FEATURE transfers, but I already had this code half written and wanted to get feedback first, especially since what I have now works (although it's not well-tested after rebasing).  
>>>
>>> I'm a little confused here about what you call an alternative mode.
>>> Are we talking about use_out_ep=1 (default behavior with INTERRUPT)
>>> or use_out_ep=0 (SETUP/SET_REPORT)? The last mode was added by me
>>> to ensure strict compatibility with Apple UEFI and strange BIOS,
>>> and this mode is actually actively used. It is important to me
>>> that it is not broken, but unfortunately I cannot test your patch
>>> on my kernel, as I temporarily do not have access to testing equipment.  
>>
>> use_out_ep=0 is the alternate mode I was talking about. It didn't exist in 5.13, so as I said I wasn't aware of it until I rebased. As the device I'm using is still stuck on that old kernel (for now) and I don't know if I have any USB gadget capable devices on new kernels, I was unable to test it, and would very much like to make sure it doesn't regress before a patch is merged. I wasn't intending to break it, but I figured I'd get feedback I'd need to change before this was merged so if you could test it to ensure it doesn't regress any behavior that would be much appreciated and help me out. I will probably wait until then before submitting a v2.
> 
> I will get access to the USB analyzer and test environment in about a month,
> if that suits you. You can write directly to my email after a month,
> I will help you with testing.

I'm not in a huge rush, though I might try to find some hardware I can test a modern kernel on to help test. What are you running the kernel on?

Hi,

On 7/31/22 01:14, Maxim Devaev wrote:
> В Thu, 28 Jul 2022 11:11:31 -0700
> Vicki Pfau <vi@endrift.com> пишет:
> 
>> On 7/28/22 01:59, Maxim Devaev wrote:
>>> В Tue, 26 Jul 2022 21:26:05 -0700
>>> Vicki Pfau <vi@endrift.com> пишет:
>>>   
>>>> On 7/26/22 02:51, Maxim Devaev wrote:  
>>>>> В Mon, 25 Jul 2022 17:58:26 -0700
>>>>> Vicki Pfau <vi@endrift.com> пишет:
>>>>>     
>>>>>> While the HID gadget implementation has been sufficient for devices that only
>>>>>> use INTERRUPT transfers, the USB HID standard includes provisions for Set- and
>>>>>> Get-Feature report CONTROL transfers that go over endpoint 0. These were
>>>>>> previously impossible with the existing implementation, and would either send
>>>>>> an empty reply, or stall out.
>>>>>>
>>>>>> As the feature is a standard part of USB HID, it stands to reason that devices
>>>>>> would use it, and that the HID gadget should support it. This patch adds
>>>>>> support for host-to-device Set-Feature reports through a new ioctl
>>>>>> interface to the hidg class dev nodes.
>>>>>>
>>>>>> Signed-off-by: Vicki Pfau <vi@endrift.com>    
>>>>>
>>>>> Won't it break the logic of the existing software that works with /dev/hidgX?
>>>>> Will it work if I want my gadget to work the old way?    
>>>>
>>>> For existing software to use SET_FEATURE at all it has to use an alternative mode, which seems to have only been added somewhat recently. That mode also appears to preclude use of INTERRUPT transfers at all, unless there's some way to set up two hidg nodes that map to the same interface, with one for INTERRUPT and one for SET_FEATURE. If this breaks that, I suppose that's a regression, but this is meant to augment the original, long-standing mode so you can mix INTERRUPT and SET/GET_FEATURE transfers, as there is no way to do that yet. Honestly, the alternate mode seems more like a workaround, as far as I can tell, and not an ideal implementation. I'm not sure when it was added, but as I was originally authoring this against 5.13 and didn't see it until I went to rebase onto master, it can't have been that long ago. So if it breaks any software (which I don't believe it does), it would only affect very new software.
>>>>
>>>> As I alluded to, I'd thought about perhaps adding a second node per interface so one would act as INTERRUPT transfers and the other as SET/GET_FEATURE transfers, but I already had this code half written and wanted to get feedback first, especially since what I have now works (although it's not well-tested after rebasing).  
>>>
>>> I'm a little confused here about what you call an alternative mode.
>>> Are we talking about use_out_ep=1 (default behavior with INTERRUPT)
>>> or use_out_ep=0 (SETUP/SET_REPORT)? The last mode was added by me
>>> to ensure strict compatibility with Apple UEFI and strange BIOS,
>>> and this mode is actually actively used. It is important to me
>>> that it is not broken, but unfortunately I cannot test your patch
>>> on my kernel, as I temporarily do not have access to testing equipment.  
>>
>> use_out_ep=0 is the alternate mode I was talking about. It didn't exist in 5.13, so as I said I wasn't aware of it until I rebased. As the device I'm using is still stuck on that old kernel (for now) and I don't know if I have any USB gadget capable devices on new kernels, I was unable to test it, and would very much like to make sure it doesn't regress before a patch is merged. I wasn't intending to break it, but I figured I'd get feedback I'd need to change before this was merged so if you could test it to ensure it doesn't regress any behavior that would be much appreciated and help me out. I will probably wait until then before submitting a v2.
> 
> I will get access to the USB analyzer and test environment in about a month,
> if that suits you. You can write directly to my email after a month,
> I will help you with testing.

I wanted to check the status of this. We're in the middle of rebasing onto a newer kernel, so I might be able to test it myself soon. What software are you using?

В Thu, 8 Sep 2022 16:57:36 -0700
Vicki Pfau <vi@endrift.com> пишет:

> Hi,
> 
> On 7/31/22 01:14, Maxim Devaev wrote:
> > В Thu, 28 Jul 2022 11:11:31 -0700
> > Vicki Pfau <vi@endrift.com> пишет:
> >   
> >> On 7/28/22 01:59, Maxim Devaev wrote:  
> >>> В Tue, 26 Jul 2022 21:26:05 -0700
> >>> Vicki Pfau <vi@endrift.com> пишет:
> >>>     
> >>>> On 7/26/22 02:51, Maxim Devaev wrote:    
> >>>>> В Mon, 25 Jul 2022 17:58:26 -0700
> >>>>> Vicki Pfau <vi@endrift.com> пишет:
> >>>>>       
> >>>>>> While the HID gadget implementation has been sufficient for devices that only
> >>>>>> use INTERRUPT transfers, the USB HID standard includes provisions for Set- and
> >>>>>> Get-Feature report CONTROL transfers that go over endpoint 0. These were
> >>>>>> previously impossible with the existing implementation, and would either send
> >>>>>> an empty reply, or stall out.
> >>>>>>
> >>>>>> As the feature is a standard part of USB HID, it stands to reason that devices
> >>>>>> would use it, and that the HID gadget should support it. This patch adds
> >>>>>> support for host-to-device Set-Feature reports through a new ioctl
> >>>>>> interface to the hidg class dev nodes.
> >>>>>>
> >>>>>> Signed-off-by: Vicki Pfau <vi@endrift.com>      
> >>>>>
> >>>>> Won't it break the logic of the existing software that works with /dev/hidgX?
> >>>>> Will it work if I want my gadget to work the old way?      
> >>>>
> >>>> For existing software to use SET_FEATURE at all it has to use an alternative mode, which seems to have only been added somewhat recently. That mode also appears to preclude use of INTERRUPT transfers at all, unless there's some way to set up two hidg nodes that map to the same interface, with one for INTERRUPT and one for SET_FEATURE. If this breaks that, I suppose that's a regression, but this is meant to augment the original, long-standing mode so you can mix INTERRUPT and SET/GET_FEATURE transfers, as there is no way to do that yet. Honestly, the alternate mode seems more like a workaround, as far as I can tell, and not an ideal implementation. I'm not sure when it was added, but as I was originally authoring this against 5.13 and didn't see it until I went to rebase onto master, it can't have been that long ago. So if it breaks any software (which I don't believe it does), it would only affect very new software.
> >>>>
> >>>> As I alluded to, I'd thought about perhaps adding a second node per interface so one would act as INTERRUPT transfers and the other as SET/GET_FEATURE transfers, but I already had this code half written and wanted to get feedback first, especially since what I have now works (although it's not well-tested after rebasing).    
> >>>
> >>> I'm a little confused here about what you call an alternative mode.
> >>> Are we talking about use_out_ep=1 (default behavior with INTERRUPT)
> >>> or use_out_ep=0 (SETUP/SET_REPORT)? The last mode was added by me
> >>> to ensure strict compatibility with Apple UEFI and strange BIOS,
> >>> and this mode is actually actively used. It is important to me
> >>> that it is not broken, but unfortunately I cannot test your patch
> >>> on my kernel, as I temporarily do not have access to testing equipment.    
> >>
> >> use_out_ep=0 is the alternate mode I was talking about. It didn't exist in 5.13, so as I said I wasn't aware of it until I rebased. As the device I'm using is still stuck on that old kernel (for now) and I don't know if I have any USB gadget capable devices on new kernels, I was unable to test it, and would very much like to make sure it doesn't regress before a patch is merged. I wasn't intending to break it, but I figured I'd get feedback I'd need to change before this was merged so if you could test it to ensure it doesn't regress any behavior that would be much appreciated and help me out. I will probably wait until then before submitting a v2.  
> > 
> > I will get access to the USB analyzer and test environment in about a month,
> > if that suits you. You can write directly to my email after a month,
> > I will help you with testing.  
> 
> I wanted to check the status of this. We're in the middle of rebasing onto a newer kernel, so I might be able to test it myself soon. What software are you using?

I'm using PiKVM on Raspberry Pi 4 (https://github.com/pikvm/pikvm) but for generic testing you need to make
the usual ways of using gadget work in both modes: https://www.isticktoit.net/?p=1383
Unfortunately, I'm still away and I can't use my equipment :/

On 9/13/22 03:06, Maxim Devaev wrote:
> В Thu, 8 Sep 2022 16:57:36 -0700
> Vicki Pfau <vi@endrift.com> пишет:
> 
>> Hi,
>>
>> On 7/31/22 01:14, Maxim Devaev wrote:
>>> В Thu, 28 Jul 2022 11:11:31 -0700
>>> Vicki Pfau <vi@endrift.com> пишет:
>>>   
>>>> On 7/28/22 01:59, Maxim Devaev wrote:  
>>>>> В Tue, 26 Jul 2022 21:26:05 -0700
>>>>> Vicki Pfau <vi@endrift.com> пишет:
>>>>>     
>>>>>> On 7/26/22 02:51, Maxim Devaev wrote:    
>>>>>>> В Mon, 25 Jul 2022 17:58:26 -0700
>>>>>>> Vicki Pfau <vi@endrift.com> пишет:
>>>>>>>       
>>>>>>>> While the HID gadget implementation has been sufficient for devices that only
>>>>>>>> use INTERRUPT transfers, the USB HID standard includes provisions for Set- and
>>>>>>>> Get-Feature report CONTROL transfers that go over endpoint 0. These were
>>>>>>>> previously impossible with the existing implementation, and would either send
>>>>>>>> an empty reply, or stall out.
>>>>>>>>
>>>>>>>> As the feature is a standard part of USB HID, it stands to reason that devices
>>>>>>>> would use it, and that the HID gadget should support it. This patch adds
>>>>>>>> support for host-to-device Set-Feature reports through a new ioctl
>>>>>>>> interface to the hidg class dev nodes.
>>>>>>>>
>>>>>>>> Signed-off-by: Vicki Pfau <vi@endrift.com>      
>>>>>>>
>>>>>>> Won't it break the logic of the existing software that works with /dev/hidgX?
>>>>>>> Will it work if I want my gadget to work the old way?      
>>>>>>
>>>>>> For existing software to use SET_FEATURE at all it has to use an alternative mode, which seems to have only been added somewhat recently. That mode also appears to preclude use of INTERRUPT transfers at all, unless there's some way to set up two hidg nodes that map to the same interface, with one for INTERRUPT and one for SET_FEATURE. If this breaks that, I suppose that's a regression, but this is meant to augment the original, long-standing mode so you can mix INTERRUPT and SET/GET_FEATURE transfers, as there is no way to do that yet. Honestly, the alternate mode seems more like a workaround, as far as I can tell, and not an ideal implementation. I'm not sure when it was added, but as I was originally authoring this against 5.13 and didn't see it until I went to rebase onto master, it can't have been that long ago. So if it breaks any software (which I don't believe it does), it would only affect very new software.
>>>>>>
>>>>>> As I alluded to, I'd thought about perhaps adding a second node per interface so one would act as INTERRUPT transfers and the other as SET/GET_FEATURE transfers, but I already had this code half written and wanted to get feedback first, especially since what I have now works (although it's not well-tested after rebasing).    
>>>>>
>>>>> I'm a little confused here about what you call an alternative mode.
>>>>> Are we talking about use_out_ep=1 (default behavior with INTERRUPT)
>>>>> or use_out_ep=0 (SETUP/SET_REPORT)? The last mode was added by me
>>>>> to ensure strict compatibility with Apple UEFI and strange BIOS,
>>>>> and this mode is actually actively used. It is important to me
>>>>> that it is not broken, but unfortunately I cannot test your patch
>>>>> on my kernel, as I temporarily do not have access to testing equipment.    
>>>>
>>>> use_out_ep=0 is the alternate mode I was talking about. It didn't exist in 5.13, so as I said I wasn't aware of it until I rebased. As the device I'm using is still stuck on that old kernel (for now) and I don't know if I have any USB gadget capable devices on new kernels, I was unable to test it, and would very much like to make sure it doesn't regress before a patch is merged. I wasn't intending to break it, but I figured I'd get feedback I'd need to change before this was merged so if you could test it to ensure it doesn't regress any behavior that would be much appreciated and help me out. I will probably wait until then before submitting a v2.  
>>>
>>> I will get access to the USB analyzer and test environment in about a month,
>>> if that suits you. You can write directly to my email after a month,
>>> I will help you with testing.  
>>
>> I wanted to check the status of this. We're in the middle of rebasing onto a newer kernel, so I might be able to test it myself soon. What software are you using?
> 
> I'm using PiKVM on Raspberry Pi 4 (https://github.com/pikvm/pikvm) but for generic testing you need to make
> the usual ways of using gadget work in both modes: https://www.isticktoit.net/?p=1383
> Unfortunately, I'm still away and I can't use my equipment :/

I finally got a chance to test on 6.0, and I can confirm that it doesn't break use_out_ep=1 style read/write. You mention PiKVM, which I can test (I have a Pi 4 and bought the PiKVM v3 kit when it was on Kickstarter), but given that the lowest version of Linux it supports predates use_out_ep=0 style, I wasn't sure if that was sufficient to make sure I didn't break it. I'll prepare a v2 as soon as I can confirm how to test use_out_ep=0 style.

В Fri, 21 Oct 2022 17:28:25 -0700
Vicki Pfau <vi@endrift.com> пишет:

> On 9/13/22 03:06, Maxim Devaev wrote:
> > В Thu, 8 Sep 2022 16:57:36 -0700
> > Vicki Pfau <vi@endrift.com> пишет:
> >   
> >> Hi,
> >>
> >> On 7/31/22 01:14, Maxim Devaev wrote:  
> >>> В Thu, 28 Jul 2022 11:11:31 -0700
> >>> Vicki Pfau <vi@endrift.com> пишет:
> >>>     
> >>>> On 7/28/22 01:59, Maxim Devaev wrote:    
> >>>>> В Tue, 26 Jul 2022 21:26:05 -0700
> >>>>> Vicki Pfau <vi@endrift.com> пишет:
> >>>>>       
> >>>>>> On 7/26/22 02:51, Maxim Devaev wrote:      
> >>>>>>> В Mon, 25 Jul 2022 17:58:26 -0700
> >>>>>>> Vicki Pfau <vi@endrift.com> пишет:
> >>>>>>>         
> >>>>>>>> While the HID gadget implementation has been sufficient for devices that only
> >>>>>>>> use INTERRUPT transfers, the USB HID standard includes provisions for Set- and
> >>>>>>>> Get-Feature report CONTROL transfers that go over endpoint 0. These were
> >>>>>>>> previously impossible with the existing implementation, and would either send
> >>>>>>>> an empty reply, or stall out.
> >>>>>>>>
> >>>>>>>> As the feature is a standard part of USB HID, it stands to reason that devices
> >>>>>>>> would use it, and that the HID gadget should support it. This patch adds
> >>>>>>>> support for host-to-device Set-Feature reports through a new ioctl
> >>>>>>>> interface to the hidg class dev nodes.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Vicki Pfau <vi@endrift.com>        
> >>>>>>>
> >>>>>>> Won't it break the logic of the existing software that works with /dev/hidgX?
> >>>>>>> Will it work if I want my gadget to work the old way?        
> >>>>>>
> >>>>>> For existing software to use SET_FEATURE at all it has to use an alternative mode, which seems to have only been added somewhat recently. That mode also appears to preclude use of INTERRUPT transfers at all, unless there's some way to set up two hidg nodes that map to the same interface, with one for INTERRUPT and one for SET_FEATURE. If this breaks that, I suppose that's a regression, but this is meant to augment the original, long-standing mode so you can mix INTERRUPT and SET/GET_FEATURE transfers, as there is no way to do that yet. Honestly, the alternate mode seems more like a workaround, as far as I can tell, and not an ideal implementation. I'm not sure when it was added, but as I was originally authoring this against 5.13 and didn't see it until I went to rebase onto master, it can't have been that long ago. So if it breaks any software (which I don't believe it does), it would only affect very new software.
> >>>>>>
> >>>>>> As I alluded to, I'd thought about perhaps adding a second node per interface so one would act as INTERRUPT transfers and the other as SET/GET_FEATURE transfers, but I already had this code half written and wanted to get feedback first, especially since what I have now works (although it's not well-tested after rebasing).      
> >>>>>
> >>>>> I'm a little confused here about what you call an alternative mode.
> >>>>> Are we talking about use_out_ep=1 (default behavior with INTERRUPT)
> >>>>> or use_out_ep=0 (SETUP/SET_REPORT)? The last mode was added by me
> >>>>> to ensure strict compatibility with Apple UEFI and strange BIOS,
> >>>>> and this mode is actually actively used. It is important to me
> >>>>> that it is not broken, but unfortunately I cannot test your patch
> >>>>> on my kernel, as I temporarily do not have access to testing equipment.      
> >>>>
> >>>> use_out_ep=0 is the alternate mode I was talking about. It didn't exist in 5.13, so as I said I wasn't aware of it until I rebased. As the device I'm using is still stuck on that old kernel (for now) and I don't know if I have any USB gadget capable devices on new kernels, I was unable to test it, and would very much like to make sure it doesn't regress before a patch is merged. I wasn't intending to break it, but I figured I'd get feedback I'd need to change before this was merged so if you could test it to ensure it doesn't regress any behavior that would be much appreciated and help me out. I will probably wait until then before submitting a v2.    
> >>>
> >>> I will get access to the USB analyzer and test environment in about a month,
> >>> if that suits you. You can write directly to my email after a month,
> >>> I will help you with testing.    
> >>
> >> I wanted to check the status of this. We're in the middle of rebasing onto a newer kernel, so I might be able to test it myself soon. What software are you using?  
> > 
> > I'm using PiKVM on Raspberry Pi 4 (https://github.com/pikvm/pikvm) but for generic testing you need to make
> > the usual ways of using gadget work in both modes: https://www.isticktoit.net/?p=1383
> > Unfortunately, I'm still away and I can't use my equipment :/  
> 
> I finally got a chance to test on 6.0, and I can confirm that it doesn't break use_out_ep=1 style read/write. You mention PiKVM, which I can test (I have a Pi 4 and bought the PiKVM v3 kit when it was on Kickstarter), but given that the lowest version of Linux it supports predates use_out_ep=0 style, I wasn't sure if that was sufficient to make sure I didn't break it. I'll prepare a v2 as soon as I can confirm how to test use_out_ep=0 style.

Sounds great! BTW PiKVM uses 5.15 LTS kernel from Raspberry Pi repo with several patches. use_out_ep works there.
https://github.com/raspberrypi/linux