[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7a6bf94b-91cd-15d5-dd9c-798e7a927727@codeaurora.org>
Date: Mon, 30 Aug 2021 09:48:16 +0530
From: Sandeep Maheswaram <sanm@...eaurora.org>
To: Felipe Balbi <balbi@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Mathias Nyman <mathias.nyman@...el.com>,
linux-arm-msm@...r.kernel.org, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org,
Pratham Pratap <prathampratap@...eaurora.org>,
Jack Pham <jackp@...eaurora.org>,
Stephen Boyd <swboyd@...omium.org>,
Matthias Kaehlcke <mka@...omium.org>,
Doug Anderson <dianders@...omium.org>
Subject: Re: Regarding usb dwc3 core shutdown callback
Hi,
On 8/26/2021 4:13 PM, Felipe Balbi wrote:
> Hi,
>
> Sandeep Maheswaram <sanm@...eaurora.org> writes:
>>> (why isn't this email plain/text? Content Type was set to multipart
>>> alternative, please configure your email client correctly :-)
>>>
>>> While at that, also make sure to break lines at 80-columns)
>>>
>>> Sandeep Maheswaram <sanm@...eaurora.org> writes:
>>>> Hi,
>>>>
>>>> Earlier I have posted the patch for usb dwc3 core shutdown callback
>>>>
>>>> https://lore.kernel.org/linux-arm-msm/1618380209-20114-1-git-send-email-sanm@codeaurora.org/
>>>>
>>>> and it was reverted due to issues.
>>> Right, as should be expected when we find regressions
>>>
>>>> https://lore.kernel.org/linux-usb/20210603151742.298243-1-alexandru.elisei@arm.com/
>>>>
>>>> As we already have shutdown callback in xhci plat driver where we halt
>>>> the controller, so there will be no transactions with usb devices.
>>>>
>>>> https://lore.kernel.org/linux-usb/20200306092328.41253-1-ran.wang_1@nxp.com/
>>>>
>>>> So I think dwc3 core shutdown may not be required at least when we are
>>>> using host mode. Let me know your opinion about this.
>>> If that's the case, then sure. Please validate the condition, though,
>>> and kindly report back on your findings
>> I have enabled couple of logs in shutdown path and see no URBs
>> enqueued after xhci shut down.
>>
>> Hope this is enough for validation . Please suggest if anything more I
>> could do.
> how about writing a little script to kexec into another kernel for a few
> hundred iterations and make sure things still work after all that?
Currently kexec is not supported on qcom devices. Anything we can do
apart from kexec?
Powered by blists - more mailing lists