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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux