linux-kernel - Re: [RFC PATCH v2] usb:gadget: Fixed issue with config_ep_by

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 6 Dec 2019 10:04:18 -0500 (EST)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Jayshri Pawar <jpawar@...ence.com>
cc:     linux-usb@...r.kernel.org, <gregkh@...uxfoundation.org>,
        <felipe.balbi@...ux.intel.com>, <heikki.krogerus@...ux.intel.com>,
        <rogerq@...com>, <linux-kernel@...r.kernel.org>,
        <jbergsagel@...com>, <nsekhar@...com>, <nm@...com>,
        <peter.chen@....com>, <kurahul@...ence.com>, <pawell@...ence.com>,
        <sparmar@...ence.com>
Subject: Re: [RFC PATCH v2] usb:gadget: Fixed issue with config_ep_by_speed
 function.

On Fri, 6 Dec 2019, Jayshri Pawar wrote:

> This patch adds additional parameter alt to config_ep_by_speed function.
> This additional parameter allows to improve this function and
> find proper usb_ss_ep_comp_descriptor.
> 
> Problem has appeared during testing f_tcm (BOT/UAS) driver function.
> 
> f_tcm function for SS use array of headers for both  BOT/UAS alternate
> setting:
> 
> static struct usb_descriptor_header *uasp_ss_function_desc[] = {
>         (struct usb_descriptor_header *) &bot_intf_desc,
>         (struct usb_descriptor_header *) &uasp_ss_bi_desc,
>         (struct usb_descriptor_header *) &bot_bi_ep_comp_desc,
>         (struct usb_descriptor_header *) &uasp_ss_bo_desc,
>         (struct usb_descriptor_header *) &bot_bo_ep_comp_desc,
> 
>         (struct usb_descriptor_header *) &uasp_intf_desc,
>         (struct usb_descriptor_header *) &uasp_ss_bi_desc,
>         (struct usb_descriptor_header *) &uasp_bi_ep_comp_desc,
>         (struct usb_descriptor_header *) &uasp_bi_pipe_desc,
>         (struct usb_descriptor_header *) &uasp_ss_bo_desc,
>         (struct usb_descriptor_header *) &uasp_bo_ep_comp_desc,
>         (struct usb_descriptor_header *) &uasp_bo_pipe_desc,
>         (struct usb_descriptor_header *) &uasp_ss_status_desc,
>         (struct usb_descriptor_header *) &uasp_status_in_ep_comp_desc,
>         (struct usb_descriptor_header *) &uasp_status_pipe_desc,
>         (struct usb_descriptor_header *) &uasp_ss_cmd_desc,
>         (struct usb_descriptor_header *) &uasp_cmd_comp_desc,
>         (struct usb_descriptor_header *) &uasp_cmd_pipe_desc,
>         NULL,
> };
> 
> The first 5 descriptors are associated with BOT alternate setting,
> and others are associated  with UAS.

If the first 5 descriptors are really associated with the BOT alternate
setting, why is the second descriptor named uasp_ss_bi_desc?  And why
is the fourth descriptor named uasp_ss_bo_desc?  These names suggest
they are associated with UAS.

If the same descriptors are used for both settings, the names should 
reflect this.  For example, they could be called bot_uasp_ss_bi_desc 
and bot_uasp_ss_bo_desc.

Alan Stern