On Tue, 6 Nov 2018 17:44:56 +0100 Michael Mueller <mimu@xxxxxxxxxxxxx> wrote: > On 31.10.18 13:45, Cornelia Huck wrote: > > On Thu, 25 Oct 2018 14:37:50 +0200 > > Michael Mueller <mimu@xxxxxxxxxxxxx> wrote: > >> diff --git a/arch/s390/include/asm/isc.h b/arch/s390/include/asm/isc.h > >> index 6cb9e2ed05b6..b2cc1ec78d06 100644 > >> --- a/arch/s390/include/asm/isc.h > >> +++ b/arch/s390/include/asm/isc.h > >> @@ -21,6 +21,7 @@ > >> /* Adapter interrupts. */ > >> #define QDIO_AIRQ_ISC IO_SCH_ISC /* I/O subchannel in qdio mode */ > >> #define PCI_ISC 2 /* PCI I/O subchannels */ > >> +#define GAL_ISC 5 /* GIB alert */ > > Dumb question: iscs are ordered by priority. What are the semantics > > here? Are gib alerts only for ap-style adapter interrupts (at least > > currently, it seems to me like that)? Is there a requirement to use a > > distinct isc? > > GIB alerts will be issued for all sorts of passed-trough adapters. Currently > we are looking for AP and later for PCI as well. The GIB alert is a > *fallback > mechanism* when the interruption cannot be directly delivered in-sie. > Thus I consider its priority as less important. The GAL isc comes in at a higher priority than AP, but at a lower priority than PCI. It probably does not really matter if it is only a fallback, but I still wanted to point it out :) > > Why a distinct ISC? That is probably not required. On the other hand I don't > want to trigger the GAL handler by adapter interruptions for other reasons. If more users of I/O interrupts are added in the future, we won't be able to avoid isc re-usage. But it looks fine for now. > > > > >> #define AP_ISC 6 /* adjunct processor (crypto) devices */ > >> > >> /* Functions for registration of I/O interruption subclasses */ >
