(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:
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:
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.
(In reply to Lukas Kahnert from comment #76) /bugzilla. kernel. org/show_ bug.cgi? id=199529
> This error happens because your patch only fixes the mis-detection of the
> IRQ. There ist still https:/
> 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)
0x0B20, // Range Minimum
0x0B20, // Range Maximum
0x20, // Alignment
0x20, // Length
)
{ 7}
{
Device (SMBD)
{
Name (_HID, "SMB0001") // _HID: Hardware ID
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
IO (Decode16,
IRQ (Level, ActiveLow, Shared, )
})
}
}
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);
res-> start = irq;
res-> end = irq;
acpi_ dev_irqresource _disabled( res, gsi);
if (irq >= 0) {
} else {
}
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.