Re: [patch 00/37] PNP resource_table cleanups, v2

[Rene Herman]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/