Re: [PATCH v4] Move DWC2 driver out of staging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02/01/2014 03:00 AM, Andre Heider wrote:
> On Fri, Jan 31, 2014 at 11:48:37PM -0700, Stephen Warren wrote:
>> On 01/31/2014 11:12 AM, Andre Heider wrote:
>>> On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote:
>>>> The DWC2 driver should now be in good enough shape to move out of
>>>> staging. I have stress tested it overnight on RPI running mass
>>>> storage and Ethernet transfers in parallel, and for several days
>>>> on our proprietary PCI-based platform.
>> ...
>>> this looks just fine, but for whatever reason it breaks sdhci on my rpi.
>>> With today's Linus' master the dwc2 controller seems to initialize fine,
>>> but I get this upon boot:
>>>
>>> [    1.783316] sdhci-bcm2835 20300000.sdhci: sdhci_pltfm_init failed -12
>>> [    1.794820] sdhci-bcm2835: probe of 20300000.sdhci failed with error -12
...
>> This is due to the following code:
...
>> What ends up happening, simply due to memory allocation order, is that
>> the memory writes inside usb_settoggle() end up setting the SDHCI struct
>> platform_device's num_resources to 0, so that it's call to
>> platform_get_resource() fails.
>>
>> With the DWC2 move patch reverted, some other random piece of memory is
>> being corrupted, which just happens not to cause any visible problem.
>> Likely it's some other struct platform_device that's already had its
>> resources read by the time DWC2 probes and corrupts them.
>>
>> (Yes, this was hard to find!)
> 
> Nice work, but how did you pinpoint this? Am I missing some option/tool
> or did I just not stare for long enough?

Well, there was a clear place where an issue was present; the resource
lookup in sdhci_pltfm_init() was failing, so I put a bunch of printfs
into that function to dump out the data platform_get_resource() used.
This clearly pointed at num_resources==0 being the problem. Next, I
dumped the same data from the code in drivers/of that sets it up, and it
was OK there, so I knew it was getting over-written somewhere. I then
basically added hundreds of calls to the same data dumping function
throughout kernel functions like really_probe() to track down the
location of the problem. Luckily, the behaviour was stable, so I wasn't
chasing a race/timing condition. Eventually I narrowed the window to the
few lines of code I mentioned in _dwc2_hcd_endpoint_reset(). It would
have been much harder if it was e.g. the USB HW DMAing to memory that
caused the corruption, so I was lucky:-)
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel




[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux