Re: 2.6.19-rc4: known unfixed regressions (v3)

[ebiederm@xmission.com (Eric W. Biederman)]

"Bryan O'Sullivan" <bos@serpentine.com> 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.

Eric