All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] ACPI/IORT: Fix PCI ACS enablement
@ 2017-09-19 17:05 ` Lorenzo Pieralisi
  0 siblings, 0 replies; 18+ messages in thread
From: Lorenzo Pieralisi @ 2017-09-19 17:05 UTC (permalink / raw)
  To: linux-acpi
  Cc: linux-arm-kernel, linux-pci, Lorenzo Pieralisi, Will Deacon,
	Robin Murphy, Zhou Wang, Alex Williamson

commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
workarounds") removed kernel code that was allowing to initialize
and probe the SMMU devices early (ie earlier than PCI devices through
linker script callback entries) in the boot process because it was not
needed any longer in that the SMMU devices/drivers now support deferred
probing.

Since the SMMUs probe routines are also in charge of requesting global
PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
up early-probing workarounds") also postponed PCI ACS enablement to
SMMUs devices probe time, which may be too late given that PCI devices
needs to detect if PCI ACS is enabled to init the respective capability
through the following call path:

pci_device_add()
 -> pci_init_capabilities()
  -> pci_enable_acs()

Add code in the ACPI IORT SMMU platform devices initialization path
(that is called before ACPI PCI enumeration) to detect if an SMMU is
present in HW and enable PCI ACS if it actually is, restoring the
correct PCI ACS enablement sequencing.

Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
Signed-workarounds")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Zhou Wang <wangzhou1@hisilicon.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
---
 drivers/acpi/arm64/iort.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 9565d57..71a7694 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -1184,6 +1184,7 @@ static void __init iort_init_platform_devices(void)
 	struct acpi_table_iort *iort;
 	struct fwnode_handle *fwnode;
 	int i, ret;
+	bool smmu_detected = false;
 
 	/*
 	 * iort_table and iort both point to the start of IORT table, but
@@ -1218,11 +1219,21 @@ static void __init iort_init_platform_devices(void)
 				acpi_free_fwnode_static(fwnode);
 				return;
 			}
+
+			smmu_detected = true;
 		}
 
 		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
 					 iort_node->length);
 	}
+
+	/*
+	 * If IORT reports an SMMU component make sure PCI ACS is
+	 * requested so that PCI devices can enable it in their
+	 * capabilities.
+	 */
+	if (smmu_detected)
+		pci_request_acs();
 }
 
 void __init acpi_iort_init(void)
-- 
2.10.0


^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH] ACPI/IORT: Fix PCI ACS enablement
@ 2017-09-19 17:05 ` Lorenzo Pieralisi
  0 siblings, 0 replies; 18+ messages in thread
From: Lorenzo Pieralisi @ 2017-09-19 17:05 UTC (permalink / raw)
  To: linux-arm-kernel

commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
workarounds") removed kernel code that was allowing to initialize
and probe the SMMU devices early (ie earlier than PCI devices through
linker script callback entries) in the boot process because it was not
needed any longer in that the SMMU devices/drivers now support deferred
probing.

Since the SMMUs probe routines are also in charge of requesting global
PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
up early-probing workarounds") also postponed PCI ACS enablement to
SMMUs devices probe time, which may be too late given that PCI devices
needs to detect if PCI ACS is enabled to init the respective capability
through the following call path:

pci_device_add()
 -> pci_init_capabilities()
  -> pci_enable_acs()

Add code in the ACPI IORT SMMU platform devices initialization path
(that is called before ACPI PCI enumeration) to detect if an SMMU is
present in HW and enable PCI ACS if it actually is, restoring the
correct PCI ACS enablement sequencing.

Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
Signed-workarounds")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Zhou Wang <wangzhou1@hisilicon.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
---
 drivers/acpi/arm64/iort.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 9565d57..71a7694 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -1184,6 +1184,7 @@ static void __init iort_init_platform_devices(void)
 	struct acpi_table_iort *iort;
 	struct fwnode_handle *fwnode;
 	int i, ret;
+	bool smmu_detected = false;
 
 	/*
 	 * iort_table and iort both point to the start of IORT table, but
@@ -1218,11 +1219,21 @@ static void __init iort_init_platform_devices(void)
 				acpi_free_fwnode_static(fwnode);
 				return;
 			}
+
+			smmu_detected = true;
 		}
 
 		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
 					 iort_node->length);
 	}
+
+	/*
+	 * If IORT reports an SMMU component make sure PCI ACS is
+	 * requested so that PCI devices can enable it in their
+	 * capabilities.
+	 */
+	if (smmu_detected)
+		pci_request_acs();
 }
 
 void __init acpi_iort_init(void)
-- 
2.10.0

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [PATCH] ACPI/IORT: Fix PCI ACS enablement
  2017-09-19 17:05 ` Lorenzo Pieralisi
  (?)
@ 2017-09-21 11:32   ` Zhou Wang
  -1 siblings, 0 replies; 18+ messages in thread
From: Zhou Wang @ 2017-09-21 11:32 UTC (permalink / raw)
  To: Lorenzo Pieralisi, linux-acpi
  Cc: linux-arm-kernel, linux-pci, Will Deacon, Robin Murphy, Alex Williamson

On 2017/9/20 1:05, Lorenzo Pieralisi wrote:
> commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> workarounds") removed kernel code that was allowing to initialize
> and probe the SMMU devices early (ie earlier than PCI devices through
> linker script callback entries) in the boot process because it was not
> needed any longer in that the SMMU devices/drivers now support deferred
> probing.
> 
> Since the SMMUs probe routines are also in charge of requesting global
> PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
> up early-probing workarounds") also postponed PCI ACS enablement to
> SMMUs devices probe time, which may be too late given that PCI devices
> needs to detect if PCI ACS is enabled to init the respective capability
> through the following call path:
> 
> pci_device_add()
>  -> pci_init_capabilities()
>   -> pci_enable_acs()
> 
> Add code in the ACPI IORT SMMU platform devices initialization path
> (that is called before ACPI PCI enumeration) to detect if an SMMU is
> present in HW and enable PCI ACS if it actually is, restoring the
> correct PCI ACS enablement sequencing.
> 
> Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> Signed-workarounds")
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Zhou Wang <wangzhou1@hisilicon.com>
> Cc: Alex Williamson <alex.williamson@redhat.com>
> ---
>  drivers/acpi/arm64/iort.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 9565d57..71a7694 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -1184,6 +1184,7 @@ static void __init iort_init_platform_devices(void)
>  	struct acpi_table_iort *iort;
>  	struct fwnode_handle *fwnode;
>  	int i, ret;
> +	bool smmu_detected = false;
>  
>  	/*
>  	 * iort_table and iort both point to the start of IORT table, but
> @@ -1218,11 +1219,21 @@ static void __init iort_init_platform_devices(void)
>  				acpi_free_fwnode_static(fwnode);
>  				return;
>  			}
> +
> +			smmu_detected = true;
>  		}
>  
>  		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
>  					 iort_node->length);
>  	}
> +
> +	/*
> +	 * If IORT reports an SMMU component make sure PCI ACS is
> +	 * requested so that PCI devices can enable it in their
> +	 * capabilities.
> +	 */
> +	if (smmu_detected)
> +		pci_request_acs();
>  }
>  
>  void __init acpi_iort_init(void)
>

Hi Lorenzo,

I tested this patch, it works well in my HiSilicon Hip08 based system.
However, setting ACS flag at the stage of SMMU device init seems not good,
I mean what if in one system there are only platform devices connected to
SMMU device.

Best,
Zhou


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] ACPI/IORT: Fix PCI ACS enablement
@ 2017-09-21 11:32   ` Zhou Wang
  0 siblings, 0 replies; 18+ messages in thread
From: Zhou Wang @ 2017-09-21 11:32 UTC (permalink / raw)
  To: Lorenzo Pieralisi, linux-acpi
  Cc: linux-arm-kernel, linux-pci, Will Deacon, Robin Murphy, Alex Williamson

On 2017/9/20 1:05, Lorenzo Pieralisi wrote:
> commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> workarounds") removed kernel code that was allowing to initialize
> and probe the SMMU devices early (ie earlier than PCI devices through
> linker script callback entries) in the boot process because it was not
> needed any longer in that the SMMU devices/drivers now support deferred
> probing.
> 
> Since the SMMUs probe routines are also in charge of requesting global
> PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
> up early-probing workarounds") also postponed PCI ACS enablement to
> SMMUs devices probe time, which may be too late given that PCI devices
> needs to detect if PCI ACS is enabled to init the respective capability
> through the following call path:
> 
> pci_device_add()
>  -> pci_init_capabilities()
>   -> pci_enable_acs()
> 
> Add code in the ACPI IORT SMMU platform devices initialization path
> (that is called before ACPI PCI enumeration) to detect if an SMMU is
> present in HW and enable PCI ACS if it actually is, restoring the
> correct PCI ACS enablement sequencing.
> 
> Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> Signed-workarounds")
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Zhou Wang <wangzhou1@hisilicon.com>
> Cc: Alex Williamson <alex.williamson@redhat.com>
> ---
>  drivers/acpi/arm64/iort.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 9565d57..71a7694 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -1184,6 +1184,7 @@ static void __init iort_init_platform_devices(void)
>  	struct acpi_table_iort *iort;
>  	struct fwnode_handle *fwnode;
>  	int i, ret;
> +	bool smmu_detected = false;
>  
>  	/*
>  	 * iort_table and iort both point to the start of IORT table, but
> @@ -1218,11 +1219,21 @@ static void __init iort_init_platform_devices(void)
>  				acpi_free_fwnode_static(fwnode);
>  				return;
>  			}
> +
> +			smmu_detected = true;
>  		}
>  
>  		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
>  					 iort_node->length);
>  	}
> +
> +	/*
> +	 * If IORT reports an SMMU component make sure PCI ACS is
> +	 * requested so that PCI devices can enable it in their
> +	 * capabilities.
> +	 */
> +	if (smmu_detected)
> +		pci_request_acs();
>  }
>  
>  void __init acpi_iort_init(void)
>

Hi Lorenzo,

I tested this patch, it works well in my HiSilicon Hip08 based system.
However, setting ACS flag at the stage of SMMU device init seems not good,
I mean what if in one system there are only platform devices connected to
SMMU device.

Best,
Zhou


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH] ACPI/IORT: Fix PCI ACS enablement
@ 2017-09-21 11:32   ` Zhou Wang
  0 siblings, 0 replies; 18+ messages in thread
From: Zhou Wang @ 2017-09-21 11:32 UTC (permalink / raw)
  To: linux-arm-kernel

On 2017/9/20 1:05, Lorenzo Pieralisi wrote:
> commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> workarounds") removed kernel code that was allowing to initialize
> and probe the SMMU devices early (ie earlier than PCI devices through
> linker script callback entries) in the boot process because it was not
> needed any longer in that the SMMU devices/drivers now support deferred
> probing.
> 
> Since the SMMUs probe routines are also in charge of requesting global
> PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
> up early-probing workarounds") also postponed PCI ACS enablement to
> SMMUs devices probe time, which may be too late given that PCI devices
> needs to detect if PCI ACS is enabled to init the respective capability
> through the following call path:
> 
> pci_device_add()
>  -> pci_init_capabilities()
>   -> pci_enable_acs()
> 
> Add code in the ACPI IORT SMMU platform devices initialization path
> (that is called before ACPI PCI enumeration) to detect if an SMMU is
> present in HW and enable PCI ACS if it actually is, restoring the
> correct PCI ACS enablement sequencing.
> 
> Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> Signed-workarounds")
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Zhou Wang <wangzhou1@hisilicon.com>
> Cc: Alex Williamson <alex.williamson@redhat.com>
> ---
>  drivers/acpi/arm64/iort.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 9565d57..71a7694 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -1184,6 +1184,7 @@ static void __init iort_init_platform_devices(void)
>  	struct acpi_table_iort *iort;
>  	struct fwnode_handle *fwnode;
>  	int i, ret;
> +	bool smmu_detected = false;
>  
>  	/*
>  	 * iort_table and iort both point to the start of IORT table, but
> @@ -1218,11 +1219,21 @@ static void __init iort_init_platform_devices(void)
>  				acpi_free_fwnode_static(fwnode);
>  				return;
>  			}
> +
> +			smmu_detected = true;
>  		}
>  
>  		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
>  					 iort_node->length);
>  	}
> +
> +	/*
> +	 * If IORT reports an SMMU component make sure PCI ACS is
> +	 * requested so that PCI devices can enable it in their
> +	 * capabilities.
> +	 */
> +	if (smmu_detected)
> +		pci_request_acs();
>  }
>  
>  void __init acpi_iort_init(void)
>

Hi Lorenzo,

I tested this patch, it works well in my HiSilicon Hip08 based system.
However, setting ACS flag at the stage of SMMU device init seems not good,
I mean what if in one system there are only platform devices connected to
SMMU device.

Best,
Zhou

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] ACPI/IORT: Fix PCI ACS enablement
  2017-09-21 11:32   ` Zhou Wang
@ 2017-09-22  9:45     ` Lorenzo Pieralisi
  -1 siblings, 0 replies; 18+ messages in thread
From: Lorenzo Pieralisi @ 2017-09-22  9:45 UTC (permalink / raw)
  To: Zhou Wang
  Cc: linux-acpi, linux-arm-kernel, linux-pci, Will Deacon,
	Robin Murphy, Alex Williamson

On Thu, Sep 21, 2017 at 07:32:58PM +0800, Zhou Wang wrote:
> On 2017/9/20 1:05, Lorenzo Pieralisi wrote:
> > commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> > workarounds") removed kernel code that was allowing to initialize
> > and probe the SMMU devices early (ie earlier than PCI devices through
> > linker script callback entries) in the boot process because it was not
> > needed any longer in that the SMMU devices/drivers now support deferred
> > probing.
> > 
> > Since the SMMUs probe routines are also in charge of requesting global
> > PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
> > up early-probing workarounds") also postponed PCI ACS enablement to
> > SMMUs devices probe time, which may be too late given that PCI devices
> > needs to detect if PCI ACS is enabled to init the respective capability
> > through the following call path:
> > 
> > pci_device_add()
> >  -> pci_init_capabilities()
> >   -> pci_enable_acs()
> > 
> > Add code in the ACPI IORT SMMU platform devices initialization path
> > (that is called before ACPI PCI enumeration) to detect if an SMMU is
> > present in HW and enable PCI ACS if it actually is, restoring the
> > correct PCI ACS enablement sequencing.
> > 
> > Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> > Signed-workarounds")
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Robin Murphy <robin.murphy@arm.com>
> > Cc: Zhou Wang <wangzhou1@hisilicon.com>
> > Cc: Alex Williamson <alex.williamson@redhat.com>
> > ---
> >  drivers/acpi/arm64/iort.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> > index 9565d57..71a7694 100644
> > --- a/drivers/acpi/arm64/iort.c
> > +++ b/drivers/acpi/arm64/iort.c
> > @@ -1184,6 +1184,7 @@ static void __init iort_init_platform_devices(void)
> >  	struct acpi_table_iort *iort;
> >  	struct fwnode_handle *fwnode;
> >  	int i, ret;
> > +	bool smmu_detected = false;
> >  
> >  	/*
> >  	 * iort_table and iort both point to the start of IORT table, but
> > @@ -1218,11 +1219,21 @@ static void __init iort_init_platform_devices(void)
> >  				acpi_free_fwnode_static(fwnode);
> >  				return;
> >  			}
> > +
> > +			smmu_detected = true;
> >  		}
> >  
> >  		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
> >  					 iort_node->length);
> >  	}
> > +
> > +	/*
> > +	 * If IORT reports an SMMU component make sure PCI ACS is
> > +	 * requested so that PCI devices can enable it in their
> > +	 * capabilities.
> > +	 */
> > +	if (smmu_detected)
> > +		pci_request_acs();
> >  }
> >  
> >  void __init acpi_iort_init(void)
> >
> 
> Hi Lorenzo,
> 
> I tested this patch, it works well in my HiSilicon Hip08 based system.
> However, setting ACS flag at the stage of SMMU device init seems not good,
> I mean what if in one system there are only platform devices connected to
> SMMU device.

That's a fair point if you explain to me how current pci_request_acs()
usage copes with your remark above.

Lorenzo

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH] ACPI/IORT: Fix PCI ACS enablement
@ 2017-09-22  9:45     ` Lorenzo Pieralisi
  0 siblings, 0 replies; 18+ messages in thread
From: Lorenzo Pieralisi @ 2017-09-22  9:45 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Sep 21, 2017 at 07:32:58PM +0800, Zhou Wang wrote:
> On 2017/9/20 1:05, Lorenzo Pieralisi wrote:
> > commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> > workarounds") removed kernel code that was allowing to initialize
> > and probe the SMMU devices early (ie earlier than PCI devices through
> > linker script callback entries) in the boot process because it was not
> > needed any longer in that the SMMU devices/drivers now support deferred
> > probing.
> > 
> > Since the SMMUs probe routines are also in charge of requesting global
> > PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
> > up early-probing workarounds") also postponed PCI ACS enablement to
> > SMMUs devices probe time, which may be too late given that PCI devices
> > needs to detect if PCI ACS is enabled to init the respective capability
> > through the following call path:
> > 
> > pci_device_add()
> >  -> pci_init_capabilities()
> >   -> pci_enable_acs()
> > 
> > Add code in the ACPI IORT SMMU platform devices initialization path
> > (that is called before ACPI PCI enumeration) to detect if an SMMU is
> > present in HW and enable PCI ACS if it actually is, restoring the
> > correct PCI ACS enablement sequencing.
> > 
> > Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> > Signed-workarounds")
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Robin Murphy <robin.murphy@arm.com>
> > Cc: Zhou Wang <wangzhou1@hisilicon.com>
> > Cc: Alex Williamson <alex.williamson@redhat.com>
> > ---
> >  drivers/acpi/arm64/iort.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> > index 9565d57..71a7694 100644
> > --- a/drivers/acpi/arm64/iort.c
> > +++ b/drivers/acpi/arm64/iort.c
> > @@ -1184,6 +1184,7 @@ static void __init iort_init_platform_devices(void)
> >  	struct acpi_table_iort *iort;
> >  	struct fwnode_handle *fwnode;
> >  	int i, ret;
> > +	bool smmu_detected = false;
> >  
> >  	/*
> >  	 * iort_table and iort both point to the start of IORT table, but
> > @@ -1218,11 +1219,21 @@ static void __init iort_init_platform_devices(void)
> >  				acpi_free_fwnode_static(fwnode);
> >  				return;
> >  			}
> > +
> > +			smmu_detected = true;
> >  		}
> >  
> >  		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
> >  					 iort_node->length);
> >  	}
> > +
> > +	/*
> > +	 * If IORT reports an SMMU component make sure PCI ACS is
> > +	 * requested so that PCI devices can enable it in their
> > +	 * capabilities.
> > +	 */
> > +	if (smmu_detected)
> > +		pci_request_acs();
> >  }
> >  
> >  void __init acpi_iort_init(void)
> >
> 
> Hi Lorenzo,
> 
> I tested this patch, it works well in my HiSilicon Hip08 based system.
> However, setting ACS flag at the stage of SMMU device init seems not good,
> I mean what if in one system there are only platform devices connected to
> SMMU device.

That's a fair point if you explain to me how current pci_request_acs()
usage copes with your remark above.

Lorenzo

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] ACPI/IORT: Fix PCI ACS enablement
  2017-09-22  9:45     ` Lorenzo Pieralisi
  (?)
@ 2017-09-23  2:26       ` Zhou Wang
  -1 siblings, 0 replies; 18+ messages in thread
From: Zhou Wang @ 2017-09-23  2:26 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: linux-acpi, linux-arm-kernel, linux-pci, Will Deacon,
	Robin Murphy, Alex Williamson

On 2017/9/22 17:45, Lorenzo Pieralisi wrote:
> On Thu, Sep 21, 2017 at 07:32:58PM +0800, Zhou Wang wrote:
>> On 2017/9/20 1:05, Lorenzo Pieralisi wrote:
>>> commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
>>> workarounds") removed kernel code that was allowing to initialize
>>> and probe the SMMU devices early (ie earlier than PCI devices through
>>> linker script callback entries) in the boot process because it was not
>>> needed any longer in that the SMMU devices/drivers now support deferred
>>> probing.
>>>
>>> Since the SMMUs probe routines are also in charge of requesting global
>>> PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
>>> up early-probing workarounds") also postponed PCI ACS enablement to
>>> SMMUs devices probe time, which may be too late given that PCI devices
>>> needs to detect if PCI ACS is enabled to init the respective capability
>>> through the following call path:
>>>
>>> pci_device_add()
>>>  -> pci_init_capabilities()
>>>   -> pci_enable_acs()
>>>
>>> Add code in the ACPI IORT SMMU platform devices initialization path
>>> (that is called before ACPI PCI enumeration) to detect if an SMMU is
>>> present in HW and enable PCI ACS if it actually is, restoring the
>>> correct PCI ACS enablement sequencing.
>>>
>>> Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
>>> Signed-workarounds")
>>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>>> Cc: Will Deacon <will.deacon@arm.com>
>>> Cc: Robin Murphy <robin.murphy@arm.com>
>>> Cc: Zhou Wang <wangzhou1@hisilicon.com>
>>> Cc: Alex Williamson <alex.williamson@redhat.com>
>>> ---
>>>  drivers/acpi/arm64/iort.c | 11 +++++++++++
>>>  1 file changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>>> index 9565d57..71a7694 100644
>>> --- a/drivers/acpi/arm64/iort.c
>>> +++ b/drivers/acpi/arm64/iort.c
>>> @@ -1184,6 +1184,7 @@ static void __init iort_init_platform_devices(void)
>>>  	struct acpi_table_iort *iort;
>>>  	struct fwnode_handle *fwnode;
>>>  	int i, ret;
>>> +	bool smmu_detected = false;
>>>  
>>>  	/*
>>>  	 * iort_table and iort both point to the start of IORT table, but
>>> @@ -1218,11 +1219,21 @@ static void __init iort_init_platform_devices(void)
>>>  				acpi_free_fwnode_static(fwnode);
>>>  				return;
>>>  			}
>>> +
>>> +			smmu_detected = true;
>>>  		}
>>>  
>>>  		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
>>>  					 iort_node->length);
>>>  	}
>>> +
>>> +	/*
>>> +	 * If IORT reports an SMMU component make sure PCI ACS is
>>> +	 * requested so that PCI devices can enable it in their
>>> +	 * capabilities.
>>> +	 */
>>> +	if (smmu_detected)
>>> +		pci_request_acs();
>>>  }
>>>  
>>>  void __init acpi_iort_init(void)
>>>
>>
>> Hi Lorenzo,
>>
>> I tested this patch, it works well in my HiSilicon Hip08 based system.
>> However, setting ACS flag at the stage of SMMU device init seems not good,
>> I mean what if in one system there are only platform devices connected to
>> SMMU device.
> 
> That's a fair point if you explain to me how current pci_request_acs()
> usage copes with your remark above.

The current pci_request_acs usage for ARM SMMU-V3 sets ACS flags under CONFIG_PCI.
However, as mentioned in your commit message, this setting is too late.

For the usage of X86 and AMD, as I am not familiar with the devices used in these
two platforms, maybe the default devices in these platforms are PCIe based :)

Best,
Zhou

> 
> Lorenzo
> 
> .
> 


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] ACPI/IORT: Fix PCI ACS enablement
@ 2017-09-23  2:26       ` Zhou Wang
  0 siblings, 0 replies; 18+ messages in thread
From: Zhou Wang @ 2017-09-23  2:26 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: linux-acpi, linux-arm-kernel, linux-pci, Will Deacon,
	Robin Murphy, Alex Williamson

On 2017/9/22 17:45, Lorenzo Pieralisi wrote:
> On Thu, Sep 21, 2017 at 07:32:58PM +0800, Zhou Wang wrote:
>> On 2017/9/20 1:05, Lorenzo Pieralisi wrote:
>>> commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
>>> workarounds") removed kernel code that was allowing to initialize
>>> and probe the SMMU devices early (ie earlier than PCI devices through
>>> linker script callback entries) in the boot process because it was not
>>> needed any longer in that the SMMU devices/drivers now support deferred
>>> probing.
>>>
>>> Since the SMMUs probe routines are also in charge of requesting global
>>> PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
>>> up early-probing workarounds") also postponed PCI ACS enablement to
>>> SMMUs devices probe time, which may be too late given that PCI devices
>>> needs to detect if PCI ACS is enabled to init the respective capability
>>> through the following call path:
>>>
>>> pci_device_add()
>>>  -> pci_init_capabilities()
>>>   -> pci_enable_acs()
>>>
>>> Add code in the ACPI IORT SMMU platform devices initialization path
>>> (that is called before ACPI PCI enumeration) to detect if an SMMU is
>>> present in HW and enable PCI ACS if it actually is, restoring the
>>> correct PCI ACS enablement sequencing.
>>>
>>> Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
>>> Signed-workarounds")
>>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>>> Cc: Will Deacon <will.deacon@arm.com>
>>> Cc: Robin Murphy <robin.murphy@arm.com>
>>> Cc: Zhou Wang <wangzhou1@hisilicon.com>
>>> Cc: Alex Williamson <alex.williamson@redhat.com>
>>> ---
>>>  drivers/acpi/arm64/iort.c | 11 +++++++++++
>>>  1 file changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>>> index 9565d57..71a7694 100644
>>> --- a/drivers/acpi/arm64/iort.c
>>> +++ b/drivers/acpi/arm64/iort.c
>>> @@ -1184,6 +1184,7 @@ static void __init iort_init_platform_devices(void)
>>>  	struct acpi_table_iort *iort;
>>>  	struct fwnode_handle *fwnode;
>>>  	int i, ret;
>>> +	bool smmu_detected = false;
>>>  
>>>  	/*
>>>  	 * iort_table and iort both point to the start of IORT table, but
>>> @@ -1218,11 +1219,21 @@ static void __init iort_init_platform_devices(void)
>>>  				acpi_free_fwnode_static(fwnode);
>>>  				return;
>>>  			}
>>> +
>>> +			smmu_detected = true;
>>>  		}
>>>  
>>>  		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
>>>  					 iort_node->length);
>>>  	}
>>> +
>>> +	/*
>>> +	 * If IORT reports an SMMU component make sure PCI ACS is
>>> +	 * requested so that PCI devices can enable it in their
>>> +	 * capabilities.
>>> +	 */
>>> +	if (smmu_detected)
>>> +		pci_request_acs();
>>>  }
>>>  
>>>  void __init acpi_iort_init(void)
>>>
>>
>> Hi Lorenzo,
>>
>> I tested this patch, it works well in my HiSilicon Hip08 based system.
>> However, setting ACS flag at the stage of SMMU device init seems not good,
>> I mean what if in one system there are only platform devices connected to
>> SMMU device.
> 
> That's a fair point if you explain to me how current pci_request_acs()
> usage copes with your remark above.

The current pci_request_acs usage for ARM SMMU-V3 sets ACS flags under CONFIG_PCI.
However, as mentioned in your commit message, this setting is too late.

For the usage of X86 and AMD, as I am not familiar with the devices used in these
two platforms, maybe the default devices in these platforms are PCIe based :)

Best,
Zhou

> 
> Lorenzo
> 
> .
> 


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH] ACPI/IORT: Fix PCI ACS enablement
@ 2017-09-23  2:26       ` Zhou Wang
  0 siblings, 0 replies; 18+ messages in thread
From: Zhou Wang @ 2017-09-23  2:26 UTC (permalink / raw)
  To: linux-arm-kernel

On 2017/9/22 17:45, Lorenzo Pieralisi wrote:
> On Thu, Sep 21, 2017 at 07:32:58PM +0800, Zhou Wang wrote:
>> On 2017/9/20 1:05, Lorenzo Pieralisi wrote:
>>> commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
>>> workarounds") removed kernel code that was allowing to initialize
>>> and probe the SMMU devices early (ie earlier than PCI devices through
>>> linker script callback entries) in the boot process because it was not
>>> needed any longer in that the SMMU devices/drivers now support deferred
>>> probing.
>>>
>>> Since the SMMUs probe routines are also in charge of requesting global
>>> PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
>>> up early-probing workarounds") also postponed PCI ACS enablement to
>>> SMMUs devices probe time, which may be too late given that PCI devices
>>> needs to detect if PCI ACS is enabled to init the respective capability
>>> through the following call path:
>>>
>>> pci_device_add()
>>>  -> pci_init_capabilities()
>>>   -> pci_enable_acs()
>>>
>>> Add code in the ACPI IORT SMMU platform devices initialization path
>>> (that is called before ACPI PCI enumeration) to detect if an SMMU is
>>> present in HW and enable PCI ACS if it actually is, restoring the
>>> correct PCI ACS enablement sequencing.
>>>
>>> Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
>>> Signed-workarounds")
>>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>>> Cc: Will Deacon <will.deacon@arm.com>
>>> Cc: Robin Murphy <robin.murphy@arm.com>
>>> Cc: Zhou Wang <wangzhou1@hisilicon.com>
>>> Cc: Alex Williamson <alex.williamson@redhat.com>
>>> ---
>>>  drivers/acpi/arm64/iort.c | 11 +++++++++++
>>>  1 file changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>>> index 9565d57..71a7694 100644
>>> --- a/drivers/acpi/arm64/iort.c
>>> +++ b/drivers/acpi/arm64/iort.c
>>> @@ -1184,6 +1184,7 @@ static void __init iort_init_platform_devices(void)
>>>  	struct acpi_table_iort *iort;
>>>  	struct fwnode_handle *fwnode;
>>>  	int i, ret;
>>> +	bool smmu_detected = false;
>>>  
>>>  	/*
>>>  	 * iort_table and iort both point to the start of IORT table, but
>>> @@ -1218,11 +1219,21 @@ static void __init iort_init_platform_devices(void)
>>>  				acpi_free_fwnode_static(fwnode);
>>>  				return;
>>>  			}
>>> +
>>> +			smmu_detected = true;
>>>  		}
>>>  
>>>  		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
>>>  					 iort_node->length);
>>>  	}
>>> +
>>> +	/*
>>> +	 * If IORT reports an SMMU component make sure PCI ACS is
>>> +	 * requested so that PCI devices can enable it in their
>>> +	 * capabilities.
>>> +	 */
>>> +	if (smmu_detected)
>>> +		pci_request_acs();
>>>  }
>>>  
>>>  void __init acpi_iort_init(void)
>>>
>>
>> Hi Lorenzo,
>>
>> I tested this patch, it works well in my HiSilicon Hip08 based system.
>> However, setting ACS flag at the stage of SMMU device init seems not good,
>> I mean what if in one system there are only platform devices connected to
>> SMMU device.
> 
> That's a fair point if you explain to me how current pci_request_acs()
> usage copes with your remark above.

The current pci_request_acs usage for ARM SMMU-V3 sets ACS flags under CONFIG_PCI.
However, as mentioned in your commit message, this setting is too late.

For the usage of X86 and AMD, as I am not familiar with the devices used in these
two platforms, maybe the default devices in these platforms are PCIe based :)

Best,
Zhou

> 
> Lorenzo
> 
> .
> 

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] ACPI/IORT: Fix PCI ACS enablement
  2017-09-23  2:26       ` Zhou Wang
@ 2017-09-28 15:46         ` Lorenzo Pieralisi
  -1 siblings, 0 replies; 18+ messages in thread
From: Lorenzo Pieralisi @ 2017-09-28 15:46 UTC (permalink / raw)
  To: Zhou Wang
  Cc: linux-acpi, linux-arm-kernel, linux-pci, Will Deacon,
	Robin Murphy, Alex Williamson

On Sat, Sep 23, 2017 at 10:26:29AM +0800, Zhou Wang wrote:
> On 2017/9/22 17:45, Lorenzo Pieralisi wrote:
> > On Thu, Sep 21, 2017 at 07:32:58PM +0800, Zhou Wang wrote:
> >> On 2017/9/20 1:05, Lorenzo Pieralisi wrote:
> >>> commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> >>> workarounds") removed kernel code that was allowing to initialize
> >>> and probe the SMMU devices early (ie earlier than PCI devices through
> >>> linker script callback entries) in the boot process because it was not
> >>> needed any longer in that the SMMU devices/drivers now support deferred
> >>> probing.
> >>>
> >>> Since the SMMUs probe routines are also in charge of requesting global
> >>> PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
> >>> up early-probing workarounds") also postponed PCI ACS enablement to
> >>> SMMUs devices probe time, which may be too late given that PCI devices
> >>> needs to detect if PCI ACS is enabled to init the respective capability
> >>> through the following call path:
> >>>
> >>> pci_device_add()
> >>>  -> pci_init_capabilities()
> >>>   -> pci_enable_acs()
> >>>
> >>> Add code in the ACPI IORT SMMU platform devices initialization path
> >>> (that is called before ACPI PCI enumeration) to detect if an SMMU is
> >>> present in HW and enable PCI ACS if it actually is, restoring the
> >>> correct PCI ACS enablement sequencing.
> >>>
> >>> Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> >>> Signed-workarounds")
> >>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >>> Cc: Will Deacon <will.deacon@arm.com>
> >>> Cc: Robin Murphy <robin.murphy@arm.com>
> >>> Cc: Zhou Wang <wangzhou1@hisilicon.com>
> >>> Cc: Alex Williamson <alex.williamson@redhat.com>
> >>> ---
> >>>  drivers/acpi/arm64/iort.c | 11 +++++++++++
> >>>  1 file changed, 11 insertions(+)
> >>>
> >>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> >>> index 9565d57..71a7694 100644
> >>> --- a/drivers/acpi/arm64/iort.c
> >>> +++ b/drivers/acpi/arm64/iort.c
> >>> @@ -1184,6 +1184,7 @@ static void __init iort_init_platform_devices(void)
> >>>  	struct acpi_table_iort *iort;
> >>>  	struct fwnode_handle *fwnode;
> >>>  	int i, ret;
> >>> +	bool smmu_detected = false;
> >>>  
> >>>  	/*
> >>>  	 * iort_table and iort both point to the start of IORT table, but
> >>> @@ -1218,11 +1219,21 @@ static void __init iort_init_platform_devices(void)
> >>>  				acpi_free_fwnode_static(fwnode);
> >>>  				return;
> >>>  			}
> >>> +
> >>> +			smmu_detected = true;
> >>>  		}
> >>>  
> >>>  		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
> >>>  					 iort_node->length);
> >>>  	}
> >>> +
> >>> +	/*
> >>> +	 * If IORT reports an SMMU component make sure PCI ACS is
> >>> +	 * requested so that PCI devices can enable it in their
> >>> +	 * capabilities.
> >>> +	 */
> >>> +	if (smmu_detected)
> >>> +		pci_request_acs();
> >>>  }
> >>>  
> >>>  void __init acpi_iort_init(void)
> >>>
> >>
> >> Hi Lorenzo,
> >>
> >> I tested this patch, it works well in my HiSilicon Hip08 based system.
> >> However, setting ACS flag at the stage of SMMU device init seems not good,
> >> I mean what if in one system there are only platform devices connected to
> >> SMMU device.
> > 
> > That's a fair point if you explain to me how current pci_request_acs()
> > usage copes with your remark above.
> 
> The current pci_request_acs usage for ARM SMMU-V3 sets ACS flags under CONFIG_PCI.
> However, as mentioned in your commit message, this setting is too late.
> 
> For the usage of X86 and AMD, as I am not familiar with the devices used in these
> two platforms, maybe the default devices in these platforms are PCIe based :)

I do not understand what your point is. ACS enablement is a global flag,
that is currently set whenever an x86/AMD/ARM IOMMU is detected/probed
AFAICS.

I agree that ACS enablement should be done before PCI enumeration,
for other comments either you are questioning the current policy
behind ACS enablement in the kernel - which can be a fair point - or
I do not understand what you mean.

Let me know since I would like to queue this patch unless I hear
a compelling objection to it.

Lorenzo

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH] ACPI/IORT: Fix PCI ACS enablement
@ 2017-09-28 15:46         ` Lorenzo Pieralisi
  0 siblings, 0 replies; 18+ messages in thread
From: Lorenzo Pieralisi @ 2017-09-28 15:46 UTC (permalink / raw)
  To: linux-arm-kernel

On Sat, Sep 23, 2017 at 10:26:29AM +0800, Zhou Wang wrote:
> On 2017/9/22 17:45, Lorenzo Pieralisi wrote:
> > On Thu, Sep 21, 2017 at 07:32:58PM +0800, Zhou Wang wrote:
> >> On 2017/9/20 1:05, Lorenzo Pieralisi wrote:
> >>> commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> >>> workarounds") removed kernel code that was allowing to initialize
> >>> and probe the SMMU devices early (ie earlier than PCI devices through
> >>> linker script callback entries) in the boot process because it was not
> >>> needed any longer in that the SMMU devices/drivers now support deferred
> >>> probing.
> >>>
> >>> Since the SMMUs probe routines are also in charge of requesting global
> >>> PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
> >>> up early-probing workarounds") also postponed PCI ACS enablement to
> >>> SMMUs devices probe time, which may be too late given that PCI devices
> >>> needs to detect if PCI ACS is enabled to init the respective capability
> >>> through the following call path:
> >>>
> >>> pci_device_add()
> >>>  -> pci_init_capabilities()
> >>>   -> pci_enable_acs()
> >>>
> >>> Add code in the ACPI IORT SMMU platform devices initialization path
> >>> (that is called before ACPI PCI enumeration) to detect if an SMMU is
> >>> present in HW and enable PCI ACS if it actually is, restoring the
> >>> correct PCI ACS enablement sequencing.
> >>>
> >>> Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> >>> Signed-workarounds")
> >>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >>> Cc: Will Deacon <will.deacon@arm.com>
> >>> Cc: Robin Murphy <robin.murphy@arm.com>
> >>> Cc: Zhou Wang <wangzhou1@hisilicon.com>
> >>> Cc: Alex Williamson <alex.williamson@redhat.com>
> >>> ---
> >>>  drivers/acpi/arm64/iort.c | 11 +++++++++++
> >>>  1 file changed, 11 insertions(+)
> >>>
> >>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> >>> index 9565d57..71a7694 100644
> >>> --- a/drivers/acpi/arm64/iort.c
> >>> +++ b/drivers/acpi/arm64/iort.c
> >>> @@ -1184,6 +1184,7 @@ static void __init iort_init_platform_devices(void)
> >>>  	struct acpi_table_iort *iort;
> >>>  	struct fwnode_handle *fwnode;
> >>>  	int i, ret;
> >>> +	bool smmu_detected = false;
> >>>  
> >>>  	/*
> >>>  	 * iort_table and iort both point to the start of IORT table, but
> >>> @@ -1218,11 +1219,21 @@ static void __init iort_init_platform_devices(void)
> >>>  				acpi_free_fwnode_static(fwnode);
> >>>  				return;
> >>>  			}
> >>> +
> >>> +			smmu_detected = true;
> >>>  		}
> >>>  
> >>>  		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
> >>>  					 iort_node->length);
> >>>  	}
> >>> +
> >>> +	/*
> >>> +	 * If IORT reports an SMMU component make sure PCI ACS is
> >>> +	 * requested so that PCI devices can enable it in their
> >>> +	 * capabilities.
> >>> +	 */
> >>> +	if (smmu_detected)
> >>> +		pci_request_acs();
> >>>  }
> >>>  
> >>>  void __init acpi_iort_init(void)
> >>>
> >>
> >> Hi Lorenzo,
> >>
> >> I tested this patch, it works well in my HiSilicon Hip08 based system.
> >> However, setting ACS flag at the stage of SMMU device init seems not good,
> >> I mean what if in one system there are only platform devices connected to
> >> SMMU device.
> > 
> > That's a fair point if you explain to me how current pci_request_acs()
> > usage copes with your remark above.
> 
> The current pci_request_acs usage for ARM SMMU-V3 sets ACS flags under CONFIG_PCI.
> However, as mentioned in your commit message, this setting is too late.
> 
> For the usage of X86 and AMD, as I am not familiar with the devices used in these
> two platforms, maybe the default devices in these platforms are PCIe based :)

I do not understand what your point is. ACS enablement is a global flag,
that is currently set whenever an x86/AMD/ARM IOMMU is detected/probed
AFAICS.

I agree that ACS enablement should be done before PCI enumeration,
for other comments either you are questioning the current policy
behind ACS enablement in the kernel - which can be a fair point - or
I do not understand what you mean.

Let me know since I would like to queue this patch unless I hear
a compelling objection to it.

Lorenzo

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] ACPI/IORT: Fix PCI ACS enablement
  2017-09-28 15:46         ` Lorenzo Pieralisi
  (?)
@ 2017-09-29  4:23           ` Zhou Wang
  -1 siblings, 0 replies; 18+ messages in thread
From: Zhou Wang @ 2017-09-29  4:23 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: linux-acpi, linux-arm-kernel, linux-pci, Will Deacon,
	Robin Murphy, Alex Williamson

On 2017/9/28 23:46, Lorenzo Pieralisi wrote:
> On Sat, Sep 23, 2017 at 10:26:29AM +0800, Zhou Wang wrote:
>> On 2017/9/22 17:45, Lorenzo Pieralisi wrote:
>>> On Thu, Sep 21, 2017 at 07:32:58PM +0800, Zhou Wang wrote:
>>>> On 2017/9/20 1:05, Lorenzo Pieralisi wrote:
>>>>> commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
>>>>> workarounds") removed kernel code that was allowing to initialize
>>>>> and probe the SMMU devices early (ie earlier than PCI devices through
>>>>> linker script callback entries) in the boot process because it was not
>>>>> needed any longer in that the SMMU devices/drivers now support deferred
>>>>> probing.
>>>>>
>>>>> Since the SMMUs probe routines are also in charge of requesting global
>>>>> PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
>>>>> up early-probing workarounds") also postponed PCI ACS enablement to
>>>>> SMMUs devices probe time, which may be too late given that PCI devices
>>>>> needs to detect if PCI ACS is enabled to init the respective capability
>>>>> through the following call path:
>>>>>
>>>>> pci_device_add()
>>>>>  -> pci_init_capabilities()
>>>>>   -> pci_enable_acs()
>>>>>
>>>>> Add code in the ACPI IORT SMMU platform devices initialization path
>>>>> (that is called before ACPI PCI enumeration) to detect if an SMMU is
>>>>> present in HW and enable PCI ACS if it actually is, restoring the
>>>>> correct PCI ACS enablement sequencing.
>>>>>
>>>>> Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
>>>>> Signed-workarounds")
>>>>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>>>>> Cc: Will Deacon <will.deacon@arm.com>
>>>>> Cc: Robin Murphy <robin.murphy@arm.com>
>>>>> Cc: Zhou Wang <wangzhou1@hisilicon.com>
>>>>> Cc: Alex Williamson <alex.williamson@redhat.com>
>>>>> ---
>>>>>  drivers/acpi/arm64/iort.c | 11 +++++++++++
>>>>>  1 file changed, 11 insertions(+)
>>>>>
>>>>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>>>>> index 9565d57..71a7694 100644
>>>>> --- a/drivers/acpi/arm64/iort.c
>>>>> +++ b/drivers/acpi/arm64/iort.c
>>>>> @@ -1184,6 +1184,7 @@ static void __init iort_init_platform_devices(void)
>>>>>  	struct acpi_table_iort *iort;
>>>>>  	struct fwnode_handle *fwnode;
>>>>>  	int i, ret;
>>>>> +	bool smmu_detected = false;
>>>>>  
>>>>>  	/*
>>>>>  	 * iort_table and iort both point to the start of IORT table, but
>>>>> @@ -1218,11 +1219,21 @@ static void __init iort_init_platform_devices(void)
>>>>>  				acpi_free_fwnode_static(fwnode);
>>>>>  				return;
>>>>>  			}
>>>>> +
>>>>> +			smmu_detected = true;
>>>>>  		}
>>>>>  
>>>>>  		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
>>>>>  					 iort_node->length);
>>>>>  	}
>>>>> +
>>>>> +	/*
>>>>> +	 * If IORT reports an SMMU component make sure PCI ACS is
>>>>> +	 * requested so that PCI devices can enable it in their
>>>>> +	 * capabilities.
>>>>> +	 */
>>>>> +	if (smmu_detected)
>>>>> +		pci_request_acs();
>>>>>  }
>>>>>  
>>>>>  void __init acpi_iort_init(void)
>>>>>
>>>>
>>>> Hi Lorenzo,
>>>>
>>>> I tested this patch, it works well in my HiSilicon Hip08 based system.
>>>> However, setting ACS flag at the stage of SMMU device init seems not good,
>>>> I mean what if in one system there are only platform devices connected to
>>>> SMMU device.
>>>
>>> That's a fair point if you explain to me how current pci_request_acs()
>>> usage copes with your remark above.
>>
>> The current pci_request_acs usage for ARM SMMU-V3 sets ACS flags under CONFIG_PCI.
>> However, as mentioned in your commit message, this setting is too late.
>>
>> For the usage of X86 and AMD, as I am not familiar with the devices used in these
>> two platforms, maybe the default devices in these platforms are PCIe based :)
> 
> I do not understand what your point is. ACS enablement is a global flag,
> that is currently set whenever an x86/AMD/ARM IOMMU is detected/probed
> AFAICS.

There are named devices(platform devices) and/or PCI devices connected to SMMU.
However, ACS flags is only for PCI devices. So setting this flag in SMMU device init
maybe need check if there are PCIe devices connected to SMMU, as maybe devices connected
to SMMU are all named devices.

> 
> I agree that ACS enablement should be done before PCI enumeration,
> for other comments either you are questioning the current policy
> behind ACS enablement in the kernel - which can be a fair point - or
> I do not understand what you mean.
> 
> Let me know since I would like to queue this patch unless I hear
> a compelling objection to it.

I think this is not a big problem. If you want to queue this patch, you can add:

Tested-by: Zhou Wang <wangzhou1@hisilicon.com>

Thanks,
Zhou

> 
> Lorenzo
> 
> .
> 


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] ACPI/IORT: Fix PCI ACS enablement
@ 2017-09-29  4:23           ` Zhou Wang
  0 siblings, 0 replies; 18+ messages in thread
From: Zhou Wang @ 2017-09-29  4:23 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: linux-acpi, linux-arm-kernel, linux-pci, Will Deacon,
	Robin Murphy, Alex Williamson

On 2017/9/28 23:46, Lorenzo Pieralisi wrote:
> On Sat, Sep 23, 2017 at 10:26:29AM +0800, Zhou Wang wrote:
>> On 2017/9/22 17:45, Lorenzo Pieralisi wrote:
>>> On Thu, Sep 21, 2017 at 07:32:58PM +0800, Zhou Wang wrote:
>>>> On 2017/9/20 1:05, Lorenzo Pieralisi wrote:
>>>>> commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
>>>>> workarounds") removed kernel code that was allowing to initialize
>>>>> and probe the SMMU devices early (ie earlier than PCI devices through
>>>>> linker script callback entries) in the boot process because it was not
>>>>> needed any longer in that the SMMU devices/drivers now support deferred
>>>>> probing.
>>>>>
>>>>> Since the SMMUs probe routines are also in charge of requesting global
>>>>> PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
>>>>> up early-probing workarounds") also postponed PCI ACS enablement to
>>>>> SMMUs devices probe time, which may be too late given that PCI devices
>>>>> needs to detect if PCI ACS is enabled to init the respective capability
>>>>> through the following call path:
>>>>>
>>>>> pci_device_add()
>>>>>  -> pci_init_capabilities()
>>>>>   -> pci_enable_acs()
>>>>>
>>>>> Add code in the ACPI IORT SMMU platform devices initialization path
>>>>> (that is called before ACPI PCI enumeration) to detect if an SMMU is
>>>>> present in HW and enable PCI ACS if it actually is, restoring the
>>>>> correct PCI ACS enablement sequencing.
>>>>>
>>>>> Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
>>>>> Signed-workarounds")
>>>>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>>>>> Cc: Will Deacon <will.deacon@arm.com>
>>>>> Cc: Robin Murphy <robin.murphy@arm.com>
>>>>> Cc: Zhou Wang <wangzhou1@hisilicon.com>
>>>>> Cc: Alex Williamson <alex.williamson@redhat.com>
>>>>> ---
>>>>>  drivers/acpi/arm64/iort.c | 11 +++++++++++
>>>>>  1 file changed, 11 insertions(+)
>>>>>
>>>>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>>>>> index 9565d57..71a7694 100644
>>>>> --- a/drivers/acpi/arm64/iort.c
>>>>> +++ b/drivers/acpi/arm64/iort.c
>>>>> @@ -1184,6 +1184,7 @@ static void __init iort_init_platform_devices(void)
>>>>>  	struct acpi_table_iort *iort;
>>>>>  	struct fwnode_handle *fwnode;
>>>>>  	int i, ret;
>>>>> +	bool smmu_detected = false;
>>>>>  
>>>>>  	/*
>>>>>  	 * iort_table and iort both point to the start of IORT table, but
>>>>> @@ -1218,11 +1219,21 @@ static void __init iort_init_platform_devices(void)
>>>>>  				acpi_free_fwnode_static(fwnode);
>>>>>  				return;
>>>>>  			}
>>>>> +
>>>>> +			smmu_detected = true;
>>>>>  		}
>>>>>  
>>>>>  		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
>>>>>  					 iort_node->length);
>>>>>  	}
>>>>> +
>>>>> +	/*
>>>>> +	 * If IORT reports an SMMU component make sure PCI ACS is
>>>>> +	 * requested so that PCI devices can enable it in their
>>>>> +	 * capabilities.
>>>>> +	 */
>>>>> +	if (smmu_detected)
>>>>> +		pci_request_acs();
>>>>>  }
>>>>>  
>>>>>  void __init acpi_iort_init(void)
>>>>>
>>>>
>>>> Hi Lorenzo,
>>>>
>>>> I tested this patch, it works well in my HiSilicon Hip08 based system.
>>>> However, setting ACS flag at the stage of SMMU device init seems not good,
>>>> I mean what if in one system there are only platform devices connected to
>>>> SMMU device.
>>>
>>> That's a fair point if you explain to me how current pci_request_acs()
>>> usage copes with your remark above.
>>
>> The current pci_request_acs usage for ARM SMMU-V3 sets ACS flags under CONFIG_PCI.
>> However, as mentioned in your commit message, this setting is too late.
>>
>> For the usage of X86 and AMD, as I am not familiar with the devices used in these
>> two platforms, maybe the default devices in these platforms are PCIe based :)
> 
> I do not understand what your point is. ACS enablement is a global flag,
> that is currently set whenever an x86/AMD/ARM IOMMU is detected/probed
> AFAICS.

There are named devices(platform devices) and/or PCI devices connected to SMMU.
However, ACS flags is only for PCI devices. So setting this flag in SMMU device init
maybe need check if there are PCIe devices connected to SMMU, as maybe devices connected
to SMMU are all named devices.

> 
> I agree that ACS enablement should be done before PCI enumeration,
> for other comments either you are questioning the current policy
> behind ACS enablement in the kernel - which can be a fair point - or
> I do not understand what you mean.
> 
> Let me know since I would like to queue this patch unless I hear
> a compelling objection to it.

I think this is not a big problem. If you want to queue this patch, you can add:

Tested-by: Zhou Wang <wangzhou1@hisilicon.com>

Thanks,
Zhou

> 
> Lorenzo
> 
> .
> 


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH] ACPI/IORT: Fix PCI ACS enablement
@ 2017-09-29  4:23           ` Zhou Wang
  0 siblings, 0 replies; 18+ messages in thread
From: Zhou Wang @ 2017-09-29  4:23 UTC (permalink / raw)
  To: linux-arm-kernel

On 2017/9/28 23:46, Lorenzo Pieralisi wrote:
> On Sat, Sep 23, 2017 at 10:26:29AM +0800, Zhou Wang wrote:
>> On 2017/9/22 17:45, Lorenzo Pieralisi wrote:
>>> On Thu, Sep 21, 2017 at 07:32:58PM +0800, Zhou Wang wrote:
>>>> On 2017/9/20 1:05, Lorenzo Pieralisi wrote:
>>>>> commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
>>>>> workarounds") removed kernel code that was allowing to initialize
>>>>> and probe the SMMU devices early (ie earlier than PCI devices through
>>>>> linker script callback entries) in the boot process because it was not
>>>>> needed any longer in that the SMMU devices/drivers now support deferred
>>>>> probing.
>>>>>
>>>>> Since the SMMUs probe routines are also in charge of requesting global
>>>>> PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
>>>>> up early-probing workarounds") also postponed PCI ACS enablement to
>>>>> SMMUs devices probe time, which may be too late given that PCI devices
>>>>> needs to detect if PCI ACS is enabled to init the respective capability
>>>>> through the following call path:
>>>>>
>>>>> pci_device_add()
>>>>>  -> pci_init_capabilities()
>>>>>   -> pci_enable_acs()
>>>>>
>>>>> Add code in the ACPI IORT SMMU platform devices initialization path
>>>>> (that is called before ACPI PCI enumeration) to detect if an SMMU is
>>>>> present in HW and enable PCI ACS if it actually is, restoring the
>>>>> correct PCI ACS enablement sequencing.
>>>>>
>>>>> Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
>>>>> Signed-workarounds")
>>>>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>>>>> Cc: Will Deacon <will.deacon@arm.com>
>>>>> Cc: Robin Murphy <robin.murphy@arm.com>
>>>>> Cc: Zhou Wang <wangzhou1@hisilicon.com>
>>>>> Cc: Alex Williamson <alex.williamson@redhat.com>
>>>>> ---
>>>>>  drivers/acpi/arm64/iort.c | 11 +++++++++++
>>>>>  1 file changed, 11 insertions(+)
>>>>>
>>>>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>>>>> index 9565d57..71a7694 100644
>>>>> --- a/drivers/acpi/arm64/iort.c
>>>>> +++ b/drivers/acpi/arm64/iort.c
>>>>> @@ -1184,6 +1184,7 @@ static void __init iort_init_platform_devices(void)
>>>>>  	struct acpi_table_iort *iort;
>>>>>  	struct fwnode_handle *fwnode;
>>>>>  	int i, ret;
>>>>> +	bool smmu_detected = false;
>>>>>  
>>>>>  	/*
>>>>>  	 * iort_table and iort both point to the start of IORT table, but
>>>>> @@ -1218,11 +1219,21 @@ static void __init iort_init_platform_devices(void)
>>>>>  				acpi_free_fwnode_static(fwnode);
>>>>>  				return;
>>>>>  			}
>>>>> +
>>>>> +			smmu_detected = true;
>>>>>  		}
>>>>>  
>>>>>  		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
>>>>>  					 iort_node->length);
>>>>>  	}
>>>>> +
>>>>> +	/*
>>>>> +	 * If IORT reports an SMMU component make sure PCI ACS is
>>>>> +	 * requested so that PCI devices can enable it in their
>>>>> +	 * capabilities.
>>>>> +	 */
>>>>> +	if (smmu_detected)
>>>>> +		pci_request_acs();
>>>>>  }
>>>>>  
>>>>>  void __init acpi_iort_init(void)
>>>>>
>>>>
>>>> Hi Lorenzo,
>>>>
>>>> I tested this patch, it works well in my HiSilicon Hip08 based system.
>>>> However, setting ACS flag at the stage of SMMU device init seems not good,
>>>> I mean what if in one system there are only platform devices connected to
>>>> SMMU device.
>>>
>>> That's a fair point if you explain to me how current pci_request_acs()
>>> usage copes with your remark above.
>>
>> The current pci_request_acs usage for ARM SMMU-V3 sets ACS flags under CONFIG_PCI.
>> However, as mentioned in your commit message, this setting is too late.
>>
>> For the usage of X86 and AMD, as I am not familiar with the devices used in these
>> two platforms, maybe the default devices in these platforms are PCIe based :)
> 
> I do not understand what your point is. ACS enablement is a global flag,
> that is currently set whenever an x86/AMD/ARM IOMMU is detected/probed
> AFAICS.

There are named devices(platform devices) and/or PCI devices connected to SMMU.
However, ACS flags is only for PCI devices. So setting this flag in SMMU device init
maybe need check if there are PCIe devices connected to SMMU, as maybe devices connected
to SMMU are all named devices.

> 
> I agree that ACS enablement should be done before PCI enumeration,
> for other comments either you are questioning the current policy
> behind ACS enablement in the kernel - which can be a fair point - or
> I do not understand what you mean.
> 
> Let me know since I would like to queue this patch unless I hear
> a compelling objection to it.

I think this is not a big problem. If you want to queue this patch, you can add:

Tested-by: Zhou Wang <wangzhou1@hisilicon.com>

Thanks,
Zhou

> 
> Lorenzo
> 
> .
> 

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] ACPI/IORT: Fix PCI ACS enablement
  2017-09-29  4:23           ` Zhou Wang
  (?)
@ 2017-09-29 16:08             ` Lorenzo Pieralisi
  -1 siblings, 0 replies; 18+ messages in thread
From: Lorenzo Pieralisi @ 2017-09-29 16:08 UTC (permalink / raw)
  To: Zhou Wang
  Cc: linux-pci, Will Deacon, linux-acpi, Alex Williamson,
	Robin Murphy, linux-arm-kernel

On Fri, Sep 29, 2017 at 12:23:18PM +0800, Zhou Wang wrote:
> On 2017/9/28 23:46, Lorenzo Pieralisi wrote:
> > On Sat, Sep 23, 2017 at 10:26:29AM +0800, Zhou Wang wrote:
> >> On 2017/9/22 17:45, Lorenzo Pieralisi wrote:
> >>> On Thu, Sep 21, 2017 at 07:32:58PM +0800, Zhou Wang wrote:
> >>>> On 2017/9/20 1:05, Lorenzo Pieralisi wrote:
> >>>>> commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> >>>>> workarounds") removed kernel code that was allowing to initialize
> >>>>> and probe the SMMU devices early (ie earlier than PCI devices through
> >>>>> linker script callback entries) in the boot process because it was not
> >>>>> needed any longer in that the SMMU devices/drivers now support deferred
> >>>>> probing.
> >>>>>
> >>>>> Since the SMMUs probe routines are also in charge of requesting global
> >>>>> PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
> >>>>> up early-probing workarounds") also postponed PCI ACS enablement to
> >>>>> SMMUs devices probe time, which may be too late given that PCI devices
> >>>>> needs to detect if PCI ACS is enabled to init the respective capability
> >>>>> through the following call path:
> >>>>>
> >>>>> pci_device_add()
> >>>>>  -> pci_init_capabilities()
> >>>>>   -> pci_enable_acs()
> >>>>>
> >>>>> Add code in the ACPI IORT SMMU platform devices initialization path
> >>>>> (that is called before ACPI PCI enumeration) to detect if an SMMU is
> >>>>> present in HW and enable PCI ACS if it actually is, restoring the
> >>>>> correct PCI ACS enablement sequencing.
> >>>>>
> >>>>> Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> >>>>> Signed-workarounds")
> >>>>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >>>>> Cc: Will Deacon <will.deacon@arm.com>
> >>>>> Cc: Robin Murphy <robin.murphy@arm.com>
> >>>>> Cc: Zhou Wang <wangzhou1@hisilicon.com>
> >>>>> Cc: Alex Williamson <alex.williamson@redhat.com>
> >>>>> ---
> >>>>>  drivers/acpi/arm64/iort.c | 11 +++++++++++
> >>>>>  1 file changed, 11 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> >>>>> index 9565d57..71a7694 100644
> >>>>> --- a/drivers/acpi/arm64/iort.c
> >>>>> +++ b/drivers/acpi/arm64/iort.c
> >>>>> @@ -1184,6 +1184,7 @@ static void __init iort_init_platform_devices(void)
> >>>>>  	struct acpi_table_iort *iort;
> >>>>>  	struct fwnode_handle *fwnode;
> >>>>>  	int i, ret;
> >>>>> +	bool smmu_detected = false;
> >>>>>  
> >>>>>  	/*
> >>>>>  	 * iort_table and iort both point to the start of IORT table, but
> >>>>> @@ -1218,11 +1219,21 @@ static void __init iort_init_platform_devices(void)
> >>>>>  				acpi_free_fwnode_static(fwnode);
> >>>>>  				return;
> >>>>>  			}
> >>>>> +
> >>>>> +			smmu_detected = true;
> >>>>>  		}
> >>>>>  
> >>>>>  		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
> >>>>>  					 iort_node->length);
> >>>>>  	}
> >>>>> +
> >>>>> +	/*
> >>>>> +	 * If IORT reports an SMMU component make sure PCI ACS is
> >>>>> +	 * requested so that PCI devices can enable it in their
> >>>>> +	 * capabilities.
> >>>>> +	 */
> >>>>> +	if (smmu_detected)
> >>>>> +		pci_request_acs();
> >>>>>  }
> >>>>>  
> >>>>>  void __init acpi_iort_init(void)
> >>>>>
> >>>>
> >>>> Hi Lorenzo,
> >>>>
> >>>> I tested this patch, it works well in my HiSilicon Hip08 based system.
> >>>> However, setting ACS flag at the stage of SMMU device init seems not good,
> >>>> I mean what if in one system there are only platform devices connected to
> >>>> SMMU device.
> >>>
> >>> That's a fair point if you explain to me how current pci_request_acs()
> >>> usage copes with your remark above.
> >>
> >> The current pci_request_acs usage for ARM SMMU-V3 sets ACS flags under CONFIG_PCI.
> >> However, as mentioned in your commit message, this setting is too late.
> >>
> >> For the usage of X86 and AMD, as I am not familiar with the devices used in these
> >> two platforms, maybe the default devices in these platforms are PCIe based :)
> > 
> > I do not understand what your point is. ACS enablement is a global flag,
> > that is currently set whenever an x86/AMD/ARM IOMMU is detected/probed
> > AFAICS.
> 
> There are named devices(platform devices) and/or PCI devices connected to SMMU.
> However, ACS flags is only for PCI devices. So setting this flag in SMMU device init
> maybe need check if there are PCIe devices connected to SMMU, as maybe devices connected
> to SMMU are all named devices.

Understood but that's a problem that exists in the current kernel,
what I am saying is that's not what I am fixing with this patch.

Lorenzo

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] ACPI/IORT: Fix PCI ACS enablement
@ 2017-09-29 16:08             ` Lorenzo Pieralisi
  0 siblings, 0 replies; 18+ messages in thread
From: Lorenzo Pieralisi @ 2017-09-29 16:08 UTC (permalink / raw)
  To: Zhou Wang
  Cc: linux-pci, Will Deacon, linux-acpi, Alex Williamson,
	Robin Murphy, linux-arm-kernel

On Fri, Sep 29, 2017 at 12:23:18PM +0800, Zhou Wang wrote:
> On 2017/9/28 23:46, Lorenzo Pieralisi wrote:
> > On Sat, Sep 23, 2017 at 10:26:29AM +0800, Zhou Wang wrote:
> >> On 2017/9/22 17:45, Lorenzo Pieralisi wrote:
> >>> On Thu, Sep 21, 2017 at 07:32:58PM +0800, Zhou Wang wrote:
> >>>> On 2017/9/20 1:05, Lorenzo Pieralisi wrote:
> >>>>> commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> >>>>> workarounds") removed kernel code that was allowing to initialize
> >>>>> and probe the SMMU devices early (ie earlier than PCI devices through
> >>>>> linker script callback entries) in the boot process because it was not
> >>>>> needed any longer in that the SMMU devices/drivers now support deferred
> >>>>> probing.
> >>>>>
> >>>>> Since the SMMUs probe routines are also in charge of requesting global
> >>>>> PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
> >>>>> up early-probing workarounds") also postponed PCI ACS enablement to
> >>>>> SMMUs devices probe time, which may be too late given that PCI devices
> >>>>> needs to detect if PCI ACS is enabled to init the respective capability
> >>>>> through the following call path:
> >>>>>
> >>>>> pci_device_add()
> >>>>>  -> pci_init_capabilities()
> >>>>>   -> pci_enable_acs()
> >>>>>
> >>>>> Add code in the ACPI IORT SMMU platform devices initialization path
> >>>>> (that is called before ACPI PCI enumeration) to detect if an SMMU is
> >>>>> present in HW and enable PCI ACS if it actually is, restoring the
> >>>>> correct PCI ACS enablement sequencing.
> >>>>>
> >>>>> Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> >>>>> Signed-workarounds")
> >>>>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >>>>> Cc: Will Deacon <will.deacon@arm.com>
> >>>>> Cc: Robin Murphy <robin.murphy@arm.com>
> >>>>> Cc: Zhou Wang <wangzhou1@hisilicon.com>
> >>>>> Cc: Alex Williamson <alex.williamson@redhat.com>
> >>>>> ---
> >>>>>  drivers/acpi/arm64/iort.c | 11 +++++++++++
> >>>>>  1 file changed, 11 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> >>>>> index 9565d57..71a7694 100644
> >>>>> --- a/drivers/acpi/arm64/iort.c
> >>>>> +++ b/drivers/acpi/arm64/iort.c
> >>>>> @@ -1184,6 +1184,7 @@ static void __init iort_init_platform_devices(void)
> >>>>>  	struct acpi_table_iort *iort;
> >>>>>  	struct fwnode_handle *fwnode;
> >>>>>  	int i, ret;
> >>>>> +	bool smmu_detected = false;
> >>>>>  
> >>>>>  	/*
> >>>>>  	 * iort_table and iort both point to the start of IORT table, but
> >>>>> @@ -1218,11 +1219,21 @@ static void __init iort_init_platform_devices(void)
> >>>>>  				acpi_free_fwnode_static(fwnode);
> >>>>>  				return;
> >>>>>  			}
> >>>>> +
> >>>>> +			smmu_detected = true;
> >>>>>  		}
> >>>>>  
> >>>>>  		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
> >>>>>  					 iort_node->length);
> >>>>>  	}
> >>>>> +
> >>>>> +	/*
> >>>>> +	 * If IORT reports an SMMU component make sure PCI ACS is
> >>>>> +	 * requested so that PCI devices can enable it in their
> >>>>> +	 * capabilities.
> >>>>> +	 */
> >>>>> +	if (smmu_detected)
> >>>>> +		pci_request_acs();
> >>>>>  }
> >>>>>  
> >>>>>  void __init acpi_iort_init(void)
> >>>>>
> >>>>
> >>>> Hi Lorenzo,
> >>>>
> >>>> I tested this patch, it works well in my HiSilicon Hip08 based system.
> >>>> However, setting ACS flag at the stage of SMMU device init seems not good,
> >>>> I mean what if in one system there are only platform devices connected to
> >>>> SMMU device.
> >>>
> >>> That's a fair point if you explain to me how current pci_request_acs()
> >>> usage copes with your remark above.
> >>
> >> The current pci_request_acs usage for ARM SMMU-V3 sets ACS flags under CONFIG_PCI.
> >> However, as mentioned in your commit message, this setting is too late.
> >>
> >> For the usage of X86 and AMD, as I am not familiar with the devices used in these
> >> two platforms, maybe the default devices in these platforms are PCIe based :)
> > 
> > I do not understand what your point is. ACS enablement is a global flag,
> > that is currently set whenever an x86/AMD/ARM IOMMU is detected/probed
> > AFAICS.
> 
> There are named devices(platform devices) and/or PCI devices connected to SMMU.
> However, ACS flags is only for PCI devices. So setting this flag in SMMU device init
> maybe need check if there are PCIe devices connected to SMMU, as maybe devices connected
> to SMMU are all named devices.

Understood but that's a problem that exists in the current kernel,
what I am saying is that's not what I am fixing with this patch.

Lorenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH] ACPI/IORT: Fix PCI ACS enablement
@ 2017-09-29 16:08             ` Lorenzo Pieralisi
  0 siblings, 0 replies; 18+ messages in thread
From: Lorenzo Pieralisi @ 2017-09-29 16:08 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Sep 29, 2017 at 12:23:18PM +0800, Zhou Wang wrote:
> On 2017/9/28 23:46, Lorenzo Pieralisi wrote:
> > On Sat, Sep 23, 2017 at 10:26:29AM +0800, Zhou Wang wrote:
> >> On 2017/9/22 17:45, Lorenzo Pieralisi wrote:
> >>> On Thu, Sep 21, 2017 at 07:32:58PM +0800, Zhou Wang wrote:
> >>>> On 2017/9/20 1:05, Lorenzo Pieralisi wrote:
> >>>>> commit f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> >>>>> workarounds") removed kernel code that was allowing to initialize
> >>>>> and probe the SMMU devices early (ie earlier than PCI devices through
> >>>>> linker script callback entries) in the boot process because it was not
> >>>>> needed any longer in that the SMMU devices/drivers now support deferred
> >>>>> probing.
> >>>>>
> >>>>> Since the SMMUs probe routines are also in charge of requesting global
> >>>>> PCI ACS kernel enablement, commit f6810c15cf97 ("iommu/arm-smmu: Clean
> >>>>> up early-probing workarounds") also postponed PCI ACS enablement to
> >>>>> SMMUs devices probe time, which may be too late given that PCI devices
> >>>>> needs to detect if PCI ACS is enabled to init the respective capability
> >>>>> through the following call path:
> >>>>>
> >>>>> pci_device_add()
> >>>>>  -> pci_init_capabilities()
> >>>>>   -> pci_enable_acs()
> >>>>>
> >>>>> Add code in the ACPI IORT SMMU platform devices initialization path
> >>>>> (that is called before ACPI PCI enumeration) to detect if an SMMU is
> >>>>> present in HW and enable PCI ACS if it actually is, restoring the
> >>>>> correct PCI ACS enablement sequencing.
> >>>>>
> >>>>> Fixes: f6810c15cf97 ("iommu/arm-smmu: Clean up early-probing
> >>>>> Signed-workarounds")
> >>>>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >>>>> Cc: Will Deacon <will.deacon@arm.com>
> >>>>> Cc: Robin Murphy <robin.murphy@arm.com>
> >>>>> Cc: Zhou Wang <wangzhou1@hisilicon.com>
> >>>>> Cc: Alex Williamson <alex.williamson@redhat.com>
> >>>>> ---
> >>>>>  drivers/acpi/arm64/iort.c | 11 +++++++++++
> >>>>>  1 file changed, 11 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> >>>>> index 9565d57..71a7694 100644
> >>>>> --- a/drivers/acpi/arm64/iort.c
> >>>>> +++ b/drivers/acpi/arm64/iort.c
> >>>>> @@ -1184,6 +1184,7 @@ static void __init iort_init_platform_devices(void)
> >>>>>  	struct acpi_table_iort *iort;
> >>>>>  	struct fwnode_handle *fwnode;
> >>>>>  	int i, ret;
> >>>>> +	bool smmu_detected = false;
> >>>>>  
> >>>>>  	/*
> >>>>>  	 * iort_table and iort both point to the start of IORT table, but
> >>>>> @@ -1218,11 +1219,21 @@ static void __init iort_init_platform_devices(void)
> >>>>>  				acpi_free_fwnode_static(fwnode);
> >>>>>  				return;
> >>>>>  			}
> >>>>> +
> >>>>> +			smmu_detected = true;
> >>>>>  		}
> >>>>>  
> >>>>>  		iort_node = ACPI_ADD_PTR(struct acpi_iort_node, iort_node,
> >>>>>  					 iort_node->length);
> >>>>>  	}
> >>>>> +
> >>>>> +	/*
> >>>>> +	 * If IORT reports an SMMU component make sure PCI ACS is
> >>>>> +	 * requested so that PCI devices can enable it in their
> >>>>> +	 * capabilities.
> >>>>> +	 */
> >>>>> +	if (smmu_detected)
> >>>>> +		pci_request_acs();
> >>>>>  }
> >>>>>  
> >>>>>  void __init acpi_iort_init(void)
> >>>>>
> >>>>
> >>>> Hi Lorenzo,
> >>>>
> >>>> I tested this patch, it works well in my HiSilicon Hip08 based system.
> >>>> However, setting ACS flag at the stage of SMMU device init seems not good,
> >>>> I mean what if in one system there are only platform devices connected to
> >>>> SMMU device.
> >>>
> >>> That's a fair point if you explain to me how current pci_request_acs()
> >>> usage copes with your remark above.
> >>
> >> The current pci_request_acs usage for ARM SMMU-V3 sets ACS flags under CONFIG_PCI.
> >> However, as mentioned in your commit message, this setting is too late.
> >>
> >> For the usage of X86 and AMD, as I am not familiar with the devices used in these
> >> two platforms, maybe the default devices in these platforms are PCIe based :)
> > 
> > I do not understand what your point is. ACS enablement is a global flag,
> > that is currently set whenever an x86/AMD/ARM IOMMU is detected/probed
> > AFAICS.
> 
> There are named devices(platform devices) and/or PCI devices connected to SMMU.
> However, ACS flags is only for PCI devices. So setting this flag in SMMU device init
> maybe need check if there are PCIe devices connected to SMMU, as maybe devices connected
> to SMMU are all named devices.

Understood but that's a problem that exists in the current kernel,
what I am saying is that's not what I am fixing with this patch.

Lorenzo

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2017-09-29 16:08 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-19 17:05 [PATCH] ACPI/IORT: Fix PCI ACS enablement Lorenzo Pieralisi
2017-09-19 17:05 ` Lorenzo Pieralisi
2017-09-21 11:32 ` Zhou Wang
2017-09-21 11:32   ` Zhou Wang
2017-09-21 11:32   ` Zhou Wang
2017-09-22  9:45   ` Lorenzo Pieralisi
2017-09-22  9:45     ` Lorenzo Pieralisi
2017-09-23  2:26     ` Zhou Wang
2017-09-23  2:26       ` Zhou Wang
2017-09-23  2:26       ` Zhou Wang
2017-09-28 15:46       ` Lorenzo Pieralisi
2017-09-28 15:46         ` Lorenzo Pieralisi
2017-09-29  4:23         ` Zhou Wang
2017-09-29  4:23           ` Zhou Wang
2017-09-29  4:23           ` Zhou Wang
2017-09-29 16:08           ` Lorenzo Pieralisi
2017-09-29 16:08             ` Lorenzo Pieralisi
2017-09-29 16:08             ` Lorenzo Pieralisi

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.