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
