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

[Sergey Shtylyov <s.shtylyov@omp.ru>]

On 10/19/21 9:46 PM, Sergey Shtylyov 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!

   And some drivers prefer to manage the IRQs themselves too.

>    This series doesn't have an alternative then (other than ignoring :-))...

   Or overriding IRQ0 to an error code in platform_get_irq(), finally, of/c...

MBR, Sergey