linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Cc: robh+dt@kernel.org, mark.rutland@arm.com,
	devicetree@vger.kernel.org, linux-pci@vger.kernel.org,
	Jeremy.Linton@arm.com, Grant.Likely@arm.com,
	Robin.Murphy@arm.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] dt-bindings: Add external-facing PCIe port property
Date: Wed, 20 Mar 2019 17:03:38 -0500	[thread overview]
Message-ID: <20190320220338.GH251185@google.com> (raw)
In-Reply-To: <20190318182124.53859-2-jean-philippe.brucker@arm.com>

On Mon, Mar 18, 2019 at 06:21:23PM +0000, Jean-Philippe Brucker wrote:
> Provide a way for the firmware to tell the OS which devices are external
> to the machine and therefore untrusted. The property can describe for
> example thunderbolt and other hot-pluggable ports, which should always
> have the strongest IOMMU protection.

s/thunderbolt/Thunderbolt/

I think the important bit is that the port is user-accessible, whether
it is hot-pluggable or not, right?

I think I'm OK with this from a PCI perspective.

> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
> ---
>  Documentation/devicetree/bindings/pci/pci.txt | 47 +++++++++++++++++++
>  1 file changed, 47 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
> index c77981c5dd18..55cdbc5d2804 100644
> --- a/Documentation/devicetree/bindings/pci/pci.txt
> +++ b/Documentation/devicetree/bindings/pci/pci.txt
> @@ -24,3 +24,50 @@ driver implementation may support the following properties:
>     unsupported link speed, for instance, trying to do training for
>     unsupported link speed, etc.  Must be '4' for gen4, '3' for gen3, '2'
>     for gen2, and '1' for gen1. Any other values are invalid.
> +
> +PCI-PCI Bridge properties
> +-------------------------
> +
> +Root ports and switch ports may be described explicitly in the device

Maybe "PCIe root ports and switch ports" since pci.txt seems to apply
to both conventional PCI and PCIe?

> +tree, as children of the host bridge node. Even though those devices are
> +discoverable by probing, it might be necessary to describe properties that
> +aren't provided by standard PCIe capabilities.
> +
> +Required properties:
> +
> +- reg:
> +   Identifies the PCI-PCI bridge. As defined in the IEEE Std 1275-1994
> +   document, it is a five-cell address encoded as (phys.hi phys.mid
> +   phys.lo size.hi size.lo). phys.hi should contain the device's BDF as
> +   0b00000000 bbbbbbbb dddddfff 00000000. The other cells should be zero.
> +
> +   The bus number is defined by firmware, through the standard bridge
> +   configuration mechanism. If this port is a switch port, then firmware
> +   allocates the bus number and writes it into the Secondary Bus Number
> +   register of the bridge directly above this port. Otherwise, the bus
> +   number of a root port is the first number in the bus-range property,
> +   defaulting to zero.
> +
> +   If firmware leaves the ARI Forwarding Enable bit set in the bridge
> +   above this port, then phys.hi contains the 8-bit function number as
> +   0b00000000 bbbbbbbb ffffffff 00000000. Note that the PCIe specification
> +   recommends that firmware only leaves ARI enabled when it knows that the
> +   OS is ARI-aware.
> +
> +Optional properties:
> +
> +- external-facing:
> +   When present, the port is external facing. All bridges and endpoints
> +   downstream of this port are external to the machine.

Maybe include a note about why this is important, ie, we care because
malicious devices may be attached to an external port?  I know you
have that in the commit log but it would be more visible here.

Elsewhere you use "external-facing", here too for consistency?

> +Example:
> +
> +pcie@10000000 {
> +	compatible = "pci-host-ecam-generic";
> +	...
> +	pcie@0008 {
> +		/* Root port 00:01.0 is external-facing */
> +		reg = <0x00000800 0 0 0 0>;
> +		external-facing;
> +	};
> +};
> -- 
> 2.21.0
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-03-20 22:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-18 18:21 [PATCH 0/2] PCI: Describe external-facing ports in device tree Jean-Philippe Brucker
2019-03-18 18:21 ` [PATCH 1/2] dt-bindings: Add external-facing PCIe port property Jean-Philippe Brucker
2019-03-20 22:03   ` Bjorn Helgaas [this message]
2019-03-25 12:59     ` Jean-Philippe Brucker
2019-03-25 13:53       ` Bjorn Helgaas
2019-03-18 18:21 ` [PATCH 2/2] PCI: OF: Support external-facing property Jean-Philippe Brucker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190320220338.GH251185@google.com \
    --to=helgaas@kernel.org \
    --cc=Grant.Likely@arm.com \
    --cc=Jeremy.Linton@arm.com \
    --cc=Robin.Murphy@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jean-philippe.brucker@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).