[BUG] platform_get_irq_byname_optional -- dwc3-haps registers IRQ 0, WARN on first gadget init

[BUG] platform_get_irq_byname_optional -- dwc3-haps registers IRQ 0, WARN on first gadget init

[Farhad Alemi]

Hello,

As part of the kernel research at ASU's SEFCOM
lab, we hit the crash below. Crash reports can be found here:

  https://github.com/farhad-alemi/public_bug_reports/tree/main/149-usb-dwc3-haps-registers-irq-0/

  dwc3 dwc3.2.auto: Configuration mismatch. dr_mode forced to gadget
  0 is an invalid IRQ number
  WARNING: drivers/base/platform.c:492 at
platform_get_irq_byname_optional+0x1ed/0x220, CPU#1: repro/9498
  Call Trace:
   platform_get_irq_byname_optional+0x1ed/0x220
   dwc3_gadget_init+0x607/0x2170
   dwc3_core_init_mode+0x2f8/0x790
   dwc3_core_probe+0x2345/0x2850
   dwc3_probe+0x100/0x150
   platform_probe+0xf9/0x190
   really_probe+0x267/0xaf0
   __driver_probe_device+0x1e2/0x350
   driver_probe_device+0x4f/0x240
   __device_attach_driver+0x270/0x410
   bus_for_each_drv+0x258/0x2f0
   __device_attach+0x2c5/0x450

Our reproducer.c is available upon request.

Happy to test a patch if that would help.

Regards,

Re: [BUG] platform_get_irq_byname_optional -- dwc3-haps registers IRQ 0, WARN on first gadget init

[Greg Kroah-Hartman]

On Fri, Aug 28, 2026 at 05:34:05AM +0000, Farhad Alemi wrote:
> Hello,
> 
> As part of the kernel research at ASU's SEFCOM
> lab, we hit the crash below. Crash reports can be found here:
> 
>   https://github.com/farhad-alemi/public_bug_reports/tree/main/149-usb-dwc3-haps-registers-irq-0/

Digging through random urls isn't that helpful to us, please include all
of the needed information in the email itself.

Remember, some of us get 1000+ emails a day to handle :(

> 
>   dwc3 dwc3.2.auto: Configuration mismatch. dr_mode forced to gadget
>   0 is an invalid IRQ number
>   WARNING: drivers/base/platform.c:492 at
> platform_get_irq_byname_optional+0x1ed/0x220, CPU#1: repro/9498
>   Call Trace:
>    platform_get_irq_byname_optional+0x1ed/0x220
>    dwc3_gadget_init+0x607/0x2170
>    dwc3_core_init_mode+0x2f8/0x790
>    dwc3_core_probe+0x2345/0x2850
>    dwc3_probe+0x100/0x150
>    platform_probe+0xf9/0x190
>    really_probe+0x267/0xaf0
>    __driver_probe_device+0x1e2/0x350
>    driver_probe_device+0x4f/0x240
>    __device_attach_driver+0x270/0x410
>    bus_for_each_drv+0x258/0x2f0
>    __device_attach+0x2c5/0x450
> 
> Our reproducer.c is available upon request.
> 
> Happy to test a patch if that would help.

Please send a patch.

thanks,

greg k-h

Re: [BUG] platform_get_irq_byname_optional -- dwc3-haps registers IRQ 0, WARN on first gadget init

[Greg Kroah-Hartman]

On Fri, Aug 28, 2026 at 05:34:05AM +0000, Farhad Alemi wrote:
> Hello,
> 
> As part of the kernel research at ASU's SEFCOM
> lab, we hit the crash below. Crash reports can be found here:
> 
>   https://github.com/farhad-alemi/public_bug_reports/tree/main/149-usb-dwc3-haps-registers-irq-0/
> 
>   dwc3 dwc3.2.auto: Configuration mismatch. dr_mode forced to gadget
>   0 is an invalid IRQ number
>   WARNING: drivers/base/platform.c:492 at
> platform_get_irq_byname_optional+0x1ed/0x220, CPU#1: repro/9498
>   Call Trace:
>    platform_get_irq_byname_optional+0x1ed/0x220
>    dwc3_gadget_init+0x607/0x2170
>    dwc3_core_init_mode+0x2f8/0x790
>    dwc3_core_probe+0x2345/0x2850
>    dwc3_probe+0x100/0x150
>    platform_probe+0xf9/0x190
>    really_probe+0x267/0xaf0
>    __driver_probe_device+0x1e2/0x350
>    driver_probe_device+0x4f/0x240
>    __device_attach_driver+0x270/0x410
>    bus_for_each_drv+0x258/0x2f0
>    __device_attach+0x2c5/0x450
> 
> Our reproducer.c is available upon request.
> 
> Happy to test a patch if that would help.

Again, see my prior emails.  No idea why you are still sending these
out, do we need to set a ban on this address to our lists?

greg k-h

Re: [BUG] platform_get_irq_byname_optional -- dwc3-haps registers IRQ 0, WARN on first gadget init

[Farhad Alemi]

Greg,

You're right; sorry. I've stopped sending.

I'll resend individually, with the reproducer inline, and a proposed fix where I
can write one. If you'd rather prefer that these not go to
the lists at all, say so and I'll drop it.

On Thu, Aug 27, 2026 at 11:12 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Fri, Aug 28, 2026 at 05:34:05AM +0000, Farhad Alemi wrote:
> > Hello,
> >
> > As part of the kernel research at ASU's SEFCOM
> > lab, we hit the crash below. Crash reports can be found here:
> >
> >   https://github.com/farhad-alemi/public_bug_reports/tree/main/149-usb-dwc3-haps-registers-irq-0/
> >
> >   dwc3 dwc3.2.auto: Configuration mismatch. dr_mode forced to gadget
> >   0 is an invalid IRQ number
> >   WARNING: drivers/base/platform.c:492 at
> > platform_get_irq_byname_optional+0x1ed/0x220, CPU#1: repro/9498
> >   Call Trace:
> >    platform_get_irq_byname_optional+0x1ed/0x220
> >    dwc3_gadget_init+0x607/0x2170
> >    dwc3_core_init_mode+0x2f8/0x790
> >    dwc3_core_probe+0x2345/0x2850
> >    dwc3_probe+0x100/0x150
> >    platform_probe+0xf9/0x190
> >    really_probe+0x267/0xaf0
> >    __driver_probe_device+0x1e2/0x350
> >    driver_probe_device+0x4f/0x240
> >    __device_attach_driver+0x270/0x410
> >    bus_for_each_drv+0x258/0x2f0
> >    __device_attach+0x2c5/0x450
> >
> > Our reproducer.c is available upon request.
> >
> > Happy to test a patch if that would help.
>
> Again, see my prior emails.  No idea why you are still sending these
> out, do we need to set a ban on this address to our lists?
>
> greg k-h

Re: [BUG] platform_get_irq_byname_optional -- dwc3-haps registers IRQ 0, WARN on first gadget init

[Greg Kroah-Hartman]

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Thu, Aug 27, 2026 at 11:16:24PM -0700, Farhad Alemi wrote:
> Greg,
> 
> You're right; sorry. I've stopped sending.
> 
> I'll resend individually, with the reproducer inline, and a proposed fix where I
> can write one. If you'd rather prefer that these not go to
> the lists at all, say so and I'll drop it.

We always want bugfixes, always send those.  But random "here's a kernel
splat" with no information as to what you were doing to cause this, nor
any help in determining if it even is valid or not, is not helpful to
anyone, least of all yourself.

See how syzbot works and emulate that, as it seems like you are doing
almost the same exact thing.

good luck!

greg k-h