On Tue, Oct 19, 2021 at 09:28:08PM +0300, Sergey Shtylyov wrote: > On 10/19/21 10:31 AM, Greg Kroah-Hartman 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). Alan Stern
