lkml.org 
[lkml]   [2007]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: pci-disable-decode-of-io-memory-during-bar-sizing.patch


    On Tue, 30 Oct 2007, Arjan van de Ven wrote:
    >
    > the problem is... you're not supposed to mix both types of accesses.

    You have to, anyway. Even now the MMCONFIG stuff uses CONF1 cycles for
    startup.

    Also, there's reason to believe that mixing things up _has_ to work
    anyway, and if the issue is between "works in practice" and "theory says
    that you shouldn't mix", I'll take practice every time.

    Especially since we *know* that the theory is broken. Right now MMCONFIG
    is effectively disabled very aggressively because it's simply unusably
    flaky. So the choice is between:

    - don't use MMCONFIG at all, because it has so many problems
    - use MMCONFIG sparingly enough to hide the problems

    and what "you're supposed to do" is simply trumped by Real Life(tm).
    Because Intel screwed up so badly when they designed that piece of shit.

    (Where "screwed up badly" is the usual "left it to firmware people" thing,
    of course. Dammit, Intel *could* have just made it a real PCI BAR in the
    Northbridge, and specified it as such, and we wouldn't have these
    problems! But no, it had to be another idiotic "firmware tells where it
    is" thing)

    > > The fact is, CONF1 style accesses are just safer, and *work*.
    >
    > I would suggest a slight twist then: use CONF1 *until* you're using
    > something above 256, and then and only then switch to MMCONFIG from
    > then on for all accesses.

    No.

    Maybe if you do it per-device, and only *after* probing (ie we have seen
    multiple, and successful, accesses), but globally, absolutely not. That
    would be useless. The bugs we have had in this area have been exactly the
    kinds of things like "we don't know the real size of the MMCONFIG areas"
    etc.

    I could easily see device driver writers probing to see if something
    works, and I absolutely don't think we should just automatically enable
    MMCONFIG from then on.

    But maybe we could have a per-device flag that a driver *can* set. Ie have
    the logic be:

    - use MMCONFIG if we have to (reg >= 256)

    OR

    - use MMCONFIG if the driver specifically asked us to

    and then drivers that absolutely need it, and know they do, can set that
    flag. Preferably after they actually verified that it works.

    That way you _can_ get the "this is how you're supposed to do it"
    behaviour, but you get it when there is a reasonable chance that it
    actually works.

    And quite frankly, if you're not supposed to mix these things even across
    devices, then I think we are better off just doing what we effectively do
    now: mostly ignore the damn thing because it's too broken to use.

    Maybe somebody inside Intel could just clarify the documentation, and
    change it from "you're not supposed to mix" to "mix all you want".

    Linus
    -
    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-10-30 18:11    [W:0.049 / U:4.704 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site