From: ebiederm@xmission.com (Eric W. Biederman)
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Matthew Wilcox <matthew@wil.cx>,
Greg Kroah-Hartman <greg@kroah.com>, Ingo Molnar <mingo@elte.hu>,
Russell King <rmk-pci@arm.linux.org.uk>,
linuxppc-dev@ozlabs.org, Thomas Gleixner <tglx@linutronix.de>,
linux-pci@atrey.karlin.mff.cuni.cz,
"David S.Miller" <davem@davemloft.net>
Subject: Re: [RFC/PATCH 4/7] Powerpc MSI implementation
Date: Tue, 07 Nov 2006 19:43:15 -0700 [thread overview]
Message-ID: <m1wt6664l8.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <1162951680.28571.627.camel@localhost.localdomain> (Benjamin Herrenschmidt's message of "Wed, 08 Nov 2006 13:08:00 +1100")
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> My initial idea was that the msi_info structure would have a variable
> lenght, that is, would end with msi_desc[0] and would be allocated to
> the the right size, but it might suck a bit :-)
That could work. The whole array of interrupts thing allocated on
device probe, I question a little bit. I can just about see allocating
another interrupt if you can when a network device start getting another
flow through it. But it is working well enough at the moment it doesn't
appear time to run out and change the drivers.
>> Hopefully I can look at this a little more this evening and see what we
>> need to do to harmonize the two msi implementations.
>
> Thanks !
I'm still having a hard time wrapping my head around the sanity of not letting
the kernel touch the hardware in the presence of a hypervisor. How do you cope
with hardware that follows a specification the hypervisor is not aware of?
This seems to be a violation of the principle that the driver knows the hardware
better than some generic layer.
Eric
next prev parent reply other threads:[~2006-11-08 2:44 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-07 7:21 [RFC/PATCH 0/7] Powerpc MSI Implementation Michael Ellerman
2006-11-07 7:21 ` [RFC/PATCH 2/7] Make some MSI-X #defines generic Michael Ellerman
2006-11-13 18:31 ` patch pci-make-some-msi-x-defines-generic.patch added to gregkh-2.6 tree gregkh
2006-11-07 7:21 ` [RFC/PATCH 1/7] Add #defines for Hypertransport MSI fields Michael Ellerman
2006-11-07 8:01 ` Segher Boessenkool
2006-11-07 7:21 ` [RFC/PATCH 3/7] Rip out the existing powerpc msi stubs Michael Ellerman
2006-11-07 7:21 ` [RFC/PATCH 4/7] Powerpc MSI implementation Michael Ellerman
2006-11-07 20:07 ` Matthew Wilcox
2006-11-07 20:14 ` Russell King
2006-11-07 20:40 ` Benjamin Herrenschmidt
2006-11-07 20:44 ` Matthew Wilcox
2006-11-07 20:48 ` Russell King
2006-11-07 21:02 ` Matthew Wilcox
2006-11-07 22:25 ` Russell King
2006-11-07 22:29 ` Benjamin Herrenschmidt
2006-11-07 23:11 ` Eric W. Biederman
2006-11-08 0:15 ` Benjamin Herrenschmidt
2006-11-08 1:33 ` Eric W. Biederman
2006-11-08 2:08 ` Benjamin Herrenschmidt
2006-11-08 2:43 ` Eric W. Biederman [this message]
2006-11-08 3:02 ` Benjamin Herrenschmidt
2006-11-07 20:39 ` Benjamin Herrenschmidt
2006-11-07 7:21 ` [RFC/PATCH 5/7] RTAS " Michael Ellerman
2006-11-08 20:16 ` Jake Moilanen
2006-11-08 23:35 ` Michael Ellerman
2006-11-07 7:21 ` [RFC/PATCH 6/7] MPIC MSI backend Michael Ellerman
2006-11-07 8:27 ` Segher Boessenkool
2006-11-07 8:42 ` Benjamin Herrenschmidt
2006-11-07 9:04 ` Segher Boessenkool
2006-11-07 9:16 ` Benjamin Herrenschmidt
2006-11-07 11:12 ` Segher Boessenkool
2006-11-07 7:21 ` [RFC/PATCH 7/7] Enable MSI on Powerpc Michael Ellerman
2006-11-07 7:41 ` [RFC/PATCH 0/7] Powerpc MSI Implementation Benjamin Herrenschmidt
2006-11-07 8:02 ` Greg KH
2006-11-08 5:18 ` Michael Ellerman
2006-11-08 10:26 ` Eric W. Biederman
2006-11-08 23:33 ` Michael Ellerman
2006-11-09 7:36 ` Segher Boessenkool
2006-11-13 6:05 ` Michael Ellerman
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1wt6664l8.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=benh@kernel.crashing.org \
--cc=davem@davemloft.net \
--cc=greg@kroah.com \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=linuxppc-dev@ozlabs.org \
--cc=matthew@wil.cx \
--cc=mingo@elte.hu \
--cc=rmk-pci@arm.linux.org.uk \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.