On Tue, Jul 24, 2018 at 01:49:32PM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2018-07-24 at 12:14 +1000, David Gibson wrote: > > > I don't know, is there much shared logic ? And the shared bits are the > > > subclassing, that's handled that way... > > > > > > This is really a different piece of HW, a separate ICS implementation, > > > that has its own quirks, is configured via different registers, does > > > EOI differently etc... > > > > > > Even the resend stuff is done differently, the resend bitmap is > > > actually SW visible via an IODA table. > > > > > > I mean, we could (maybe we do these days not sure) have an ICS > > > superclass wrapper on the actual icp_irq() but that's really all there > > > is to it I think. > > > > Hm, yeah, fair enough. I realized what I was suggesting would > > actually need another layer of qirqs than we have, so it's not a good > > idea after all. Ok, I'm happy proceeding with exposing icp_irq(). > > The only idea I have if you want to keep icp_* private is to put a > 'helper' in the ICS superclass that the subclass uses to encapsulate > the ICP call, but at this point it's just churn.
I concur.
>
> But yeah you really don't want a layer of qirqs, it wouldn't work any
> way, it's really an ICS, it will send messages to the ICP with a XIRR
> value in them etc... just like an ICS, it's not somethign you want
> qirq's for .
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
