LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: firstname.lastname@example.org (Eric W. Biederman)
To: Benjamin Herrenschmidt <email@example.com>
Cc: Greg Kroah-Hartman <firstname.lastname@example.org>,
Tony Luck <email@example.com>,
Grant Grundler <firstname.lastname@example.org>,
Ingo Molnar <email@example.com>,
Kyle McMartin <firstname.lastname@example.org>,
email@example.com, Brice Goglin <firstname.lastname@example.org>,
"David S. Miller" <email@example.com>
Subject: Re: [PATCH 0/6] MSI portability cleanups
Date: Sun, 28 Jan 2007 14:34:00 -0700 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: <email@example.com> (Benjamin Herrenschmidt's message of "Mon, 29 Jan 2007 07:23:25 +1100")
Benjamin Herrenschmidt <firstname.lastname@example.org> 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
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.
prev parent reply other threads:[~2007-01-28 21:35 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1169714047.65693.647693675533.qpush@cradle>
2007-01-28 19:40 ` Eric W. Biederman
2007-01-28 19:42 ` [PATCH 1/6] msi: Kill msi_lookup_irq Eric W. Biederman
2007-01-28 19:44 ` [PATCH 2/6] msi: Remove msi_lock Eric W. Biederman
2007-01-28 19:45 ` [PATCH 3/6] msi: Fix msi_remove_pci_irq_vectors Eric W. Biederman
2007-01-28 19:47 ` [PATCH 4/6] msi: Remove attach_msi_entry Eric W. Biederman
2007-01-28 19:52 ` [PATCH 5/6] msi: Kill the msi_desc array Eric W. Biederman
2007-01-28 19:56 ` [PATCH 6/6] msi: Make MSI useable more architectures Eric W. Biederman
2007-01-28 22:01 ` [PATCH 1/6] msi: Kill msi_lookup_irq Paul Mackerras
2007-01-28 22:18 ` Eric W. Biederman
2007-01-28 20:23 ` [PATCH 0/6] MSI portability cleanups Benjamin Herrenschmidt
2007-01-28 20:47 ` Jeff Garzik
2007-01-28 21:20 ` Eric W. Biederman
2007-01-28 21:26 ` Ingo Molnar
2007-01-28 22:09 ` Benjamin Herrenschmidt
2007-01-28 23:26 ` Eric W. Biederman
2007-01-28 23:37 ` David Miller
2007-01-29 5:18 ` Eric W. Biederman
2007-01-29 5:25 ` David Miller
2007-01-29 5:58 ` Eric W. Biederman
2007-01-29 6:05 ` Benjamin Herrenschmidt
2007-01-29 8:28 ` Eric W. Biederman
2007-01-29 9:03 ` Eric W. Biederman
2007-01-29 10:11 ` Michael Ellerman
2007-01-29 20:32 ` Benjamin Herrenschmidt
2007-01-29 23:29 ` Paul Mackerras
2007-01-29 23:40 ` Benjamin Herrenschmidt
2007-01-29 20:22 ` Benjamin Herrenschmidt
2007-01-29 23:05 ` Paul Mackerras
2007-01-30 19:32 ` Segher Boessenkool
2007-01-29 1:33 ` Benjamin Herrenschmidt
2007-02-01 4:29 ` Greg KH
2007-01-28 23:44 ` David Miller
2007-01-28 22:11 ` Eric W. Biederman
2007-01-28 23:42 ` David Miller
2007-01-28 21:34 ` Eric W. Biederman [this message]
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH 0/6] MSI portability cleanups' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).