public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Selvarasu Ganesan <selvarasu.g@samsung.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: quic_jjohnson@quicinc.com, kees@kernel.org,
	abdul.rahim@myyahoo.com, m.grzeschik@pengutronix.de,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	jh0801.jung@samsung.com, dh10.jung@samsung.com,
	naushad@samsung.com, akash.m5@samsung.com, rc93.raju@samsung.com,
	taehyun.cho@samsung.com, hongpooh.kim@samsung.com,
	eomji.oh@samsung.com, shijie.cai@samsung.com,
	alim.akhtar@samsung.com, stable@vger.kernel.org
Subject: Re: [PATCH] usb: gadget: f_midi: Fixing wMaxPacketSize exceeded issue during MIDI bind retries
Date: Fri, 20 Dec 2024 19:02:06 +0530	[thread overview]
Message-ID: <a1dedf06-e804-4580-a690-25e55312eab8@samsung.com> (raw)
In-Reply-To: <2024122013-scary-paver-fcff@gregkh>


On 12/20/2024 5:54 PM, Greg KH wrote:
> On Wed, Dec 18, 2024 at 03:51:50PM +0530, Selvarasu Ganesan wrote:
>> On 12/18/2024 11:01 AM, Greg KH wrote:
>>> On Sun, Dec 08, 2024 at 08:53:20PM +0530, Selvarasu Ganesan wrote:
>>>> The current implementation sets the wMaxPacketSize of bulk in/out
>>>> endpoints to 1024 bytes at the end of the f_midi_bind function. However,
>>>> in cases where there is a failure in the first midi bind attempt,
>>>> consider rebinding.
>>> What considers rebinding?  Your change does not modify that.
>> Hi Greg,
>> Thanks for your review comments.
>>
>>
>> Here the term "rebind" in this context refers to attempting to bind the
>> MIDI function a second time in certain scenarios.
>> The situations where rebinding is considered include:
>>
>>    * When there is a failure in the first UDC write attempt, which may be
>>      caused by other functions bind along with MIDI
>>    * Runtime composition change : Example : MIDI,ADB to MIDI. Or MIDI to
>>      MIDI,ADB
>>
>> The issue arises during the second time the "f_midi_bind" function is
>> called. The problem lies in the fact that the size of
>> "bulk_in_desc.wMaxPacketSize" is set to 1024 during the first call,
>> which exceeds the hardware capability of the dwc3 TX/RX FIFO
>> (ep->maxpacket_limit = 512).
> Ok, but then why not properly reset ALL of the options/values when a
> failure happens, not just this one when the initialization happens
> again?  Odds are you might be missing the change of something else here
> as well, right?
Are you suggesting that we reset the entire value of 
usb_endpoint_descriptor before call usb_ep_autoconfig? If so, Sorry I am 
not clear on your reasoning for wanting to reset all options/values. 
After all, all values will be overwritten 
afterusb_ep_autoconfig.Additionally, the wMaxPacketSize is the only 
value being checked during the EP claim process (usb_ep_autoconfig), and 
it has caused issues where claiming wMaxPacketSize is grater than 
ep->maxpacket_limit.
>
> Also, cleaning up from an error is a better thing to do than forcing
> something to be set all the time when you don't have anything gone
> wrong.
As I previously mentioned, this is a general approach to set 
wMaxPacketSize before claiming the endpoint. This is because the 
usb_ep_autoconfig treats endpoint descriptors as if they were full 
speed. Following the same pattern as other function drivers, that 
approach allows us to claim the EP with using a full-speed descriptor. 
We can use the same approach here instead of resetting wMaxPacketSize 
every time.

The following provided code is used to claim an EP with a full-speed 
bulk descriptor in MIDI. Its also working solution.  But, We thinking 
that it may unnecessarily complicate the code as it only utilizes the 
full descriptor for obtaining the EP address here. What you think shall 
we go with below approach instead of rest wMaxPacketSize before call 
usb_ep_autoconfig?

diff --git a/drivers/usb/gadget/function/f_midi.c 
b/drivers/usb/gadget/function/f_midi.c
index 837fcdfa3840..fe12c8d82bf2 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -116,6 +116,22 @@ DECLARE_UAC_AC_HEADER_DESCRIPTOR(1);
  DECLARE_USB_MIDI_OUT_JACK_DESCRIPTOR(1);
  DECLARE_USB_MS_ENDPOINT_DESCRIPTOR(16);

+static struct usb_endpoint_descriptor fs_bulk_in_desc = {
+ .bLength =              USB_DT_ENDPOINT_SIZE,
+ .bDescriptorType =      USB_DT_ENDPOINT,
+
+ .bEndpointAddress =     USB_DIR_IN,
+ .bmAttributes =         USB_ENDPOINT_XFER_BULK,
+};
+
+static struct usb_endpoint_descriptor fs_bulk_out_desc = {
+ .bLength =              USB_DT_ENDPOINT_SIZE,
+ .bDescriptorType =      USB_DT_ENDPOINT,
+
+ .bEndpointAddress =     USB_DIR_OUT,
+ .bmAttributes =         USB_ENDPOINT_XFER_BULK,
+};
+
  /* B.3.1  Standard AC Interface Descriptor */
  static struct usb_interface_descriptor ac_interface_desc = {
.bLength =              USB_DT_INTERFACE_SIZE,
@@ -908,11 +924,11 @@ static int f_midi_bind(struct usb_configuration 
*c, struct usb_function *f)
status = -ENODEV;

/* allocate instance-specific endpoints */
- midi->in_ep = usb_ep_autoconfig(cdev->gadget, &bulk_in_desc);
+ midi->in_ep = usb_ep_autoconfig(cdev->gadget, &fs_bulk_in_desc);
if (!midi->in_ep)
goto fail;

- midi->out_ep = usb_ep_autoconfig(cdev->gadget, &bulk_out_desc);
+ midi->out_ep = usb_ep_autoconfig(cdev->gadget, &fs_bulk_out_desc);
if (!midi->out_ep)
goto fail;

@@ -1006,6 +1022,9 @@ static int f_midi_bind(struct usb_configuration 
*c, struct usb_function *f)
ms_in_desc.bLength = USB_DT_MS_ENDPOINT_SIZE(midi->out_ports);
ms_in_desc.bNumEmbMIDIJack = midi->out_ports;

+ bulk_in_desc.bEndpointAddress = fs_bulk_in_desc.bEndpointAddress;
+ bulk_out_desc.bEndpointAddress = fs_bulk_out_desc.bEndpointAddress;
+
/* ... and add them to the list */
endpoint_descriptor_index = i;
midi_function[i++] = (struct usb_descriptor_header *) &bulk_out_desc;



>
> thanks,
>
> greg k-h
>

  reply	other threads:[~2024-12-20 13:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20241208152338epcas5p4fde427bb4467414417083221067ac7ab@epcas5p4.samsung.com>
2024-12-08 15:23 ` [PATCH] usb: gadget: f_midi: Fixing wMaxPacketSize exceeded issue during MIDI bind retries Selvarasu Ganesan
2024-12-10  9:53   ` Selvarasu Ganesan
2024-12-10 10:18     ` Greg KH
2024-12-10 14:11       ` Selvarasu Ganesan
2024-12-10 14:25         ` Greg KH
2024-12-12 12:28           ` Selvarasu Ganesan
2024-12-18  5:31   ` Greg KH
2024-12-18 10:21     ` Selvarasu Ganesan
2024-12-18 15:51       ` Alan Stern
2024-12-19  4:06         ` Selvarasu Ganesan
2024-12-20 12:24       ` Greg KH
2024-12-20 13:32         ` Selvarasu Ganesan [this message]
2024-12-20 15:15           ` Greg KH
2024-12-21 18:07             ` Selvarasu Ganesan
2025-01-06  5:17               ` Selvarasu Ganesan
2025-01-16  5:19               ` Selvarasu Ganesan
2025-01-17 11:05                 ` Greg KH
2025-01-18  6:09                   ` Selvarasu Ganesan
     [not found] <CGME20241208151349epcas5p1a94ca45020318f54885072d4987160b3@epcas5p1.samsung.com>
2024-12-08 15:13 ` Faraz Ata
2024-12-08 15:28   ` Selvarasu Ganesan
2024-12-08 15:48     ` Greg KH
2024-12-08 16:00       ` Selvarasu Ganesan

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=a1dedf06-e804-4580-a690-25e55312eab8@samsung.com \
    --to=selvarasu.g@samsung.com \
    --cc=abdul.rahim@myyahoo.com \
    --cc=akash.m5@samsung.com \
    --cc=alim.akhtar@samsung.com \
    --cc=dh10.jung@samsung.com \
    --cc=eomji.oh@samsung.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hongpooh.kim@samsung.com \
    --cc=jh0801.jung@samsung.com \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=m.grzeschik@pengutronix.de \
    --cc=naushad@samsung.com \
    --cc=quic_jjohnson@quicinc.com \
    --cc=rc93.raju@samsung.com \
    --cc=shijie.cai@samsung.com \
    --cc=stable@vger.kernel.org \
    --cc=taehyun.cho@samsung.com \
    /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