Re: [PATCH 2/2] Initial generic hypertransport interrupt support.

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

Dave Olson <olson@pathscale.com> writes:

> On Thu, 13 Jul 2006, Eric W. Biederman wrote:
> | And I tested it on one of them.  The problem is that there is no API in
> | the kernel for properly handling hypertransport interrupts or even faking
> | it well currently.  There is no shame in breaking a bad unmaintainable
> | hack, as I did.  The responsible thing is to when you find one to
> | fix up the code so that things work by design in a maintainable way,
> | which I am attempting to do.
>
> There's no problem providing a better replacement, just make sure
> that the existing drivers can use it.

I am working on that.  What broke the drivers was the removal of
the assumption that irq == vector.  Which was a bad hack and never
always true.

> | All existing drivers that use HT interrupts are broken by design.
>
> That's a statement designed to provoke arguments, and I'll just leave
> it that we disagree.

I am just saying that if you don't have the infrastructure you need 
you cannot implement things correctly.  It is no fault of the driver
authors.  Except possibly not standing up and asking for some
infrastructure to do what needs to be done.

> | Sure.  In that case can I please have a good description of what
> | weird hacks your hardware designers have done.
>
> There's really nothing special at all about the interrupt
> setup, except in one very minor way.   The value of the HT interrupt
> destination address needs to be copied from HT config space, to
> an internal chip register (which is, can, and should be, handled by
> the driver init code).

The kernel changes the value at runtime, based upon user input.
I assume your mirror register needs to be updated after every change.

Since the kernel changes the value at runtime, and since a different
register needs to be written to, I can't quite use the generic code I
have written as is.  

> | The functions I exported I intend to export.  The complaint seems to
> | be that you don't have anything that will work on earlier kernels.
> | I have to agree you don't.
>
> Huh?  I didn't say anything that could possibly be read as applying
> to earlier kernels, and to be crystal clear, that's not my concern
> at all.
>
> Maybe somebody else can articulate what I'm trying to say, but I don't
> think I can say it in a clearer way.

Ok.  I guess I was reading something in that wasn't there.  So see a
similarity and say it looks like that can be generalized.  I look and
I don't see what having a magic DWIM enable irq interface would help
with.  The counter argument is essentially that if you have multiple
options implemented but some of them are buggy

Eric