linux-kernel - Re: [PATCH 0/7] Level-triggered MSI support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5d7e8fa9-e1d2-acc2-4137-443b5a82b488@linaro.org>
Date:   Mon, 23 Apr 2018 13:43:37 +0100
From:   Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:     Marc Zyngier <marc.zyngier@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>
Cc:     Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/7] Level-triggered MSI support



On 23/04/18 11:34, Marc Zyngier wrote:
> This series is a first shot at teaching the kernel about the oxymoron
> expressed in $SUBJECT. Over the past couple of years, we've seen some
> SoCs coming up with ways of signalling level interrupts using a new
> flavor of MSIs, where the MSI controller uses two distinct messages:
> one that raises a virtual line, and one that lowers it. The target MSI
> controller is in charge of maintaining the state of the line.
> 
> This allows for a much simplified HW signal routing (no need to have
> hundreds of discrete lines to signal level interrupts if you already
> have a memory bus), but results in a departure from the current idea
> the kernel has of MSIs.
> 
> This series takes a minimal approach to the problem, which is to allow
> MSI controllers to use not only one, but up to two messages at a
> time. This is controlled by a flag exposed at MSI irq domain creation,
> and is only supported with platform MSI.
> 
> The rest of the series repaints the Marvell ICU/GICP drivers which
> already make use of this feature with a side-channel, and adds support
> for the same feature in GICv3. A side effect of the last GICv3 patch
> is that you can also use SPIs to signal PCI MSIs. This is a last
> resort measure for SoCs where the ITS is unusable for unspeakable
> reasons.
> 
> Marc Zyngier (7):
>    genirq/msi: Allow level-triggered MSIs to be exposed by MSI providers
>    genirq/msi: Limit level-triggered MSI to platform devices
>    irqchip/mvebu-gicp: Use level-triggered MSIs between ICU and GICP
>    dma-iommu: Fix compilation when !CONFIG_IOMMU_DMA
>    irqchip/gic-v3: Add support for Message Based Interrupts as an MSI
>      controller
>    irqchip/gic-v3: Add PCI/MSI support to the GICv3 MBI sub-driver
>    dt-bindings/gic-v3: Add documentation for MBI support
> 

Thanks for the patches,

Am able to get PCIe MSI interrupts on Qualcomm DragonBoard DB820c with 
this patchset.

root@...aro-alip:~# cat /proc/interrupts  | grep -i MSI
  44:          0          0          0          0     GICv3 437 Edge 
  qcom-pcie-msi
  45:          0          0          0          0     GICv3 445 Edge 
  qcom-pcie-msi
  46:          0          0          0          0     GICv3 453 Edge 
  qcom-pcie-msi
  80:          0          0          0          0       MSI 134217728 
Edge      PCIe PME, aerdrv
114:          0          0          0          0       MSI 268435456 
Edge      PCIe PME, aerdrv
115:          0          0          0          0       MSI 134742016 
Edge      ahci[0001:01:00.0]
197:          0          0          0          0       MSI   0 Edge 
PCIe PME, aerdrv
199:       2108          0          0          0       MSI 524288 Edge 
    ath10k_pci
202:        295          0          0          0       MSI 268959744 
Edge      eth0


Tested-by: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>

--srini