On Friday 27 June 2008 08:54:04 am David Howells wrote: > Rene Herman <rene.herman@xxxxxxxxxxxx> wrote: > > > Well, it's been promoted from a u8, so no need for that anyway, but <shrug>. > > My logic is that in commit 95b24192cf27631dc11541e97c430389320e7a93 it says > the following: > > ACPI Extended Interrupt Descriptors can encode 32-bit interrupt > numbers, so an interrupt number may exceed the size of the bitmap > we use to track possible IRQ settings. > > so the field in 'struct acpi_resource_irq' might at some point increase to be > a 32-bit unsigned value. Otherwise there's no point having the check at all, > right? There are two flavors of ACPI IRQ descriptors, which the CA puts into acpi_resource_irq and acpi_resource_extended_irq. struct acpi_resource_irq will never have an IRQ number larger than 255. PNP_IRQ_NR is currently 256, so we don't really have a problem there. struct acpi_resource_extended_irq has a u32 IRQ value, and that's where I'm worried. We already have plenty of devices with GSIs in the 2000 range. In most cases, I think these are PCI devices, so these GSIs appear in _PRT (PCI routing tables) rather than in _PRS. But there is the possibility that we could see a configurable ACPI device with a large GSI, and that's why I added the check. I think what happened here is that I meant to put this test in pnpacpi_parse_ext_irq_option(), but somehow it got into pnpacpi_parse_irq_option() instead. I'll try to sort this out today. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
