[lkml]   [2006]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.19-rc4: known unfixed regressions (v3)
    "Bryan O'Sullivan" <> writes:

    > Eric W. Biederman wrote:
    >> How comes the driver fixes in the context of my patches?
    > The fix is simple enough, it's just not as clean as I'd like. I have to pull
    > apart the contents of the ht_irq_msg that the new update hook is getting passed,
    > in order to get the vector out, so that I can reprogram the offending chip
    > register after I've done the config space writes. It's a pretty roundabout way
    > to do the job.

    Huh? As I read the ipath code I am passing you the value that needs to go
    into ipath->int_config and thus into dd->ipath_kregs->kr_interrupt_config.

    Sure it is coming as 2 32bit words instead of a one big 64 bit one, but
    that is simple to fix.

    If your card doesn't pay attention to configuration space access cycles then
    there should be no reason to write the value there. If your card does pay
    attention to the configuration space access cycles it should be trivial to
    make this work.

    Please stop getting stuck on your existing hack that only put in the vector
    number and didn't put in any of the other interrupt routing information.

    If you really need to write to both the config space registers and your
    magic shadow copy of the register I can certainly do the config space
    writes for you. I just figured it would be more efficient not to.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-11-07 18:37    [W:0.029 / U:29.820 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site