From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.deacon@arm.com (Will Deacon) Date: Tue, 11 Apr 2017 17:41:03 +0100 Subject: [RFC PATCH 3/7] iommu/arm-smmu-v3: Introduce smmu option USE_SHARED_IRQS for Silicon errata In-Reply-To: References: <1491921765-29475-1-git-send-email-linucherian@gmail.com> <1491921765-29475-4-git-send-email-linucherian@gmail.com> <20170411162123.GF17109@arm.com> Message-ID: <20170411164103.GI17109@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Apr 11, 2017 at 05:38:21PM +0100, Robin Murphy wrote: > On 11/04/17 17:21, Will Deacon wrote: > > On Tue, Apr 11, 2017 at 04:54:26PM +0100, Robin Murphy wrote: > >> On 11/04/17 15:42, linucherian at gmail.com wrote: > >>> From: Geetha > >>> > >>> Cavium 99xx SMMU implementation doesn't not support unique irq lines for > >>> gerror, eventq and cmdq-sync. USE_SHARED_IRQS option enables to use single > >>> irq line for all three interrupts. > >> > >> AFAICS, there's nothing actually wrong with using shared wired IRQs - > >> the architecture spec doesn't appear to say anything about it. I think > >> it might suffice to simply add IRQF_SHARED if we can see the SMMU > >> doesn't support MSIs anyway - it doesn't really seem like something we > >> need to treat as a specific quirk. > > > > No, this is not permitted by the spec. See 3.18.2 ("Interrupt sources"), > > where it's clear that each source asserts a *unique* wired interrupt. > > Perhaps I'm reading it too generously; it does indeed specify that the > *implementation* has to provide a unique output for each source, but > other than suggesting a particular mode of operation based on that I > don't see anything actually forbidding the *integration* from then just > munging those lines together externally, as integrators so often like to > do. That's the case I had in mind. Sure, but then there wouldn't be any point in the architecture mandating a unique source, would there? What next, OR all the address lines together too? Will