[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <17854.33603.655565.110084@cargo.ozlabs.ibm.com>
Date: Tue, 30 Jan 2007 10:29:07 +1100
From: Paul Mackerras <paulus@...ba.org>
To: michael@...erman.id.au
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>, tony.luck@...el.com,
grundler@...isc-linux.org, jeff@...zik.org,
linux-kernel@...r.kernel.org, kyle@...isc-linux.org,
linuxppc-dev@...abs.org, linux-pci@...ey.karlin.mff.cuni.cz,
brice@...i.com, greg@...ah.com, shaohua.li@...el.com,
mingo@...e.hu, David Miller <davem@...emloft.net>
Subject: Re: [PATCH 0/6] MSI portability cleanups
Michael Ellerman writes:
> You can read config space, but it's not clear to me if the HV is allowed
> to filter it and hide things. It's also possible that the device
It appears that the HV does not prevent us from reading or writing any
config space registers for functions that are assigned to us.
> supports MSI, but for some reason the HV doesn't allow it on that device
> etc. so you really have to ask the HV if it's enabled. So pci_find_cap()
> shouldn't crash or anything, but it may lie to you.
It's possible that the device can do MSI(X), but that using MSI(X)
requires other platform resources (e.g. interrupt source numbers) and
there are none free. I believe the platform guarantees a minimum
number of MSI(X) interrupts per function, but a pci_enable_msix() call
may not be able to give the driver as many MSI-X interrupts as it is
requesting even if the function can handle that many.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists