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