lkml.org 
[lkml]   [2007]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))
    Alan wrote:
    >> 2.6.0 - 2.6.19: libata guarantees that all PCI BARs are reserved to the
    >> libata driver.
    >
    > Please read the code Jeff. The old IDE quirk code in the PCI layer blanked
    > BAR 0 to BAR 3 of a compatibility mode controller

    (a) I'm well of aware of this, and (b) that changes nothing.

    I said "PCI BARs" for a reason. libata was written according to the
    following model:

    1) Programmatically reserve /all/ resources associated with
    our PCI device
    2) Manually reserve resources associated with our PCI device,
    but are not listed in struct pci_dev.

    You have changed this to:

    1) Manually reserve /some/ resources associated with PCI device
    2) Manually reserve resources associated with our PCI device,
    but are not listed in struct pci_dev.

    But then 2.6.21 goes back to:

    1) Programmatically reserve /all/ resources associated with
    our PCI device
    2) Manually reserve resources associated with our PCI device,
    but are not listed in struct pci_dev.

    Maybe I can say it more clearly by telling you how to fix the regression
    you have introduced: Loop through all BAR resources in struct pci_dev,
    and reserve them if they are not already reserved by libata earlier in
    the code. There. Regression fixed.

    (but then we rewrite this code again in 2.6.21)


    > You then request_region 0x1f0 and 0x170 (BAR 0 and BAR 2) directly. You
    > never request the legacy BAR 1 and BAR 3 because they were erased by the
    > PCI quirk code and thus never claim the other port. Thats been a bug since
    > day one but it never seemed worth fixing in the short term.

    Yes -- that's a bug, one that existed prior to the "it doesn't boot"
    combined mode regression everybody complained about. I'm talking about
    a new regression just introduced via
    dc3c3377f03634d351fafdfe35b237b283586c04, not a old bug that existed
    prior to the regression introduced in
    368c73d4f689dae0807d0a2aa74c61fd2b9b075f.

    Jeff


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-01-03 00:47    [W:3.726 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site