On 01-05-08 22:47, Bjorn Helgaas wrote:
I want to understand this better. I think the case we're concerned about is this: Memory descriptor 0 is not assigned, i.e., its base and limit/range registers starting at 0x40 contain zeroes, but Descriptor 1, starting at 0x48, *is* assigned. The 2.6.25 "get_resources" code doesn't touch the resource table for Descriptor 0, so its entry remains "unset". The "set_resources" code skips Descriptor 0 because its resource table entry is "unset" and writes Descriptor 1.
Yes.
When I convert the table to a list, I have to make sure that we write the Descriptor 1 resources to the correct place starting at 0x48, not to the Descriptor 0 registers. To do this, I made "get_resources" set the pnp_resource.index field to the current descriptor index, and "set_resources" uses pnp_resource.index to compute the register address. However, PNPBIOS, PNPACPI, and even ISAPNP Resource Data is all based on the ordinal position in list (see the fourth paragraph of section 4.6.1 of the ISA spec). Having pnp_resource.index in addition to a list position adds a lot of confusion.
I agree. Got confused/uneasy about the difference myself looking at the dynamic code.
I think a better solution would be to get rid of pnp_resource.index and have "get_resources" add a "disabled" resource for Descriptor 0, so the Nth MEM resource in the list would always correspond to the Nth Memory Descriptor register. Does this make sense?
It does. Ofcourse, you can than also not reuse _UNSET resources as you did previously but that's for the best anyway.
In trying to come up with problems I'm only finding a difference in an added failure mode with respect to the static array if we run out of memory at a bad time and this is quite unserious.
Yes, I'd say to just do that. It might appear a bit clumsy from an implementation standpoint but the only thing this stuff should be doing is enable inane amounts of possible resources for one device without forcing them on all.
Rene -- 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
