[lkml]   [2008]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 00/37] PNP resource_table cleanups, v2
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.


> 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.


 \ /
  Last update: 2008-05-04 16:17    [W:0.056 / U:3.976 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site