linux-kernel - Re: dwc2: problems with IN requests completion in linux-next

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-id: <54B4F863.6040303@samsung.com>
Date:	Tue, 13 Jan 2015 11:50:11 +0100
From:	Robert Baldyga <r.baldyga@...sung.com>
To:	Paul Zimmerman <Paul.Zimmerman@...opsys.com>,
	"dinh.linux@...il.com" <dinh.linux@...il.com>
Cc:	"balbi@...com" <balbi@...com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: dwc2: problems with IN requests completion in linux-next

On 01/13/2015 11:18 AM, Robert Baldyga wrote:
> On 01/12/2015 10:35 PM, Paul Zimmerman wrote:
>>> From: Robert Baldyga [mailto:r.baldyga@...sung.com]
>>> Sent: Monday, December 22, 2014 6:13 AM
>>>
>>> I have recently noticed problem with DWC2 driver in latest linux-next. I
>>> use it in gadget only mode at Samsung platform (Odroid U3) but I believe
>>> the bug can be reproduced at another platforms.
>>>
>>> While running FFS example (tools/usb/ffs-aio-example/simple/) the
>>> communication breaks after few seconds. It's because one of IN requests
>>> enqueued in DWC2 driver do not complete. At USB analyzer I see that USB
>>> device started to transmit data from this request, but it ended incomplete.
>>>
>>> I bisected kernel tree, and I got following patches are reason of break.
>>>
>>> 941fcce usb: dwc2: Update the gadget driver to use common dwc2_hsotg
>>> structure
>>> 117777b usb: dwc2: Move gadget probe function into platform code
>>> bcc0607 usb: dwc2: convert to use dev_pm_ops API
>>> 510ffaa usb: dwc2: Initialize the USB core for peripheral mode
>>> db8178c usb: dwc2: Update common interrupt handler to call gadget
>>> interrupt handler
>>> 8d736d8 usb: dwc2: gadget: Do not fail probe if there isn't a clock node
>>>
>>> Patch 941fcce breaks DWC2 driver at my platform and it starts to work
>>> from 8d736d8 but it has described bug.
>>>
>>> I will try to localize reason of this issue.
>>
>> Hi Robert,
>>
>> I think the most likely suspect would be db8178c, since the rest appear
>> to be init-time things. It seems to revert cleanly, can you try
>> reverting just that patch and see if it helps?
>>
> 
> Hi Paul,
> 
> Thanks. It looks like you're right, commit db8178c causes the break.
> 
> I have found out that if we don't call dwc2_is_controller_alive() in
> interrupt handler everything works well. Conclusion is that reading from
> GSNPSID causes the problem.
> 
> BTW it's strange that this register is used for testing if controller is
> alive. Documentation says nothing about that as well as it does not say
> that reading this register can affect hardware behaviour.
> 
> Avoiding to read this register in device mode seems to be the simplest
> solution. But the question is why does it behave this way?
> 

It looks like calling dwc2_is_controller_alive() under spinlock solves
the problem. I will prepare patch.

Best regards,
Robert Baldyga
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/