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

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

Dave Olson <olson@pathscale.com> writes:

> On Tue, 7 Nov 2006, Eric W. Biederman wrote:
> | 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.
>
> Yes.
>
> | Sure it is coming as 2 32bit words instead of a one big 64 bit one, but
> | that is simple to fix.
>
> It would be cleaner, but not absolutely necessary.
>
> | 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.
>
> The card does pay attention, and other programs such as lspci and the
> like also look at the config space.  They should definitely be kept
> in sync, and config writes are fairly cheap, anyway.

Well this is a rathole so it really isn't safe for lspci to play with
(races with the kernel accessing it)

This hole concept of you having the register but not connecting it up on
the card is rather bizarre.

> | 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.
>
> The HT layer should always do the config updates, since you are trying
> to clean up that layer.  Only the "extra" stuff (if any) should be done by
> the callback.

Fine by me.  That's why the patch was up for review.  That is just moving
the if statement I currently have.  So it should be trivial.  If that
won't break your card that is good enough for me.

Eric
-
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/