Re: [PATCH 00/22] Explicitly deny IRQ0 in the USB host drivers

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

 



On 10/19/21 9:35 PM, Alan Stern wrote:
[...]
>>>>> Here are 22 patches against the 'usb-next' branch of Greg KH's 'usb.git' repo.
>>>>> The affected drivers use platform_get_irq() which can return IRQ0 (considered
>>>>> invalid, according to Linus) that means broken HCD when passed to usb_add_hcd()
>>>>> called at the end of the probe methods. I think that the solution to this issue
>>>>> is either explicitly deny or accept IRQ0 in usb_add_hcd()... /but/ here's this
>>>>> patch set to get the things going...
>>>>
>>>> Why not fix the root of the problem for your platform that is failing to
>>>> assign a valid irq for the device?
>>>>
>>>> Are you going to make this change to all callers of this function in the
>>>> kernel tree?
>>>
>>> Also, you should have gotten a huge WARNING in your kernel log if this
>>> happens to let you know that something bad is going on.
>>
>>    That's the relatively recent addition, yet it doesn't override IRQ0 to s/th
>> like -EINVAL.
>>
>>> Is this patch
>>> series going to really change any of that?
>>
>>    How? It doesn't touch drivers/base/platform.c...
>>
>>>
>>> What is the root problem here that you are trying to paper over with
>>> this patchset?
>>
>>    As I said, it would be preferrable to either deny IRQ0 in usb_add_hcd() or
>> just don't try to filter it out. The real problem is that usb_add_hcd() does
>> add a non-functioning HCD without the necessary IRQ handling (it only hooks
>> an IRQ when it's non-zero).
> 
> This is because some HCDs don't use interrupts (e.g., dummy-hcd).

   Ah, that was the missing piece of a puzzle, thanks!
   This series doesn't have an alternative then (other than ignoring :-))...

> Alan Stern

MBR, Sergey



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux