[PATCH] PCI: controller: Move PCI_DOMAINS selection to arch Kconfig

[Lorenzo Pieralisi]

Commit 51bc085d6454 ("PCI: Improve host drivers compile test coverage")
added configuration options to allow PCI host controller drivers to be
compile tested on all architectures.

Some host controller drivers (eg PCIE_ALTERA) config entries select
the PCI_DOMAINS config option to enable PCI domains management in
the kernel. Now that host controller drivers can be compiled on
all architectures, this triggers build regressions on arches that
do not implement the PCI_DOMAINS required API (ie pci_domain_nr()):

drivers/ata/pata_ali.c: In function 'ali_init_chipset':
drivers/ata/pata_ali.c:469:38: error:
implicit declaration of function 'pci_domain_nr';
  did you mean 'pci_iomap_wc'?

The PCI_DOMAINS config option is meant to be selected by the arch
configuration since it is an arch rather a than host controller option.

Move the PCI_DOMAINS selection to the sub-arch Kconfig entries,
therefore fixing the build regression.

Fixes: 51bc085d6454 ("PCI: Improve host drivers compile test coverage")
Link: https://lkml.kernel.org/r/20180612170229.ga10...@roeck-us.net
Reported-by: Guenter Roeck 
Signed-off-by: Lorenzo Pieralisi 
Cc: Scott Branden 
Cc: Will Deacon 
Cc: Rob Herring 
Cc: Bjorn Helgaas 
Cc: Russell King 
Cc: Jan Kiszka 
Cc: Guenter Roeck 
Cc: Ley Foon Tan 
---
 arch/arm/Kconfig   | 1 +
 arch/arm/mach-bcm/Kconfig  | 1 +
 arch/arm/mach-socfpga/Kconfig  | 1 +
 drivers/pci/controller/Kconfig | 3 ---
 4 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 54eeb8d00bc6..7f1633dd9e07 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -701,6 +701,7 @@ config ARCH_VIRT
select ARM_GIC_V3_ITS if PCI
select ARM_PSCI
select HAVE_ARM_ARCH_TIMER
+   select PCI_DOMAINS if PCI
 
 #
 # This is sorted alphabetically by mach-* pathname.  However, plat-*
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index c46a728df44e..25aac6ee2ab1 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -20,6 +20,7 @@ config ARCH_BCM_IPROC
select GPIOLIB
select ARM_AMBA
select PINCTRL
+   select PCI_DOMAINS if PCI
help
  This enables support for systems based on Broadcom IPROC architected 
SoCs.
  The IPROC complex contains one or more ARM CPUs along with common
diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index d0f62eacf59d..4adb901dd5eb 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -10,6 +10,7 @@ menuconfig ARCH_SOCFPGA
select HAVE_ARM_SCU
select HAVE_ARM_TWD if SMP
select MFD_SYSCON
+   select PCI_DOMAINS if PCI
 
 if ARCH_SOCFPGA
 config SOCFPGA_SUSPEND
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 18fa09b3ac8f..cc9fa02d32a0 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -96,7 +96,6 @@ config PCI_HOST_GENERIC
depends on OF
select PCI_HOST_COMMON
select IRQ_DOMAIN
-   select PCI_DOMAINS
help
  Say Y here if you want to support a simple generic PCI host
  controller, such as the one emulated by kvmtool.
@@ -138,7 +137,6 @@ config PCI_VERSATILE
 
 config PCIE_IPROC
tristate
-   select PCI_DOMAINS
help
  This enables the iProc PCIe core controller support for Broadcom's
  iProc family of SoCs. An appropriate bus interface driver needs
@@ -176,7 +174,6 @@ config PCIE_IPROC_MSI
 config PCIE_ALTERA
bool "Altera PCIe controller"
depends on ARM || NIOS2 || COMPILE_TEST
-   select PCI_DOMAINS
help
  Say Y here if you want to enable PCIe controller support on Altera
  FPGA.
-- 
2.15.0

[PATCH] PCI: controller: Move PCI_DOMAINS selection to arch Kconfig

[Lorenzo Pieralisi]

Commit 51bc085d6454 ("PCI: Improve host drivers compile test coverage")
added configuration options to allow PCI host controller drivers to be
compile tested on all architectures.

Some host controller drivers (eg PCIE_ALTERA) config entries select
the PCI_DOMAINS config option to enable PCI domains management in
the kernel. Now that host controller drivers can be compiled on
all architectures, this triggers build regressions on arches that
do not implement the PCI_DOMAINS required API (ie pci_domain_nr()):

drivers/ata/pata_ali.c: In function 'ali_init_chipset':
drivers/ata/pata_ali.c:469:38: error:
implicit declaration of function 'pci_domain_nr';
  did you mean 'pci_iomap_wc'?

The PCI_DOMAINS config option is meant to be selected by the arch
configuration since it is an arch rather a than host controller option.

Move the PCI_DOMAINS selection to the sub-arch Kconfig entries,
therefore fixing the build regression.

Fixes: 51bc085d6454 ("PCI: Improve host drivers compile test coverage")
Link: https://lkml.kernel.org/r/20180612170229.ga10...@roeck-us.net
Reported-by: Guenter Roeck 
Signed-off-by: Lorenzo Pieralisi 
Cc: Scott Branden 
Cc: Will Deacon 
Cc: Rob Herring 
Cc: Bjorn Helgaas 
Cc: Russell King 
Cc: Jan Kiszka 
Cc: Guenter Roeck 
Cc: Ley Foon Tan 
---
 arch/arm/Kconfig   | 1 +
 arch/arm/mach-bcm/Kconfig  | 1 +
 arch/arm/mach-socfpga/Kconfig  | 1 +
 drivers/pci/controller/Kconfig | 3 ---
 4 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 54eeb8d00bc6..7f1633dd9e07 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -701,6 +701,7 @@ config ARCH_VIRT
select ARM_GIC_V3_ITS if PCI
select ARM_PSCI
select HAVE_ARM_ARCH_TIMER
+   select PCI_DOMAINS if PCI
 
 #
 # This is sorted alphabetically by mach-* pathname.  However, plat-*
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index c46a728df44e..25aac6ee2ab1 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -20,6 +20,7 @@ config ARCH_BCM_IPROC
select GPIOLIB
select ARM_AMBA
select PINCTRL
+   select PCI_DOMAINS if PCI
help
  This enables support for systems based on Broadcom IPROC architected 
SoCs.
  The IPROC complex contains one or more ARM CPUs along with common
diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index d0f62eacf59d..4adb901dd5eb 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -10,6 +10,7 @@ menuconfig ARCH_SOCFPGA
select HAVE_ARM_SCU
select HAVE_ARM_TWD if SMP
select MFD_SYSCON
+   select PCI_DOMAINS if PCI
 
 if ARCH_SOCFPGA
 config SOCFPGA_SUSPEND
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 18fa09b3ac8f..cc9fa02d32a0 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -96,7 +96,6 @@ config PCI_HOST_GENERIC
depends on OF
select PCI_HOST_COMMON
select IRQ_DOMAIN
-   select PCI_DOMAINS
help
  Say Y here if you want to support a simple generic PCI host
  controller, such as the one emulated by kvmtool.
@@ -138,7 +137,6 @@ config PCI_VERSATILE
 
 config PCIE_IPROC
tristate
-   select PCI_DOMAINS
help
  This enables the iProc PCIe core controller support for Broadcom's
  iProc family of SoCs. An appropriate bus interface driver needs
@@ -176,7 +174,6 @@ config PCIE_IPROC_MSI
 config PCIE_ALTERA
bool "Altera PCIe controller"
depends on ARM || NIOS2 || COMPILE_TEST
-   select PCI_DOMAINS
help
  Say Y here if you want to enable PCIe controller support on Altera
  FPGA.
-- 
2.15.0

Re: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared

[Lorenzo Pieralisi]

On Wed, May 23, 2018 at 09:12:01PM +, Dexuan Cui wrote:
> 
> Before the guest finishes the device initialization, the device can be
> removed anytime by the host, and after that the host won't respond to
> the guest's request, so the guest should be prepared to handle this
> case.
> 
> Signed-off-by: Dexuan Cui 
> Cc: Stephen Hemminger 
> Cc: K. Y. Srinivasan 
> ---
>  drivers/pci/host/pci-hyperv.c | 46 
> ---
>  1 file changed, 34 insertions(+), 12 deletions(-)

Applied with a minor tweak to the commit log to pci/hv for v4.18.

Thanks,
Lorenzo

> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index ad6a64d..248765f 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -556,6 +556,26 @@ static void put_pcichild(struct hv_pci_dev *hv_pcidev,
>  static void get_hvpcibus(struct hv_pcibus_device *hv_pcibus);
>  static void put_hvpcibus(struct hv_pcibus_device *hv_pcibus);
>  
> +/*
> + * There is no good way to get notified from vmbus_onoffer_rescind(),
> + * so let's use polling here, since this is not a hot path.
> + */
> +static int wait_for_response(struct hv_device *hdev,
> +  struct completion *comp)
> +{
> + while (true) {
> + if (hdev->channel->rescind) {
> + dev_warn_once(>device, "The device is gone.\n");
> + return -ENODEV;
> + }
> +
> + if (wait_for_completion_timeout(comp, HZ / 10))
> + break;
> + }
> +
> + return 0;
> +}
> +
>  /**
>   * devfn_to_wslot() - Convert from Linux PCI slot to Windows
>   * @devfn:   The Linux representation of PCI slot
> @@ -1569,7 +1589,8 @@ static struct hv_pci_dev *new_pcichild_device(struct 
> hv_pcibus_device *hbus,
>   if (ret)
>   goto error;
>  
> - wait_for_completion(_pkt.host_event);
> + if (wait_for_response(hbus->hdev, _pkt.host_event))
> + goto error;
>  
>   hpdev->desc = *desc;
>   refcount_set(>refs, 1);
> @@ -2070,15 +2091,16 @@ static int hv_pci_protocol_negotiation(struct 
> hv_device *hdev)
>   sizeof(struct pci_version_request),
>   (unsigned long)pkt, VM_PKT_DATA_INBAND,
>   VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> + if (!ret)
> + ret = wait_for_response(hdev, _pkt.host_event);
> +
>   if (ret) {
>   dev_err(>device,
> - "PCI Pass-through VSP failed sending version 
> reqquest: %#x",
> + "PCI Pass-through VSP failed to request 
> version: %d",
>   ret);
>   goto exit;
>   }
>  
> - wait_for_completion(_pkt.host_event);
> -
>   if (comp_pkt.completion_status >= 0) {
>   pci_protocol_version = pci_protocol_versions[i];
>   dev_info(>device,
> @@ -2287,11 +2309,12 @@ static int hv_pci_enter_d0(struct hv_device *hdev)
>   ret = vmbus_sendpacket(hdev->channel, d0_entry, sizeof(*d0_entry),
>  (unsigned long)pkt, VM_PKT_DATA_INBAND,
>  VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> + if (!ret)
> + ret = wait_for_response(hdev, _pkt.host_event);
> +
>   if (ret)
>   goto exit;
>  
> - wait_for_completion(_pkt.host_event);
> -
>   if (comp_pkt.completion_status < 0) {
>   dev_err(>device,
>   "PCI Pass-through VSP failed D0 Entry with status %x\n",
> @@ -2331,11 +2354,10 @@ static int hv_pci_query_relations(struct hv_device 
> *hdev)
>  
>   ret = vmbus_sendpacket(hdev->channel, , sizeof(message),
>  0, VM_PKT_DATA_INBAND, 0);
> - if (ret)
> - return ret;
> + if (!ret)
> + ret = wait_for_response(hdev, );
>  
> - wait_for_completion();
> - return 0;
> + return ret;
>  }
>  
>  /**
> @@ -2405,11 +2427,11 @@ static int hv_send_resources_allocated(struct 
> hv_device *hdev)
>   size_res, (unsigned long)pkt,
>   VM_PKT_DATA_INBAND,
>   VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> + if (!ret)
> + ret = wait_for_response(hdev, _pkt.host_event);
>   if (ret)
>   break;
>  
> - wait_for_completion(_pkt.host_event);
> -
>   if (comp_pkt.completion_status < 0) {
>   ret = -EPROTO;
>   dev_err(>device,
> -- 
> 2.7.4
> 

Re: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared

[Lorenzo Pieralisi]

On Wed, May 23, 2018 at 09:12:01PM +, Dexuan Cui wrote:
> 
> Before the guest finishes the device initialization, the device can be
> removed anytime by the host, and after that the host won't respond to
> the guest's request, so the guest should be prepared to handle this
> case.
> 
> Signed-off-by: Dexuan Cui 
> Cc: Stephen Hemminger 
> Cc: K. Y. Srinivasan 
> ---
>  drivers/pci/host/pci-hyperv.c | 46 
> ---
>  1 file changed, 34 insertions(+), 12 deletions(-)

Applied with a minor tweak to the commit log to pci/hv for v4.18.

Thanks,
Lorenzo

> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index ad6a64d..248765f 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -556,6 +556,26 @@ static void put_pcichild(struct hv_pci_dev *hv_pcidev,
>  static void get_hvpcibus(struct hv_pcibus_device *hv_pcibus);
>  static void put_hvpcibus(struct hv_pcibus_device *hv_pcibus);
>  
> +/*
> + * There is no good way to get notified from vmbus_onoffer_rescind(),
> + * so let's use polling here, since this is not a hot path.
> + */
> +static int wait_for_response(struct hv_device *hdev,
> +  struct completion *comp)
> +{
> + while (true) {
> + if (hdev->channel->rescind) {
> + dev_warn_once(>device, "The device is gone.\n");
> + return -ENODEV;
> + }
> +
> + if (wait_for_completion_timeout(comp, HZ / 10))
> + break;
> + }
> +
> + return 0;
> +}
> +
>  /**
>   * devfn_to_wslot() - Convert from Linux PCI slot to Windows
>   * @devfn:   The Linux representation of PCI slot
> @@ -1569,7 +1589,8 @@ static struct hv_pci_dev *new_pcichild_device(struct 
> hv_pcibus_device *hbus,
>   if (ret)
>   goto error;
>  
> - wait_for_completion(_pkt.host_event);
> + if (wait_for_response(hbus->hdev, _pkt.host_event))
> + goto error;
>  
>   hpdev->desc = *desc;
>   refcount_set(>refs, 1);
> @@ -2070,15 +2091,16 @@ static int hv_pci_protocol_negotiation(struct 
> hv_device *hdev)
>   sizeof(struct pci_version_request),
>   (unsigned long)pkt, VM_PKT_DATA_INBAND,
>   VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> + if (!ret)
> + ret = wait_for_response(hdev, _pkt.host_event);
> +
>   if (ret) {
>   dev_err(>device,
> - "PCI Pass-through VSP failed sending version 
> reqquest: %#x",
> + "PCI Pass-through VSP failed to request 
> version: %d",
>   ret);
>   goto exit;
>   }
>  
> - wait_for_completion(_pkt.host_event);
> -
>   if (comp_pkt.completion_status >= 0) {
>   pci_protocol_version = pci_protocol_versions[i];
>   dev_info(>device,
> @@ -2287,11 +2309,12 @@ static int hv_pci_enter_d0(struct hv_device *hdev)
>   ret = vmbus_sendpacket(hdev->channel, d0_entry, sizeof(*d0_entry),
>  (unsigned long)pkt, VM_PKT_DATA_INBAND,
>  VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> + if (!ret)
> + ret = wait_for_response(hdev, _pkt.host_event);
> +
>   if (ret)
>   goto exit;
>  
> - wait_for_completion(_pkt.host_event);
> -
>   if (comp_pkt.completion_status < 0) {
>   dev_err(>device,
>   "PCI Pass-through VSP failed D0 Entry with status %x\n",
> @@ -2331,11 +2354,10 @@ static int hv_pci_query_relations(struct hv_device 
> *hdev)
>  
>   ret = vmbus_sendpacket(hdev->channel, , sizeof(message),
>  0, VM_PKT_DATA_INBAND, 0);
> - if (ret)
> - return ret;
> + if (!ret)
> + ret = wait_for_response(hdev, );
>  
> - wait_for_completion();
> - return 0;
> + return ret;
>  }
>  
>  /**
> @@ -2405,11 +2427,11 @@ static int hv_send_resources_allocated(struct 
> hv_device *hdev)
>   size_res, (unsigned long)pkt,
>   VM_PKT_DATA_INBAND,
>   VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> + if (!ret)
> + ret = wait_for_response(hdev, _pkt.host_event);
>   if (ret)
>   break;
>  
> - wait_for_completion(_pkt.host_event);
> -
>   if (comp_pkt.completion_status < 0) {
>   ret = -EPROTO;
>   dev_err(>device,
> -- 
> 2.7.4
> 

Re: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared

[Lorenzo Pieralisi]

On Thu, May 24, 2018 at 11:55:35PM +, Dexuan Cui wrote:
> > From: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
> > Sent: Thursday, May 24, 2018 05:41
> > On Wed, May 23, 2018 at 09:12:01PM +, Dexuan Cui wrote:
> > >
> > > Before the guest finishes the device initialization, the device can be
> > > removed anytime by the host, and after that the host won't respond to
> > > the guest's request, so the guest should be prepared to handle this
> > > case.
> > >
> > > --- a/drivers/pci/host/pci-hyperv.c
> > > +++ b/drivers/pci/host/pci-hyperv.c
> > > @@ -556,6 +556,26 @@ static void put_pcichild(struct hv_pci_dev
> > *hv_pcidev,
> > >  static void get_hvpcibus(struct hv_pcibus_device *hv_pcibus);
> > >  static void put_hvpcibus(struct hv_pcibus_device *hv_pcibus);
> > >
> > > +/*
> > > + * There is no good way to get notified from vmbus_onoffer_rescind(),
> > > + * so let's use polling here, since this is not a hot path.
> > > + */
> > > +static int wait_for_response(struct hv_device *hdev,
> > > +  struct completion *comp)
> > > +{
> > > + while (true) {
> > > + if (hdev->channel->rescind) {
> > > + dev_warn_once(>device, "The device is gone.\n");
> > > + return -ENODEV;
> > > + }
> > > +
> > > + if (wait_for_completion_timeout(comp, HZ / 10))
> > > + break;
> > > + }
> > > +
> > > + return 0;
> > 
> > This is pretty racy, isn't it ? Also, I reckon you should consider the
> > timeout return value as an error condition unless I am completely
> > missing the point of what you are doing.
> > 
> > Lorenzo
> 
> Actually, this is not racy: we only exit the loop when 
> 1) the channel is rescinded 
> or
> 2) the channel is not rescinded, and the event is completed.
> 
> wait_for_completion_timeout() returns 0 if timed out: in this case,
> we keep spinning in the loop every 0.1 second, testing the 2 conditions.

Yes sorry, you are right, the exit condition is correct, I am waiting for
maintainers ACK to merge it, I need it as soon as possible if you want
this to make it for v4.18.

Thanks,
Lorenzo

> If the chanel is not rescinded, here we should wait for the event 
> forever, as the host is supposed to respond to us quickly, and the
> event will be completed accordingly. This is what the current code
> does. But, in case the channel is rescinded, we need to exit the loop 
> immediately with an error return value: this is the only change
> made by the patch.
> 
> Ideally, we should not use this ugly "polling" method, and the
> rescind-handler, i.e. vmbus_onoffer_rescind(), should notify 
> wait_for_response(), but as I mentioned, there is no good way
> to get notified from vmbus_onoffer_rescind(), so I'm proposing
> this "polling" method: it's simple and it can work correctly,
> and this is not a hot path.
> 
> Thanks,
> -- Dexuan

Re: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared

[Lorenzo Pieralisi]

On Thu, May 24, 2018 at 11:55:35PM +, Dexuan Cui wrote:
> > From: Lorenzo Pieralisi 
> > Sent: Thursday, May 24, 2018 05:41
> > On Wed, May 23, 2018 at 09:12:01PM +, Dexuan Cui wrote:
> > >
> > > Before the guest finishes the device initialization, the device can be
> > > removed anytime by the host, and after that the host won't respond to
> > > the guest's request, so the guest should be prepared to handle this
> > > case.
> > >
> > > --- a/drivers/pci/host/pci-hyperv.c
> > > +++ b/drivers/pci/host/pci-hyperv.c
> > > @@ -556,6 +556,26 @@ static void put_pcichild(struct hv_pci_dev
> > *hv_pcidev,
> > >  static void get_hvpcibus(struct hv_pcibus_device *hv_pcibus);
> > >  static void put_hvpcibus(struct hv_pcibus_device *hv_pcibus);
> > >
> > > +/*
> > > + * There is no good way to get notified from vmbus_onoffer_rescind(),
> > > + * so let's use polling here, since this is not a hot path.
> > > + */
> > > +static int wait_for_response(struct hv_device *hdev,
> > > +  struct completion *comp)
> > > +{
> > > + while (true) {
> > > + if (hdev->channel->rescind) {
> > > + dev_warn_once(>device, "The device is gone.\n");
> > > + return -ENODEV;
> > > + }
> > > +
> > > + if (wait_for_completion_timeout(comp, HZ / 10))
> > > + break;
> > > + }
> > > +
> > > + return 0;
> > 
> > This is pretty racy, isn't it ? Also, I reckon you should consider the
> > timeout return value as an error condition unless I am completely
> > missing the point of what you are doing.
> > 
> > Lorenzo
> 
> Actually, this is not racy: we only exit the loop when 
> 1) the channel is rescinded 
> or
> 2) the channel is not rescinded, and the event is completed.
> 
> wait_for_completion_timeout() returns 0 if timed out: in this case,
> we keep spinning in the loop every 0.1 second, testing the 2 conditions.

Yes sorry, you are right, the exit condition is correct, I am waiting for
maintainers ACK to merge it, I need it as soon as possible if you want
this to make it for v4.18.

Thanks,
Lorenzo

> If the chanel is not rescinded, here we should wait for the event 
> forever, as the host is supposed to respond to us quickly, and the
> event will be completed accordingly. This is what the current code
> does. But, in case the channel is rescinded, we need to exit the loop 
> immediately with an error return value: this is the only change
> made by the patch.
> 
> Ideally, we should not use this ugly "polling" method, and the
> rescind-handler, i.e. vmbus_onoffer_rescind(), should notify 
> wait_for_response(), but as I mentioned, there is no good way
> to get notified from vmbus_onoffer_rescind(), so I'm proposing
> this "polling" method: it's simple and it can work correctly,
> and this is not a hot path.
> 
> Thanks,
> -- Dexuan

Re: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared

[Lorenzo Pieralisi]

On Wed, May 23, 2018 at 09:12:01PM +, Dexuan Cui wrote:
> 
> Before the guest finishes the device initialization, the device can be
> removed anytime by the host, and after that the host won't respond to
> the guest's request, so the guest should be prepared to handle this
> case.
> 
> Signed-off-by: Dexuan Cui 
> Cc: Stephen Hemminger 
> Cc: K. Y. Srinivasan 
> ---
>  drivers/pci/host/pci-hyperv.c | 46 
> ---
>  1 file changed, 34 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index ad6a64d..248765f 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -556,6 +556,26 @@ static void put_pcichild(struct hv_pci_dev *hv_pcidev,
>  static void get_hvpcibus(struct hv_pcibus_device *hv_pcibus);
>  static void put_hvpcibus(struct hv_pcibus_device *hv_pcibus);
>  
> +/*
> + * There is no good way to get notified from vmbus_onoffer_rescind(),
> + * so let's use polling here, since this is not a hot path.
> + */
> +static int wait_for_response(struct hv_device *hdev,
> +  struct completion *comp)
> +{
> + while (true) {
> + if (hdev->channel->rescind) {
> + dev_warn_once(>device, "The device is gone.\n");
> + return -ENODEV;
> + }
> +
> + if (wait_for_completion_timeout(comp, HZ / 10))
> + break;
> + }
> +
> + return 0;

This is pretty racy, isn't it ? Also, I reckon you should consider the
timeout return value as an error condition unless I am completely
missing the point of what you are doing.

Lorenzo

> +}
> +
>  /**
>   * devfn_to_wslot() - Convert from Linux PCI slot to Windows
>   * @devfn:   The Linux representation of PCI slot
> @@ -1569,7 +1589,8 @@ static struct hv_pci_dev *new_pcichild_device(struct 
> hv_pcibus_device *hbus,
>   if (ret)
>   goto error;
>  
> - wait_for_completion(_pkt.host_event);
> + if (wait_for_response(hbus->hdev, _pkt.host_event))
> + goto error;
>  
>   hpdev->desc = *desc;
>   refcount_set(>refs, 1);
> @@ -2070,15 +2091,16 @@ static int hv_pci_protocol_negotiation(struct 
> hv_device *hdev)
>   sizeof(struct pci_version_request),
>   (unsigned long)pkt, VM_PKT_DATA_INBAND,
>   VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> + if (!ret)
> + ret = wait_for_response(hdev, _pkt.host_event);
> +
>   if (ret) {
>   dev_err(>device,
> - "PCI Pass-through VSP failed sending version 
> reqquest: %#x",
> + "PCI Pass-through VSP failed to request 
> version: %d",
>   ret);
>   goto exit;
>   }
>  
> - wait_for_completion(_pkt.host_event);
> -
>   if (comp_pkt.completion_status >= 0) {
>   pci_protocol_version = pci_protocol_versions[i];
>   dev_info(>device,
> @@ -2287,11 +2309,12 @@ static int hv_pci_enter_d0(struct hv_device *hdev)
>   ret = vmbus_sendpacket(hdev->channel, d0_entry, sizeof(*d0_entry),
>  (unsigned long)pkt, VM_PKT_DATA_INBAND,
>  VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> + if (!ret)
> + ret = wait_for_response(hdev, _pkt.host_event);
> +
>   if (ret)
>   goto exit;
>  
> - wait_for_completion(_pkt.host_event);
> -
>   if (comp_pkt.completion_status < 0) {
>   dev_err(>device,
>   "PCI Pass-through VSP failed D0 Entry with status %x\n",
> @@ -2331,11 +2354,10 @@ static int hv_pci_query_relations(struct hv_device 
> *hdev)
>  
>   ret = vmbus_sendpacket(hdev->channel, , sizeof(message),
>  0, VM_PKT_DATA_INBAND, 0);
> - if (ret)
> - return ret;
> + if (!ret)
> + ret = wait_for_response(hdev, );
>  
> - wait_for_completion();
> - return 0;
> + return ret;
>  }
>  
>  /**
> @@ -2405,11 +2427,11 @@ static int hv_send_resources_allocated(struct 
> hv_device *hdev)
>   size_res, (unsigned long)pkt,
>   VM_PKT_DATA_INBAND,
>   VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> + if (!ret)
> + ret = wait_for_response(hdev, _pkt.host_event);
>   if (ret)
>   break;
>  
> - wait_for_completion(_pkt.host_event);
> -
>   if (comp_pkt.completion_status < 0) {
>   ret = -EPROTO;
>   dev_err(>device,
> -- 
> 2.7.4
> 

Re: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared

[Lorenzo Pieralisi]

On Wed, May 23, 2018 at 09:12:01PM +, Dexuan Cui wrote:
> 
> Before the guest finishes the device initialization, the device can be
> removed anytime by the host, and after that the host won't respond to
> the guest's request, so the guest should be prepared to handle this
> case.
> 
> Signed-off-by: Dexuan Cui 
> Cc: Stephen Hemminger 
> Cc: K. Y. Srinivasan 
> ---
>  drivers/pci/host/pci-hyperv.c | 46 
> ---
>  1 file changed, 34 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index ad6a64d..248765f 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -556,6 +556,26 @@ static void put_pcichild(struct hv_pci_dev *hv_pcidev,
>  static void get_hvpcibus(struct hv_pcibus_device *hv_pcibus);
>  static void put_hvpcibus(struct hv_pcibus_device *hv_pcibus);
>  
> +/*
> + * There is no good way to get notified from vmbus_onoffer_rescind(),
> + * so let's use polling here, since this is not a hot path.
> + */
> +static int wait_for_response(struct hv_device *hdev,
> +  struct completion *comp)
> +{
> + while (true) {
> + if (hdev->channel->rescind) {
> + dev_warn_once(>device, "The device is gone.\n");
> + return -ENODEV;
> + }
> +
> + if (wait_for_completion_timeout(comp, HZ / 10))
> + break;
> + }
> +
> + return 0;

This is pretty racy, isn't it ? Also, I reckon you should consider the
timeout return value as an error condition unless I am completely
missing the point of what you are doing.

Lorenzo

> +}
> +
>  /**
>   * devfn_to_wslot() - Convert from Linux PCI slot to Windows
>   * @devfn:   The Linux representation of PCI slot
> @@ -1569,7 +1589,8 @@ static struct hv_pci_dev *new_pcichild_device(struct 
> hv_pcibus_device *hbus,
>   if (ret)
>   goto error;
>  
> - wait_for_completion(_pkt.host_event);
> + if (wait_for_response(hbus->hdev, _pkt.host_event))
> + goto error;
>  
>   hpdev->desc = *desc;
>   refcount_set(>refs, 1);
> @@ -2070,15 +2091,16 @@ static int hv_pci_protocol_negotiation(struct 
> hv_device *hdev)
>   sizeof(struct pci_version_request),
>   (unsigned long)pkt, VM_PKT_DATA_INBAND,
>   VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> + if (!ret)
> + ret = wait_for_response(hdev, _pkt.host_event);
> +
>   if (ret) {
>   dev_err(>device,
> - "PCI Pass-through VSP failed sending version 
> reqquest: %#x",
> + "PCI Pass-through VSP failed to request 
> version: %d",
>   ret);
>   goto exit;
>   }
>  
> - wait_for_completion(_pkt.host_event);
> -
>   if (comp_pkt.completion_status >= 0) {
>   pci_protocol_version = pci_protocol_versions[i];
>   dev_info(>device,
> @@ -2287,11 +2309,12 @@ static int hv_pci_enter_d0(struct hv_device *hdev)
>   ret = vmbus_sendpacket(hdev->channel, d0_entry, sizeof(*d0_entry),
>  (unsigned long)pkt, VM_PKT_DATA_INBAND,
>  VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> + if (!ret)
> + ret = wait_for_response(hdev, _pkt.host_event);
> +
>   if (ret)
>   goto exit;
>  
> - wait_for_completion(_pkt.host_event);
> -
>   if (comp_pkt.completion_status < 0) {
>   dev_err(>device,
>   "PCI Pass-through VSP failed D0 Entry with status %x\n",
> @@ -2331,11 +2354,10 @@ static int hv_pci_query_relations(struct hv_device 
> *hdev)
>  
>   ret = vmbus_sendpacket(hdev->channel, , sizeof(message),
>  0, VM_PKT_DATA_INBAND, 0);
> - if (ret)
> - return ret;
> + if (!ret)
> + ret = wait_for_response(hdev, );
>  
> - wait_for_completion();
> - return 0;
> + return ret;
>  }
>  
>  /**
> @@ -2405,11 +2427,11 @@ static int hv_send_resources_allocated(struct 
> hv_device *hdev)
>   size_res, (unsigned long)pkt,
>   VM_PKT_DATA_INBAND,
>   VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> + if (!ret)
> + ret = wait_for_response(hdev, _pkt.host_event);
>   if (ret)
>   break;
>  
> - wait_for_completion(_pkt.host_event);
> -
>   if (comp_pkt.completion_status < 0) {
>   ret = -EPROTO;
>   dev_err(>device,
> -- 
> 2.7.4
> 

Re: [PATCH v2] PCI: qcom: add runtime pm support to pcie_port

[Lorenzo Pieralisi]

On Wed, May 23, 2018 at 11:44:25AM +0100, Srinivas Kandagatla wrote:
> This patch is required when the pcie controller sits on a bus with
> its own power domain and clocks which are controlled via a bus driver
> like simple pm bus. As these bus driver have runtime pm enabled, it makes
> sense to update the usage counter so that the runtime pm does not suspend
> the clks or power domain associated with the bus driver.
> 
> Signed-off-by: Srinivas Kandagatla 
> Signed-off-by: Bjorn Andersson 
> ---
>  drivers/pci/dwc/pcie-qcom.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)

Applied to pci/dwc for v4.18, thanks.

Lorenzo

> diff --git a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c
> index 5897af7d3355..d6ed5aeeae9c 100644
> --- a/drivers/pci/dwc/pcie-qcom.c
> +++ b/drivers/pci/dwc/pcie-qcom.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1088,6 +1089,7 @@ static int qcom_pcie_host_init(struct pcie_port *pp)
>   struct qcom_pcie *pcie = to_qcom_pcie(pci);
>   int ret;
>  
> + pm_runtime_get_sync(pci->dev);
>   qcom_ep_reset_assert(pcie);
>  
>   ret = pcie->ops->init(pcie);
> @@ -1124,6 +1126,7 @@ static int qcom_pcie_host_init(struct pcie_port *pp)
>   phy_power_off(pcie->phy);
>  err_deinit:
>   pcie->ops->deinit(pcie);
> + pm_runtime_put(pci->dev);
>  
>   return ret;
>  }
> @@ -1212,6 +1215,7 @@ static int qcom_pcie_probe(struct platform_device *pdev)
>   if (!pci)
>   return -ENOMEM;
>  
> + pm_runtime_enable(dev);
>   pci->dev = dev;
>   pci->ops = _pcie_ops;
>   pp = >pp;
> @@ -1257,14 +1261,17 @@ static int qcom_pcie_probe(struct platform_device 
> *pdev)
>   }
>  
>   ret = phy_init(pcie->phy);
> - if (ret)
> + if (ret) {
> + pm_runtime_disable(>dev);
>   return ret;
> + }
>  
>   platform_set_drvdata(pdev, pcie);
>  
>   ret = dw_pcie_host_init(pp);
>   if (ret) {
>   dev_err(dev, "cannot initialize host\n");
> + pm_runtime_disable(>dev);
>   return ret;
>   }
>  
> -- 
> 2.16.2
> 

Re: [PATCH v2] PCI: qcom: add runtime pm support to pcie_port

[Lorenzo Pieralisi]

On Wed, May 23, 2018 at 11:44:25AM +0100, Srinivas Kandagatla wrote:
> This patch is required when the pcie controller sits on a bus with
> its own power domain and clocks which are controlled via a bus driver
> like simple pm bus. As these bus driver have runtime pm enabled, it makes
> sense to update the usage counter so that the runtime pm does not suspend
> the clks or power domain associated with the bus driver.
> 
> Signed-off-by: Srinivas Kandagatla 
> Signed-off-by: Bjorn Andersson 
> ---
>  drivers/pci/dwc/pcie-qcom.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)

Applied to pci/dwc for v4.18, thanks.

Lorenzo

> diff --git a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c
> index 5897af7d3355..d6ed5aeeae9c 100644
> --- a/drivers/pci/dwc/pcie-qcom.c
> +++ b/drivers/pci/dwc/pcie-qcom.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1088,6 +1089,7 @@ static int qcom_pcie_host_init(struct pcie_port *pp)
>   struct qcom_pcie *pcie = to_qcom_pcie(pci);
>   int ret;
>  
> + pm_runtime_get_sync(pci->dev);
>   qcom_ep_reset_assert(pcie);
>  
>   ret = pcie->ops->init(pcie);
> @@ -1124,6 +1126,7 @@ static int qcom_pcie_host_init(struct pcie_port *pp)
>   phy_power_off(pcie->phy);
>  err_deinit:
>   pcie->ops->deinit(pcie);
> + pm_runtime_put(pci->dev);
>  
>   return ret;
>  }
> @@ -1212,6 +1215,7 @@ static int qcom_pcie_probe(struct platform_device *pdev)
>   if (!pci)
>   return -ENOMEM;
>  
> + pm_runtime_enable(dev);
>   pci->dev = dev;
>   pci->ops = _pcie_ops;
>   pp = >pp;
> @@ -1257,14 +1261,17 @@ static int qcom_pcie_probe(struct platform_device 
> *pdev)
>   }
>  
>   ret = phy_init(pcie->phy);
> - if (ret)
> + if (ret) {
> + pm_runtime_disable(>dev);
>   return ret;
> + }
>  
>   platform_set_drvdata(pdev, pcie);
>  
>   ret = dw_pcie_host_init(pp);
>   if (ret) {
>   dev_err(dev, "cannot initialize host\n");
> + pm_runtime_disable(>dev);
>   return ret;
>   }
>  
> -- 
> 2.16.2
> 

Re: [PATCH v7 2/2] PCI: mediatek: Using chained IRQ to setup IRQ handle

[Lorenzo Pieralisi]

On Fri, May 18, 2018 at 02:51:54PM -0500, Bjorn Helgaas wrote:
> On Fri, May 04, 2018 at 01:47:33PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > Using irq_chip solution to setup IRQs in order to consist
> > with IRQ framework.
> > 
> > Signed-off-by: Honghui Zhang 
> > Acked-by: Ryder Lee 
> > ---
> >  drivers/pci/host/pcie-mediatek.c | 206 
> > ++-
> >  1 file changed, 115 insertions(+), 91 deletions(-)
> > 
> > diff --git a/drivers/pci/host/pcie-mediatek.c 
> > b/drivers/pci/host/pcie-mediatek.c
> > index c3dc549..dabf1086 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > ...
> 
> > -static int mtk_pcie_msi_map(struct irq_domain *domain, unsigned int irq,
> > -   irq_hw_number_t hwirq)
> > +static struct msi_domain_info mtk_msi_domain_info = {
> 
> I think this patch should be amended to include this:
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 0d0177ce436c..368b70d9371b 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -193,7 +193,7 @@ config PCIE_MEDIATEK
>   bool "MediaTek PCIe controller"
>   depends on (ARM || ARM64) && (ARCH_MEDIATEK || COMPILE_TEST)
>   depends on OF
> - depends on PCI

Actually I amended your patch, since I do not think the deletion above
belongs in this commit (I agree that's completely useless but that's
not this patch that we should remove it).

Lorenzo

> + depends on PCI_MSI_IRQ_DOMAIN

Re: [PATCH v7 2/2] PCI: mediatek: Using chained IRQ to setup IRQ handle

[Lorenzo Pieralisi]

On Fri, May 18, 2018 at 02:51:54PM -0500, Bjorn Helgaas wrote:
> On Fri, May 04, 2018 at 01:47:33PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > Using irq_chip solution to setup IRQs in order to consist
> > with IRQ framework.
> > 
> > Signed-off-by: Honghui Zhang 
> > Acked-by: Ryder Lee 
> > ---
> >  drivers/pci/host/pcie-mediatek.c | 206 
> > ++-
> >  1 file changed, 115 insertions(+), 91 deletions(-)
> > 
> > diff --git a/drivers/pci/host/pcie-mediatek.c 
> > b/drivers/pci/host/pcie-mediatek.c
> > index c3dc549..dabf1086 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > ...
> 
> > -static int mtk_pcie_msi_map(struct irq_domain *domain, unsigned int irq,
> > -   irq_hw_number_t hwirq)
> > +static struct msi_domain_info mtk_msi_domain_info = {
> 
> I think this patch should be amended to include this:
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 0d0177ce436c..368b70d9371b 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -193,7 +193,7 @@ config PCIE_MEDIATEK
>   bool "MediaTek PCIe controller"
>   depends on (ARM || ARM64) && (ARCH_MEDIATEK || COMPILE_TEST)
>   depends on OF
> - depends on PCI

Actually I amended your patch, since I do not think the deletion above
belongs in this commit (I agree that's completely useless but that's
not this patch that we should remove it).

Lorenzo

> + depends on PCI_MSI_IRQ_DOMAIN

Re: [PATCH INTERNAL 3/3] PCI: iproc: Disable MSI parsing in certain PAXC blocks

[Lorenzo Pieralisi]

[+Robin]

On Fri, May 18, 2018 at 12:48:28PM -0700, Ray Jui wrote:
> Hi Lorenzo,
> 
> On 5/18/2018 6:56 AM, Lorenzo Pieralisi wrote:
> >On Fri, May 18, 2018 at 02:53:41PM +0530, p...@codeaurora.org wrote:
> >>On 2018-05-17 22:51, Ray Jui wrote:
> >>>The internal MSI parsing logic in certain revisions of PAXC root
> >>>complexes does not work properly and can casue corruptions on the
> >>>writes. They need to be disabled
> >>>
> >>>Signed-off-by: Ray Jui <ray@broadcom.com>
> >>>Reviewed-by: Scott Branden <scott.bran...@broadcom.com>
> >>>---
> >>>drivers/pci/host/pcie-iproc.c | 34 --
> >>>1 file changed, 32 insertions(+), 2 deletions(-)
> >>>
> >>>diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
> >>>index 3c76c5f..b906d80 100644
> >>>--- a/drivers/pci/host/pcie-iproc.c
> >>>+++ b/drivers/pci/host/pcie-iproc.c
> >>>@@ -1144,10 +1144,22 @@ static int iproc_pcie_paxb_v2_msi_steer(struct
> >>>iproc_pcie *pcie, u64 msi_addr)
> >>>   return ret;
> >>>}
> >>>
> >>>-static void iproc_pcie_paxc_v2_msi_steer(struct iproc_pcie *pcie, u64
> >>>msi_addr)
> >>>+static void iproc_pcie_paxc_v2_msi_steer(struct iproc_pcie *pcie, u64
> >>>msi_addr,
> >>>+   bool enable)
> >>>{
> >>>   u32 val;
> >>>
> >>>+  if (!enable) {
> >>>+  /*
> >>>+   * Disable PAXC MSI steering. All write transfers will be
> >>>+   * treated as non-MSI transfers
> >>>+   */
> >>>+  val = iproc_pcie_read_reg(pcie, IPROC_PCIE_MSI_EN_CFG);
> >>>+  val &= ~MSI_ENABLE_CFG;
> >>>+  iproc_pcie_write_reg(pcie, IPROC_PCIE_MSI_EN_CFG, val);
> >>>+  return;
> >>>+  }
> >>>+
> >>>   /*
> >>>* Program bits [43:13] of address of GITS_TRANSLATER register into
> >>>* bits [30:0] of the MSI base address register.  In fact, in all iProc
> >>>@@ -1201,7 +1213,7 @@ static int iproc_pcie_msi_steer(struct iproc_pcie
> >>>*pcie,
> >>>   return ret;
> >>>   break;
> >>>   case IPROC_PCIE_PAXC_V2:
> >>>-  iproc_pcie_paxc_v2_msi_steer(pcie, msi_addr);
> >>>+  iproc_pcie_paxc_v2_msi_steer(pcie, msi_addr, true);
> >>
> >>Are you calling iproc_pcie_paxc_v2_msi_steer() anywhere else with 'false' ?
> >>I see its getting called only from one place in current code
> >>iproc_pcie_msi_steer().
> >
> >It is called below with the false field to disable MSIs. That's probably
> >one reason more to create a function to enable/disable MSIs instead of
> >adding a parameter to iproc_pcie_paxc_v2_msi_steer().
> 
> Correct. Thanks for helping to explain.
> 
> >
> >Which brings me to the question: what happens to those MSIs writes
> >when MSIs are disabled according to this patch ? Are they terminated
> >at the root complex ?
> 
> Note the PAXC block parses MSI writes from our internally connected
> endpoints (i.e., an embedded network processor). The PAXC block examines
> these MSI writes and modifies the memory attributes (to DEVICE) of these
> data and then send them out to the AXI bus. These MSI writes will then be
> forwarded to the GIC (e.g., GICv2m, GICv3-ITS from ARM) for further
> processing. This is saying, PAXC itself does not process these MSI writes.
> They are processed by the GIC and associated interrupt will be generated
> form the GIC. PAXC's job is to parse and tag them properly so these MSI
> writes can reach the GIC, and at the same, reach the GIC at the right order.
> 
> On some of these problematic PAXCs, we are being forced to disable this PAXC
> internal parsing logic. In this case, we set up static mapping with the
> IOMMU to modify the memory attributes of these MSI writes. These MSI writes
> are always designated towards a specific memory address (e.g., on the GICv3
> based system, it's the address of the translator register), and that's why
> static mapping table can be set up to work around this.

Which means, I presume, that there must be some code that somehow
somewhere in the kernel sets-up those mappings and it has to be related
to this patch, in which case I wonder why we enable the PAXC steering at
all given that this (hack) can be done through the IOMMU (and I assume
that on all PAXC platforms that do need MSIs there is an IOMMU IP
upstream the root bridge, otherwise I have no idea what will happen to
those MSI writes).

Lorenzo

Re: [PATCH INTERNAL 3/3] PCI: iproc: Disable MSI parsing in certain PAXC blocks

[Lorenzo Pieralisi]

[+Robin]

On Fri, May 18, 2018 at 12:48:28PM -0700, Ray Jui wrote:
> Hi Lorenzo,
> 
> On 5/18/2018 6:56 AM, Lorenzo Pieralisi wrote:
> >On Fri, May 18, 2018 at 02:53:41PM +0530, p...@codeaurora.org wrote:
> >>On 2018-05-17 22:51, Ray Jui wrote:
> >>>The internal MSI parsing logic in certain revisions of PAXC root
> >>>complexes does not work properly and can casue corruptions on the
> >>>writes. They need to be disabled
> >>>
> >>>Signed-off-by: Ray Jui 
> >>>Reviewed-by: Scott Branden 
> >>>---
> >>>drivers/pci/host/pcie-iproc.c | 34 --
> >>>1 file changed, 32 insertions(+), 2 deletions(-)
> >>>
> >>>diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
> >>>index 3c76c5f..b906d80 100644
> >>>--- a/drivers/pci/host/pcie-iproc.c
> >>>+++ b/drivers/pci/host/pcie-iproc.c
> >>>@@ -1144,10 +1144,22 @@ static int iproc_pcie_paxb_v2_msi_steer(struct
> >>>iproc_pcie *pcie, u64 msi_addr)
> >>>   return ret;
> >>>}
> >>>
> >>>-static void iproc_pcie_paxc_v2_msi_steer(struct iproc_pcie *pcie, u64
> >>>msi_addr)
> >>>+static void iproc_pcie_paxc_v2_msi_steer(struct iproc_pcie *pcie, u64
> >>>msi_addr,
> >>>+   bool enable)
> >>>{
> >>>   u32 val;
> >>>
> >>>+  if (!enable) {
> >>>+  /*
> >>>+   * Disable PAXC MSI steering. All write transfers will be
> >>>+   * treated as non-MSI transfers
> >>>+   */
> >>>+  val = iproc_pcie_read_reg(pcie, IPROC_PCIE_MSI_EN_CFG);
> >>>+  val &= ~MSI_ENABLE_CFG;
> >>>+  iproc_pcie_write_reg(pcie, IPROC_PCIE_MSI_EN_CFG, val);
> >>>+  return;
> >>>+  }
> >>>+
> >>>   /*
> >>>* Program bits [43:13] of address of GITS_TRANSLATER register into
> >>>* bits [30:0] of the MSI base address register.  In fact, in all iProc
> >>>@@ -1201,7 +1213,7 @@ static int iproc_pcie_msi_steer(struct iproc_pcie
> >>>*pcie,
> >>>   return ret;
> >>>   break;
> >>>   case IPROC_PCIE_PAXC_V2:
> >>>-  iproc_pcie_paxc_v2_msi_steer(pcie, msi_addr);
> >>>+  iproc_pcie_paxc_v2_msi_steer(pcie, msi_addr, true);
> >>
> >>Are you calling iproc_pcie_paxc_v2_msi_steer() anywhere else with 'false' ?
> >>I see its getting called only from one place in current code
> >>iproc_pcie_msi_steer().
> >
> >It is called below with the false field to disable MSIs. That's probably
> >one reason more to create a function to enable/disable MSIs instead of
> >adding a parameter to iproc_pcie_paxc_v2_msi_steer().
> 
> Correct. Thanks for helping to explain.
> 
> >
> >Which brings me to the question: what happens to those MSIs writes
> >when MSIs are disabled according to this patch ? Are they terminated
> >at the root complex ?
> 
> Note the PAXC block parses MSI writes from our internally connected
> endpoints (i.e., an embedded network processor). The PAXC block examines
> these MSI writes and modifies the memory attributes (to DEVICE) of these
> data and then send them out to the AXI bus. These MSI writes will then be
> forwarded to the GIC (e.g., GICv2m, GICv3-ITS from ARM) for further
> processing. This is saying, PAXC itself does not process these MSI writes.
> They are processed by the GIC and associated interrupt will be generated
> form the GIC. PAXC's job is to parse and tag them properly so these MSI
> writes can reach the GIC, and at the same, reach the GIC at the right order.
> 
> On some of these problematic PAXCs, we are being forced to disable this PAXC
> internal parsing logic. In this case, we set up static mapping with the
> IOMMU to modify the memory attributes of these MSI writes. These MSI writes
> are always designated towards a specific memory address (e.g., on the GICv3
> based system, it's the address of the translator register), and that's why
> static mapping table can be set up to work around this.

Which means, I presume, that there must be some code that somehow
somewhere in the kernel sets-up those mappings and it has to be related
to this patch, in which case I wonder why we enable the PAXC steering at
all given that this (hack) can be done through the IOMMU (and I assume
that on all PAXC platforms that do need MSIs there is an IOMMU IP
upstream the root bridge, otherwise I have no idea what will happen to
those MSI writes).

Lorenzo

Re: [PATCH v7 2/2] PCI: mediatek: Using chained IRQ to setup IRQ handle

[Lorenzo Pieralisi]

On Fri, May 18, 2018 at 02:51:54PM -0500, Bjorn Helgaas wrote:
> On Fri, May 04, 2018 at 01:47:33PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > Using irq_chip solution to setup IRQs in order to consist
> > with IRQ framework.
> > 
> > Signed-off-by: Honghui Zhang 
> > Acked-by: Ryder Lee 
> > ---
> >  drivers/pci/host/pcie-mediatek.c | 206 
> > ++-
> >  1 file changed, 115 insertions(+), 91 deletions(-)
> > 
> > diff --git a/drivers/pci/host/pcie-mediatek.c 
> > b/drivers/pci/host/pcie-mediatek.c
> > index c3dc549..dabf1086 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > ...
> 
> > -static int mtk_pcie_msi_map(struct irq_domain *domain, unsigned int irq,
> > -   irq_hw_number_t hwirq)
> > +static struct msi_domain_info mtk_msi_domain_info = {
> 
> I think this patch should be amended to include this:
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 0d0177ce436c..368b70d9371b 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -193,7 +193,7 @@ config PCIE_MEDIATEK
>   bool "MediaTek PCIe controller"
>   depends on (ARM || ARM64) && (ARCH_MEDIATEK || COMPILE_TEST)
>   depends on OF
> - depends on PCI
> + depends on PCI_MSI_IRQ_DOMAIN
>   select PCIEPORTBUS
>   help
> Say Y here if you want to enable PCIe controller support on
> 
> 
> Lorenzo, if you want to fold that in and update your branch, I can pull it.
> If not, I can add a patch on top, which should only break compile-testing
> bisection.

I folded the patch above and pushed into pci/mediatek, thanks !

Lorenzo

Re: [PATCH v7 2/2] PCI: mediatek: Using chained IRQ to setup IRQ handle

[Lorenzo Pieralisi]

On Fri, May 18, 2018 at 02:51:54PM -0500, Bjorn Helgaas wrote:
> On Fri, May 04, 2018 at 01:47:33PM +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > Using irq_chip solution to setup IRQs in order to consist
> > with IRQ framework.
> > 
> > Signed-off-by: Honghui Zhang 
> > Acked-by: Ryder Lee 
> > ---
> >  drivers/pci/host/pcie-mediatek.c | 206 
> > ++-
> >  1 file changed, 115 insertions(+), 91 deletions(-)
> > 
> > diff --git a/drivers/pci/host/pcie-mediatek.c 
> > b/drivers/pci/host/pcie-mediatek.c
> > index c3dc549..dabf1086 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > ...
> 
> > -static int mtk_pcie_msi_map(struct irq_domain *domain, unsigned int irq,
> > -   irq_hw_number_t hwirq)
> > +static struct msi_domain_info mtk_msi_domain_info = {
> 
> I think this patch should be amended to include this:
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 0d0177ce436c..368b70d9371b 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -193,7 +193,7 @@ config PCIE_MEDIATEK
>   bool "MediaTek PCIe controller"
>   depends on (ARM || ARM64) && (ARCH_MEDIATEK || COMPILE_TEST)
>   depends on OF
> - depends on PCI
> + depends on PCI_MSI_IRQ_DOMAIN
>   select PCIEPORTBUS
>   help
> Say Y here if you want to enable PCIe controller support on
> 
> 
> Lorenzo, if you want to fold that in and update your branch, I can pull it.
> If not, I can add a patch on top, which should only break compile-testing
> bisection.

I folded the patch above and pushed into pci/mediatek, thanks !

Lorenzo

Re: [PATCH] PCI: endpoint: Create configfs entry for each pci_epf_device_id table entry

[Lorenzo Pieralisi]

On Fri, May 18, 2018 at 08:19:20PM +0530, Kishon Vijay Abraham I wrote:
> Hi Lorenzo,
> 
> On Friday 18 May 2018 07:52 PM, Lorenzo Pieralisi wrote:
> > Hi Kishon, Gustavo,
> > 
> > On Mon, Apr 02, 2018 at 06:59:35PM +0530, Kishon Vijay Abraham I wrote:
> >> In order to be able to provide correct driver_data for pci_epf device,
> >> a separate configfs entry for each pci_epf_device_id table entry in
> >> pci_epf_driver is required.
> >>
> >> Add support to create configfs entry for each pci_epf_device_id
> >> table entry here.
> >>
> >> Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
> >> ---
> >>  drivers/pci/endpoint/pci-epf-core.c | 23 +--
> >>  include/linux/pci-epf.h |  4 ++--
> >>  2 files changed, 23 insertions(+), 4 deletions(-)
> > 
> > Do we still need this patch after the recent discussion on the configfs
> > interface ?
> 
> Yeah, Since we allow multiple pci_epf_device_id entries to be created, I think
> this patch is still valid.
> 
> If someone wants to create a new pci_epf_device_id entry (maybe for 
> configuring
> the driver in a different way), this would be still required.

Applied to pci/endpoint for v4.18, thanks.

Lorenzo

> Thanks
> Kishon
> > 
> > https://patchwork.ozlabs.org/patch/903494/
> > 
> > Lorenzo
> > 
> >> diff --git a/drivers/pci/endpoint/pci-epf-core.c 
> >> b/drivers/pci/endpoint/pci-epf-core.c
> >> index 59ed29e550e9..d6787f39fd41 100644
> >> --- a/drivers/pci/endpoint/pci-epf-core.c
> >> +++ b/drivers/pci/endpoint/pci-epf-core.c
> >> @@ -15,6 +15,8 @@
> >>  #include 
> >>  #include 
> >>  
> >> +static DEFINE_MUTEX(pci_epf_mutex);
> >> +
> >>  static struct bus_type pci_epf_bus_type;
> >>  static const struct device_type pci_epf_type;
> >>  
> >> @@ -139,7 +141,13 @@ EXPORT_SYMBOL_GPL(pci_epf_alloc_space);
> >>   */
> >>  void pci_epf_unregister_driver(struct pci_epf_driver *driver)
> >>  {
> >> -  pci_ep_cfs_remove_epf_group(driver->group);
> >> +  struct config_group *group;
> >> +
> >> +  mutex_lock(_epf_mutex);
> >> +  list_for_each_entry(group, >epf_group, group_entry)
> >> +  pci_ep_cfs_remove_epf_group(group);
> >> +  list_del(>epf_group);
> >> +  mutex_unlock(_epf_mutex);
> >>driver_unregister(>driver);
> >>  }
> >>  EXPORT_SYMBOL_GPL(pci_epf_unregister_driver);
> >> @@ -155,6 +163,8 @@ int __pci_epf_register_driver(struct pci_epf_driver 
> >> *driver,
> >>  struct module *owner)
> >>  {
> >>int ret;
> >> +  struct config_group *group;
> >> +  const struct pci_epf_device_id *id;
> >>  
> >>if (!driver->ops)
> >>return -EINVAL;
> >> @@ -169,7 +179,16 @@ int __pci_epf_register_driver(struct pci_epf_driver 
> >> *driver,
> >>if (ret)
> >>return ret;
> >>  
> >> -  driver->group = pci_ep_cfs_add_epf_group(driver->driver.name);
> >> +  INIT_LIST_HEAD(>epf_group);
> >> +
> >> +  id = driver->id_table;
> >> +  while (id->name[0]) {
> >> +  group = pci_ep_cfs_add_epf_group(id->name);
> >> +  mutex_lock(_epf_mutex);
> >> +  list_add_tail(>group_entry, >epf_group);
> >> +  mutex_unlock(_epf_mutex);
> >> +  id++;
> >> +  }
> >>  
> >>return 0;
> >>  }
> >> diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
> >> index e897bf076701..a30dcaafa6e8 100644
> >> --- a/include/linux/pci-epf.h
> >> +++ b/include/linux/pci-epf.h
> >> @@ -72,7 +72,7 @@ struct pci_epf_ops {
> >>   * @driver: PCI EPF driver
> >>   * @ops: set of function pointers for performing EPF operations
> >>   * @owner: the owner of the module that registers the PCI EPF driver
> >> - * @group: configfs group corresponding to the PCI EPF driver
> >> + * @epf_group: list of configfs group corresponding to the PCI EPF driver
> >>   * @id_table: identifies EPF devices for probing
> >>   */
> >>  struct pci_epf_driver {
> >> @@ -82,7 +82,7 @@ struct pci_epf_driver {
> >>struct device_driverdriver;
> >>struct pci_epf_ops  *ops;
> >>struct module   *owner;
> >> -  struct config_group *group;
> >> +  struct list_headepf_group;
> >>const struct pci_epf_device_id  *id_table;
> >>  };
> >>  
> >> -- 
> >> 2.16.2
> >>

Re: [PATCH] PCI: endpoint: Create configfs entry for each pci_epf_device_id table entry

[Lorenzo Pieralisi]

On Fri, May 18, 2018 at 08:19:20PM +0530, Kishon Vijay Abraham I wrote:
> Hi Lorenzo,
> 
> On Friday 18 May 2018 07:52 PM, Lorenzo Pieralisi wrote:
> > Hi Kishon, Gustavo,
> > 
> > On Mon, Apr 02, 2018 at 06:59:35PM +0530, Kishon Vijay Abraham I wrote:
> >> In order to be able to provide correct driver_data for pci_epf device,
> >> a separate configfs entry for each pci_epf_device_id table entry in
> >> pci_epf_driver is required.
> >>
> >> Add support to create configfs entry for each pci_epf_device_id
> >> table entry here.
> >>
> >> Signed-off-by: Kishon Vijay Abraham I 
> >> ---
> >>  drivers/pci/endpoint/pci-epf-core.c | 23 +--
> >>  include/linux/pci-epf.h |  4 ++--
> >>  2 files changed, 23 insertions(+), 4 deletions(-)
> > 
> > Do we still need this patch after the recent discussion on the configfs
> > interface ?
> 
> Yeah, Since we allow multiple pci_epf_device_id entries to be created, I think
> this patch is still valid.
> 
> If someone wants to create a new pci_epf_device_id entry (maybe for 
> configuring
> the driver in a different way), this would be still required.

Applied to pci/endpoint for v4.18, thanks.

Lorenzo

> Thanks
> Kishon
> > 
> > https://patchwork.ozlabs.org/patch/903494/
> > 
> > Lorenzo
> > 
> >> diff --git a/drivers/pci/endpoint/pci-epf-core.c 
> >> b/drivers/pci/endpoint/pci-epf-core.c
> >> index 59ed29e550e9..d6787f39fd41 100644
> >> --- a/drivers/pci/endpoint/pci-epf-core.c
> >> +++ b/drivers/pci/endpoint/pci-epf-core.c
> >> @@ -15,6 +15,8 @@
> >>  #include 
> >>  #include 
> >>  
> >> +static DEFINE_MUTEX(pci_epf_mutex);
> >> +
> >>  static struct bus_type pci_epf_bus_type;
> >>  static const struct device_type pci_epf_type;
> >>  
> >> @@ -139,7 +141,13 @@ EXPORT_SYMBOL_GPL(pci_epf_alloc_space);
> >>   */
> >>  void pci_epf_unregister_driver(struct pci_epf_driver *driver)
> >>  {
> >> -  pci_ep_cfs_remove_epf_group(driver->group);
> >> +  struct config_group *group;
> >> +
> >> +  mutex_lock(_epf_mutex);
> >> +  list_for_each_entry(group, >epf_group, group_entry)
> >> +  pci_ep_cfs_remove_epf_group(group);
> >> +  list_del(>epf_group);
> >> +  mutex_unlock(_epf_mutex);
> >>driver_unregister(>driver);
> >>  }
> >>  EXPORT_SYMBOL_GPL(pci_epf_unregister_driver);
> >> @@ -155,6 +163,8 @@ int __pci_epf_register_driver(struct pci_epf_driver 
> >> *driver,
> >>  struct module *owner)
> >>  {
> >>int ret;
> >> +  struct config_group *group;
> >> +  const struct pci_epf_device_id *id;
> >>  
> >>if (!driver->ops)
> >>return -EINVAL;
> >> @@ -169,7 +179,16 @@ int __pci_epf_register_driver(struct pci_epf_driver 
> >> *driver,
> >>if (ret)
> >>return ret;
> >>  
> >> -  driver->group = pci_ep_cfs_add_epf_group(driver->driver.name);
> >> +  INIT_LIST_HEAD(>epf_group);
> >> +
> >> +  id = driver->id_table;
> >> +  while (id->name[0]) {
> >> +  group = pci_ep_cfs_add_epf_group(id->name);
> >> +  mutex_lock(_epf_mutex);
> >> +  list_add_tail(>group_entry, >epf_group);
> >> +  mutex_unlock(_epf_mutex);
> >> +  id++;
> >> +  }
> >>  
> >>return 0;
> >>  }
> >> diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
> >> index e897bf076701..a30dcaafa6e8 100644
> >> --- a/include/linux/pci-epf.h
> >> +++ b/include/linux/pci-epf.h
> >> @@ -72,7 +72,7 @@ struct pci_epf_ops {
> >>   * @driver: PCI EPF driver
> >>   * @ops: set of function pointers for performing EPF operations
> >>   * @owner: the owner of the module that registers the PCI EPF driver
> >> - * @group: configfs group corresponding to the PCI EPF driver
> >> + * @epf_group: list of configfs group corresponding to the PCI EPF driver
> >>   * @id_table: identifies EPF devices for probing
> >>   */
> >>  struct pci_epf_driver {
> >> @@ -82,7 +82,7 @@ struct pci_epf_driver {
> >>struct device_driverdriver;
> >>struct pci_epf_ops  *ops;
> >>struct module   *owner;
> >> -  struct config_group *group;
> >> +  struct list_headepf_group;
> >>const struct pci_epf_device_id  *id_table;
> >>  };
> >>  
> >> -- 
> >> 2.16.2
> >>

Re: [PATCH] PCI: endpoint: Create configfs entry for each pci_epf_device_id table entry

[Lorenzo Pieralisi]

Hi Kishon, Gustavo,

On Mon, Apr 02, 2018 at 06:59:35PM +0530, Kishon Vijay Abraham I wrote:
> In order to be able to provide correct driver_data for pci_epf device,
> a separate configfs entry for each pci_epf_device_id table entry in
> pci_epf_driver is required.
> 
> Add support to create configfs entry for each pci_epf_device_id
> table entry here.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/pci/endpoint/pci-epf-core.c | 23 +--
>  include/linux/pci-epf.h |  4 ++--
>  2 files changed, 23 insertions(+), 4 deletions(-)

Do we still need this patch after the recent discussion on the configfs
interface ?

https://patchwork.ozlabs.org/patch/903494/

Lorenzo

> diff --git a/drivers/pci/endpoint/pci-epf-core.c 
> b/drivers/pci/endpoint/pci-epf-core.c
> index 59ed29e550e9..d6787f39fd41 100644
> --- a/drivers/pci/endpoint/pci-epf-core.c
> +++ b/drivers/pci/endpoint/pci-epf-core.c
> @@ -15,6 +15,8 @@
>  #include 
>  #include 
>  
> +static DEFINE_MUTEX(pci_epf_mutex);
> +
>  static struct bus_type pci_epf_bus_type;
>  static const struct device_type pci_epf_type;
>  
> @@ -139,7 +141,13 @@ EXPORT_SYMBOL_GPL(pci_epf_alloc_space);
>   */
>  void pci_epf_unregister_driver(struct pci_epf_driver *driver)
>  {
> - pci_ep_cfs_remove_epf_group(driver->group);
> + struct config_group *group;
> +
> + mutex_lock(_epf_mutex);
> + list_for_each_entry(group, >epf_group, group_entry)
> + pci_ep_cfs_remove_epf_group(group);
> + list_del(>epf_group);
> + mutex_unlock(_epf_mutex);
>   driver_unregister(>driver);
>  }
>  EXPORT_SYMBOL_GPL(pci_epf_unregister_driver);
> @@ -155,6 +163,8 @@ int __pci_epf_register_driver(struct pci_epf_driver 
> *driver,
> struct module *owner)
>  {
>   int ret;
> + struct config_group *group;
> + const struct pci_epf_device_id *id;
>  
>   if (!driver->ops)
>   return -EINVAL;
> @@ -169,7 +179,16 @@ int __pci_epf_register_driver(struct pci_epf_driver 
> *driver,
>   if (ret)
>   return ret;
>  
> - driver->group = pci_ep_cfs_add_epf_group(driver->driver.name);
> + INIT_LIST_HEAD(>epf_group);
> +
> + id = driver->id_table;
> + while (id->name[0]) {
> + group = pci_ep_cfs_add_epf_group(id->name);
> + mutex_lock(_epf_mutex);
> + list_add_tail(>group_entry, >epf_group);
> + mutex_unlock(_epf_mutex);
> + id++;
> + }
>  
>   return 0;
>  }
> diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
> index e897bf076701..a30dcaafa6e8 100644
> --- a/include/linux/pci-epf.h
> +++ b/include/linux/pci-epf.h
> @@ -72,7 +72,7 @@ struct pci_epf_ops {
>   * @driver: PCI EPF driver
>   * @ops: set of function pointers for performing EPF operations
>   * @owner: the owner of the module that registers the PCI EPF driver
> - * @group: configfs group corresponding to the PCI EPF driver
> + * @epf_group: list of configfs group corresponding to the PCI EPF driver
>   * @id_table: identifies EPF devices for probing
>   */
>  struct pci_epf_driver {
> @@ -82,7 +82,7 @@ struct pci_epf_driver {
>   struct device_driverdriver;
>   struct pci_epf_ops  *ops;
>   struct module   *owner;
> - struct config_group *group;
> + struct list_headepf_group;
>   const struct pci_epf_device_id  *id_table;
>  };
>  
> -- 
> 2.16.2
> 

Re: [PATCH] PCI: endpoint: Create configfs entry for each pci_epf_device_id table entry

[Lorenzo Pieralisi]

Hi Kishon, Gustavo,

On Mon, Apr 02, 2018 at 06:59:35PM +0530, Kishon Vijay Abraham I wrote:
> In order to be able to provide correct driver_data for pci_epf device,
> a separate configfs entry for each pci_epf_device_id table entry in
> pci_epf_driver is required.
> 
> Add support to create configfs entry for each pci_epf_device_id
> table entry here.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/pci/endpoint/pci-epf-core.c | 23 +--
>  include/linux/pci-epf.h |  4 ++--
>  2 files changed, 23 insertions(+), 4 deletions(-)

Do we still need this patch after the recent discussion on the configfs
interface ?

https://patchwork.ozlabs.org/patch/903494/

Lorenzo

> diff --git a/drivers/pci/endpoint/pci-epf-core.c 
> b/drivers/pci/endpoint/pci-epf-core.c
> index 59ed29e550e9..d6787f39fd41 100644
> --- a/drivers/pci/endpoint/pci-epf-core.c
> +++ b/drivers/pci/endpoint/pci-epf-core.c
> @@ -15,6 +15,8 @@
>  #include 
>  #include 
>  
> +static DEFINE_MUTEX(pci_epf_mutex);
> +
>  static struct bus_type pci_epf_bus_type;
>  static const struct device_type pci_epf_type;
>  
> @@ -139,7 +141,13 @@ EXPORT_SYMBOL_GPL(pci_epf_alloc_space);
>   */
>  void pci_epf_unregister_driver(struct pci_epf_driver *driver)
>  {
> - pci_ep_cfs_remove_epf_group(driver->group);
> + struct config_group *group;
> +
> + mutex_lock(_epf_mutex);
> + list_for_each_entry(group, >epf_group, group_entry)
> + pci_ep_cfs_remove_epf_group(group);
> + list_del(>epf_group);
> + mutex_unlock(_epf_mutex);
>   driver_unregister(>driver);
>  }
>  EXPORT_SYMBOL_GPL(pci_epf_unregister_driver);
> @@ -155,6 +163,8 @@ int __pci_epf_register_driver(struct pci_epf_driver 
> *driver,
> struct module *owner)
>  {
>   int ret;
> + struct config_group *group;
> + const struct pci_epf_device_id *id;
>  
>   if (!driver->ops)
>   return -EINVAL;
> @@ -169,7 +179,16 @@ int __pci_epf_register_driver(struct pci_epf_driver 
> *driver,
>   if (ret)
>   return ret;
>  
> - driver->group = pci_ep_cfs_add_epf_group(driver->driver.name);
> + INIT_LIST_HEAD(>epf_group);
> +
> + id = driver->id_table;
> + while (id->name[0]) {
> + group = pci_ep_cfs_add_epf_group(id->name);
> + mutex_lock(_epf_mutex);
> + list_add_tail(>group_entry, >epf_group);
> + mutex_unlock(_epf_mutex);
> + id++;
> + }
>  
>   return 0;
>  }
> diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
> index e897bf076701..a30dcaafa6e8 100644
> --- a/include/linux/pci-epf.h
> +++ b/include/linux/pci-epf.h
> @@ -72,7 +72,7 @@ struct pci_epf_ops {
>   * @driver: PCI EPF driver
>   * @ops: set of function pointers for performing EPF operations
>   * @owner: the owner of the module that registers the PCI EPF driver
> - * @group: configfs group corresponding to the PCI EPF driver
> + * @epf_group: list of configfs group corresponding to the PCI EPF driver
>   * @id_table: identifies EPF devices for probing
>   */
>  struct pci_epf_driver {
> @@ -82,7 +82,7 @@ struct pci_epf_driver {
>   struct device_driverdriver;
>   struct pci_epf_ops  *ops;
>   struct module   *owner;
> - struct config_group *group;
> + struct list_headepf_group;
>   const struct pci_epf_device_id  *id_table;
>  };
>  
> -- 
> 2.16.2
> 

Re: [PATCH INTERNAL 3/3] PCI: iproc: Disable MSI parsing in certain PAXC blocks

[Lorenzo Pieralisi]

On Fri, May 18, 2018 at 02:53:41PM +0530, p...@codeaurora.org wrote:
> On 2018-05-17 22:51, Ray Jui wrote:
> >The internal MSI parsing logic in certain revisions of PAXC root
> >complexes does not work properly and can casue corruptions on the
> >writes. They need to be disabled
> >
> >Signed-off-by: Ray Jui 
> >Reviewed-by: Scott Branden 
> >---
> > drivers/pci/host/pcie-iproc.c | 34 --
> > 1 file changed, 32 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
> >index 3c76c5f..b906d80 100644
> >--- a/drivers/pci/host/pcie-iproc.c
> >+++ b/drivers/pci/host/pcie-iproc.c
> >@@ -1144,10 +1144,22 @@ static int iproc_pcie_paxb_v2_msi_steer(struct
> >iproc_pcie *pcie, u64 msi_addr)
> > return ret;
> > }
> >
> >-static void iproc_pcie_paxc_v2_msi_steer(struct iproc_pcie *pcie, u64
> >msi_addr)
> >+static void iproc_pcie_paxc_v2_msi_steer(struct iproc_pcie *pcie, u64
> >msi_addr,
> >+ bool enable)
> > {
> > u32 val;
> >
> >+if (!enable) {
> >+/*
> >+ * Disable PAXC MSI steering. All write transfers will be
> >+ * treated as non-MSI transfers
> >+ */
> >+val = iproc_pcie_read_reg(pcie, IPROC_PCIE_MSI_EN_CFG);
> >+val &= ~MSI_ENABLE_CFG;
> >+iproc_pcie_write_reg(pcie, IPROC_PCIE_MSI_EN_CFG, val);
> >+return;
> >+}
> >+
> > /*
> >  * Program bits [43:13] of address of GITS_TRANSLATER register into
> >  * bits [30:0] of the MSI base address register.  In fact, in all iProc
> >@@ -1201,7 +1213,7 @@ static int iproc_pcie_msi_steer(struct iproc_pcie
> >*pcie,
> > return ret;
> > break;
> > case IPROC_PCIE_PAXC_V2:
> >-iproc_pcie_paxc_v2_msi_steer(pcie, msi_addr);
> >+iproc_pcie_paxc_v2_msi_steer(pcie, msi_addr, true);
> 
> Are you calling iproc_pcie_paxc_v2_msi_steer() anywhere else with 'false' ?
> I see its getting called only from one place in current code
> iproc_pcie_msi_steer().

It is called below with the false field to disable MSIs. That's probably
one reason more to create a function to enable/disable MSIs instead of
adding a parameter to iproc_pcie_paxc_v2_msi_steer().

Which brings me to the question: what happens to those MSIs writes
when MSIs are disabled according to this patch ? Are they terminated
at the root complex ?

Lorenzo

> > break;
> > default:
> > return -EINVAL;
> >@@ -1427,6 +1439,24 @@ int iproc_pcie_remove(struct iproc_pcie *pcie)
> > }
> > EXPORT_SYMBOL(iproc_pcie_remove);
> >
> >+/*
> >+ * The MSI parsing logic in certain revisions of Broadcom PAXC based root
> >+ * complex does not work and needs to be disabled
> >+ */
> >+static void quirk_paxc_disable_msi_parsing(struct pci_dev *pdev)
> >+{
> >+struct iproc_pcie *pcie = iproc_data(pdev->bus);
> >+
> >+if (pdev->hdr_type == PCI_HEADER_TYPE_BRIDGE)
> >+iproc_pcie_paxc_v2_msi_steer(pcie, 0, false);
> >+}
> >+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0x16f0,
> >+quirk_paxc_disable_msi_parsing);
> >+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0xd802,
> >+quirk_paxc_disable_msi_parsing);
> >+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0xd804,
> >+quirk_paxc_disable_msi_parsing);
> >+
> > MODULE_AUTHOR("Ray Jui ");
> > MODULE_DESCRIPTION("Broadcom iPROC PCIe common driver");
> > MODULE_LICENSE("GPL v2");

Re: [PATCH INTERNAL 3/3] PCI: iproc: Disable MSI parsing in certain PAXC blocks

[Lorenzo Pieralisi]

On Fri, May 18, 2018 at 02:53:41PM +0530, p...@codeaurora.org wrote:
> On 2018-05-17 22:51, Ray Jui wrote:
> >The internal MSI parsing logic in certain revisions of PAXC root
> >complexes does not work properly and can casue corruptions on the
> >writes. They need to be disabled
> >
> >Signed-off-by: Ray Jui 
> >Reviewed-by: Scott Branden 
> >---
> > drivers/pci/host/pcie-iproc.c | 34 --
> > 1 file changed, 32 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
> >index 3c76c5f..b906d80 100644
> >--- a/drivers/pci/host/pcie-iproc.c
> >+++ b/drivers/pci/host/pcie-iproc.c
> >@@ -1144,10 +1144,22 @@ static int iproc_pcie_paxb_v2_msi_steer(struct
> >iproc_pcie *pcie, u64 msi_addr)
> > return ret;
> > }
> >
> >-static void iproc_pcie_paxc_v2_msi_steer(struct iproc_pcie *pcie, u64
> >msi_addr)
> >+static void iproc_pcie_paxc_v2_msi_steer(struct iproc_pcie *pcie, u64
> >msi_addr,
> >+ bool enable)
> > {
> > u32 val;
> >
> >+if (!enable) {
> >+/*
> >+ * Disable PAXC MSI steering. All write transfers will be
> >+ * treated as non-MSI transfers
> >+ */
> >+val = iproc_pcie_read_reg(pcie, IPROC_PCIE_MSI_EN_CFG);
> >+val &= ~MSI_ENABLE_CFG;
> >+iproc_pcie_write_reg(pcie, IPROC_PCIE_MSI_EN_CFG, val);
> >+return;
> >+}
> >+
> > /*
> >  * Program bits [43:13] of address of GITS_TRANSLATER register into
> >  * bits [30:0] of the MSI base address register.  In fact, in all iProc
> >@@ -1201,7 +1213,7 @@ static int iproc_pcie_msi_steer(struct iproc_pcie
> >*pcie,
> > return ret;
> > break;
> > case IPROC_PCIE_PAXC_V2:
> >-iproc_pcie_paxc_v2_msi_steer(pcie, msi_addr);
> >+iproc_pcie_paxc_v2_msi_steer(pcie, msi_addr, true);
> 
> Are you calling iproc_pcie_paxc_v2_msi_steer() anywhere else with 'false' ?
> I see its getting called only from one place in current code
> iproc_pcie_msi_steer().

It is called below with the false field to disable MSIs. That's probably
one reason more to create a function to enable/disable MSIs instead of
adding a parameter to iproc_pcie_paxc_v2_msi_steer().

Which brings me to the question: what happens to those MSIs writes
when MSIs are disabled according to this patch ? Are they terminated
at the root complex ?

Lorenzo

> > break;
> > default:
> > return -EINVAL;
> >@@ -1427,6 +1439,24 @@ int iproc_pcie_remove(struct iproc_pcie *pcie)
> > }
> > EXPORT_SYMBOL(iproc_pcie_remove);
> >
> >+/*
> >+ * The MSI parsing logic in certain revisions of Broadcom PAXC based root
> >+ * complex does not work and needs to be disabled
> >+ */
> >+static void quirk_paxc_disable_msi_parsing(struct pci_dev *pdev)
> >+{
> >+struct iproc_pcie *pcie = iproc_data(pdev->bus);
> >+
> >+if (pdev->hdr_type == PCI_HEADER_TYPE_BRIDGE)
> >+iproc_pcie_paxc_v2_msi_steer(pcie, 0, false);
> >+}
> >+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0x16f0,
> >+quirk_paxc_disable_msi_parsing);
> >+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0xd802,
> >+quirk_paxc_disable_msi_parsing);
> >+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0xd804,
> >+quirk_paxc_disable_msi_parsing);
> >+
> > MODULE_AUTHOR("Ray Jui ");
> > MODULE_DESCRIPTION("Broadcom iPROC PCIe common driver");
> > MODULE_LICENSE("GPL v2");

Re: [PATCH v4] PCI: kirin: Add MSI support

[Lorenzo Pieralisi]

On Wed, May 16, 2018 at 09:21:59AM +0800, Xiaowei Song wrote:
> From: Yao Chen 
> 
> Add support for MSI.
> 
> Signed-off-by: Yao Chen 
> Cc: Xiaowei Song 
> ---
>  drivers/pci/dwc/pcie-kirin.c | 51 
> 
>  1 file changed, 51 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-kirin.c b/drivers/pci/dwc/pcie-kirin.c
> index d2970a0..00ca4e5 100644
> --- a/drivers/pci/dwc/pcie-kirin.c
> +++ b/drivers/pci/dwc/pcie-kirin.c
> @@ -426,9 +426,28 @@ static int kirin_pcie_establish_link(struct pcie_port 
> *pp)
>   return 0;
>  }
>  
> +static irqreturn_t kirin_pcie_msi_irq_handler(int irq, void *arg)
> +{
> + struct pcie_port *pp = arg;
> +
> + return dw_handle_msi_irq(pp);
> +}

You do not need an IRQ handler, the IRQ is handled already in the
dwc driver following Gustavo's rework.

https://patchwork.ozlabs.org/patch/882017/

> +static void kirin_pcie_msi_init(struct pcie_port *pp)
> +{
> + dw_pcie_msi_init(pp);
> +}
> +
> +static void kirin_pcie_enable_interrupts(struct pcie_port *pp)
> +{
> + if (IS_ENABLED(CONFIG_PCI_MSI))
> + kirin_pcie_msi_init(pp);
> +}

Why do you need two functons ?

> +
>  static int kirin_pcie_host_init(struct pcie_port *pp)
>  {
>   kirin_pcie_establish_link(pp);
> + kirin_pcie_enable_interrupts(pp);
>  
>   return 0;
>  }
> @@ -445,9 +464,41 @@ static const struct dw_pcie_host_ops kirin_pcie_host_ops 
> = {
>   .host_init = kirin_pcie_host_init,
>  };
>  
> +static int kirin_pcie_add_msi(struct dw_pcie *pci,
> + struct platform_device *pdev)
> +{
> + int ret = 0;
> +
> + if (IS_ENABLED(CONFIG_PCI_MSI)) {
> + ret = platform_get_irq(pdev, 0);
> + if (ret < 0) {
> + dev_err(>dev, "failed to get MSI IRQ (%d)\n",
> + pci->pp.msi_irq);
> + return ret;
> + }
> +
> + pci->pp.msi_irq = ret;
> +
> + ret = devm_request_irq(>dev, pci->pp.msi_irq,
> +kirin_pcie_msi_irq_handler,
> +IRQF_SHARED | IRQF_NO_THREAD,
> +"kirin_pcie_msi", >pp);
> + if (ret)
> + dev_err(>dev, "failed to request MSI IRQ %d\n",
> + pci->pp.msi_irq);

This is wrong. If msi_irq is set, the dwc driver will handle the MSI and
you must not request the IRQ in the platform driver, see above for
the link to Gustavo's work.

Lorenzo

> + }
> + return ret;
> +}
> +
>  static int __init kirin_add_pcie_port(struct dw_pcie *pci,
> struct platform_device *pdev)
>  {
> + int ret;
> +
> + ret = kirin_pcie_add_msi(pci, pdev);
> + if (ret)
> + return ret;
> +
>   pci->pp.ops = _pcie_host_ops;
>  
>   return dw_pcie_host_init(>pp);
> -- 
> 2.7.3
> 

Re: [PATCH v4] PCI: kirin: Add MSI support

[Lorenzo Pieralisi]

On Wed, May 16, 2018 at 09:21:59AM +0800, Xiaowei Song wrote:
> From: Yao Chen 
> 
> Add support for MSI.
> 
> Signed-off-by: Yao Chen 
> Cc: Xiaowei Song 
> ---
>  drivers/pci/dwc/pcie-kirin.c | 51 
> 
>  1 file changed, 51 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-kirin.c b/drivers/pci/dwc/pcie-kirin.c
> index d2970a0..00ca4e5 100644
> --- a/drivers/pci/dwc/pcie-kirin.c
> +++ b/drivers/pci/dwc/pcie-kirin.c
> @@ -426,9 +426,28 @@ static int kirin_pcie_establish_link(struct pcie_port 
> *pp)
>   return 0;
>  }
>  
> +static irqreturn_t kirin_pcie_msi_irq_handler(int irq, void *arg)
> +{
> + struct pcie_port *pp = arg;
> +
> + return dw_handle_msi_irq(pp);
> +}

You do not need an IRQ handler, the IRQ is handled already in the
dwc driver following Gustavo's rework.

https://patchwork.ozlabs.org/patch/882017/

> +static void kirin_pcie_msi_init(struct pcie_port *pp)
> +{
> + dw_pcie_msi_init(pp);
> +}
> +
> +static void kirin_pcie_enable_interrupts(struct pcie_port *pp)
> +{
> + if (IS_ENABLED(CONFIG_PCI_MSI))
> + kirin_pcie_msi_init(pp);
> +}

Why do you need two functons ?

> +
>  static int kirin_pcie_host_init(struct pcie_port *pp)
>  {
>   kirin_pcie_establish_link(pp);
> + kirin_pcie_enable_interrupts(pp);
>  
>   return 0;
>  }
> @@ -445,9 +464,41 @@ static const struct dw_pcie_host_ops kirin_pcie_host_ops 
> = {
>   .host_init = kirin_pcie_host_init,
>  };
>  
> +static int kirin_pcie_add_msi(struct dw_pcie *pci,
> + struct platform_device *pdev)
> +{
> + int ret = 0;
> +
> + if (IS_ENABLED(CONFIG_PCI_MSI)) {
> + ret = platform_get_irq(pdev, 0);
> + if (ret < 0) {
> + dev_err(>dev, "failed to get MSI IRQ (%d)\n",
> + pci->pp.msi_irq);
> + return ret;
> + }
> +
> + pci->pp.msi_irq = ret;
> +
> + ret = devm_request_irq(>dev, pci->pp.msi_irq,
> +kirin_pcie_msi_irq_handler,
> +IRQF_SHARED | IRQF_NO_THREAD,
> +"kirin_pcie_msi", >pp);
> + if (ret)
> + dev_err(>dev, "failed to request MSI IRQ %d\n",
> + pci->pp.msi_irq);

This is wrong. If msi_irq is set, the dwc driver will handle the MSI and
you must not request the IRQ in the platform driver, see above for
the link to Gustavo's work.

Lorenzo

> + }
> + return ret;
> +}
> +
>  static int __init kirin_add_pcie_port(struct dw_pcie *pci,
> struct platform_device *pdev)
>  {
> + int ret;
> +
> + ret = kirin_pcie_add_msi(pci, pdev);
> + if (ret)
> + return ret;
> +
>   pci->pp.ops = _pcie_host_ops;
>  
>   return dw_pcie_host_init(>pp);
> -- 
> 2.7.3
> 

Re: [PATCH] pci: cadence: Host and EP driver updates for PHY and power management

[Lorenzo Pieralisi]

On Wed, May 16, 2018 at 01:06:05PM +, Alan Douglas wrote:
> From: Alan Douglas 
> 
> This patch is based on next branch in Bjorn Helgaas' linux-pci git repository.
This sentence does not belong in a commit log and you should not be
basing patches on top of Bjorn's next branch, use v4.17-rc1, that is
an immutable commit.

> Allow optional list of generic PHYs to be provided via DTS for cadence
> RP and EP drivers.  Added power management ops which will
> enable/disable these PHYs.  Corrected parameters for cdns_pcie_writel
> function, value to be written had too small width.

Too many things at once. Each patch must solve one logical problem
and one only - it is easier to understand why if you think that
a patch may need to be reverted - if many changes are lumped together
this becomes complicated, that's one of the reasons.

So, please split this patch and send a v2, thank you.

Lorenzo

> Signed-off-by: Alan Douglas 
> ---
>  .../devicetree/bindings/pci/cdns,cdns-pcie-ep.txt  |4 +
>  .../bindings/pci/cdns,cdns-pcie-host.txt   |5 +
>  drivers/pci/cadence/pcie-cadence-ep.c  |   15 +++-
>  drivers/pci/cadence/pcie-cadence-host.c|   36 ++-
>  drivers/pci/cadence/pcie-cadence.c |  123 
> 
>  drivers/pci/cadence/pcie-cadence.h |   13 ++-
>  6 files changed, 193 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.txt 
> b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.txt
> index 9a30523..e40c635 100644
> --- a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.txt
> +++ b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.txt
> @@ -9,6 +9,8 @@ Required properties:
>  
>  Optional properties:
>  - max-functions: Maximum number of functions that can be configured (default 
> 1).
> +- phys: From PHY bindings: List of Generic PHY phandles.
> +- phy-names:  List of names to identify the PHY.
>  
>  Example:
>  
> @@ -19,4 +21,6 @@ pcie@fc00 {
>   reg-names = "reg", "mem";
>   cdns,max-outbound-regions = <16>;
>   max-functions = /bits/ 8 <8>;
> + phys = <_phy0 _phy1>;
> + phy-names = "pcie-lane0","pcie-lane1";
>  };
> diff --git a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.txt 
> b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.txt
> index 20a33f3..13be218 100644
> --- a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.txt
> +++ b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.txt
> @@ -24,6 +24,8 @@ Optional properties:
>translations (default 32)
>  - vendor-id: The PCI vendor ID (16 bits, default is design dependent)
>  - device-id: The PCI device ID (16 bits, default is design dependent)
> +- phys: From PHY bindings: List of Generic PHY phandles.
> +- phy-names:  List of names to identify the PHY.
>  
>  Example:
>  
> @@ -57,4 +59,7 @@ pcie@fb00 {
>   interrupt-map-mask = <0x0 0x0 0x0  0x7>;
>  
>   msi-parent = <_pci>;
> +
> + phys = <_phy0>;
> + phy-names = "pcie-phy";
>  };
> diff --git a/drivers/pci/cadence/pcie-cadence-ep.c 
> b/drivers/pci/cadence/pcie-cadence-ep.c
> index 3d8283e..e74b8a4 100644
> --- a/drivers/pci/cadence/pcie-cadence-ep.c
> +++ b/drivers/pci/cadence/pcie-cadence-ep.c
> @@ -439,6 +439,7 @@ static int cdns_pcie_ep_probe(struct platform_device 
> *pdev)
>   struct pci_epc *epc;
>   struct resource *res;
>   int ret;
> + int phy_count;
>  
>   ep = devm_kzalloc(dev, sizeof(*ep), GFP_KERNEL);
>   if (!ep)
> @@ -472,6 +473,12 @@ static int cdns_pcie_ep_probe(struct platform_device 
> *pdev)
>   if (!ep->ob_addr)
>   return -ENOMEM;
>  
> + ret = cdns_pcie_init_phy(dev, pcie);
> + if (ret) {
> + dev_err(dev, "failed to init phy\n");
> + return ret;
> + }
> + platform_set_drvdata(pdev, pcie);
>   pm_runtime_enable(dev);
>   ret = pm_runtime_get_sync(dev);
>   if (ret < 0) {
> @@ -520,6 +527,10 @@ static int cdns_pcie_ep_probe(struct platform_device 
> *pdev)
>  
>   err_get_sync:
>   pm_runtime_disable(dev);
> + cdns_pcie_disable_phy(pcie);
> + phy_count = pcie->phy_count;
> + while (phy_count--)
> + device_link_del(pcie->link[phy_count]);
>  
>   return ret;
>  }
> @@ -527,6 +538,7 @@ static int cdns_pcie_ep_probe(struct platform_device 
> *pdev)
>  static void cdns_pcie_ep_shutdown(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
> + struct cdns_pcie *pcie = dev_get_drvdata(dev);
>   int ret;
>  
>   ret = pm_runtime_put_sync(dev);
> @@ -535,13 +547,14 @@ static void cdns_pcie_ep_shutdown(struct 
> platform_device *pdev)
>  
>   pm_runtime_disable(dev);
>  
> - /* The PCIe controller can't be disabled. */
> + cdns_pcie_disable_phy(pcie);
>  }
>  
>  static struct platform_driver cdns_pcie_ep_driver = {
>   .driver = {

Re: [PATCH] pci: cadence: Host and EP driver updates for PHY and power management

[Lorenzo Pieralisi]

On Wed, May 16, 2018 at 01:06:05PM +, Alan Douglas wrote:
> From: Alan Douglas 
> 
> This patch is based on next branch in Bjorn Helgaas' linux-pci git repository.
This sentence does not belong in a commit log and you should not be
basing patches on top of Bjorn's next branch, use v4.17-rc1, that is
an immutable commit.

> Allow optional list of generic PHYs to be provided via DTS for cadence
> RP and EP drivers.  Added power management ops which will
> enable/disable these PHYs.  Corrected parameters for cdns_pcie_writel
> function, value to be written had too small width.

Too many things at once. Each patch must solve one logical problem
and one only - it is easier to understand why if you think that
a patch may need to be reverted - if many changes are lumped together
this becomes complicated, that's one of the reasons.

So, please split this patch and send a v2, thank you.

Lorenzo

> Signed-off-by: Alan Douglas 
> ---
>  .../devicetree/bindings/pci/cdns,cdns-pcie-ep.txt  |4 +
>  .../bindings/pci/cdns,cdns-pcie-host.txt   |5 +
>  drivers/pci/cadence/pcie-cadence-ep.c  |   15 +++-
>  drivers/pci/cadence/pcie-cadence-host.c|   36 ++-
>  drivers/pci/cadence/pcie-cadence.c |  123 
> 
>  drivers/pci/cadence/pcie-cadence.h |   13 ++-
>  6 files changed, 193 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.txt 
> b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.txt
> index 9a30523..e40c635 100644
> --- a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.txt
> +++ b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.txt
> @@ -9,6 +9,8 @@ Required properties:
>  
>  Optional properties:
>  - max-functions: Maximum number of functions that can be configured (default 
> 1).
> +- phys: From PHY bindings: List of Generic PHY phandles.
> +- phy-names:  List of names to identify the PHY.
>  
>  Example:
>  
> @@ -19,4 +21,6 @@ pcie@fc00 {
>   reg-names = "reg", "mem";
>   cdns,max-outbound-regions = <16>;
>   max-functions = /bits/ 8 <8>;
> + phys = <_phy0 _phy1>;
> + phy-names = "pcie-lane0","pcie-lane1";
>  };
> diff --git a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.txt 
> b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.txt
> index 20a33f3..13be218 100644
> --- a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.txt
> +++ b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.txt
> @@ -24,6 +24,8 @@ Optional properties:
>translations (default 32)
>  - vendor-id: The PCI vendor ID (16 bits, default is design dependent)
>  - device-id: The PCI device ID (16 bits, default is design dependent)
> +- phys: From PHY bindings: List of Generic PHY phandles.
> +- phy-names:  List of names to identify the PHY.
>  
>  Example:
>  
> @@ -57,4 +59,7 @@ pcie@fb00 {
>   interrupt-map-mask = <0x0 0x0 0x0  0x7>;
>  
>   msi-parent = <_pci>;
> +
> + phys = <_phy0>;
> + phy-names = "pcie-phy";
>  };
> diff --git a/drivers/pci/cadence/pcie-cadence-ep.c 
> b/drivers/pci/cadence/pcie-cadence-ep.c
> index 3d8283e..e74b8a4 100644
> --- a/drivers/pci/cadence/pcie-cadence-ep.c
> +++ b/drivers/pci/cadence/pcie-cadence-ep.c
> @@ -439,6 +439,7 @@ static int cdns_pcie_ep_probe(struct platform_device 
> *pdev)
>   struct pci_epc *epc;
>   struct resource *res;
>   int ret;
> + int phy_count;
>  
>   ep = devm_kzalloc(dev, sizeof(*ep), GFP_KERNEL);
>   if (!ep)
> @@ -472,6 +473,12 @@ static int cdns_pcie_ep_probe(struct platform_device 
> *pdev)
>   if (!ep->ob_addr)
>   return -ENOMEM;
>  
> + ret = cdns_pcie_init_phy(dev, pcie);
> + if (ret) {
> + dev_err(dev, "failed to init phy\n");
> + return ret;
> + }
> + platform_set_drvdata(pdev, pcie);
>   pm_runtime_enable(dev);
>   ret = pm_runtime_get_sync(dev);
>   if (ret < 0) {
> @@ -520,6 +527,10 @@ static int cdns_pcie_ep_probe(struct platform_device 
> *pdev)
>  
>   err_get_sync:
>   pm_runtime_disable(dev);
> + cdns_pcie_disable_phy(pcie);
> + phy_count = pcie->phy_count;
> + while (phy_count--)
> + device_link_del(pcie->link[phy_count]);
>  
>   return ret;
>  }
> @@ -527,6 +538,7 @@ static int cdns_pcie_ep_probe(struct platform_device 
> *pdev)
>  static void cdns_pcie_ep_shutdown(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
> + struct cdns_pcie *pcie = dev_get_drvdata(dev);
>   int ret;
>  
>   ret = pm_runtime_put_sync(dev);
> @@ -535,13 +547,14 @@ static void cdns_pcie_ep_shutdown(struct 
> platform_device *pdev)
>  
>   pm_runtime_disable(dev);
>  
> - /* The PCIe controller can't be disabled. */
> + cdns_pcie_disable_phy(pcie);
>  }
>  
>  static struct platform_driver cdns_pcie_ep_driver = {
>   .driver = {
>   .name = "cdns-pcie-ep",
>

Re: [PATCH v2 0/4] Add DesignWare EP support

[Lorenzo Pieralisi]

On Tue, May 15, 2018 at 03:41:40PM +0100, Gustavo Pimentel wrote:
> Patch set was made against the Lorenzo's pci/dwc branch.
> 
> The PCIe controller dual mode is capable of operating in RC mode as well
> as EP mode by configuration option. Till now only RC mode was supported,
> with this patch is add EP support to the DesignWare driver.
> 
> Gustavo Pimentel (4):
>   bindings: PCI: designware: Example update
>   PCI: dwc: Add support for EP mode
>   bindings: PCI: designware: Add support for EP in DesignWare driver
>   misc: pci_endpoint_test: Add DesignWare EP entry
> 
>  .../devicetree/bindings/pci/designware-pcie.txt|  24 +++-
>  drivers/misc/pci_endpoint_test.c   |   1 +
>  drivers/pci/dwc/Kconfig|  37 +++--
>  drivers/pci/dwc/pcie-designware-ep.c   |   3 +
>  drivers/pci/dwc/pcie-designware-plat.c | 149 
> +++--
>  drivers/pci/endpoint/functions/pci-epf-test.c  |   7 +
>  include/linux/pci-epc.h|   8 ++
>  7 files changed, 205 insertions(+), 24 deletions(-)

Applied to pci/dwc for v4.18 with some small commit log tweaks.

Thanks,
Lorenzo

Re: [PATCH v2 0/4] Add DesignWare EP support

[Lorenzo Pieralisi]

On Tue, May 15, 2018 at 03:41:40PM +0100, Gustavo Pimentel wrote:
> Patch set was made against the Lorenzo's pci/dwc branch.
> 
> The PCIe controller dual mode is capable of operating in RC mode as well
> as EP mode by configuration option. Till now only RC mode was supported,
> with this patch is add EP support to the DesignWare driver.
> 
> Gustavo Pimentel (4):
>   bindings: PCI: designware: Example update
>   PCI: dwc: Add support for EP mode
>   bindings: PCI: designware: Add support for EP in DesignWare driver
>   misc: pci_endpoint_test: Add DesignWare EP entry
> 
>  .../devicetree/bindings/pci/designware-pcie.txt|  24 +++-
>  drivers/misc/pci_endpoint_test.c   |   1 +
>  drivers/pci/dwc/Kconfig|  37 +++--
>  drivers/pci/dwc/pcie-designware-ep.c   |   3 +
>  drivers/pci/dwc/pcie-designware-plat.c | 149 
> +++--
>  drivers/pci/endpoint/functions/pci-epf-test.c  |   7 +
>  include/linux/pci-epc.h|   8 ++
>  7 files changed, 205 insertions(+), 24 deletions(-)

Applied to pci/dwc for v4.18 with some small commit log tweaks.

Thanks,
Lorenzo

Re: [PATCH] pci: endpoint: Replace mdelay with usleep_range in pci_epf_test_write

[Lorenzo Pieralisi]

On Tue, Apr 10, 2018 at 09:04:06PM +0800, Jia-Ju Bai wrote:
> pci_epf_test_write() is never called in atomic context.
> 
> The call chain ending up at pci_epf_test_write() is:
> [1] pci_epf_test_write() <- pci_epf_test_cmd_handler()
> 
> pci_epf_test_cmd_handler() is set as a parameter of INIT_DELAYED_WORK() 
> in pci_epf_test_probe().
> This function is not called in atomic context.
> 
> Despite never getting called from atomic context, pci_epf_test_write()
> calls mdelay() to busily wait.
> This is not necessary and can be replaced with usleep_range() to
> avoid busy waiting.
> 
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.
> 
> Signed-off-by: Jia-Ju Bai 
> ---
>  drivers/pci/endpoint/functions/pci-epf-test.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to pci/endpoint for v4.18, thanks.

Lorenzo

> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> b/drivers/pci/endpoint/functions/pci-epf-test.c
> index f9308c2..2f0642e 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -237,7 +237,7 @@ static int pci_epf_test_write(struct pci_epf_test 
> *epf_test)
>* wait 1ms inorder for the write to complete. Without this delay L3
>* error in observed in the host system.
>*/
> - mdelay(1);
> + usleep_range(1000, 2000);
>  
>   kfree(buf);
>  
> -- 
> 1.9.1
> 

Re: [PATCH] pci: endpoint: Replace mdelay with usleep_range in pci_epf_test_write

[Lorenzo Pieralisi]

On Tue, Apr 10, 2018 at 09:04:06PM +0800, Jia-Ju Bai wrote:
> pci_epf_test_write() is never called in atomic context.
> 
> The call chain ending up at pci_epf_test_write() is:
> [1] pci_epf_test_write() <- pci_epf_test_cmd_handler()
> 
> pci_epf_test_cmd_handler() is set as a parameter of INIT_DELAYED_WORK() 
> in pci_epf_test_probe().
> This function is not called in atomic context.
> 
> Despite never getting called from atomic context, pci_epf_test_write()
> calls mdelay() to busily wait.
> This is not necessary and can be replaced with usleep_range() to
> avoid busy waiting.
> 
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.
> 
> Signed-off-by: Jia-Ju Bai 
> ---
>  drivers/pci/endpoint/functions/pci-epf-test.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to pci/endpoint for v4.18, thanks.

Lorenzo

> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> b/drivers/pci/endpoint/functions/pci-epf-test.c
> index f9308c2..2f0642e 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -237,7 +237,7 @@ static int pci_epf_test_write(struct pci_epf_test 
> *epf_test)
>* wait 1ms inorder for the write to complete. Without this delay L3
>* error in observed in the host system.
>*/
> - mdelay(1);
> + usleep_range(1000, 2000);
>  
>   kfree(buf);
>  
> -- 
> 1.9.1
> 

Re: [PATCH] pci: endpoint: Replace mdelay with usleep_range in pci_epf_test_write

[Lorenzo Pieralisi]

On Tue, Apr 10, 2018 at 09:04:06PM +0800, Jia-Ju Bai wrote:
> pci_epf_test_write() is never called in atomic context.
> 
> The call chain ending up at pci_epf_test_write() is:
> [1] pci_epf_test_write() <- pci_epf_test_cmd_handler()
> 
> pci_epf_test_cmd_handler() is set as a parameter of INIT_DELAYED_WORK() 
> in pci_epf_test_probe().
> This function is not called in atomic context.
> 
> Despite never getting called from atomic context, pci_epf_test_write()
> calls mdelay() to busily wait.
> This is not necessary and can be replaced with usleep_range() to
> avoid busy waiting.
> 
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.
> 
> Signed-off-by: Jia-Ju Bai 
> ---
>  drivers/pci/endpoint/functions/pci-epf-test.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to pci/endpoint for v4.18, thanks.

Lorenzo

> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> b/drivers/pci/endpoint/functions/pci-epf-test.c
> index f9308c2..2f0642e 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -237,7 +237,7 @@ static int pci_epf_test_write(struct pci_epf_test 
> *epf_test)
>* wait 1ms inorder for the write to complete. Without this delay L3
>* error in observed in the host system.
>*/
> - mdelay(1);
> + usleep_range(1000, 2000);
>  
>   kfree(buf);
>  
> -- 
> 1.9.1
> 

Re: [PATCH] pci: endpoint: Replace mdelay with usleep_range in pci_epf_test_write

[Lorenzo Pieralisi]

On Tue, Apr 10, 2018 at 09:04:06PM +0800, Jia-Ju Bai wrote:
> pci_epf_test_write() is never called in atomic context.
> 
> The call chain ending up at pci_epf_test_write() is:
> [1] pci_epf_test_write() <- pci_epf_test_cmd_handler()
> 
> pci_epf_test_cmd_handler() is set as a parameter of INIT_DELAYED_WORK() 
> in pci_epf_test_probe().
> This function is not called in atomic context.
> 
> Despite never getting called from atomic context, pci_epf_test_write()
> calls mdelay() to busily wait.
> This is not necessary and can be replaced with usleep_range() to
> avoid busy waiting.
> 
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.
> 
> Signed-off-by: Jia-Ju Bai 
> ---
>  drivers/pci/endpoint/functions/pci-epf-test.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to pci/endpoint for v4.18, thanks.

Lorenzo

> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> b/drivers/pci/endpoint/functions/pci-epf-test.c
> index f9308c2..2f0642e 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -237,7 +237,7 @@ static int pci_epf_test_write(struct pci_epf_test 
> *epf_test)
>* wait 1ms inorder for the write to complete. Without this delay L3
>* error in observed in the host system.
>*/
> - mdelay(1);
> + usleep_range(1000, 2000);
>  
>   kfree(buf);
>  
> -- 
> 1.9.1
> 

Re: [PATCH v2 07/10] PCI: Convert of_pci_get_host_bridge_resources() users to devm variant

[Lorenzo Pieralisi]

On Thu, May 03, 2018 at 10:18:24AM +0300, Vladimir Zapolskiy wrote:
> Hi Jan,
> 
> On 04/30/2018 08:48 AM, Jan Kiszka wrote:
> > From: Jan Kiszka <jan.kis...@siemens.com>
> > 
> > Straightforward for all of them, no more leaks afterwards.
> > 
> > CC: Jingoo Han <jingooh...@gmail.com>
> > CC: Joao Pinto <joao.pi...@synopsys.com>
> > CC: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
> > Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
> > Acked-by: Jingoo Han <jingoo1...@gmail.com>
> 
> [snip]
> 
> > diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> > index 6ab28f29ac6a..6eb36c924983 100644
> > --- a/drivers/pci/host/pcie-rcar.c
> > +++ b/drivers/pci/host/pcie-rcar.c
> > @@ -1067,12 +1067,11 @@ static int 
> > rcar_pcie_parse_request_of_pci_ranges(struct rcar_pcie *pci)
> >  {
> > int err;
> > struct device *dev = pci->dev;
> > -   struct device_node *np = dev->of_node;
> > resource_size_t iobase;
> > struct resource_entry *win, *tmp;
> >  
> > -   err = of_pci_get_host_bridge_resources(np, 0, 0xff, >resources,
> > -  );
> > +   err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
> > +   >resources, );
> > if (err)
> > return err;
> >  
> 
> this one snippet is obsoleted by https://patchwork.ozlabs.org/patch/904326/
> 
> If 08/10 remains a deprecation, then it is sufficient to exclude the R-Car 
> change,
> otherwise I hope maintainers can deal with the proper ordering.

Isn't applying your patch:

https://patchwork.ozlabs.org/patch/904326/

and dropping the rcar hunk from this patch enough ?

Lorenzo

Re: [PATCH v2 07/10] PCI: Convert of_pci_get_host_bridge_resources() users to devm variant

[Lorenzo Pieralisi]

On Thu, May 03, 2018 at 10:18:24AM +0300, Vladimir Zapolskiy wrote:
> Hi Jan,
> 
> On 04/30/2018 08:48 AM, Jan Kiszka wrote:
> > From: Jan Kiszka 
> > 
> > Straightforward for all of them, no more leaks afterwards.
> > 
> > CC: Jingoo Han 
> > CC: Joao Pinto 
> > CC: Lorenzo Pieralisi 
> > Signed-off-by: Jan Kiszka 
> > Acked-by: Jingoo Han 
> 
> [snip]
> 
> > diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> > index 6ab28f29ac6a..6eb36c924983 100644
> > --- a/drivers/pci/host/pcie-rcar.c
> > +++ b/drivers/pci/host/pcie-rcar.c
> > @@ -1067,12 +1067,11 @@ static int 
> > rcar_pcie_parse_request_of_pci_ranges(struct rcar_pcie *pci)
> >  {
> > int err;
> > struct device *dev = pci->dev;
> > -   struct device_node *np = dev->of_node;
> > resource_size_t iobase;
> > struct resource_entry *win, *tmp;
> >  
> > -   err = of_pci_get_host_bridge_resources(np, 0, 0xff, >resources,
> > -  );
> > +   err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
> > +   >resources, );
> > if (err)
> > return err;
> >  
> 
> this one snippet is obsoleted by https://patchwork.ozlabs.org/patch/904326/
> 
> If 08/10 remains a deprecation, then it is sufficient to exclude the R-Car 
> change,
> otherwise I hope maintainers can deal with the proper ordering.

Isn't applying your patch:

https://patchwork.ozlabs.org/patch/904326/

and dropping the rcar hunk from this patch enough ?

Lorenzo

Re: [PATCH] pci: endpoint: Replace mdelay with usleep_range in pci_epf_test_write

[Lorenzo Pieralisi]

On Tue, Apr 10, 2018 at 09:04:06PM +0800, Jia-Ju Bai wrote:
> pci_epf_test_write() is never called in atomic context.
> 
> The call chain ending up at pci_epf_test_write() is:
> [1] pci_epf_test_write() <- pci_epf_test_cmd_handler()
> 
> pci_epf_test_cmd_handler() is set as a parameter of INIT_DELAYED_WORK() 
> in pci_epf_test_probe().
> This function is not called in atomic context.
> 
> Despite never getting called from atomic context, pci_epf_test_write()
> calls mdelay() to busily wait.
> This is not necessary and can be replaced with usleep_range() to
> avoid busy waiting.
> 
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.
> 
> Signed-off-by: Jia-Ju Bai 
> ---
>  drivers/pci/endpoint/functions/pci-epf-test.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I'd request Kishon's ACK on this.

Thanks,
Lorenzo

> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> b/drivers/pci/endpoint/functions/pci-epf-test.c
> index f9308c2..2f0642e 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -237,7 +237,7 @@ static int pci_epf_test_write(struct pci_epf_test 
> *epf_test)
>* wait 1ms inorder for the write to complete. Without this delay L3
>* error in observed in the host system.
>*/
> - mdelay(1);
> + usleep_range(1000, 2000);
>  
>   kfree(buf);
>  
> -- 
> 1.9.1
> 

Re: [PATCH] pci: endpoint: Replace mdelay with usleep_range in pci_epf_test_write

[Lorenzo Pieralisi]

On Tue, Apr 10, 2018 at 09:04:06PM +0800, Jia-Ju Bai wrote:
> pci_epf_test_write() is never called in atomic context.
> 
> The call chain ending up at pci_epf_test_write() is:
> [1] pci_epf_test_write() <- pci_epf_test_cmd_handler()
> 
> pci_epf_test_cmd_handler() is set as a parameter of INIT_DELAYED_WORK() 
> in pci_epf_test_probe().
> This function is not called in atomic context.
> 
> Despite never getting called from atomic context, pci_epf_test_write()
> calls mdelay() to busily wait.
> This is not necessary and can be replaced with usleep_range() to
> avoid busy waiting.
> 
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.
> 
> Signed-off-by: Jia-Ju Bai 
> ---
>  drivers/pci/endpoint/functions/pci-epf-test.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I'd request Kishon's ACK on this.

Thanks,
Lorenzo

> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> b/drivers/pci/endpoint/functions/pci-epf-test.c
> index f9308c2..2f0642e 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -237,7 +237,7 @@ static int pci_epf_test_write(struct pci_epf_test 
> *epf_test)
>* wait 1ms inorder for the write to complete. Without this delay L3
>* error in observed in the host system.
>*/
> - mdelay(1);
> + usleep_range(1000, 2000);
>  
>   kfree(buf);
>  
> -- 
> 1.9.1
> 

Re: [PATCH v7 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code

[Lorenzo Pieralisi]

On Fri, May 04, 2018 at 01:47:31PM +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang 
> 
> Two fixups for mediatek's host bridge:
> The first patch fixup class type and vendor ID for MT7622.
> The second patch fixup the IRQ handle routine by using irq_chip solution
> to avoid IRQ reentry which may exist for both MT2712 and MT7622.
> 
> Change since v6:
>  - Remove the irq_mask, irq_unmask callback in lower layer irq_chip since we
>have set the MSI_FLAG_USE_DEF_CHIP_OPS flags.
>  - Add irq_ack callback in irq_chip to handle edge IRQ.
>  - Uing handle_edge_irq to handle the MSI IRQs.
> 
> Change since v5:
>  - Make the comments consistend with the code modification in the first patch.
>  - Using writew to performing a 16-bit write.
>  - Using irq_chip solution to fix the IRQ issue.
> 
> The v5 patchset could be found in:
>  https://patchwork.kernel.org/patch/10133303
>  https://patchwork.kernel.org/patch/10133305
> 
> Change since v4:
>  - Only setup vendor ID for MT7622, igorning the device ID since mediatek's
>host bridge driver does not cares about the device ID.
> 
> Change since v3:
>  - Setup the class type and vendor ID at the beginning of startup instead
>of in a quirk.
>  - Add mediatek's vendor ID, it could be found in:
>https://pcisig.com/membership/member-companies?combine==4
> 
> Change since v2:
>  - Move the initialize of the iterate before the loop to fix an
>INTx IRQ issue in the first patch
> 
> Change since v1:
>  - Add the second patch.
>  - Make the first patch's commit message more standard.
> 
> Honghui Zhang (2):
>   PCI: mediatek: Set up vendor ID and class type for MT7622
>   PCI: mediatek: Using chained IRQ to setup IRQ handle
> 
>  drivers/pci/host/pcie-mediatek.c | 234 
> +++
>  include/linux/pci_ids.h  |   2 +
>  2 files changed, 143 insertions(+), 93 deletions(-)

Applied to pci/mediatek for v4.18, thanks.

Lorenzo

Re: [PATCH v7 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code

[Lorenzo Pieralisi]

On Fri, May 04, 2018 at 01:47:31PM +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang 
> 
> Two fixups for mediatek's host bridge:
> The first patch fixup class type and vendor ID for MT7622.
> The second patch fixup the IRQ handle routine by using irq_chip solution
> to avoid IRQ reentry which may exist for both MT2712 and MT7622.
> 
> Change since v6:
>  - Remove the irq_mask, irq_unmask callback in lower layer irq_chip since we
>have set the MSI_FLAG_USE_DEF_CHIP_OPS flags.
>  - Add irq_ack callback in irq_chip to handle edge IRQ.
>  - Uing handle_edge_irq to handle the MSI IRQs.
> 
> Change since v5:
>  - Make the comments consistend with the code modification in the first patch.
>  - Using writew to performing a 16-bit write.
>  - Using irq_chip solution to fix the IRQ issue.
> 
> The v5 patchset could be found in:
>  https://patchwork.kernel.org/patch/10133303
>  https://patchwork.kernel.org/patch/10133305
> 
> Change since v4:
>  - Only setup vendor ID for MT7622, igorning the device ID since mediatek's
>host bridge driver does not cares about the device ID.
> 
> Change since v3:
>  - Setup the class type and vendor ID at the beginning of startup instead
>of in a quirk.
>  - Add mediatek's vendor ID, it could be found in:
>https://pcisig.com/membership/member-companies?combine==4
> 
> Change since v2:
>  - Move the initialize of the iterate before the loop to fix an
>INTx IRQ issue in the first patch
> 
> Change since v1:
>  - Add the second patch.
>  - Make the first patch's commit message more standard.
> 
> Honghui Zhang (2):
>   PCI: mediatek: Set up vendor ID and class type for MT7622
>   PCI: mediatek: Using chained IRQ to setup IRQ handle
> 
>  drivers/pci/host/pcie-mediatek.c | 234 
> +++
>  include/linux/pci_ids.h  |   2 +
>  2 files changed, 143 insertions(+), 93 deletions(-)

Applied to pci/mediatek for v4.18, thanks.

Lorenzo

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

[Lorenzo Pieralisi]

On Fri, May 04, 2018 at 11:28:58AM +0530, Kishon Vijay Abraham I wrote:
> Hi Lorenzo,
> 
> On Thursday 03 May 2018 07:46 PM, Lorenzo Pieralisi wrote:
> > On Thu, May 03, 2018 at 12:03:15PM +0530, Kishon Vijay Abraham I wrote:
> > 
> > [...]
> > 
> >>>> Since the linkup notifier and BAR index (where auxiliary registers are
> >>>> located) may be configurable and is something platform dependent,
> >>>> perhaps the configuration of this variables should be done by module
> >>>> parameter and not by configfs, leaving this configuration
> >>>> responsibility in charge of each platform.
> >>>
> >>> They are platform dependent because they depend on the EP controller.
> >>> That's why I said that those are EP controller parameters. I do not
> >>> think they are module parameters either - they should be part of HW
> >>> description in firmware.
> >>
> >> The problem is because pci-epf-test cannot be described in HW. 
> >> pci-epf-test is
> >> also not automatically bound to the EP controller but is bound by the user 
> >> like
> >> below
> >> ln -s functions/pci_epf_test/func1 controllers/5100.pcie_ep/
> >>
> >> So given that user anyways has to bind the epf device to the controller, 
> >> based
> >> on the platform the user can use a different configfs entry like below
> >> ln -s functions/pci_epf_test_dw/func1 controllers/5100.pcie_ep/ or
> >> ln -s functions/pci_epf_test_k2g/func1 controllers/2180.pcie-ep/
> >>
> >> If the epf can be described in dt, then something like below can be done
> >> pcie1_ep: pcie_ep@5100 {
> >>compatible = "ti,dra7-pcie-ep";
> >>interrupts = <0 232 0x4>;
> >>num-lanes = <1>;
> >>num-ib-windows = <4>;
> >>num-ob-windows = <16>;
> >>phys = <_phy>;
> >>phy-names = "pcie-phy0";
> >>pci_epf_test: pci_epf_test@0 {
> >>name = "pci_epf_test_dw";
> >>;
> >>}
> >> };
> >>
> >> With this pci-dra7xx.c driver should create pci_epf_device using
> >> pci_epf_create("pci_epf_test_dw");
> >>
> >> Then the driver_data corresponding to "pci_epf_test_dw" will select linkup
> >> notifier or BAR index etc.
> > 
> > Those two properties are properties of the EP controller (it is not 100%
> > clear to me how the test BAR register is defined), is this correct ?
> 
> Right, these properties are specific to a platform. In some of the platforms
> like K2G (BAR0 is reserved i.e it is used to map PCIe app registers and cannot
> be used by pci_epf_test. In such cases we should use a BAR other than BAR0).

I do not think those properties are pci_epf_test specific, that's the
whole point I am making. Those are EPC controller features.

> > If yes, given that those properties are not useful before an EPF is
> > bound to an EPC, can't they be retrieved at bind time from the EPC
> > controller data (that we can add through DT bindings) ?
> 
> hmm..
> 
> We can have quirk in pci_epc, something like below
> 
> struct pci_epc {
>   .
>   .
>   unsigned int quirks;
>   .
>   .
> };
> 
> #define EPC_QUIRKS_NO_LINKUP_NOTIFIER BIT(0)
> #define EPC_QUIRKS_BAR0_RESERVED  BIT(1)
> #define EPC_QUIRKS_BAR1_RESERVED  BIT(2)
> #define EPC_QUIRKS_BAR2_RESERVED  BIT(3)
> #define EPC_QUIRKS_BAR3_RESERVED  BIT(4)
> #define EPC_QUIRKS_BAR4_RESERVED  BIT(5)
> #define EPC_QUIRKS_BAR5_RESERVED  BIT(6)
> 
> The controller driver can set the appropriate quirks
> epc->quirks |= EPC_QUIRKS_NO_LINKUP_NOTIFIER | EPC_QUIRKS_BAR0_RESERVED;
> 
> Then pci-epf-test driver can checks the quirks to see the supported EPC 
> features.
> 
> Does something like above looks okay to you?

Well, it is better than the driver_data approach, I would not call them
quirks but features and for the BARs you should define a mask it does
not make sense to enumerate them. It is probably a good idea to leave
room for additional "features" so please choose the bits placement
wisely.

Thanks,
Lorenzo

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

[Lorenzo Pieralisi]

On Fri, May 04, 2018 at 11:28:58AM +0530, Kishon Vijay Abraham I wrote:
> Hi Lorenzo,
> 
> On Thursday 03 May 2018 07:46 PM, Lorenzo Pieralisi wrote:
> > On Thu, May 03, 2018 at 12:03:15PM +0530, Kishon Vijay Abraham I wrote:
> > 
> > [...]
> > 
> >>>> Since the linkup notifier and BAR index (where auxiliary registers are
> >>>> located) may be configurable and is something platform dependent,
> >>>> perhaps the configuration of this variables should be done by module
> >>>> parameter and not by configfs, leaving this configuration
> >>>> responsibility in charge of each platform.
> >>>
> >>> They are platform dependent because they depend on the EP controller.
> >>> That's why I said that those are EP controller parameters. I do not
> >>> think they are module parameters either - they should be part of HW
> >>> description in firmware.
> >>
> >> The problem is because pci-epf-test cannot be described in HW. 
> >> pci-epf-test is
> >> also not automatically bound to the EP controller but is bound by the user 
> >> like
> >> below
> >> ln -s functions/pci_epf_test/func1 controllers/5100.pcie_ep/
> >>
> >> So given that user anyways has to bind the epf device to the controller, 
> >> based
> >> on the platform the user can use a different configfs entry like below
> >> ln -s functions/pci_epf_test_dw/func1 controllers/5100.pcie_ep/ or
> >> ln -s functions/pci_epf_test_k2g/func1 controllers/2180.pcie-ep/
> >>
> >> If the epf can be described in dt, then something like below can be done
> >> pcie1_ep: pcie_ep@5100 {
> >>compatible = "ti,dra7-pcie-ep";
> >>interrupts = <0 232 0x4>;
> >>num-lanes = <1>;
> >>num-ib-windows = <4>;
> >>num-ob-windows = <16>;
> >>phys = <_phy>;
> >>phy-names = "pcie-phy0";
> >>pci_epf_test: pci_epf_test@0 {
> >>name = "pci_epf_test_dw";
> >>;
> >>}
> >> };
> >>
> >> With this pci-dra7xx.c driver should create pci_epf_device using
> >> pci_epf_create("pci_epf_test_dw");
> >>
> >> Then the driver_data corresponding to "pci_epf_test_dw" will select linkup
> >> notifier or BAR index etc.
> > 
> > Those two properties are properties of the EP controller (it is not 100%
> > clear to me how the test BAR register is defined), is this correct ?
> 
> Right, these properties are specific to a platform. In some of the platforms
> like K2G (BAR0 is reserved i.e it is used to map PCIe app registers and cannot
> be used by pci_epf_test. In such cases we should use a BAR other than BAR0).

I do not think those properties are pci_epf_test specific, that's the
whole point I am making. Those are EPC controller features.

> > If yes, given that those properties are not useful before an EPF is
> > bound to an EPC, can't they be retrieved at bind time from the EPC
> > controller data (that we can add through DT bindings) ?
> 
> hmm..
> 
> We can have quirk in pci_epc, something like below
> 
> struct pci_epc {
>   .
>   .
>   unsigned int quirks;
>   .
>   .
> };
> 
> #define EPC_QUIRKS_NO_LINKUP_NOTIFIER BIT(0)
> #define EPC_QUIRKS_BAR0_RESERVED  BIT(1)
> #define EPC_QUIRKS_BAR1_RESERVED  BIT(2)
> #define EPC_QUIRKS_BAR2_RESERVED  BIT(3)
> #define EPC_QUIRKS_BAR3_RESERVED  BIT(4)
> #define EPC_QUIRKS_BAR4_RESERVED  BIT(5)
> #define EPC_QUIRKS_BAR5_RESERVED  BIT(6)
> 
> The controller driver can set the appropriate quirks
> epc->quirks |= EPC_QUIRKS_NO_LINKUP_NOTIFIER | EPC_QUIRKS_BAR0_RESERVED;
> 
> Then pci-epf-test driver can checks the quirks to see the supported EPC 
> features.
> 
> Does something like above looks okay to you?

Well, it is better than the driver_data approach, I would not call them
quirks but features and for the BARs you should define a mask it does
not make sense to enumerate them. It is probably a good idea to leave
room for additional "features" so please choose the bits placement
wisely.

Thanks,
Lorenzo

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

[Lorenzo Pieralisi]

On Thu, May 03, 2018 at 12:03:15PM +0530, Kishon Vijay Abraham I wrote:

[...]

> >> Since the linkup notifier and BAR index (where auxiliary registers are
> >> located) may be configurable and is something platform dependent,
> >> perhaps the configuration of this variables should be done by module
> >> parameter and not by configfs, leaving this configuration
> >> responsibility in charge of each platform.
> > 
> > They are platform dependent because they depend on the EP controller.
> > That's why I said that those are EP controller parameters. I do not
> > think they are module parameters either - they should be part of HW
> > description in firmware.
> 
> The problem is because pci-epf-test cannot be described in HW. pci-epf-test is
> also not automatically bound to the EP controller but is bound by the user 
> like
> below
> ln -s functions/pci_epf_test/func1 controllers/5100.pcie_ep/
> 
> So given that user anyways has to bind the epf device to the controller, based
> on the platform the user can use a different configfs entry like below
> ln -s functions/pci_epf_test_dw/func1 controllers/5100.pcie_ep/ or
> ln -s functions/pci_epf_test_k2g/func1 controllers/2180.pcie-ep/
> 
> If the epf can be described in dt, then something like below can be done
> pcie1_ep: pcie_ep@5100 {
>   compatible = "ti,dra7-pcie-ep";
>   interrupts = <0 232 0x4>;
>   num-lanes = <1>;
>   num-ib-windows = <4>;
>   num-ob-windows = <16>;
>   phys = <_phy>;
>   phy-names = "pcie-phy0";
>   pci_epf_test: pci_epf_test@0 {
>   name = "pci_epf_test_dw";
>   ;
>   }
> };
> 
> With this pci-dra7xx.c driver should create pci_epf_device using
> pci_epf_create("pci_epf_test_dw");
> 
> Then the driver_data corresponding to "pci_epf_test_dw" will select linkup
> notifier or BAR index etc.

Those two properties are properties of the EP controller (it is not 100%
clear to me how the test BAR register is defined), is this correct ?

If yes, given that those properties are not useful before an EPF is
bound to an EPC, can't they be retrieved at bind time from the EPC
controller data (that we can add through DT bindings) ?

Thanks,
Lorenzo

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

[Lorenzo Pieralisi]

On Thu, May 03, 2018 at 12:03:15PM +0530, Kishon Vijay Abraham I wrote:

[...]

> >> Since the linkup notifier and BAR index (where auxiliary registers are
> >> located) may be configurable and is something platform dependent,
> >> perhaps the configuration of this variables should be done by module
> >> parameter and not by configfs, leaving this configuration
> >> responsibility in charge of each platform.
> > 
> > They are platform dependent because they depend on the EP controller.
> > That's why I said that those are EP controller parameters. I do not
> > think they are module parameters either - they should be part of HW
> > description in firmware.
> 
> The problem is because pci-epf-test cannot be described in HW. pci-epf-test is
> also not automatically bound to the EP controller but is bound by the user 
> like
> below
> ln -s functions/pci_epf_test/func1 controllers/5100.pcie_ep/
> 
> So given that user anyways has to bind the epf device to the controller, based
> on the platform the user can use a different configfs entry like below
> ln -s functions/pci_epf_test_dw/func1 controllers/5100.pcie_ep/ or
> ln -s functions/pci_epf_test_k2g/func1 controllers/2180.pcie-ep/
> 
> If the epf can be described in dt, then something like below can be done
> pcie1_ep: pcie_ep@5100 {
>   compatible = "ti,dra7-pcie-ep";
>   interrupts = <0 232 0x4>;
>   num-lanes = <1>;
>   num-ib-windows = <4>;
>   num-ob-windows = <16>;
>   phys = <_phy>;
>   phy-names = "pcie-phy0";
>   pci_epf_test: pci_epf_test@0 {
>   name = "pci_epf_test_dw";
>   ;
>   }
> };
> 
> With this pci-dra7xx.c driver should create pci_epf_device using
> pci_epf_create("pci_epf_test_dw");
> 
> Then the driver_data corresponding to "pci_epf_test_dw" will select linkup
> notifier or BAR index etc.

Those two properties are properties of the EP controller (it is not 100%
clear to me how the test BAR register is defined), is this correct ?

If yes, given that those properties are not useful before an EPF is
bound to an EPC, can't they be retrieved at bind time from the EPC
controller data (that we can add through DT bindings) ?

Thanks,
Lorenzo

Re: [PATCH v8] PCI: hv: Make sure the bus domain is really unique

[Lorenzo Pieralisi]

On Tue, May 01, 2018 at 05:56:32PM +, Sridhar Pitchai wrote:
> When Linux runs as a guest VM in Hyper-V and Hyper-V adds the virtual PCI
> bus to the guest, Hyper-V always provides unique PCI domain.
> 
> commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain")
> overrode unique domain with the serial number of the first device added to
> the virtual PCI bus.
> 
> The reason for that patch was to have a consistent and short name for the
> device, but Hyper-V doesn't provide unique serial numbers. Using non-unique
> serial numbers as domain IDs leads to duplicate device addresses, which
> causes PCI bus registration to fail.
> 
> commit 0c195567a8f6 ("netvsc: transparent VF management") avoids the need
> for commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI
> domain").  When scripts were used to configure VF devices, the name of
> the VF needed to be consistent and short, but with commit 0c195567a8f6
> ("netvsc: transparent VF management") all the setup is done in the kernel,
> and we do not need to maintain consistent name.
> 
> Revert commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI
> domain") so we can reliably support multiple devices being assigned to
> a guest.
> 
> This revert should only be backported to kernels that contain commit
> 0c195567a8f6 ("netvsc: transparent VF management").

I removed this last paragraph, the information is in the stable tag
below.

> Fixes: 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain")
> Signed-off-by: Sridhar Pitchai <sridhar.pitc...@microsoft.com>
> Cc: sta...@vger.kernel.org # v4.14+
> Reviewed-by: Bjorn Helgaas <bhelg...@google.com>
> 
> ---
> Changes in v8:
> * fix the commit comment. [Lorenzo Pieralisi, Bjorn Helgaas]
> ---
>  drivers/pci/host/pci-hyperv.c | 11 ---
>  1 file changed, 11 deletions(-)

Applied to pci/hv for v4.18, thanks.

Lorenzo

> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index 2faf38eab785..ac67e56e451a 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -1518,17 +1518,6 @@ static struct hv_pci_dev *new_pcichild_device(struct 
> hv_pcibus_device *hbus,
>   get_pcichild(hpdev, hv_pcidev_ref_childlist);
>   spin_lock_irqsave(>device_list_lock, flags);
>  
> - /*
> -  * When a device is being added to the bus, we set the PCI domain
> -  * number to be the device serial number, which is non-zero and
> -  * unique on the same VM.  The serial numbers start with 1, and
> -  * increase by 1 for each device.  So device names including this
> -  * can have shorter names than based on the bus instance UUID.
> -  * Only the first device serial number is used for domain, so the
> -  * domain number will not change after the first device is added.
> -  */
> - if (list_empty(>children))
> - hbus->sysdata.domain = desc->ser;
>   list_add_tail(>list_entry, >children);
>   spin_unlock_irqrestore(>device_list_lock, flags);
>   return hpdev;
> -- 
> 2.14.1
> 
> 

Re: [PATCH v8] PCI: hv: Make sure the bus domain is really unique

[Lorenzo Pieralisi]

On Tue, May 01, 2018 at 05:56:32PM +, Sridhar Pitchai wrote:
> When Linux runs as a guest VM in Hyper-V and Hyper-V adds the virtual PCI
> bus to the guest, Hyper-V always provides unique PCI domain.
> 
> commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain")
> overrode unique domain with the serial number of the first device added to
> the virtual PCI bus.
> 
> The reason for that patch was to have a consistent and short name for the
> device, but Hyper-V doesn't provide unique serial numbers. Using non-unique
> serial numbers as domain IDs leads to duplicate device addresses, which
> causes PCI bus registration to fail.
> 
> commit 0c195567a8f6 ("netvsc: transparent VF management") avoids the need
> for commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI
> domain").  When scripts were used to configure VF devices, the name of
> the VF needed to be consistent and short, but with commit 0c195567a8f6
> ("netvsc: transparent VF management") all the setup is done in the kernel,
> and we do not need to maintain consistent name.
> 
> Revert commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI
> domain") so we can reliably support multiple devices being assigned to
> a guest.
> 
> This revert should only be backported to kernels that contain commit
> 0c195567a8f6 ("netvsc: transparent VF management").

I removed this last paragraph, the information is in the stable tag
below.

> Fixes: 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain")
> Signed-off-by: Sridhar Pitchai 
> Cc: sta...@vger.kernel.org # v4.14+
> Reviewed-by: Bjorn Helgaas 
> 
> ---
> Changes in v8:
> * fix the commit comment. [Lorenzo Pieralisi, Bjorn Helgaas]
> ---
>  drivers/pci/host/pci-hyperv.c | 11 ---
>  1 file changed, 11 deletions(-)

Applied to pci/hv for v4.18, thanks.

Lorenzo

> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index 2faf38eab785..ac67e56e451a 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -1518,17 +1518,6 @@ static struct hv_pci_dev *new_pcichild_device(struct 
> hv_pcibus_device *hbus,
>   get_pcichild(hpdev, hv_pcidev_ref_childlist);
>   spin_lock_irqsave(>device_list_lock, flags);
>  
> - /*
> -  * When a device is being added to the bus, we set the PCI domain
> -  * number to be the device serial number, which is non-zero and
> -  * unique on the same VM.  The serial numbers start with 1, and
> -  * increase by 1 for each device.  So device names including this
> -  * can have shorter names than based on the bus instance UUID.
> -  * Only the first device serial number is used for domain, so the
> -  * domain number will not change after the first device is added.
> -  */
> - if (list_empty(>children))
> - hbus->sysdata.domain = desc->ser;
>   list_add_tail(>list_entry, >children);
>   spin_unlock_irqrestore(>device_list_lock, flags);
>   return hpdev;
> -- 
> 2.14.1
> 
> 

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

[Lorenzo Pieralisi]

On Wed, May 02, 2018 at 11:39:00AM +0100, Gustavo Pimentel wrote:
> Hi Lorenzo,
> 
> On 01/05/2018 15:26, Lorenzo Pieralisi wrote:
> > On Tue, May 01, 2018 at 05:53:59PM +0530, Kishon Vijay Abraham I wrote:
> >> Hi Lorenzo,
> >>
> >> On Tuesday 01 May 2018 05:24 PM, Lorenzo Pieralisi wrote:
> >>> On Tue, May 01, 2018 at 03:37:47PM +0530, Kishon Vijay Abraham I wrote:
> >>>> Hi Lorenzo,
> >>>>
> >>>> On Thursday 26 April 2018 10:26 PM, Lorenzo Pieralisi wrote:
> >>>>> On Tue, Apr 24, 2018 at 02:44:40PM +0100, Gustavo Pimentel wrote:
> >>>>>> Adds a seconds entry on the pci_epf_test_ids structure that disables 
> >>>>>> the
> >>>>>
> >>>>> "Add a second entry to..."
> >>>>>
> >>>>>> linkup_notifier parameter on driver for the designware EP.
> >>>>>>
> >>>>>> This allows designware EPs that doesn't have linkup notification signal
> >>>>>> to work with pcitest.
> >>>>>>
> >>>>>> Updates the binding documentation accordingly.
> >>>>>
> >>>>> Valid for all the series: use imperative sentences.
> >>>>>
> >>>>> eg:
> >>>>>
> >>>>> "Update the binding documentation accordingly".
> >>>>>
> >>>>> not
> >>>>>
> >>>>> "Updates the binding documentation accordingly".
> >>>>>
> >>>>>> Signed-off-by: Gustavo Pimentel <gustavo.pimen...@synopsys.com>
> >>>>>> Acked-by: Kishon Vijay Abraham I <kis...@ti.com>
> >>>>>> ---
> >>>>>> Change v2->v3:
> >>>>>>  - Added second entry in pci_epf_test_ids structure.
> >>>>>>  - Remove test_reg_bar field assignment on second entry.
> >>>>>> Changes v3->v4:
> >>>>>>  - Nothing changed, just to follow the patch set version.
> >>>>>> Changes v4->v5:
> >>>>>>  - Changed pci_epf_test_cfg2 to pci_epf_test_designware.
> >>>>>> Changes v5->v6:
> >>>>>>  - Changed name field from pci_epf_test_designware to pci_epf_test_dw.
> >>>>>> Changes v6->v7:
> >>>>>>  - Changed variable name from data_cfg2 to 
> >>>>>> data_linkup_notifier_disabled.
> >>>>>>
> >>>>>>  Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++
> >>>>>>  drivers/pci/endpoint/functions/pci-epf-test.c| 8 
> >>>>>>  2 files changed, 10 insertions(+)
> >>>>>>
> >>>>>> diff --git a/Documentation/PCI/endpoint/function/binding/pci-test.txt 
> >>>>>> b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >>>>>> index 3b68b95..dc39f47 100644
> >>>>>> --- a/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >>>>>> +++ b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >>>>>> @@ -1,6 +1,8 @@
> >>>>>>  PCI TEST ENDPOINT FUNCTION
> >>>>>>  
> >>>>>>  name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
> >>>>>> +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver
> >>>>>> +  with a custom configuration for the designware EP.
> >>>>>
> >>>>> The link between the "name" and the device created is quite obscure and
> >>>>> reading pci-test-howto.txt certainly does not clarify it.
> >>>>>
> >>>>> In pci-test-howto.txt an explanation should be added to the configs
> >>>>> device creation paragraph to clarify it.
> >>>>>
> >>>>>>  Configurable Fields:
> >>>>>>  vendorid   : should be 0x104c
> >>>>>> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> >>>>>> b/drivers/pci/endpoint/functions/pci-epf-test.c
> >>>>>> index 7cef851..4ab463b 100644
> >>>>>> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> >>>>>> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> >>>>>> @@ -459,10 +459,18 @@ static

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

[Lorenzo Pieralisi]

On Wed, May 02, 2018 at 11:39:00AM +0100, Gustavo Pimentel wrote:
> Hi Lorenzo,
> 
> On 01/05/2018 15:26, Lorenzo Pieralisi wrote:
> > On Tue, May 01, 2018 at 05:53:59PM +0530, Kishon Vijay Abraham I wrote:
> >> Hi Lorenzo,
> >>
> >> On Tuesday 01 May 2018 05:24 PM, Lorenzo Pieralisi wrote:
> >>> On Tue, May 01, 2018 at 03:37:47PM +0530, Kishon Vijay Abraham I wrote:
> >>>> Hi Lorenzo,
> >>>>
> >>>> On Thursday 26 April 2018 10:26 PM, Lorenzo Pieralisi wrote:
> >>>>> On Tue, Apr 24, 2018 at 02:44:40PM +0100, Gustavo Pimentel wrote:
> >>>>>> Adds a seconds entry on the pci_epf_test_ids structure that disables 
> >>>>>> the
> >>>>>
> >>>>> "Add a second entry to..."
> >>>>>
> >>>>>> linkup_notifier parameter on driver for the designware EP.
> >>>>>>
> >>>>>> This allows designware EPs that doesn't have linkup notification signal
> >>>>>> to work with pcitest.
> >>>>>>
> >>>>>> Updates the binding documentation accordingly.
> >>>>>
> >>>>> Valid for all the series: use imperative sentences.
> >>>>>
> >>>>> eg:
> >>>>>
> >>>>> "Update the binding documentation accordingly".
> >>>>>
> >>>>> not
> >>>>>
> >>>>> "Updates the binding documentation accordingly".
> >>>>>
> >>>>>> Signed-off-by: Gustavo Pimentel 
> >>>>>> Acked-by: Kishon Vijay Abraham I 
> >>>>>> ---
> >>>>>> Change v2->v3:
> >>>>>>  - Added second entry in pci_epf_test_ids structure.
> >>>>>>  - Remove test_reg_bar field assignment on second entry.
> >>>>>> Changes v3->v4:
> >>>>>>  - Nothing changed, just to follow the patch set version.
> >>>>>> Changes v4->v5:
> >>>>>>  - Changed pci_epf_test_cfg2 to pci_epf_test_designware.
> >>>>>> Changes v5->v6:
> >>>>>>  - Changed name field from pci_epf_test_designware to pci_epf_test_dw.
> >>>>>> Changes v6->v7:
> >>>>>>  - Changed variable name from data_cfg2 to 
> >>>>>> data_linkup_notifier_disabled.
> >>>>>>
> >>>>>>  Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++
> >>>>>>  drivers/pci/endpoint/functions/pci-epf-test.c| 8 
> >>>>>>  2 files changed, 10 insertions(+)
> >>>>>>
> >>>>>> diff --git a/Documentation/PCI/endpoint/function/binding/pci-test.txt 
> >>>>>> b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >>>>>> index 3b68b95..dc39f47 100644
> >>>>>> --- a/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >>>>>> +++ b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >>>>>> @@ -1,6 +1,8 @@
> >>>>>>  PCI TEST ENDPOINT FUNCTION
> >>>>>>  
> >>>>>>  name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
> >>>>>> +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver
> >>>>>> +  with a custom configuration for the designware EP.
> >>>>>
> >>>>> The link between the "name" and the device created is quite obscure and
> >>>>> reading pci-test-howto.txt certainly does not clarify it.
> >>>>>
> >>>>> In pci-test-howto.txt an explanation should be added to the configs
> >>>>> device creation paragraph to clarify it.
> >>>>>
> >>>>>>  Configurable Fields:
> >>>>>>  vendorid   : should be 0x104c
> >>>>>> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> >>>>>> b/drivers/pci/endpoint/functions/pci-epf-test.c
> >>>>>> index 7cef851..4ab463b 100644
> >>>>>> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> >>>>>> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> >>>>>> @@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)
> >>&

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

[Lorenzo Pieralisi]

On Tue, May 01, 2018 at 05:53:59PM +0530, Kishon Vijay Abraham I wrote:
> Hi Lorenzo,
> 
> On Tuesday 01 May 2018 05:24 PM, Lorenzo Pieralisi wrote:
> > On Tue, May 01, 2018 at 03:37:47PM +0530, Kishon Vijay Abraham I wrote:
> >> Hi Lorenzo,
> >>
> >> On Thursday 26 April 2018 10:26 PM, Lorenzo Pieralisi wrote:
> >>> On Tue, Apr 24, 2018 at 02:44:40PM +0100, Gustavo Pimentel wrote:
> >>>> Adds a seconds entry on the pci_epf_test_ids structure that disables the
> >>>
> >>> "Add a second entry to..."
> >>>
> >>>> linkup_notifier parameter on driver for the designware EP.
> >>>>
> >>>> This allows designware EPs that doesn't have linkup notification signal
> >>>> to work with pcitest.
> >>>>
> >>>> Updates the binding documentation accordingly.
> >>>
> >>> Valid for all the series: use imperative sentences.
> >>>
> >>> eg:
> >>>
> >>> "Update the binding documentation accordingly".
> >>>
> >>> not
> >>>
> >>> "Updates the binding documentation accordingly".
> >>>
> >>>> Signed-off-by: Gustavo Pimentel <gustavo.pimen...@synopsys.com>
> >>>> Acked-by: Kishon Vijay Abraham I <kis...@ti.com>
> >>>> ---
> >>>> Change v2->v3:
> >>>>  - Added second entry in pci_epf_test_ids structure.
> >>>>  - Remove test_reg_bar field assignment on second entry.
> >>>> Changes v3->v4:
> >>>>  - Nothing changed, just to follow the patch set version.
> >>>> Changes v4->v5:
> >>>>  - Changed pci_epf_test_cfg2 to pci_epf_test_designware.
> >>>> Changes v5->v6:
> >>>>  - Changed name field from pci_epf_test_designware to pci_epf_test_dw.
> >>>> Changes v6->v7:
> >>>>  - Changed variable name from data_cfg2 to data_linkup_notifier_disabled.
> >>>>
> >>>>  Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++
> >>>>  drivers/pci/endpoint/functions/pci-epf-test.c| 8 
> >>>>  2 files changed, 10 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/PCI/endpoint/function/binding/pci-test.txt 
> >>>> b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >>>> index 3b68b95..dc39f47 100644
> >>>> --- a/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >>>> +++ b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >>>> @@ -1,6 +1,8 @@
> >>>>  PCI TEST ENDPOINT FUNCTION
> >>>>  
> >>>>  name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
> >>>> +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver
> >>>> +  with a custom configuration for the designware EP.
> >>>
> >>> The link between the "name" and the device created is quite obscure and
> >>> reading pci-test-howto.txt certainly does not clarify it.
> >>>
> >>> In pci-test-howto.txt an explanation should be added to the configs
> >>> device creation paragraph to clarify it.
> >>>
> >>>>  Configurable Fields:
> >>>>  vendorid : should be 0x104c
> >>>> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> >>>> b/drivers/pci/endpoint/functions/pci-epf-test.c
> >>>> index 7cef851..4ab463b 100644
> >>>> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> >>>> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> >>>> @@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)
> >>>>  return 0;
> >>>>  }
> >>>>  
> >>>> +static const struct pci_epf_test_data data_linkup_notifier_disabled = {
> >>>> +.linkup_notifier = false
> >>>> +};
> >>>> +
> >>>>  static const struct pci_epf_device_id pci_epf_test_ids[] = {
> >>>>  {
> >>>>  .name = "pci_epf_test",
> >>>>  },
> >>>> +{
> >>>> +.name = "pci_epf_test_dw",
> >>>> +.driver_data = 
> >>>> (kernel_ulong_t)_linkup_notifier_disabled,
> >>>>

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

[Lorenzo Pieralisi]

On Tue, May 01, 2018 at 05:53:59PM +0530, Kishon Vijay Abraham I wrote:
> Hi Lorenzo,
> 
> On Tuesday 01 May 2018 05:24 PM, Lorenzo Pieralisi wrote:
> > On Tue, May 01, 2018 at 03:37:47PM +0530, Kishon Vijay Abraham I wrote:
> >> Hi Lorenzo,
> >>
> >> On Thursday 26 April 2018 10:26 PM, Lorenzo Pieralisi wrote:
> >>> On Tue, Apr 24, 2018 at 02:44:40PM +0100, Gustavo Pimentel wrote:
> >>>> Adds a seconds entry on the pci_epf_test_ids structure that disables the
> >>>
> >>> "Add a second entry to..."
> >>>
> >>>> linkup_notifier parameter on driver for the designware EP.
> >>>>
> >>>> This allows designware EPs that doesn't have linkup notification signal
> >>>> to work with pcitest.
> >>>>
> >>>> Updates the binding documentation accordingly.
> >>>
> >>> Valid for all the series: use imperative sentences.
> >>>
> >>> eg:
> >>>
> >>> "Update the binding documentation accordingly".
> >>>
> >>> not
> >>>
> >>> "Updates the binding documentation accordingly".
> >>>
> >>>> Signed-off-by: Gustavo Pimentel 
> >>>> Acked-by: Kishon Vijay Abraham I 
> >>>> ---
> >>>> Change v2->v3:
> >>>>  - Added second entry in pci_epf_test_ids structure.
> >>>>  - Remove test_reg_bar field assignment on second entry.
> >>>> Changes v3->v4:
> >>>>  - Nothing changed, just to follow the patch set version.
> >>>> Changes v4->v5:
> >>>>  - Changed pci_epf_test_cfg2 to pci_epf_test_designware.
> >>>> Changes v5->v6:
> >>>>  - Changed name field from pci_epf_test_designware to pci_epf_test_dw.
> >>>> Changes v6->v7:
> >>>>  - Changed variable name from data_cfg2 to data_linkup_notifier_disabled.
> >>>>
> >>>>  Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++
> >>>>  drivers/pci/endpoint/functions/pci-epf-test.c| 8 
> >>>>  2 files changed, 10 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/PCI/endpoint/function/binding/pci-test.txt 
> >>>> b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >>>> index 3b68b95..dc39f47 100644
> >>>> --- a/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >>>> +++ b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >>>> @@ -1,6 +1,8 @@
> >>>>  PCI TEST ENDPOINT FUNCTION
> >>>>  
> >>>>  name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
> >>>> +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver
> >>>> +  with a custom configuration for the designware EP.
> >>>
> >>> The link between the "name" and the device created is quite obscure and
> >>> reading pci-test-howto.txt certainly does not clarify it.
> >>>
> >>> In pci-test-howto.txt an explanation should be added to the configs
> >>> device creation paragraph to clarify it.
> >>>
> >>>>  Configurable Fields:
> >>>>  vendorid : should be 0x104c
> >>>> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> >>>> b/drivers/pci/endpoint/functions/pci-epf-test.c
> >>>> index 7cef851..4ab463b 100644
> >>>> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> >>>> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> >>>> @@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)
> >>>>  return 0;
> >>>>  }
> >>>>  
> >>>> +static const struct pci_epf_test_data data_linkup_notifier_disabled = {
> >>>> +.linkup_notifier = false
> >>>> +};
> >>>> +
> >>>>  static const struct pci_epf_device_id pci_epf_test_ids[] = {
> >>>>  {
> >>>>  .name = "pci_epf_test",
> >>>>  },
> >>>> +{
> >>>> +.name = "pci_epf_test_dw",
> >>>> +.driver_data = 
> >>>> (kernel_ulong_t)_linkup_notifier_disabled,
> >>>> +},
> >>>>  {},
> >&g

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

[Lorenzo Pieralisi]

On Tue, May 01, 2018 at 03:37:47PM +0530, Kishon Vijay Abraham I wrote:
> Hi Lorenzo,
> 
> On Thursday 26 April 2018 10:26 PM, Lorenzo Pieralisi wrote:
> > On Tue, Apr 24, 2018 at 02:44:40PM +0100, Gustavo Pimentel wrote:
> >> Adds a seconds entry on the pci_epf_test_ids structure that disables the
> > 
> > "Add a second entry to..."
> > 
> >> linkup_notifier parameter on driver for the designware EP.
> >>
> >> This allows designware EPs that doesn't have linkup notification signal
> >> to work with pcitest.
> >>
> >> Updates the binding documentation accordingly.
> > 
> > Valid for all the series: use imperative sentences.
> > 
> > eg:
> > 
> > "Update the binding documentation accordingly".
> > 
> > not
> > 
> > "Updates the binding documentation accordingly".
> > 
> >> Signed-off-by: Gustavo Pimentel <gustavo.pimen...@synopsys.com>
> >> Acked-by: Kishon Vijay Abraham I <kis...@ti.com>
> >> ---
> >> Change v2->v3:
> >>  - Added second entry in pci_epf_test_ids structure.
> >>  - Remove test_reg_bar field assignment on second entry.
> >> Changes v3->v4:
> >>  - Nothing changed, just to follow the patch set version.
> >> Changes v4->v5:
> >>  - Changed pci_epf_test_cfg2 to pci_epf_test_designware.
> >> Changes v5->v6:
> >>  - Changed name field from pci_epf_test_designware to pci_epf_test_dw.
> >> Changes v6->v7:
> >>  - Changed variable name from data_cfg2 to data_linkup_notifier_disabled.
> >>
> >>  Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++
> >>  drivers/pci/endpoint/functions/pci-epf-test.c| 8 
> >>  2 files changed, 10 insertions(+)
> >>
> >> diff --git a/Documentation/PCI/endpoint/function/binding/pci-test.txt 
> >> b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >> index 3b68b95..dc39f47 100644
> >> --- a/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >> +++ b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >> @@ -1,6 +1,8 @@
> >>  PCI TEST ENDPOINT FUNCTION
> >>  
> >>  name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
> >> +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver
> >> +  with a custom configuration for the designware EP.
> > 
> > The link between the "name" and the device created is quite obscure and
> > reading pci-test-howto.txt certainly does not clarify it.
> > 
> > In pci-test-howto.txt an explanation should be added to the configs
> > device creation paragraph to clarify it.
> > 
> >>  Configurable Fields:
> >>  vendorid   : should be 0x104c
> >> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> >> b/drivers/pci/endpoint/functions/pci-epf-test.c
> >> index 7cef851..4ab463b 100644
> >> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> >> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> >> @@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)
> >>return 0;
> >>  }
> >>  
> >> +static const struct pci_epf_test_data data_linkup_notifier_disabled = {
> >> +  .linkup_notifier = false
> >> +};
> >> +
> >>  static const struct pci_epf_device_id pci_epf_test_ids[] = {
> >>{
> >>.name = "pci_epf_test",
> >>},
> >> +  {
> >> +  .name = "pci_epf_test_dw",
> >> +  .driver_data = (kernel_ulong_t)_linkup_notifier_disabled,
> >> +  },
> >>{},
> > 
> > Should not this be a property derived from the controller compatible
> > property instead of the test device name written in configfs ?
> 
> pci_epf_test is an independent driver on its own that operates in a layer 
> above
> the controller driver. So it does not get the controller compatible (which is
> used in controller drivers like pcie-designware-plat.c). pci_epf_test uses
> "pci_epf_device_id" which is _similar_ to "of_device_id" used by platform 
> drivers.

I understand that, the problem is that the independent driver depends on
features of the related controller driver as this patch shows. This
patch basically says that if you use a specific path in configfs (that
includes pci_epf_test_dw) your device has specific HW features (eg
linkup notifier above), that obviously depends on the platform HW not on
the string you use in configfs.

What I am questioning is a) if I understand this right and b) whether
this is the right approach.

Lorenzo

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

[Lorenzo Pieralisi]

On Tue, May 01, 2018 at 03:37:47PM +0530, Kishon Vijay Abraham I wrote:
> Hi Lorenzo,
> 
> On Thursday 26 April 2018 10:26 PM, Lorenzo Pieralisi wrote:
> > On Tue, Apr 24, 2018 at 02:44:40PM +0100, Gustavo Pimentel wrote:
> >> Adds a seconds entry on the pci_epf_test_ids structure that disables the
> > 
> > "Add a second entry to..."
> > 
> >> linkup_notifier parameter on driver for the designware EP.
> >>
> >> This allows designware EPs that doesn't have linkup notification signal
> >> to work with pcitest.
> >>
> >> Updates the binding documentation accordingly.
> > 
> > Valid for all the series: use imperative sentences.
> > 
> > eg:
> > 
> > "Update the binding documentation accordingly".
> > 
> > not
> > 
> > "Updates the binding documentation accordingly".
> > 
> >> Signed-off-by: Gustavo Pimentel 
> >> Acked-by: Kishon Vijay Abraham I 
> >> ---
> >> Change v2->v3:
> >>  - Added second entry in pci_epf_test_ids structure.
> >>  - Remove test_reg_bar field assignment on second entry.
> >> Changes v3->v4:
> >>  - Nothing changed, just to follow the patch set version.
> >> Changes v4->v5:
> >>  - Changed pci_epf_test_cfg2 to pci_epf_test_designware.
> >> Changes v5->v6:
> >>  - Changed name field from pci_epf_test_designware to pci_epf_test_dw.
> >> Changes v6->v7:
> >>  - Changed variable name from data_cfg2 to data_linkup_notifier_disabled.
> >>
> >>  Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++
> >>  drivers/pci/endpoint/functions/pci-epf-test.c| 8 
> >>  2 files changed, 10 insertions(+)
> >>
> >> diff --git a/Documentation/PCI/endpoint/function/binding/pci-test.txt 
> >> b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >> index 3b68b95..dc39f47 100644
> >> --- a/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >> +++ b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> >> @@ -1,6 +1,8 @@
> >>  PCI TEST ENDPOINT FUNCTION
> >>  
> >>  name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
> >> +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver
> >> +  with a custom configuration for the designware EP.
> > 
> > The link between the "name" and the device created is quite obscure and
> > reading pci-test-howto.txt certainly does not clarify it.
> > 
> > In pci-test-howto.txt an explanation should be added to the configs
> > device creation paragraph to clarify it.
> > 
> >>  Configurable Fields:
> >>  vendorid   : should be 0x104c
> >> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> >> b/drivers/pci/endpoint/functions/pci-epf-test.c
> >> index 7cef851..4ab463b 100644
> >> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> >> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> >> @@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)
> >>return 0;
> >>  }
> >>  
> >> +static const struct pci_epf_test_data data_linkup_notifier_disabled = {
> >> +  .linkup_notifier = false
> >> +};
> >> +
> >>  static const struct pci_epf_device_id pci_epf_test_ids[] = {
> >>{
> >>.name = "pci_epf_test",
> >>},
> >> +  {
> >> +  .name = "pci_epf_test_dw",
> >> +  .driver_data = (kernel_ulong_t)_linkup_notifier_disabled,
> >> +  },
> >>{},
> > 
> > Should not this be a property derived from the controller compatible
> > property instead of the test device name written in configfs ?
> 
> pci_epf_test is an independent driver on its own that operates in a layer 
> above
> the controller driver. So it does not get the controller compatible (which is
> used in controller drivers like pcie-designware-plat.c). pci_epf_test uses
> "pci_epf_device_id" which is _similar_ to "of_device_id" used by platform 
> drivers.

I understand that, the problem is that the independent driver depends on
features of the related controller driver as this patch shows. This
patch basically says that if you use a specific path in configfs (that
includes pci_epf_test_dw) your device has specific HW features (eg
linkup notifier above), that obviously depends on the platform HW not on
the string you use in configfs.

What I am questioning is a) if I understand this right and b) whether
this is the right approach.

Lorenzo

Re: [PATCH v8 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

[Lorenzo Pieralisi]

On Fri, Apr 27, 2018 at 12:59:58PM +0100, Gustavo Pimentel wrote:
> Add a seconds entry on the pci_epf_test_ids structure that disables the

"Add a second entry..."

> linkup_notifier parameter on driver for the DesignWare EP.
> 
> Allow DesignWare EPs that doesn't have linkup notification signal to work
> with pcitest.
> 
> Update the binding documentation accordingly.
> 
> Signed-off-by: Gustavo Pimentel 
> Acked-by: Kishon Vijay Abraham I 
> ---
> Change v2->v3:
>  - Added second entry in pci_epf_test_ids structure.
>  - Remove test_reg_bar field assignment on second entry.
> Changes v3->v4:
>  - Nothing changed, just to follow the patch set version.
> Changes v4->v5:
>  - Changed pci_epf_test_cfg2 to pci_epf_test_designware.
> Changes v5->v6:
>  - Changed name field from pci_epf_test_designware to pci_epf_test_dw.
> Changes v6->v7:
>  - Changed variable name from data_cfg2 to data_linkup_notifier_disabled.
> Changes v7->v8:
>  - Patch description rework for an imperative verbal mode.
> 
>  Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++
>  drivers/pci/endpoint/functions/pci-epf-test.c| 8 
>  2 files changed, 10 insertions(+)
> 
> diff --git a/Documentation/PCI/endpoint/function/binding/pci-test.txt 
> b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> index 3b68b95..dc39f47 100644
> --- a/Documentation/PCI/endpoint/function/binding/pci-test.txt
> +++ b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> @@ -1,6 +1,8 @@
>  PCI TEST ENDPOINT FUNCTION
>  
>  name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
> +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver
> +  with a custom configuration for the designware EP.
>  
>  Configurable Fields:
>  vendorid  : should be 0x104c
> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> b/drivers/pci/endpoint/functions/pci-epf-test.c
> index 7cef851..4ab463b 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)
>   return 0;
>  }
>  
> +static const struct pci_epf_test_data data_linkup_notifier_disabled = {
> + .linkup_notifier = false
> +};
> +
>  static const struct pci_epf_device_id pci_epf_test_ids[] = {
>   {
>   .name = "pci_epf_test",
>   },
> + {
> + .name = "pci_epf_test_dw",
> + .driver_data = (kernel_ulong_t)_linkup_notifier_disabled,

You have not answered my question on this though:

https://marc.info/?l=linux-pci=152476180723047=2

> + },
>   {},
>  };
>  
> -- 
> 2.7.4
> 
> 

Re: [PATCH v8 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

[Lorenzo Pieralisi]

On Fri, Apr 27, 2018 at 12:59:58PM +0100, Gustavo Pimentel wrote:
> Add a seconds entry on the pci_epf_test_ids structure that disables the

"Add a second entry..."

> linkup_notifier parameter on driver for the DesignWare EP.
> 
> Allow DesignWare EPs that doesn't have linkup notification signal to work
> with pcitest.
> 
> Update the binding documentation accordingly.
> 
> Signed-off-by: Gustavo Pimentel 
> Acked-by: Kishon Vijay Abraham I 
> ---
> Change v2->v3:
>  - Added second entry in pci_epf_test_ids structure.
>  - Remove test_reg_bar field assignment on second entry.
> Changes v3->v4:
>  - Nothing changed, just to follow the patch set version.
> Changes v4->v5:
>  - Changed pci_epf_test_cfg2 to pci_epf_test_designware.
> Changes v5->v6:
>  - Changed name field from pci_epf_test_designware to pci_epf_test_dw.
> Changes v6->v7:
>  - Changed variable name from data_cfg2 to data_linkup_notifier_disabled.
> Changes v7->v8:
>  - Patch description rework for an imperative verbal mode.
> 
>  Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++
>  drivers/pci/endpoint/functions/pci-epf-test.c| 8 
>  2 files changed, 10 insertions(+)
> 
> diff --git a/Documentation/PCI/endpoint/function/binding/pci-test.txt 
> b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> index 3b68b95..dc39f47 100644
> --- a/Documentation/PCI/endpoint/function/binding/pci-test.txt
> +++ b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> @@ -1,6 +1,8 @@
>  PCI TEST ENDPOINT FUNCTION
>  
>  name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
> +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver
> +  with a custom configuration for the designware EP.
>  
>  Configurable Fields:
>  vendorid  : should be 0x104c
> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> b/drivers/pci/endpoint/functions/pci-epf-test.c
> index 7cef851..4ab463b 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)
>   return 0;
>  }
>  
> +static const struct pci_epf_test_data data_linkup_notifier_disabled = {
> + .linkup_notifier = false
> +};
> +
>  static const struct pci_epf_device_id pci_epf_test_ids[] = {
>   {
>   .name = "pci_epf_test",
>   },
> + {
> + .name = "pci_epf_test_dw",
> + .driver_data = (kernel_ulong_t)_linkup_notifier_disabled,

You have not answered my question on this though:

https://marc.info/?l=linux-pci=152476180723047=2

> + },
>   {},
>  };
>  
> -- 
> 2.7.4
> 
> 

Re: [PATCH] arm64: skip cpu nodes marked as disabled in DT

[Lorenzo Pieralisi]

On Thu, Apr 26, 2018 at 07:54:06PM +, Rohit Khanna wrote:
> Thanks Lorenzo for pulling out the old thread.
> 
> So just to make sure my understanding is correct from the discussion
> on that thread, below is not a preferred approach.
> 
> "If CPUs are marked as disabled in the devicetree, make sure they do
> not exist in the system CPU information and CPU topology information."
> 
> 
> The reason is because - "The meaning of disabled for cpus in ePAPR is
> that the cpu is offline (i.e. in a spinloop or wfi), not that the cpu
> is unavailable."
> 
> 
> Preferred approach is -
> "Since with this approach the DT should change anyway if on different
> >hardware devices based on the same chip you want to allow booting a
> >different number of CPUs, why do not we remove the cpu nodes instead of
> >disabling them"

Yes, I think that's the best course of action and it was the outcome
of that email thread.

Lorenzo

> Thanks
> Rohit
> 
> From: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
> Sent: Thursday, April 26, 2018 3:18 AM
> To: Catalin Marinas; Rohit Khanna
> Cc: will.dea...@arm.com; linux-kernel@vger.kernel.org; Thierry Reding; 
> Alexander Van Brunt; Bo Yan; Jason Sequeira; Mark Rutland
> Subject: Re: [PATCH] arm64: skip cpu nodes marked as disabled in DT
> 
> On Thu, Apr 26, 2018 at 08:25:14AM +0100, Catalin Marinas wrote:
> > On Wed, Apr 25, 2018 at 11:36:06PM +, Rohit Khanna wrote:
> > > Adding few other folks.
> >
> > It looks fine to me but cc'ing Mark and Lorenzo (and it should have been
> > posted on linux-arm-ker...@lists.infradead.org).
> >
> > > From: Rohit Khanna
> > > Sent: Wednesday, April 25, 2018 4:08 PM
> > > To: catalin.mari...@arm.com; will.dea...@arm.com
> > > Cc: linux-kernel@vger.kernel.org; Rohit Khanna
> > > Subject: [PATCH] arm64: skip cpu nodes marked as disabled in DT
> > >
> > > Skip the CPU nodes that are marked as disabled in DT.
> > >
> > > Bug 1828570
> 
> That's not information that can be used in its current form, which
> bug-tracking system ?
> 
> > > Signed-off-by: Rohit Khanna <rokha...@nvidia.com>
> > > Reviewed-on: http://git-master/r/1245333
> 
> If it is a public mailing list discussion the
> 
> Link:
> 
> tag and the lkml redirector should be used, I do not know what the
> redirector used here is though.
> 
> Process is defined here:
> 
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> 
> > > Reviewed-by: Alexander Van Brunt <avanbr...@nvidia.com>
> > > ---
> > >  arch/arm64/kernel/smp.c | 4 
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> > > index f3e2e3aec0b0..2b4371b0948d 100644
> > > --- a/arch/arm64/kernel/smp.c
> > > +++ b/arch/arm64/kernel/smp.c
> > > @@ -578,6 +578,10 @@ static void __init of_parse_and_init_cpus(void)
> > > for_each_node_by_type(dn, "cpu") {
> > > u64 hwid = of_get_cpu_mpidr(dn);
> > >
> > > +   /* Check to see if the cpu is disabled */
> > > +   if (!of_device_is_available(dn))
> > > +   goto next;
> > > +
> 
> This was discussed a long time ago and kind of dropped - I digged the
> thread out of archives for everyone's information:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/174324.html
> 
> Lorenzo

Re: [PATCH] arm64: skip cpu nodes marked as disabled in DT

[Lorenzo Pieralisi]

On Thu, Apr 26, 2018 at 07:54:06PM +, Rohit Khanna wrote:
> Thanks Lorenzo for pulling out the old thread.
> 
> So just to make sure my understanding is correct from the discussion
> on that thread, below is not a preferred approach.
> 
> "If CPUs are marked as disabled in the devicetree, make sure they do
> not exist in the system CPU information and CPU topology information."
> 
> 
> The reason is because - "The meaning of disabled for cpus in ePAPR is
> that the cpu is offline (i.e. in a spinloop or wfi), not that the cpu
> is unavailable."
> 
> 
> Preferred approach is -
> "Since with this approach the DT should change anyway if on different
> >hardware devices based on the same chip you want to allow booting a
> >different number of CPUs, why do not we remove the cpu nodes instead of
> >disabling them"

Yes, I think that's the best course of action and it was the outcome
of that email thread.

Lorenzo

> Thanks
> Rohit
> 
> From: Lorenzo Pieralisi 
> Sent: Thursday, April 26, 2018 3:18 AM
> To: Catalin Marinas; Rohit Khanna
> Cc: will.dea...@arm.com; linux-kernel@vger.kernel.org; Thierry Reding; 
> Alexander Van Brunt; Bo Yan; Jason Sequeira; Mark Rutland
> Subject: Re: [PATCH] arm64: skip cpu nodes marked as disabled in DT
> 
> On Thu, Apr 26, 2018 at 08:25:14AM +0100, Catalin Marinas wrote:
> > On Wed, Apr 25, 2018 at 11:36:06PM +, Rohit Khanna wrote:
> > > Adding few other folks.
> >
> > It looks fine to me but cc'ing Mark and Lorenzo (and it should have been
> > posted on linux-arm-ker...@lists.infradead.org).
> >
> > > From: Rohit Khanna
> > > Sent: Wednesday, April 25, 2018 4:08 PM
> > > To: catalin.mari...@arm.com; will.dea...@arm.com
> > > Cc: linux-kernel@vger.kernel.org; Rohit Khanna
> > > Subject: [PATCH] arm64: skip cpu nodes marked as disabled in DT
> > >
> > > Skip the CPU nodes that are marked as disabled in DT.
> > >
> > > Bug 1828570
> 
> That's not information that can be used in its current form, which
> bug-tracking system ?
> 
> > > Signed-off-by: Rohit Khanna 
> > > Reviewed-on: http://git-master/r/1245333
> 
> If it is a public mailing list discussion the
> 
> Link:
> 
> tag and the lkml redirector should be used, I do not know what the
> redirector used here is though.
> 
> Process is defined here:
> 
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> 
> > > Reviewed-by: Alexander Van Brunt 
> > > ---
> > >  arch/arm64/kernel/smp.c | 4 
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> > > index f3e2e3aec0b0..2b4371b0948d 100644
> > > --- a/arch/arm64/kernel/smp.c
> > > +++ b/arch/arm64/kernel/smp.c
> > > @@ -578,6 +578,10 @@ static void __init of_parse_and_init_cpus(void)
> > > for_each_node_by_type(dn, "cpu") {
> > > u64 hwid = of_get_cpu_mpidr(dn);
> > >
> > > +   /* Check to see if the cpu is disabled */
> > > +   if (!of_device_is_available(dn))
> > > +   goto next;
> > > +
> 
> This was discussed a long time ago and kind of dropped - I digged the
> thread out of archives for everyone's information:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/174324.html
> 
> Lorenzo

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

[Lorenzo Pieralisi]

On Tue, Apr 24, 2018 at 02:44:40PM +0100, Gustavo Pimentel wrote:
> Adds a seconds entry on the pci_epf_test_ids structure that disables the

"Add a second entry to..."

> linkup_notifier parameter on driver for the designware EP.
> 
> This allows designware EPs that doesn't have linkup notification signal
> to work with pcitest.
> 
> Updates the binding documentation accordingly.

Valid for all the series: use imperative sentences.

eg:

"Update the binding documentation accordingly".

not

"Updates the binding documentation accordingly".

> Signed-off-by: Gustavo Pimentel 
> Acked-by: Kishon Vijay Abraham I 
> ---
> Change v2->v3:
>  - Added second entry in pci_epf_test_ids structure.
>  - Remove test_reg_bar field assignment on second entry.
> Changes v3->v4:
>  - Nothing changed, just to follow the patch set version.
> Changes v4->v5:
>  - Changed pci_epf_test_cfg2 to pci_epf_test_designware.
> Changes v5->v6:
>  - Changed name field from pci_epf_test_designware to pci_epf_test_dw.
> Changes v6->v7:
>  - Changed variable name from data_cfg2 to data_linkup_notifier_disabled.
> 
>  Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++
>  drivers/pci/endpoint/functions/pci-epf-test.c| 8 
>  2 files changed, 10 insertions(+)
> 
> diff --git a/Documentation/PCI/endpoint/function/binding/pci-test.txt 
> b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> index 3b68b95..dc39f47 100644
> --- a/Documentation/PCI/endpoint/function/binding/pci-test.txt
> +++ b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> @@ -1,6 +1,8 @@
>  PCI TEST ENDPOINT FUNCTION
>  
>  name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
> +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver
> +  with a custom configuration for the designware EP.

The link between the "name" and the device created is quite obscure and
reading pci-test-howto.txt certainly does not clarify it.

In pci-test-howto.txt an explanation should be added to the configs
device creation paragraph to clarify it.

>  Configurable Fields:
>  vendorid  : should be 0x104c
> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> b/drivers/pci/endpoint/functions/pci-epf-test.c
> index 7cef851..4ab463b 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)
>   return 0;
>  }
>  
> +static const struct pci_epf_test_data data_linkup_notifier_disabled = {
> + .linkup_notifier = false
> +};
> +
>  static const struct pci_epf_device_id pci_epf_test_ids[] = {
>   {
>   .name = "pci_epf_test",
>   },
> + {
> + .name = "pci_epf_test_dw",
> + .driver_data = (kernel_ulong_t)_linkup_notifier_disabled,
> + },
>   {},

Should not this be a property derived from the controller compatible
property instead of the test device name written in configfs ?

I think I am missing something in the whole scheme of things, please
clarify.

Thanks,
Lorenzo

Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry

[Lorenzo Pieralisi]

On Tue, Apr 24, 2018 at 02:44:40PM +0100, Gustavo Pimentel wrote:
> Adds a seconds entry on the pci_epf_test_ids structure that disables the

"Add a second entry to..."

> linkup_notifier parameter on driver for the designware EP.
> 
> This allows designware EPs that doesn't have linkup notification signal
> to work with pcitest.
> 
> Updates the binding documentation accordingly.

Valid for all the series: use imperative sentences.

eg:

"Update the binding documentation accordingly".

not

"Updates the binding documentation accordingly".

> Signed-off-by: Gustavo Pimentel 
> Acked-by: Kishon Vijay Abraham I 
> ---
> Change v2->v3:
>  - Added second entry in pci_epf_test_ids structure.
>  - Remove test_reg_bar field assignment on second entry.
> Changes v3->v4:
>  - Nothing changed, just to follow the patch set version.
> Changes v4->v5:
>  - Changed pci_epf_test_cfg2 to pci_epf_test_designware.
> Changes v5->v6:
>  - Changed name field from pci_epf_test_designware to pci_epf_test_dw.
> Changes v6->v7:
>  - Changed variable name from data_cfg2 to data_linkup_notifier_disabled.
> 
>  Documentation/PCI/endpoint/function/binding/pci-test.txt | 2 ++
>  drivers/pci/endpoint/functions/pci-epf-test.c| 8 
>  2 files changed, 10 insertions(+)
> 
> diff --git a/Documentation/PCI/endpoint/function/binding/pci-test.txt 
> b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> index 3b68b95..dc39f47 100644
> --- a/Documentation/PCI/endpoint/function/binding/pci-test.txt
> +++ b/Documentation/PCI/endpoint/function/binding/pci-test.txt
> @@ -1,6 +1,8 @@
>  PCI TEST ENDPOINT FUNCTION
>  
>  name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
> +name: Should be "pci_epf_test_dw" to bind to the pci_epf_test driver
> +  with a custom configuration for the designware EP.

The link between the "name" and the device created is quite obscure and
reading pci-test-howto.txt certainly does not clarify it.

In pci-test-howto.txt an explanation should be added to the configs
device creation paragraph to clarify it.

>  Configurable Fields:
>  vendorid  : should be 0x104c
> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> b/drivers/pci/endpoint/functions/pci-epf-test.c
> index 7cef851..4ab463b 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -459,10 +459,18 @@ static int pci_epf_test_bind(struct pci_epf *epf)
>   return 0;
>  }
>  
> +static const struct pci_epf_test_data data_linkup_notifier_disabled = {
> + .linkup_notifier = false
> +};
> +
>  static const struct pci_epf_device_id pci_epf_test_ids[] = {
>   {
>   .name = "pci_epf_test",
>   },
> + {
> + .name = "pci_epf_test_dw",
> + .driver_data = (kernel_ulong_t)_linkup_notifier_disabled,
> + },
>   {},

Should not this be a property derived from the controller compatible
property instead of the test device name written in configfs ?

I think I am missing something in the whole scheme of things, please
clarify.

Thanks,
Lorenzo

Re: [PATCH] arm64: skip cpu nodes marked as disabled in DT

[Lorenzo Pieralisi]

On Thu, Apr 26, 2018 at 08:25:14AM +0100, Catalin Marinas wrote:
> On Wed, Apr 25, 2018 at 11:36:06PM +, Rohit Khanna wrote:
> > Adding few other folks.
> 
> It looks fine to me but cc'ing Mark and Lorenzo (and it should have been
> posted on linux-arm-ker...@lists.infradead.org).
> 
> > From: Rohit Khanna
> > Sent: Wednesday, April 25, 2018 4:08 PM
> > To: catalin.mari...@arm.com; will.dea...@arm.com
> > Cc: linux-kernel@vger.kernel.org; Rohit Khanna
> > Subject: [PATCH] arm64: skip cpu nodes marked as disabled in DT
> > 
> > Skip the CPU nodes that are marked as disabled in DT.
> > 
> > Bug 1828570

That's not information that can be used in its current form, which
bug-tracking system ?

> > Signed-off-by: Rohit Khanna 
> > Reviewed-on: http://git-master/r/1245333

If it is a public mailing list discussion the

Link:

tag and the lkml redirector should be used, I do not know what the
redirector used here is though.

Process is defined here:

https://www.kernel.org/doc/html/latest/process/submitting-patches.html

> > Reviewed-by: Alexander Van Brunt 
> > ---
> >  arch/arm64/kernel/smp.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> > index f3e2e3aec0b0..2b4371b0948d 100644
> > --- a/arch/arm64/kernel/smp.c
> > +++ b/arch/arm64/kernel/smp.c
> > @@ -578,6 +578,10 @@ static void __init of_parse_and_init_cpus(void)
> > for_each_node_by_type(dn, "cpu") {
> > u64 hwid = of_get_cpu_mpidr(dn);
> > 
> > +   /* Check to see if the cpu is disabled */
> > +   if (!of_device_is_available(dn))
> > +   goto next;
> > +

This was discussed a long time ago and kind of dropped - I digged the
thread out of archives for everyone's information:

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/174324.html

Lorenzo

Re: [PATCH] arm64: skip cpu nodes marked as disabled in DT

[Lorenzo Pieralisi]

On Thu, Apr 26, 2018 at 08:25:14AM +0100, Catalin Marinas wrote:
> On Wed, Apr 25, 2018 at 11:36:06PM +, Rohit Khanna wrote:
> > Adding few other folks.
> 
> It looks fine to me but cc'ing Mark and Lorenzo (and it should have been
> posted on linux-arm-ker...@lists.infradead.org).
> 
> > From: Rohit Khanna
> > Sent: Wednesday, April 25, 2018 4:08 PM
> > To: catalin.mari...@arm.com; will.dea...@arm.com
> > Cc: linux-kernel@vger.kernel.org; Rohit Khanna
> > Subject: [PATCH] arm64: skip cpu nodes marked as disabled in DT
> > 
> > Skip the CPU nodes that are marked as disabled in DT.
> > 
> > Bug 1828570

That's not information that can be used in its current form, which
bug-tracking system ?

> > Signed-off-by: Rohit Khanna 
> > Reviewed-on: http://git-master/r/1245333

If it is a public mailing list discussion the

Link:

tag and the lkml redirector should be used, I do not know what the
redirector used here is though.

Process is defined here:

https://www.kernel.org/doc/html/latest/process/submitting-patches.html

> > Reviewed-by: Alexander Van Brunt 
> > ---
> >  arch/arm64/kernel/smp.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> > index f3e2e3aec0b0..2b4371b0948d 100644
> > --- a/arch/arm64/kernel/smp.c
> > +++ b/arch/arm64/kernel/smp.c
> > @@ -578,6 +578,10 @@ static void __init of_parse_and_init_cpus(void)
> > for_each_node_by_type(dn, "cpu") {
> > u64 hwid = of_get_cpu_mpidr(dn);
> > 
> > +   /* Check to see if the cpu is disabled */
> > +   if (!of_device_is_available(dn))
> > +   goto next;
> > +

This was discussed a long time ago and kind of dropped - I digged the
thread out of archives for everyone's information:

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/174324.html

Lorenzo

Re: [PATCH 6/6] arm: Allow to enable PCI_DOMAINS manually

[Lorenzo Pieralisi]

On Tue, Apr 24, 2018 at 05:13:42PM +0200, Jan Kiszka wrote:
> From: Jan Kiszka 
> 
> Required when running over Jailhouse, and there is already a physical
> host controller that Jailhouse does not intercept and rather adds a
> virtual one. That is the case for the Tegra TK1, e.g.
> 
> Signed-off-by: Jan Kiszka 
> ---
>  arch/arm/Kconfig | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index a7f8e7f4b88f..5f8190cb057d 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1248,8 +1248,13 @@ config PCI
> VESA. If you have PCI, say Y, otherwise N.
>  
>  config PCI_DOMAINS
> - bool
> + bool "Support for multiple PCI domains"
>   depends on PCI
> + help
> +   Automatically enabled if the platform supports multiple PCI host
> +   controllers. Say Y if running over a hypervisor like Jailhouse that
> +   dynamically adds further host controllers while the system is
> +   running. Say N otherwise.

Alternatively, you could select it under PCI_HOST_GENERIC if that's all
you need in Jailhouse. Actually that's a change that makes sense anyway
I think.

Lorenzo

Re: [PATCH 6/6] arm: Allow to enable PCI_DOMAINS manually

[Lorenzo Pieralisi]

On Tue, Apr 24, 2018 at 05:13:42PM +0200, Jan Kiszka wrote:
> From: Jan Kiszka 
> 
> Required when running over Jailhouse, and there is already a physical
> host controller that Jailhouse does not intercept and rather adds a
> virtual one. That is the case for the Tegra TK1, e.g.
> 
> Signed-off-by: Jan Kiszka 
> ---
>  arch/arm/Kconfig | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index a7f8e7f4b88f..5f8190cb057d 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1248,8 +1248,13 @@ config PCI
> VESA. If you have PCI, say Y, otherwise N.
>  
>  config PCI_DOMAINS
> - bool
> + bool "Support for multiple PCI domains"
>   depends on PCI
> + help
> +   Automatically enabled if the platform supports multiple PCI host
> +   controllers. Say Y if running over a hypervisor like Jailhouse that
> +   dynamically adds further host controllers while the system is
> +   running. Say N otherwise.

Alternatively, you could select it under PCI_HOST_GENERIC if that's all
you need in Jailhouse. Actually that's a change that makes sense anyway
I think.

Lorenzo

Re: [PATCH 1/6] PCI: Make pci_get_new_domain_nr static

[Lorenzo Pieralisi]

On Tue, Apr 24, 2018 at 05:13:37PM +0200, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kis...@siemens.com>
> 
> The only user of that function is of_pci_bus_find_domain_nr. Pure
> cleanup.

"The only user of pci_get_new_domain_nr() is of_pci_bus_find_domain_nr().
Since they are defined in the same compilation unit,
pci_get_new_domain_nr() can be made static, which also simplifies
preprocessor conditionals.

No functional change intended."

> Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
> ---
>  drivers/pci/pci.c   | 6 ++
>  include/linux/pci.h | 3 ---
>  2 files changed, 2 insertions(+), 7 deletions(-)

Acked-by: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>

> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index e597655a5643..695c2bb4e853 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -5702,15 +5702,14 @@ static void pci_no_domains(void)
>  #endif
>  }
>  
> -#ifdef CONFIG_PCI_DOMAINS
> +#ifdef CONFIG_PCI_DOMAINS_GENERIC
>  static atomic_t __domain_nr = ATOMIC_INIT(-1);
>  
> -int pci_get_new_domain_nr(void)
> +static int pci_get_new_domain_nr(void)
>  {
>   return atomic_inc_return(&__domain_nr);
>  }
>  
> -#ifdef CONFIG_PCI_DOMAINS_GENERIC
>  static int of_pci_bus_find_domain_nr(struct device *parent)
>  {
>   static int use_dt_domains = -1;
> @@ -5765,7 +5764,6 @@ int pci_bus_find_domain_nr(struct pci_bus *bus, struct 
> device *parent)
>  acpi_pci_bus_find_domain_nr(bus);
>  }
>  #endif
> -#endif
>  
>  /**
>   * pci_ext_cfg_avail - can we access extended PCI config space?
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 73178a2fcee0..963232a6cd2e 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1510,12 +1510,10 @@ void pci_cfg_access_unlock(struct pci_dev *dev);
>   */
>  #ifdef CONFIG_PCI_DOMAINS
>  extern int pci_domains_supported;
> -int pci_get_new_domain_nr(void);
>  #else
>  enum { pci_domains_supported = 0 };
>  static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
>  static inline int pci_proc_domain(struct pci_bus *bus) { return 0; }
> -static inline int pci_get_new_domain_nr(void) { return -ENOSYS; }
>  #endif /* CONFIG_PCI_DOMAINS */
>  
>  /*
> @@ -1670,7 +1668,6 @@ static inline struct pci_dev 
> *pci_get_domain_bus_and_slot(int domain,
>  
>  static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
>  static inline struct pci_dev *pci_dev_get(struct pci_dev *dev) { return 
> NULL; }
> -static inline int pci_get_new_domain_nr(void) { return -ENOSYS; }
>  
>  #define dev_is_pci(d) (false)
>  #define dev_is_pf(d) (false)
> -- 
> 2.13.6
> 

Re: [PATCH 1/6] PCI: Make pci_get_new_domain_nr static

[Lorenzo Pieralisi]

On Tue, Apr 24, 2018 at 05:13:37PM +0200, Jan Kiszka wrote:
> From: Jan Kiszka 
> 
> The only user of that function is of_pci_bus_find_domain_nr. Pure
> cleanup.

"The only user of pci_get_new_domain_nr() is of_pci_bus_find_domain_nr().
Since they are defined in the same compilation unit,
pci_get_new_domain_nr() can be made static, which also simplifies
preprocessor conditionals.

No functional change intended."

> Signed-off-by: Jan Kiszka 
> ---
>  drivers/pci/pci.c   | 6 ++
>  include/linux/pci.h | 3 ---
>  2 files changed, 2 insertions(+), 7 deletions(-)

Acked-by: Lorenzo Pieralisi 

> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index e597655a5643..695c2bb4e853 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -5702,15 +5702,14 @@ static void pci_no_domains(void)
>  #endif
>  }
>  
> -#ifdef CONFIG_PCI_DOMAINS
> +#ifdef CONFIG_PCI_DOMAINS_GENERIC
>  static atomic_t __domain_nr = ATOMIC_INIT(-1);
>  
> -int pci_get_new_domain_nr(void)
> +static int pci_get_new_domain_nr(void)
>  {
>   return atomic_inc_return(&__domain_nr);
>  }
>  
> -#ifdef CONFIG_PCI_DOMAINS_GENERIC
>  static int of_pci_bus_find_domain_nr(struct device *parent)
>  {
>   static int use_dt_domains = -1;
> @@ -5765,7 +5764,6 @@ int pci_bus_find_domain_nr(struct pci_bus *bus, struct 
> device *parent)
>  acpi_pci_bus_find_domain_nr(bus);
>  }
>  #endif
> -#endif
>  
>  /**
>   * pci_ext_cfg_avail - can we access extended PCI config space?
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 73178a2fcee0..963232a6cd2e 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1510,12 +1510,10 @@ void pci_cfg_access_unlock(struct pci_dev *dev);
>   */
>  #ifdef CONFIG_PCI_DOMAINS
>  extern int pci_domains_supported;
> -int pci_get_new_domain_nr(void);
>  #else
>  enum { pci_domains_supported = 0 };
>  static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
>  static inline int pci_proc_domain(struct pci_bus *bus) { return 0; }
> -static inline int pci_get_new_domain_nr(void) { return -ENOSYS; }
>  #endif /* CONFIG_PCI_DOMAINS */
>  
>  /*
> @@ -1670,7 +1668,6 @@ static inline struct pci_dev 
> *pci_get_domain_bus_and_slot(int domain,
>  
>  static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
>  static inline struct pci_dev *pci_dev_get(struct pci_dev *dev) { return 
> NULL; }
> -static inline int pci_get_new_domain_nr(void) { return -ENOSYS; }
>  
>  #define dev_is_pci(d) (false)
>  #define dev_is_pf(d) (false)
> -- 
> 2.13.6
> 

Re: [RFC 5/5] PCI: tegra: use seq_open_data

[Lorenzo Pieralisi]

On Wed, Mar 07, 2018 at 12:41:05PM +, Lorenzo Pieralisi wrote:
> On Fri, Mar 02, 2018 at 11:42:07AM +0100, Thierry Reding wrote:
> > On Fri, Mar 02, 2018 at 12:37:24AM +0100, Rasmus Villemoes wrote:
> > > Simplify the code slightly by having seq_open_data do the ->private
> > > assignment.
> > > 
> > > Signed-off-by: Rasmus Villemoes <li...@rasmusvillemoes.dk>
> > > ---
> > >  drivers/pci/host/pci-tegra.c | 11 +--
> > >  1 file changed, 1 insertion(+), 10 deletions(-)
> > 
> > I had to go hunt for patch 1/5 to be able to tell if this is indeed
> > equivalent. It is, so:
> > 
> > Reviewed-by: Thierry Reding <tred...@nvidia.com>
> > Acked-by: Thierry Reding <tred...@nvidia.com>
> 
> I can't apply this patch standalone so I assume this will go via
> some other tree; I will drop it from the PCI patch queue, if I
> should not please do let me know.

I would kindly ask you some feedback - where are we with this patch
series ? Please let me know if should consider it for the pci tree
as per my request above.

Thanks,
Lorenzo

Re: [RFC 5/5] PCI: tegra: use seq_open_data

[Lorenzo Pieralisi]

On Wed, Mar 07, 2018 at 12:41:05PM +, Lorenzo Pieralisi wrote:
> On Fri, Mar 02, 2018 at 11:42:07AM +0100, Thierry Reding wrote:
> > On Fri, Mar 02, 2018 at 12:37:24AM +0100, Rasmus Villemoes wrote:
> > > Simplify the code slightly by having seq_open_data do the ->private
> > > assignment.
> > > 
> > > Signed-off-by: Rasmus Villemoes 
> > > ---
> > >  drivers/pci/host/pci-tegra.c | 11 +--
> > >  1 file changed, 1 insertion(+), 10 deletions(-)
> > 
> > I had to go hunt for patch 1/5 to be able to tell if this is indeed
> > equivalent. It is, so:
> > 
> > Reviewed-by: Thierry Reding 
> > Acked-by: Thierry Reding 
> 
> I can't apply this patch standalone so I assume this will go via
> some other tree; I will drop it from the PCI patch queue, if I
> should not please do let me know.

I would kindly ask you some feedback - where are we with this patch
series ? Please let me know if should consider it for the pci tree
as per my request above.

Thanks,
Lorenzo

Re: [PATCH v3 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver

[Lorenzo Pieralisi]

On Tue, Apr 17, 2018 at 09:17:36AM +0200, Daniel Lezcano wrote:

[...]

>  Actually there is no impact with the change Sudeep is referring to. It
>  is for ACPI, we are DT based. Confirmed with Jeremy.
> 
>  So AFAICT, it is not a problem.
> >>>
> >>> It is a problem - DT or ACPI alike. Sudeep was referring to the notion
> >>> of "cluster" that has no architectural meaning whatsoever and using
> >>> topology_physical_package_id() to detect a "cluster" was/is/will always
> >>> be the wrong thing to do. The notion of cluster must not appear in the
> >>> kernel at all, it has no architectural meaning. I understand you need
> >>> to group CPUs but that has to be done in a different way, through
> >>> cooling devices, thermal domains or power domains DT/ACPI bindings but
> >>> not by using topology masks.
> >>
> >> I don't get it. What is the cluster concept defined in the ARM
> >> documentation?
> >>
> >> ARM Cortex-A53 MPCore Processor Technical Reference Manual
> >>
> >> 4.5.2. Multiprocessor Affinity Register
> >>
> >> I see the documentation says:
> >>
> >> A cluster with two cores, three cores, ...
> >>
> >> How the kernel can represent that if you kill the
> >> topology_physical_package_id() ?
> > 
> > From an Arm ARM perspective (ARM v8 reference manual), the MPIDR_EL1 has
> > no notion of cluster which means that a cluster is not architecturally
> > defined on Arm systems.
> 
> Sorry, I'm lost :/ You say the MPIDR_EL1 has no notion of cluster but
> the documentation describing this register is all talking about cluster.
> 
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0500g/BABHBJCI.html

I pointed you at the documentation I am referring to. You are referring
to A53 TRM, I am referring to the Arm architecture reference manual that
is the reference for all Arm cores.

> > Currently, as Morten explained today, topology_physical_package_id()
> > is supposed to represent a "cluster" and that's completely wrong
> > because a "cluster" cannot be defined from an architectural perspective.
> > 
> > It was a bodge used as a shortcut, wrongly. We should have never used
> > that API for that purpose and there must be no code in the kernel
> > relying on:
> > 
> > topology_physical_package_id()
> > 
> > to define a cluster; the information you require to group CPUs must
> > come from something else, which is firmware bindings(DT or ACPI) as
> > I mentioned.
> 
> Why not ?

I explained why not :). A cluster is not defined architecturally on Arm
- it is as simple as that and you can't rely on a given MPIDR_EL1
subfield to define what a cluster id is.

> diff --git a/arch/arm64/include/asm/topology.h
> b/arch/arm64/include/asm/topology.h
> index c4f2d50..ac0776d 100644
> --- a/arch/arm64/include/asm/topology.h
> +++ b/arch/arm64/include/asm/topology.h
> @@ -14,7 +14,8 @@ struct cpu_topology {
> 
>  extern struct cpu_topology cpu_topology[NR_CPUS];
> 
> -#define topology_physical_package_id(cpu)
> (cpu_topology[cpu].cluster_id)
> +#define topology_physical_package_id(cpu)  (0)
> +#define topology_physical_cluster_id(cpu)

There is no such a thing (and there is no architecturally defined
package id on Arm either).

> (cpu_topology[cpu].cluster_id)
>  #define topology_core_id(cpu)  (cpu_topology[cpu].core_id)
>  #define topology_core_cpumask(cpu) (_topology[cpu].core_sibling)
>  #define topology_sibling_cpumask(cpu)  (_topology[cpu].thread_sibling)
> 
> 
> > Please speak to Sudeep who will fill you on the reasoning above.
> 
> Yes, Sudeep is next to me but I would prefer to keep the discussion on
> the mailing list so everyone can get the reasoning.

It is not a reasoning - it is the Arm architecture. There is no
architecturally defined cluster id on Arm. The affinity bits in
MPIDR_EL1 must be treated as a unique number that represents a given
core/thread, how the bits are allocated across affinity levels is not
something that you can rely on architecturally - that's why DT/ACPI
topology bindings exist to group cpus in a hierarchical topology.

HTH,
Lorenzo

Re: [PATCH v3 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver

[Lorenzo Pieralisi]

On Tue, Apr 17, 2018 at 09:17:36AM +0200, Daniel Lezcano wrote:

[...]

>  Actually there is no impact with the change Sudeep is referring to. It
>  is for ACPI, we are DT based. Confirmed with Jeremy.
> 
>  So AFAICT, it is not a problem.
> >>>
> >>> It is a problem - DT or ACPI alike. Sudeep was referring to the notion
> >>> of "cluster" that has no architectural meaning whatsoever and using
> >>> topology_physical_package_id() to detect a "cluster" was/is/will always
> >>> be the wrong thing to do. The notion of cluster must not appear in the
> >>> kernel at all, it has no architectural meaning. I understand you need
> >>> to group CPUs but that has to be done in a different way, through
> >>> cooling devices, thermal domains or power domains DT/ACPI bindings but
> >>> not by using topology masks.
> >>
> >> I don't get it. What is the cluster concept defined in the ARM
> >> documentation?
> >>
> >> ARM Cortex-A53 MPCore Processor Technical Reference Manual
> >>
> >> 4.5.2. Multiprocessor Affinity Register
> >>
> >> I see the documentation says:
> >>
> >> A cluster with two cores, three cores, ...
> >>
> >> How the kernel can represent that if you kill the
> >> topology_physical_package_id() ?
> > 
> > From an Arm ARM perspective (ARM v8 reference manual), the MPIDR_EL1 has
> > no notion of cluster which means that a cluster is not architecturally
> > defined on Arm systems.
> 
> Sorry, I'm lost :/ You say the MPIDR_EL1 has no notion of cluster but
> the documentation describing this register is all talking about cluster.
> 
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0500g/BABHBJCI.html

I pointed you at the documentation I am referring to. You are referring
to A53 TRM, I am referring to the Arm architecture reference manual that
is the reference for all Arm cores.

> > Currently, as Morten explained today, topology_physical_package_id()
> > is supposed to represent a "cluster" and that's completely wrong
> > because a "cluster" cannot be defined from an architectural perspective.
> > 
> > It was a bodge used as a shortcut, wrongly. We should have never used
> > that API for that purpose and there must be no code in the kernel
> > relying on:
> > 
> > topology_physical_package_id()
> > 
> > to define a cluster; the information you require to group CPUs must
> > come from something else, which is firmware bindings(DT or ACPI) as
> > I mentioned.
> 
> Why not ?

I explained why not :). A cluster is not defined architecturally on Arm
- it is as simple as that and you can't rely on a given MPIDR_EL1
subfield to define what a cluster id is.

> diff --git a/arch/arm64/include/asm/topology.h
> b/arch/arm64/include/asm/topology.h
> index c4f2d50..ac0776d 100644
> --- a/arch/arm64/include/asm/topology.h
> +++ b/arch/arm64/include/asm/topology.h
> @@ -14,7 +14,8 @@ struct cpu_topology {
> 
>  extern struct cpu_topology cpu_topology[NR_CPUS];
> 
> -#define topology_physical_package_id(cpu)
> (cpu_topology[cpu].cluster_id)
> +#define topology_physical_package_id(cpu)  (0)
> +#define topology_physical_cluster_id(cpu)

There is no such a thing (and there is no architecturally defined
package id on Arm either).

> (cpu_topology[cpu].cluster_id)
>  #define topology_core_id(cpu)  (cpu_topology[cpu].core_id)
>  #define topology_core_cpumask(cpu) (_topology[cpu].core_sibling)
>  #define topology_sibling_cpumask(cpu)  (_topology[cpu].thread_sibling)
> 
> 
> > Please speak to Sudeep who will fill you on the reasoning above.
> 
> Yes, Sudeep is next to me but I would prefer to keep the discussion on
> the mailing list so everyone can get the reasoning.

It is not a reasoning - it is the Arm architecture. There is no
architecturally defined cluster id on Arm. The affinity bits in
MPIDR_EL1 must be treated as a unique number that represents a given
core/thread, how the bits are allocated across affinity levels is not
something that you can rely on architecturally - that's why DT/ACPI
topology bindings exist to group cpus in a hierarchical topology.

HTH,
Lorenzo

Re: [PATCH v3 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver

[Lorenzo Pieralisi]

On Mon, Apr 16, 2018 at 03:57:03PM +0200, Daniel Lezcano wrote:
> On 16/04/2018 14:30, Lorenzo Pieralisi wrote:
> > On Mon, Apr 16, 2018 at 02:10:30PM +0200, Daniel Lezcano wrote:
> >> On 16/04/2018 12:10, Viresh Kumar wrote:
> >>> On 16-04-18, 12:03, Daniel Lezcano wrote:
> >>>> On 16/04/2018 11:50, Viresh Kumar wrote:
> >>>>> On 16-04-18, 11:45, Daniel Lezcano wrote:
> >>>>>> Can you elaborate a bit ? I'm not sure to get the point.
> >>>>>
> >>>>> Sure. With your current code on Hikey960 (big/LITTLE), you end up
> >>>>> creating two cooling devices, one for the big cluster and one for
> >>>>> small cluster. Which is the right thing to do, as we also have two
> >>>>> cpufreq cooling devices.
> >>>>>
> >>>>> But with the change Sudeep is referring to, the helper you used to get
> >>>>> cluster id will return 0 (SoC id) for all the 8 CPUs. So your code
> >>>>> will end up creating a single cpuidle cooling device for all the CPUs.
> >>>>> Which would be wrong.
> >>>>
> >>>> Is the semantic of topology_physical_package_id changing ?
> >>>
> >>> That's what I understood from his email.
> >>>
> >>>> I don't
> >>>> understand the change Sudeep is referring to.
> >>
> >> Actually there is no impact with the change Sudeep is referring to. It
> >> is for ACPI, we are DT based. Confirmed with Jeremy.
> >>
> >> So AFAICT, it is not a problem.
> > 
> > It is a problem - DT or ACPI alike. Sudeep was referring to the notion
> > of "cluster" that has no architectural meaning whatsoever and using
> > topology_physical_package_id() to detect a "cluster" was/is/will always
> > be the wrong thing to do. The notion of cluster must not appear in the
> > kernel at all, it has no architectural meaning. I understand you need
> > to group CPUs but that has to be done in a different way, through
> > cooling devices, thermal domains or power domains DT/ACPI bindings but
> > not by using topology masks.
> 
> I don't get it. What is the cluster concept defined in the ARM
> documentation?
> 
> ARM Cortex-A53 MPCore Processor Technical Reference Manual
> 
> 4.5.2. Multiprocessor Affinity Register
> 
> I see the documentation says:
> 
> A cluster with two cores, three cores, ...
> 
> How the kernel can represent that if you kill the
> topology_physical_package_id() ?

>From an Arm ARM perspective (ARM v8 reference manual), the MPIDR_EL1 has
no notion of cluster which means that a cluster is not architecturally
defined on Arm systems.

Currently, as Morten explained today, topology_physical_package_id()
is supposed to represent a "cluster" and that's completely wrong
because a "cluster" cannot be defined from an architectural perspective.

It was a bodge used as a shortcut, wrongly. We should have never used
that API for that purpose and there must be no code in the kernel
relying on:

topology_physical_package_id()

to define a cluster; the information you require to group CPUs must
come from something else, which is firmware bindings(DT or ACPI) as
I mentioned.

Please speak to Sudeep who will fill you on the reasoning above.

Thanks,
Lorenzo

Re: [PATCH v3 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver

[Lorenzo Pieralisi]

On Mon, Apr 16, 2018 at 03:57:03PM +0200, Daniel Lezcano wrote:
> On 16/04/2018 14:30, Lorenzo Pieralisi wrote:
> > On Mon, Apr 16, 2018 at 02:10:30PM +0200, Daniel Lezcano wrote:
> >> On 16/04/2018 12:10, Viresh Kumar wrote:
> >>> On 16-04-18, 12:03, Daniel Lezcano wrote:
> >>>> On 16/04/2018 11:50, Viresh Kumar wrote:
> >>>>> On 16-04-18, 11:45, Daniel Lezcano wrote:
> >>>>>> Can you elaborate a bit ? I'm not sure to get the point.
> >>>>>
> >>>>> Sure. With your current code on Hikey960 (big/LITTLE), you end up
> >>>>> creating two cooling devices, one for the big cluster and one for
> >>>>> small cluster. Which is the right thing to do, as we also have two
> >>>>> cpufreq cooling devices.
> >>>>>
> >>>>> But with the change Sudeep is referring to, the helper you used to get
> >>>>> cluster id will return 0 (SoC id) for all the 8 CPUs. So your code
> >>>>> will end up creating a single cpuidle cooling device for all the CPUs.
> >>>>> Which would be wrong.
> >>>>
> >>>> Is the semantic of topology_physical_package_id changing ?
> >>>
> >>> That's what I understood from his email.
> >>>
> >>>> I don't
> >>>> understand the change Sudeep is referring to.
> >>
> >> Actually there is no impact with the change Sudeep is referring to. It
> >> is for ACPI, we are DT based. Confirmed with Jeremy.
> >>
> >> So AFAICT, it is not a problem.
> > 
> > It is a problem - DT or ACPI alike. Sudeep was referring to the notion
> > of "cluster" that has no architectural meaning whatsoever and using
> > topology_physical_package_id() to detect a "cluster" was/is/will always
> > be the wrong thing to do. The notion of cluster must not appear in the
> > kernel at all, it has no architectural meaning. I understand you need
> > to group CPUs but that has to be done in a different way, through
> > cooling devices, thermal domains or power domains DT/ACPI bindings but
> > not by using topology masks.
> 
> I don't get it. What is the cluster concept defined in the ARM
> documentation?
> 
> ARM Cortex-A53 MPCore Processor Technical Reference Manual
> 
> 4.5.2. Multiprocessor Affinity Register
> 
> I see the documentation says:
> 
> A cluster with two cores, three cores, ...
> 
> How the kernel can represent that if you kill the
> topology_physical_package_id() ?

>From an Arm ARM perspective (ARM v8 reference manual), the MPIDR_EL1 has
no notion of cluster which means that a cluster is not architecturally
defined on Arm systems.

Currently, as Morten explained today, topology_physical_package_id()
is supposed to represent a "cluster" and that's completely wrong
because a "cluster" cannot be defined from an architectural perspective.

It was a bodge used as a shortcut, wrongly. We should have never used
that API for that purpose and there must be no code in the kernel
relying on:

topology_physical_package_id()

to define a cluster; the information you require to group CPUs must
come from something else, which is firmware bindings(DT or ACPI) as
I mentioned.

Please speak to Sudeep who will fill you on the reasoning above.

Thanks,
Lorenzo

Re: [PATCH v3 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver

[Lorenzo Pieralisi]

On Mon, Apr 16, 2018 at 02:10:30PM +0200, Daniel Lezcano wrote:
> On 16/04/2018 12:10, Viresh Kumar wrote:
> > On 16-04-18, 12:03, Daniel Lezcano wrote:
> >> On 16/04/2018 11:50, Viresh Kumar wrote:
> >>> On 16-04-18, 11:45, Daniel Lezcano wrote:
>  Can you elaborate a bit ? I'm not sure to get the point.
> >>>
> >>> Sure. With your current code on Hikey960 (big/LITTLE), you end up
> >>> creating two cooling devices, one for the big cluster and one for
> >>> small cluster. Which is the right thing to do, as we also have two
> >>> cpufreq cooling devices.
> >>>
> >>> But with the change Sudeep is referring to, the helper you used to get
> >>> cluster id will return 0 (SoC id) for all the 8 CPUs. So your code
> >>> will end up creating a single cpuidle cooling device for all the CPUs.
> >>> Which would be wrong.
> >>
> >> Is the semantic of topology_physical_package_id changing ?
> > 
> > That's what I understood from his email.
> > 
> >> I don't
> >> understand the change Sudeep is referring to.
> 
> Actually there is no impact with the change Sudeep is referring to. It
> is for ACPI, we are DT based. Confirmed with Jeremy.
> 
> So AFAICT, it is not a problem.

It is a problem - DT or ACPI alike. Sudeep was referring to the notion
of "cluster" that has no architectural meaning whatsoever and using
topology_physical_package_id() to detect a "cluster" was/is/will always
be the wrong thing to do. The notion of cluster must not appear in the
kernel at all, it has no architectural meaning. I understand you need
to group CPUs but that has to be done in a different way, through
cooling devices, thermal domains or power domains DT/ACPI bindings but
not by using topology masks.

You should be able to figure out this week at OSPM the reasoning behind
what I am saying above.

Cheers,
Lorenzo

Re: [PATCH v3 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver

[Lorenzo Pieralisi]

On Mon, Apr 16, 2018 at 02:10:30PM +0200, Daniel Lezcano wrote:
> On 16/04/2018 12:10, Viresh Kumar wrote:
> > On 16-04-18, 12:03, Daniel Lezcano wrote:
> >> On 16/04/2018 11:50, Viresh Kumar wrote:
> >>> On 16-04-18, 11:45, Daniel Lezcano wrote:
>  Can you elaborate a bit ? I'm not sure to get the point.
> >>>
> >>> Sure. With your current code on Hikey960 (big/LITTLE), you end up
> >>> creating two cooling devices, one for the big cluster and one for
> >>> small cluster. Which is the right thing to do, as we also have two
> >>> cpufreq cooling devices.
> >>>
> >>> But with the change Sudeep is referring to, the helper you used to get
> >>> cluster id will return 0 (SoC id) for all the 8 CPUs. So your code
> >>> will end up creating a single cpuidle cooling device for all the CPUs.
> >>> Which would be wrong.
> >>
> >> Is the semantic of topology_physical_package_id changing ?
> > 
> > That's what I understood from his email.
> > 
> >> I don't
> >> understand the change Sudeep is referring to.
> 
> Actually there is no impact with the change Sudeep is referring to. It
> is for ACPI, we are DT based. Confirmed with Jeremy.
> 
> So AFAICT, it is not a problem.

It is a problem - DT or ACPI alike. Sudeep was referring to the notion
of "cluster" that has no architectural meaning whatsoever and using
topology_physical_package_id() to detect a "cluster" was/is/will always
be the wrong thing to do. The notion of cluster must not appear in the
kernel at all, it has no architectural meaning. I understand you need
to group CPUs but that has to be done in a different way, through
cooling devices, thermal domains or power domains DT/ACPI bindings but
not by using topology masks.

You should be able to figure out this week at OSPM the reasoning behind
what I am saying above.

Cheers,
Lorenzo

Re: [PATCH v7] Revert "PCI: hv: Use device serial number as PCI domain"

[Lorenzo Pieralisi]

On Thu, Apr 12, 2018 at 03:56:42PM +, Sridhar Pitchai wrote:
> > 
> > >> I am still not happy with this patch.
> > >>
> > >> -  You do not explain at all the dependency on commit 
> 0c195567a8f6 and
> > >>you should because that's fundamental, if that patch is not 
> present
> > >>this revert breaks the kernel as per previous discussions[1].
> > >> -  You are sending this patch to all stable kernels that contain 
> the
> > >>commit you are fixing - some that may not contain the commit 
> above
> > >>(that was merged in v4.14), you are breaking those kernels, 
> if not
> > >>explain me why please
> > 
> > >If there's a dependency on 0c195567a8f6, I totally agree that
> > >needs to be cleared up.  I was assuming that turned out to be
> > >irrelevant.
> > That is right. There is no dependency on 0c195567a8f6. We just need to 
> revert
> > 4a9b0933bdfc.
> 
> > This patch should only be applied to later versions after  
> 0c195567a8f6" (transparent VF).
> > Otherwise it causes long & random names of VF NICs for bonding. That 
> will make bonding
> > config difficult, especially for auto config.
> 
> >Thanks,
> >- Haiyang
> Ok. I will update the patch, as Lorenzo suggested. 

Please update your email client quoting policy so that it does not add
unnecessary indentation spaces, for long threads this gets messy.

If you send a patch to a specific stable version you have to test it
first thing on that stable version before adding a stable tag, reverting
a patch from stable kernels is the last thing we want to do - that's the
reason why I keep complaining.

Thanks,
Lorenzo

Re: [PATCH v7] Revert "PCI: hv: Use device serial number as PCI domain"

[Lorenzo Pieralisi]

On Thu, Apr 12, 2018 at 03:56:42PM +, Sridhar Pitchai wrote:
> > 
> > >> I am still not happy with this patch.
> > >>
> > >> -  You do not explain at all the dependency on commit 
> 0c195567a8f6 and
> > >>you should because that's fundamental, if that patch is not 
> present
> > >>this revert breaks the kernel as per previous discussions[1].
> > >> -  You are sending this patch to all stable kernels that contain 
> the
> > >>commit you are fixing - some that may not contain the commit 
> above
> > >>(that was merged in v4.14), you are breaking those kernels, 
> if not
> > >>explain me why please
> > 
> > >If there's a dependency on 0c195567a8f6, I totally agree that
> > >needs to be cleared up.  I was assuming that turned out to be
> > >irrelevant.
> > That is right. There is no dependency on 0c195567a8f6. We just need to 
> revert
> > 4a9b0933bdfc.
> 
> > This patch should only be applied to later versions after  
> 0c195567a8f6" (transparent VF).
> > Otherwise it causes long & random names of VF NICs for bonding. That 
> will make bonding
> > config difficult, especially for auto config.
> 
> >Thanks,
> >- Haiyang
> Ok. I will update the patch, as Lorenzo suggested. 

Please update your email client quoting policy so that it does not add
unnecessary indentation spaces, for long threads this gets messy.

If you send a patch to a specific stable version you have to test it
first thing on that stable version before adding a stable tag, reverting
a patch from stable kernels is the last thing we want to do - that's the
reason why I keep complaining.

Thanks,
Lorenzo

Re: [PATCH v7] Revert "PCI: hv: Use device serial number as PCI domain"

[Lorenzo Pieralisi]

On Thu, Apr 12, 2018 at 02:44:42AM +, Sridhar Pitchai wrote:
> When Linux runs as a guest VM in Hyper-V and Hyper-V adds the virtual PCI
> bus to the guest, Hyper-V always provides unique PCI domain.
> 
> commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain")
> overrode unique domain with the serial number of the first device added to
> the virtual PCI bus.
> 
> The reason for that patch was to have a consistent and short name for the
> device, but Hyper-V doesn't provide unique serial numbers. Using non-unique
> serial numbers as domain IDs leads to duplicate device addresses, which
> causes PCI bus registration to fail.
> 
> Revert commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI
> domain") so we can reliably support multiple devices being assigned to
> a guest.
> 
> Fixes: 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain")
> Signed-off-by: Sridhar Pitchai 
> Cc: sta...@vger.kernel.org

I am still not happy with this patch.

-  You do not explain at all the dependency on commit 0c195567a8f6 and
   you should because that's fundamental, if that patch is not present
   this revert breaks the kernel as per previous discussions[1].
-  You are sending this patch to all stable kernels that contain the
   commit you are fixing - some that may not contain the commit above
   (that was merged in v4.14), you are breaking those kernels, if not
   explain me why please

You must mark the stable kernels you want this revert to be applied to
eg:

Cc:  # v4.14+

and for kernels that do not contain the 0c195567a8f6 commit you have to
add the dependency. Please read the documentation Greg provided you in
relation to stable kernel rules.

Use:

git tag --contains

to detect in what kernel version the given commits are present.

[1] https://marc.info/?l=linux-pci=152158684221212=2

> Reviewed-by: Bjorn Helgaas 
> 
> ---
> Changes in v7:
> * fix the commit comment. [Bjorn Helgaas]
> ---
>  drivers/pci/host/pci-hyperv.c | 11 ---
>  1 file changed, 11 deletions(-)
> 
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index 2faf38eab785..ac67e56e451a 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -1518,17 +1518,6 @@ static struct hv_pci_dev *new_pcichild_device(struct 
> hv_pcibus_device *hbus,
>   get_pcichild(hpdev, hv_pcidev_ref_childlist);
>   spin_lock_irqsave(>device_list_lock, flags);
>  
> - /*
> -  * When a device is being added to the bus, we set the PCI domain
> -  * number to be the device serial number, which is non-zero and
> -  * unique on the same VM.  The serial numbers start with 1, and
> -  * increase by 1 for each device.  So device names including this
> -  * can have shorter names than based on the bus instance UUID.
> -  * Only the first device serial number is used for domain, so the
> -  * domain number will not change after the first device is added.
> -  */
> - if (list_empty(>children))
> - hbus->sysdata.domain = desc->ser;
>   list_add_tail(>list_entry, >children);
>   spin_unlock_irqrestore(>device_list_lock, flags);
>   return hpdev;
> -- 
> 2.14.1
> 

Re: [PATCH v7] Revert "PCI: hv: Use device serial number as PCI domain"

[Lorenzo Pieralisi]

On Thu, Apr 12, 2018 at 02:44:42AM +, Sridhar Pitchai wrote:
> When Linux runs as a guest VM in Hyper-V and Hyper-V adds the virtual PCI
> bus to the guest, Hyper-V always provides unique PCI domain.
> 
> commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain")
> overrode unique domain with the serial number of the first device added to
> the virtual PCI bus.
> 
> The reason for that patch was to have a consistent and short name for the
> device, but Hyper-V doesn't provide unique serial numbers. Using non-unique
> serial numbers as domain IDs leads to duplicate device addresses, which
> causes PCI bus registration to fail.
> 
> Revert commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI
> domain") so we can reliably support multiple devices being assigned to
> a guest.
> 
> Fixes: 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain")
> Signed-off-by: Sridhar Pitchai 
> Cc: sta...@vger.kernel.org

I am still not happy with this patch.

-  You do not explain at all the dependency on commit 0c195567a8f6 and
   you should because that's fundamental, if that patch is not present
   this revert breaks the kernel as per previous discussions[1].
-  You are sending this patch to all stable kernels that contain the
   commit you are fixing - some that may not contain the commit above
   (that was merged in v4.14), you are breaking those kernels, if not
   explain me why please

You must mark the stable kernels you want this revert to be applied to
eg:

Cc:  # v4.14+

and for kernels that do not contain the 0c195567a8f6 commit you have to
add the dependency. Please read the documentation Greg provided you in
relation to stable kernel rules.

Use:

git tag --contains

to detect in what kernel version the given commits are present.

[1] https://marc.info/?l=linux-pci=152158684221212=2

> Reviewed-by: Bjorn Helgaas 
> 
> ---
> Changes in v7:
> * fix the commit comment. [Bjorn Helgaas]
> ---
>  drivers/pci/host/pci-hyperv.c | 11 ---
>  1 file changed, 11 deletions(-)
> 
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index 2faf38eab785..ac67e56e451a 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -1518,17 +1518,6 @@ static struct hv_pci_dev *new_pcichild_device(struct 
> hv_pcibus_device *hbus,
>   get_pcichild(hpdev, hv_pcidev_ref_childlist);
>   spin_lock_irqsave(>device_list_lock, flags);
>  
> - /*
> -  * When a device is being added to the bus, we set the PCI domain
> -  * number to be the device serial number, which is non-zero and
> -  * unique on the same VM.  The serial numbers start with 1, and
> -  * increase by 1 for each device.  So device names including this
> -  * can have shorter names than based on the bus instance UUID.
> -  * Only the first device serial number is used for domain, so the
> -  * domain number will not change after the first device is added.
> -  */
> - if (list_empty(>children))
> - hbus->sysdata.domain = desc->ser;
>   list_add_tail(>list_entry, >children);
>   spin_unlock_irqrestore(>device_list_lock, flags);
>   return hpdev;
> -- 
> 2.14.1
> 

Re: [PATCH v2 6/9] PCI: dwc: Define maximum number of vectors

[Lorenzo Pieralisi]

On Tue, Apr 10, 2018 at 08:59:30AM +0100, Gustavo Pimentel wrote:
> Hi Lorenzo,
> 
> On 09/04/2018 17:03, Lorenzo Pieralisi wrote:
> > On Mon, Apr 09, 2018 at 10:41:15AM +0100, Gustavo Pimentel wrote:
> >> Adds a callback that defines the maximum number of vectors that can be use
> >> by the Root Complex.
> >>
> >> Since this is a parameter associated to each SoC IP setting, makes sense to
> >> be configurable and easily visible to future modifications.
> >>
> >> The designware IP supports a maximum of 256 vectors.
> > 
> > I think that a DT property instead of a callback would have made more
> > sense - I struggle to see the point in defining a callback to initialize
> > a variable, this can be done in the generic dwc code (and a DT binding).
> 
> The addition of this callback was done in MSI-X patch series before I take 
> over
> the PCIe Designware driver responsibility. However I remember a thread in 
> which
> this subject was discussed (see [1]), maybe this could bring some light about
> the motive why is was done like this. If you don't agree I can do patch after
> this series only focusing on this topic in order to do like to suggested.
> 
> [1] -> https://www.spinics.net/lists/linux-pci/msg61835.html

Lucas has a point - it is fine to handle them as you do in this patch,
it does not make much sense to add a property for something that
strictly depends on the compatible string.

Thanks,
Lorenzo

Re: [PATCH v2 6/9] PCI: dwc: Define maximum number of vectors

[Lorenzo Pieralisi]

On Tue, Apr 10, 2018 at 08:59:30AM +0100, Gustavo Pimentel wrote:
> Hi Lorenzo,
> 
> On 09/04/2018 17:03, Lorenzo Pieralisi wrote:
> > On Mon, Apr 09, 2018 at 10:41:15AM +0100, Gustavo Pimentel wrote:
> >> Adds a callback that defines the maximum number of vectors that can be use
> >> by the Root Complex.
> >>
> >> Since this is a parameter associated to each SoC IP setting, makes sense to
> >> be configurable and easily visible to future modifications.
> >>
> >> The designware IP supports a maximum of 256 vectors.
> > 
> > I think that a DT property instead of a callback would have made more
> > sense - I struggle to see the point in defining a callback to initialize
> > a variable, this can be done in the generic dwc code (and a DT binding).
> 
> The addition of this callback was done in MSI-X patch series before I take 
> over
> the PCIe Designware driver responsibility. However I remember a thread in 
> which
> this subject was discussed (see [1]), maybe this could bring some light about
> the motive why is was done like this. If you don't agree I can do patch after
> this series only focusing on this topic in order to do like to suggested.
> 
> [1] -> https://www.spinics.net/lists/linux-pci/msg61835.html

Lucas has a point - it is fine to handle them as you do in this patch,
it does not make much sense to add a property for something that
strictly depends on the compatible string.

Thanks,
Lorenzo

Re: [PATCH v2 6/9] PCI: dwc: Define maximum number of vectors

[Lorenzo Pieralisi]

On Mon, Apr 09, 2018 at 10:41:15AM +0100, Gustavo Pimentel wrote:
> Adds a callback that defines the maximum number of vectors that can be use
> by the Root Complex.
> 
> Since this is a parameter associated to each SoC IP setting, makes sense to
> be configurable and easily visible to future modifications.
> 
> The designware IP supports a maximum of 256 vectors.

I think that a DT property instead of a callback would have made more
sense - I struggle to see the point in defining a callback to initialize
a variable, this can be done in the generic dwc code (and a DT binding).

Lorenzo

> Signed-off-by: Gustavo Pimentel 
> ---
> Change v1->v2:
> - Nothing changed, just to follow the patch set version.
> 
>  drivers/pci/dwc/pcie-designware-plat.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-plat.c 
> b/drivers/pci/dwc/pcie-designware-plat.c
> index 5382a7a..94da252 100644
> --- a/drivers/pci/dwc/pcie-designware-plat.c
> +++ b/drivers/pci/dwc/pcie-designware-plat.c
> @@ -48,8 +48,14 @@ static int dw_plat_pcie_host_init(struct pcie_port *pp)
>   return 0;
>  }
>  
> +static void dw_plat_set_num_vectors(struct pcie_port *pp)
> +{
> + pp->num_vectors = MAX_MSI_IRQS;
> +}
> +
>  static const struct dw_pcie_host_ops dw_plat_pcie_host_ops = {
>   .host_init = dw_plat_pcie_host_init,
> + .set_num_vectors = dw_plat_set_num_vectors,
>  };
>  
>  static int dw_plat_pcie_establish_link(struct dw_pcie *pci)
> -- 
> 2.7.4
> 
> 

Re: [PATCH v2 6/9] PCI: dwc: Define maximum number of vectors

[Lorenzo Pieralisi]

On Mon, Apr 09, 2018 at 10:41:15AM +0100, Gustavo Pimentel wrote:
> Adds a callback that defines the maximum number of vectors that can be use
> by the Root Complex.
> 
> Since this is a parameter associated to each SoC IP setting, makes sense to
> be configurable and easily visible to future modifications.
> 
> The designware IP supports a maximum of 256 vectors.

I think that a DT property instead of a callback would have made more
sense - I struggle to see the point in defining a callback to initialize
a variable, this can be done in the generic dwc code (and a DT binding).

Lorenzo

> Signed-off-by: Gustavo Pimentel 
> ---
> Change v1->v2:
> - Nothing changed, just to follow the patch set version.
> 
>  drivers/pci/dwc/pcie-designware-plat.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-plat.c 
> b/drivers/pci/dwc/pcie-designware-plat.c
> index 5382a7a..94da252 100644
> --- a/drivers/pci/dwc/pcie-designware-plat.c
> +++ b/drivers/pci/dwc/pcie-designware-plat.c
> @@ -48,8 +48,14 @@ static int dw_plat_pcie_host_init(struct pcie_port *pp)
>   return 0;
>  }
>  
> +static void dw_plat_set_num_vectors(struct pcie_port *pp)
> +{
> + pp->num_vectors = MAX_MSI_IRQS;
> +}
> +
>  static const struct dw_pcie_host_ops dw_plat_pcie_host_ops = {
>   .host_init = dw_plat_pcie_host_init,
> + .set_num_vectors = dw_plat_set_num_vectors,
>  };
>  
>  static int dw_plat_pcie_establish_link(struct dw_pcie *pci)
> -- 
> 2.7.4
> 
> 

Re: [RFC PATCH 2/2] ACPI/IORT: use swiotlb_dma_ops when smmu probe failed

[Lorenzo Pieralisi]

[+cc Robin]

On Thu, Mar 29, 2018 at 03:01:00AM -0700, Wang Dongsheng wrote:
> If SMMU probe failed, master should use swiotlb as dma ops.
> SMMU may probe failed with specified environment, so there
> are not any iommu resources in iommu_device_list.
> 
> The master will always get EPROBE_DEFER from really_probe
> (dma_configure) but in fact SMMU has probe failed. The issue
> causes all of masters failed to be driven.

I added Robin to pick his brain. An alternative would consist
in using a bus notifier to prevent deferred probing once the SMMU
driver probing failed but that seems backwards given that a major
reason to move to deferred probing was to remove the bus notifiers
dependency in the first place.

It seems to me this is both an OF/ACPI issue - it is not an IORT
only problem.

Lorenzo

> Signed-off-by: Wang Dongsheng 
> ---
>  drivers/acpi/arm64/iort.c | 39 +--
>  1 file changed, 33 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index e2f7bdd..a6f4c27 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -774,17 +774,45 @@ static int arm_smmu_iort_xlate(struct device *dev, u32 
> streamid,
>   return ret;
>  }
>  
> -static inline bool iort_iommu_driver_enabled(u8 type)
> +static int iort_check_dev_dl_status(struct device *dev, void *data)
>  {
> + struct fwnode_handle *fwnode = data;
> +
> + if (dev->fwnode != fwnode)
> + return 0;
> +
> + if (dev->links.status == DL_DEV_PROBE_FAILED)
> + return -ENODEV;
> +
> + return -EPROBE_DEFER;
> +}
> +
> +static int iort_iommu_driver_enabled(u8 type, struct fwnode_handle *fwnode)
> +{
> + bool buildin;
> + int ret;
> +
>   switch (type) {
>   case ACPI_IORT_NODE_SMMU_V3:
> - return IS_BUILTIN(CONFIG_ARM_SMMU_V3);
> + buildin = IS_BUILTIN(CONFIG_ARM_SMMU_V3);
> + break;
>   case ACPI_IORT_NODE_SMMU:
> - return IS_BUILTIN(CONFIG_ARM_SMMU);
> + buildin = IS_BUILTIN(CONFIG_ARM_SMMU);
> + break;
>   default:
>   pr_warn("IORT node type %u does not describe an SMMU\n", type);
> - return false;
> + buildin = false;
>   }
> +
> + if (!buildin)
> + return -ENODEV;
> +
> + ret = bus_for_each_dev(_bus_type, NULL, fwnode,
> +iort_check_dev_dl_status);
> + if (!ret)
> + return -EPROBE_DEFER;
> +
> + return ret;
>  }
>  
>  #ifdef CONFIG_IOMMU_API
> @@ -919,8 +947,7 @@ static int iort_iommu_xlate(struct device *dev, struct 
> acpi_iort_node *node,
>*/
>   ops = iommu_ops_from_fwnode(iort_fwnode);
>   if (!ops)
> - return iort_iommu_driver_enabled(node->type) ?
> --EPROBE_DEFER : -ENODEV;
> + return iort_iommu_driver_enabled(node->type, iort_fwnode);
>  
>   return arm_smmu_iort_xlate(dev, streamid, iort_fwnode, ops);
>  }
> -- 
> 2.7.4
> 

Re: [RFC PATCH 2/2] ACPI/IORT: use swiotlb_dma_ops when smmu probe failed

[Lorenzo Pieralisi]

[+cc Robin]

On Thu, Mar 29, 2018 at 03:01:00AM -0700, Wang Dongsheng wrote:
> If SMMU probe failed, master should use swiotlb as dma ops.
> SMMU may probe failed with specified environment, so there
> are not any iommu resources in iommu_device_list.
> 
> The master will always get EPROBE_DEFER from really_probe
> (dma_configure) but in fact SMMU has probe failed. The issue
> causes all of masters failed to be driven.

I added Robin to pick his brain. An alternative would consist
in using a bus notifier to prevent deferred probing once the SMMU
driver probing failed but that seems backwards given that a major
reason to move to deferred probing was to remove the bus notifiers
dependency in the first place.

It seems to me this is both an OF/ACPI issue - it is not an IORT
only problem.

Lorenzo

> Signed-off-by: Wang Dongsheng 
> ---
>  drivers/acpi/arm64/iort.c | 39 +--
>  1 file changed, 33 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index e2f7bdd..a6f4c27 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -774,17 +774,45 @@ static int arm_smmu_iort_xlate(struct device *dev, u32 
> streamid,
>   return ret;
>  }
>  
> -static inline bool iort_iommu_driver_enabled(u8 type)
> +static int iort_check_dev_dl_status(struct device *dev, void *data)
>  {
> + struct fwnode_handle *fwnode = data;
> +
> + if (dev->fwnode != fwnode)
> + return 0;
> +
> + if (dev->links.status == DL_DEV_PROBE_FAILED)
> + return -ENODEV;
> +
> + return -EPROBE_DEFER;
> +}
> +
> +static int iort_iommu_driver_enabled(u8 type, struct fwnode_handle *fwnode)
> +{
> + bool buildin;
> + int ret;
> +
>   switch (type) {
>   case ACPI_IORT_NODE_SMMU_V3:
> - return IS_BUILTIN(CONFIG_ARM_SMMU_V3);
> + buildin = IS_BUILTIN(CONFIG_ARM_SMMU_V3);
> + break;
>   case ACPI_IORT_NODE_SMMU:
> - return IS_BUILTIN(CONFIG_ARM_SMMU);
> + buildin = IS_BUILTIN(CONFIG_ARM_SMMU);
> + break;
>   default:
>   pr_warn("IORT node type %u does not describe an SMMU\n", type);
> - return false;
> + buildin = false;
>   }
> +
> + if (!buildin)
> + return -ENODEV;
> +
> + ret = bus_for_each_dev(_bus_type, NULL, fwnode,
> +iort_check_dev_dl_status);
> + if (!ret)
> + return -EPROBE_DEFER;
> +
> + return ret;
>  }
>  
>  #ifdef CONFIG_IOMMU_API
> @@ -919,8 +947,7 @@ static int iort_iommu_xlate(struct device *dev, struct 
> acpi_iort_node *node,
>*/
>   ops = iommu_ops_from_fwnode(iort_fwnode);
>   if (!ops)
> - return iort_iommu_driver_enabled(node->type) ?
> --EPROBE_DEFER : -ENODEV;
> + return iort_iommu_driver_enabled(node->type, iort_fwnode);
>  
>   return arm_smmu_iort_xlate(dev, streamid, iort_fwnode, ops);
>  }
> -- 
> 2.7.4
> 

Re: [PATCH 3/8] bindings: PCI: designware: Add support for the EP in designware driver

[Lorenzo Pieralisi]

On Wed, Mar 28, 2018 at 12:38:33PM +0100, Gustavo Pimentel wrote:

Please always write a commit log even if it is trivial.

Thanks,
Lorenzo

> Signed-off-by: Gustavo Pimentel 
> ---
>  Documentation/devicetree/bindings/pci/designware-pcie.txt | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt 
> b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> index 6300762..4bb2e08 100644
> --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> @@ -3,6 +3,7 @@
>  Required properties:
>  - compatible:
>   "snps,dw-pcie" for RC mode;
> + "snps,dw-pcie-ep" for EP mode;
>  - reg: Should contain the configuration address space.
>  - reg-names: Must be "config" for the PCIe configuration space.
>  (The old way of getting the configuration address space from "ranges"
> @@ -56,3 +57,15 @@ Example configuration:
>   #interrupt-cells = <1>;
>   num-lanes = <1>;
>   };
> +or
> + pcie_ep: pcie_ep@dfc0 {
> + compatible = "snps,dw-pcie-ep";
> + reg = <0xdfc0 0x0001000>, /* IP registers 1 */
> +   <0xdfc01000 0x0001000>, /* IP registers 2 */
> +   <0xd000 0x200>; /* Configuration space */
> + reg-names = "dbi", "dbi2", "addr_space";
> + device_type = "pci";
> + num-ib-windows = <6>;
> + num-ob-windows = <2>;
> + num-lanes = <1>;
> + };
> -- 
> 2.7.4
> 
> 

Re: [PATCH 3/8] bindings: PCI: designware: Add support for the EP in designware driver

[Lorenzo Pieralisi]

On Wed, Mar 28, 2018 at 12:38:33PM +0100, Gustavo Pimentel wrote:

Please always write a commit log even if it is trivial.

Thanks,
Lorenzo

> Signed-off-by: Gustavo Pimentel 
> ---
>  Documentation/devicetree/bindings/pci/designware-pcie.txt | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt 
> b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> index 6300762..4bb2e08 100644
> --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> @@ -3,6 +3,7 @@
>  Required properties:
>  - compatible:
>   "snps,dw-pcie" for RC mode;
> + "snps,dw-pcie-ep" for EP mode;
>  - reg: Should contain the configuration address space.
>  - reg-names: Must be "config" for the PCIe configuration space.
>  (The old way of getting the configuration address space from "ranges"
> @@ -56,3 +57,15 @@ Example configuration:
>   #interrupt-cells = <1>;
>   num-lanes = <1>;
>   };
> +or
> + pcie_ep: pcie_ep@dfc0 {
> + compatible = "snps,dw-pcie-ep";
> + reg = <0xdfc0 0x0001000>, /* IP registers 1 */
> +   <0xdfc01000 0x0001000>, /* IP registers 2 */
> +   <0xd000 0x200>; /* Configuration space */
> + reg-names = "dbi", "dbi2", "addr_space";
> + device_type = "pci";
> + num-ib-windows = <6>;
> + num-ob-windows = <2>;
> + num-lanes = <1>;
> + };
> -- 
> 2.7.4
> 
> 

Re: [PATCH 2/2] perf: add arm64 smmuv3 pmu driver

[Lorenzo Pieralisi]

On Tue, Apr 03, 2018 at 09:15:11AM +0800, Hanjun Guo wrote:
> [+Cc Lorenzo]
> 
> Hi Neil,
> 
> On 2018/4/3 1:59, Neil Leeder wrote:
> > Hi Hanjun,
> > 
> > On 4/2/2018 10:24 AM, Hanjun Guo wrote:
> > 
> >>
> >> I think we need to wait for the new version of IORT spec,
> >> which includes the fix for the two base address for SMMUv3
> >> PMCG (now just represent one).
> >>
> >> Thanks
> >> Hanjun
> >>
> > It's in rev D which is available now:
> > http://infocenter.arm.com/help/topic/com.arm.doc.den0049d/DEN0049D_IO_Remapping_Table.pdf
> 
> Thanks for let me know, I didn't notice the update :)
> 
> Lorenzo, do you have a plan for ACPICA changes?

We should be able to send them upstream very soon.

Thanks,
Lorenzo

Re: [PATCH 2/2] perf: add arm64 smmuv3 pmu driver

[Lorenzo Pieralisi]

On Tue, Apr 03, 2018 at 09:15:11AM +0800, Hanjun Guo wrote:
> [+Cc Lorenzo]
> 
> Hi Neil,
> 
> On 2018/4/3 1:59, Neil Leeder wrote:
> > Hi Hanjun,
> > 
> > On 4/2/2018 10:24 AM, Hanjun Guo wrote:
> > 
> >>
> >> I think we need to wait for the new version of IORT spec,
> >> which includes the fix for the two base address for SMMUv3
> >> PMCG (now just represent one).
> >>
> >> Thanks
> >> Hanjun
> >>
> > It's in rev D which is available now:
> > http://infocenter.arm.com/help/topic/com.arm.doc.den0049d/DEN0049D_IO_Remapping_Table.pdf
> 
> Thanks for let me know, I didn't notice the update :)
> 
> Lorenzo, do you have a plan for ACPICA changes?

We should be able to send them upstream very soon.

Thanks,
Lorenzo

Re: [PATCH v5 06/12] PCI: designware-ep: Make dw_pcie_ep_set_bar() handle 64-bit BARs properly

[Lorenzo Pieralisi]

On Mon, Apr 02, 2018 at 09:37:03PM +0200, Niklas Cassel wrote:
> On Thu, Mar 29, 2018 at 03:17:11PM +0530, Kishon Vijay Abraham I wrote:
> > Hi,
> > 
> > On Wednesday 28 March 2018 05:20 PM, Niklas Cassel wrote:
> > > Since a 64-bit BAR consists of a BAR pair, we need to write to both
> > > BARs in the BAR pair to setup the BAR properly.
> > > 
> > > Signed-off-by: Niklas Cassel 
> > > ---
> > >  drivers/pci/dwc/pcie-designware-ep.c | 11 +--
> > >  1 file changed, 9 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
> > > b/drivers/pci/dwc/pcie-designware-ep.c
> > > index 5a0bb53c795c..571b90f88d84 100644
> > > --- a/drivers/pci/dwc/pcie-designware-ep.c
> > > +++ b/drivers/pci/dwc/pcie-designware-ep.c
> > > @@ -138,8 +138,15 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, 
> > > u8 func_no,
> > >   return ret;
> > >  
> > >   dw_pcie_dbi_ro_wr_en(pci);
> > > - dw_pcie_writel_dbi2(pci, reg, size - 1);
> > > - dw_pcie_writel_dbi(pci, reg, flags);
> > > + if (flags & PCI_BASE_ADDRESS_MEM_TYPE_64) {
> > > + dw_pcie_writel_dbi2(pci, reg, lower_32_bits(size - 1));
> > > + dw_pcie_writel_dbi(pci, reg, flags);
> > > + dw_pcie_writel_dbi2(pci, reg + 4, upper_32_bits(size - 1));
> > > + dw_pcie_writel_dbi(pci, reg + 4, 0);
> > > + } else {
> > > + dw_pcie_writel_dbi2(pci, reg, size - 1);
> > > + dw_pcie_writel_dbi(pci, reg, flags);
> > > + }
> > 
> > 
> > I think this should work too?
> > dw_pcie_writel_dbi2(pci, reg, lower_32_bits(size - 1));
> > dw_pcie_writel_dbi(pci, reg, flags);
> > 
> > if (flags & PCI_BASE_ADDRESS_MEM_TYPE_64) {
> > dw_pcie_writel_dbi2(pci, reg + 4, upper_32_bits(size - 1));
> > dw_pcie_writel_dbi(pci, reg + 4, 0);
> > }
> > 
> 
> Hello Kishon,
> 
> I agree, your suggestion is more neat.
> 
> 
> Kishon, please tell me if you insist that the long if-statement
> in pci_epc_set_bar() should be split, since there are 5 different
> conditions. Because imho, having 5 succeeding if-statements isn't
> clearer than having 1 long if-statement.
> 
> If Kishon agrees with me, then the review comment in this mail
> seems to be the only review comment.
> And in that case, perhaps Lorenzo wouldn't mind fixing this up.
> Or perhaps Lorenzo prefers if I reroll the whole patch series?

I updated it myself in my pci/endpoint branch, please have a look, I
can't guarantee we can merge this for this cycle though, I will ask
Bjorn; apologies I could not be online for a while.

Lorenzo

> Kind regards,
> Niklas

Re: [PATCH v5 06/12] PCI: designware-ep: Make dw_pcie_ep_set_bar() handle 64-bit BARs properly

[Lorenzo Pieralisi]

On Mon, Apr 02, 2018 at 09:37:03PM +0200, Niklas Cassel wrote:
> On Thu, Mar 29, 2018 at 03:17:11PM +0530, Kishon Vijay Abraham I wrote:
> > Hi,
> > 
> > On Wednesday 28 March 2018 05:20 PM, Niklas Cassel wrote:
> > > Since a 64-bit BAR consists of a BAR pair, we need to write to both
> > > BARs in the BAR pair to setup the BAR properly.
> > > 
> > > Signed-off-by: Niklas Cassel 
> > > ---
> > >  drivers/pci/dwc/pcie-designware-ep.c | 11 +--
> > >  1 file changed, 9 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
> > > b/drivers/pci/dwc/pcie-designware-ep.c
> > > index 5a0bb53c795c..571b90f88d84 100644
> > > --- a/drivers/pci/dwc/pcie-designware-ep.c
> > > +++ b/drivers/pci/dwc/pcie-designware-ep.c
> > > @@ -138,8 +138,15 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, 
> > > u8 func_no,
> > >   return ret;
> > >  
> > >   dw_pcie_dbi_ro_wr_en(pci);
> > > - dw_pcie_writel_dbi2(pci, reg, size - 1);
> > > - dw_pcie_writel_dbi(pci, reg, flags);
> > > + if (flags & PCI_BASE_ADDRESS_MEM_TYPE_64) {
> > > + dw_pcie_writel_dbi2(pci, reg, lower_32_bits(size - 1));
> > > + dw_pcie_writel_dbi(pci, reg, flags);
> > > + dw_pcie_writel_dbi2(pci, reg + 4, upper_32_bits(size - 1));
> > > + dw_pcie_writel_dbi(pci, reg + 4, 0);
> > > + } else {
> > > + dw_pcie_writel_dbi2(pci, reg, size - 1);
> > > + dw_pcie_writel_dbi(pci, reg, flags);
> > > + }
> > 
> > 
> > I think this should work too?
> > dw_pcie_writel_dbi2(pci, reg, lower_32_bits(size - 1));
> > dw_pcie_writel_dbi(pci, reg, flags);
> > 
> > if (flags & PCI_BASE_ADDRESS_MEM_TYPE_64) {
> > dw_pcie_writel_dbi2(pci, reg + 4, upper_32_bits(size - 1));
> > dw_pcie_writel_dbi(pci, reg + 4, 0);
> > }
> > 
> 
> Hello Kishon,
> 
> I agree, your suggestion is more neat.
> 
> 
> Kishon, please tell me if you insist that the long if-statement
> in pci_epc_set_bar() should be split, since there are 5 different
> conditions. Because imho, having 5 succeeding if-statements isn't
> clearer than having 1 long if-statement.
> 
> If Kishon agrees with me, then the review comment in this mail
> seems to be the only review comment.
> And in that case, perhaps Lorenzo wouldn't mind fixing this up.
> Or perhaps Lorenzo prefers if I reroll the whole patch series?

I updated it myself in my pci/endpoint branch, please have a look, I
can't guarantee we can merge this for this cycle though, I will ask
Bjorn; apologies I could not be online for a while.

Lorenzo

> Kind regards,
> Niklas

Re: [PATCH v3]PCI: hv: fix PCI-BUS domainID corruption

[Lorenzo Pieralisi]

On Tue, Mar 20, 2018 at 11:00:36PM +, Sridhar Pitchai wrote:
> Hi Lorenzo,
>Transparent SRIOV is exposing the NIC directly to the kernel via
>para-virtual device, unlike creating a netdev and associating it
>with the bond driver. Further descriptions here,
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=0c195567a8f6e82ea5535cd9f1d54a1626dd233e
> 
> Previously, when using the bond driver, unique and persistent VF NIC
> name was required, so we used serial number as PCI domain which is
> included as part of the VF NIC name.  Transparent SRIOV mode puts VF
> NIC based on MAC match as a slave of synthetic NIC, so VF NIC’s name
> is no longer important.

Please read the link I sent you in relation to email formatting.

Then add your description above in a way that anyone not 100% familiar
with hyperv can understand it - that's what the commit log is for.

You are sending this patch to stable kernels, patch above has been in
the kernel from v4.14. The patch you are fixing since v4.11, you ought
to be careful since you do not want to have broken kernel versions owing
to stable patches mismatches, that's why I asked and I will ask again,
are you sure you won't trigger a regression by sending this fix to
stable ?

I assume the bond driver mechanism is now done and dusted.

Thanks,
Lorenzo

> Thanks,
> Sridhar
> 
> On 3/20/18, 11:32 AM, "Lorenzo Pieralisi" <lorenzo.pieral...@arm.com> wrote:
> 
> On Tue, Mar 20, 2018 at 05:56:15PM +, Sridhar Pitchai wrote:
> > Hi Lorenzo,
> 
> > Are we good with the explanation? Can I send the patch with the
> > updated commit comments?
> 
> Almost.
> 
> [...]
> 
> > Since we have the transparent SRIOV mode now, the short VF device 
> name
> > is no longer needed.
> 
> Can you correlate transparent SRIOV mode to the point you are making
> below ? Please explain what transparent SRIOV mode allows you to remove
> and why. The rest of the explanation seems OK.
> 
> Please follow this email format:
> 
> 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvger.kernel.org%2Flkml%2F%23s3-9=04%7C01%7CSridhar.Pitchai%40microsoft.com%7Cc5cdcb7951f64318e52708d58e90e6f2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636571675366181738%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1=yBdqc4NQZsO7O9vfgJsr5olU8GfLNjF5e9EAaCb7vq4%3D=0
> 
> Thanks,
> Lorenzo
> 
> > I still do not understand what this means and how it is related to 
> the
> > patch below, it may be clear to you, it is not to me, at all.
> > 
> > Sridhar >> the patch below, was introduced to make the device name 
> small, by taking only
> > 16bits of the serial number. Since we are not going to have the 
> serial number
> > updated to the BUS id, this has to be removed.
> > 
> > Fixes: 4a9b0933bdfc("PCI:hv:Use device serial number as PCI domain")
> > 
> > Fixes: 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI 
> domain")
> > Sridhr >> yes
> > 
> > I asked you an explicit question. Commit above was added for a 
> reason
> > I assume. This patch implies that kernel has been broken since v4.11
> > which is almost a year ago and nobody every noticed ? Or there are
> > systems where commit above is _necessary_ and this patch would break
> > them ?
> > 
> > I want a detailed explanation that highlights *why* it is safe to 
> apply
> > this patch and send it to stable kernels, commit log above won't do.
> > 
> > Sridhar>> HyperV provides a unique domain ID for PCI BUS. But it is 
> modified by the child
> > device when it is added. This cannot produce a unique domain ID all 
> the time.
> > Here in the bug, we see the collision between the serial number and 
> already
> > existing PCI bus. The cleaner way is never touch the domain ID 
> provided by
> > hyperV during the PCI bus creation. As long as hyperV make sure it 
> provides a
> > unique domain ID for the PCI for a VM it will not break, and HyperV 
> will
> > guarantees that the domain for the PCI bus for a given VM will be 
> always unique.
> > The original patch was also intending to have a unique domain ID 
> for the PCI
> > bus, by taking the serial number of the device, but it is not 
> sufficient, when
>

Re: [PATCH v3]PCI: hv: fix PCI-BUS domainID corruption

[Lorenzo Pieralisi]

On Tue, Mar 20, 2018 at 11:00:36PM +, Sridhar Pitchai wrote:
> Hi Lorenzo,
>Transparent SRIOV is exposing the NIC directly to the kernel via
>para-virtual device, unlike creating a netdev and associating it
>with the bond driver. Further descriptions here,
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=0c195567a8f6e82ea5535cd9f1d54a1626dd233e
> 
> Previously, when using the bond driver, unique and persistent VF NIC
> name was required, so we used serial number as PCI domain which is
> included as part of the VF NIC name.  Transparent SRIOV mode puts VF
> NIC based on MAC match as a slave of synthetic NIC, so VF NIC’s name
> is no longer important.

Please read the link I sent you in relation to email formatting.

Then add your description above in a way that anyone not 100% familiar
with hyperv can understand it - that's what the commit log is for.

You are sending this patch to stable kernels, patch above has been in
the kernel from v4.14. The patch you are fixing since v4.11, you ought
to be careful since you do not want to have broken kernel versions owing
to stable patches mismatches, that's why I asked and I will ask again,
are you sure you won't trigger a regression by sending this fix to
stable ?

I assume the bond driver mechanism is now done and dusted.

Thanks,
Lorenzo

> Thanks,
> Sridhar
> 
> On 3/20/18, 11:32 AM, "Lorenzo Pieralisi"  wrote:
> 
> On Tue, Mar 20, 2018 at 05:56:15PM +, Sridhar Pitchai wrote:
> > Hi Lorenzo,
> 
> > Are we good with the explanation? Can I send the patch with the
> > updated commit comments?
> 
> Almost.
> 
> [...]
> 
> > Since we have the transparent SRIOV mode now, the short VF device 
> name
> > is no longer needed.
> 
> Can you correlate transparent SRIOV mode to the point you are making
> below ? Please explain what transparent SRIOV mode allows you to remove
> and why. The rest of the explanation seems OK.
> 
> Please follow this email format:
> 
> 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvger.kernel.org%2Flkml%2F%23s3-9=04%7C01%7CSridhar.Pitchai%40microsoft.com%7Cc5cdcb7951f64318e52708d58e90e6f2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636571675366181738%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1=yBdqc4NQZsO7O9vfgJsr5olU8GfLNjF5e9EAaCb7vq4%3D=0
> 
> Thanks,
> Lorenzo
> 
> > I still do not understand what this means and how it is related to 
> the
> > patch below, it may be clear to you, it is not to me, at all.
> > 
> > Sridhar >> the patch below, was introduced to make the device name 
> small, by taking only
> > 16bits of the serial number. Since we are not going to have the 
> serial number
> > updated to the BUS id, this has to be removed.
> > 
> > Fixes: 4a9b0933bdfc("PCI:hv:Use device serial number as PCI domain")
> > 
> > Fixes: 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI 
> domain")
> > Sridhr >> yes
> > 
> > I asked you an explicit question. Commit above was added for a 
> reason
> > I assume. This patch implies that kernel has been broken since v4.11
> > which is almost a year ago and nobody every noticed ? Or there are
> > systems where commit above is _necessary_ and this patch would break
> > them ?
> > 
> > I want a detailed explanation that highlights *why* it is safe to 
> apply
> > this patch and send it to stable kernels, commit log above won't do.
> > 
> > Sridhar>> HyperV provides a unique domain ID for PCI BUS. But it is 
> modified by the child
> > device when it is added. This cannot produce a unique domain ID all 
> the time.
> > Here in the bug, we see the collision between the serial number and 
> already
> > existing PCI bus. The cleaner way is never touch the domain ID 
> provided by
> > hyperV during the PCI bus creation. As long as hyperV make sure it 
> provides a
> > unique domain ID for the PCI for a VM it will not break, and HyperV 
> will
> > guarantees that the domain for the PCI bus for a given VM will be 
> always unique.
> > The original patch was also intending to have a unique domain ID 
> for the PCI
> > bus, by taking the serial number of the device, but it is not 
> sufficient, when
> > the device seri

Re: [PATCH v3]PCI: hv: fix PCI-BUS domainID corruption

[Lorenzo Pieralisi]

On Tue, Mar 20, 2018 at 05:56:15PM +, Sridhar Pitchai wrote:
> Hi Lorenzo,

> Are we good with the explanation? Can I send the patch with the
> updated commit comments?

Almost.

[...]

> Since we have the transparent SRIOV mode now, the short VF device name
> is no longer needed.

Can you correlate transparent SRIOV mode to the point you are making
below ? Please explain what transparent SRIOV mode allows you to remove
and why. The rest of the explanation seems OK.

Please follow this email format:

http://vger.kernel.org/lkml/#s3-9

Thanks,
Lorenzo

> I still do not understand what this means and how it is related to the
> patch below, it may be clear to you, it is not to me, at all.
> 
> Sridhar >> the patch below, was introduced to make the device name small, 
> by taking only
> 16bits of the serial number. Since we are not going to have the serial 
> number
> updated to the BUS id, this has to be removed.
> 
> Fixes: 4a9b0933bdfc("PCI:hv:Use device serial number as PCI domain")
> 
> Fixes: 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain")
> Sridhr >> yes
> 
> I asked you an explicit question. Commit above was added for a reason
> I assume. This patch implies that kernel has been broken since v4.11
> which is almost a year ago and nobody every noticed ? Or there are
> systems where commit above is _necessary_ and this patch would break
> them ?
> 
> I want a detailed explanation that highlights *why* it is safe to apply
> this patch and send it to stable kernels, commit log above won't do.
> 
> Sridhar>> HyperV provides a unique domain ID for PCI BUS. But it is 
> modified by the child
> device when it is added. This cannot produce a unique domain ID all the 
> time.
> Here in the bug, we see the collision between the serial number and 
> already
> existing PCI bus. The cleaner way is never touch the domain ID provided by
> hyperV during the PCI bus creation. As long as hyperV make sure it 
> provides a
> unique domain ID for the PCI for a VM it will not break, and HyperV will
> guarantees that the domain for the PCI bus for a given VM will be always 
> unique.
> The original patch was also intending to have a unique domain ID for the 
> PCI
> bus, by taking the serial number of the device, but it is not sufficient, 
> when
> the device serial number is number which is the domain ID of the existing 
> PCI
> bus.  With the current kernel we can repro this issue by adding a device 
> with a
> serial number matching the existing PCI bus domain id. (in this case that
> happens to be zero).
> 
> 
> Thanks,
> Lorenzo
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Sridhar Pitchai 
> ---
> Changes in v3:
> * fix the commit comment. [KY Srinivasan, Michael Kelley]
> ---
>   drivers/pci/host/pci-hyperv.c | 11 ---
>   1 file changed, 11 deletions(-)
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index 2faf38e..ac67e56 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -1518,17 +1518,6 @@ static struct hv_pci_dev 
> *new_pcichild_device(struct hv_pcibus_device *hbus,
>   get_pcichild(hpdev, hv_pcidev_ref_childlist);
>   spin_lock_irqsave(>device_list_lock, flags);
>   
> - /*
> -  * When a device is being added to the bus, we set the PCI domain
> -  * number to be the device serial number, which is non-zero and
> -  * unique on the same VM.  The serial numbers start with 1, and
> -  * increase by 1 for each device.  So device names including this
> -  * can have shorter names than based on the bus instance UUID.
> -  * Only the first device serial number is used for domain, so the
> -  * domain number will not change after the first device is added.
> -  */
> - if (list_empty(>children))
> - hbus->sysdata.domain = desc->ser;
>   list_add_tail(>list_entry, >children);
>   spin_unlock_irqrestore(>device_list_lock, flags);
>   return hpdev;
> --
> 2.7.4 
> 
> 
> 

Re: [PATCH v3]PCI: hv: fix PCI-BUS domainID corruption

[Lorenzo Pieralisi]

On Tue, Mar 20, 2018 at 05:56:15PM +, Sridhar Pitchai wrote:
> Hi Lorenzo,

> Are we good with the explanation? Can I send the patch with the
> updated commit comments?

Almost.

[...]

> Since we have the transparent SRIOV mode now, the short VF device name
> is no longer needed.

Can you correlate transparent SRIOV mode to the point you are making
below ? Please explain what transparent SRIOV mode allows you to remove
and why. The rest of the explanation seems OK.

Please follow this email format:

http://vger.kernel.org/lkml/#s3-9

Thanks,
Lorenzo

> I still do not understand what this means and how it is related to the
> patch below, it may be clear to you, it is not to me, at all.
> 
> Sridhar >> the patch below, was introduced to make the device name small, 
> by taking only
> 16bits of the serial number. Since we are not going to have the serial 
> number
> updated to the BUS id, this has to be removed.
> 
> Fixes: 4a9b0933bdfc("PCI:hv:Use device serial number as PCI domain")
> 
> Fixes: 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain")
> Sridhr >> yes
> 
> I asked you an explicit question. Commit above was added for a reason
> I assume. This patch implies that kernel has been broken since v4.11
> which is almost a year ago and nobody every noticed ? Or there are
> systems where commit above is _necessary_ and this patch would break
> them ?
> 
> I want a detailed explanation that highlights *why* it is safe to apply
> this patch and send it to stable kernels, commit log above won't do.
> 
> Sridhar>> HyperV provides a unique domain ID for PCI BUS. But it is 
> modified by the child
> device when it is added. This cannot produce a unique domain ID all the 
> time.
> Here in the bug, we see the collision between the serial number and 
> already
> existing PCI bus. The cleaner way is never touch the domain ID provided by
> hyperV during the PCI bus creation. As long as hyperV make sure it 
> provides a
> unique domain ID for the PCI for a VM it will not break, and HyperV will
> guarantees that the domain for the PCI bus for a given VM will be always 
> unique.
> The original patch was also intending to have a unique domain ID for the 
> PCI
> bus, by taking the serial number of the device, but it is not sufficient, 
> when
> the device serial number is number which is the domain ID of the existing 
> PCI
> bus.  With the current kernel we can repro this issue by adding a device 
> with a
> serial number matching the existing PCI bus domain id. (in this case that
> happens to be zero).
> 
> 
> Thanks,
> Lorenzo
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Sridhar Pitchai 
> ---
> Changes in v3:
> * fix the commit comment. [KY Srinivasan, Michael Kelley]
> ---
>   drivers/pci/host/pci-hyperv.c | 11 ---
>   1 file changed, 11 deletions(-)
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index 2faf38e..ac67e56 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -1518,17 +1518,6 @@ static struct hv_pci_dev 
> *new_pcichild_device(struct hv_pcibus_device *hbus,
>   get_pcichild(hpdev, hv_pcidev_ref_childlist);
>   spin_lock_irqsave(>device_list_lock, flags);
>   
> - /*
> -  * When a device is being added to the bus, we set the PCI domain
> -  * number to be the device serial number, which is non-zero and
> -  * unique on the same VM.  The serial numbers start with 1, and
> -  * increase by 1 for each device.  So device names including this
> -  * can have shorter names than based on the bus instance UUID.
> -  * Only the first device serial number is used for domain, so the
> -  * domain number will not change after the first device is added.
> -  */
> - if (list_empty(>children))
> - hbus->sysdata.domain = desc->ser;
>   list_add_tail(>list_entry, >children);
>   spin_unlock_irqrestore(>device_list_lock, flags);
>   return hpdev;
> --
> 2.7.4 
> 
> 
> 

Re: [PATCH v4 0/5] PCI endpoint 64-bit BAR fixes

[Lorenzo Pieralisi]

On Thu, Mar 08, 2018 at 02:33:25PM +0100, Niklas Cassel wrote:
> PCI endpoint fixes to improve the way 64-bit BARs are handled.
> 
> 
> There are still future improvements that could be made:
> 
> pci-epf-test.c always allocates space for
> 6 BARs, even when using 64-bit BARs (which
> really only requires us to allocate 3 BARs).
> 
> pcitest.sh will print "NOT OKAY" for BAR1,
> BAR3, and BAR5 when using 64-bit BARs.
> This could probably be improved to say
> something like "N/A (64-bit BAR)".
> 
> Niklas Cassel (5):
>   PCI: endpoint: BAR width should not depend on sizeof dma_addr_t
>   PCI: designware-ep: Make dw_pcie_ep_set_bar() handle 64-bit BARs
> properly
>   PCI: designware-ep: Make dw_pcie_ep_reset_bar() handle 64-bit BARs
> properly
>   PCI: endpoint: Make pci_epc_set_bar() return the BAR width that was
> set-up
>   misc: pci_endpoint_test: Handle 64-bit BARs properly
> 
>  drivers/misc/pci_endpoint_test.c  | 12 +++-
>  drivers/pci/cadence/pcie-cadence-ep.c |  2 +-
>  drivers/pci/dwc/pcie-designware-ep.c  | 22 ++
>  drivers/pci/endpoint/functions/pci-epf-test.c | 22 +++---
>  4 files changed, 41 insertions(+), 17 deletions(-)

Niklas,

I am fine with the series but I'd need Kishon ACKs (and Greg's for the
last patch), I am ready to queue them then.

Thanks,
Lorenzo

Re: [PATCH v4 0/5] PCI endpoint 64-bit BAR fixes

[Lorenzo Pieralisi]

On Thu, Mar 08, 2018 at 02:33:25PM +0100, Niklas Cassel wrote:
> PCI endpoint fixes to improve the way 64-bit BARs are handled.
> 
> 
> There are still future improvements that could be made:
> 
> pci-epf-test.c always allocates space for
> 6 BARs, even when using 64-bit BARs (which
> really only requires us to allocate 3 BARs).
> 
> pcitest.sh will print "NOT OKAY" for BAR1,
> BAR3, and BAR5 when using 64-bit BARs.
> This could probably be improved to say
> something like "N/A (64-bit BAR)".
> 
> Niklas Cassel (5):
>   PCI: endpoint: BAR width should not depend on sizeof dma_addr_t
>   PCI: designware-ep: Make dw_pcie_ep_set_bar() handle 64-bit BARs
> properly
>   PCI: designware-ep: Make dw_pcie_ep_reset_bar() handle 64-bit BARs
> properly
>   PCI: endpoint: Make pci_epc_set_bar() return the BAR width that was
> set-up
>   misc: pci_endpoint_test: Handle 64-bit BARs properly
> 
>  drivers/misc/pci_endpoint_test.c  | 12 +++-
>  drivers/pci/cadence/pcie-cadence-ep.c |  2 +-
>  drivers/pci/dwc/pcie-designware-ep.c  | 22 ++
>  drivers/pci/endpoint/functions/pci-epf-test.c | 22 +++---
>  4 files changed, 41 insertions(+), 17 deletions(-)

Niklas,

I am fine with the series but I'd need Kishon ACKs (and Greg's for the
last patch), I am ready to queue them then.

Thanks,
Lorenzo

Re: [PATCH v4 1/5] PCI: endpoint: BAR width should not depend on sizeof dma_addr_t

[Lorenzo Pieralisi]

On Sat, Mar 17, 2018 at 01:55:13AM +0100, Niklas Cassel wrote:
> On Fri, Mar 16, 2018 at 06:02:20PM +0000, Lorenzo Pieralisi wrote:
> > On Thu, Mar 08, 2018 at 02:33:26PM +0100, Niklas Cassel wrote:
> > > If a BAR supports 64-bit width or not depends on the hardware,
> > > and should thus not depend on sizeof(dma_addr_t).
> > > 
> > > Since this driver is generic, default to always using BAR width
> > > of 32-bits. 64-bit BARs can easily be tested by replacing
> > > PCI_BASE_ADDRESS_MEM_TYPE_32 with PCI_BASE_ADDRESS_MEM_TYPE_64
> > > in bar_flags.
> > > 
> > > Signed-off-by: Niklas Cassel <niklas.cas...@axis.com>
> > > ---
> > > Note to Lorenzo/Bjorn:
> > > It is not trivial to convert the bar_size + bar_flags +
> > > struct pci_epf->bar member array to an array of struct resources,
> > > since we need to be able to store the addresses returned
> > > by dma_alloc_coherent(), which is of type dma_addr_t.
> > > struct resource uses resource_size_t, which is defined as phys_addr_t.
> > > E.g. ARTPEC-7 uses 64-bit dma_addr_t, but only 32-bit phys_addr_t.
> > > 
> > >  drivers/pci/endpoint/functions/pci-epf-test.c | 15 +--
> > >  1 file changed, 9 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> > > b/drivers/pci/endpoint/functions/pci-epf-test.c
> > > index 800da09d9005..7c70433b11a7 100644
> > > --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> > > +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> > > @@ -71,6 +71,14 @@ struct pci_epf_test_data {
> > >  };
> > >  
> > >  static int bar_size[] = { 512, 512, 1024, 16384, 131072, 1048576 };
> > > +static int bar_flags[] = {
> > > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> > > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> > > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> > > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> > > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> > > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32
> > > +};
> > 
> > Niklas,
> > 
> > I think you are almost there, I have one question though to address
> > that can even simplify the patchset.
> > 
> > If, according to your own commit logs (and my reading of the code), the
> > Cadence driver makes a decision on the BAR size just by checking the
> > corresponding region size (I would be happy to hear the reason
> > underpinning that choice, BTW), why can't we do the same for DWC (ie to
> > let the DWC driver decides whether a BAR should be 64 or 32 bits ?)
> 
> We could, but I think that would be a mistake.
> 
> The API that the user/"endpoint function" has available to configure
> the BARs:
> pci_epc_set_bar()
> 
> If the user, for some reason, wants to configure a BAR with a
> 64-bit width, even though the BAR size is less than 4 GB,
> I think that the API should allow that.

Yes, that's a good point, thanks a lot for the explanation.

Lorenzo

> This would not be possible if pci_epc_set_bar() would start to
> ignore PCI_BASE_ADDRESS_MEM_TYPE_64 from the flags parameter
> (and BAR width thus only being controlled by the size parameter).
> 
> int pci_epc_set_bar(struct pci_epc *epc, u8 func_no, enum pci_barno bar,
>   dma_addr_t bar_phys, size_t size, int flags);
> 
> 
> 
> Best regards,
> Niklas

Re: [PATCH v4 1/5] PCI: endpoint: BAR width should not depend on sizeof dma_addr_t

[Lorenzo Pieralisi]

On Sat, Mar 17, 2018 at 01:55:13AM +0100, Niklas Cassel wrote:
> On Fri, Mar 16, 2018 at 06:02:20PM +0000, Lorenzo Pieralisi wrote:
> > On Thu, Mar 08, 2018 at 02:33:26PM +0100, Niklas Cassel wrote:
> > > If a BAR supports 64-bit width or not depends on the hardware,
> > > and should thus not depend on sizeof(dma_addr_t).
> > > 
> > > Since this driver is generic, default to always using BAR width
> > > of 32-bits. 64-bit BARs can easily be tested by replacing
> > > PCI_BASE_ADDRESS_MEM_TYPE_32 with PCI_BASE_ADDRESS_MEM_TYPE_64
> > > in bar_flags.
> > > 
> > > Signed-off-by: Niklas Cassel 
> > > ---
> > > Note to Lorenzo/Bjorn:
> > > It is not trivial to convert the bar_size + bar_flags +
> > > struct pci_epf->bar member array to an array of struct resources,
> > > since we need to be able to store the addresses returned
> > > by dma_alloc_coherent(), which is of type dma_addr_t.
> > > struct resource uses resource_size_t, which is defined as phys_addr_t.
> > > E.g. ARTPEC-7 uses 64-bit dma_addr_t, but only 32-bit phys_addr_t.
> > > 
> > >  drivers/pci/endpoint/functions/pci-epf-test.c | 15 +--
> > >  1 file changed, 9 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> > > b/drivers/pci/endpoint/functions/pci-epf-test.c
> > > index 800da09d9005..7c70433b11a7 100644
> > > --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> > > +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> > > @@ -71,6 +71,14 @@ struct pci_epf_test_data {
> > >  };
> > >  
> > >  static int bar_size[] = { 512, 512, 1024, 16384, 131072, 1048576 };
> > > +static int bar_flags[] = {
> > > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> > > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> > > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> > > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> > > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> > > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32
> > > +};
> > 
> > Niklas,
> > 
> > I think you are almost there, I have one question though to address
> > that can even simplify the patchset.
> > 
> > If, according to your own commit logs (and my reading of the code), the
> > Cadence driver makes a decision on the BAR size just by checking the
> > corresponding region size (I would be happy to hear the reason
> > underpinning that choice, BTW), why can't we do the same for DWC (ie to
> > let the DWC driver decides whether a BAR should be 64 or 32 bits ?)
> 
> We could, but I think that would be a mistake.
> 
> The API that the user/"endpoint function" has available to configure
> the BARs:
> pci_epc_set_bar()
> 
> If the user, for some reason, wants to configure a BAR with a
> 64-bit width, even though the BAR size is less than 4 GB,
> I think that the API should allow that.

Yes, that's a good point, thanks a lot for the explanation.

Lorenzo

> This would not be possible if pci_epc_set_bar() would start to
> ignore PCI_BASE_ADDRESS_MEM_TYPE_64 from the flags parameter
> (and BAR width thus only being controlled by the size parameter).
> 
> int pci_epc_set_bar(struct pci_epc *epc, u8 func_no, enum pci_barno bar,
>   dma_addr_t bar_phys, size_t size, int flags);
> 
> 
> 
> Best regards,
> Niklas

Re: [PATCH v4 3/4] PCI: hv: Remove hbus->enum_sem

[Lorenzo Pieralisi]

On Fri, Mar 16, 2018 at 05:41:27PM +, Dexuan Cui wrote:
> > From: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
> > Sent: Friday, March 16, 2018 03:54
> > ...
> > Dexuan,
> > while applying/updating these patches I notice this one may be squashed
> > into: https://patchwork.ozlabs.org/patch/886266/
> > 
> > since they logically belong in the same patch. Are you OK with me doing
> > that ? Is my reading correct ?
> > Lorenzo
> 
> I'm OK. 
> I used two patches
> [PATCH v4 1/2] PCI: hv: Serialize the present and eject work items
> [PATCH v4 3/4] PCI: hv: Remove hbus->enum_sem
> only because the first fixed a real issue and hence IMO should go into
> stable kernels, and the second is only a cleanup patch, which doesn't
> need go into stable kernels.
> 
> Either way is ok to me. 
> Please feel free to do whatever you think is better. :-)

OK, patch series reworked and queued in my pci/hv branch please have
a look and let me know if that looks OK for you, I won't ask Bjorn
to move it into -next till you give me the go-ahead.

Thanks,
Lorenzo

Re: [PATCH v4 3/4] PCI: hv: Remove hbus->enum_sem

[Lorenzo Pieralisi]

On Fri, Mar 16, 2018 at 05:41:27PM +, Dexuan Cui wrote:
> > From: Lorenzo Pieralisi 
> > Sent: Friday, March 16, 2018 03:54
> > ...
> > Dexuan,
> > while applying/updating these patches I notice this one may be squashed
> > into: https://patchwork.ozlabs.org/patch/886266/
> > 
> > since they logically belong in the same patch. Are you OK with me doing
> > that ? Is my reading correct ?
> > Lorenzo
> 
> I'm OK. 
> I used two patches
> [PATCH v4 1/2] PCI: hv: Serialize the present and eject work items
> [PATCH v4 3/4] PCI: hv: Remove hbus->enum_sem
> only because the first fixed a real issue and hence IMO should go into
> stable kernels, and the second is only a cleanup patch, which doesn't
> need go into stable kernels.
> 
> Either way is ok to me. 
> Please feel free to do whatever you think is better. :-)

OK, patch series reworked and queued in my pci/hv branch please have
a look and let me know if that looks OK for you, I won't ask Bjorn
to move it into -next till you give me the go-ahead.

Thanks,
Lorenzo

Re: [PATCH v4 1/5] PCI: endpoint: BAR width should not depend on sizeof dma_addr_t

[Lorenzo Pieralisi]

On Thu, Mar 08, 2018 at 02:33:26PM +0100, Niklas Cassel wrote:
> If a BAR supports 64-bit width or not depends on the hardware,
> and should thus not depend on sizeof(dma_addr_t).
> 
> Since this driver is generic, default to always using BAR width
> of 32-bits. 64-bit BARs can easily be tested by replacing
> PCI_BASE_ADDRESS_MEM_TYPE_32 with PCI_BASE_ADDRESS_MEM_TYPE_64
> in bar_flags.
> 
> Signed-off-by: Niklas Cassel 
> ---
> Note to Lorenzo/Bjorn:
> It is not trivial to convert the bar_size + bar_flags +
> struct pci_epf->bar member array to an array of struct resources,
> since we need to be able to store the addresses returned
> by dma_alloc_coherent(), which is of type dma_addr_t.
> struct resource uses resource_size_t, which is defined as phys_addr_t.
> E.g. ARTPEC-7 uses 64-bit dma_addr_t, but only 32-bit phys_addr_t.
> 
>  drivers/pci/endpoint/functions/pci-epf-test.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> b/drivers/pci/endpoint/functions/pci-epf-test.c
> index 800da09d9005..7c70433b11a7 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -71,6 +71,14 @@ struct pci_epf_test_data {
>  };
>  
>  static int bar_size[] = { 512, 512, 1024, 16384, 131072, 1048576 };
> +static int bar_flags[] = {
> + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32
> +};

Niklas,

I think you are almost there, I have one question though to address
that can even simplify the patchset.

If, according to your own commit logs (and my reading of the code), the
Cadence driver makes a decision on the BAR size just by checking the
corresponding region size (I would be happy to hear the reason
underpinning that choice, BTW), why can't we do the same for DWC (ie to
let the DWC driver decides whether a BAR should be 64 or 32 bits ?)

This would mean that in this patch we would not bother about the BAR
32/64 size flag at all.

Thoughts ?

Lorenzo

>  
>  static int pci_epf_test_copy(struct pci_epf_test *epf_test)
>  {
> @@ -358,7 +366,6 @@ static void pci_epf_test_unbind(struct pci_epf *epf)
>  
>  static int pci_epf_test_set_bar(struct pci_epf *epf)
>  {
> - int flags;
>   int bar;
>   int ret;
>   struct pci_epf_bar *epf_bar;
> @@ -367,15 +374,11 @@ static int pci_epf_test_set_bar(struct pci_epf *epf)
>   struct pci_epf_test *epf_test = epf_get_drvdata(epf);
>   enum pci_barno test_reg_bar = epf_test->test_reg_bar;
>  
> - flags = PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32;
> - if (sizeof(dma_addr_t) == 0x8)
> - flags |= PCI_BASE_ADDRESS_MEM_TYPE_64;
> -
>   for (bar = BAR_0; bar <= BAR_5; bar++) {
>   epf_bar = >bar[bar];
>   ret = pci_epc_set_bar(epc, epf->func_no, bar,
> epf_bar->phys_addr,
> -   epf_bar->size, flags);
> +   epf_bar->size, bar_flags[bar]);
>   if (ret) {
>   pci_epf_free_space(epf, epf_test->reg[bar], bar);
>   dev_err(dev, "failed to set BAR%d\n", bar);
> -- 
> 2.14.2
> 

Re: [PATCH v4 1/5] PCI: endpoint: BAR width should not depend on sizeof dma_addr_t

[Lorenzo Pieralisi]

On Thu, Mar 08, 2018 at 02:33:26PM +0100, Niklas Cassel wrote:
> If a BAR supports 64-bit width or not depends on the hardware,
> and should thus not depend on sizeof(dma_addr_t).
> 
> Since this driver is generic, default to always using BAR width
> of 32-bits. 64-bit BARs can easily be tested by replacing
> PCI_BASE_ADDRESS_MEM_TYPE_32 with PCI_BASE_ADDRESS_MEM_TYPE_64
> in bar_flags.
> 
> Signed-off-by: Niklas Cassel 
> ---
> Note to Lorenzo/Bjorn:
> It is not trivial to convert the bar_size + bar_flags +
> struct pci_epf->bar member array to an array of struct resources,
> since we need to be able to store the addresses returned
> by dma_alloc_coherent(), which is of type dma_addr_t.
> struct resource uses resource_size_t, which is defined as phys_addr_t.
> E.g. ARTPEC-7 uses 64-bit dma_addr_t, but only 32-bit phys_addr_t.
> 
>  drivers/pci/endpoint/functions/pci-epf-test.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> b/drivers/pci/endpoint/functions/pci-epf-test.c
> index 800da09d9005..7c70433b11a7 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -71,6 +71,14 @@ struct pci_epf_test_data {
>  };
>  
>  static int bar_size[] = { 512, 512, 1024, 16384, 131072, 1048576 };
> +static int bar_flags[] = {
> + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32
> +};

Niklas,

I think you are almost there, I have one question though to address
that can even simplify the patchset.

If, according to your own commit logs (and my reading of the code), the
Cadence driver makes a decision on the BAR size just by checking the
corresponding region size (I would be happy to hear the reason
underpinning that choice, BTW), why can't we do the same for DWC (ie to
let the DWC driver decides whether a BAR should be 64 or 32 bits ?)

This would mean that in this patch we would not bother about the BAR
32/64 size flag at all.

Thoughts ?

Lorenzo

>  
>  static int pci_epf_test_copy(struct pci_epf_test *epf_test)
>  {
> @@ -358,7 +366,6 @@ static void pci_epf_test_unbind(struct pci_epf *epf)
>  
>  static int pci_epf_test_set_bar(struct pci_epf *epf)
>  {
> - int flags;
>   int bar;
>   int ret;
>   struct pci_epf_bar *epf_bar;
> @@ -367,15 +374,11 @@ static int pci_epf_test_set_bar(struct pci_epf *epf)
>   struct pci_epf_test *epf_test = epf_get_drvdata(epf);
>   enum pci_barno test_reg_bar = epf_test->test_reg_bar;
>  
> - flags = PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32;
> - if (sizeof(dma_addr_t) == 0x8)
> - flags |= PCI_BASE_ADDRESS_MEM_TYPE_64;
> -
>   for (bar = BAR_0; bar <= BAR_5; bar++) {
>   epf_bar = >bar[bar];
>   ret = pci_epc_set_bar(epc, epf->func_no, bar,
> epf_bar->phys_addr,
> -   epf_bar->size, flags);
> +   epf_bar->size, bar_flags[bar]);
>   if (ret) {
>   pci_epf_free_space(epf, epf_test->reg[bar], bar);
>   dev_err(dev, "failed to set BAR%d\n", bar);
> -- 
> 2.14.2
> 

Re: [PATCH v5 2/2] PCI: mediatek: Set up class type and vendor ID for MT7622

[Lorenzo Pieralisi]

On Wed, Jan 03, 2018 at 02:39:04PM +0800, Honghui Zhang wrote:
> On Tue, 2018-01-02 at 10:56 +0000, Lorenzo Pieralisi wrote:
> > On Thu, Dec 28, 2017 at 09:39:12AM +0800, Honghui Zhang wrote:
> > > On Wed, 2017-12-27 at 12:45 -0600, Bjorn Helgaas wrote:
> > > > On Wed, Dec 27, 2017 at 08:59:54AM +0800, honghui.zh...@mediatek.com 
> > > > wrote:
> > > > > From: Honghui Zhang <honghui.zh...@mediatek.com>
> > > > > 
> 
> > > > > + /* Set up class code for MT7622 */
> > > > > + val = PCI_CLASS_BRIDGE_PCI << 16;
> > > > > + writel(val, port->base + PCIE_CONF_CLASS);
> > > > 
> > > > 1) Your comments mention MT7622 specifically, but this code is run for
> > > > both mt2712-pcie and mt7622-pcie.  If this code is safe and necessary
> > > > for both mt2712-pcie and mt7622-pcie, please remove the mention of
> > > > MT7622.
> > > 
> > > Hmm, the code snippet added here will only be executed by MT7622, since
> > > MT2712 will not enter this  "if (pcie->base) {"  condition.
> > > Should the mention of MT7622 must be removed in this case?
> > 
> > You should add an explicit way (eg of_device_is_compatible() match for
> > instance) to apply the quirk just on the platform that requires it.
> > 
> > Checking for "if (pcie->base)" is really not the way to do it.
> > 
> 
> hi, Lorenzo,
> Thanks very much for your advise.
> Passing the compatible string or platform data into this function needed
> to add some new field in the struct mtk_pcie_port, then I guess both set
> it for MT2712 and MT7622 is an easy way, since re-setting those values
> for MT2712 is safe.
> 
> > > > 2) The first comment mentions both "vendor ID and device ID" but you
> > > > don't write the device ID.  Since this code applies to both
> > > > mt2712-pcie and mt7622-pcie, my guess is that you don't *want* to
> > > > write the device ID.  If that's the case, please fix the comment.
> > > > 
> > > 
> > > My bad, I did not check the comments carefully.
> > > Thanks.
> > > 
> > > > 3) If you only need to set the vendor ID, you're performing a 32-bit
> > > > write (writel()) to update a 16-bit value.  Please use writew()
> > > > instead.
> > > > 
> > > 
> > > Ok, thanks, I guess I could use the following code snippet in the next
> > > version:
> > > val = readl(port->base + PCIE_CONF_VENDOR_ID)
> > > val &= ~GENMASK(15, 0);
> > > val |= PCI_VENDOR_ID_MEDIATEK;
> > > writel(val, port->base + PCIE_CONF_VENDOR_ID);
> > 
> > Have you read Bjorn's comment ? Or there is a problem with using
> > a writew() ?
> > 
> 
> This control register is a 32bit register, I'm not sure whether the apb
> bus support write an 16bit value with 16bit but not 32bit address
> alignment. I prefer the more safety old way of writel.
> 
> I need to do more test about the writew if the code elegant is more
> important.

I will mark this patch as "Changes Requested" waiting for a new
version, thanks.

Lorenzo

Re: [PATCH v5 2/2] PCI: mediatek: Set up class type and vendor ID for MT7622

[Lorenzo Pieralisi]

On Wed, Jan 03, 2018 at 02:39:04PM +0800, Honghui Zhang wrote:
> On Tue, 2018-01-02 at 10:56 +0000, Lorenzo Pieralisi wrote:
> > On Thu, Dec 28, 2017 at 09:39:12AM +0800, Honghui Zhang wrote:
> > > On Wed, 2017-12-27 at 12:45 -0600, Bjorn Helgaas wrote:
> > > > On Wed, Dec 27, 2017 at 08:59:54AM +0800, honghui.zh...@mediatek.com 
> > > > wrote:
> > > > > From: Honghui Zhang 
> > > > > 
> 
> > > > > + /* Set up class code for MT7622 */
> > > > > + val = PCI_CLASS_BRIDGE_PCI << 16;
> > > > > + writel(val, port->base + PCIE_CONF_CLASS);
> > > > 
> > > > 1) Your comments mention MT7622 specifically, but this code is run for
> > > > both mt2712-pcie and mt7622-pcie.  If this code is safe and necessary
> > > > for both mt2712-pcie and mt7622-pcie, please remove the mention of
> > > > MT7622.
> > > 
> > > Hmm, the code snippet added here will only be executed by MT7622, since
> > > MT2712 will not enter this  "if (pcie->base) {"  condition.
> > > Should the mention of MT7622 must be removed in this case?
> > 
> > You should add an explicit way (eg of_device_is_compatible() match for
> > instance) to apply the quirk just on the platform that requires it.
> > 
> > Checking for "if (pcie->base)" is really not the way to do it.
> > 
> 
> hi, Lorenzo,
> Thanks very much for your advise.
> Passing the compatible string or platform data into this function needed
> to add some new field in the struct mtk_pcie_port, then I guess both set
> it for MT2712 and MT7622 is an easy way, since re-setting those values
> for MT2712 is safe.
> 
> > > > 2) The first comment mentions both "vendor ID and device ID" but you
> > > > don't write the device ID.  Since this code applies to both
> > > > mt2712-pcie and mt7622-pcie, my guess is that you don't *want* to
> > > > write the device ID.  If that's the case, please fix the comment.
> > > > 
> > > 
> > > My bad, I did not check the comments carefully.
> > > Thanks.
> > > 
> > > > 3) If you only need to set the vendor ID, you're performing a 32-bit
> > > > write (writel()) to update a 16-bit value.  Please use writew()
> > > > instead.
> > > > 
> > > 
> > > Ok, thanks, I guess I could use the following code snippet in the next
> > > version:
> > > val = readl(port->base + PCIE_CONF_VENDOR_ID)
> > > val &= ~GENMASK(15, 0);
> > > val |= PCI_VENDOR_ID_MEDIATEK;
> > > writel(val, port->base + PCIE_CONF_VENDOR_ID);
> > 
> > Have you read Bjorn's comment ? Or there is a problem with using
> > a writew() ?
> > 
> 
> This control register is a 32bit register, I'm not sure whether the apb
> bus support write an 16bit value with 16bit but not 32bit address
> alignment. I prefer the more safety old way of writel.
> 
> I need to do more test about the writew if the code elegant is more
> important.

I will mark this patch as "Changes Requested" waiting for a new
version, thanks.

Lorenzo