[PATCH 0/3] Enable PCIe ATS for devicetree boot

[PATCH 0/3] Enable PCIe ATS for devicetree boot

[Jean-Philippe Brucker]

Before enabling Address Translation Support (ATS) in endpoints, the OS
needs to confirm that the Root Complex supports it. Obtain this
information from the firmware description since there is no architected
method. ACPI provides a bit via IORT tables, so add the devicetree
equivalent.

It was discussed a while ago [1], but at the time only a software model
supported it. Respin it now that hardware is available [2].

To test this with the Arm RevC model, enable ATS in the endpoint and
note that ATS is enabled. Address translation is transparent to the OS.

	-C pci.pcie_rc.ahci0.endpoint.ats_supported=1

    $ lspci -s 00:1f.0 -vv
    	Capabilities: [100 v1] Address Translation Service (ATS)
		ATSCap: Invalidate Queue Depth: 00
    		ATSCtl: Enable+, Smallest Translation Unit: 00


[1] https://lore.kernel.org/linux-iommu/20200213165049.508908-1-jean-philippe@linaro.org/
[2] https://lore.kernel.org/linux-arm-kernel/ZeJP6CwrZ2FSbTYm@Asurada-Nvidia/

Jean-Philippe Brucker (3):
  dt-bindings: PCI: generic: Add ats-supported property
  iommu/of: Support ats-supported device-tree property
  arm64: dts: fvp: Enable PCIe ATS for Base RevC FVP

 .../devicetree/bindings/pci/host-generic-pci.yaml        | 6 ++++++
 drivers/iommu/of_iommu.c                                 | 9 +++++++++
 arch/arm64/boot/dts/arm/fvp-base-revc.dts                | 1 +
 3 files changed, 16 insertions(+)

-- 
2.44.0

[PATCH 1/3] dt-bindings: PCI: generic: Add ats-supported property

[Jean-Philippe Brucker]

Add a way for firmware to tell the OS that ATS is supported by the PCI
root complex. An endpoint with ATS enabled may send Translation Requests
and Translated Memory Requests, which look just like Normal Memory
Requests with a non-zero AT field. So a root controller that ignores the
AT field may simply forward the request to the IOMMU as a Normal Memory
Request, which could end badly. In any case, the endpoint will be
unusable.

The ats-supported property allows the OS to only enable ATS in endpoints
if the root controller can handle ATS requests. Only add the property to
pcie-host-ecam-generic for the moment. For non-generic root controllers,
availability of ATS can be inferred from the compatible string.

Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
From a while ago: https://lore.kernel.org/all/20200219222454.GA16221@bogus/
---
 Documentation/devicetree/bindings/pci/host-generic-pci.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.yaml b/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
index d25423aa71674..94d4a4914a483 100644
--- a/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
+++ b/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
@@ -110,6 +110,12 @@ properties:
   iommu-map-mask: true
   msi-parent: true
 
+  ats-supported:
+    description:
+      Indicates that a PCIe host controller supports ATS, and can handle Memory
+      Requests with Address Type (AT).
+    type: boolean
+
 required:
   - compatible
   - reg
-- 
2.44.0

Re: [PATCH 1/3] dt-bindings: PCI: generic: Add ats-supported property

[Liviu Dudau]

On Mon, Apr 29, 2024 at 12:39:37PM +0100, Jean-Philippe Brucker wrote:
> Add a way for firmware to tell the OS that ATS is supported by the PCI
> root complex. An endpoint with ATS enabled may send Translation Requests
> and Translated Memory Requests, which look just like Normal Memory
> Requests with a non-zero AT field. So a root controller that ignores the
> AT field may simply forward the request to the IOMMU as a Normal Memory
> Request, which could end badly. In any case, the endpoint will be
> unusable.
> 
> The ats-supported property allows the OS to only enable ATS in endpoints
> if the root controller can handle ATS requests. Only add the property to
> pcie-host-ecam-generic for the moment. For non-generic root controllers,
> availability of ATS can be inferred from the compatible string.
> 
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Reviewed-by: Rob Herring <robh@kernel.org>

Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>

> ---
> From a while ago: https://lore.kernel.org/all/20200219222454.GA16221@bogus/
> ---
>  Documentation/devicetree/bindings/pci/host-generic-pci.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.yaml b/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
> index d25423aa71674..94d4a4914a483 100644
> --- a/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
> +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
> @@ -110,6 +110,12 @@ properties:
>    iommu-map-mask: true
>    msi-parent: true
>  
> +  ats-supported:
> +    description:
> +      Indicates that a PCIe host controller supports ATS, and can handle Memory
> +      Requests with Address Type (AT).
> +    type: boolean
> +
>  required:
>    - compatible
>    - reg
> -- 
> 2.44.0
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH 2/3] iommu/of: Support ats-supported device-tree property

[Jean-Philippe Brucker]

Device-tree declares whether a PCI root-complex supports ATS by setting
the "ats-supported" property. Copy this flag into device fwspec to let
IOMMU drivers quickly check if they can enable ATS for a device.

Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Tested-by: Ketan Patil <ketanp@nvidia.com>
---
 drivers/iommu/of_iommu.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 3afe0b48a48db..082b94c2b3291 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -105,6 +105,14 @@ static int of_iommu_configure_device(struct device_node *master_np,
 		      of_iommu_configure_dev(master_np, dev);
 }
 
+static void of_pci_check_device_ats(struct device *dev, struct device_node *np)
+{
+	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+
+	if (fwspec && of_property_read_bool(np, "ats-supported"))
+		fwspec->flags |= IOMMU_FWSPEC_PCI_RC_ATS;
+}
+
 /*
  * Returns:
  *  0 on success, an iommu was configured
@@ -147,6 +155,7 @@ int of_iommu_configure(struct device *dev, struct device_node *master_np,
 		pci_request_acs();
 		err = pci_for_each_dma_alias(to_pci_dev(dev),
 					     of_pci_iommu_init, &info);
+		of_pci_check_device_ats(dev, master_np);
 	} else {
 		err = of_iommu_configure_device(master_np, dev, id);
 	}
-- 
2.44.0

Re: [PATCH 2/3] iommu/of: Support ats-supported device-tree property

[Jason Gunthorpe]

On Mon, Apr 29, 2024 at 12:39:38PM +0100, Jean-Philippe Brucker wrote:
> Device-tree declares whether a PCI root-complex supports ATS by setting
> the "ats-supported" property. Copy this flag into device fwspec to let
> IOMMU drivers quickly check if they can enable ATS for a device.
> 
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Tested-by: Ketan Patil <ketanp@nvidia.com>
> ---
>  drivers/iommu/of_iommu.c | 9 +++++++++
>  1 file changed, 9 insertions(+)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 2/3] iommu/of: Support ats-supported device-tree property

[Liviu Dudau]

On Mon, Apr 29, 2024 at 12:39:38PM +0100, Jean-Philippe Brucker wrote:
> Device-tree declares whether a PCI root-complex supports ATS by setting
> the "ats-supported" property. Copy this flag into device fwspec to let
> IOMMU drivers quickly check if they can enable ATS for a device.
> 
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Tested-by: Ketan Patil <ketanp@nvidia.com>

Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>

> ---
>  drivers/iommu/of_iommu.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 3afe0b48a48db..082b94c2b3291 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -105,6 +105,14 @@ static int of_iommu_configure_device(struct device_node *master_np,
>  		      of_iommu_configure_dev(master_np, dev);
>  }
>  
> +static void of_pci_check_device_ats(struct device *dev, struct device_node *np)
> +{
> +	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> +
> +	if (fwspec && of_property_read_bool(np, "ats-supported"))
> +		fwspec->flags |= IOMMU_FWSPEC_PCI_RC_ATS;
> +}
> +
>  /*
>   * Returns:
>   *  0 on success, an iommu was configured
> @@ -147,6 +155,7 @@ int of_iommu_configure(struct device *dev, struct device_node *master_np,
>  		pci_request_acs();
>  		err = pci_for_each_dma_alias(to_pci_dev(dev),
>  					     of_pci_iommu_init, &info);
> +		of_pci_check_device_ats(dev, master_np);
>  	} else {
>  		err = of_iommu_configure_device(master_np, dev, id);
>  	}
> -- 
> 2.44.0
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: [PATCH 2/3] iommu/of: Support ats-supported device-tree property

[Robin Murphy]

On 29/04/2024 12:39 pm, Jean-Philippe Brucker wrote:
> Device-tree declares whether a PCI root-complex supports ATS by setting
> the "ats-supported" property. Copy this flag into device fwspec to let
> IOMMU drivers quickly check if they can enable ATS for a device.

I don't think this functionally conflicts with what I've got going on in 
this area at the moment, and although the way it fits around the other 
error handling seems a bit obtuse and clunky IMO, apparently that's the 
fault of the existing ACPI implementation, so for now,

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Tested-by: Ketan Patil <ketanp@nvidia.com>
> ---
>   drivers/iommu/of_iommu.c | 9 +++++++++
>   1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 3afe0b48a48db..082b94c2b3291 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -105,6 +105,14 @@ static int of_iommu_configure_device(struct device_node *master_np,
>   		      of_iommu_configure_dev(master_np, dev);
>   }
>   
> +static void of_pci_check_device_ats(struct device *dev, struct device_node *np)
> +{
> +	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> +
> +	if (fwspec && of_property_read_bool(np, "ats-supported"))
> +		fwspec->flags |= IOMMU_FWSPEC_PCI_RC_ATS;
> +}
> +
>   /*
>    * Returns:
>    *  0 on success, an iommu was configured
> @@ -147,6 +155,7 @@ int of_iommu_configure(struct device *dev, struct device_node *master_np,
>   		pci_request_acs();
>   		err = pci_for_each_dma_alias(to_pci_dev(dev),
>   					     of_pci_iommu_init, &info);
> +		of_pci_check_device_ats(dev, master_np);
>   	} else {
>   		err = of_iommu_configure_device(master_np, dev, id);
>   	}

Re: [PATCH 2/3] iommu/of: Support ats-supported device-tree property

[Nicolin Chen]

On Mon, Apr 29, 2024 at 12:39:38PM +0100, Jean-Philippe Brucker wrote:
> Device-tree declares whether a PCI root-complex supports ATS by setting
> the "ats-supported" property. Copy this flag into device fwspec to let
> IOMMU drivers quickly check if they can enable ATS for a device.
> 
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Tested-by: Ketan Patil <ketanp@nvidia.com>

Thank you for sending this!

Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>

[PATCH 3/3] arm64: dts: fvp: Enable PCIe ATS for Base RevC FVP

[Jean-Philippe Brucker]

Declare that the host controller supports ATS, so the OS can enable it
for ATS-capable PCIe endpoints.

Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
---
 arch/arm64/boot/dts/arm/fvp-base-revc.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/arm/fvp-base-revc.dts b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
index 60472d65a3557..85f1c15cc65d0 100644
--- a/arch/arm64/boot/dts/arm/fvp-base-revc.dts
+++ b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
@@ -243,6 +243,7 @@ pci: pci@40000000 {
 		iommu-map = <0x0 &smmu 0x0 0x10000>;
 
 		dma-coherent;
+		ats-supported;
 	};
 
 	smmu: iommu@2b400000 {
-- 
2.44.0

Re: [PATCH 3/3] arm64: dts: fvp: Enable PCIe ATS for Base RevC FVP

[Sudeep Holla]

On Mon, Apr 29, 2024 at 12:39:39PM +0100, Jean-Philippe Brucker wrote:
> Declare that the host controller supports ATS, so the OS can enable it
> for ATS-capable PCIe endpoints.
>

Acked-by: Sudeep Holla <sudeep.holla@arm.com>

--
Regards,
Sudeep

RE: [PATCH 0/3] Enable PCIe ATS for devicetree boot

[Vidya Sagar]

Thanks, Jean for this series.
May I know the current status of it?
Although it was actively reviewed, I see that its current status is set to 
'Handled Elsewhere' in https://patchwork.kernel.org/project/linux-pci/list/?series=848836&state=*
What is the plan to get this series accepted?

Thanks,
Vidya Sagar

> -----Original Message-----
> From: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Sent: Monday, April 29, 2024 5:10 PM
> To: will@kernel.org; lpieralisi@kernel.org; kw@linux.com; robh@kernel.org;
> bhelgaas@google.com; krzk+dt@kernel.org; conor+dt@kernel.org;
> liviu.dudau@arm.com; sudeep.holla@arm.com; joro@8bytes.org
> Cc: robin.murphy@arm.com; Nicolin Chen <nicolinc@nvidia.com>; Ketan Patil
> <ketanp@nvidia.com>; linux-pci@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; iommu@lists.linux.dev; devicetree@vger.kernel.org;
> Jean-Philippe Brucker <jean-philippe@linaro.org>
> Subject: [PATCH 0/3] Enable PCIe ATS for devicetree boot
> 
> External email: Use caution opening links or attachments
> 
> 
> Before enabling Address Translation Support (ATS) in endpoints, the OS needs to
> confirm that the Root Complex supports it. Obtain this information from the
> firmware description since there is no architected method. ACPI provides a bit via
> IORT tables, so add the devicetree equivalent.
> 
> It was discussed a while ago [1], but at the time only a software model supported
> it. Respin it now that hardware is available [2].
> 
> To test this with the Arm RevC model, enable ATS in the endpoint and note that
> ATS is enabled. Address translation is transparent to the OS.
> 
>         -C pci.pcie_rc.ahci0.endpoint.ats_supported=1
> 
>     $ lspci -s 00:1f.0 -vv
>         Capabilities: [100 v1] Address Translation Service (ATS)
>                 ATSCap: Invalidate Queue Depth: 00
>                 ATSCtl: Enable+, Smallest Translation Unit: 00
> 
> 
> [1] https://lore.kernel.org/linux-iommu/20200213165049.508908-1-jean-
> philippe@linaro.org/
> [2] https://lore.kernel.org/linux-arm-kernel/ZeJP6CwrZ2FSbTYm@Asurada-
> Nvidia/
> 
> Jean-Philippe Brucker (3):
>   dt-bindings: PCI: generic: Add ats-supported property
>   iommu/of: Support ats-supported device-tree property
>   arm64: dts: fvp: Enable PCIe ATS for Base RevC FVP
> 
>  .../devicetree/bindings/pci/host-generic-pci.yaml        | 6 ++++++
>  drivers/iommu/of_iommu.c                                 | 9 +++++++++
>  arch/arm64/boot/dts/arm/fvp-base-revc.dts                | 1 +
>  3 files changed, 16 insertions(+)
> 
> --
> 2.44.0
> 

Re: [PATCH 0/3] Enable PCIe ATS for devicetree boot

[Bjorn Helgaas]

On Wed, May 15, 2024 at 06:28:15PM +0000, Vidya Sagar wrote:
> Thanks, Jean for this series.
> May I know the current status of it?
> Although it was actively reviewed, I see that its current status is set to 
> 'Handled Elsewhere' in https://patchwork.kernel.org/project/linux-pci/list/?series=848836&state=*
> What is the plan to get this series accepted?

I probably marked it "handled elsewhere" in the PCI patchwork because
it doesn't touch PCI files (the binding has already been reviewed by
Rob and Liviu), so I assumed the iommu folks would take the series.
I don't know how they track patches.

The merge window is open now, so likely they would wait until the next
cycle so it would have some time in linux-next, but that's up to them.

> > -----Original Message-----
> > From: Jean-Philippe Brucker <jean-philippe@linaro.org>
> > Sent: Monday, April 29, 2024 5:10 PM
> > To: will@kernel.org; lpieralisi@kernel.org; kw@linux.com; robh@kernel.org;
> > bhelgaas@google.com; krzk+dt@kernel.org; conor+dt@kernel.org;
> > liviu.dudau@arm.com; sudeep.holla@arm.com; joro@8bytes.org
> > Cc: robin.murphy@arm.com; Nicolin Chen <nicolinc@nvidia.com>; Ketan Patil
> > <ketanp@nvidia.com>; linux-pci@vger.kernel.org; linux-arm-
> > kernel@lists.infradead.org; iommu@lists.linux.dev; devicetree@vger.kernel.org;
> > Jean-Philippe Brucker <jean-philippe@linaro.org>
> > Subject: [PATCH 0/3] Enable PCIe ATS for devicetree boot
> > 
> > External email: Use caution opening links or attachments
> > 
> > 
> > Before enabling Address Translation Support (ATS) in endpoints, the OS needs to
> > confirm that the Root Complex supports it. Obtain this information from the
> > firmware description since there is no architected method. ACPI provides a bit via
> > IORT tables, so add the devicetree equivalent.
> > 
> > It was discussed a while ago [1], but at the time only a software model supported
> > it. Respin it now that hardware is available [2].
> > 
> > To test this with the Arm RevC model, enable ATS in the endpoint and note that
> > ATS is enabled. Address translation is transparent to the OS.
> > 
> >         -C pci.pcie_rc.ahci0.endpoint.ats_supported=1
> > 
> >     $ lspci -s 00:1f.0 -vv
> >         Capabilities: [100 v1] Address Translation Service (ATS)
> >                 ATSCap: Invalidate Queue Depth: 00
> >                 ATSCtl: Enable+, Smallest Translation Unit: 00
> > 
> > 
> > [1] https://lore.kernel.org/linux-iommu/20200213165049.508908-1-jean-
> > philippe@linaro.org/
> > [2] https://lore.kernel.org/linux-arm-kernel/ZeJP6CwrZ2FSbTYm@Asurada-
> > Nvidia/
> > 
> > Jean-Philippe Brucker (3):
> >   dt-bindings: PCI: generic: Add ats-supported property
> >   iommu/of: Support ats-supported device-tree property
> >   arm64: dts: fvp: Enable PCIe ATS for Base RevC FVP
> > 
> >  .../devicetree/bindings/pci/host-generic-pci.yaml        | 6 ++++++
> >  drivers/iommu/of_iommu.c                                 | 9 +++++++++
> >  arch/arm64/boot/dts/arm/fvp-base-revc.dts                | 1 +
> >  3 files changed, 16 insertions(+)
> > 
> > --
> > 2.44.0
> > 
> 

Re: [PATCH 0/3] Enable PCIe ATS for devicetree boot

[Jean-Philippe Brucker]

Hi,

On Wed, May 15, 2024 at 01:52:41PM -0500, Bjorn Helgaas wrote:
> On Wed, May 15, 2024 at 06:28:15PM +0000, Vidya Sagar wrote:
> > Thanks, Jean for this series.
> > May I know the current status of it?
> > Although it was actively reviewed, I see that its current status is set to 
> > 'Handled Elsewhere' in https://patchwork.kernel.org/project/linux-pci/list/?series=848836&state=*
> > What is the plan to get this series accepted?
> 
> I probably marked it "handled elsewhere" in the PCI patchwork because
> it doesn't touch PCI files (the binding has already been reviewed by
> Rob and Liviu), so I assumed the iommu folks would take the series.
> I don't know how they track patches.

Yes I think this can go through the IOMMU tree. Since patch 3 is still
missing an Ack, I'm resendng the series next cycle.

Thanks,
Jean

> 
> The merge window is open now, so likely they would wait until the next
> cycle so it would have some time in linux-next, but that's up to them.

Re: [PATCH 0/3] Enable PCIe ATS for devicetree boot

[Sudeep Holla]

On Thu, May 16, 2024 at 08:35:00AM +0100, Jean-Philippe Brucker wrote:
> Hi,
> 
> On Wed, May 15, 2024 at 01:52:41PM -0500, Bjorn Helgaas wrote:
> > On Wed, May 15, 2024 at 06:28:15PM +0000, Vidya Sagar wrote:
> > > Thanks, Jean for this series.
> > > May I know the current status of it?
> > > Although it was actively reviewed, I see that its current status is set to 
> > > 'Handled Elsewhere' in https://patchwork.kernel.org/project/linux-pci/list/?series=848836&state=*
> > > What is the plan to get this series accepted?
> > 
> > I probably marked it "handled elsewhere" in the PCI patchwork because
> > it doesn't touch PCI files (the binding has already been reviewed by
> > Rob and Liviu), so I assumed the iommu folks would take the series.
> > I don't know how they track patches.
> 
> Yes I think this can go through the IOMMU tree. Since patch 3 is still
> missing an Ack, I'm resendng the series next cycle.
> 

Extremely sorry for that, since I saw Liviu on the thread, I assumed he
would have acked/reviewed 3/3 as well but now I see that is not the case.
That said, you must not delay the change just for the DTS file changes.
Anyways I will ack it now.

--
Regards,
Sudeep

Re: [PATCH 0/3] Enable PCIe ATS for devicetree boot

[Jean-Philippe Brucker]

On Thu, May 16, 2024 at 11:41:28AM +0100, Sudeep Holla wrote:
> On Thu, May 16, 2024 at 08:35:00AM +0100, Jean-Philippe Brucker wrote:
> > Hi,
> > 
> > On Wed, May 15, 2024 at 01:52:41PM -0500, Bjorn Helgaas wrote:
> > > On Wed, May 15, 2024 at 06:28:15PM +0000, Vidya Sagar wrote:
> > > > Thanks, Jean for this series.
> > > > May I know the current status of it?
> > > > Although it was actively reviewed, I see that its current status is set to 
> > > > 'Handled Elsewhere' in https://patchwork.kernel.org/project/linux-pci/list/?series=848836&state=*
> > > > What is the plan to get this series accepted?
> > > 
> > > I probably marked it "handled elsewhere" in the PCI patchwork because
> > > it doesn't touch PCI files (the binding has already been reviewed by
> > > Rob and Liviu), so I assumed the iommu folks would take the series.
> > > I don't know how they track patches.
> > 
> > Yes I think this can go through the IOMMU tree. Since patch 3 is still
> > missing an Ack, I'm resendng the series next cycle.
> > 
> 
> Extremely sorry for that, since I saw Liviu on the thread, I assumed he
> would have acked/reviewed 3/3 as well but now I see that is not the case.
> That said, you must not delay the change just for the DTS file changes.
> Anyways I will ack it now.

Thanks Sudeep!  It's no problem really, I sent the series very late in the
cycle so wasn't really aiming for 6.10 anyway

Thanks,
Jean

Re: [PATCH 0/3] Enable PCIe ATS for devicetree boot

[liviu.dudau]

On Thu, May 16, 2024 at 11:41:28AM +0100, Sudeep Holla wrote:
> On Thu, May 16, 2024 at 08:35:00AM +0100, Jean-Philippe Brucker wrote:
> > Hi,
> > 
> > On Wed, May 15, 2024 at 01:52:41PM -0500, Bjorn Helgaas wrote:
> > > On Wed, May 15, 2024 at 06:28:15PM +0000, Vidya Sagar wrote:
> > > > Thanks, Jean for this series.
> > > > May I know the current status of it?
> > > > Although it was actively reviewed, I see that its current status is set to 
> > > > 'Handled Elsewhere' in https://patchwork.kernel.org/project/linux-pci/list/?series=848836&state=*
> > > > What is the plan to get this series accepted?
> > > 
> > > I probably marked it "handled elsewhere" in the PCI patchwork because
> > > it doesn't touch PCI files (the binding has already been reviewed by
> > > Rob and Liviu), so I assumed the iommu folks would take the series.
> > > I don't know how they track patches.
> > 
> > Yes I think this can go through the IOMMU tree. Since patch 3 is still
> > missing an Ack, I'm resendng the series next cycle.
> > 
> 
> Extremely sorry for that, since I saw Liviu on the thread, I assumed he
> would have acked/reviewed 3/3 as well but now I see that is not the case.
> That said, you must not delay the change just for the DTS file changes.
> Anyways I will ack it now.

Appologies, I was travelling last week and thought DT changes will be taken
via Robin.

Best regards,
Liviu

> 
> --
> Regards,
> Sudeep

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯