On 8/15/2024 5:34 AM, Thinh Nguyen wrote:
> On Wed, Aug 14, 2024, Selvarasu Ganesan wrote:
>> On 8/14/2024 4:47 AM, Thinh Nguyen wrote:
>>> On Sat, Aug 10, 2024, Selvarasu Ganesan wrote:
>>>> On 8/10/2024 4:58 AM, Thinh Nguyen wrote:
>>>>> On Thu, Aug 08, 2024, Selvarasu Ganesan wrote:
>>>>>> This commit addresses an issue where the USB core could access an
>>>>>> invalid event buffer address during runtime suspend, potentially causing
>>>>>> SMMU faults and other memory issues. The problem arises from the
>>>>>> following sequence.
>>>>>> 1. In dwc3_gadget_suspend, there is a chance of a timeout when
>>>>>> moving the USB core to the halt state after clearing the
>>>>>> run/stop bit by software.
>>>>>> 2. In dwc3_core_exit, the event buffer is cleared regardless of
>>>>>> the USB core's status, which may lead to an SMMU faults and
>>>>> This is a workaround to your specific setup behavior. Please document in
>>>>> the commit message which platforms are impacted.
>>>> Please correct me if i am wrong. I dont think this workaround only
>>>> applicable our specific setup. It could be a common issue across all
>>>> other vendor platforms, and it's required to must check the controller
>>>> status before clear the event buffers address. What you think is it
>>>> really required to mention the platform details in commit message?
>>> How can it be a common issue, the suspend sequence hasn't completed in
>>> the dwc3 driver but yet the buffer is no longer accessible? Also, as you
>>> noted, we don't know the exact condition for the SMMU fault, and this
>>> isn't reproducible all the time.
>> Agree. Will update platform detail in next version.
>>>>>> other memory issues. if the USB core tries to access the event
>>>>>> buffer address.
>>>>>>
>>>>>> To prevent this issue, this commit ensures that the event buffer address
>>>>>> is not cleared by software when the USB core is active during runtime
>>>>>> suspend by checking its status before clearing the buffer address.
>>>>>>
>>>>>> Cc: stable@xxxxxxxxxxxxxxx
>>>>> We can keep the stable tag, but there's no issue with the commit below.
>>>> By mistaken I mentioned wrong commit ID. The correct commit id would be
>>>> 660e9bde74d69 ("usb: dwc3: remove num_event_buffers").
>>> The above commit isn't the issue either. If it is, then the problem
>>> should still exist prior to that.
>>
>> This issue still persists in older kernels (6.1.X) as well. We believed
>> that it could be a common issue due to the missing condition for
>> checking the controller status in the mentioned commit above. We require
>> this fix in all stable kernel for the Exynos platform. Is it fine to
>> only mention the "Cc" tag in this case?
> You can just Cc stable and indicate how far you want this to be
> backported. Make sure to note that this change resolves a hardware
> quirk.
>
> e.g.
> Cc: stable <stable@xxxxxxxxxx> # 6.1.x
Sure. Thanks for the confirmation.
>
> BR,
> Thinh
