Benjamin Herrenschmidt <[email protected]> writes:
>> The other big change is that I added a field to irq_desc to point
>> at the msi_desc. This removes the conflicts with the existing pointer
>> fields and makes the irq -> msi_desc mapping useable outside of msi.c
>
> I'm not even sure we would have needed that with Michael's mecanism in
> fact. One other reason why I prefer it.
>
> Basically, backends like MPIC etc... don't need it. The irq chip
> operations are normal MPIC operations and don't need to know they are
> done on an MSI nor what MSI etc... and thus we don't need it. Same with
> RTAS.
If you get rid of the bass ackwards setup_msi_msg operation they do,
so you can support at least one write_msi_msg call.
> On the other hand, x86 needs it, but then, x86 uses it's own MSI
> specific irq_chip, in which case it can use irq_desc->chip_data as long
> as it does it within the backend.
Most of the uses are within msi.c as the code is currently structured
which means you can't use it that way.
> So I may have missed a case where a given backend might need both that
> irq -> msi_desc mapping -and- use irq_desc->chip_data for other things,
> but that's one thing I was hoping we could avoid with Michael's code.
That is where we are today. Find a way to remove the code that uses it
and it can go away.
>> The only architecture problem that isn't solvable in this context is
>> the problem of supporting the crazy hypervisor on the ppc RTAS, which
>> asks us to drive the hardware but does not give us access to the
>> hardware registers.
>
> So you are saying that we should use your model while admitting that it
> can't solve our problems...
My approach can solve your problems with a few tweaks just like Michaels
approach would have needed to solve mine.
> I really don't understand why you seem so totally opposed to Michael's
> approach which definitely looks to me like the sane thing to do. Note
> that in the end, Michael's approach isn't -that- different from yours,
> just a bit more abstracted.
1) Because every one tells me it is the greatest thing since sliced bread,
and when I look it simply doesn't work, and my feeling would be it would
be a complete retesting effort of all currently supported architectures
to make Michaels code work.
2) Because it was scrap and replace, which is a horrible way to deal with
a problem when we have 3 architectures working already.
Honestly I think Michael and I can get along but all of the cheer leaders seem
to be exacerbating the situation.
I do agree Michael's approach isn't that different than mine and I think we
can converge on a single implementation. To a large extent that is what
my patchset is about. Moving the current code far enough it is usable,
and a reasonable basis for more work.
I don't write the current code but since I touched it and started cleaning
it up I seem to be stuck with it. So I will be happy to take care of it
until we get a version that all architectures can use.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
