Re: Panda: USB crash with today's linux-next

["Cousson, Benoit" <b-cousson@ti.com>]

On 5/14/2012 2:47 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, May 14, 2012 at 03:29:21PM +0300, Felipe Balbi wrote:
>> On Mon, May 14, 2012 at 03:24:11PM +0300, Tomi Valkeinen wrote:
>>> On Mon, 2012-05-14 at 15:15 +0300, Felipe Balbi wrote:
>>>
>>>> looks like MUSB is probing before transceiver driver... could it be ?
>>>> Can you check transceiver has actually probed ? I guess panda's using
>>>> twl6030-usb.c
>>>
>>> Ah. Perhaps it's then about this?
>>>
>>> [    0.352905] Skipping twl internal clock init and using bootloader value (unknown osc rate)
>>> [    0.354034] twl 1-0048: PIH (irq 39) chaining IRQs 352..372
>>> [    0.356079] VUSB: 3300 mV normal standby
>>> [    0.358123] genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 356
>>> [    0.358215] twl6030_usb twl6030_usb: can't get IRQ 356, err -22
>>> [    0.358398] twl6030_usb: probe of twl6030_usb failed with error -22
>>
>> sounds about right. Now, why can't it get the IRQ... Benoit, is this
>> related to your sparse irq/irq_domain changes ?
>
> Looks like twl6030-irq still missed conversion to threaded IRQ. It still
> has that ugly ass kthread to handle the IRQs. Oh well, yet another
> broken OMAP driver...

Well, yeah, I did not clean all that mess.

That being said, we did have some issue recently as well, but due to the 
increase of IRQ number and the fact the NR_IRQS is still used since 
SPARSE_IRQ migration is not completed.

At least we saw similar issue with OMAP5.

Maybe increasing NR_IRQS will fix that, but in this case, it looks like 
the IRQ might already been used by someone else.
This is probably because something is still using the hard coded IRQ 
BASE number from the irqs.h define.

I was planning to get rid of them to highlight the broken driver / board 
that might still used them. But this is on my TODO list :-(

Regards,
Benoit