Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: wcheng=codeaurora.org@mg.codeaurora.org
DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 0E16CC433CA
Subject: Re: [PATCH] usb: gadget: Stall OS descriptor request for unsupported
 functions
To:     Jack Pham <jackp@codeaurora.org>
Cc:     balbi@kernel.org, gregkh@linuxfoundation.org,
        linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
        Chandana Kishori Chiluveru <cchiluve@codeaurora.org>
References: <1616464217-2650-1-git-send-email-wcheng@codeaurora.org>
 <20210323062542.GA17922@jackp-linux.qualcomm.com>
From:   Wesley Cheng <wcheng@codeaurora.org>
Message-ID: <297cf185-70d6-5018-08ab-e069dc84d8e0@codeaurora.org>
Date:   Mon, 22 Mar 2021 23:57:33 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <20210323062542.GA17922@jackp-linux.qualcomm.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 3/22/2021 11:25 PM, Jack Pham wrote:
> Hi Wesley,
> 
> On Mon, Mar 22, 2021 at 06:50:17PM -0700, Wesley Cheng wrote:
>> From: Chandana Kishori Chiluveru <cchiluve@codeaurora.org>
>>
>> Hosts which request "OS descriptors" from gadgets do so during
>> the enumeration phase and before the configuration is set with
>> SET_CONFIGURATION. Composite driver supports OS descriptor
>> handling in composite_setup function. This requires to pass
>> signature field, vendor code, compatibleID and subCompatibleID
>> from user space.
>>
>> For USB compositions that contain functions which don't implement os
>> descriptors, Windows is sending vendor specific requests for os
>> descriptors and composite driver handling this request with invalid
>> data. With this invalid info host resetting the bus and never
>> selecting the configuration and leading enumeration issue.
>>
>> Fix this by bailing out from the OS descriptor setup request
>> handling if the functions does not have OS descriptors compatibleID.
>>
>> Signed-off-by: Chandana Kishori Chiluveru <cchiluve@codeaurora.org>
>> Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
>> ---
>>  drivers/usb/gadget/composite.c | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
>> index 72a9797..473edda6 100644
>> --- a/drivers/usb/gadget/composite.c
>> +++ b/drivers/usb/gadget/composite.c
>> @@ -1945,6 +1945,12 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl)
>>  				buf[6] = w_index;
>>  				/* Number of ext compat interfaces */
>>  				count = count_ext_compat(os_desc_cfg);
>> +				/*
>> +				 * Bailout if device does not
>> +				 * have ext_compat interfaces.
>> +				 */
>> +				if (count == 0)
>> +					break;
>>  				buf[8] = count;
>>  				count *= 24; /* 24 B/ext compat desc */
>>  				count += 16; /* header */
> 
> Do we still need this fix? IIRC we had this change in our downstream
> kernel to fix the case when dynamically re-configuring ConfigFS, i.e.
> changing the composition of functions wherein none of the interfaces
> support OS Descriptors, so this causes count_ext_compat() to return
> 0 and results in the issue described in $SUBJECT.
> 
Hi Jack,

You're correct.  We can address this as well in the userspace perspective.

> But I think this is more of a problem of an improperly configured
> ConfigFS gadget. If userspace instead removes the config from the
> gadget's os_desc subdirectory that should cause cdev->os_desc_config to
> be set to NULL and hence composite_setup() should never enter this
> handling at all, right?

Sure, I'll go with fixing it in the userspace, since the support to
stall the OS desc is already present in the composite driver as you
mentioned.  Thanks for the input.

Thanks
Wesley Cheng

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project