LKML Archive on
help / color / mirror / Atom feed
From: (Eric W. Biederman)
To: Benjamin Herrenschmidt <>
Cc: Greg Kroah-Hartman <>,
	Tony Luck <>,
	Grant Grundler <>,
	Ingo Molnar <>,,
	Kyle McMartin <>,, Brice Goglin <>,,,
	"David S. Miller" <>
Subject: Re: [PATCH 0/6] MSI portability cleanups
Date: Sun, 28 Jan 2007 14:34:00 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <1170015805.26655.15.camel@localhost.localdomain> (Benjamin Herrenschmidt's message of "Mon, 29 Jan 2007 07:23:25 +1100")

Benjamin Herrenschmidt <> 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.


      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]

Reply instructions:

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).