linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krishna Kurapati PSSNV <quic_kriskura@quicinc.com>
To: Hardik Gajjar <hgajjar@de.adit-jv.com>
Cc: <gregkh@linuxfoundation.org>, <maze@google.com>,
	<linux-usb@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<guofeng.li@gm.com>, <hardik.gajjar@bosch.com>,
	<eugeniu.rosca@bosch.com>
Subject: Re: [PATCH] usb: gadget: f_ncm: Fix Kernel Panic due to access of invalid gadget ptr
Date: Fri, 8 Mar 2024 17:47:37 +0530	[thread overview]
Message-ID: <4816d981-3955-495c-8fc6-3b9b15ba1689@quicinc.com> (raw)
In-Reply-To: <20240308115506.GA5631@vmlxhi-118.adit-jv.com>



On 3/8/2024 5:25 PM, Hardik Gajjar wrote:
> On Thu, Mar 07, 2024 at 11:12:07PM +0530, Krishna Kurapati PSSNV wrote:
>>

[...]

> 
> I believe using gether_cleanup altogether may not be an optimal solution.
> The creation and deletion of network interfaces should align with the behavior of each specific network driver.
> 
> For instance, in the case of NCM, the usb0 interface is created upon the creation of a directory
> in config/usb_gadget/gX/functions/ncm.usb0, and it is removed when the corresponding directory
> is deleted. This follows a standard flow observed in many network drivers, where interfaces are
> created during driver loading/probing and deleted during removal.
> 

Hi Hardik,

  Yeah. I observed this behavior.

> Typically, deleting the gadget on every disconnection is not considered a good practice, as it can
> negatively impact the user experience when accessing the gadget.
> 

Got it. I was suspecting issues might come up during fast Plug-In/ 
Plug-Out cases as setting and cleanup of network interface might take 
some time.

> In our specific scenario, retaining the usb0 network interface has proven to enhance performance
> and stabilize connections. Previous attempts to remove it resulted in an observed increase in time of 300ms,
> particularly at the start of Apple CarPlay sessions.
> 

Thanks for this info. Makes sense to keep it in free_inst only. But my 
initial doubt only stemmed from the fact that actions taken during bind 
must be reversed during unbind.

> Furthermore, it's important to highlight that in Qualcomm products and msm kernels, the inclusion of gether_cleanup
> in the unbind process was eventually reverted. While the specific reason for reverting the patch is unknown,
> it suggests that the addition may not have yielded the intended or required results
> 
> Following is the revert patch details in msm-5.4 kernel, if you want check it.
> 
> Revert "usb: gadget: f_ncm: allocate/free net device upon driver bind/unbind"
> 
> This reverts commit 006d8adf555a8c6d34113f564ade312d68abd3b3.
> 
> Move back the allocation of netdevice to alloc_inst(), one-time
> registration to bind(), deregistration and free to rm_inst(). The
> UI update issue will be taken up with proper stakeholders.
> 
> Change-Id: I56448b08f6796a43ec5b0dfe0dd2d42cdc0eec14
> 

Agree. This was merged first in 4.19 downstream (most probably for car 
play use case only) and then reverted in 5.4. But present 4.19 code in 
QC still keeps it in unbind path. The only reason I suspect it was 
reverted was to get back on to same page with upstream driver (atleast 
starting from 5.10, this was the reasoning to remove gether_cleanup in 
unbind path and put it back in free_inst).

Thanks,
Krishna,

  reply	other threads:[~2024-03-08 12:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-07 16:18 [PATCH] usb: gadget: f_ncm: Fix Kernel Panic due to access of invalid gadget ptr Hardik Gajjar
2024-03-07 16:45 ` Greg KH
2024-03-07 17:33   ` Hardik Gajjar
2024-03-07 17:42 ` Krishna Kurapati PSSNV
2024-03-08 11:55   ` Hardik Gajjar
2024-03-08 12:17     ` Krishna Kurapati PSSNV [this message]
2024-03-11 12:04       ` Hardik Gajjar
2024-04-19 13:35         ` Hardik Gajjar

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=4816d981-3955-495c-8fc6-3b9b15ba1689@quicinc.com \
    --to=quic_kriskura@quicinc.com \
    --cc=eugeniu.rosca@bosch.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guofeng.li@gm.com \
    --cc=hardik.gajjar@bosch.com \
    --cc=hgajjar@de.adit-jv.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=maze@google.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;
as well as URLs for NNTP newsgroup(s).