Hi,
(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 <[email protected]> writes:
> Hi,
>
> Earlier I have posted the patch for usb dwc3 core shutdown callback
>
> https://lore.kernel.org/linux-arm-msm/[email protected]/
>
> and it was reverted due to issues.
Right, as should be expected when we find regressions
> https://lore.kernel.org/linux-usb/[email protected]/
>
> 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/[email protected]/
>
> 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
--
balbi
Hi,
On 8/12/2021 2:37 PM, Felipe Balbi wrote:
> Hi,
>
> (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 <[email protected]> writes:
>> Hi,
>>
>> Earlier I have posted the patch for usb dwc3 core shutdown callback
>>
>> https://lore.kernel.org/linux-arm-msm/[email protected]/
>>
>> and it was reverted due to issues.
> Right, as should be expected when we find regressions
>
>> https://lore.kernel.org/linux-usb/[email protected]/
>>
>> 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/[email protected]/
>>
>> 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.
[ 312.862737] systemd-journald[650]: Received SIGTERM from PID 1 (init).
[ 312.866332] xhci-hcd xhci-hcd.0.auto: xhci_urb_enqueue
[ 312.875205] xhci-hcd xhci-hcd.0.auto: xhci_urb_enqueue
[ 312.951045] Unsafe core_pattern used with fs.suid_dumpable=2.
[ 312.951045] Pipe handler or fully qualified core dump path required.
[ 312.951045] Set kernel.core_pattern before fs.suid_dumpable.
[ 312.981364] ip_local_port_range: prefer different parity for
start/end values.
[ 313.086729] Bluetooth: qca_download_firmware() hci0: QCA Downloading
qca/crnv32.bin
[ 313.194059] init: console-ttyMSM0 main process (516) killed by TERM
signal
[ 313.317109] kvm: exiting hardware virtualization
[ 313.338988] platform video-firmware.0: Removing from iommu group 14
[ 313.345975] platform wifi-firmware.0: Removing from iommu group 12
[ 313.372244] xhci-hcd xhci-hcd.0.auto: -->xhci_shutdown
[ 313.377591] xhci-hcd xhci-hcd.0.auto: // Halt the HC
[ 313.382811] xhci-hcd xhci-hcd.0.auto: xhci_shutdown completed -
status = 1
[ 313.398238] Bluetooth: qca_uart_setup() hci0: QCA setup on UART is
completed
[ 313.405583] debugfs: Directory 'ibs' with parent 'hci0' already present!
[ 313.439006] Bluetooth: qca_hw_error() hci0: mem_dump_status: 0
[ 313.445073] Bluetooth: qca_send_crashbuffer() hci0: crash the soc to
collect controller dump
[ 313.595791] arm-smmu 15000000.iommu: disabling translation
[ 313.601831] arm-smmu 5040000.iommu: disabling translation
[ 313.608559] reboot: Restarting system
Regards
Sandeep
Hi,
Sandeep Maheswaram <[email protected]> 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 <[email protected]> writes:
>>> Hi,
>>>
>>> Earlier I have posted the patch for usb dwc3 core shutdown callback
>>>
>>> https://lore.kernel.org/linux-arm-msm/[email protected]/
>>>
>>> and it was reverted due to issues.
>> Right, as should be expected when we find regressions
>>
>>> https://lore.kernel.org/linux-usb/[email protected]/
>>>
>>> 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/[email protected]/
>>>
>>> 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?
--
balbi
Hi,
On 8/26/2021 4:13 PM, Felipe Balbi wrote:
> Hi,
>
> Sandeep Maheswaram <[email protected]> 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 <[email protected]> writes:
>>>> Hi,
>>>>
>>>> Earlier I have posted the patch for usb dwc3 core shutdown callback
>>>>
>>>> https://lore.kernel.org/linux-arm-msm/[email protected]/
>>>>
>>>> and it was reverted due to issues.
>>> Right, as should be expected when we find regressions
>>>
>>>> https://lore.kernel.org/linux-usb/[email protected]/
>>>>
>>>> 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/[email protected]/
>>>>
>>>> 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?
Sandeep Maheswaram <[email protected]> writes:
> Hi,
>
> On 8/26/2021 4:13 PM, Felipe Balbi wrote:
>> Hi,
>>
>> Sandeep Maheswaram <[email protected]> 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 <[email protected]> writes:
>>>>> Hi,
>>>>>
>>>>> Earlier I have posted the patch for usb dwc3 core shutdown callback
>>>>>
>>>>> https://lore.kernel.org/linux-arm-msm/[email protected]/
>>>>>
>>>>> and it was reverted due to issues.
>>>> Right, as should be expected when we find regressions
>>>>
>>>>> https://lore.kernel.org/linux-usb/[email protected]/
>>>>>
>>>>> 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/[email protected]/
>>>>>
>>>>> 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?
Sure about that? I've been using kexec with 8150 for quite a while.
--
balbi