lkml.org 
[lkml]   [2008]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [patch 00/37] PNP resource_table cleanups, v2
    Date
    On Thursday 03 April 2008 09:54:51 am Rene Herman wrote:
    > However, now that you made me look closer and in context -- there's actually
    > a possibly somewhat serious problem here.
    >
    > isapnp_read_resources() stores the resources as read from the hardware at
    > the index in the table that matches the actual index in the hardware and
    > isapnp_set_resources() stores them back into those same hardware indices.
    >
    > Now by using pnp_add_foo_resource() which just scans for the first _UNSET
    > resource, the resources might not end up in the same linear position in
    > table/list if intermediate resources were unset in hardware (!ret). A
    > subsequent isapnp_set_resources() would them restore the value to the wrong
    > hardware index.
    >
    > The IORESOURCE_ flags currently reserve too few bits (IORESOURCE_BITS, 8)
    > to be able to store the hardware index: IORESOURCE_MEM and IORESOURCE_DMA
    > need 2 and 1 respectively and there are 1 and 0 available respectively. It's
    > ofcourse possible to hijack a few more bits in IORESOURCE_ flags but you're
    > turning this into a list. I suppose the idea is to make it a simple list of
    > struct resource, but perhaps a resource-private "driver_data" sort of field
    > comes in handy for more than this already? Swiping more of IORESOURCE_ is a
    > bit ugly...
    >
    > In any case, I missed this, but ISAPnP is still (at least in principle)
    > broken with the current set therefore.

    Hmm... you're right. And I think it could bite PNPBIOS and PNPACPI
    as well -- they don't read/write hardware registers directly, but the
    firmware still depends on preserving the resource order. I'll have to
    ponder that for a while.

    Bjorn


    \
     
     \ /
      Last update: 2008-04-03 18:47    [W:4.143 / U:0.196 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site