From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Chris Wulff <Chris.Wulff@biamp.com>
Cc: "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
Christian Brauner <brauner@kernel.org>,
Paul Cercueil <paul@crapouillou.net>, Jan Kara <jack@suse.cz>,
Jeff Layton <jlayton@kernel.org>,
Dmitry Antipov <dmantipov@yandex.ru>,
David Sands <david.sands@biamp.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>
Subject: Re: [PATCH v3] usb: gadget: f_fs: add capability for dfu run-time descriptor
Date: Wed, 31 Jul 2024 10:27:59 +0200 [thread overview]
Message-ID: <2024073122-shakable-photo-67d1@gregkh> (raw)
In-Reply-To: <CO1PR17MB54197F118CBC8783D289B97DE1102@CO1PR17MB5419.namprd17.prod.outlook.com>
On Wed, Apr 24, 2024 at 10:14:58PM +0000, Chris Wulff wrote:
> From: David Sands <david.sands@biamp.com>
>
> Add the ability for FunctionFS driver to be able to create DFU Run-Time
> descriptors.
Don't you need some userspace documentation for this as well?
> --- a/include/uapi/linux/usb/ch9.h
> +++ b/include/uapi/linux/usb/ch9.h
> @@ -254,6 +254,9 @@ struct usb_ctrlrequest {
> #define USB_DT_DEVICE_CAPABILITY 0x10
> #define USB_DT_WIRELESS_ENDPOINT_COMP 0x11
> #define USB_DT_WIRE_ADAPTER 0x21
> +/* From USB Device Firmware Upgrade Specification, Revision 1.1 */
> +#define USB_DT_DFU_FUNCTIONAL 0x21
So USB_DT_WIRE_ADAPTER and USB_DT_DFU_FUNCTIONAL are the same? That
seems wrong.
> +/* these are from the Wireless USB spec */
What spec? What "these"?
> #define USB_DT_RPIPE 0x22
> #define USB_DT_CS_RADIO_CONTROL 0x23
> /* From the T10 UAS specification */
> @@ -263,6 +266,7 @@ struct usb_ctrlrequest {
> /* From the USB 3.1 spec */
> #define USB_DT_SSP_ISOC_ENDPOINT_COMP 0x31
>
> +
> /* Conventional codes for class-specific descriptors. The convention is
> * defined in the USB "Common Class" Spec (3.11). Individual class specs
> * are authoritative for their usage, not the "common class" writeup.
Unneeded change?
> @@ -329,9 +333,10 @@ struct usb_device_descriptor {
> #define USB_CLASS_USB_TYPE_C_BRIDGE 0x12
> #define USB_CLASS_MISC 0xef
> #define USB_CLASS_APP_SPEC 0xfe
> -#define USB_CLASS_VENDOR_SPEC 0xff
> +#define USB_SUBCLASS_DFU 0x01
>
> -#define USB_SUBCLASS_VENDOR_SPEC 0xff
> +#define USB_CLASS_VENDOR_SPEC 0xff
> +#define USB_SUBCLASS_VENDOR_SPEC 0xff
Why reorder these?
>
> /*-------------------------------------------------------------------------*/
>
> diff --git a/include/uapi/linux/usb/functionfs.h b/include/uapi/linux/usb/functionfs.h
> index 9f88de9c3d66..6d2061500184 100644
> --- a/include/uapi/linux/usb/functionfs.h
> +++ b/include/uapi/linux/usb/functionfs.h
> @@ -37,6 +37,31 @@ struct usb_endpoint_descriptor_no_audio {
> __u8 bInterval;
> } __attribute__((packed));
>
> +/**
> + * struct usb_dfu_functional_descriptor - DFU Functional descriptor
> + * @bLength: Size of the descriptor (bytes)
> + * @bDescriptorType: USB_DT_DFU_FUNCTIONAL
> + * @bmAttributes: DFU attributes
> + * @wDetachTimeOut: Maximum time to wait after DFU_DETACH (ms, le16)
> + * @wTransferSize: Maximum number of bytes per control-write (le16)
> + * @bcdDFUVersion: DFU Spec version (BCD, le16)
> + */
> +struct usb_dfu_functional_descriptor {
> + __u8 bLength;
> + __u8 bDescriptorType;
> + __u8 bmAttributes;
> + __le16 wDetachTimeOut;
> + __le16 wTransferSize;
> + __le16 bcdDFUVersion;
> +} __attribute__ ((packed));
> +
> +/* from DFU functional descriptor bmAttributes */
> +#define DFU_FUNC_ATT_WILL_DETACH (1 << 3)
> +#define DFU_FUNC_ATT_MANIFEST_TOLERANT (1 << 2)
> +#define DFU_FUNC_ATT_CAN_UPLOAD (1 << 1)
> +#define DFU_FUNC_ATT_CAN_DOWNLOAD (1 << 0)
Please use proper BIT macros here to make this more obvious. And in
sorted order?
thanks,
greg k-h
next prev parent reply other threads:[~2024-07-31 8:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-24 22:14 [PATCH v3] usb: gadget: f_fs: add capability for dfu run-time descriptor Chris Wulff
2024-07-31 8:27 ` Greg Kroah-Hartman [this message]
2024-08-01 0:09 ` Chris Wulff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2024073122-shakable-photo-67d1@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=Chris.Wulff@biamp.com \
--cc=brauner@kernel.org \
--cc=david.sands@biamp.com \
--cc=dmantipov@yandex.ru \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=paul@crapouillou.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).