On Wed, Apr 08, 2020 at 01:59:16PM +0200, Christoph Hellwig wrote:
> To help enforcing the W^X protection don't allow remapping existing
> pages as executable.
>
> Based on patch from Peter Zijlstra .
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/x86/include/asm/pgtable_types.h | 6 ++
>
On Wed, Apr 08, 2020 at 01:59:24PM +0200, Christoph Hellwig wrote:
> arch_alloc_vmap_stack can use a slightly higher level vmalloc function.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Mark Rutland
Mark.
> ---
> arch/arm64/include/asm/vmap_stack.h | 6 ++
>
On Thu, Mar 26, 2020 at 06:11:31PM +0100, Alexander Graf wrote:
> On 26.03.20 18:05, Christoph Hellwig wrote:
> >
> > On Thu, Mar 26, 2020 at 05:29:22PM +0100, Alexander Graf wrote:
> > > The swiotlb is a very convenient fallback mechanism for bounce buffering
> > > of
> > > DMAable data. It is u
s access size, requires strict
> alignment and can also force write responses to come from the endpoint.
>
> ? It's a small change, but it better fits with the arm64 terminology
> ("strongly ordered" is no longer used in the architecture).
>
> If you're happy with that, I can make the change and queue this patch
> for 5.4.
FWIW, with that wording:
Acked-by: Mark Rutland
Mark.
On Fri, Jul 07, 2017 at 08:22:21AM -0700, Scott Branden wrote:
> On 17-07-07 07:55 AM, Robin Murphy wrote:
> >On 07/07/17 14:30, Mark Rutland wrote:
> >>On Fri, Jul 07, 2017 at 12:39:58PM +0530, Srinath Mannam wrote:
> >>>+Example (6)
> >>>+===
&g
On Fri, Jul 07, 2017 at 12:39:59PM +0530, Srinath Mannam wrote:
> The MSI Device ID or Stream ID are passed as sideband
> data on the SOC bus to which PCI RC is connected.
>
> If sideband data on SOC bus is less than 16bits then
> PCI RC will have to derive sideband data from RID by
> dropping sel
On Fri, Jul 07, 2017 at 12:39:58PM +0530, Srinath Mannam wrote:
> This patch adds info about optional DT properties
> iommu-map-drop-mask and msi-map-drop-mask.
>
> A drop mask represents the bits which will be
> removed/dropped by system from Requester ID before
> mapping it to msi ID or stream I
On Fri, Jul 07, 2017 at 12:39:57PM +0530, Srinath Mannam wrote:
> These patches implements optional DT properties to generate
> smaller sideband data from RID which can be further mapped
> to MSI Device ID or Stream ID
>
> On some of the systems, sideband data is smaller than RID
> (16bits). For s
On Thu, May 04, 2017 at 06:05:33PM +0530, Geetha sowjanya wrote:
> From: Linu Cherian
>
> Cavium ThunderX2 SMMU implementation doesn't support page 1 register space
> and PAGE0_REGS_ONLY option will be enabled as an errata workaround.
>
> This option when turned on, replaces all page 1 offsets u
On Thu, Apr 27, 2017 at 05:16:23PM +0530, Geetha sowjanya wrote:
> + /*
> + * Override the size, for Cavium CN99xx implementations
> + * which doesn't support the page 1 SMMU register space.
> + */
> + cpu_model = read_cpuid_id() & MIDR_CPU_MODEL_MASK;
> + if (cpu_model =
ommu-cells = <1>, specifies a mask of bits to
ignore when matching stream IDs (e.g. this may be
programmed into the SMRn.MASK field of every
stream match register used).
Otherwise, this looks good to me; thanks for respinning this.
If you're happy to make the a
On Tue, Mar 07, 2017 at 06:26:28PM +, Robin Murphy wrote:
> The current SMR masking support using a 2-cell iommu-specifier is
> primarily intended to handle individual masters with large and/or
> complex Stream ID assignments; it quickly gets a bit clunky in other SMR
> use-cases where we just
On Tue, Mar 07, 2017 at 09:39:55AM -0700, Jordan Crouse wrote:
> Implement support for dynamic domain switching. This feature is
> only enabled when the qcom,dynamic device tree attribute for an smmu
> instance.
>
> In order to use dynamic domains, a non-dynamic domain must first
> be created and
On Wed, Feb 08, 2017 at 07:15:37PM +0530, Sricharan wrote:
> >Clocks are not architectural, so it only makes sense to associate them
> >with an implementation-specific compatible string. There's also no
>
> ok, it for this the QCOM specific implementation binding is tried(going to).
>
> >guarante
On Wed, Feb 08, 2017 at 04:23:17PM +0530, Sricharan wrote:
> >On Thu, Feb 02, 2017 at 10:40:18PM +0530, Sricharan R wrote:
> >> +- clock-names:Should be a pair of "smmu_iface_clk" and "smmu_bus_clk"
> >> + required for smmu's register group access and interface
> >> +
Hi,
On Thu, Feb 02, 2017 at 10:40:18PM +0530, Sricharan R wrote:
> +- clock-names:Should be a pair of "smmu_iface_clk" and "smmu_bus_clk"
> + required for smmu's register group access and interface
> + clk for the smmu's underlying bus access.
> +
> +- clocks:
On Thu, Jan 05, 2017 at 02:00:05PM +, Will Deacon wrote:
> On Thu, Jan 05, 2017 at 12:08:57PM +0000, Mark Rutland wrote:
> > On Thu, Jan 05, 2017 at 11:55:29AM +, Will Deacon wrote:
> > > On Tue, Jan 03, 2017 at 04:30:54PM -0500, Rob Clark wrote:
> > > &
On Thu, Jan 05, 2017 at 11:55:29AM +, Will Deacon wrote:
> On Tue, Jan 03, 2017 at 04:30:54PM -0500, Rob Clark wrote:
> > TODO maybe we want two options, one to enable stalling, and 2nd to punt
> > handling to wq? I haven't needed to use mm APIs from fault handler yet
> > (although it is somet
On Fri, Dec 16, 2016 at 02:08:09PM +, Stuart Yoder wrote:
>
> > -Original Message-
> > From: Mark Rutland [mailto:mark.rutl...@arm.com]
> >
> > On Thu, Dec 15, 2016 at 06:16:13PM -0600, Stuart Yoder wrote:
> > > In the iommu-map binding cha
On Fri, Dec 16, 2016 at 02:36:57AM +, Stuart Yoder wrote:
> For context, please see the thread:
> https://www.spinics.net/lists/arm-kernel/msg539066.html
>
> The existing iommu-map binding did not account for the situation where
> #iommu-cells == 2, as permitted in the ARM SMMU binding. The 2
Hi Stuart,
On Thu, Dec 15, 2016 at 06:16:13PM -0600, Stuart Yoder wrote:
> The generic IOMMU binding says that the meaning of an 'IOMMU specifier'
> is defined by the binding of a specific SMMU. The ARM SMMU binding
> never explicitly uses the term 'specifier' at all. Update implicit
> reference
gs around so that the check always happens before the index
> may be dereferenced.
>
> Fixes: adfec2e709d2 ("iommu/arm-smmu: Convert to iommu_fwspec")
> Reported-by: Mark Rutland
> Signed-off-by: Robin Murphy
This patch fixes the KASAN splats as I saw (example below).
Wi
Hi,
On Fri, Oct 28, 2016 at 05:16:37PM +0100, Robin Murphy wrote:
> On 27/10/16 18:10, Stuart Yoder wrote:
> > A question about how the SMR masking defined in the arm,smmu binding
> > relates to the PCI iommu-map.
> >
> > The #iommu-cells property defines the number of cells an "IOMMU specifier"
On Fri, Apr 22, 2016 at 02:27:38PM +0800, Yangbo Lu wrote:
> Update Freescale DCFG compatible with 'fsl,-dcfg' instead
> of 'fsl,ls1021a-dcfg' to include more chips.
>
> Signed-off-by: Yangbo Lu
> ---
> Changes for v8:
> - Added this patch
> ---
> Documentation/devicetree/bindings/arm/fsl.
On Wed, Feb 24, 2016 at 03:54:48PM +, Chalamarla, Tirumalesh wrote:
>
> On 2/24/16, 3:32 AM, "Mark Rutland" wrote:
>
> >On Tue, Feb 23, 2016 at 03:50:21PM -0800, Tirumalesh Chalamarla wrote:
> >> in Summary,
> >>
> >> if i chang
8 bit systems even though the property now indicates Cavium only.
>
> Thanks,
> Tirumalesh.
>
> On 02/23/2016 04:26 AM, Mark Rutland wrote:
> >On Thu, Feb 18, 2016 at 10:29:18AM -0800, tchalama...@caviumnetworks.com
> >wrote:
> >>From: Tirumalesh Chalamarla
>
On Thu, Feb 18, 2016 at 10:29:18AM -0800, tchalama...@caviumnetworks.com wrote:
> From: Tirumalesh Chalamarla
>
> Due to Errata#27704 CN88xx SMMUv2,supports only shared ASID and VMID
> namespaces; specifically within a given node SMMU0 and SMMU1 share,
> as does SMMU2 and SMMU3.
>
> This patch
On Mon, Feb 08, 2016 at 06:13:11PM +0530, Anup Patel wrote:
> On Mon, Feb 8, 2016 at 4:48 PM, Mark Rutland wrote:
> > On Mon, Feb 08, 2016 at 10:47:32AM +0530, Anup Patel wrote:
> >> To allow use of large memory (> 4Gb) with 32bit devices we need to use
> >> IOM
On Mon, Feb 08, 2016 at 10:47:32AM +0530, Anup Patel wrote:
> To allow use of large memory (> 4Gb) with 32bit devices we need to use
> IOMMU based DMA mappings for such 32bit devices. The IOMMU dt-bindings
> allows us do this by specifying 'iommus' attribute in 32bit device DT
> node. Unfortunately
On Fri, Feb 05, 2016 at 08:02:09PM +, Mark Rutland wrote:
> On Fri, Feb 05, 2016 at 10:47:07AM -0800, tchalama...@caviumnetworks.com
> wrote:
> > From: Tirumalesh Chalamarla
> >
> > An issue exists whereby the Linux kernel requires that ASIDs are a
> > unique
On Fri, Feb 05, 2016 at 10:47:07AM -0800, tchalama...@caviumnetworks.com wrote:
> From: Tirumalesh Chalamarla
>
> An issue exists whereby the Linux kernel requires that ASIDs are a
> unique namespace per SMMU.
The SMMU architecture requires this, and Linux relies on hardware
following the arch
On Thu, Jan 28, 2016 at 05:28:30PM +, Robin Murphy wrote:
> On 27/01/16 05:21, Anup Patel wrote:
> >To allow use of large memory (> 4Gb) with 32bit devices we need to use
> >some kind of iommu for such 32bit devices.
> >
> >This patch extends SMMUv1/SMMUv2 driver to support DMA domains which
>
On Wed, Jan 27, 2016 at 10:51:19AM +0530, Anup Patel wrote:
> This patch adds info about 'smmu-inst-as-data' DT option in ARM
> SMMUv1/SMMUv2 driver bindings document.
>
> Signed-off-by: Anup Patel
> Reviewed-by: Ray Jui
> Reviewed-by: Vikram Prakash
> Reviewed-by: Scott Branden
> ---
> Docum
On Thu, Dec 17, 2015 at 11:51:03AM +, Will Deacon wrote:
> [adding devicetree since I'd like an Ack from them if possible]
>
> On Thu, Dec 17, 2015 at 03:29:36PM +0530, Prem Mallappa wrote:
> > Signed-off-by: Prem Mallappa
>
> Please can you add a commit message for this?
>
> > ---
> > Doc
#x27;.' which should be a '/'. in the
path.
With those changes:
Acked-by: Mark Rutland
Thanks,
Mark.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Mon, Oct 05, 2015 at 12:32:00PM +0200, Christoffer Dall wrote:
> [cc'ing Mark R. and Shannon for their input on FDT and ACPI].
>
> On Mon, Oct 05, 2015 at 11:07:35AM +0100, Peter Maydell wrote:
> > On 5 October 2015 at 10:37, Christoffer Dall
> > wrote:
> > > On Fri, Oct 02, 2015 at 11:53:07PM
es and/or wording
details to sort out, but I think the common/simple case is sorted. I'll
send a v2 once those have been settled.
> If not, I will be sending out my patches for your consideration.
Please do!
> Thanks,
> David Daney
>
> On 07/27/2015 01:16 AM, Marc Zyngier
> > +PCI root complex
> > +
> > +
> > +Optional properties
> > +---
> > +
> > +- msi-map: Maps a Requester ID to an MSI controller and associated
> > + msi-specifier data. The property is an arbitrary number of tuples of
> > + (rid-base,msi-controller,msi-base,leng
On Mon, Aug 24, 2015 at 02:37:59PM +0100, Rob Herring wrote:
> On Mon, Aug 24, 2015 at 5:17 AM, Mark Rutland wrote:
> > On Wed, Aug 05, 2015 at 05:51:20PM +0100, Mark Rutland wrote:
> >> Rob,
> >>
> >> Do you have any objections to this, or are you happy to
On Wed, Aug 05, 2015 at 05:51:20PM +0100, Mark Rutland wrote:
> Rob,
>
> Do you have any objections to this, or are you happy to take this patch?
>
> There's a user of this binding (the GICv3 ITS) queued for v4.3 already in
> the tip tree, so either we either need to be
[...]
> > +PCI root complex
> > +
> > +
> > +Optional properties
> > +---
> > +
> > +- msi-map: Maps a Requester ID to an MSI controller and associated
> > + msi-specifier data. The property is an arbitrary number of tuples of
> > + (rid-base,msi-controller,msi-ba
ists.linux-foundation.org] On Behalf Of Mark Rutland
> > Sent: Thursday, July 23, 2015 10:23 PM
> > To: devicet...@vger.kernel.org
> > Cc: Mark Rutland; lorenzo.pieral...@arm.com; a...@arndb.de;
> > marc.zyng...@arm.com; will.dea...@arm.com; linux-
> > ke
se of the binding that you are happy to
provide your ack?
Thanks,
Mark.
On Thu, Jul 23, 2015 at 05:52:43PM +0100, Mark Rutland wrote:
> Currently msi-parent is used in a couple of drivers despite being fairly
> underspecified. This patch adds a generic binding for MSIs (including
> th
On Mon, Jul 27, 2015 at 09:02:46AM +0100, Marc Zyngier wrote:
> Hi Mark,
Hi,
> On 23/07/15 17:52, Mark Rutland wrote:
> > Currently msi-parent is used in a couple of drivers despite being fairly
> > underspecified. This patch adds a generic binding for MSIs (including
> >
> > +Example (5)
> > +===
> > +
> > +/ {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + msi_a: msi-controller@a {
> > + reg = <0xa 0x1>;
> > + compatible = "vendor,some-controller";
> > + msi-controller;
> > + #msi-cells = <1>;
a real system!
> On 23/07/15 17:52, Mark Rutland wrote:
> > The existing IOMMU bindings are able to specify the relationship between
> > masters and IOMMUs, but they are insufficient for describing the general
> > case of hotpluggable busses such as PCI where the set of ma
a new msi-map property
(specific to PCI*) which may be used to map devices (identified by their
Requester ID) to sideband data for each MSI controller that they may
target.
Signed-off-by: Mark Rutland
---
Documentation/devicetree/bindings/pci/pci-msi.txt | 220 ++
1 file
: Mark Rutland
---
.../devicetree/bindings/pci/pci-iommu.txt | 171 +
1 file changed, 171 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.txt
diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.txt
b/Documentation/devicetree
-hotpluggable devices.
For busses where sideband data may be derived from some bus-specific
master ID scheme, other properties will be required to describe the
mapping.
Signed-off-by: Mark Rutland
---
.../bindings/interrupt-controller/msi.txt | 135 +
1 file changed
ake use
of (non-probeable) sideband data.
Thanks,
Mark.
Mark Rutland (3):
Docs: dt: add generic MSI bindings
Docs: dt: Add PCI MSI map bindings
Docs: dt: add PCI IOMMU map bindings
.../bindings/interrupt-controller/msi.txt | 135 +
.../devicetree/bindings/pci/pci
2ccc634e69 Mon Sep 17 00:00:00 2001
From: Mark Rutland
Date: Thu, 9 Jul 2015 17:53:00 +0100
Subject: [PATCH] Documentation: dt: add generic MSI bindings
Currently msi-parent is in use in a couple of drviers despite being
fairly underspecified. This patch adds a generic binding for MSIs
(including
On Tue, Jun 09, 2015 at 11:17:54AM +0100, Mark Rutland wrote:
> On Fri, Jun 05, 2015 at 10:05:34AM +0100, Will Deacon wrote:
> > On Thu, Jun 04, 2015 at 11:19:30PM +0100, Chalamarla, Tirumalesh wrote:
> > > > On Jun 1, 2015, at 3:22 AM, Mark Rutland wrote:
> > > &
On Fri, Jun 05, 2015 at 10:05:34AM +0100, Will Deacon wrote:
> On Thu, Jun 04, 2015 at 11:19:30PM +0100, Chalamarla, Tirumalesh wrote:
> > > On Jun 1, 2015, at 3:22 AM, Mark Rutland wrote:
> > > It's possible to specify that the paths exist. I expect that software
>
On Fri, May 29, 2015 at 06:46:07PM +0100, Chalamarla, Tirumalesh wrote:
>
> > On May 27, 2015, at 10:39 AM, Mark Rutland wrote:
> >
> > On Tue, May 26, 2015 at 11:20:59PM +0100, Chalamarla, Tirumalesh wrote:
> >> This is some thing we also like to see in ITS and
On Tue, May 26, 2015 at 11:20:59PM +0100, Chalamarla, Tirumalesh wrote:
> This is some thing we also like to see in ITS and SMMU drivers.
> > On Mar 24, 2015, at 8:50 AM, Mark Rutland wrote:
> >
> > Hi all,
> >
> > For some devices, identification of particular
> > > smi_common:smi@14022000 {
> > > compatible = “mediate, mt8173-smi”;
> > > reg = <0 0x14022000 0 0x1000>;
> > > clocks = <&mmsys MM_SMI_COMMON>;
> > > clocks-names = “smi_common”;
> > > };
> > >
> > > larb0:
On Tue, Apr 14, 2015 at 10:07:54AM +0100, Yong Wu wrote:
> Hi Mark,
> Thanks very much for review.
> About the clock name should be the PoV of _this_ device. Could you
> help check below?
>
> On Fri, 2015-03-06 at 11:13 +, Mark Rutland wrote:
> > On Fri, Ma
Hi all,
For some devices, identification of particular masters is critical to
their operation (e.g. IOMMUs, MSI controllers). The identity of masters
is determined from sideband signals on the bus, and it may or may not be
possible to probe and/or configure this information. Worse still, these
inf
On Fri, Mar 06, 2015 at 10:48:19AM +, yong...@mediatek.com wrote:
> From: Yong Wu
>
> This patch add mediatek iommu dts binding document.
>
> Signed-off-by: Yong Wu
> ---
> .../devicetree/bindings/iommu/mediatek,iommu.txt | 41
> ++
> 1 file changed, 41 insertions(+)
On Fri, Mar 06, 2015 at 10:48:18AM +, yong...@mediatek.com wrote:
> From: Yong Wu
>
> This patch add smi binding document.
Please move binding documents to the start of the series. It makes
things far easier to review.
>
> Signed-off-by: Yong Wu
> ---
> .../devicetree/bindings/soc/mediat
m MMU and Tegra SMMU as
> discussed here:
>
> https://lkml.org/lkml/2014/4/27/346
>
> Acked-by: Will Deacon
> Reviewed-by: Arnd Bergmann
> Acked-by: Rob Herring
> Signed-off-by: Thierry Reding
This looks good to me, and you've adressed the only comments I had,
On Thu, Jul 31, 2014 at 11:09:06AM +0100, Thierry Reding wrote:
> On Wed, Jul 30, 2014 at 07:18:42PM +0100, Mark Rutland wrote:
> [...]
> > > >> +
> > > >> +Multiple-maste
[...]
> > > +Examples:
> > > +=
> > > +
> > > +Single-master IOMMU:
> > > +
> > > +
> > > + iommu {
> > > + #iommu-cells = <0>;
> > > + };
> > > +
> > > + master {
> > > + iommus = <&/iommu>;
> >
> > Nit: this should be iommus = <&{/iommu}>, or it's not
[...]
> >> +Multiple-master IOMMU:
> >> +--
> >> +
> >> + iommu {
> >> + /* the specifier represents the ID of the master */
> >> + #iommu-cells = <1>;
> >> + };
> >> +
> >> + master@1 {
> >> + /* device has master ID 42 in the IO
Hi Thierry,
This looks sane to me.
I just have a few questions below which are hopefully simple/stupid.
On Fri, Jul 04, 2014 at 04:29:17PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> This commit introduces a generic device tree binding for IOMMU devices.
> Only a very minimal subse
On Thu, Oct 31, 2013 at 08:19:42AM +, Hiroshi Doyu wrote:
> Stephen Warren wrote @ Wed, 30 Oct 2013 23:48:38
> +0100:
>
> > On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> > > Create a header file to define the swgroup IDs used by the IOMMU(SMMU)
> > > binding. "swgroups" is a group of H/W cli
On Thu, Oct 31, 2013 at 08:18:08AM +, Hiroshi Doyu wrote:
> Stephen Warren wrote @ Wed, 30 Oct 2013 23:44:04
> +0100:
>
> > > + host1x {
> > > + compatible = "nvidia,tegra30-host1x", "simple-bus";
> > > + nvidia,memory-clients = <&smmu TEGRA_SWGROUP_HC>;
> > > +
On Thu, Oct 31, 2013 at 05:11:26PM +, Hiroshi Doyu wrote:
> Hiroshi Doyu wrote @ Thu, 31 Oct 2013 19:05:24 +0200 (EET):
>
> > Hi Mark,
> >
> > Mark Rutland wrote @ Thu, 31 Oct 2013 17:51:27 +0100:
> >
> > > On Fri, Oct 18, 2013 at 11:26:46AM +0100
On Wed, Oct 30, 2013 at 10:33:32PM +, Stephen Warren wrote:
> On 10/18/2013 04:26 AM, Hiroshi Doyu wrote:
> > This provides the info about which H/W Accelerators are supported on
> > Tegra SoC. This info is passed from DT. This is necessary to have the
> > unified SMMU driver among Tegra SoCs.
On Fri, Oct 18, 2013 at 11:26:51AM +0100, Hiroshi Doyu wrote:
> This provides the info about which H/W Accelerators are supported on
> Tegra SoC. This info is passed from DT. This is necessary to have the
> unified SMMU driver among Tegra SoCs. Instead of using platform data,
> DT passes "nvidia,sw
On Fri, Oct 18, 2013 at 11:26:46AM +0100, Hiroshi Doyu wrote:
> Fix IOMMU register address.
>
> Signed-off-by: Hiroshi Doyu
> ---
> arch/arm/boot/dts/tegra114.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/
On Fri, Oct 18, 2013 at 11:26:53AM +0100, Hiroshi Doyu wrote:
> This is a bitmap that indicates which HardWare Accelerators(HWA) are
> supported on Tegra114 SoC.
The title and patch disagree here; the patch _changes_ the existing
nvidia,swgroups property, and the commit message doesn't explain why
> > +static const struct of_device_id vfio_dt_match[] = {
> > + � � /* In the future, we can implement a better mechanism to bind
> the
> > + � � �* module to any device. For now add the compatible property to
> the
> > + � � �* dtb of the devices we want to use. � */
73 matches
Mail list logo
