Hi, I recently filed bug 9487 (http://bugzilla.kernel.org/show_bug.cgi?id=9487 ), which prevents the pen on most, if not all, Toshiba Tablet PCs from waking up from suspend mode. I don't think the bug was announced on this list since I originally filed it in the wrong category. Anyway, I investigated the issue further and here is what happens as far as I can tell: During boot, _CRS is called and the returned buffer is converted into the kernel's own format. This is not a one-to-one mapping. Specifically, the ACPI spec allows high true, edge sensitive, non-shareable interrupts to be represented by 3-byte descriptors, but 4-byte descriptors that set the appropriate flags are also possible, which is what these Tablet PCs choose to do for their serial port. Upon resume, _SRS is called, so the internal representation needs to be converted back to an AML buffer, but at this point the information how the original buffer looked like is lost. In my case, the kernel chooses a three-byte descriptor that evidently throws off the device's firmware, which expects the buffer to be in the same format as returned by _CRS. Of course, this is not technically a kernel bug because the buffer passed to _SRS complies with the ACPI standard, but I think this sort of problem is fairly common. The other instance I'm aware of actually goes in the opposite direction: The The Fujitsu Lifebook C1020's parallel port returns a three-byte descriptor and appears to require a three-byte descriptor to be passed to _SRS in order to wake up (see http://bugzilla.kernel.org/show_bug.cgi?id=6316 ). Presumably Windows does not alter the form of the buffer, so it's reasonable that linux should do the same. I've created a patch that keeps track of whether _CRS returned a three or four-byte descriptor by adding a new field descriptor_length to acpi_resource_irq and respects that information during conversion back to an AML resource. It's attached to bug 9487. When I made the changes I stumbled upon the following bugs in rsparser.c that I took the liberty of correcting, but I'd be happy to separate the changes into two patches if that's desired: * decode_irq_flags would leave values uninitialized if additional flags such as IORESOURCE_IRQ_SHAREABLE were set. * pnpacpi_encode_irq would deduce sharable from triggering and polarity. This may well be okay in practice, but the IORESOURCE_IRQ_SHAREABLE flag should be used (the same goes for pnpacpi_encode_ext_irq, btw). * pnpacpi_encode_ext_irq would write to resource->data.irq.sharable which is actually data.extended_irq.polarity. Thanks, Tom - 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
