(In reply to Hans de Goede from comment #78)
> (In reply to Lukas Kahnert from comment #76)
> > This error happens because your patch only fixes the mis-detection of the
> > IRQ. There ist still https://bugzilla.kernel.org/show_bug.cgi?id=199529
> > which needs also bei fixed to get the touchscreen work.
> 
> Right, I figured that out now, actually I believe that with your hack to
> drivers/acpi/resource.c the changes you made to drivers/base/platform.c
> should no longer be necessary.
> 
> We've been looking at the wrong part of the DSDT the culprit is not:
> 
> Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
>                     {
>                         0x00000007,
>                     }
> 
> This uses an extended interrupt syntax, so acpi_dev_get_irqresource() gets
> called with legacy == false and the troublesome acpi_get_override_irq()
> never happens.
> 
> I believe the real culprit is:
> 
>     Scope (_SB.PCI0)
>     {
>         Device (SMBD)
>         {
>             Name (_HID, "SMB0001")  // _HID: Hardware ID
>             Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource
> Settings
>             {
>                 IO (Decode16,
>                     0x0B20,             // Range Minimum
>                     0x0B20,             // Range Maximum
>                     0x20,               // Alignment
>                     0x20,               // Length
>                     )
>                 IRQ (Level, ActiveLow, Shared, )
>                     {7}
>             })
>         }
>     }
> 
> Which does use a legacy style IRQ resource, this causes
> acpi_dev_get_irqresource() to be called with legacy == true and then the
> troublesome acpi_get_override_irq() happens.
> 
> I believe that this troublesome node gets parsed before the AMDI0030 node
> and then by the time the AMDI0030 node happens, inside
> acpi_dev_get_irqresource() we hit the else of:
> 
>         irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
>         if (irq >= 0) {
>                 res->start = irq;
>                 res->end = irq;
>         } else {
>                 acpi_dev_irqresource_disabled(res, gsi);
>         }
> 
> Which sets the DISABLED flag, which is causing the issue in
> drivers/base/platform.c . The reason we hit the else path is because of the
> earlier enumeration of the same interrupt with conflicting trigger /
> polarity settings so the second one fails with -EBUSY (it would work if the
> flags would match).
> 
> My new attempt deals with this by adding the "SMB0001" HID to the blacklist
> for creating platform devices, so that acpi_dev_get_resources() does not get
> called on it at all, avoiding the call of acpi_dev_get_irqresource() with
> legacy == false.
> 
> The not creating of a platform_device for the "SMB0001" HID is not an issue
> since the driver for it is an acpi bus driver not a platform bus driver.

Thanks for this good explanation :)

I can also confirm that your patch works on my laptop

(In reply to Hans de Goede from comment #81)
> p.s.
> 
> I plan to add the following to the commit msg, please let me know if you've
> objections against this:
> 
> Reported-by: Lukas Kahnert <email address hidden>
> Tested-by: Marc <email address hidden>

I'm glad that I could help :)