[PATCH 3/4] Simplify rtas_change_msi() error semantics

Michael Ellerman michael at ellerman.id.au
Tue Oct 2 17:40:25 EST 2007


On Tue, 2007-10-02 at 16:24 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2007-10-02 at 15:58 +1000, Michael Ellerman wrote:
> > > Looks allright, just a question tho... what do we do if it fails ?
> > Do we
> > > try to fallback to a lower number of MSIs ? Or what ? Dead device ?
> > 
> > That's all up to the device driver. In theory the driver could try again
> > with a lower count - but that might require extra logic in the driver to
> > handle shared irq handlers etc. In practice I think the current drivers
> > will just fail.
> 
> Question is badly phrased.. I meant something more like... what do we do
> if RTAS returns a lower count ?
> 
> That is, we end up with that device with that lower count of MSIs
> enabled, we fail at the driver level, do we still somewhat keep track ?
> Drivers might assume that means it can use LSIs no ? which may not be
> the case... Shouldn't we try to switch back to LSI mode (or does the
> RTAS interface doesnt allow it ?)

OK I get you. So:

rtas_setup_msi_irqs() detects that it got fewer MSIs than it asked for
and returns an error.

The generic code (drivers/pci/msi.c) notices the error and calls
msi_free_irqs().

That calls back into rtas_teardown_msi_irqs() which disposes of the virq
mappings and calls rtas_disable_msi().

rtas_disable_msi() asks firmware to configure 0 MSIs on the device, that
hopefully succeeds. AFAIK configuring 0 MSIs is as close as we can get
to disabling MSI via RTAS.

Perhaps that should also (re)enable INTX?

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20071002/472c196e/attachment.pgp>


More information about the Linuxppc-dev mailing list