Re: [PATCH for-next] scsi: ufs: Update dwc driver maintainer to Pedro Sousa

[Joao Pinto]

Thanks Martin.

On 2/5/2019 3:37 AM, Martin K. Petersen wrote:
> Joao,
>
>> Currently I am managing the Synopsys drivers & tools team (full-time) and
>> so I am passing the DWC UFS driver maintenance to Pedro Sousa.
> Applied to 5.1/scsi-queue, thanks.
>

Re: [PATCH for-next] scsi: ufs: Update dwc driver maintainer to Pedro Sousa

[Joao Pinto]

Hello Bart,

First of all thanks for the feedback.

On 1/30/2019 5:54 PM, Bart Van Assche wrote:
> On Wed, 2019-01-30 at 18:48 +0100, Joao Pinto wrote:
>> Currently I am managing the Synopsys drivers & tools team (full-time) and
>> so I am passing the DWC UFS driver maintenance to Pedro Sousa.
>>
>> Signed-off-by: Joao Pinto 
>> Cc: Pedro Sousa 
>> Cc: Marc Gonzalez 
>> Cc: Alex Lemberg 
>> ---
>>  MAINTAINERS | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 70c93b1..458a2a2 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -15673,7 +15673,7 @@ F:   Documentation/scsi/ufs.txt
>>  F:  drivers/scsi/ufs/
>>  
>>  UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER DWC HOOKS
>> -M:  Joao Pinto 
>> +M:  Pedro Sousa 
>>  L:  linux-s...@vger.kernel.org
>>  S:  Supported
>>  F:  drivers/scsi/ufs/*dwc*
> Shouldn't people have proven to be willing to stick around before being
> added as a kernel maintainer? Additionally, what is the experience level of
> Pedro with kernel development? All I know is the following:

Pedro Sousa is my team member and has been working in Unipro/UFS Synopsys
drivers for almost 2 years.

His work has been mainly internal, and now our goal is to start using the
mainline DWC UFS driver I submitted 2 years ago in our regular activities,
update and maintain it effectively as we are doing in other titles.

Currently I am Pedro' manager, and in my opinion he has the right experience for
this step and that is why I am suggesting to transfer Synopsys driver
maintenance from me to him.

>
> $ git log --author "Pedro Sousa" | wc -l
> 0
> $ git log | grep -c "Pedro Sousa"
> 0
>
> Are you aware that people who are not mentioned in the MAINTAINERS file are
> allowed to review kernel patches?

Yes, I am aware and Pedro is perfectly capable of doing that, and for that
reason I am suggesting him as the right person to maintain Synopsys UFS driver.

>
> Thanks,
>
> Bart.
>
Thanks,

Joao

[PATCH for-next] scsi: ufs: Update dwc driver maintainer to Pedro Sousa

[Joao Pinto]

Currently I am managing the Synopsys drivers & tools team (full-time) and
so I am passing the DWC UFS driver maintenance to Pedro Sousa.

Signed-off-by: Joao Pinto 
Cc: Pedro Sousa 
Cc: Marc Gonzalez 
Cc: Alex Lemberg 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 70c93b1..458a2a2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15673,7 +15673,7 @@ F:  Documentation/scsi/ufs.txt
 F: drivers/scsi/ufs/
 
 UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER DWC HOOKS
-M: Joao Pinto 
+M: Pedro Sousa 
 L: linux-s...@vger.kernel.org
 S: Supported
 F: drivers/scsi/ufs/*dwc*
-- 
2.7.4

[PATCH] PCI: designware: Change maintainer to Gustavo Pimentel

[Joao Pinto]

Currently I am managing the Synopsys drivers & tools team (full-time) and so I
am passing the pcie-designware maintenance to Gustavo.

Signed-off-by: Joao Pinto 
CC: Gustavo Pimentel 
CC: Jingoo Han 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a5b256b..e5e8984 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11153,7 +11153,7 @@ F:  drivers/pci/controller/dwc/pci-exynos.c
 
 PCI DRIVER FOR SYNOPSYS DESIGNWARE
 M: Jingoo Han 
-M: Joao Pinto 
+M: Gustavo Pimentel 
 L: linux-...@vger.kernel.org
 S: Maintained
 F: Documentation/devicetree/bindings/pci/designware-pcie.txt
-- 
2.9.3

[PATCH] PCI: designware: Change maintainer to Gustavo Pimentel

[Joao Pinto]

Currently I am managing the Synopsys drivers & tools team (full-time) and so I
am passing the pcie-designware maintenance to Gustavo.

Signed-off-by: Joao Pinto 
CC: Gustavo Pimentel 
CC: Jingoo Han 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a5b256b..e5e8984 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11153,7 +11153,7 @@ F:  drivers/pci/controller/dwc/pci-exynos.c
 
 PCI DRIVER FOR SYNOPSYS DESIGNWARE
 M: Jingoo Han 
-M: Joao Pinto 
+M: Gustavo Pimentel 
 L: linux-...@vger.kernel.org
 S: Maintained
 F: Documentation/devicetree/bindings/pci/designware-pcie.txt
-- 
2.9.3

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

[Joao Pinto]

Hi Gustavo,

Às 8:13 AM de 5/15/2018, Gustavo Pimentel escreveu:
> 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|  41 --
>  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, 206 insertions(+), 27 deletions(-)
> 

Thanks for this patch-set.

Reviewed-by: Joao Pinto <jpi...@synopsys.com>

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

[Joao Pinto]

Hi Gustavo,

Às 8:13 AM de 5/15/2018, Gustavo Pimentel escreveu:
> 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|  41 --
>  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, 206 insertions(+), 27 deletions(-)
> 

Thanks for this patch-set.

Reviewed-by: Joao Pinto 

Re: [PATCH v4 6/8] PCI: Rework of_pci_get_host_bridge_resources() to devm_of_pci_get_host_bridge_resources()

[Joao Pinto]

Hi Jan,

Às 10:07 AM de 5/15/2018, Jan Kiszka escreveu:
> From: Jan Kiszka <jan.kis...@siemens.com>
> 
> of_pci_get_host_bridge_resources() allocates the resource structures it
> fills dynamically, but none of its callers care to release them so far.
> Rather than requiring everyone to do this explicitly, convert the
> existing function to a managed version.
> 
> 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>
> ---
>  drivers/pci/dwc/pcie-designware-host.c |  2 +-
>  drivers/pci/host/pci-aardvark.c|  2 +-
>  drivers/pci/host/pci-ftpci100.c|  2 +-
>  drivers/pci/host/pci-v3-semi.c |  2 +-
>  drivers/pci/host/pci-versatile.c   |  2 +-
>  drivers/pci/host/pci-xgene.c   |  2 +-
>  drivers/pci/host/pcie-altera.c |  2 +-
>  drivers/pci/host/pcie-iproc-platform.c |  2 +-
>  drivers/pci/host/pcie-rcar.c   |  2 +-
>  drivers/pci/host/pcie-rockchip.c   |  2 +-
>  drivers/pci/host/pcie-xilinx-nwl.c |  2 +-
>  drivers/pci/host/pcie-xilinx.c |  2 +-
>  drivers/pci/of.c   | 30 --
>  include/linux/of_pci.h |  4 ++--
>  14 files changed, 26 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-host.c 
> b/drivers/pci/dwc/pcie-designware-host.c
> index 5a535690b7b5..a8f6ab54b4c0 100644
> --- a/drivers/pci/dwc/pcie-designware-host.c
> +++ b/drivers/pci/dwc/pcie-designware-host.c
> @@ -342,7 +342,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
>   if (!bridge)
>   return -ENOMEM;
>  
> - ret = of_pci_get_host_bridge_resources(dev, 0, 0xff,
> + ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
>   >windows, >io_base);
>   if (ret)
>   return ret;

(snip...)

Thanks for this patch!

Acked-by: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH v4 6/8] PCI: Rework of_pci_get_host_bridge_resources() to devm_of_pci_get_host_bridge_resources()

[Joao Pinto]

Hi Jan,

Às 10:07 AM de 5/15/2018, Jan Kiszka escreveu:
> From: Jan Kiszka 
> 
> of_pci_get_host_bridge_resources() allocates the resource structures it
> fills dynamically, but none of its callers care to release them so far.
> Rather than requiring everyone to do this explicitly, convert the
> existing function to a managed version.
> 
> CC: Jingoo Han 
> CC: Joao Pinto 
> CC: Lorenzo Pieralisi 
> Signed-off-by: Jan Kiszka 
> ---
>  drivers/pci/dwc/pcie-designware-host.c |  2 +-
>  drivers/pci/host/pci-aardvark.c|  2 +-
>  drivers/pci/host/pci-ftpci100.c|  2 +-
>  drivers/pci/host/pci-v3-semi.c |  2 +-
>  drivers/pci/host/pci-versatile.c   |  2 +-
>  drivers/pci/host/pci-xgene.c   |  2 +-
>  drivers/pci/host/pcie-altera.c |  2 +-
>  drivers/pci/host/pcie-iproc-platform.c |  2 +-
>  drivers/pci/host/pcie-rcar.c   |  2 +-
>  drivers/pci/host/pcie-rockchip.c   |  2 +-
>  drivers/pci/host/pcie-xilinx-nwl.c |  2 +-
>  drivers/pci/host/pcie-xilinx.c |  2 +-
>  drivers/pci/of.c   | 30 --
>  include/linux/of_pci.h |  4 ++--
>  14 files changed, 26 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-host.c 
> b/drivers/pci/dwc/pcie-designware-host.c
> index 5a535690b7b5..a8f6ab54b4c0 100644
> --- a/drivers/pci/dwc/pcie-designware-host.c
> +++ b/drivers/pci/dwc/pcie-designware-host.c
> @@ -342,7 +342,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
>   if (!bridge)
>   return -ENOMEM;
>  
> - ret = of_pci_get_host_bridge_resources(dev, 0, 0xff,
> + ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
>       >windows, >io_base);
>   if (ret)
>   return ret;

(snip...)

Thanks for this patch!

Acked-by: Joao Pinto 

Re: [PATCH 2/4] PCI: dwc: Add support for EP mode

[Joao Pinto]

 if (IS_ERR(pci->dbi_base))
>   return PTR_ERR(pci->dbi_base);
>  
>   platform_set_drvdata(pdev, dw_plat_pcie);
>  
> - ret = dw_plat_add_pcie_port(>pp, pdev);
> - if (ret < 0)
> - return ret;
> + switch (dw_plat_pcie->mode) {
> + case DW_PCIE_RC_TYPE:
> + if (!IS_ENABLED(CONFIG_PCIE_DW_PLAT_HOST))
> + return -ENODEV;
> +
> + ret = dw_plat_add_pcie_port(dw_plat_pcie, pdev);
> + if (ret < 0)
> + return ret;
> + break;
> + case DW_PCIE_EP_TYPE:
> + if (!IS_ENABLED(CONFIG_PCIE_DW_PLAT_EP))
> + return -ENODEV;
> +
> + ret = dw_plat_add_pcie_ep(dw_plat_pcie, pdev);
> + if (ret < 0)
> + return ret;
> + break;
> + default:
> + dev_err(dev, "INVALID device type %d\n", dw_plat_pcie->mode);
> + }
>  
>   return 0;
>  }
>  
> +static const struct dw_plat_pcie_of_data dw_plat_pcie_rc_of_data = {
> + .mode = DW_PCIE_RC_TYPE,
> +};
> +
> +static const struct dw_plat_pcie_of_data dw_plat_pcie_ep_of_data = {
> + .mode = DW_PCIE_EP_TYPE,
> +};
> +
>  static const struct of_device_id dw_plat_pcie_of_match[] = {
> - { .compatible = "snps,dw-pcie", },
> + {
> + .compatible = "snps,dw-pcie",
> + .data = _plat_pcie_rc_of_data,
> + },
> + {
> + .compatible = "snps,dw-pcie-ep",
> + .data = _plat_pcie_ep_of_data,
> + },
>   {},
>  };
>  
> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> b/drivers/pci/endpoint/functions/pci-epf-test.c
> index 7cef851..bee401d 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -435,6 +435,13 @@ static int pci_epf_test_bind(struct pci_epf *epf)
>   if (WARN_ON_ONCE(!epc))
>   return -EINVAL;
>  
> + if (epc->features & EPC_FEATURE_NO_LINKUP_NOTIFIER)
> + epf_test->linkup_notifier = false;
> + else
> + epf_test->linkup_notifier = true;
> +
> + epf_test->test_reg_bar = EPC_FEATURE_GET_BAR(epc->features);
> +
>   ret = pci_epc_write_header(epc, epf->func_no, header);
>   if (ret) {
>   dev_err(dev, "configuration header write failed\n");
> diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
> index af657ca..243eaa5 100644
> --- a/include/linux/pci-epc.h
> +++ b/include/linux/pci-epc.h
> @@ -90,8 +90,16 @@ struct pci_epc {
>   struct config_group *group;
>   /* spinlock to protect against concurrent access of EP controller */
>   spinlock_t  lock;
> + unsigned intfeatures;
>  };
>  
> +#define EPC_FEATURE_NO_LINKUP_NOTIFIER   BIT(0)
> +#define EPC_FEATURE_BAR_MASK (BIT(1) | BIT(2) | BIT(3))
> +#define EPC_FEATURE_SET_BAR(features, bar)   \
> + (features |= (EPC_FEATURE_BAR_MASK & (bar << 1)))
> +#define EPC_FEATURE_GET_BAR(features)\
> + ((features & EPC_FEATURE_BAR_MASK) >> 1)
> +
>  #define to_pci_epc(device) container_of((device), struct pci_epc, dev)
>  
>  #define pci_epc_create(dev, ops)\
> 


Acked-by: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH 2/4] PCI: dwc: Add support for EP mode

[Joao Pinto]

  return PTR_ERR(pci->dbi_base);
>  
>   platform_set_drvdata(pdev, dw_plat_pcie);
>  
> - ret = dw_plat_add_pcie_port(>pp, pdev);
> - if (ret < 0)
> - return ret;
> + switch (dw_plat_pcie->mode) {
> + case DW_PCIE_RC_TYPE:
> + if (!IS_ENABLED(CONFIG_PCIE_DW_PLAT_HOST))
> + return -ENODEV;
> +
> + ret = dw_plat_add_pcie_port(dw_plat_pcie, pdev);
> + if (ret < 0)
> + return ret;
> + break;
> + case DW_PCIE_EP_TYPE:
> + if (!IS_ENABLED(CONFIG_PCIE_DW_PLAT_EP))
> + return -ENODEV;
> +
> + ret = dw_plat_add_pcie_ep(dw_plat_pcie, pdev);
> + if (ret < 0)
> + return ret;
> + break;
> + default:
> + dev_err(dev, "INVALID device type %d\n", dw_plat_pcie->mode);
> + }
>  
>   return 0;
>  }
>  
> +static const struct dw_plat_pcie_of_data dw_plat_pcie_rc_of_data = {
> + .mode = DW_PCIE_RC_TYPE,
> +};
> +
> +static const struct dw_plat_pcie_of_data dw_plat_pcie_ep_of_data = {
> + .mode = DW_PCIE_EP_TYPE,
> +};
> +
>  static const struct of_device_id dw_plat_pcie_of_match[] = {
> - { .compatible = "snps,dw-pcie", },
> + {
> + .compatible = "snps,dw-pcie",
> + .data = _plat_pcie_rc_of_data,
> + },
> + {
> + .compatible = "snps,dw-pcie-ep",
> + .data = _plat_pcie_ep_of_data,
> + },
>   {},
>  };
>  
> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
> b/drivers/pci/endpoint/functions/pci-epf-test.c
> index 7cef851..bee401d 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -435,6 +435,13 @@ static int pci_epf_test_bind(struct pci_epf *epf)
>   if (WARN_ON_ONCE(!epc))
>   return -EINVAL;
>  
> + if (epc->features & EPC_FEATURE_NO_LINKUP_NOTIFIER)
> + epf_test->linkup_notifier = false;
> + else
> + epf_test->linkup_notifier = true;
> +
> + epf_test->test_reg_bar = EPC_FEATURE_GET_BAR(epc->features);
> +
>   ret = pci_epc_write_header(epc, epf->func_no, header);
>   if (ret) {
>   dev_err(dev, "configuration header write failed\n");
> diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
> index af657ca..243eaa5 100644
> --- a/include/linux/pci-epc.h
> +++ b/include/linux/pci-epc.h
> @@ -90,8 +90,16 @@ struct pci_epc {
>   struct config_group *group;
>   /* spinlock to protect against concurrent access of EP controller */
>   spinlock_t  lock;
> + unsigned intfeatures;
>  };
>  
> +#define EPC_FEATURE_NO_LINKUP_NOTIFIER   BIT(0)
> +#define EPC_FEATURE_BAR_MASK (BIT(1) | BIT(2) | BIT(3))
> +#define EPC_FEATURE_SET_BAR(features, bar)   \
> + (features |= (EPC_FEATURE_BAR_MASK & (bar << 1)))
> +#define EPC_FEATURE_GET_BAR(features)\
> + ((features & EPC_FEATURE_BAR_MASK) >> 1)
> +
>  #define to_pci_epc(device) container_of((device), struct pci_epc, dev)
>  
>  #define pci_epc_create(dev, ops)\
> 


Acked-by: Joao Pinto 

Re: [PATCH v5 09/10] PCI: dwc: Small computation improvement

[Joao Pinto]

Às 3:34 PM de 4/17/2018, Gustavo Pimentel escreveu:
> Replaces a simple division by 2 to a right shift rotation of 1 bit.
> 
> Probably any recent and decent compiler does this kind of substitution
> in order to improve code performance. Nevertheless it's a coding good
> practice whenever there is a division / multiplication by multiple of 2
> to replace it by the equivalent operation in this case, the shift
> rotation.
> 
> Signed-off-by: Gustavo Pimentel <gustavo.pimen...@synopsys.com>
> ---
> Change v1->v2:
>  - Nothing changed, just to follow the patch set version.
> Change v2->v3:
>  - Nothing changed, just to follow the patch set version.
> Changes v3->v4:
>  - Added a small explication to the log description.
> Changes v4->v5:
>  - Nothing changed, just to follow the patch set version.
> 
>  drivers/pci/dwc/pcie-designware-host.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-host.c 
> b/drivers/pci/dwc/pcie-designware-host.c
> index 5a23f78..fc55fde 100644
> --- a/drivers/pci/dwc/pcie-designware-host.c
> +++ b/drivers/pci/dwc/pcie-designware-host.c
> @@ -332,8 +332,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
>  
>   cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "config");
>   if (cfg_res) {
> - pp->cfg0_size = resource_size(cfg_res) / 2;
> - pp->cfg1_size = resource_size(cfg_res) / 2;
> + pp->cfg0_size = resource_size(cfg_res) >> 1;
> + pp->cfg1_size = resource_size(cfg_res) >> 1;
>   pp->cfg0_base = cfg_res->start;
>   pp->cfg1_base = cfg_res->start + pp->cfg0_size;
>   } else if (!pp->va_cfg0_base) {
> @@ -377,8 +377,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
>   break;
>   case 0:
>   pp->cfg = win->res;
> - pp->cfg0_size = resource_size(pp->cfg) / 2;
> - pp->cfg1_size = resource_size(pp->cfg) / 2;
> + pp->cfg0_size = resource_size(pp->cfg) >> 1;
> +     pp->cfg1_size = resource_size(pp->cfg) >> 1;
>   pp->cfg0_base = pp->cfg->start;
>   pp->cfg1_base = pp->cfg->start + pp->cfg0_size;
>   break;
> 

Thanks Gustavo!

Acked-by: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH v5 09/10] PCI: dwc: Small computation improvement

[Joao Pinto]

Às 3:34 PM de 4/17/2018, Gustavo Pimentel escreveu:
> Replaces a simple division by 2 to a right shift rotation of 1 bit.
> 
> Probably any recent and decent compiler does this kind of substitution
> in order to improve code performance. Nevertheless it's a coding good
> practice whenever there is a division / multiplication by multiple of 2
> to replace it by the equivalent operation in this case, the shift
> rotation.
> 
> Signed-off-by: Gustavo Pimentel 
> ---
> Change v1->v2:
>  - Nothing changed, just to follow the patch set version.
> Change v2->v3:
>  - Nothing changed, just to follow the patch set version.
> Changes v3->v4:
>  - Added a small explication to the log description.
> Changes v4->v5:
>  - Nothing changed, just to follow the patch set version.
> 
>  drivers/pci/dwc/pcie-designware-host.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-host.c 
> b/drivers/pci/dwc/pcie-designware-host.c
> index 5a23f78..fc55fde 100644
> --- a/drivers/pci/dwc/pcie-designware-host.c
> +++ b/drivers/pci/dwc/pcie-designware-host.c
> @@ -332,8 +332,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
>  
>   cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "config");
>   if (cfg_res) {
> - pp->cfg0_size = resource_size(cfg_res) / 2;
> - pp->cfg1_size = resource_size(cfg_res) / 2;
> + pp->cfg0_size = resource_size(cfg_res) >> 1;
> + pp->cfg1_size = resource_size(cfg_res) >> 1;
>   pp->cfg0_base = cfg_res->start;
>   pp->cfg1_base = cfg_res->start + pp->cfg0_size;
>   } else if (!pp->va_cfg0_base) {
> @@ -377,8 +377,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
>   break;
>   case 0:
>   pp->cfg = win->res;
> - pp->cfg0_size = resource_size(pp->cfg) / 2;
> - pp->cfg1_size = resource_size(pp->cfg) / 2;
> + pp->cfg0_size = resource_size(pp->cfg) >> 1;
> + pp->cfg1_size = resource_size(pp->cfg) >> 1;
>   pp->cfg0_base = pp->cfg->start;
>   pp->cfg1_base = pp->cfg->start + pp->cfg0_size;
>   break;
> 

Thanks Gustavo!

Acked-by: Joao Pinto 

Re: [PATCH v5 08/10] PCI: dwc: Replace lower into upper case characters

[Joao Pinto]

 PCIE_MSI_INTR0_ENABLE + (ctrl * 12), 4,
>   >irq_status[ctrl]);
> - /* setup RC BARs */
> +
> + /* Setup RC BARs */
>   dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, 0x0004);
>   dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_1, 0x);
>  
> - /* setup interrupt pins */
> + /* Setup interrupt pins */
>   dw_pcie_dbi_ro_wr_en(pci);
>   val = dw_pcie_readl_dbi(pci, PCI_INTERRUPT_LINE);
>   val &= 0x00ff;
> @@ -664,13 +667,13 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
>   dw_pcie_writel_dbi(pci, PCI_INTERRUPT_LINE, val);
>   dw_pcie_dbi_ro_wr_dis(pci);
>  
> - /* setup bus numbers */
> + /* Setup bus numbers */
>   val = dw_pcie_readl_dbi(pci, PCI_PRIMARY_BUS);
>   val &= 0xff00;
>   val |= 0x00ff0100;
>   dw_pcie_writel_dbi(pci, PCI_PRIMARY_BUS, val);
>  
> - /* setup command register */
> + /* Setup command register */
>   val = dw_pcie_readl_dbi(pci, PCI_COMMAND);
>   val &= 0x;
>   val |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY |
> @@ -683,7 +686,7 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
>* we should not program the ATU here.
>*/
>   if (!pp->ops->rd_other_conf) {
> - /* get iATU unroll support */
> + /* Get iATU unroll support */
>   pci->iatu_unroll_enabled = dw_pcie_iatu_unroll_enabled(pci);
>   dev_dbg(pci->dev, "iATU unroll: %s\n",
>   pci->iatu_unroll_enabled ? "enabled" : "disabled");
> @@ -701,7 +704,7 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
>  
>   /* Enable write permission for the DBI read-only register */
>   dw_pcie_dbi_ro_wr_en(pci);
> - /* program correct class for RC */
> + /* Program correct class for RC */
>   dw_pcie_wr_own_conf(pp, PCI_CLASS_DEVICE, 2, PCI_CLASS_BRIDGE_PCI);
>   /* Better disable write permission right after the update */
>   dw_pcie_dbi_ro_wr_dis(pci);
> diff --git a/drivers/pci/dwc/pcie-designware.c 
> b/drivers/pci/dwc/pcie-designware.c
> index 1b7282e..778c4f7 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -69,7 +69,7 @@ u32 __dw_pcie_read_dbi(struct dw_pcie *pci, void __iomem 
> *base, u32 reg,
>  
>   ret = dw_pcie_read(base + reg, size, );
>   if (ret)
> - dev_err(pci->dev, "read DBI address failed\n");
> + dev_err(pci->dev, "Read DBI address failed\n");
>  
>   return val;
>  }
> @@ -86,7 +86,7 @@ void __dw_pcie_write_dbi(struct dw_pcie *pci, void __iomem 
> *base, u32 reg,
>  
>   ret = dw_pcie_write(base + reg, size, val);
>   if (ret)
> - dev_err(pci->dev, "write DBI address failed\n");
> + dev_err(pci->dev, "Write DBI address failed\n");
>  }
>  
>  static u32 dw_pcie_readl_ob_unroll(struct dw_pcie *pci, u32 index, u32 reg)
> @@ -137,7 +137,7 @@ static void dw_pcie_prog_outbound_atu_unroll(struct 
> dw_pcie *pci, int index,
>  
>   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
>   }
> - dev_err(pci->dev, "outbound iATU is not being enabled\n");
> + dev_err(pci->dev, "Outbound iATU is not being enabled\n");
>  }
>  
>  void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> @@ -180,7 +180,7 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int 
> index, int type,
>  
>   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
>   }
> - dev_err(pci->dev, "outbound iATU is not being enabled\n");
> + dev_err(pci->dev, "Outbound iATU is not being enabled\n");
>  }
>  
>  static u32 dw_pcie_readl_ib_unroll(struct dw_pcie *pci, u32 index, u32 reg)
> @@ -238,7 +238,7 @@ static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie 
> *pci, int index,
>  
>   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
>   }
> - dev_err(pci->dev, "inbound iATU is not being enabled\n");
> + dev_err(pci->dev, "Inbound iATU is not being enabled\n");
>  
>   return -EBUSY;
>  }
> @@ -284,7 +284,7 @@ int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int 
> index, int bar,
>  
>   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
>   }
> - dev_err(pci->dev, "inbound iATU is not being enabled\n");
> + dev_err(pci->dev, "Inbound iATU is not being enabled\n");
>  
>   return -EBUSY;
>  }
> @@ -313,16 +313,16 @@ int dw_pcie_wait_for_link(struct dw_pcie *pci)
>  {
>   int retries;
>  
> - /* check if the link is up or not */
> + /* Check if the link is up or not */
>   for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
>   if (dw_pcie_link_up(pci)) {
> - dev_info(pci->dev, "link up\n");
> + dev_info(pci->dev, "Link up\n");
>   return 0;
>   }
>   usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
>   }
>  
> - dev_err(pci->dev, "phy link never came up\n");
> + dev_err(pci->dev, "Phy link never came up\n");
>  
>   return -ETIMEDOUT;
>  }
> @@ -351,7 +351,7 @@ void dw_pcie_setup(struct dw_pcie *pci)
>   if (ret)
>   lanes = 0;
>  
> - /* set the number of lanes */
> + /* Set the number of lanes */
>   val = dw_pcie_readl_dbi(pci, PCIE_PORT_LINK_CONTROL);
>   val &= ~PORT_LINK_MODE_MASK;
>   switch (lanes) {
> @@ -373,7 +373,7 @@ void dw_pcie_setup(struct dw_pcie *pci)
>   }
>   dw_pcie_writel_dbi(pci, PCIE_PORT_LINK_CONTROL, val);
>  
> - /* set link width speed control register */
> + /* Set link width speed control register */
>   val = dw_pcie_readl_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL);
>   val &= ~PORT_LOGIC_LINK_WIDTH_MASK;
>   switch (lanes) {
> 

Acked-by: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH v5 08/10] PCI: dwc: Replace lower into upper case characters

[Joao Pinto]

 >irq_status[ctrl]);
> - /* setup RC BARs */
> +
> + /* Setup RC BARs */
>   dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, 0x0004);
>   dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_1, 0x);
>  
> - /* setup interrupt pins */
> + /* Setup interrupt pins */
>   dw_pcie_dbi_ro_wr_en(pci);
>   val = dw_pcie_readl_dbi(pci, PCI_INTERRUPT_LINE);
>   val &= 0x00ff;
> @@ -664,13 +667,13 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
>   dw_pcie_writel_dbi(pci, PCI_INTERRUPT_LINE, val);
>   dw_pcie_dbi_ro_wr_dis(pci);
>  
> - /* setup bus numbers */
> + /* Setup bus numbers */
>   val = dw_pcie_readl_dbi(pci, PCI_PRIMARY_BUS);
>   val &= 0xff00;
>   val |= 0x00ff0100;
>   dw_pcie_writel_dbi(pci, PCI_PRIMARY_BUS, val);
>  
> - /* setup command register */
> + /* Setup command register */
>   val = dw_pcie_readl_dbi(pci, PCI_COMMAND);
>   val &= 0x;
>   val |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY |
> @@ -683,7 +686,7 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
>* we should not program the ATU here.
>*/
>   if (!pp->ops->rd_other_conf) {
> - /* get iATU unroll support */
> + /* Get iATU unroll support */
>   pci->iatu_unroll_enabled = dw_pcie_iatu_unroll_enabled(pci);
>   dev_dbg(pci->dev, "iATU unroll: %s\n",
>   pci->iatu_unroll_enabled ? "enabled" : "disabled");
> @@ -701,7 +704,7 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
>  
>   /* Enable write permission for the DBI read-only register */
>   dw_pcie_dbi_ro_wr_en(pci);
> - /* program correct class for RC */
> + /* Program correct class for RC */
>   dw_pcie_wr_own_conf(pp, PCI_CLASS_DEVICE, 2, PCI_CLASS_BRIDGE_PCI);
>   /* Better disable write permission right after the update */
>   dw_pcie_dbi_ro_wr_dis(pci);
> diff --git a/drivers/pci/dwc/pcie-designware.c 
> b/drivers/pci/dwc/pcie-designware.c
> index 1b7282e..778c4f7 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -69,7 +69,7 @@ u32 __dw_pcie_read_dbi(struct dw_pcie *pci, void __iomem 
> *base, u32 reg,
>  
>   ret = dw_pcie_read(base + reg, size, );
>   if (ret)
> - dev_err(pci->dev, "read DBI address failed\n");
> + dev_err(pci->dev, "Read DBI address failed\n");
>  
>   return val;
>  }
> @@ -86,7 +86,7 @@ void __dw_pcie_write_dbi(struct dw_pcie *pci, void __iomem 
> *base, u32 reg,
>  
>   ret = dw_pcie_write(base + reg, size, val);
>   if (ret)
> - dev_err(pci->dev, "write DBI address failed\n");
> + dev_err(pci->dev, "Write DBI address failed\n");
>  }
>  
>  static u32 dw_pcie_readl_ob_unroll(struct dw_pcie *pci, u32 index, u32 reg)
> @@ -137,7 +137,7 @@ static void dw_pcie_prog_outbound_atu_unroll(struct 
> dw_pcie *pci, int index,
>  
>   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
>   }
> - dev_err(pci->dev, "outbound iATU is not being enabled\n");
> + dev_err(pci->dev, "Outbound iATU is not being enabled\n");
>  }
>  
>  void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> @@ -180,7 +180,7 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int 
> index, int type,
>  
>   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
>   }
> - dev_err(pci->dev, "outbound iATU is not being enabled\n");
> + dev_err(pci->dev, "Outbound iATU is not being enabled\n");
>  }
>  
>  static u32 dw_pcie_readl_ib_unroll(struct dw_pcie *pci, u32 index, u32 reg)
> @@ -238,7 +238,7 @@ static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie 
> *pci, int index,
>  
>   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
>   }
> - dev_err(pci->dev, "inbound iATU is not being enabled\n");
> + dev_err(pci->dev, "Inbound iATU is not being enabled\n");
>  
>   return -EBUSY;
>  }
> @@ -284,7 +284,7 @@ int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int 
> index, int bar,
>  
>   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
>   }
> - dev_err(pci->dev, "inbound iATU is not being enabled\n");
> + dev_err(pci->dev, "Inbound iATU is not being enabled\n");
>  
>   return -EBUSY;
>  }
> @@ -313,16 +313,16 @@ int dw_pcie_wait_for_link(struct dw_pcie *pci)
>  {
>   int retries;
>  
> - /* check if the link is up or not */
> + /* Check if the link is up or not */
>   for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
>   if (dw_pcie_link_up(pci)) {
> - dev_info(pci->dev, "link up\n");
> + dev_info(pci->dev, "Link up\n");
>   return 0;
>   }
>   usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
>   }
>  
> - dev_err(pci->dev, "phy link never came up\n");
> + dev_err(pci->dev, "Phy link never came up\n");
>  
>   return -ETIMEDOUT;
>  }
> @@ -351,7 +351,7 @@ void dw_pcie_setup(struct dw_pcie *pci)
>   if (ret)
>   lanes = 0;
>  
> - /* set the number of lanes */
> + /* Set the number of lanes */
>   val = dw_pcie_readl_dbi(pci, PCIE_PORT_LINK_CONTROL);
>   val &= ~PORT_LINK_MODE_MASK;
>   switch (lanes) {
> @@ -373,7 +373,7 @@ void dw_pcie_setup(struct dw_pcie *pci)
>   }
>   dw_pcie_writel_dbi(pci, PCIE_PORT_LINK_CONTROL, val);
>  
> - /* set link width speed control register */
> + /* Set link width speed control register */
>   val = dw_pcie_readl_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL);
>   val &= ~PORT_LOGIC_LINK_WIDTH_MASK;
>   switch (lanes) {
> 

Acked-by: Joao Pinto 

Re: [PATCH v5 07/10] PCI: dwc: Define maximum number of vectors

[Joao Pinto]

Hi Gustavo,

Às 3:34 PM de 4/17/2018, Gustavo Pimentel escreveu:
> 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.
> 
> Signed-off-by: Gustavo Pimentel <gustavo.pimen...@synopsys.com>
> ---
> Change v1->v2:
>  - Nothing changed, just to follow the patch set version.
> Change v2->v3:
>  - Nothing changed, just to follow the patch set version.
> Changes v3->v4:
>  - Nothing changed, just to follow the patch set version.
> Changes v4->v5:
>  - 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 efc315c..5937fed 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)
> 

Yes, in our reference plat driver we should target all the available IRQs. 
Thanks!

Acked-by: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH v5 07/10] PCI: dwc: Define maximum number of vectors

[Joao Pinto]

Hi Gustavo,

Às 3:34 PM de 4/17/2018, Gustavo Pimentel escreveu:
> 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.
> 
> Signed-off-by: Gustavo Pimentel 
> ---
> Change v1->v2:
>  - Nothing changed, just to follow the patch set version.
> Change v2->v3:
>  - Nothing changed, just to follow the patch set version.
> Changes v3->v4:
>  - Nothing changed, just to follow the patch set version.
> Changes v4->v5:
>  - 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 efc315c..5937fed 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)
> 

Yes, in our reference plat driver we should target all the available IRQs. 
Thanks!

Acked-by: Joao Pinto 

Re: [PATCH v5 02/10] PCI: dwc: Add support for endpoint mode

[Joao Pinto]

Hi Gustavo,

Às 3:34 PM de 4/17/2018, Gustavo Pimentel escreveu:
> The PCIe controller dual mode is capable of operating in host mode as well
> as endpoint mode by configuration, therefore this patch aims to add
> endpoint mode support to the designware driver.
> 
> Signed-off-by: Gustavo Pimentel 
> Acked-by: Kishon Vijay Abraham I 
> ---
> Change v1->v2:
>  - Removed dw_plat_pcie_stop_link empty function.
>  - Implemented Kishon's suggestions about dw-pcie-rc and dw-pcie strings.
> compatibility.
>  - Added second entry on pci_epf_test_ids structure.
> Changes v2->v3:
>  - Reverted additions in dw_pcie_ep_linkup function.
>  - Replaced devm_ioremap by devm_ioremap_resource function.
>  - Moved second entry in pci_epf_test_ids structure into a new patch file.
> Changes v3->v4:
>  - Reverted "snps,dw-pcie-rc" compatible string requested by Rob Herring.
> Changes v4->v5:
>  - Nothing changed, just to follow the patch set version.
> 
>  drivers/pci/dwc/Kconfig|  45 +++---
>  drivers/pci/dwc/pcie-designware-plat.c | 149 
> ++---
>  2 files changed, 174 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig
> index 2f3f5c5..3fd7daf 100644
> --- a/drivers/pci/dwc/Kconfig
> +++ b/drivers/pci/dwc/Kconfig
> @@ -7,8 +7,7 @@ config PCIE_DW
>  
>  config PCIE_DW_HOST
>  bool
> - depends on PCI
> - depends on PCI_MSI_IRQ_DOMAIN
> + depends on PCI && PCI_MSI_IRQ_DOMAIN
>  select PCIE_DW
>  
>  config PCIE_DW_EP
> @@ -52,16 +51,42 @@ config PCI_DRA7XX_EP
>  
>  config PCIE_DW_PLAT
>   bool "Platform bus based DesignWare PCIe Controller"
> - depends on PCI
> - depends on PCI_MSI_IRQ_DOMAIN
> - select PCIE_DW_HOST
> - ---help---
> -  This selects the DesignWare PCIe controller support. Select this if
> -  you have a PCIe controller on Platform bus.
> + help
> +   There are two instances of PCIe controller in Designware IP.
> +   This controller can work either as EP or RC. In order to enable
> +   host-specific features PCIE_DW_PLAT_HOST must be selected and in
> +   order to enable device-specific features PCIE_DW_PLAT_EP must be
> +   selected.

I just have have a suggestion regarding the PCIE-DW_PLAT Kconfig option that in
my opinion should be hidden from the user like the PCIE_DW_HOST option, since it
should be set only by PCIE_DW_PLAT_HOST and PCIE_DW_PLAT_EP.

Thanks,
Joao

>  
> -  If you have a controller with this interface, say Y or M here.
> +config PCIE_DW_PLAT_HOST
> + bool "Platform bus based DesignWare PCIe Controller - Host mode"
> + depends on PCI && PCI_MSI_IRQ_DOMAIN
> + select PCIE_DW_HOST
> + select PCIE_DW_PLAT
> + default y
> + help
> +   Enables support for the PCIe controller in the Designware IP to
> +   work in host mode. There are two instances of PCIe controller in
> +   Designware IP.
> +   This controller can work either as EP or RC. In order to enable
> +   host-specific features PCIE_DW_PLAT_HOST must be selected and in
> +   order to enable device-specific features PCI_DW_PLAT_EP must be
> +   selected.
>  
> -  If unsure, say N.
> +config PCIE_DW_PLAT_EP
> + bool "Platform bus based DesignWare PCIe Controller - Endpoint mode"
> + depends on PCI && PCI_MSI_IRQ_DOMAIN
> + depends on PCI_ENDPOINT
> + select PCIE_DW_EP
> + select PCIE_DW_PLAT
> + help
> +   Enables support for the PCIe controller in the Designware IP to
> +   work in endpoint mode. There are two instances of PCIe controller
> +   in Designware IP.
> +   This controller can work either as EP or RC. In order to enable
> +   host-specific features PCIE_DW_PLAT_HOST must be selected and in
> +   order to enable device-specific features PCI_DW_PLAT_EP must be
> +   selected.
>  
>  config PCI_EXYNOS
>   bool "Samsung Exynos PCIe controller"
> diff --git a/drivers/pci/dwc/pcie-designware-plat.c 
> b/drivers/pci/dwc/pcie-designware-plat.c
> index 5416aa8..efc315c 100644
> --- a/drivers/pci/dwc/pcie-designware-plat.c
> +++ b/drivers/pci/dwc/pcie-designware-plat.c
> @@ -12,19 +12,29 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "pcie-designware.h"
>  
>  struct dw_plat_pcie {
> - struct dw_pcie  *pci;
> + struct dw_pcie  *pci;
> + struct regmap   *regmap;
> + enum dw_pcie_device_modemode;
>  };
>  
> +struct dw_plat_pcie_of_data {
> + enum dw_pcie_device_modemode;
> +};
> +
> +static const struct of_device_id dw_plat_pcie_of_match[];
> +
>  static int dw_plat_pcie_host_init(struct pcie_port *pp)
>  {
>   struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> @@ -42,9 +52,53 @@ static const struct dw_pcie_host_ops 

Re: [PATCH v5 02/10] PCI: dwc: Add support for endpoint mode

[Joao Pinto]

Hi Gustavo,

Às 3:34 PM de 4/17/2018, Gustavo Pimentel escreveu:
> The PCIe controller dual mode is capable of operating in host mode as well
> as endpoint mode by configuration, therefore this patch aims to add
> endpoint mode support to the designware driver.
> 
> Signed-off-by: Gustavo Pimentel 
> Acked-by: Kishon Vijay Abraham I 
> ---
> Change v1->v2:
>  - Removed dw_plat_pcie_stop_link empty function.
>  - Implemented Kishon's suggestions about dw-pcie-rc and dw-pcie strings.
> compatibility.
>  - Added second entry on pci_epf_test_ids structure.
> Changes v2->v3:
>  - Reverted additions in dw_pcie_ep_linkup function.
>  - Replaced devm_ioremap by devm_ioremap_resource function.
>  - Moved second entry in pci_epf_test_ids structure into a new patch file.
> Changes v3->v4:
>  - Reverted "snps,dw-pcie-rc" compatible string requested by Rob Herring.
> Changes v4->v5:
>  - Nothing changed, just to follow the patch set version.
> 
>  drivers/pci/dwc/Kconfig|  45 +++---
>  drivers/pci/dwc/pcie-designware-plat.c | 149 
> ++---
>  2 files changed, 174 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig
> index 2f3f5c5..3fd7daf 100644
> --- a/drivers/pci/dwc/Kconfig
> +++ b/drivers/pci/dwc/Kconfig
> @@ -7,8 +7,7 @@ config PCIE_DW
>  
>  config PCIE_DW_HOST
>  bool
> - depends on PCI
> - depends on PCI_MSI_IRQ_DOMAIN
> + depends on PCI && PCI_MSI_IRQ_DOMAIN
>  select PCIE_DW
>  
>  config PCIE_DW_EP
> @@ -52,16 +51,42 @@ config PCI_DRA7XX_EP
>  
>  config PCIE_DW_PLAT
>   bool "Platform bus based DesignWare PCIe Controller"
> - depends on PCI
> - depends on PCI_MSI_IRQ_DOMAIN
> - select PCIE_DW_HOST
> - ---help---
> -  This selects the DesignWare PCIe controller support. Select this if
> -  you have a PCIe controller on Platform bus.
> + help
> +   There are two instances of PCIe controller in Designware IP.
> +   This controller can work either as EP or RC. In order to enable
> +   host-specific features PCIE_DW_PLAT_HOST must be selected and in
> +   order to enable device-specific features PCIE_DW_PLAT_EP must be
> +   selected.

I just have have a suggestion regarding the PCIE-DW_PLAT Kconfig option that in
my opinion should be hidden from the user like the PCIE_DW_HOST option, since it
should be set only by PCIE_DW_PLAT_HOST and PCIE_DW_PLAT_EP.

Thanks,
Joao

>  
> -  If you have a controller with this interface, say Y or M here.
> +config PCIE_DW_PLAT_HOST
> + bool "Platform bus based DesignWare PCIe Controller - Host mode"
> + depends on PCI && PCI_MSI_IRQ_DOMAIN
> + select PCIE_DW_HOST
> + select PCIE_DW_PLAT
> + default y
> + help
> +   Enables support for the PCIe controller in the Designware IP to
> +   work in host mode. There are two instances of PCIe controller in
> +   Designware IP.
> +   This controller can work either as EP or RC. In order to enable
> +   host-specific features PCIE_DW_PLAT_HOST must be selected and in
> +   order to enable device-specific features PCI_DW_PLAT_EP must be
> +   selected.
>  
> -  If unsure, say N.
> +config PCIE_DW_PLAT_EP
> + bool "Platform bus based DesignWare PCIe Controller - Endpoint mode"
> + depends on PCI && PCI_MSI_IRQ_DOMAIN
> + depends on PCI_ENDPOINT
> + select PCIE_DW_EP
> + select PCIE_DW_PLAT
> + help
> +   Enables support for the PCIe controller in the Designware IP to
> +   work in endpoint mode. There are two instances of PCIe controller
> +   in Designware IP.
> +   This controller can work either as EP or RC. In order to enable
> +   host-specific features PCIE_DW_PLAT_HOST must be selected and in
> +   order to enable device-specific features PCI_DW_PLAT_EP must be
> +   selected.
>  
>  config PCI_EXYNOS
>   bool "Samsung Exynos PCIe controller"
> diff --git a/drivers/pci/dwc/pcie-designware-plat.c 
> b/drivers/pci/dwc/pcie-designware-plat.c
> index 5416aa8..efc315c 100644
> --- a/drivers/pci/dwc/pcie-designware-plat.c
> +++ b/drivers/pci/dwc/pcie-designware-plat.c
> @@ -12,19 +12,29 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "pcie-designware.h"
>  
>  struct dw_plat_pcie {
> - struct dw_pcie  *pci;
> + struct dw_pcie  *pci;
> + struct regmap   *regmap;
> + enum dw_pcie_device_modemode;
>  };
>  
> +struct dw_plat_pcie_of_data {
> + enum dw_pcie_device_modemode;
> +};
> +
> +static const struct of_device_id dw_plat_pcie_of_match[];
> +
>  static int dw_plat_pcie_host_init(struct pcie_port *pp)
>  {
>   struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> @@ -42,9 +52,53 @@ static const struct dw_pcie_host_ops dw_plat_pcie_host_ops 
> = {
>   .host_init = 

Re: [PATCH v2] PCI: dwc: Use {upper,lower}_32_bits() macros for clarity

[Joao Pinto]

Hi Stephen,

Às 11:25 PM de 12/27/2017, Stephen Boyd escreveu:
> We have macros for getting the upper or lower 32 bits of a
> number. Use them here to shave a couple lines off the code
> and provide clarity.
> 
> Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
> ---
> 
> Changes from v1:
>  * Update dw_msi_setup_msg() too
>  * Reword commit text slightly
> 
>  drivers/pci/dwc/pcie-designware-host.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-host.c 
> b/drivers/pci/dwc/pcie-designware-host.c
> index 81e2157a7cfb..454b8d244071 100644
> --- a/drivers/pci/dwc/pcie-designware-host.c
> +++ b/drivers/pci/dwc/pcie-designware-host.c
> @@ -89,10 +89,8 @@ void dw_pcie_msi_init(struct pcie_port *pp)
>   msi_target = virt_to_phys((void *)pp->msi_data);
>  
>   /* program the msi_data */
> - dw_pcie_wr_own_conf(pp, PCIE_MSI_ADDR_LO, 4,
> - (u32)(msi_target & 0x));
> - dw_pcie_wr_own_conf(pp, PCIE_MSI_ADDR_HI, 4,
> - (u32)(msi_target >> 32 & 0x));
> + dw_pcie_wr_own_conf(pp, PCIE_MSI_ADDR_LO, 4, lower_32_bits(msi_target));
> + dw_pcie_wr_own_conf(pp, PCIE_MSI_ADDR_HI, 4, upper_32_bits(msi_target));
>  }
>  
>  static void dw_pcie_msi_clear_irq(struct pcie_port *pp, int irq)
> @@ -189,8 +187,8 @@ static void dw_msi_setup_msg(struct pcie_port *pp, 
> unsigned int irq, u32 pos)
>   else
>   msi_target = virt_to_phys((void *)pp->msi_data);
>  
> - msg.address_lo = (u32)(msi_target & 0x);
> - msg.address_hi = (u32)(msi_target >> 32 & 0x);
> + msg.address_lo = lower_32_bits(msi_target);
> + msg.address_hi = upper_32_bits(msi_target);
>  
>   if (pp->ops->get_msi_data)
>   msg.data = pp->ops->get_msi_data(pp, pos);
> 

Thanks for the patch.
Gustavo' patch-set targeting the update of the Interrupt API for
pcie-designware* already does this modification, so I would suggest that we wait
for Gustavo' patch to be stable and get the same modification.

Best regards,
Joao Pinto

Re: [PATCH v2] PCI: dwc: Use {upper,lower}_32_bits() macros for clarity

[Joao Pinto]

Hi Stephen,

Às 11:25 PM de 12/27/2017, Stephen Boyd escreveu:
> We have macros for getting the upper or lower 32 bits of a
> number. Use them here to shave a couple lines off the code
> and provide clarity.
> 
> Signed-off-by: Stephen Boyd 
> ---
> 
> Changes from v1:
>  * Update dw_msi_setup_msg() too
>  * Reword commit text slightly
> 
>  drivers/pci/dwc/pcie-designware-host.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-host.c 
> b/drivers/pci/dwc/pcie-designware-host.c
> index 81e2157a7cfb..454b8d244071 100644
> --- a/drivers/pci/dwc/pcie-designware-host.c
> +++ b/drivers/pci/dwc/pcie-designware-host.c
> @@ -89,10 +89,8 @@ void dw_pcie_msi_init(struct pcie_port *pp)
>   msi_target = virt_to_phys((void *)pp->msi_data);
>  
>   /* program the msi_data */
> - dw_pcie_wr_own_conf(pp, PCIE_MSI_ADDR_LO, 4,
> - (u32)(msi_target & 0x));
> - dw_pcie_wr_own_conf(pp, PCIE_MSI_ADDR_HI, 4,
> - (u32)(msi_target >> 32 & 0x));
> + dw_pcie_wr_own_conf(pp, PCIE_MSI_ADDR_LO, 4, lower_32_bits(msi_target));
> + dw_pcie_wr_own_conf(pp, PCIE_MSI_ADDR_HI, 4, upper_32_bits(msi_target));
>  }
>  
>  static void dw_pcie_msi_clear_irq(struct pcie_port *pp, int irq)
> @@ -189,8 +187,8 @@ static void dw_msi_setup_msg(struct pcie_port *pp, 
> unsigned int irq, u32 pos)
>   else
>   msi_target = virt_to_phys((void *)pp->msi_data);
>  
> - msg.address_lo = (u32)(msi_target & 0x);
> - msg.address_hi = (u32)(msi_target >> 32 & 0x);
> + msg.address_lo = lower_32_bits(msi_target);
> + msg.address_hi = upper_32_bits(msi_target);
>  
>   if (pp->ops->get_msi_data)
>   msg.data = pp->ops->get_msi_data(pp, pos);
> 

Thanks for the patch.
Gustavo' patch-set targeting the update of the Interrupt API for
pcie-designware* already does this modification, so I would suggest that we wait
for Gustavo' patch to be stable and get the same modification.

Best regards,
Joao Pinto

Re: [PATCH v6 00/18] dwc MSI fixes, ARTPEC-6 EP mode support, ARTPEC-7 SoC support

[Joao Pinto]

Hi Niklas,

Às 11:22 PM de 12/20/2017, Niklas Cassel escreveu:
> On Wed, Dec 20, 2017 at 07:47:41PM +0000, Joao Pinto wrote:
>>
>> Hello to all,
>>
>> Às 5:34 PM de 12/20/2017, Lorenzo Pieralisi escreveu:
>>> On Wed, Dec 20, 2017 at 12:29:21AM +0100, Niklas Cassel wrote:
>>>> This is a series that adds:
>>>> - PCI endpoint mode support in the ARTPEC-6 driver.
>>>> - ARTPEC-7 SoC support in the ARTPEC-6 driver (the SoCs are very similar).
>>>> - Small fixes for MSI in designware-ep and designware-host,
>>>>   needed to get endpoint mode support working for ARTPEC-6.
>>>> - Cleanups in pci-dra7xx to better prepare for endpoint mode in other
>>>>   DWC based PCIe drivers.
>>>
>>> Joao, Jingoo,
>>>
>>> Gustavo tested the series and Kishon ACK'ed the relevant patches,
>>> I need your ACKs on designware patches to queue this series for
>>> v4.16.
>>>
>>> I am away from tomorrow (noon) till beginning of January which means
>>> that either I queue this series tomorrow or at -rc6, please do
>>> chime in if you can.
>>
>> Sorry, I have been a bit tied up! Already checked each patch related to DWC.
>> Could anyone from artpec finish the revision, since there are some patches
>> related to that SoC?
> 
> Thanks for looking at the patches.
> 
> Thanks to everyone that has helped in any way.
> 
> Since I am the maintainer for pcie-artpec6.c
> (at least according to MAINTAINERS ;)),
> I'm supposing that my sign-off will suffice.

You're right :), I didn't remember you were the maintainer.
Have a Merry Christmas.

Thanks,
Joao

> 
> Regards,
> Niklas
> 

Re: [PATCH v6 00/18] dwc MSI fixes, ARTPEC-6 EP mode support, ARTPEC-7 SoC support

[Joao Pinto]

Hi Niklas,

Às 11:22 PM de 12/20/2017, Niklas Cassel escreveu:
> On Wed, Dec 20, 2017 at 07:47:41PM +0000, Joao Pinto wrote:
>>
>> Hello to all,
>>
>> Às 5:34 PM de 12/20/2017, Lorenzo Pieralisi escreveu:
>>> On Wed, Dec 20, 2017 at 12:29:21AM +0100, Niklas Cassel wrote:
>>>> This is a series that adds:
>>>> - PCI endpoint mode support in the ARTPEC-6 driver.
>>>> - ARTPEC-7 SoC support in the ARTPEC-6 driver (the SoCs are very similar).
>>>> - Small fixes for MSI in designware-ep and designware-host,
>>>>   needed to get endpoint mode support working for ARTPEC-6.
>>>> - Cleanups in pci-dra7xx to better prepare for endpoint mode in other
>>>>   DWC based PCIe drivers.
>>>
>>> Joao, Jingoo,
>>>
>>> Gustavo tested the series and Kishon ACK'ed the relevant patches,
>>> I need your ACKs on designware patches to queue this series for
>>> v4.16.
>>>
>>> I am away from tomorrow (noon) till beginning of January which means
>>> that either I queue this series tomorrow or at -rc6, please do
>>> chime in if you can.
>>
>> Sorry, I have been a bit tied up! Already checked each patch related to DWC.
>> Could anyone from artpec finish the revision, since there are some patches
>> related to that SoC?
> 
> Thanks for looking at the patches.
> 
> Thanks to everyone that has helped in any way.
> 
> Since I am the maintainer for pcie-artpec6.c
> (at least according to MAINTAINERS ;)),
> I'm supposing that my sign-off will suffice.

You're right :), I didn't remember you were the maintainer.
Have a Merry Christmas.

Thanks,
Joao

> 
> Regards,
> Niklas
> 

Re: [PATCH v6 00/18] dwc MSI fixes, ARTPEC-6 EP mode support, ARTPEC-7 SoC support

[Joao Pinto]

Hello to all,

Às 5:34 PM de 12/20/2017, Lorenzo Pieralisi escreveu:
> On Wed, Dec 20, 2017 at 12:29:21AM +0100, Niklas Cassel wrote:
>> This is a series that adds:
>> - PCI endpoint mode support in the ARTPEC-6 driver.
>> - ARTPEC-7 SoC support in the ARTPEC-6 driver (the SoCs are very similar).
>> - Small fixes for MSI in designware-ep and designware-host,
>>   needed to get endpoint mode support working for ARTPEC-6.
>> - Cleanups in pci-dra7xx to better prepare for endpoint mode in other
>>   DWC based PCIe drivers.
> 
> Joao, Jingoo,
> 
> Gustavo tested the series and Kishon ACK'ed the relevant patches,
> I need your ACKs on designware patches to queue this series for
> v4.16.
> 
> I am away from tomorrow (noon) till beginning of January which means
> that either I queue this series tomorrow or at -rc6, please do
> chime in if you can.

Sorry, I have been a bit tied up! Already checked each patch related to DWC.
Could anyone from artpec finish the revision, since there are some patches
related to that SoC?

Thanks,
Joao

> 
> Thanks,
> Lorenzo
> 
>> Changes since V5:
>> -Dropped GFP_DMA32 from "PCI: dwc: Use the DMA-API to get the MSI address"
>>  so that we use the exact same GFP flags as before.
>> -Rewrote commit message for "PCI: dwc: Make cpu_addr_fixup take struct
>> dw_pcie as argument" to be more detailed.
>>
>> Niklas Cassel (18):
>>   PCI: dwc: Use the DMA-API to get the MSI address
>>   PCI: designware-ep: dw_pcie_ep_set_msi() should only set MMC bits
>>   PCI: designware-ep: Read-only registers need DBI_RO_WR_EN to be
>> writable
>>   PCI: designware-ep: Pre-allocate memory for MSI in dw_pcie_ep_init
>>   PCI: designware-ep: Remove static keyword from dw_pcie_ep_reset_bar()
>>   PCI: designware-ep: Add generic function for raising MSI irq
>>   PCI: dwc: dra7xx: Refactor Kconfig and Makefile handling for host/ep
>> mode
>>   PCI: dwc: dra7xx: Assign pp->ops in dra7xx_add_pcie_port() rather than
>> in probe
>>   PCI: dwc: dra7xx: Help compiler to remove unused code
>>   PCI: dwc: artpec6: Remove unused defines
>>   PCI: dwc: artpec6: Use BIT and GENMASK macros
>>   PCI: dwc: artpec6: Split artpec6_pcie_establish_link() into smaller
>> functions
>>   bindings: PCI: artpec: Add support for endpoint mode
>>   PCI: dwc: artpec6: Add support for endpoint mode
>>   PCI: dwc: Make cpu_addr_fixup take struct dw_pcie as argument
>>   PCI: dwc: artpec6: Deassert the core before waiting for PHY
>>   bindings: PCI: artpec: Add support for the ARTPEC-7 SoC
>>   PCI: dwc: artpec6: Add support for the ARTPEC-7 SoC
>>
>>  .../devicetree/bindings/pci/axis,artpec6-pcie.txt  |   5 +-
>>  drivers/pci/dwc/Kconfig|  68 +--
>>  drivers/pci/dwc/Makefile   |   4 +-
>>  drivers/pci/dwc/pci-dra7xx.c   |  27 +-
>>  drivers/pci/dwc/pcie-artpec6.c | 470 
>> ++---
>>  drivers/pci/dwc/pcie-designware-ep.c   |  59 ++-
>>  drivers/pci/dwc/pcie-designware-host.c |  15 +-
>>  drivers/pci/dwc/pcie-designware.c  |   2 +-
>>  drivers/pci/dwc/pcie-designware.h  |  22 +-
>>  9 files changed, 554 insertions(+), 118 deletions(-)
>>
>> -- 
>> 2.14.2
>>

Re: [PATCH v6 00/18] dwc MSI fixes, ARTPEC-6 EP mode support, ARTPEC-7 SoC support

[Joao Pinto]

Hello to all,

Às 5:34 PM de 12/20/2017, Lorenzo Pieralisi escreveu:
> On Wed, Dec 20, 2017 at 12:29:21AM +0100, Niklas Cassel wrote:
>> This is a series that adds:
>> - PCI endpoint mode support in the ARTPEC-6 driver.
>> - ARTPEC-7 SoC support in the ARTPEC-6 driver (the SoCs are very similar).
>> - Small fixes for MSI in designware-ep and designware-host,
>>   needed to get endpoint mode support working for ARTPEC-6.
>> - Cleanups in pci-dra7xx to better prepare for endpoint mode in other
>>   DWC based PCIe drivers.
> 
> Joao, Jingoo,
> 
> Gustavo tested the series and Kishon ACK'ed the relevant patches,
> I need your ACKs on designware patches to queue this series for
> v4.16.
> 
> I am away from tomorrow (noon) till beginning of January which means
> that either I queue this series tomorrow or at -rc6, please do
> chime in if you can.

Sorry, I have been a bit tied up! Already checked each patch related to DWC.
Could anyone from artpec finish the revision, since there are some patches
related to that SoC?

Thanks,
Joao

> 
> Thanks,
> Lorenzo
> 
>> Changes since V5:
>> -Dropped GFP_DMA32 from "PCI: dwc: Use the DMA-API to get the MSI address"
>>  so that we use the exact same GFP flags as before.
>> -Rewrote commit message for "PCI: dwc: Make cpu_addr_fixup take struct
>> dw_pcie as argument" to be more detailed.
>>
>> Niklas Cassel (18):
>>   PCI: dwc: Use the DMA-API to get the MSI address
>>   PCI: designware-ep: dw_pcie_ep_set_msi() should only set MMC bits
>>   PCI: designware-ep: Read-only registers need DBI_RO_WR_EN to be
>> writable
>>   PCI: designware-ep: Pre-allocate memory for MSI in dw_pcie_ep_init
>>   PCI: designware-ep: Remove static keyword from dw_pcie_ep_reset_bar()
>>   PCI: designware-ep: Add generic function for raising MSI irq
>>   PCI: dwc: dra7xx: Refactor Kconfig and Makefile handling for host/ep
>> mode
>>   PCI: dwc: dra7xx: Assign pp->ops in dra7xx_add_pcie_port() rather than
>> in probe
>>   PCI: dwc: dra7xx: Help compiler to remove unused code
>>   PCI: dwc: artpec6: Remove unused defines
>>   PCI: dwc: artpec6: Use BIT and GENMASK macros
>>   PCI: dwc: artpec6: Split artpec6_pcie_establish_link() into smaller
>> functions
>>   bindings: PCI: artpec: Add support for endpoint mode
>>   PCI: dwc: artpec6: Add support for endpoint mode
>>   PCI: dwc: Make cpu_addr_fixup take struct dw_pcie as argument
>>   PCI: dwc: artpec6: Deassert the core before waiting for PHY
>>   bindings: PCI: artpec: Add support for the ARTPEC-7 SoC
>>   PCI: dwc: artpec6: Add support for the ARTPEC-7 SoC
>>
>>  .../devicetree/bindings/pci/axis,artpec6-pcie.txt  |   5 +-
>>  drivers/pci/dwc/Kconfig|  68 +--
>>  drivers/pci/dwc/Makefile   |   4 +-
>>  drivers/pci/dwc/pci-dra7xx.c   |  27 +-
>>  drivers/pci/dwc/pcie-artpec6.c | 470 
>> ++---
>>  drivers/pci/dwc/pcie-designware-ep.c   |  59 ++-
>>  drivers/pci/dwc/pcie-designware-host.c |  15 +-
>>  drivers/pci/dwc/pcie-designware.c  |   2 +-
>>  drivers/pci/dwc/pcie-designware.h  |  22 +-
>>  9 files changed, 554 insertions(+), 118 deletions(-)
>>
>> -- 
>> 2.14.2
>>

Re: [PATCH v6 06/18] PCI: designware-ep: Add generic function for raising MSI irq

[Joao Pinto]

Hi,

Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu:
> Add a generic function for raising MSI irqs that can be used by all
> DWC based controllers.
> 
> Note that certain controllers, like DRA7xx, have a special convenience
> register for raising MSI irqs that doesn't require you to explicitly map
> the MSI address. Therefore, it is likely that certain drivers will
> not use this generic function, even if they can.
> 
> Signed-off-by: Niklas Cassel <niklas.cas...@axis.com>
> ---
>  drivers/pci/dwc/pcie-designware-ep.c | 35 +++
>  drivers/pci/dwc/pcie-designware.h|  9 +
>  2 files changed, 44 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
> b/drivers/pci/dwc/pcie-designware-ep.c
> index 700ed2f4becf..c5aa1cac5041 100644
> --- a/drivers/pci/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/dwc/pcie-designware-ep.c
> @@ -282,6 +282,41 @@ static const struct pci_epc_ops epc_ops = {
>   .stop   = dw_pcie_ep_stop,
>  };
>  
> +int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep,
> +  u8 interrupt_num)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + struct pci_epc *epc = ep->epc;
> + u16 msg_ctrl, msg_data;
> + u32 msg_addr_lower, msg_addr_upper;
> + u64 msg_addr;
> + bool has_upper;
> + int ret;
> +
> + /* Raise MSI per the PCI Local Bus Specification Revision 3.0, 6.8.1. */
> + msg_ctrl = dw_pcie_readw_dbi(pci, MSI_MESSAGE_CONTROL);
> + has_upper = !!(msg_ctrl & PCI_MSI_FLAGS_64BIT);
> + msg_addr_lower = dw_pcie_readl_dbi(pci, MSI_MESSAGE_ADDR_L32);
> + if (has_upper) {
> + msg_addr_upper = dw_pcie_readl_dbi(pci, MSI_MESSAGE_ADDR_U32);
> + msg_data = dw_pcie_readw_dbi(pci, MSI_MESSAGE_DATA_64);
> + } else {
> + msg_addr_upper = 0;
> + msg_data = dw_pcie_readw_dbi(pci, MSI_MESSAGE_DATA_32);
> + }
> + msg_addr = ((u64) msg_addr_upper) << 32 | msg_addr_lower;
> + ret = dw_pcie_ep_map_addr(epc, ep->msi_mem_phys, msg_addr,
> +   epc->mem->page_size);
> + if (ret)
> + return ret;
> +
> + writel(msg_data | (interrupt_num - 1), ep->msi_mem);
> +
> + dw_pcie_ep_unmap_addr(epc, ep->msi_mem_phys);
> +
> + return 0;
> +}
> +
>  void dw_pcie_ep_exit(struct dw_pcie_ep *ep)
>  {
>   struct pci_epc *epc = ep->epc;
> diff --git a/drivers/pci/dwc/pcie-designware.h 
> b/drivers/pci/dwc/pcie-designware.h
> index 37dfad8d003f..24edac035160 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -106,6 +106,8 @@
>  #define MSI_CAP_MME_MASK (7 << MSI_CAP_MME_SHIFT)
>  #define MSI_MESSAGE_ADDR_L32 0x54
>  #define MSI_MESSAGE_ADDR_U32 0x58
> +#define MSI_MESSAGE_DATA_32  0x58
> +#define MSI_MESSAGE_DATA_64  0x5C
>  
>  /*
>   * Maximum number of MSI IRQs can be 256 per controller. But keep
> @@ -338,6 +340,7 @@ static inline int dw_pcie_host_init(struct pcie_port *pp)
>  void dw_pcie_ep_linkup(struct dw_pcie_ep *ep);
>  int dw_pcie_ep_init(struct dw_pcie_ep *ep);
>  void dw_pcie_ep_exit(struct dw_pcie_ep *ep);
> +int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8 interrupt_num);
>  void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar);
>  #else
>  static inline void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
> @@ -353,6 +356,12 @@ static inline void dw_pcie_ep_exit(struct dw_pcie_ep *ep)
>  {
>  }
>  
> +static inline int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep,
> +u8 interrupt_num)
> +{
> + return 0;
> +}
> +
>  static inline void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno 
> bar)
>  {
>  }
> 

Acked-by: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH v6 06/18] PCI: designware-ep: Add generic function for raising MSI irq

[Joao Pinto]

Hi,

Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu:
> Add a generic function for raising MSI irqs that can be used by all
> DWC based controllers.
> 
> Note that certain controllers, like DRA7xx, have a special convenience
> register for raising MSI irqs that doesn't require you to explicitly map
> the MSI address. Therefore, it is likely that certain drivers will
> not use this generic function, even if they can.
> 
> Signed-off-by: Niklas Cassel 
> ---
>  drivers/pci/dwc/pcie-designware-ep.c | 35 +++
>  drivers/pci/dwc/pcie-designware.h|  9 +
>  2 files changed, 44 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
> b/drivers/pci/dwc/pcie-designware-ep.c
> index 700ed2f4becf..c5aa1cac5041 100644
> --- a/drivers/pci/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/dwc/pcie-designware-ep.c
> @@ -282,6 +282,41 @@ static const struct pci_epc_ops epc_ops = {
>   .stop   = dw_pcie_ep_stop,
>  };
>  
> +int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep,
> +  u8 interrupt_num)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + struct pci_epc *epc = ep->epc;
> + u16 msg_ctrl, msg_data;
> + u32 msg_addr_lower, msg_addr_upper;
> + u64 msg_addr;
> + bool has_upper;
> + int ret;
> +
> + /* Raise MSI per the PCI Local Bus Specification Revision 3.0, 6.8.1. */
> + msg_ctrl = dw_pcie_readw_dbi(pci, MSI_MESSAGE_CONTROL);
> + has_upper = !!(msg_ctrl & PCI_MSI_FLAGS_64BIT);
> + msg_addr_lower = dw_pcie_readl_dbi(pci, MSI_MESSAGE_ADDR_L32);
> + if (has_upper) {
> + msg_addr_upper = dw_pcie_readl_dbi(pci, MSI_MESSAGE_ADDR_U32);
> + msg_data = dw_pcie_readw_dbi(pci, MSI_MESSAGE_DATA_64);
> + } else {
> + msg_addr_upper = 0;
> + msg_data = dw_pcie_readw_dbi(pci, MSI_MESSAGE_DATA_32);
> + }
> + msg_addr = ((u64) msg_addr_upper) << 32 | msg_addr_lower;
> + ret = dw_pcie_ep_map_addr(epc, ep->msi_mem_phys, msg_addr,
> +   epc->mem->page_size);
> + if (ret)
> + return ret;
> +
> + writel(msg_data | (interrupt_num - 1), ep->msi_mem);
> +
> + dw_pcie_ep_unmap_addr(epc, ep->msi_mem_phys);
> +
> + return 0;
> +}
> +
>  void dw_pcie_ep_exit(struct dw_pcie_ep *ep)
>  {
>   struct pci_epc *epc = ep->epc;
> diff --git a/drivers/pci/dwc/pcie-designware.h 
> b/drivers/pci/dwc/pcie-designware.h
> index 37dfad8d003f..24edac035160 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -106,6 +106,8 @@
>  #define MSI_CAP_MME_MASK (7 << MSI_CAP_MME_SHIFT)
>  #define MSI_MESSAGE_ADDR_L32 0x54
>  #define MSI_MESSAGE_ADDR_U32 0x58
> +#define MSI_MESSAGE_DATA_32  0x58
> +#define MSI_MESSAGE_DATA_64  0x5C
>  
>  /*
>   * Maximum number of MSI IRQs can be 256 per controller. But keep
> @@ -338,6 +340,7 @@ static inline int dw_pcie_host_init(struct pcie_port *pp)
>  void dw_pcie_ep_linkup(struct dw_pcie_ep *ep);
>  int dw_pcie_ep_init(struct dw_pcie_ep *ep);
>  void dw_pcie_ep_exit(struct dw_pcie_ep *ep);
> +int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8 interrupt_num);
>  void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar);
>  #else
>  static inline void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
> @@ -353,6 +356,12 @@ static inline void dw_pcie_ep_exit(struct dw_pcie_ep *ep)
>  {
>  }
>  
> +static inline int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep,
> +u8 interrupt_num)
> +{
> + return 0;
> +}
> +
>  static inline void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno 
> bar)
>  {
>  }
> 

Acked-by: Joao Pinto 

Re: [PATCH v6 04/18] PCI: designware-ep: Pre-allocate memory for MSI in dw_pcie_ep_init

[Joao Pinto]

Hi,

Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu:
> Certain SoCs need to map the MSI address in raise_irq.
> To map an address, you first need to call pci_epc_mem_alloc_addr(),
> however, pci_epc_mem_alloc_addr() calls ioremap() (which can sleep).
> 
> Since raise_irq is only called from atomic context, we can't call
> pci_epc_mem_alloc_addr() from raise_irq.
> 
> Pre-allocate a page in dw_pcie_ep_init(), so that this page can later
> be used to map/unmap the MSI address in raise_irq.
> 
> Signed-off-by: Niklas Cassel <niklas.cas...@axis.com>
> ---
>  drivers/pci/dwc/pcie-designware-ep.c | 10 ++
>  drivers/pci/dwc/pcie-designware.h|  2 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
> b/drivers/pci/dwc/pcie-designware-ep.c
> index 3fb34be99715..8d8019cdff2a 100644
> --- a/drivers/pci/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/dwc/pcie-designware-ep.c
> @@ -286,6 +286,9 @@ void dw_pcie_ep_exit(struct dw_pcie_ep *ep)
>  {
>   struct pci_epc *epc = ep->epc;
>  
> + pci_epc_mem_free_addr(epc, ep->msi_mem_phys, ep->msi_mem,
> +   epc->mem->page_size);
> +
>   pci_epc_mem_exit(epc);
>  }
>  
> @@ -341,6 +344,13 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
>   return ret;
>   }
>  
> + ep->msi_mem = pci_epc_mem_alloc_addr(epc, >msi_mem_phys,
> +  epc->mem->page_size);
> + if (!ep->msi_mem) {
> + dev_err(dev, "Failed to reserve memory for MSI\n");
> + return -ENOMEM;
> + }
> +
>   ep->epc = epc;
>   epc_set_drvdata(epc, ep);
>   dw_pcie_setup(pci);
> diff --git a/drivers/pci/dwc/pcie-designware.h 
> b/drivers/pci/dwc/pcie-designware.h
> index 9aaf0cd04dd6..5a1da459eda5 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -198,6 +198,8 @@ struct dw_pcie_ep {
>   unsigned long   ob_window_map;
>   u32     num_ib_windows;
>   u32 num_ob_windows;
> + void __iomem*msi_mem;
> + phys_addr_t msi_mem_phys;
>  };
>  
>  struct dw_pcie_ops {
> 

Acked-by: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH v6 04/18] PCI: designware-ep: Pre-allocate memory for MSI in dw_pcie_ep_init

[Joao Pinto]

Hi,

Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu:
> Certain SoCs need to map the MSI address in raise_irq.
> To map an address, you first need to call pci_epc_mem_alloc_addr(),
> however, pci_epc_mem_alloc_addr() calls ioremap() (which can sleep).
> 
> Since raise_irq is only called from atomic context, we can't call
> pci_epc_mem_alloc_addr() from raise_irq.
> 
> Pre-allocate a page in dw_pcie_ep_init(), so that this page can later
> be used to map/unmap the MSI address in raise_irq.
> 
> Signed-off-by: Niklas Cassel 
> ---
>  drivers/pci/dwc/pcie-designware-ep.c | 10 ++
>  drivers/pci/dwc/pcie-designware.h|  2 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
> b/drivers/pci/dwc/pcie-designware-ep.c
> index 3fb34be99715..8d8019cdff2a 100644
> --- a/drivers/pci/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/dwc/pcie-designware-ep.c
> @@ -286,6 +286,9 @@ void dw_pcie_ep_exit(struct dw_pcie_ep *ep)
>  {
>   struct pci_epc *epc = ep->epc;
>  
> + pci_epc_mem_free_addr(epc, ep->msi_mem_phys, ep->msi_mem,
> +   epc->mem->page_size);
> +
>   pci_epc_mem_exit(epc);
>  }
>  
> @@ -341,6 +344,13 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
>   return ret;
>   }
>  
> + ep->msi_mem = pci_epc_mem_alloc_addr(epc, >msi_mem_phys,
> +  epc->mem->page_size);
> + if (!ep->msi_mem) {
> + dev_err(dev, "Failed to reserve memory for MSI\n");
> + return -ENOMEM;
> + }
> +
>   ep->epc = epc;
>   epc_set_drvdata(epc, ep);
>   dw_pcie_setup(pci);
> diff --git a/drivers/pci/dwc/pcie-designware.h 
> b/drivers/pci/dwc/pcie-designware.h
> index 9aaf0cd04dd6..5a1da459eda5 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -198,6 +198,8 @@ struct dw_pcie_ep {
>   unsigned long   ob_window_map;
>   u32     num_ib_windows;
>   u32 num_ob_windows;
> + void __iomem*msi_mem;
> + phys_addr_t msi_mem_phys;
>  };
>  
>  struct dw_pcie_ops {
> 

Acked-by: Joao Pinto 

Re: [PATCH v6 03/18] PCI: designware-ep: Read-only registers need DBI_RO_WR_EN to be writable

[Joao Pinto]

Hi,

Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu:
> Certain registers that pcie-designware-ep tries to write to are read-only
> registers. However, these registers can become read/write if we first
> enable the DBI_RO_WR_EN bit. Set/unset the DBI_RO_WR_EN bit before/after
> writing these registers.
> 
> Signed-off-by: Niklas Cassel <niklas.cas...@axis.com>
> ---
>  drivers/pci/dwc/pcie-designware-ep.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
> b/drivers/pci/dwc/pcie-designware-ep.c
> index c92ab87fd660..3fb34be99715 100644
> --- a/drivers/pci/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/dwc/pcie-designware-ep.c
> @@ -35,8 +35,10 @@ static void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum 
> pci_barno bar)
>   u32 reg;
>  
>   reg = PCI_BASE_ADDRESS_0 + (4 * bar);
> + dw_pcie_dbi_ro_wr_en(pci);
>   dw_pcie_writel_dbi2(pci, reg, 0x0);
>   dw_pcie_writel_dbi(pci, reg, 0x0);
> + dw_pcie_dbi_ro_wr_dis(pci);
>  }
>  
>  static int dw_pcie_ep_write_header(struct pci_epc *epc,
> @@ -45,6 +47,7 @@ static int dw_pcie_ep_write_header(struct pci_epc *epc,
>   struct dw_pcie_ep *ep = epc_get_drvdata(epc);
>   struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
>  
> + dw_pcie_dbi_ro_wr_en(pci);
>   dw_pcie_writew_dbi(pci, PCI_VENDOR_ID, hdr->vendorid);
>   dw_pcie_writew_dbi(pci, PCI_DEVICE_ID, hdr->deviceid);
>   dw_pcie_writeb_dbi(pci, PCI_REVISION_ID, hdr->revid);
> @@ -58,6 +61,7 @@ static int dw_pcie_ep_write_header(struct pci_epc *epc,
>   dw_pcie_writew_dbi(pci, PCI_SUBSYSTEM_ID, hdr->subsys_id);
>   dw_pcie_writeb_dbi(pci, PCI_INTERRUPT_PIN,
>  hdr->interrupt_pin);
> + dw_pcie_dbi_ro_wr_dis(pci);
>  
>   return 0;
>  }
> @@ -142,8 +146,10 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, enum 
> pci_barno bar,
>   if (ret)
>   return ret;
>  
> + dw_pcie_dbi_ro_wr_en(pci);
>   dw_pcie_writel_dbi2(pci, reg, size - 1);
>   dw_pcie_writel_dbi(pci, reg, flags);
> + dw_pcie_dbi_ro_wr_dis(pci);
>  
>   return 0;
>  }
> @@ -223,7 +229,9 @@ static int dw_pcie_ep_set_msi(struct pci_epc *epc, u8 
> encode_int)
>   val = dw_pcie_readw_dbi(pci, MSI_MESSAGE_CONTROL);
>   val &= ~MSI_CAP_MMC_MASK;
>   val |= (encode_int << MSI_CAP_MMC_SHIFT) & MSI_CAP_MMC_MASK;
> + dw_pcie_dbi_ro_wr_en(pci);
>   dw_pcie_writew_dbi(pci, MSI_MESSAGE_CONTROL, val);
> + dw_pcie_dbi_ro_wr_dis(pci);
>  
>   return 0;
>  }
> 

Acked-by: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH v6 03/18] PCI: designware-ep: Read-only registers need DBI_RO_WR_EN to be writable

[Joao Pinto]

Hi,

Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu:
> Certain registers that pcie-designware-ep tries to write to are read-only
> registers. However, these registers can become read/write if we first
> enable the DBI_RO_WR_EN bit. Set/unset the DBI_RO_WR_EN bit before/after
> writing these registers.
> 
> Signed-off-by: Niklas Cassel 
> ---
>  drivers/pci/dwc/pcie-designware-ep.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
> b/drivers/pci/dwc/pcie-designware-ep.c
> index c92ab87fd660..3fb34be99715 100644
> --- a/drivers/pci/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/dwc/pcie-designware-ep.c
> @@ -35,8 +35,10 @@ static void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum 
> pci_barno bar)
>   u32 reg;
>  
>   reg = PCI_BASE_ADDRESS_0 + (4 * bar);
> + dw_pcie_dbi_ro_wr_en(pci);
>   dw_pcie_writel_dbi2(pci, reg, 0x0);
>   dw_pcie_writel_dbi(pci, reg, 0x0);
> + dw_pcie_dbi_ro_wr_dis(pci);
>  }
>  
>  static int dw_pcie_ep_write_header(struct pci_epc *epc,
> @@ -45,6 +47,7 @@ static int dw_pcie_ep_write_header(struct pci_epc *epc,
>   struct dw_pcie_ep *ep = epc_get_drvdata(epc);
>   struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
>  
> + dw_pcie_dbi_ro_wr_en(pci);
>   dw_pcie_writew_dbi(pci, PCI_VENDOR_ID, hdr->vendorid);
>   dw_pcie_writew_dbi(pci, PCI_DEVICE_ID, hdr->deviceid);
>   dw_pcie_writeb_dbi(pci, PCI_REVISION_ID, hdr->revid);
> @@ -58,6 +61,7 @@ static int dw_pcie_ep_write_header(struct pci_epc *epc,
>   dw_pcie_writew_dbi(pci, PCI_SUBSYSTEM_ID, hdr->subsys_id);
>   dw_pcie_writeb_dbi(pci, PCI_INTERRUPT_PIN,
>  hdr->interrupt_pin);
> + dw_pcie_dbi_ro_wr_dis(pci);
>  
>   return 0;
>  }
> @@ -142,8 +146,10 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, enum 
> pci_barno bar,
>   if (ret)
>   return ret;
>  
> + dw_pcie_dbi_ro_wr_en(pci);
>   dw_pcie_writel_dbi2(pci, reg, size - 1);
>   dw_pcie_writel_dbi(pci, reg, flags);
> + dw_pcie_dbi_ro_wr_dis(pci);
>  
>   return 0;
>  }
> @@ -223,7 +229,9 @@ static int dw_pcie_ep_set_msi(struct pci_epc *epc, u8 
> encode_int)
>   val = dw_pcie_readw_dbi(pci, MSI_MESSAGE_CONTROL);
>   val &= ~MSI_CAP_MMC_MASK;
>   val |= (encode_int << MSI_CAP_MMC_SHIFT) & MSI_CAP_MMC_MASK;
> + dw_pcie_dbi_ro_wr_en(pci);
>   dw_pcie_writew_dbi(pci, MSI_MESSAGE_CONTROL, val);
> + dw_pcie_dbi_ro_wr_dis(pci);
>  
>   return 0;
>  }
> 

Acked-by: Joao Pinto 

Re: [PATCH v6 02/18] PCI: designware-ep: dw_pcie_ep_set_msi() should only set MMC bits

[Joao Pinto]

Hi,

Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu:
> Previously, dw_pcie_ep_set_msi() wrote all bits in the Message Control
> register, thus overwriting the PCI_MSI_FLAGS_64BIT bit.
> By clearing the PCI_MSI_FLAGS_64BIT bit, we break MSI
> on systems where the RC has set a 64 bit MSI address.
> Fix dw_pcie_ep_set_msi() so that it only sets MMC bits.
> 
> Signed-off-by: Niklas Cassel <niklas.cas...@axis.com>
> ---
>  drivers/pci/dwc/pcie-designware-ep.c | 4 +++-
>  drivers/pci/dwc/pcie-designware.h| 1 +
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
> b/drivers/pci/dwc/pcie-designware-ep.c
> index d53d5f168363..c92ab87fd660 100644
> --- a/drivers/pci/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/dwc/pcie-designware-ep.c
> @@ -220,7 +220,9 @@ static int dw_pcie_ep_set_msi(struct pci_epc *epc, u8 
> encode_int)
>   struct dw_pcie_ep *ep = epc_get_drvdata(epc);
>   struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
>  
> - val = (encode_int << MSI_CAP_MMC_SHIFT);
> + val = dw_pcie_readw_dbi(pci, MSI_MESSAGE_CONTROL);
> + val &= ~MSI_CAP_MMC_MASK;
> + val |= (encode_int << MSI_CAP_MMC_SHIFT) & MSI_CAP_MMC_MASK;
>   dw_pcie_writew_dbi(pci, MSI_MESSAGE_CONTROL, val);
>  
>   return 0;
> diff --git a/drivers/pci/dwc/pcie-designware.h 
> b/drivers/pci/dwc/pcie-designware.h
> index ecdede68522a..9aaf0cd04dd6 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -101,6 +101,7 @@
>  
>  #define MSI_MESSAGE_CONTROL  0x52
>  #define MSI_CAP_MMC_SHIFT1
> +#define MSI_CAP_MMC_MASK (7 << MSI_CAP_MMC_SHIFT)
>  #define MSI_CAP_MME_SHIFT4
>  #define MSI_CAP_MME_MASK (7 << MSI_CAP_MME_SHIFT)
>  #define MSI_MESSAGE_ADDR_L32 0x54
> 

Acked-by: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH v6 02/18] PCI: designware-ep: dw_pcie_ep_set_msi() should only set MMC bits

[Joao Pinto]

Hi,

Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu:
> Previously, dw_pcie_ep_set_msi() wrote all bits in the Message Control
> register, thus overwriting the PCI_MSI_FLAGS_64BIT bit.
> By clearing the PCI_MSI_FLAGS_64BIT bit, we break MSI
> on systems where the RC has set a 64 bit MSI address.
> Fix dw_pcie_ep_set_msi() so that it only sets MMC bits.
> 
> Signed-off-by: Niklas Cassel 
> ---
>  drivers/pci/dwc/pcie-designware-ep.c | 4 +++-
>  drivers/pci/dwc/pcie-designware.h| 1 +
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
> b/drivers/pci/dwc/pcie-designware-ep.c
> index d53d5f168363..c92ab87fd660 100644
> --- a/drivers/pci/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/dwc/pcie-designware-ep.c
> @@ -220,7 +220,9 @@ static int dw_pcie_ep_set_msi(struct pci_epc *epc, u8 
> encode_int)
>   struct dw_pcie_ep *ep = epc_get_drvdata(epc);
>   struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
>  
> - val = (encode_int << MSI_CAP_MMC_SHIFT);
> + val = dw_pcie_readw_dbi(pci, MSI_MESSAGE_CONTROL);
> + val &= ~MSI_CAP_MMC_MASK;
> + val |= (encode_int << MSI_CAP_MMC_SHIFT) & MSI_CAP_MMC_MASK;
>   dw_pcie_writew_dbi(pci, MSI_MESSAGE_CONTROL, val);
>  
>   return 0;
> diff --git a/drivers/pci/dwc/pcie-designware.h 
> b/drivers/pci/dwc/pcie-designware.h
> index ecdede68522a..9aaf0cd04dd6 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -101,6 +101,7 @@
>  
>  #define MSI_MESSAGE_CONTROL  0x52
>  #define MSI_CAP_MMC_SHIFT1
> +#define MSI_CAP_MMC_MASK (7 << MSI_CAP_MMC_SHIFT)
>  #define MSI_CAP_MME_SHIFT    4
>  #define MSI_CAP_MME_MASK (7 << MSI_CAP_MME_SHIFT)
>  #define MSI_MESSAGE_ADDR_L32 0x54
> 

Acked-by: Joao Pinto 

Re: [PATCH v6 01/18] PCI: dwc: Use the DMA-API to get the MSI address

[Joao Pinto]

Hi Niklas,

Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu:
> Use the DMA-API to get the MSI address. This address will be written to
> our PCI config space and to the register which determines which AXI
> address the DWC IP will spoof for incoming MSI irqs.
> 
> Since it is a PCIe endpoint device, rather than the CPU, that is supposed
> to write to the MSI address, the proper way to get the MSI address is by
> using the DMA API, not by using virt_to_phys().
> 
> Using virt_to_phys() might work on some systems, but using the DMA API
> should work on all systems.
> 
> This is essentially the same thing as allocating a buffer in a driver
> to which the endpoint will write to. To do this, we use the DMA API.
> 
> Signed-off-by: Niklas Cassel <niklas.cas...@axis.com>
> ---
>  drivers/pci/dwc/pcie-designware-host.c | 15 ---
>  drivers/pci/dwc/pcie-designware.h  |  3 ++-
>  2 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-host.c 
> b/drivers/pci/dwc/pcie-designware-host.c
> index 81e2157a7cfb..bf558df5b7b3 100644
> --- a/drivers/pci/dwc/pcie-designware-host.c
> +++ b/drivers/pci/dwc/pcie-designware-host.c
> @@ -83,10 +83,19 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
>  
>  void dw_pcie_msi_init(struct pcie_port *pp)
>  {
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct device *dev = pci->dev;
> + struct page *page;
>   u64 msi_target;
>  
> - pp->msi_data = __get_free_pages(GFP_KERNEL, 0);
> - msi_target = virt_to_phys((void *)pp->msi_data);
> + page = alloc_page(GFP_KERNEL);
> + pp->msi_data = dma_map_page(dev, page, 0, PAGE_SIZE, DMA_FROM_DEVICE);
> + if (dma_mapping_error(dev, pp->msi_data)) {
> + dev_err(dev, "failed to map MSI data\n");
> + __free_page(page);
> + return;
> + }
> + msi_target = (u64)pp->msi_data;
>  
>   /* program the msi_data */
>   dw_pcie_wr_own_conf(pp, PCIE_MSI_ADDR_LO, 4,
> @@ -187,7 +196,7 @@ static void dw_msi_setup_msg(struct pcie_port *pp, 
> unsigned int irq, u32 pos)
>   if (pp->ops->get_msi_addr)
>   msi_target = pp->ops->get_msi_addr(pp);
>   else
> - msi_target = virt_to_phys((void *)pp->msi_data);
> + msi_target = (u64)pp->msi_data;
>  
>   msg.address_lo = (u32)(msi_target & 0x);
>   msg.address_hi = (u32)(msi_target >> 32 & 0x);
> diff --git a/drivers/pci/dwc/pcie-designware.h 
> b/drivers/pci/dwc/pcie-designware.h
> index e5d9d77b778e..ecdede68522a 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -14,6 +14,7 @@
>  #ifndef _PCIE_DESIGNWARE_H
>  #define _PCIE_DESIGNWARE_H
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -168,7 +169,7 @@ struct pcie_port {
>   const struct dw_pcie_host_ops *ops;
>   int msi_irq;
>   struct irq_domain   *irq_domain;
> - unsigned long   msi_data;
> + dma_addr_t  msi_data;
>   DECLARE_BITMAP(msi_irq_in_use, MAX_MSI_IRQS);
>  };
>  
> 

Makes total sense! Thanks.

Acked-by: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH v6 01/18] PCI: dwc: Use the DMA-API to get the MSI address

[Joao Pinto]

Hi Niklas,

Às 11:29 PM de 12/19/2017, Niklas Cassel escreveu:
> Use the DMA-API to get the MSI address. This address will be written to
> our PCI config space and to the register which determines which AXI
> address the DWC IP will spoof for incoming MSI irqs.
> 
> Since it is a PCIe endpoint device, rather than the CPU, that is supposed
> to write to the MSI address, the proper way to get the MSI address is by
> using the DMA API, not by using virt_to_phys().
> 
> Using virt_to_phys() might work on some systems, but using the DMA API
> should work on all systems.
> 
> This is essentially the same thing as allocating a buffer in a driver
> to which the endpoint will write to. To do this, we use the DMA API.
> 
> Signed-off-by: Niklas Cassel 
> ---
>  drivers/pci/dwc/pcie-designware-host.c | 15 ---
>  drivers/pci/dwc/pcie-designware.h  |  3 ++-
>  2 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-host.c 
> b/drivers/pci/dwc/pcie-designware-host.c
> index 81e2157a7cfb..bf558df5b7b3 100644
> --- a/drivers/pci/dwc/pcie-designware-host.c
> +++ b/drivers/pci/dwc/pcie-designware-host.c
> @@ -83,10 +83,19 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
>  
>  void dw_pcie_msi_init(struct pcie_port *pp)
>  {
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct device *dev = pci->dev;
> + struct page *page;
>   u64 msi_target;
>  
> - pp->msi_data = __get_free_pages(GFP_KERNEL, 0);
> - msi_target = virt_to_phys((void *)pp->msi_data);
> + page = alloc_page(GFP_KERNEL);
> + pp->msi_data = dma_map_page(dev, page, 0, PAGE_SIZE, DMA_FROM_DEVICE);
> + if (dma_mapping_error(dev, pp->msi_data)) {
> + dev_err(dev, "failed to map MSI data\n");
> + __free_page(page);
> + return;
> + }
> + msi_target = (u64)pp->msi_data;
>  
>   /* program the msi_data */
>   dw_pcie_wr_own_conf(pp, PCIE_MSI_ADDR_LO, 4,
> @@ -187,7 +196,7 @@ static void dw_msi_setup_msg(struct pcie_port *pp, 
> unsigned int irq, u32 pos)
>   if (pp->ops->get_msi_addr)
>   msi_target = pp->ops->get_msi_addr(pp);
>   else
> - msi_target = virt_to_phys((void *)pp->msi_data);
> + msi_target = (u64)pp->msi_data;
>  
>   msg.address_lo = (u32)(msi_target & 0x);
>   msg.address_hi = (u32)(msi_target >> 32 & 0x);
> diff --git a/drivers/pci/dwc/pcie-designware.h 
> b/drivers/pci/dwc/pcie-designware.h
> index e5d9d77b778e..ecdede68522a 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -14,6 +14,7 @@
>  #ifndef _PCIE_DESIGNWARE_H
>  #define _PCIE_DESIGNWARE_H
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -168,7 +169,7 @@ struct pcie_port {
>   const struct dw_pcie_host_ops *ops;
>   int msi_irq;
>   struct irq_domain   *irq_domain;
> - unsigned long   msi_data;
> + dma_addr_t  msi_data;
>   DECLARE_BITMAP(msi_irq_in_use, MAX_MSI_IRQS);
>  };
>  
> 

Makes total sense! Thanks.

Acked-by: Joao Pinto 

Re: [PATCH v5 01/18] PCI: dwc: Use the DMA-API to get the MSI address

[Joao Pinto]

Hi Niklas,

Às 1:59 PM de 12/13/2017, Niklas Cassel escreveu:
> On Thu, Nov 30, 2017 at 03:28:43PM +, Lorenzo Pieralisi wrote:
>> Jingoo, Joao,
>>
>> I am expecting your testing on the series and ACKs on the dwc related
>> patches please, according to v4 review - I will mark them as needs
>> review/ACK waiting for you to chime in.
>>
>> v4 thread:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_833882_=DwIBAg=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=CQAV8rCgm2jd7m3iSWL5vBbGTqSc7yN3N7zeQDz-ZUY=mqyDi45qm4qE0jcm0KviYAoLHmMXMMIWEW-gAR0RKOw=
>>
> 
> Hello Lorenzo, Jingoo, Joao,
> 
> Tomorrow another 2 weeks has passed.
> V1 of this patch series was posted on 2017-10-13.

Sorry, I have been tight up with a debug session and not able to check this out.
Adding Gustavo in CC that is now also working in PCI software development.
I am going to check the code ASAP and we will test it as soon as the debug is
finished.

Thanks.

> 
> I'm a bit worried that this patch series will not make it to linux-next
> in time for this patch series to be included in the 4.16 pull request.
> 
> Here is the V5 patch series:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_project_linux-2Dpci_list_-3Fseries-3D14364=DwIBAg=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=CQAV8rCgm2jd7m3iSWL5vBbGTqSc7yN3N7zeQDz-ZUY=qXtUHFXK7_nCndQob0I0qDByBdJsL7rRjZ9cx7c847U=
> 
> Perhaps any maintainer of a designware based PCIe driver could
> help out and test this patch series?
> 
> Regards,
> Niklas
> 

Re: [PATCH v5 01/18] PCI: dwc: Use the DMA-API to get the MSI address

[Joao Pinto]

Hi Niklas,

Às 1:59 PM de 12/13/2017, Niklas Cassel escreveu:
> On Thu, Nov 30, 2017 at 03:28:43PM +, Lorenzo Pieralisi wrote:
>> Jingoo, Joao,
>>
>> I am expecting your testing on the series and ACKs on the dwc related
>> patches please, according to v4 review - I will mark them as needs
>> review/ACK waiting for you to chime in.
>>
>> v4 thread:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_833882_=DwIBAg=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=CQAV8rCgm2jd7m3iSWL5vBbGTqSc7yN3N7zeQDz-ZUY=mqyDi45qm4qE0jcm0KviYAoLHmMXMMIWEW-gAR0RKOw=
>>
> 
> Hello Lorenzo, Jingoo, Joao,
> 
> Tomorrow another 2 weeks has passed.
> V1 of this patch series was posted on 2017-10-13.

Sorry, I have been tight up with a debug session and not able to check this out.
Adding Gustavo in CC that is now also working in PCI software development.
I am going to check the code ASAP and we will test it as soon as the debug is
finished.

Thanks.

> 
> I'm a bit worried that this patch series will not make it to linux-next
> in time for this patch series to be included in the 4.16 pull request.
> 
> Here is the V5 patch series:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_project_linux-2Dpci_list_-3Fseries-3D14364=DwIBAg=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=CQAV8rCgm2jd7m3iSWL5vBbGTqSc7yN3N7zeQDz-ZUY=qXtUHFXK7_nCndQob0I0qDByBdJsL7rRjZ9cx7c847U=
> 
> Perhaps any maintainer of a designware based PCIe driver could
> help out and test this patch series?
> 
> Regards,
> Niklas
> 

Re: [PATCH net-next] net: stmmac: fix broken dma_interrupt handling for multi-queues

[Joao Pinto]

Hi Niklas,

Às 10:56 PM de 12/7/2017, Niklas Cassel escreveu:
> There is nothing that says that number of TX queues == number of RX
> queues. E.g. the ARTPEC-6 SoC has 2 TX queues and 1 RX queue.
> 

Yes you are totally right. Our Hardware was configured with 4RX queues and 4TX
queues and that lead us not to detect some of the issues that you are reporting.
We are already developing a prototype with a number of RX Queue different from
TX Queues.

We would like to resume a discussion that we had a couple of months ago, about
Synopsys testing stmmac in market boards. Currently I am the new Software Team
Manager and so I would like to say to you that we are interested in testing the
driver in several boards to assure quality in the stmmac driver, since we will
be constantly developing the new features for future HW releases.

If some vendors can send us sample boards it would be great, if we have to buy
some, it would be very useful to have reference suggestions.

Thanks and best regards,
Joao

> This code is obviously wrong:
> for (chan = 0; chan < tx_channel_count; chan++) {
> struct stmmac_rx_queue *rx_q = >rx_queue[chan];
> 
> priv->rx_queue has size MTL_MAX_RX_QUEUES, so this will send an
> uninitialized napi_struct to __napi_schedule(), causing us to
> crash in net_rx_action(), because napi_struct->poll is zero.
> 
> [12846.759880] Unable to handle kernel NULL pointer dereference at virtual 
> address 
> [12846.768014] pgd = (ptrval)
> [12846.770742] [] *pgd=39ec7831, *pte=, *ppte=
> [12846.777023] Internal error: Oops: 8007 [#1] PREEMPT SMP ARM
> [12846.782942] Modules linked in:
> [12846.785998] CPU: 0 PID: 161 Comm: dropbear Not tainted 
> 4.15.0-rc2-00285-gf5fb5f2f39a7 #36
> [12846.794177] Hardware name: Axis ARTPEC-6 Platform
> [12846.798879] task: (ptrval) task.stack: (ptrval)
> [12846.803407] PC is at 0x0
> [12846.805942] LR is at net_rx_action+0x274/0x43c
> [12846.810383] pc : [<>]lr : [<80bff064>]psr: 200e0113
> [12846.816648] sp : b90d9ae8  ip : b90d9ae8  fp : b90d9b44
> [12846.821871] r10: 0008  r9 : 0013250e  r8 : 0100
> [12846.827094] r7 : 012c  r6 :   r5 : 0001  r4 : bac84900
> [12846.833619] r3 :   r2 : b90d9b08  r1 :   r0 : bac84900
> 
> Since each DMA channel can be used for rx and tx simultaneously,
> the current code should probably be rewritten so that napi_struct is
> embedded in a new struct stmmac_channel.
> That way, stmmac_poll() can call stmmac_tx_clean() on just the tx queue
> where we got the IRQ, instead of looping through all tx queues.
> This is also how the xgbe driver does it (another driver for this IP).
> 
> Fixes: c22a3f48ef99 ("net: stmmac: adding multiple napi mechanism")
> Signed-off-by: Niklas Cassel 
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 54 
> +++
>  1 file changed, 46 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index d7250539d0bd..c52a9963c19d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1997,22 +1997,60 @@ static void stmmac_set_dma_operation_mode(struct 
> stmmac_priv *priv, u32 txmode,
>  static void stmmac_dma_interrupt(struct stmmac_priv *priv)
>  {
>   u32 tx_channel_count = priv->plat->tx_queues_to_use;
> - int status;
> + u32 rx_channel_count = priv->plat->rx_queues_to_use;
> + u32 channels_to_check = tx_channel_count > rx_channel_count ?
> + tx_channel_count : rx_channel_count;
>   u32 chan;
> + bool poll_scheduled = false;
> + int status[channels_to_check];
> +
> + /* Each DMA channel can be used for rx and tx simultaneously, yet
> +  * napi_struct is embedded in struct stmmac_rx_queue rather than in a
> +  * stmmac_channel struct.
> +  * Because of this, stmmac_poll currently checks (and possibly wakes)
> +  * all tx queues rather than just a single tx queue.
> +  */
> + for (chan = 0; chan < channels_to_check; chan++)
> + status[chan] = priv->hw->dma->dma_interrupt(priv->ioaddr,
> + >xstats,
> + chan);
>  
> - for (chan = 0; chan < tx_channel_count; chan++) {
> - struct stmmac_rx_queue *rx_q = >rx_queue[chan];
> + for (chan = 0; chan < rx_channel_count; chan++) {
> + if (likely(status[chan] & handle_rx)) {
> + struct stmmac_rx_queue *rx_q = >rx_queue[chan];
>  
> - status = priv->hw->dma->dma_interrupt(priv->ioaddr,
> -   >xstats, chan);
> - if (likely((status & handle_rx)) || (status & handle_tx)) {
>   if (likely(napi_schedule_prep(_q->napi))) {
>

Re: [PATCH net-next] net: stmmac: fix broken dma_interrupt handling for multi-queues

[Joao Pinto]

Hi Niklas,

Às 10:56 PM de 12/7/2017, Niklas Cassel escreveu:
> There is nothing that says that number of TX queues == number of RX
> queues. E.g. the ARTPEC-6 SoC has 2 TX queues and 1 RX queue.
> 

Yes you are totally right. Our Hardware was configured with 4RX queues and 4TX
queues and that lead us not to detect some of the issues that you are reporting.
We are already developing a prototype with a number of RX Queue different from
TX Queues.

We would like to resume a discussion that we had a couple of months ago, about
Synopsys testing stmmac in market boards. Currently I am the new Software Team
Manager and so I would like to say to you that we are interested in testing the
driver in several boards to assure quality in the stmmac driver, since we will
be constantly developing the new features for future HW releases.

If some vendors can send us sample boards it would be great, if we have to buy
some, it would be very useful to have reference suggestions.

Thanks and best regards,
Joao

> This code is obviously wrong:
> for (chan = 0; chan < tx_channel_count; chan++) {
> struct stmmac_rx_queue *rx_q = >rx_queue[chan];
> 
> priv->rx_queue has size MTL_MAX_RX_QUEUES, so this will send an
> uninitialized napi_struct to __napi_schedule(), causing us to
> crash in net_rx_action(), because napi_struct->poll is zero.
> 
> [12846.759880] Unable to handle kernel NULL pointer dereference at virtual 
> address 
> [12846.768014] pgd = (ptrval)
> [12846.770742] [] *pgd=39ec7831, *pte=, *ppte=
> [12846.777023] Internal error: Oops: 8007 [#1] PREEMPT SMP ARM
> [12846.782942] Modules linked in:
> [12846.785998] CPU: 0 PID: 161 Comm: dropbear Not tainted 
> 4.15.0-rc2-00285-gf5fb5f2f39a7 #36
> [12846.794177] Hardware name: Axis ARTPEC-6 Platform
> [12846.798879] task: (ptrval) task.stack: (ptrval)
> [12846.803407] PC is at 0x0
> [12846.805942] LR is at net_rx_action+0x274/0x43c
> [12846.810383] pc : [<>]lr : [<80bff064>]psr: 200e0113
> [12846.816648] sp : b90d9ae8  ip : b90d9ae8  fp : b90d9b44
> [12846.821871] r10: 0008  r9 : 0013250e  r8 : 0100
> [12846.827094] r7 : 012c  r6 :   r5 : 0001  r4 : bac84900
> [12846.833619] r3 :   r2 : b90d9b08  r1 :   r0 : bac84900
> 
> Since each DMA channel can be used for rx and tx simultaneously,
> the current code should probably be rewritten so that napi_struct is
> embedded in a new struct stmmac_channel.
> That way, stmmac_poll() can call stmmac_tx_clean() on just the tx queue
> where we got the IRQ, instead of looping through all tx queues.
> This is also how the xgbe driver does it (another driver for this IP).
> 
> Fixes: c22a3f48ef99 ("net: stmmac: adding multiple napi mechanism")
> Signed-off-by: Niklas Cassel 
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 54 
> +++
>  1 file changed, 46 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index d7250539d0bd..c52a9963c19d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1997,22 +1997,60 @@ static void stmmac_set_dma_operation_mode(struct 
> stmmac_priv *priv, u32 txmode,
>  static void stmmac_dma_interrupt(struct stmmac_priv *priv)
>  {
>   u32 tx_channel_count = priv->plat->tx_queues_to_use;
> - int status;
> + u32 rx_channel_count = priv->plat->rx_queues_to_use;
> + u32 channels_to_check = tx_channel_count > rx_channel_count ?
> + tx_channel_count : rx_channel_count;
>   u32 chan;
> + bool poll_scheduled = false;
> + int status[channels_to_check];
> +
> + /* Each DMA channel can be used for rx and tx simultaneously, yet
> +  * napi_struct is embedded in struct stmmac_rx_queue rather than in a
> +  * stmmac_channel struct.
> +  * Because of this, stmmac_poll currently checks (and possibly wakes)
> +  * all tx queues rather than just a single tx queue.
> +  */
> + for (chan = 0; chan < channels_to_check; chan++)
> + status[chan] = priv->hw->dma->dma_interrupt(priv->ioaddr,
> + >xstats,
> + chan);
>  
> - for (chan = 0; chan < tx_channel_count; chan++) {
> - struct stmmac_rx_queue *rx_q = >rx_queue[chan];
> + for (chan = 0; chan < rx_channel_count; chan++) {
> + if (likely(status[chan] & handle_rx)) {
> + struct stmmac_rx_queue *rx_q = >rx_queue[chan];
>  
> - status = priv->hw->dma->dma_interrupt(priv->ioaddr,
> -   >xstats, chan);
> - if (likely((status & handle_rx)) || (status & handle_tx)) {
>   if (likely(napi_schedule_prep(_q->napi))) {
>

Re: [PATCH v4 01/17] PCI: dwc: Use the DMA-API to get the MSI address

[Joao Pinto]

Hello to all,

Às 12:56 AM de 11/8/2017, Bjorn Helgaas escreveu:
> On Fri, Nov 03, 2017 at 02:47:05PM +0100, Niklas Cassel wrote:
>> Use the DMA-API to get the MSI address. This address will be written to
>> our PCI config space and to the register which determines which AXI
>> address the DWC IP will spoof for incoming MSI irqs.
>>
>> Since it is a PCIe endpoint device, rather than the CPU, that is supposed
>> to write to the MSI address, the proper way to get the MSI address is by
>> using the DMA API, not by using virt_to_phys().
>>
>> Using virt_to_phys() might work on some systems, but using the DMA API
>> should work on all systems.
>>
>> This is essentially the same thing as allocating a buffer in a driver
>> to which the endpoint will write to. To do this, we use the DMA API.
>>
>> Signed-off-by: Niklas Cassel 
> 
> I'm expecting Jingoo and/or Joao to chime in and ack the
> DesignWare-related patches.  I think all the others are in
> pretty good shape.
> 
>> ---
>>  drivers/pci/dwc/pcie-designware-host.c | 15 ---
>>  drivers/pci/dwc/pcie-designware.h  |  3 ++-
>>  2 files changed, 14 insertions(+), 4 deletions(-)
>> ...

Let me test this patch-set in my setup first!
I will give feedback until Friday.

Thanks,
Joao

Re: [PATCH v4 01/17] PCI: dwc: Use the DMA-API to get the MSI address

[Joao Pinto]

Hello to all,

Às 12:56 AM de 11/8/2017, Bjorn Helgaas escreveu:
> On Fri, Nov 03, 2017 at 02:47:05PM +0100, Niklas Cassel wrote:
>> Use the DMA-API to get the MSI address. This address will be written to
>> our PCI config space and to the register which determines which AXI
>> address the DWC IP will spoof for incoming MSI irqs.
>>
>> Since it is a PCIe endpoint device, rather than the CPU, that is supposed
>> to write to the MSI address, the proper way to get the MSI address is by
>> using the DMA API, not by using virt_to_phys().
>>
>> Using virt_to_phys() might work on some systems, but using the DMA API
>> should work on all systems.
>>
>> This is essentially the same thing as allocating a buffer in a driver
>> to which the endpoint will write to. To do this, we use the DMA API.
>>
>> Signed-off-by: Niklas Cassel 
> 
> I'm expecting Jingoo and/or Joao to chime in and ack the
> DesignWare-related patches.  I think all the others are in
> pretty good shape.
> 
>> ---
>>  drivers/pci/dwc/pcie-designware-host.c | 15 ---
>>  drivers/pci/dwc/pcie-designware.h  |  3 ++-
>>  2 files changed, 14 insertions(+), 4 deletions(-)
>> ...

Let me test this patch-set in my setup first!
I will give feedback until Friday.

Thanks,
Joao

Re: [PATCH] pci: dwc: Clear MSI interrupt status after it is handled

[Joao Pinto]

Hello,

Às 12:24 PM de 8/10/2017, Faiz Abbas escreveu:
> If the interrupt status is cleared before it is handled, it is possible
> that another interrupt will trigger while servicing the previous one.
> This is causing timeouts in some wireless lan cards which use pcie.
> Therefore, clear MSI interrupt status after it gets serviced instead
> of before calling generic_handler.
> 
> Signed-off-by: Faiz Abbas <faiz_ab...@ti.com>
> ---
>  drivers/pci/dwc/pcie-designware-host.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-host.c 
> b/drivers/pci/dwc/pcie-designware-host.c
> index 28ed32b..78b2584 100644
> --- a/drivers/pci/dwc/pcie-designware-host.c
> +++ b/drivers/pci/dwc/pcie-designware-host.c
> @@ -71,9 +71,9 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
>   while ((pos = find_next_bit((unsigned long *) , 32,
>   pos)) != 32) {
>   irq = irq_find_mapping(pp->irq_domain, i * 32 + pos);
> + generic_handle_irq(irq);
>   dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_STATUS + i * 12,
>   4, 1 << pos);
> - generic_handle_irq(irq);
>       pos++;
>   }
>   }
> 

It makes sense.

Acked-By: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH] pci: dwc: Clear MSI interrupt status after it is handled

[Joao Pinto]

Hello,

Às 12:24 PM de 8/10/2017, Faiz Abbas escreveu:
> If the interrupt status is cleared before it is handled, it is possible
> that another interrupt will trigger while servicing the previous one.
> This is causing timeouts in some wireless lan cards which use pcie.
> Therefore, clear MSI interrupt status after it gets serviced instead
> of before calling generic_handler.
> 
> Signed-off-by: Faiz Abbas 
> ---
>  drivers/pci/dwc/pcie-designware-host.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware-host.c 
> b/drivers/pci/dwc/pcie-designware-host.c
> index 28ed32b..78b2584 100644
> --- a/drivers/pci/dwc/pcie-designware-host.c
> +++ b/drivers/pci/dwc/pcie-designware-host.c
> @@ -71,9 +71,9 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
>   while ((pos = find_next_bit((unsigned long *) , 32,
>   pos)) != 32) {
>   irq = irq_find_mapping(pp->irq_domain, i * 32 + pos);
> + generic_handle_irq(irq);
>   dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_STATUS + i * 12,
>   4, 1 << pos);
> - generic_handle_irq(irq);
>   pos++;
>   }
>   }
> 

It makes sense.

Acked-By: Joao Pinto 

Re: [PATCH 1/1] scsi: ufs: changing maintainer

[Joao Pinto]

Hello Greg and Prabu,

Às 10:31 AM de 7/18/2017, Greg  Kroah-Hartman (gre...@linuxfoundation.org) 
escreveu:
> On Tue, Jul 18, 2017 at 09:15:58AM +, Prabu Thangamuthu wrote:
>> As per internal decision, Joao Pinto will be maintainer for DWC UFS driver.
> 
> That's "odd", does Joao want this?  Do you want this?
> 
> thanks,
> 
> greg k-h
> 

I developed and submited the driver a year ago, so I would be glad to maintain
it once again, no problem.

Best Regards,
Joao

Re: [PATCH 1/1] scsi: ufs: changing maintainer

[Joao Pinto]

Hello Greg and Prabu,

Às 10:31 AM de 7/18/2017, Greg  Kroah-Hartman (gre...@linuxfoundation.org) 
escreveu:
> On Tue, Jul 18, 2017 at 09:15:58AM +, Prabu Thangamuthu wrote:
>> As per internal decision, Joao Pinto will be maintainer for DWC UFS driver.
> 
> That's "odd", does Joao want this?  Do you want this?
> 
> thanks,
> 
> greg k-h
> 

I developed and submited the driver a year ago, so I would be glad to maintain
it once again, no problem.

Best Regards,
Joao

Re: [PATCH] PCI: dwc: designware: make dw_pcie_prog_*_atu_unroll() static

[Joao Pinto]

Hi Carlos,

Às 2:13 PM de 7/17/2017, Carlos Palminha escreveu:
> Helper functions dw_pcie_prog_*_atu_unroll don't need to be in global scope,
> so make it static.
> 
> Cleans up sparse warnings:
> - symbol 'dw_pcie_prog_outbound_atu_unroll' was not declared. Should it be 
> static?
> - symbol 'dw_pcie_prog_inbound_atu_unroll' was not declared. Should it be 
> static?
> 
> Signed-off-by: Carlos Palminha <palmi...@synopsys.com>
> ---
> Patch made against linux-next tree, tag next-20170714
> 
>  drivers/pci/dwc/pcie-designware.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware.c 
> b/drivers/pci/dwc/pcie-designware.c
> index 0e03af279259..48d6d0712ea8 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -107,7 +107,7 @@ static void dw_pcie_writel_ob_unroll(struct dw_pcie *pci, 
> u32 index, u32 reg,
>   dw_pcie_writel_dbi(pci, offset + reg, val);
>  }
> 
> -void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index, int 
> type,
> +static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index, 
> int type,
> u64 cpu_addr, u64 pci_addr, u32 size)
>  {
>   u32 retries, val;
> @@ -200,7 +200,7 @@ static void dw_pcie_writel_ib_unroll(struct dw_pcie *pci, 
> u32 index, u32 reg,
>   dw_pcie_writel_dbi(pci, offset + reg, val);
>  }
> 
> -int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie *pci, int index, int bar,
> +static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie *pci, int index, 
> int bar,
>   u64 cpu_addr, enum dw_pcie_as_type as_type)
>  {
>   int type;
> --
> 2.11.0
> 

That indeed escaped in the refactoring :) Thanks!

Acked-by: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH] PCI: dwc: designware: make dw_pcie_prog_*_atu_unroll() static

[Joao Pinto]

Hi Carlos,

Às 2:13 PM de 7/17/2017, Carlos Palminha escreveu:
> Helper functions dw_pcie_prog_*_atu_unroll don't need to be in global scope,
> so make it static.
> 
> Cleans up sparse warnings:
> - symbol 'dw_pcie_prog_outbound_atu_unroll' was not declared. Should it be 
> static?
> - symbol 'dw_pcie_prog_inbound_atu_unroll' was not declared. Should it be 
> static?
> 
> Signed-off-by: Carlos Palminha 
> ---
> Patch made against linux-next tree, tag next-20170714
> 
>  drivers/pci/dwc/pcie-designware.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware.c 
> b/drivers/pci/dwc/pcie-designware.c
> index 0e03af279259..48d6d0712ea8 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -107,7 +107,7 @@ static void dw_pcie_writel_ob_unroll(struct dw_pcie *pci, 
> u32 index, u32 reg,
>   dw_pcie_writel_dbi(pci, offset + reg, val);
>  }
> 
> -void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index, int 
> type,
> +static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index, 
> int type,
> u64 cpu_addr, u64 pci_addr, u32 size)
>  {
>   u32 retries, val;
> @@ -200,7 +200,7 @@ static void dw_pcie_writel_ib_unroll(struct dw_pcie *pci, 
> u32 index, u32 reg,
>   dw_pcie_writel_dbi(pci, offset + reg, val);
>  }
> 
> -int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie *pci, int index, int bar,
> +static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie *pci, int index, 
> int bar,
>   u64 cpu_addr, enum dw_pcie_as_type as_type)
>  {
>   int type;
> --
> 2.11.0
> 

That indeed escaped in the refactoring :) Thanks!

Acked-by: Joao Pinto 

Re: [PATCH 1/3] PCI: dwc: Handle host_init failures

[Joao Pinto]

ie_host_init(struct pcie_port *pp)
>  
>   if (IS_ENABLED(CONFIG_PCI_MSI))
>   dw_pcie_msi_init(pp);
> +
> + return 0;
>  }
>  
>  static const struct dw_pcie_host_ops dw_plat_pcie_host_ops = {
> diff --git a/drivers/pci/dwc/pcie-designware.h 
> b/drivers/pci/dwc/pcie-designware.h
> index b4d2a89f8e58..7366c8167404 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -134,7 +134,7 @@ struct dw_pcie_host_ops {
>unsigned int devfn, int where, int size, u32 *val);
>   int (*wr_other_conf)(struct pcie_port *pp, struct pci_bus *bus,
>unsigned int devfn, int where, int size, u32 val);
> - void (*host_init)(struct pcie_port *pp);
> + int (*host_init)(struct pcie_port *pp);
>   void (*msi_set_irq)(struct pcie_port *pp, int irq);
>   void (*msi_clear_irq)(struct pcie_port *pp, int irq);
>   phys_addr_t (*get_msi_addr)(struct pcie_port *pp);
> diff --git a/drivers/pci/dwc/pcie-kirin.c b/drivers/pci/dwc/pcie-kirin.c
> index 33fddb9f6739..0b0eb67f2658 100644
> --- a/drivers/pci/dwc/pcie-kirin.c
> +++ b/drivers/pci/dwc/pcie-kirin.c
> @@ -430,9 +430,11 @@ static int kirin_pcie_establish_link(struct pcie_port 
> *pp)
>   return 0;
>  }
>  
> -static void kirin_pcie_host_init(struct pcie_port *pp)
> +static int kirin_pcie_host_init(struct pcie_port *pp)
>  {
>   kirin_pcie_establish_link(pp);
> +
> + return 0;
>  }
>  
>  static struct dw_pcie_ops kirin_dw_pcie_ops = {
> diff --git a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c
> index 68c5f2ab5bc8..d15657dc3990 100644
> --- a/drivers/pci/dwc/pcie-qcom.c
> +++ b/drivers/pci/dwc/pcie-qcom.c
> @@ -891,7 +891,7 @@ static int qcom_pcie_link_up(struct dw_pcie *pci)
>   return !!(val & PCI_EXP_LNKSTA_DLLLA);
>  }
>  
> -static void qcom_pcie_host_init(struct pcie_port *pp)
> +static int qcom_pcie_host_init(struct pcie_port *pp)
>  {
>   struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>   struct qcom_pcie *pcie = to_qcom_pcie(pci);
> @@ -921,12 +921,14 @@ static void qcom_pcie_host_init(struct pcie_port *pp)
>   if (ret)
>   goto err;
>  
> - return;
> + return 0;
>  err:
>   qcom_ep_reset_assert(pcie);
>   phy_power_off(pcie->phy);
>  err_deinit:
>   pcie->ops->deinit(pcie);
> +
> + return ret;
>  }
>  
>  static int qcom_pcie_rd_own_conf(struct pcie_port *pp, int where, int size,
> diff --git a/drivers/pci/dwc/pcie-spear13xx.c 
> b/drivers/pci/dwc/pcie-spear13xx.c
> index 80897291e0fb..52000bc34600 100644
> --- a/drivers/pci/dwc/pcie-spear13xx.c
> +++ b/drivers/pci/dwc/pcie-spear13xx.c
> @@ -177,13 +177,15 @@ static int spear13xx_pcie_link_up(struct dw_pcie *pci)
>   return 0;
>  }
>  
> -static void spear13xx_pcie_host_init(struct pcie_port *pp)
> +static int spear13xx_pcie_host_init(struct pcie_port *pp)
>  {
>   struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>   struct spear13xx_pcie *spear13xx_pcie = to_spear13xx_pcie(pci);
>  
>   spear13xx_pcie_establish_link(spear13xx_pcie);
>   spear13xx_pcie_enable_interrupts(spear13xx_pcie);
> +
> + return 0;
>  }
>  
>  static const struct dw_pcie_host_ops spear13xx_pcie_host_ops = {
> 

A step in the right direction :). In the future we should add host init
validation in the specific SoC drivers, like Layerscape and Qcom have, to assure
that any problem is treated properly in the core driver.

Acked-by: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH 1/3] PCI: dwc: Handle host_init failures

[Joao Pinto]

t;   if (IS_ENABLED(CONFIG_PCI_MSI))
>   dw_pcie_msi_init(pp);
> +
> + return 0;
>  }
>  
>  static const struct dw_pcie_host_ops dw_plat_pcie_host_ops = {
> diff --git a/drivers/pci/dwc/pcie-designware.h 
> b/drivers/pci/dwc/pcie-designware.h
> index b4d2a89f8e58..7366c8167404 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -134,7 +134,7 @@ struct dw_pcie_host_ops {
>unsigned int devfn, int where, int size, u32 *val);
>   int (*wr_other_conf)(struct pcie_port *pp, struct pci_bus *bus,
>unsigned int devfn, int where, int size, u32 val);
> - void (*host_init)(struct pcie_port *pp);
> + int (*host_init)(struct pcie_port *pp);
>   void (*msi_set_irq)(struct pcie_port *pp, int irq);
>   void (*msi_clear_irq)(struct pcie_port *pp, int irq);
>   phys_addr_t (*get_msi_addr)(struct pcie_port *pp);
> diff --git a/drivers/pci/dwc/pcie-kirin.c b/drivers/pci/dwc/pcie-kirin.c
> index 33fddb9f6739..0b0eb67f2658 100644
> --- a/drivers/pci/dwc/pcie-kirin.c
> +++ b/drivers/pci/dwc/pcie-kirin.c
> @@ -430,9 +430,11 @@ static int kirin_pcie_establish_link(struct pcie_port 
> *pp)
>   return 0;
>  }
>  
> -static void kirin_pcie_host_init(struct pcie_port *pp)
> +static int kirin_pcie_host_init(struct pcie_port *pp)
>  {
>   kirin_pcie_establish_link(pp);
> +
> + return 0;
>  }
>  
>  static struct dw_pcie_ops kirin_dw_pcie_ops = {
> diff --git a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c
> index 68c5f2ab5bc8..d15657dc3990 100644
> --- a/drivers/pci/dwc/pcie-qcom.c
> +++ b/drivers/pci/dwc/pcie-qcom.c
> @@ -891,7 +891,7 @@ static int qcom_pcie_link_up(struct dw_pcie *pci)
>   return !!(val & PCI_EXP_LNKSTA_DLLLA);
>  }
>  
> -static void qcom_pcie_host_init(struct pcie_port *pp)
> +static int qcom_pcie_host_init(struct pcie_port *pp)
>  {
>   struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>   struct qcom_pcie *pcie = to_qcom_pcie(pci);
> @@ -921,12 +921,14 @@ static void qcom_pcie_host_init(struct pcie_port *pp)
>   if (ret)
>   goto err;
>  
> - return;
> + return 0;
>  err:
>   qcom_ep_reset_assert(pcie);
>   phy_power_off(pcie->phy);
>  err_deinit:
>   pcie->ops->deinit(pcie);
> +
> + return ret;
>  }
>  
>  static int qcom_pcie_rd_own_conf(struct pcie_port *pp, int where, int size,
> diff --git a/drivers/pci/dwc/pcie-spear13xx.c 
> b/drivers/pci/dwc/pcie-spear13xx.c
> index 80897291e0fb..52000bc34600 100644
> --- a/drivers/pci/dwc/pcie-spear13xx.c
> +++ b/drivers/pci/dwc/pcie-spear13xx.c
> @@ -177,13 +177,15 @@ static int spear13xx_pcie_link_up(struct dw_pcie *pci)
>   return 0;
>  }
>  
> -static void spear13xx_pcie_host_init(struct pcie_port *pp)
> +static int spear13xx_pcie_host_init(struct pcie_port *pp)
>  {
>   struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>   struct spear13xx_pcie *spear13xx_pcie = to_spear13xx_pcie(pci);
>  
>   spear13xx_pcie_establish_link(spear13xx_pcie);
>   spear13xx_pcie_enable_interrupts(spear13xx_pcie);
> +
> + return 0;
>  }
>  
>  static const struct dw_pcie_host_ops spear13xx_pcie_host_ops = {
> 

A step in the right direction :). In the future we should add host init
validation in the specific SoC drivers, like Layerscape and Qcom have, to assure
that any problem is treated properly in the core driver.

Acked-by: Joao Pinto 

Re: [PATCH] PCI: dwc: designware: test PCIE_ATU_ENABLE bit to check enabled or not

[Joao Pinto]

Hi,

Às 11:35 AM de 7/13/2017, Jisheng Zhang escreveu:
> The ATU CTRL2 register is 32 bit, besides the enable bit, other bits
> may also be set. To check whether the ATU is enabled or not, we should
> test the enable it.
> 
> Signed-off-by: Jisheng Zhang <jszh...@marvell.com>
> ---
>  drivers/pci/dwc/pcie-designware.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware.c 
> b/drivers/pci/dwc/pcie-designware.c
> index 0e03af279259..6bf0b409050a 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -177,7 +177,7 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int 
> index, int type,
>*/
>   for (retries = 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++) {
>   val = dw_pcie_readl_dbi(pci, PCIE_ATU_CR2);
> - if (val == PCIE_ATU_ENABLE)
> + if (val & PCIE_ATU_ENABLE)
>   return;
>  
>   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
> 
Make sense, turn it more accurate. Thanks!

Acked-by: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH] PCI: dwc: designware: test PCIE_ATU_ENABLE bit to check enabled or not

[Joao Pinto]

Hi,

Às 11:35 AM de 7/13/2017, Jisheng Zhang escreveu:
> The ATU CTRL2 register is 32 bit, besides the enable bit, other bits
> may also be set. To check whether the ATU is enabled or not, we should
> test the enable it.
> 
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/pci/dwc/pcie-designware.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/dwc/pcie-designware.c 
> b/drivers/pci/dwc/pcie-designware.c
> index 0e03af279259..6bf0b409050a 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -177,7 +177,7 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int 
> index, int type,
>*/
>   for (retries = 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++) {
>   val = dw_pcie_readl_dbi(pci, PCIE_ATU_CR2);
> - if (val == PCIE_ATU_ENABLE)
> + if (val & PCIE_ATU_ENABLE)
>   return;
>  
>   usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX);
> 
Make sense, turn it more accurate. Thanks!

Acked-by: Joao Pinto 

Re: [PATCH v9 2/3] PCI: Add tango PCIe host bridge support

[Joao Pinto]

Hi to all,

Às 10:38 AM de 7/4/2017, Ard Biesheuvel escreveu:
> On 4 July 2017 at 09:19, Jisheng Zhang  wrote:
>> On Tue, 4 Jul 2017 09:02:06 +0100 Ard Biesheuvel wrote:
>>
>>> On 4 July 2017 at 07:58, Jisheng Zhang  wrote:
 On Mon, 3 Jul 2017 08:27:04 -0500 wrote:

> [+cc Jingoo, Joao]
>
> On Mon, Jul 03, 2017 at 10:35:50AM +0100, Ard Biesheuvel wrote:
>> On 3 July 2017 at 00:18, Bjorn Helgaas  wrote:
>>> On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez wrote:
 This driver is required to work around several hardware bugs
 in the PCIe controller.

 NB: Revision 1 does not support legacy interrupts, or IO space.
>>>
>>> I had to apply these manually because of conflicts in Kconfig and
>>> Makefile.  What are these based on?  Easiest for me is if you base
>>> them on the current -rc1 tag.
>>>
 Signed-off-by: Marc Gonzalez 
 ---
  drivers/pci/host/Kconfig  |   8 +++
  drivers/pci/host/Makefile |   1 +
  drivers/pci/host/pcie-tango.c | 164 
 ++
  include/linux/pci_ids.h   |   2 +
  4 files changed, 175 insertions(+)
  create mode 100644 drivers/pci/host/pcie-tango.c

>> [..]
 + /*
 +  * QUIRK #2
 +  * Unfortunately, config and mem spaces are muxed.
 +  * Linux does not support such a setting, since drivers are free
 +  * to access mem space directly, at any time.
 +  * Therefore, we can only PRAY that config and mem space accesses
 +  * NEVER occur concurrently.
 +  */
 + writel_relaxed(1, pcie->mux);
 + ret = pci_generic_config_read(bus, devfn, where, size, val);
 + writel_relaxed(0, pcie->mux);
>>>
>>> I'm very hesitant about this.  When people stress this, we're going to
>>> get reports of data corruption.  Even with the disclaimer below, I
>>> don't feel good about this.  Adding the driver is an implicit claim
>>> that we support the device, but we know it can't be made reliable.
>>
>> I noticed that the Synopsys driver suffers from a similar issue: in
>> dw_pcie_rd_other_conf(), it happily reprograms the outbound I/O window
>> to perform a config space access, and switches it back to I/O space
>> afterwards (unless it has more than 2 viewports, in which case it uses
>> dedicated windows for I/O space and config space)
>
> That doesn't sound good.  Jingoo, Joao?  I remember some discussion
> about this, but not the details.
>
> I/O accesses use wrappers (inb(), etc), so there's at least the
> possibility of a mutex to serialize them with respect to config
> accesses.
>

 IIRC, for 2 viewports, we don't need to worry about the config space
 access, because config space access is serialized by pci_lock; We
 do have race between config space and io space. But the accessing config
 space and io space at the same time is rare.
>>>
>>> Being 'rare' is not sufficient, unfortunately. In the current
>>> situation, I/O space accesses may occur when the outbound window is
>>> directed to the config space of a potentially completely unrelated
>>> device. This is bad.
>>
>> Yep, I agree with you.
>>
>>>
 And the PCIe EPs which
 has io space are rare too, supporting these EPs are not the potential
 target of those platforms with 2 viewports.

>>>
>>> I am not sure EP mode is relevant here. What I do know is that boards
>>
>> I mean those PCIe EP cards which have IO space, but that doesn't matter.
>>
> 
> Ah, ok. But if such EP cards are so rare, why expose I/O space at all
> if we cannot do it safely?
> 
>>> like the Marvell 8040 based MacchiatoBin uses this IP in RC mode, and
>>> exposes config, MMIO and IO space windows using only 2 viewports. Note
>>> that this is essentially a bug in the DT description, given that its
>>> version of the IP supports 8 viewports. But the driver needs to be
>>> fixed as well.
>>
>> To fix for 2 viewports situation, we need to serialize access of the io
>> and config space. In internal repo, we can achieve it by modifying the
>> io access helper functions such as inl/outl, but this won't be accepted
>> by the mainline IMHO. Except fixing the HW, any elegant solution?
>>
>> Suggestions are appreciated.
>>
> 
> I think the safe and upstreamable approach is to disable the I/O
> window completely if num-viewports <= 2.
> 

I think that the critical case is when we are using a single ATU region, and
that has to managed by software. The hardware is not capable of managing racing
conditions, like programming the ATU while still transfering data, so problems
can ocurre for sure. In this case we should be able to add to the driver a
simple lock 

Re: [PATCH v9 2/3] PCI: Add tango PCIe host bridge support

[Joao Pinto]

Hi to all,

Às 10:38 AM de 7/4/2017, Ard Biesheuvel escreveu:
> On 4 July 2017 at 09:19, Jisheng Zhang  wrote:
>> On Tue, 4 Jul 2017 09:02:06 +0100 Ard Biesheuvel wrote:
>>
>>> On 4 July 2017 at 07:58, Jisheng Zhang  wrote:
 On Mon, 3 Jul 2017 08:27:04 -0500 wrote:

> [+cc Jingoo, Joao]
>
> On Mon, Jul 03, 2017 at 10:35:50AM +0100, Ard Biesheuvel wrote:
>> On 3 July 2017 at 00:18, Bjorn Helgaas  wrote:
>>> On Tue, Jun 20, 2017 at 10:17:40AM +0200, Marc Gonzalez wrote:
 This driver is required to work around several hardware bugs
 in the PCIe controller.

 NB: Revision 1 does not support legacy interrupts, or IO space.
>>>
>>> I had to apply these manually because of conflicts in Kconfig and
>>> Makefile.  What are these based on?  Easiest for me is if you base
>>> them on the current -rc1 tag.
>>>
 Signed-off-by: Marc Gonzalez 
 ---
  drivers/pci/host/Kconfig  |   8 +++
  drivers/pci/host/Makefile |   1 +
  drivers/pci/host/pcie-tango.c | 164 
 ++
  include/linux/pci_ids.h   |   2 +
  4 files changed, 175 insertions(+)
  create mode 100644 drivers/pci/host/pcie-tango.c

>> [..]
 + /*
 +  * QUIRK #2
 +  * Unfortunately, config and mem spaces are muxed.
 +  * Linux does not support such a setting, since drivers are free
 +  * to access mem space directly, at any time.
 +  * Therefore, we can only PRAY that config and mem space accesses
 +  * NEVER occur concurrently.
 +  */
 + writel_relaxed(1, pcie->mux);
 + ret = pci_generic_config_read(bus, devfn, where, size, val);
 + writel_relaxed(0, pcie->mux);
>>>
>>> I'm very hesitant about this.  When people stress this, we're going to
>>> get reports of data corruption.  Even with the disclaimer below, I
>>> don't feel good about this.  Adding the driver is an implicit claim
>>> that we support the device, but we know it can't be made reliable.
>>
>> I noticed that the Synopsys driver suffers from a similar issue: in
>> dw_pcie_rd_other_conf(), it happily reprograms the outbound I/O window
>> to perform a config space access, and switches it back to I/O space
>> afterwards (unless it has more than 2 viewports, in which case it uses
>> dedicated windows for I/O space and config space)
>
> That doesn't sound good.  Jingoo, Joao?  I remember some discussion
> about this, but not the details.
>
> I/O accesses use wrappers (inb(), etc), so there's at least the
> possibility of a mutex to serialize them with respect to config
> accesses.
>

 IIRC, for 2 viewports, we don't need to worry about the config space
 access, because config space access is serialized by pci_lock; We
 do have race between config space and io space. But the accessing config
 space and io space at the same time is rare.
>>>
>>> Being 'rare' is not sufficient, unfortunately. In the current
>>> situation, I/O space accesses may occur when the outbound window is
>>> directed to the config space of a potentially completely unrelated
>>> device. This is bad.
>>
>> Yep, I agree with you.
>>
>>>
 And the PCIe EPs which
 has io space are rare too, supporting these EPs are not the potential
 target of those platforms with 2 viewports.

>>>
>>> I am not sure EP mode is relevant here. What I do know is that boards
>>
>> I mean those PCIe EP cards which have IO space, but that doesn't matter.
>>
> 
> Ah, ok. But if such EP cards are so rare, why expose I/O space at all
> if we cannot do it safely?
> 
>>> like the Marvell 8040 based MacchiatoBin uses this IP in RC mode, and
>>> exposes config, MMIO and IO space windows using only 2 viewports. Note
>>> that this is essentially a bug in the DT description, given that its
>>> version of the IP supports 8 viewports. But the driver needs to be
>>> fixed as well.
>>
>> To fix for 2 viewports situation, we need to serialize access of the io
>> and config space. In internal repo, we can achieve it by modifying the
>> io access helper functions such as inl/outl, but this won't be accepted
>> by the mainline IMHO. Except fixing the HW, any elegant solution?
>>
>> Suggestions are appreciated.
>>
> 
> I think the safe and upstreamable approach is to disable the I/O
> window completely if num-viewports <= 2.
> 

I think that the critical case is when we are using a single ATU region, and
that has to managed by software. The hardware is not capable of managing racing
conditions, like programming the ATU while still transfering data, so problems
can ocurre for sure. In this case we should be able to add to the driver a
simple lock to signal that the ATU is being used. If the ATU was being used we
could make a spinlock for 

Re: [PATCH V4 2/2] scsi: ufshcd-pci: Add Intel CNL support

[Joao Pinto]

Hello to all,

Às 2:16 PM de 6/7/2017, Christoph Hellwig escreveu:
> On Tue, Jun 06, 2017 at 02:35:31PM +0300, Adrian Hunter wrote:
>> Add PCI id and variant ops for Intel CNL UFS host controller.
> 
> Looks good:
> 
> Reviewed-by: Christoph Hellwig 
> 
> It would be great if we could fold tc-dwc-g210-pci into ufshcd-pci the
> same way.
> 

I have forward the suggestion to the person on charge of UFS driver maintenance
at Synopsys. We will definitely have a look at it!

Thanks,
Joao

Re: [PATCH V4 2/2] scsi: ufshcd-pci: Add Intel CNL support

[Joao Pinto]

Hello to all,

Às 2:16 PM de 6/7/2017, Christoph Hellwig escreveu:
> On Tue, Jun 06, 2017 at 02:35:31PM +0300, Adrian Hunter wrote:
>> Add PCI id and variant ops for Intel CNL UFS host controller.
> 
> Looks good:
> 
> Reviewed-by: Christoph Hellwig 
> 
> It would be great if we could fold tc-dwc-g210-pci into ufshcd-pci the
> same way.
> 

I have forward the suggestion to the person on charge of UFS driver maintenance
at Synopsys. We will definitely have a look at it!

Thanks,
Joao

Re: Regression: 442ec4c04d1: PCI: dwc: all: Split struct pcie_port into host-only and core structures

[Joao Pinto]

Às 4:20 PM de 5/8/2017, Kishon Vijay Abraham I escreveu:
> Hi Joao,
> 
> On Monday 08 May 2017 08:43 PM, Joao Pinto wrote:
>>
>> Hi Peter,
>>
>> Às 4:02 PM de 5/8/2017, Peter Senna Tschudin escreveu:
>>> Hello Kishon,
>>>
>>> Our iMX6 hardware (imx6q-b850v3.dts) is not booting with latest
>>> linux-next and I could bisect until:
>>>
>>> commit 442ec4c04d1235f8c664a74004dae54a7a574d18
>>> Author: Kishon Vijay Abraham I <kis...@ti.com>
>>> Date:   Wed Feb 15 18:48:14 2017 +0530
>>>
>>> PCI: dwc: all: Split struct pcie_port into host-only and core structures
>>>
>>> Which seem to be causing our issues. Our device (imx6q-b850v3.dts) boots
>>> fine with 4.10, and also boots if we disable pcie with:
>>>
>>> diff --git a/arch/arm/boot/dts/imx6q-b850v3.dts 
>>> b/arch/arm/boot/dts/imx6q-b850v3.dts
>>> index 2c1e98e..e655fd7 100644
>>> --- a/arch/arm/boot/dts/imx6q-b850v3.dts
>>> +++ b/arch/arm/boot/dts/imx6q-b850v3.dts
>>> @@ -212,3 +212,8 @@
>>> };
>>> };
>>>  };
>>> +
>>> + {
>>> +status = "disabled";
>>> +};
>>>
>>> But otherwise our system freezes while initializing PCI, see dmesg with
>>> some more information. Is this something specific of our system/dt or
>>> can this be a bug that is affecting others as well?
>>>
>>> Kind Regards,
>>>
>>> Peter
>>>
>>> Starting kernel ...
>>>
>>> Uncompressing Linux... done, booting the kernel.
>>> [0.00] Booting Linux on physical CPU 0x0
>>> [0.00] Linux version 4.11.0-next-20170508-dirty 
>>> (pe...@lenovo-peter.home) (gcc version 6.1.1 20160621 (Red Hat Cross 
>>> 6.1.1-2) (GCC) 7
>>> [0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), 
>>> cr=10c5387d
>>> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
>>> instruction cache
>>> [0.00] OF: fdt: Machine model: General Electric B850v3
>>> [0.00] earlycon: ec_imx21 at MMIO 0x021ec000 (options '')
>>> [0.00] bootconsole [ec_imx21] enabled
>>> [0.00] Memory policy: Data cache writealloc
>>> [0.00] cma: Reserved 128 MiB at 0x8800
>>> [0.00] On node 0 totalpages: 524288
>>> [0.00] free_area_init_node: node 0, pgdat 80d74fc0, node_mem_map 
>>> eeff7000
>>> [0.00]   Normal zone: 3584 pages used for memmap
>>> [0.00]   Normal zone: 0 pages reserved
>>> [0.00]   Normal zone: 458752 pages, LIFO batch:31
>>> [0.00]   HighMem zone: 65536 pages, LIFO batch:15
>>> [0.00] percpu: Embedded 17 pages/cpu @eefb3000 s37900 r8192 d23540 
>>> u69632
>>> [0.00] pcpu-alloc: s37900 r8192 d23540 u69632 alloc=17*4096
>>> [0.00] pcpu-alloc: [0] 0 [0] 1
>>> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  
>>> Total pages: 520704
>>> [0.00] Kernel command line: root=/dev/mmcblk0p2 ro rootwait 
>>> cma=128M video=DP-1:1024x768@60 video=HDMI-A-1:1024x768@60 earlycon logl0
>>> [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
>>> [0.00] Dentry cache hash table entries: 262144 (order: 8, 1048576 
>>> bytes)
>>> [0.00] Inode-cache hash table entries: 131072 (order: 7, 524288 
>>> bytes)
>>> [0.00] Memory: 1934676K/2097152K available (8192K kernel code, 502K 
>>> rwdata, 2220K rodata, 1024K init, 309K bss, 31404K reserved, 131)
>>> [0.00] Virtual kernel memory layout:
>>> [0.00] vector  : 0x - 0x1000   (   4 kB)
>>> [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
>>> [0.00] vmalloc : 0xf080 - 0xff80   ( 240 MB)
>>> [0.00] lowmem  : 0x8000 - 0xf000   (1792 MB)
>>> [0.00] pkmap   : 0x7fe0 - 0x8000   (   2 MB)
>>> [0.00] modules : 0x7f00 - 0x7fe0   (  14 MB)
>>> [0.00]   .text : 0x80008000 - 0x8090   (9184 kB)
>>> [0.00]   .init : 0x80c0 - 0x80d0   (1024 kB)
>>> [0.00]   .data : 0x80d0 - 0x80d7d874   ( 503 kB)
>>> [0.00].bss : 0x80d7f000 - 0x80dcc6c0   ( 310 kB)
>>> [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
>>> [0.00] ftrace: allocat

Re: Regression: 442ec4c04d1: PCI: dwc: all: Split struct pcie_port into host-only and core structures

[Joao Pinto]

Às 4:20 PM de 5/8/2017, Kishon Vijay Abraham I escreveu:
> Hi Joao,
> 
> On Monday 08 May 2017 08:43 PM, Joao Pinto wrote:
>>
>> Hi Peter,
>>
>> Às 4:02 PM de 5/8/2017, Peter Senna Tschudin escreveu:
>>> Hello Kishon,
>>>
>>> Our iMX6 hardware (imx6q-b850v3.dts) is not booting with latest
>>> linux-next and I could bisect until:
>>>
>>> commit 442ec4c04d1235f8c664a74004dae54a7a574d18
>>> Author: Kishon Vijay Abraham I 
>>> Date:   Wed Feb 15 18:48:14 2017 +0530
>>>
>>> PCI: dwc: all: Split struct pcie_port into host-only and core structures
>>>
>>> Which seem to be causing our issues. Our device (imx6q-b850v3.dts) boots
>>> fine with 4.10, and also boots if we disable pcie with:
>>>
>>> diff --git a/arch/arm/boot/dts/imx6q-b850v3.dts 
>>> b/arch/arm/boot/dts/imx6q-b850v3.dts
>>> index 2c1e98e..e655fd7 100644
>>> --- a/arch/arm/boot/dts/imx6q-b850v3.dts
>>> +++ b/arch/arm/boot/dts/imx6q-b850v3.dts
>>> @@ -212,3 +212,8 @@
>>> };
>>> };
>>>  };
>>> +
>>> + {
>>> +status = "disabled";
>>> +};
>>>
>>> But otherwise our system freezes while initializing PCI, see dmesg with
>>> some more information. Is this something specific of our system/dt or
>>> can this be a bug that is affecting others as well?
>>>
>>> Kind Regards,
>>>
>>> Peter
>>>
>>> Starting kernel ...
>>>
>>> Uncompressing Linux... done, booting the kernel.
>>> [0.00] Booting Linux on physical CPU 0x0
>>> [0.00] Linux version 4.11.0-next-20170508-dirty 
>>> (pe...@lenovo-peter.home) (gcc version 6.1.1 20160621 (Red Hat Cross 
>>> 6.1.1-2) (GCC) 7
>>> [0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), 
>>> cr=10c5387d
>>> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
>>> instruction cache
>>> [0.00] OF: fdt: Machine model: General Electric B850v3
>>> [0.00] earlycon: ec_imx21 at MMIO 0x021ec000 (options '')
>>> [0.00] bootconsole [ec_imx21] enabled
>>> [0.00] Memory policy: Data cache writealloc
>>> [0.00] cma: Reserved 128 MiB at 0x8800
>>> [0.00] On node 0 totalpages: 524288
>>> [0.00] free_area_init_node: node 0, pgdat 80d74fc0, node_mem_map 
>>> eeff7000
>>> [0.00]   Normal zone: 3584 pages used for memmap
>>> [0.00]   Normal zone: 0 pages reserved
>>> [0.00]   Normal zone: 458752 pages, LIFO batch:31
>>> [0.00]   HighMem zone: 65536 pages, LIFO batch:15
>>> [0.00] percpu: Embedded 17 pages/cpu @eefb3000 s37900 r8192 d23540 
>>> u69632
>>> [0.00] pcpu-alloc: s37900 r8192 d23540 u69632 alloc=17*4096
>>> [0.00] pcpu-alloc: [0] 0 [0] 1
>>> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  
>>> Total pages: 520704
>>> [0.00] Kernel command line: root=/dev/mmcblk0p2 ro rootwait 
>>> cma=128M video=DP-1:1024x768@60 video=HDMI-A-1:1024x768@60 earlycon logl0
>>> [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
>>> [0.00] Dentry cache hash table entries: 262144 (order: 8, 1048576 
>>> bytes)
>>> [0.00] Inode-cache hash table entries: 131072 (order: 7, 524288 
>>> bytes)
>>> [0.00] Memory: 1934676K/2097152K available (8192K kernel code, 502K 
>>> rwdata, 2220K rodata, 1024K init, 309K bss, 31404K reserved, 131)
>>> [0.00] Virtual kernel memory layout:
>>> [0.00] vector  : 0x - 0x1000   (   4 kB)
>>> [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
>>> [0.00] vmalloc : 0xf080 - 0xff80   ( 240 MB)
>>> [0.00] lowmem  : 0x8000 - 0xf000   (1792 MB)
>>> [0.00] pkmap   : 0x7fe0 - 0x8000   (   2 MB)
>>> [0.00] modules : 0x7f00 - 0x7fe0   (  14 MB)
>>> [0.00]   .text : 0x80008000 - 0x8090   (9184 kB)
>>> [0.00]   .init : 0x80c0 - 0x80d0   (1024 kB)
>>> [0.00]   .data : 0x80d0 - 0x80d7d874   ( 503 kB)
>>> [0.00].bss : 0x80d7f000 - 0x80dcc6c0   ( 310 kB)
>>> [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
>>> [0.00] ftrace: allocating 28081 entries in 

Re: Regression: 442ec4c04d1: PCI: dwc: all: Split struct pcie_port into host-only and core structures

[Joao Pinto]

Hi Peter,

Às 4:02 PM de 5/8/2017, Peter Senna Tschudin escreveu:
> Hello Kishon,
> 
> Our iMX6 hardware (imx6q-b850v3.dts) is not booting with latest
> linux-next and I could bisect until:
> 
> commit 442ec4c04d1235f8c664a74004dae54a7a574d18
> Author: Kishon Vijay Abraham I 
> Date:   Wed Feb 15 18:48:14 2017 +0530
> 
> PCI: dwc: all: Split struct pcie_port into host-only and core structures
> 
> Which seem to be causing our issues. Our device (imx6q-b850v3.dts) boots
> fine with 4.10, and also boots if we disable pcie with:
> 
> diff --git a/arch/arm/boot/dts/imx6q-b850v3.dts 
> b/arch/arm/boot/dts/imx6q-b850v3.dts
> index 2c1e98e..e655fd7 100644
> --- a/arch/arm/boot/dts/imx6q-b850v3.dts
> +++ b/arch/arm/boot/dts/imx6q-b850v3.dts
> @@ -212,3 +212,8 @@
> };
> };
>  };
> +
> + {
> +status = "disabled";
> +};
> 
> But otherwise our system freezes while initializing PCI, see dmesg with
> some more information. Is this something specific of our system/dt or
> can this be a bug that is affecting others as well?
> 
> Kind Regards,
> 
> Peter
> 
> Starting kernel ...
> 
> Uncompressing Linux... done, booting the kernel.
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Linux version 4.11.0-next-20170508-dirty 
> (pe...@lenovo-peter.home) (gcc version 6.1.1 20160621 (Red Hat Cross 6.1.1-2) 
> (GCC) 7
> [0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), 
> cr=10c5387d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [0.00] OF: fdt: Machine model: General Electric B850v3
> [0.00] earlycon: ec_imx21 at MMIO 0x021ec000 (options '')
> [0.00] bootconsole [ec_imx21] enabled
> [0.00] Memory policy: Data cache writealloc
> [0.00] cma: Reserved 128 MiB at 0x8800
> [0.00] On node 0 totalpages: 524288
> [0.00] free_area_init_node: node 0, pgdat 80d74fc0, node_mem_map 
> eeff7000
> [0.00]   Normal zone: 3584 pages used for memmap
> [0.00]   Normal zone: 0 pages reserved
> [0.00]   Normal zone: 458752 pages, LIFO batch:31
> [0.00]   HighMem zone: 65536 pages, LIFO batch:15
> [0.00] percpu: Embedded 17 pages/cpu @eefb3000 s37900 r8192 d23540 
> u69632
> [0.00] pcpu-alloc: s37900 r8192 d23540 u69632 alloc=17*4096
> [0.00] pcpu-alloc: [0] 0 [0] 1
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
> pages: 520704
> [0.00] Kernel command line: root=/dev/mmcblk0p2 ro rootwait cma=128M 
> video=DP-1:1024x768@60 video=HDMI-A-1:1024x768@60 earlycon logl0
> [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
> [0.00] Dentry cache hash table entries: 262144 (order: 8, 1048576 
> bytes)
> [0.00] Inode-cache hash table entries: 131072 (order: 7, 524288 bytes)
> [0.00] Memory: 1934676K/2097152K available (8192K kernel code, 502K 
> rwdata, 2220K rodata, 1024K init, 309K bss, 31404K reserved, 131)
> [0.00] Virtual kernel memory layout:
> [0.00] vector  : 0x - 0x1000   (   4 kB)
> [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
> [0.00] vmalloc : 0xf080 - 0xff80   ( 240 MB)
> [0.00] lowmem  : 0x8000 - 0xf000   (1792 MB)
> [0.00] pkmap   : 0x7fe0 - 0x8000   (   2 MB)
> [0.00] modules : 0x7f00 - 0x7fe0   (  14 MB)
> [0.00]   .text : 0x80008000 - 0x8090   (9184 kB)
> [0.00]   .init : 0x80c0 - 0x80d0   (1024 kB)
> [0.00]   .data : 0x80d0 - 0x80d7d874   ( 503 kB)
> [0.00].bss : 0x80d7f000 - 0x80dcc6c0   ( 310 kB)
> [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> [0.00] ftrace: allocating 28081 entries in 83 pages
> [0.00] Hierarchical RCU implementation.
> [0.00]  RCU debugfs-based tracing is enabled.
> [0.00]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
> [0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
> [0.00] NR_IRQS:16 nr_irqs:16 16
> [0.00] L2C-310 errata 752271 769419 enabled
> [0.00] L2C-310 enabling early BRESP for Cortex-A9
> [0.00] L2C-310 full line of zeros enabled for Cortex-A9
> [0.00] L2C-310 ID prefetch enabled, offset 16 lines
> [0.00] L2C-310 dynamic clock gating enabled, standby mode enabled
> [0.00] L2C-310 cache controller enabled, 16 ways, 1024 kB
> [0.00] L2C-310: CACHE_ID 0x41c7, AUX_CTRL 0x76470001
> [0.00] Switching to timer-based delay loop, resolution 333ns
> [0.07] sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 
> 715827882841ns
> [0.008183] clocksource: mxc_timer1: mask: 0x max_cycles: 
> 0x, max_idle_ns: 637086815595 ns
> [0.019149] Console: colour dummy device 80x30
> [0.022277] 

Re: Regression: 442ec4c04d1: PCI: dwc: all: Split struct pcie_port into host-only and core structures

[Joao Pinto]

Hi Peter,

Às 4:02 PM de 5/8/2017, Peter Senna Tschudin escreveu:
> Hello Kishon,
> 
> Our iMX6 hardware (imx6q-b850v3.dts) is not booting with latest
> linux-next and I could bisect until:
> 
> commit 442ec4c04d1235f8c664a74004dae54a7a574d18
> Author: Kishon Vijay Abraham I 
> Date:   Wed Feb 15 18:48:14 2017 +0530
> 
> PCI: dwc: all: Split struct pcie_port into host-only and core structures
> 
> Which seem to be causing our issues. Our device (imx6q-b850v3.dts) boots
> fine with 4.10, and also boots if we disable pcie with:
> 
> diff --git a/arch/arm/boot/dts/imx6q-b850v3.dts 
> b/arch/arm/boot/dts/imx6q-b850v3.dts
> index 2c1e98e..e655fd7 100644
> --- a/arch/arm/boot/dts/imx6q-b850v3.dts
> +++ b/arch/arm/boot/dts/imx6q-b850v3.dts
> @@ -212,3 +212,8 @@
> };
> };
>  };
> +
> + {
> +status = "disabled";
> +};
> 
> But otherwise our system freezes while initializing PCI, see dmesg with
> some more information. Is this something specific of our system/dt or
> can this be a bug that is affecting others as well?
> 
> Kind Regards,
> 
> Peter
> 
> Starting kernel ...
> 
> Uncompressing Linux... done, booting the kernel.
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Linux version 4.11.0-next-20170508-dirty 
> (pe...@lenovo-peter.home) (gcc version 6.1.1 20160621 (Red Hat Cross 6.1.1-2) 
> (GCC) 7
> [0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), 
> cr=10c5387d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [0.00] OF: fdt: Machine model: General Electric B850v3
> [0.00] earlycon: ec_imx21 at MMIO 0x021ec000 (options '')
> [0.00] bootconsole [ec_imx21] enabled
> [0.00] Memory policy: Data cache writealloc
> [0.00] cma: Reserved 128 MiB at 0x8800
> [0.00] On node 0 totalpages: 524288
> [0.00] free_area_init_node: node 0, pgdat 80d74fc0, node_mem_map 
> eeff7000
> [0.00]   Normal zone: 3584 pages used for memmap
> [0.00]   Normal zone: 0 pages reserved
> [0.00]   Normal zone: 458752 pages, LIFO batch:31
> [0.00]   HighMem zone: 65536 pages, LIFO batch:15
> [0.00] percpu: Embedded 17 pages/cpu @eefb3000 s37900 r8192 d23540 
> u69632
> [0.00] pcpu-alloc: s37900 r8192 d23540 u69632 alloc=17*4096
> [0.00] pcpu-alloc: [0] 0 [0] 1
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
> pages: 520704
> [0.00] Kernel command line: root=/dev/mmcblk0p2 ro rootwait cma=128M 
> video=DP-1:1024x768@60 video=HDMI-A-1:1024x768@60 earlycon logl0
> [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
> [0.00] Dentry cache hash table entries: 262144 (order: 8, 1048576 
> bytes)
> [0.00] Inode-cache hash table entries: 131072 (order: 7, 524288 bytes)
> [0.00] Memory: 1934676K/2097152K available (8192K kernel code, 502K 
> rwdata, 2220K rodata, 1024K init, 309K bss, 31404K reserved, 131)
> [0.00] Virtual kernel memory layout:
> [0.00] vector  : 0x - 0x1000   (   4 kB)
> [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
> [0.00] vmalloc : 0xf080 - 0xff80   ( 240 MB)
> [0.00] lowmem  : 0x8000 - 0xf000   (1792 MB)
> [0.00] pkmap   : 0x7fe0 - 0x8000   (   2 MB)
> [0.00] modules : 0x7f00 - 0x7fe0   (  14 MB)
> [0.00]   .text : 0x80008000 - 0x8090   (9184 kB)
> [0.00]   .init : 0x80c0 - 0x80d0   (1024 kB)
> [0.00]   .data : 0x80d0 - 0x80d7d874   ( 503 kB)
> [0.00].bss : 0x80d7f000 - 0x80dcc6c0   ( 310 kB)
> [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> [0.00] ftrace: allocating 28081 entries in 83 pages
> [0.00] Hierarchical RCU implementation.
> [0.00]  RCU debugfs-based tracing is enabled.
> [0.00]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
> [0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
> [0.00] NR_IRQS:16 nr_irqs:16 16
> [0.00] L2C-310 errata 752271 769419 enabled
> [0.00] L2C-310 enabling early BRESP for Cortex-A9
> [0.00] L2C-310 full line of zeros enabled for Cortex-A9
> [0.00] L2C-310 ID prefetch enabled, offset 16 lines
> [0.00] L2C-310 dynamic clock gating enabled, standby mode enabled
> [0.00] L2C-310 cache controller enabled, 16 ways, 1024 kB
> [0.00] L2C-310: CACHE_ID 0x41c7, AUX_CTRL 0x76470001
> [0.00] Switching to timer-based delay loop, resolution 333ns
> [0.07] sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 
> 715827882841ns
> [0.008183] clocksource: mxc_timer1: mask: 0x max_cycles: 
> 0x, max_idle_ns: 637086815595 ns
> [0.019149] Console: colour dummy device 80x30
> [0.022277] Calibrating delay 

Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues

[Joao Pinto]

Às 12:56 PM de 5/8/2017, Andy Shevchenko escreveu:
> On Mon, May 8, 2017 at 2:40 PM, Joao Pinto <joao.pi...@synopsys.com> wrote:
>> Às 12:34 PM de 5/8/2017, Andy Shevchenko escreveu:
>>> On Mon, May 8, 2017 at 1:42 PM, Joao Pinto <joao.pi...@synopsys.com> wrote:
>>>> Às 11:12 AM de 5/8/2017, Andy Shevchenko escreveu:
>>>>> On Mon, May 8, 2017 at 12:54 PM, Joao Pinto <joao.pi...@synopsys.com> 
>>>>> wrote:
>>>>>> Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
> 
>>>
>>> [   44.374161] stmmac_dvr_probe <<< 0 0
>>>
>>
>> Ok, so this is the cause of the problem. The driver is geting 0 for real RX 
>> and
>> TX queues.
>>
>> Your setup uses standard DT parsing from stmmac_platform or a custom one?
>>
>> If you are using stmmac_probe_config_dt():
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fplatform.c-23n363=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=fJQj7RiT2sksJYOAZ9VSJUDnxPR7RlE6Fw_cTV0_Mqc=KhdAPUtP0twDkibE89cLYs8JjnxEvBgav5uf08WL_e8=
>>  
>>
>> You will find a function named stmmac_mtl_setup() being called:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fplatform.c-23n492=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=fJQj7RiT2sksJYOAZ9VSJUDnxPR7RlE6Fw_cTV0_Mqc=rTxn0fwdudwq9XAquH60xNHN538KBQ6_n4wODdLoyA0=
>>  
>>
>> In this function, the number of RX and TX queues is being set to 1 by 
>> default.
> 
> Ah-ha, now I know how it's happened.
> You forget to update all setup() hooks in PCI bus driver :-)
> 
> I will prepare a fix.
> Just tell me should I put Fixes tag or not? And if yes, what commit
> should I refer to?
> 

Great, you can use this commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c?id=26d6851fd24ed5d88580d66b4c8384947d5ca29b

Thanks!

Joao

Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues

[Joao Pinto]

Às 12:56 PM de 5/8/2017, Andy Shevchenko escreveu:
> On Mon, May 8, 2017 at 2:40 PM, Joao Pinto  wrote:
>> Às 12:34 PM de 5/8/2017, Andy Shevchenko escreveu:
>>> On Mon, May 8, 2017 at 1:42 PM, Joao Pinto  wrote:
>>>> Às 11:12 AM de 5/8/2017, Andy Shevchenko escreveu:
>>>>> On Mon, May 8, 2017 at 12:54 PM, Joao Pinto  
>>>>> wrote:
>>>>>> Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
> 
>>>
>>> [   44.374161] stmmac_dvr_probe <<< 0 0
>>>
>>
>> Ok, so this is the cause of the problem. The driver is geting 0 for real RX 
>> and
>> TX queues.
>>
>> Your setup uses standard DT parsing from stmmac_platform or a custom one?
>>
>> If you are using stmmac_probe_config_dt():
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fplatform.c-23n363=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=fJQj7RiT2sksJYOAZ9VSJUDnxPR7RlE6Fw_cTV0_Mqc=KhdAPUtP0twDkibE89cLYs8JjnxEvBgav5uf08WL_e8=
>>  
>>
>> You will find a function named stmmac_mtl_setup() being called:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fplatform.c-23n492=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=fJQj7RiT2sksJYOAZ9VSJUDnxPR7RlE6Fw_cTV0_Mqc=rTxn0fwdudwq9XAquH60xNHN538KBQ6_n4wODdLoyA0=
>>  
>>
>> In this function, the number of RX and TX queues is being set to 1 by 
>> default.
> 
> Ah-ha, now I know how it's happened.
> You forget to update all setup() hooks in PCI bus driver :-)
> 
> I will prepare a fix.
> Just tell me should I put Fixes tag or not? And if yes, what commit
> should I refer to?
> 

Great, you can use this commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c?id=26d6851fd24ed5d88580d66b4c8384947d5ca29b

Thanks!

Joao

Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues

[Joao Pinto]

Às 12:34 PM de 5/8/2017, Andy Shevchenko escreveu:
> On Mon, May 8, 2017 at 1:42 PM, Joao Pinto <joao.pi...@synopsys.com> wrote:
>> Às 11:12 AM de 5/8/2017, Andy Shevchenko escreveu:
>>> On Mon, May 8, 2017 at 12:54 PM, Joao Pinto <joao.pi...@synopsys.com> wrote:
>>>> Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
> 
>>>>> JFYI: With today's linux-next when _kexec:ed_ kernel boots I tried and
>>>>> got the following:
> 
>>>> Are you using the same version of Ethernet IP, 10/100?
>>>
>>> I'm running on Intel Galileo Gen2 board (v4.11 by the way works fine
>>> with direct boot from SD card)
>>>
>>>> Could you please verify if the crash you are experiencing is this place?
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2956=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0=yZu3uME5PK-3nJlxz-H-HfHh3Shjzg0je5If_jSXVb4=
>>>>
>>>> I would say that for rather old IPs, the napi is not capable of giving a 
>>>> valid
>>>> queue number. Could you please print the queue index returned by this line?
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2948=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0=p_TgHODJum23I2N4AldR4oIaOPffSDpk9agmbRMQgoM=
>>>
>>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> @@ -2953,7 +2953,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff
>>> *skb, struct net_device *dev)
>>>unsigned int enh_desc;
>>>unsigned int des;
>>>
>>> +   pr_info("%s <<< 1: priv %p, queue: %u\n", __func__, priv, queue);
>>>tx_q = >tx_queue[queue];
>>> +   pr_info("%s <<< 2: priv %p, queue: %u tx_q: %p\n", __func__,
>>> priv, queue, tx_q);
>>>
>>>
>>> [  101.591040] stmmac_xmit <<< 1: priv cdd1c4c0, queue: 7
>>> [  101.596377] stmmac_xmit <<< 2: priv cdd1c4c0, queue: 7 tx_q: cdd1caac
> 
>> I assume that the queue index is always 7 right? By return 7, the napi 
>> interface
>> 'thinks' that your setup is using 8 TX queues which I assume it is not and 
>> thats
>> the problem causing your board to malfuntion.
>>
>> Could you please check the values of the 'real' tx and rx queues count in 
>> this line?
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n4107=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=6PN46fgWi1XTHkxFzV9wkYHPkKJWvkRC1OOlEhyKdcA=cyYmWeYuPwacYmVRzJbhRm3Krz6XNyHbxq8t7ZUi8Ec=
>>  
>>
>> For default they are =1, so napi should be assuming 1RX and 1TX, and so you
>> should be getting queue index =0 in reception and transmission.
>>
>> In terms of reception, could you print the queue index that stmmac_poll is 
>> using
>> here:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n3468=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=6PN46fgWi1XTHkxFzV9wkYHPkKJWvkRC1OOlEhyKdcA=Xli0e7Key3FA7Rve_opcwc6W7nd4khVX15wwoNpFHL4=
>>  
> 
> +   pr_info("%s <<< %u\n", __func__, rx_q->queue_index);
>work_done = stmmac_rx(priv, budget, rx_q->queue_index);
>if (work_done < budget) {
>napi_complete_done(napi, work_done);
> 
>/* Configure real RX and TX queues */
>netif_set_real_num_rx_queues(ndev, priv->plat->rx_queues_to_use);
>netif_set_real_num_tx_queues(ndev, priv->plat->tx_queues_to_use);
> +   pr_info("%s <<< %hhu %hhu\n", __func__,
> priv->plat->rx_queues_to_use, priv->plat->tx_queues_to_use);
> 
> 
> [   44.374161] stmmac_dvr_probe <<< 0 0
> 

Ok, so this is the cause of the problem. The driver is geting 0 for real RX and
TX queues.

Your setup uses standard DT parsing from stmmac_platform or a custom one?

If you are using stmmac_probe_config_dt():
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c#n363

You will find a function named stmmac_mtl_setup() being called:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c#n492

In this function, the number of RX and TX queues is being set to 1 by default.

Joao


> [  109.014763] stmmac_xmit <<< 1: priv cdcea4c0, queue: 2
> [  109.020099] stmmac_xmit <<< 2: priv cdcea4c0, queue: 2 tx_q: cdcea9e4
> 
> That's all, no poll activated.
> 

Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues

[Joao Pinto]

Às 12:34 PM de 5/8/2017, Andy Shevchenko escreveu:
> On Mon, May 8, 2017 at 1:42 PM, Joao Pinto  wrote:
>> Às 11:12 AM de 5/8/2017, Andy Shevchenko escreveu:
>>> On Mon, May 8, 2017 at 12:54 PM, Joao Pinto  wrote:
>>>> Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
> 
>>>>> JFYI: With today's linux-next when _kexec:ed_ kernel boots I tried and
>>>>> got the following:
> 
>>>> Are you using the same version of Ethernet IP, 10/100?
>>>
>>> I'm running on Intel Galileo Gen2 board (v4.11 by the way works fine
>>> with direct boot from SD card)
>>>
>>>> Could you please verify if the crash you are experiencing is this place?
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2956=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0=yZu3uME5PK-3nJlxz-H-HfHh3Shjzg0je5If_jSXVb4=
>>>>
>>>> I would say that for rather old IPs, the napi is not capable of giving a 
>>>> valid
>>>> queue number. Could you please print the queue index returned by this line?
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2948=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0=p_TgHODJum23I2N4AldR4oIaOPffSDpk9agmbRMQgoM=
>>>
>>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> @@ -2953,7 +2953,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff
>>> *skb, struct net_device *dev)
>>>unsigned int enh_desc;
>>>unsigned int des;
>>>
>>> +   pr_info("%s <<< 1: priv %p, queue: %u\n", __func__, priv, queue);
>>>tx_q = >tx_queue[queue];
>>> +   pr_info("%s <<< 2: priv %p, queue: %u tx_q: %p\n", __func__,
>>> priv, queue, tx_q);
>>>
>>>
>>> [  101.591040] stmmac_xmit <<< 1: priv cdd1c4c0, queue: 7
>>> [  101.596377] stmmac_xmit <<< 2: priv cdd1c4c0, queue: 7 tx_q: cdd1caac
> 
>> I assume that the queue index is always 7 right? By return 7, the napi 
>> interface
>> 'thinks' that your setup is using 8 TX queues which I assume it is not and 
>> thats
>> the problem causing your board to malfuntion.
>>
>> Could you please check the values of the 'real' tx and rx queues count in 
>> this line?
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n4107=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=6PN46fgWi1XTHkxFzV9wkYHPkKJWvkRC1OOlEhyKdcA=cyYmWeYuPwacYmVRzJbhRm3Krz6XNyHbxq8t7ZUi8Ec=
>>  
>>
>> For default they are =1, so napi should be assuming 1RX and 1TX, and so you
>> should be getting queue index =0 in reception and transmission.
>>
>> In terms of reception, could you print the queue index that stmmac_poll is 
>> using
>> here:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n3468=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=6PN46fgWi1XTHkxFzV9wkYHPkKJWvkRC1OOlEhyKdcA=Xli0e7Key3FA7Rve_opcwc6W7nd4khVX15wwoNpFHL4=
>>  
> 
> +   pr_info("%s <<< %u\n", __func__, rx_q->queue_index);
>work_done = stmmac_rx(priv, budget, rx_q->queue_index);
>if (work_done < budget) {
>napi_complete_done(napi, work_done);
> 
>/* Configure real RX and TX queues */
>netif_set_real_num_rx_queues(ndev, priv->plat->rx_queues_to_use);
>netif_set_real_num_tx_queues(ndev, priv->plat->tx_queues_to_use);
> +   pr_info("%s <<< %hhu %hhu\n", __func__,
> priv->plat->rx_queues_to_use, priv->plat->tx_queues_to_use);
> 
> 
> [   44.374161] stmmac_dvr_probe <<< 0 0
> 

Ok, so this is the cause of the problem. The driver is geting 0 for real RX and
TX queues.

Your setup uses standard DT parsing from stmmac_platform or a custom one?

If you are using stmmac_probe_config_dt():
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c#n363

You will find a function named stmmac_mtl_setup() being called:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c#n492

In this function, the number of RX and TX queues is being set to 1 by default.

Joao


> [  109.014763] stmmac_xmit <<< 1: priv cdcea4c0, queue: 2
> [  109.020099] stmmac_xmit <<< 2: priv cdcea4c0, queue: 2 tx_q: cdcea9e4
> 
> That's all, no poll activated.
> 

Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues

[Joao Pinto]

Às 11:12 AM de 5/8/2017, Andy Shevchenko escreveu:
> On Mon, May 8, 2017 at 12:54 PM, Joao Pinto <joao.pi...@synopsys.com> wrote:
>> Hi Andy and Jan,
>>
>> Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
>>> On Mon, May 8, 2017 at 9:56 AM, Jan Kiszka <jan.kis...@siemens.com> wrote:
>>>> On 2017-03-15 12:04, Joao Pinto wrote:
>>>>> This patch prepares DMA Operation Mode configuration for multiple queues.
>>>>> The work consisted on breaking the DMA operation Mode configuration 
>>>>> function
>>>>> into RX and TX scope and adapting its mechanism in stmmac_main.
>>>
>>>> Starting with this patch, the stmmac-based network adapters of the Intel
>>>> Quark SoC stop working. I'm getting an IP via DHCP, I can ping, but TCP
>>>> connections can no longer be established.
> 
>>> JFYI: With today's linux-next when _kexec:ed_ kernel boots I tried and
>>> got the following:
>>>

snip (...)

>>>
>>>
>>
>> Are you using the same version of Ethernet IP, 10/100?
> 
> I'm running on Intel Galileo Gen2 board (v4.11 by the way works fine
> with direct boot from SD card)
> 
>> Could you please verify if the crash you are experiencing is this place?
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2956=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0=yZu3uME5PK-3nJlxz-H-HfHh3Shjzg0je5If_jSXVb4=
>>  
>>
>> I would say that for rather old IPs, the napi is not capable of giving a 
>> valid
>> queue number. Could you please print the queue index returned by this line?
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2948=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0=p_TgHODJum23I2N4AldR4oIaOPffSDpk9agmbRMQgoM=
>>  
> 
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2953,7 +2953,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff
> *skb, struct net_device *dev)
>unsigned int enh_desc;
>unsigned int des;
> 
> +   pr_info("%s <<< 1: priv %p, queue: %u\n", __func__, priv, queue);
>tx_q = >tx_queue[queue];
> +   pr_info("%s <<< 2: priv %p, queue: %u tx_q: %p\n", __func__,
> priv, queue, tx_q);
> 
> 
> [  101.591040] stmmac_xmit <<< 1: priv cdd1c4c0, queue: 7
> [  101.596377] stmmac_xmit <<< 2: priv cdd1c4c0, queue: 7 tx_q: cdd1caac
> 

I assume that the queue index is always 7 right? By return 7, the napi interface
'thinks' that your setup is using 8 TX queues which I assume it is not and thats
the problem causing your board to malfuntion.

Could you please check the values of the 'real' tx and rx queues count in this 
line?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#n4107

For default they are =1, so napi should be assuming 1RX and 1TX, and so you
should be getting queue index =0 in reception and transmission.

In terms of reception, could you print the queue index that stmmac_poll is using
here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#n3468

> 
> Also noticed warning that have to be addressed:
> 
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2504:49: warning:
> incorrect type in argument 1 (different address spaces)
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2504:49:expected
> void [noderef] *ioaddr
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2504:49:got
> struct mac_device_info *hw

This one was well caught! Although it has no influence in your setup, since you
don't have this callback implemented, eQOS (>= 4.00) and 1000 cores will have
issues if using PCS. I can make a patch for this one.

> 
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function
> ‘init_dma_rx_desc_rings’:
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1274:15: warning:
> comparison of
> unsigned expression >= 0 is always true [-Wtype-limits]
>  while (queue >= 0) {
>   ^~

This one I have in my agenda to improve it, I also talked about it with Dan
Carpenter about it.

Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues

[Joao Pinto]

Às 11:12 AM de 5/8/2017, Andy Shevchenko escreveu:
> On Mon, May 8, 2017 at 12:54 PM, Joao Pinto  wrote:
>> Hi Andy and Jan,
>>
>> Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
>>> On Mon, May 8, 2017 at 9:56 AM, Jan Kiszka  wrote:
>>>> On 2017-03-15 12:04, Joao Pinto wrote:
>>>>> This patch prepares DMA Operation Mode configuration for multiple queues.
>>>>> The work consisted on breaking the DMA operation Mode configuration 
>>>>> function
>>>>> into RX and TX scope and adapting its mechanism in stmmac_main.
>>>
>>>> Starting with this patch, the stmmac-based network adapters of the Intel
>>>> Quark SoC stop working. I'm getting an IP via DHCP, I can ping, but TCP
>>>> connections can no longer be established.
> 
>>> JFYI: With today's linux-next when _kexec:ed_ kernel boots I tried and
>>> got the following:
>>>

snip (...)

>>>
>>>
>>
>> Are you using the same version of Ethernet IP, 10/100?
> 
> I'm running on Intel Galileo Gen2 board (v4.11 by the way works fine
> with direct boot from SD card)
> 
>> Could you please verify if the crash you are experiencing is this place?
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2956=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0=yZu3uME5PK-3nJlxz-H-HfHh3Shjzg0je5If_jSXVb4=
>>  
>>
>> I would say that for rather old IPs, the napi is not capable of giving a 
>> valid
>> queue number. Could you please print the queue index returned by this line?
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2948=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0=p_TgHODJum23I2N4AldR4oIaOPffSDpk9agmbRMQgoM=
>>  
> 
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2953,7 +2953,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff
> *skb, struct net_device *dev)
>unsigned int enh_desc;
>unsigned int des;
> 
> +   pr_info("%s <<< 1: priv %p, queue: %u\n", __func__, priv, queue);
>tx_q = >tx_queue[queue];
> +   pr_info("%s <<< 2: priv %p, queue: %u tx_q: %p\n", __func__,
> priv, queue, tx_q);
> 
> 
> [  101.591040] stmmac_xmit <<< 1: priv cdd1c4c0, queue: 7
> [  101.596377] stmmac_xmit <<< 2: priv cdd1c4c0, queue: 7 tx_q: cdd1caac
> 

I assume that the queue index is always 7 right? By return 7, the napi interface
'thinks' that your setup is using 8 TX queues which I assume it is not and thats
the problem causing your board to malfuntion.

Could you please check the values of the 'real' tx and rx queues count in this 
line?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#n4107

For default they are =1, so napi should be assuming 1RX and 1TX, and so you
should be getting queue index =0 in reception and transmission.

In terms of reception, could you print the queue index that stmmac_poll is using
here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#n3468

> 
> Also noticed warning that have to be addressed:
> 
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2504:49: warning:
> incorrect type in argument 1 (different address spaces)
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2504:49:expected
> void [noderef] *ioaddr
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2504:49:got
> struct mac_device_info *hw

This one was well caught! Although it has no influence in your setup, since you
don't have this callback implemented, eQOS (>= 4.00) and 1000 cores will have
issues if using PCS. I can make a patch for this one.

> 
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function
> ‘init_dma_rx_desc_rings’:
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1274:15: warning:
> comparison of
> unsigned expression >= 0 is always true [-Wtype-limits]
>  while (queue >= 0) {
>   ^~

This one I have in my agenda to improve it, I also talked about it with Dan
Carpenter about it.

Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues

[Joao Pinto]

Hi Andy and Jan,

Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
> On Mon, May 8, 2017 at 9:56 AM, Jan Kiszka <jan.kis...@siemens.com> wrote:
>> On 2017-03-15 12:04, Joao Pinto wrote:
>>> This patch prepares DMA Operation Mode configuration for multiple queues.
>>> The work consisted on breaking the DMA operation Mode configuration function
>>> into RX and TX scope and adapting its mechanism in stmmac_main.
> 
>> Starting with this patch, the stmmac-based network adapters of the Intel
>> Quark SoC stop working. I'm getting an IP via DHCP, I can ping, but TCP
>> connections can no longer be established.
>>
>> Moving on a few patches (didn't bisect the exact one yet), the TX
>> watchdog starts to fire, and DHCP fails completely. And if I go to
>> current master in Linus tree (reverting an unrelated boot regression), I
>> even get a crash in stmmac_xmit.
>>
>> Here are some details about the hw from dma_cap POV, if this helps:
>>
>> ==
>> DMA HW features
>> ==
>> 10/100 Mbps: Y
>> 1000 Mbps: N
>> Half duplex: Y
>> Hash Filter: Y
>> Multiple MAC address registers: N
>> PCS (TBI/SGMII/RTBI PHY interfaces): N
>> SMA (MDIO) Interface: Y
>> PMT Remote wake up: N
>> PMT Magic Frame: N
>> RMON module: Y
>> IEEE 1588-2002 Time Stamp: N
>> IEEE 1588-2008 Advanced Time Stamp: Y
>> 802.3az - Energy-Efficient Ethernet (EEE): N
>> AV features: N
>> Checksum Offload in TX: Y
>> IP Checksum Offload (type1) in RX: N
>> IP Checksum Offload (type2) in RX: Y
>> RXFIFO > 2048bytes: Y
>> Number of Additional RX channel: 0
>> Number of Additional TX channel: 0
>> Enhanced descriptors: Y
>>
>> Given the number of different failure modes, my feeling is that there
>> are multiple regressions coming with these patches...
>>
>> I've tested on the IOT2000 board, but I suspect the Galileo Gen2 will be
>> affected equally. If you don't have access to any such device, let me
>> know what I can debug for you.
> 
> JFYI: With today's linux-next when _kexec:ed_ kernel boots I tried and
> got the following:
> 
> 
> # ip a s
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
>link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>inet 127.0.0.1/8 scope host lo
>   valid_lft forever preferred_lft forever
>inet6 ::1/128 scope host
>   valid_lft forever preferre[  130.403995] random: fast init done
> d_lft forever
> 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
>link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
>link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> 4: sit0@NONE:  mtu 1480 qdisc noop qlen 1000
>link/sit 0.0.0.0 brd 0.0.0.0
> # udhcpc -i eth0
> udhcpc: started, v1.26.2
> [  140.825131] stmmaceth :00:14.6 eth0: device MAC address 
> 98:4f:ee:05:ac:47
> [  140.834304] Generic PHY stmmac-a6:01: attached PHY driver [Generic
> PHY] (mii_bus:phy_addr=stmmac-a6:01, irq=-1)
> [  140.930871] stmmaceth :00:14.6 eth0: IEEE 1588-2008 Advanced
> Timestamp supported
> [  140.941109] stmmaceth :00:14.6 eth0: registered PTP clock
> [  140.953626] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> udhcpc: sending discover
> [  142.979557] stmmaceth :00:14.6 eth0: Link is Up - 100Mbps/Full
> - flow control off
> [  142.988756] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [  142.998810] BUG: unable to handle kernel NULL pointer dereference at   
> (null)
> [  143.006193] IP: stmmac_xmit+0xf1/0x1080
> [  143.010168] *pde = 
> [  143.010177]
> [  143.014762] Oops: 0002 [#1]
> [  143.017672] Modules linked in: at24 nvmem_core pwm_pca9685
> [  143.023338] CPU: 0 PID: 0 Comm: swapper Not tainted 4.11.0-next-20170508+ 
> #2
> [  143.030539] task: c8533580 task.stack: c852c000
> [  143.035237] EIP: stmmac_xmit+0xf1/0x1080
> [  143.039302] EFLAGS: 00010216 CPU: 0
> [  143.042915] EAX:  EBX: 0050 ECX:  EDX: ceb6a0c0
> [  143.049326] ESI:  EDI: cdd16000 EBP: cdc25d70 ESP: cdc25d20
> [  143.055735]  DS: 007b ES: 007b FS:  GS:  SS: 0068
> [  143.061271] CR0: 80050033 CR2:  CR3: 0eb5c000 CR4: 00100010
> [  143.067671] Call Trace:
> [  143.070238]  
> [  143.072763]  dev_hard_start_xmit+0x7c/0x1a0
> [  143.077120]  sch_direct_xmit+0xf0/0x120
> 

Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues

[Joao Pinto]

Hi Andy and Jan,

Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
> On Mon, May 8, 2017 at 9:56 AM, Jan Kiszka  wrote:
>> On 2017-03-15 12:04, Joao Pinto wrote:
>>> This patch prepares DMA Operation Mode configuration for multiple queues.
>>> The work consisted on breaking the DMA operation Mode configuration function
>>> into RX and TX scope and adapting its mechanism in stmmac_main.
> 
>> Starting with this patch, the stmmac-based network adapters of the Intel
>> Quark SoC stop working. I'm getting an IP via DHCP, I can ping, but TCP
>> connections can no longer be established.
>>
>> Moving on a few patches (didn't bisect the exact one yet), the TX
>> watchdog starts to fire, and DHCP fails completely. And if I go to
>> current master in Linus tree (reverting an unrelated boot regression), I
>> even get a crash in stmmac_xmit.
>>
>> Here are some details about the hw from dma_cap POV, if this helps:
>>
>> ==
>> DMA HW features
>> ==
>> 10/100 Mbps: Y
>> 1000 Mbps: N
>> Half duplex: Y
>> Hash Filter: Y
>> Multiple MAC address registers: N
>> PCS (TBI/SGMII/RTBI PHY interfaces): N
>> SMA (MDIO) Interface: Y
>> PMT Remote wake up: N
>> PMT Magic Frame: N
>> RMON module: Y
>> IEEE 1588-2002 Time Stamp: N
>> IEEE 1588-2008 Advanced Time Stamp: Y
>> 802.3az - Energy-Efficient Ethernet (EEE): N
>> AV features: N
>> Checksum Offload in TX: Y
>> IP Checksum Offload (type1) in RX: N
>> IP Checksum Offload (type2) in RX: Y
>> RXFIFO > 2048bytes: Y
>> Number of Additional RX channel: 0
>> Number of Additional TX channel: 0
>> Enhanced descriptors: Y
>>
>> Given the number of different failure modes, my feeling is that there
>> are multiple regressions coming with these patches...
>>
>> I've tested on the IOT2000 board, but I suspect the Galileo Gen2 will be
>> affected equally. If you don't have access to any such device, let me
>> know what I can debug for you.
> 
> JFYI: With today's linux-next when _kexec:ed_ kernel boots I tried and
> got the following:
> 
> 
> # ip a s
> 1: lo:  mtu 65536 qdisc noqueue qlen 1000
>link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>inet 127.0.0.1/8 scope host lo
>   valid_lft forever preferred_lft forever
>inet6 ::1/128 scope host
>   valid_lft forever preferre[  130.403995] random: fast init done
> d_lft forever
> 2: eth0:  mtu 1500 qdisc noop qlen 1000
>link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> 3: eth1:  mtu 1500 qdisc noop qlen 1000
>link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> 4: sit0@NONE:  mtu 1480 qdisc noop qlen 1000
>link/sit 0.0.0.0 brd 0.0.0.0
> # udhcpc -i eth0
> udhcpc: started, v1.26.2
> [  140.825131] stmmaceth :00:14.6 eth0: device MAC address 
> 98:4f:ee:05:ac:47
> [  140.834304] Generic PHY stmmac-a6:01: attached PHY driver [Generic
> PHY] (mii_bus:phy_addr=stmmac-a6:01, irq=-1)
> [  140.930871] stmmaceth :00:14.6 eth0: IEEE 1588-2008 Advanced
> Timestamp supported
> [  140.941109] stmmaceth :00:14.6 eth0: registered PTP clock
> [  140.953626] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> udhcpc: sending discover
> [  142.979557] stmmaceth :00:14.6 eth0: Link is Up - 100Mbps/Full
> - flow control off
> [  142.988756] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [  142.998810] BUG: unable to handle kernel NULL pointer dereference at   
> (null)
> [  143.006193] IP: stmmac_xmit+0xf1/0x1080
> [  143.010168] *pde = 
> [  143.010177]
> [  143.014762] Oops: 0002 [#1]
> [  143.017672] Modules linked in: at24 nvmem_core pwm_pca9685
> [  143.023338] CPU: 0 PID: 0 Comm: swapper Not tainted 4.11.0-next-20170508+ 
> #2
> [  143.030539] task: c8533580 task.stack: c852c000
> [  143.035237] EIP: stmmac_xmit+0xf1/0x1080
> [  143.039302] EFLAGS: 00010216 CPU: 0
> [  143.042915] EAX:  EBX: 0050 ECX:  EDX: ceb6a0c0
> [  143.049326] ESI:  EDI: cdd16000 EBP: cdc25d70 ESP: cdc25d20
> [  143.055735]  DS: 007b ES: 007b FS:  GS:  SS: 0068
> [  143.061271] CR0: 80050033 CR2:  CR3: 0eb5c000 CR4: 00100010
> [  143.067671] Call Trace:
> [  143.070238]  
> [  143.072763]  dev_hard_start_xmit+0x7c/0x1a0
> [  143.077120]  sch_direct_xmit+0xf0/0x120
> [  143.081130]  __dev_queue_xmit+0x181/0x430
> [  143.085311]  ? eth_commit_mac_addr_change+0x20/0x20
> [  143.09

Re: [PATCH net-next v3] bindings: net: stmmac: add missing note about LPI interrupt

[Joao Pinto]

Hi Niklas,

Às 1:39 PM de 4/18/2017, Niklas Cassel escreveu:
> From: Niklas Cassel <niklas.cas...@axis.com>
> 
> The hardware has a LPI interrupt.
> There is already code in the stmmac driver to parse and handle the
> interrupt. However, this information was missing from the DT binding.
> 
> At the same time, improve the description of the existing interrupts.
> 
> Signed-off-by: Niklas Cassel <niklas.cas...@axis.com>
> ---
>  Documentation/devicetree/bindings/net/stmmac.txt | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
> b/Documentation/devicetree/bindings/net/stmmac.txt
> index f652b0c384ce..c3a7be6615c5 100644
> --- a/Documentation/devicetree/bindings/net/stmmac.txt
> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
> @@ -7,9 +7,12 @@ Required properties:
>  - interrupt-parent: Should be the phandle for the interrupt controller
>that services interrupts for this device
>  - interrupts: Should contain the STMMAC interrupts
> -- interrupt-names: Should contain the interrupt names "macirq"
> -  "eth_wake_irq" if this interrupt is supported in the "interrupts"
> -  property
> +- interrupt-names: Should contain a list of interrupt names corresponding to
> + the interrupts in the interrupts property, if available.
> + Valid interrupt names are:
> +  - "macirq" (combined signal for various interrupt events)
> +  - "eth_wake_irq" (the interrupt to manage the remote wake-up packet 
> detection)
> +  - "eth_lpi" (the interrupt that occurs when Tx or Rx enters/exits LPI 
> state)
>  - phy-mode: See ethernet.txt file in the same directory.
>  - snps,reset-gpiogpio number for phy reset.
>  - snps,reset-active-low boolean flag to indicate if phy reset is active low.
> @@ -152,8 +155,8 @@ Examples:
>   compatible = "st,spear600-gmac";
>   reg = <0xe080 0x8000>;
>   interrupt-parent = <>;
> - interrupts = <24 23>;
> - interrupt-names = "macirq", "eth_wake_irq";
> + interrupts = <24 23 22>;
> + interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
>   mac-address = []; /* Filled in by U-Boot */
>   max-frame-size = <3800>;
>   phy-mode = "gmii";
> 

Acked-By: Joao Pinto <jpi...@synopsys.com>

Regards!

Re: [PATCH net-next v3] bindings: net: stmmac: add missing note about LPI interrupt

[Joao Pinto]

Hi Niklas,

Às 1:39 PM de 4/18/2017, Niklas Cassel escreveu:
> From: Niklas Cassel 
> 
> The hardware has a LPI interrupt.
> There is already code in the stmmac driver to parse and handle the
> interrupt. However, this information was missing from the DT binding.
> 
> At the same time, improve the description of the existing interrupts.
> 
> Signed-off-by: Niklas Cassel 
> ---
>  Documentation/devicetree/bindings/net/stmmac.txt | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
> b/Documentation/devicetree/bindings/net/stmmac.txt
> index f652b0c384ce..c3a7be6615c5 100644
> --- a/Documentation/devicetree/bindings/net/stmmac.txt
> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
> @@ -7,9 +7,12 @@ Required properties:
>  - interrupt-parent: Should be the phandle for the interrupt controller
>that services interrupts for this device
>  - interrupts: Should contain the STMMAC interrupts
> -- interrupt-names: Should contain the interrupt names "macirq"
> -  "eth_wake_irq" if this interrupt is supported in the "interrupts"
> -  property
> +- interrupt-names: Should contain a list of interrupt names corresponding to
> + the interrupts in the interrupts property, if available.
> + Valid interrupt names are:
> +  - "macirq" (combined signal for various interrupt events)
> +  - "eth_wake_irq" (the interrupt to manage the remote wake-up packet 
> detection)
> +  - "eth_lpi" (the interrupt that occurs when Tx or Rx enters/exits LPI 
> state)
>  - phy-mode: See ethernet.txt file in the same directory.
>  - snps,reset-gpiogpio number for phy reset.
>  - snps,reset-active-low boolean flag to indicate if phy reset is active low.
> @@ -152,8 +155,8 @@ Examples:
>   compatible = "st,spear600-gmac";
>   reg = <0xe080 0x8000>;
>   interrupt-parent = <>;
> - interrupts = <24 23>;
> - interrupt-names = "macirq", "eth_wake_irq";
> + interrupts = <24 23 22>;
> + interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
>   mac-address = []; /* Filled in by U-Boot */
>   max-frame-size = <3800>;
>   phy-mode = "gmii";
> 

Acked-By: Joao Pinto 

Regards!

Re: [PATCH net-next] net: stmmac: set total length of the packet to be transmitted in TDES3

[Joao Pinto]

Hi Niklas,

Às 7:33 PM de 4/10/2017, Niklas Cassel escreveu:
> From: Niklas Cassel 
> 
> Field FL/TPL in register TDES3 is not correctly set on GMAC4.
> TX appears to be functional on GMAC 4.10a even if this field is not set,
> however, to avoid relying on undefined behavior, set the length in TDES3.
> 
> The field has a different meaning depending on if the TSE bit in TDES3
> is set or not (TSO). However, regardless of the TSE bit, the field is
> not optional. The field is already set correctly when the TSE bit is set.
> 
> Since there is no limit for the number of descriptors that can be
> used for a single packet, the field should be set to the sum of
> the buffers contained in:
> [ ...  ...
> ], which should be equal to skb->len.
> 
> Signed-off-by: Niklas Cassel 

Sounds fine to me. Did you check for performance improvement? Thanks.

Joao

Re: [PATCH net-next] net: stmmac: set total length of the packet to be transmitted in TDES3

[Joao Pinto]

Hi Niklas,

Às 7:33 PM de 4/10/2017, Niklas Cassel escreveu:
> From: Niklas Cassel 
> 
> Field FL/TPL in register TDES3 is not correctly set on GMAC4.
> TX appears to be functional on GMAC 4.10a even if this field is not set,
> however, to avoid relying on undefined behavior, set the length in TDES3.
> 
> The field has a different meaning depending on if the TSE bit in TDES3
> is set or not (TSO). However, regardless of the TSE bit, the field is
> not optional. The field is already set correctly when the TSE bit is set.
> 
> Since there is no limit for the number of descriptors that can be
> used for a single packet, the field should be set to the sum of
> the buffers contained in:
> [ ...  ...
> ], which should be equal to skb->len.
> 
> Signed-off-by: Niklas Cassel 

Sounds fine to me. Did you check for performance improvement? Thanks.

Joao

Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues

[Joao Pinto]

Hello Peppe,

Às 2:07 PM de 4/3/2017, Giuseppe CAVALLARO escreveu:
> Hello Joao
> 
> On 3/30/2017 6:42 PM, Joao Pinto wrote:
>> Às 5:35 PM de 3/30/2017, Niklas Cassel escreveu:
>>> On 03/30/2017 04:34 PM, Thierry Reding wrote:
>>>> On Thu, Mar 30, 2017 at 09:45:36AM +0200, Corentin Labbe wrote:
>>>>> On Tue, Mar 28, 2017 at 06:01:05PM -0700, David Miller wrote:
>>>>>> From: Arnd Bergmann <a...@arndb.de>
>>>>>> Date: Tue, 28 Mar 2017 11:48:21 +0200
>>>>>>
>>>>>>> A driver must not access the two fields directly but should instead use
>>>>>>> the helper functions to set the values and keep a consistent internal
>>>>>>> state:
>>>>>>>
>>>>>>> ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_dvr_probe':
>>>>>>> ethernet/stmicro/stmmac/stmmac_main.c:4083:8: error: 'struct net_device'
>>>>>>> has no member named 'real_num_rx_queues'; did you mean 
>>>>>>> 'real_num_tx_queues'?
>>>>>>>
>>>>>>> Fixes: a8f5102af2a7 ("net: stmmac: TX and RX queue priority 
>>>>>>> configuration")
>>>>>>> Signed-off-by: Arnd Bergmann <a...@arndb.de>
>>>>>> Applied.
>>>>> This break my revert patch. (since it patch ("net: stmmac: enable multiple
>>>>> buffers").
>>>>> Since dwmac-sunxi is still broken, what can I do ? send two revert patch ?
>>>>> or adapt the reverting patch.
>>>> Have you tried if the kcalloc() patch I sent on Tuesday fixes things the
>>>> issues introduced by the multiple buffers patch? Niklas reported that it
>>>> restores functionality on his setup.
>>>>
>>>> If it makes things work for you as well, we could maybe avoid the revert
>>>> altogether.
>>> Thierry, I know that you are using DWMAC CORE 4.XX
>>> How many RX queues and how many TX queues have you got?
>>>
>>> I'm also using DWMAC CORE 4.XX
>>> We have 2 TX queues and 1 RX queue.
>>>
>>> I think that Corentin is using DWMAC CORE 3.XX
>>>
>>> I know that Joao is using an IP Prototyping Kit that uses
>>> DWMAC CORE 4.XX (connected via PCIe).
>>> It would be nice if Joao could get an IP Prototyping Kit
>>> based on DWMAC CORE 3.XX.
>>>
>>> Doesn't Synopsys have an IP Prototyping Kit based on
>>> DWMAC CORE 3.XX laying around somewhere? :)
>>>
>> I requested a prototyping platform with MAC 100 or a MAC 1000 in order to 
>> make
>> more tests, but I don't have an ETA for it yet.
>>
>> The implication of the multiple buffers patch in 3.xx is some flow change in 
>> the
>> configuration of dma op mode or similar. I would recomend Corentin to dump 
>> the
>> dma & mac registers in the end of the _open function in order to see if the 
>> DMA
>> is really being well configured and is really started.
> 
> Old devices managed as stmmac: mac10/100 platform driver have no multi-queue
> support.
> 
> It was introduced in the new versions managed by mac1000 but in my opinion
> the stmmac driver has to only work with a single queue for tx and rx on ALL
> the 3.x versions.
> 
> In fact, although the latest series have the multi-queue and channels there is
> just one IRQ and this is a very poor implementation.
> The 3.xx is very different from what we have in the 4.XX (QoS) on this part 
> and
> AV/B.
> 
> Nobody has ever asked for having this support in all these years for the 
> previous
> chips.
> 
> Adding this kind of support we'll spend time for having a no useful 
> optimization
> and risking to break the compatibility with a lot platforms that use these 
> chips.
> 
> I image, multi-queue stable on 4.XX and no support on all older versions.
> Let me know if you share that.

Yes older cores do not support multiple queues and I tried to isolate the
features not to affect older versions.

Do you think that functions as "ndev = alloc_etherdev_mqs" has some sort of
influence?

Thanks.

> 
> Regards
> Peppe
> 
>>
>> Thanks.
>>
>> Joao
>>
>>
> 

Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues

[Joao Pinto]

Hello Peppe,

Às 2:07 PM de 4/3/2017, Giuseppe CAVALLARO escreveu:
> Hello Joao
> 
> On 3/30/2017 6:42 PM, Joao Pinto wrote:
>> Às 5:35 PM de 3/30/2017, Niklas Cassel escreveu:
>>> On 03/30/2017 04:34 PM, Thierry Reding wrote:
>>>> On Thu, Mar 30, 2017 at 09:45:36AM +0200, Corentin Labbe wrote:
>>>>> On Tue, Mar 28, 2017 at 06:01:05PM -0700, David Miller wrote:
>>>>>> From: Arnd Bergmann 
>>>>>> Date: Tue, 28 Mar 2017 11:48:21 +0200
>>>>>>
>>>>>>> A driver must not access the two fields directly but should instead use
>>>>>>> the helper functions to set the values and keep a consistent internal
>>>>>>> state:
>>>>>>>
>>>>>>> ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_dvr_probe':
>>>>>>> ethernet/stmicro/stmmac/stmmac_main.c:4083:8: error: 'struct net_device'
>>>>>>> has no member named 'real_num_rx_queues'; did you mean 
>>>>>>> 'real_num_tx_queues'?
>>>>>>>
>>>>>>> Fixes: a8f5102af2a7 ("net: stmmac: TX and RX queue priority 
>>>>>>> configuration")
>>>>>>> Signed-off-by: Arnd Bergmann 
>>>>>> Applied.
>>>>> This break my revert patch. (since it patch ("net: stmmac: enable multiple
>>>>> buffers").
>>>>> Since dwmac-sunxi is still broken, what can I do ? send two revert patch ?
>>>>> or adapt the reverting patch.
>>>> Have you tried if the kcalloc() patch I sent on Tuesday fixes things the
>>>> issues introduced by the multiple buffers patch? Niklas reported that it
>>>> restores functionality on his setup.
>>>>
>>>> If it makes things work for you as well, we could maybe avoid the revert
>>>> altogether.
>>> Thierry, I know that you are using DWMAC CORE 4.XX
>>> How many RX queues and how many TX queues have you got?
>>>
>>> I'm also using DWMAC CORE 4.XX
>>> We have 2 TX queues and 1 RX queue.
>>>
>>> I think that Corentin is using DWMAC CORE 3.XX
>>>
>>> I know that Joao is using an IP Prototyping Kit that uses
>>> DWMAC CORE 4.XX (connected via PCIe).
>>> It would be nice if Joao could get an IP Prototyping Kit
>>> based on DWMAC CORE 3.XX.
>>>
>>> Doesn't Synopsys have an IP Prototyping Kit based on
>>> DWMAC CORE 3.XX laying around somewhere? :)
>>>
>> I requested a prototyping platform with MAC 100 or a MAC 1000 in order to 
>> make
>> more tests, but I don't have an ETA for it yet.
>>
>> The implication of the multiple buffers patch in 3.xx is some flow change in 
>> the
>> configuration of dma op mode or similar. I would recomend Corentin to dump 
>> the
>> dma & mac registers in the end of the _open function in order to see if the 
>> DMA
>> is really being well configured and is really started.
> 
> Old devices managed as stmmac: mac10/100 platform driver have no multi-queue
> support.
> 
> It was introduced in the new versions managed by mac1000 but in my opinion
> the stmmac driver has to only work with a single queue for tx and rx on ALL
> the 3.x versions.
> 
> In fact, although the latest series have the multi-queue and channels there is
> just one IRQ and this is a very poor implementation.
> The 3.xx is very different from what we have in the 4.XX (QoS) on this part 
> and
> AV/B.
> 
> Nobody has ever asked for having this support in all these years for the 
> previous
> chips.
> 
> Adding this kind of support we'll spend time for having a no useful 
> optimization
> and risking to break the compatibility with a lot platforms that use these 
> chips.
> 
> I image, multi-queue stable on 4.XX and no support on all older versions.
> Let me know if you share that.

Yes older cores do not support multiple queues and I tried to isolate the
features not to affect older versions.

Do you think that functions as "ndev = alloc_etherdev_mqs" has some sort of
influence?

Thanks.

> 
> Regards
> Peppe
> 
>>
>> Thanks.
>>
>> Joao
>>
>>
> 

Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues

[Joao Pinto]

Às 5:57 PM de 3/31/2017, David Miller escreveu:
> From: Joao Pinto <joao.pi...@synopsys.com>
> Date: Fri, 31 Mar 2017 11:43:38 +0100
> 
>> @David: Could you please create a branch in your git tree for us to work on 
>> it
>> until the multiple buffers get stable for everyone? This way the patches 
>> could
>> circulate in the mailing-list with a different target, like stmmac-next or 
>> similar.
>>
>> What do you think?
> 
> Sorry, I'm not going to do that.
> 

Ok. I will send the patches normally through the mailing-list.

Thanks.

Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues

[Joao Pinto]

Às 5:57 PM de 3/31/2017, David Miller escreveu:
> From: Joao Pinto 
> Date: Fri, 31 Mar 2017 11:43:38 +0100
> 
>> @David: Could you please create a branch in your git tree for us to work on 
>> it
>> until the multiple buffers get stable for everyone? This way the patches 
>> could
>> circulate in the mailing-list with a different target, like stmmac-next or 
>> similar.
>>
>> What do you think?
> 
> Sorry, I'm not going to do that.
> 

Ok. I will send the patches normally through the mailing-list.

Thanks.

[PATCH] net: stmmac: fix cbs configuration

[Joao Pinto]

The QoS IP does not accept AVB capabilities to default/queue 0, this way we
guarantee 75% bandwidth for AVB. This patch assures that only queues >= 1
gets CBS confgured. Additional info was also added to stmmac.txt.

Reported-by: Niklas Cassel <niklas.cas...@axis.com>
Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
 Documentation/devicetree/bindings/net/stmmac.txt  | 2 ++
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
b/Documentation/devicetree/bindings/net/stmmac.txt
index 784d988..f652b0c 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -103,6 +103,8 @@ Optional properties:
- Choose one of these modes:
- snps,dcb-algorithm: TX queue will be working in DCB
- snps,avb-algorithm: TX queue will be working in AVB
+ [Attention] Queue 0 is reserved for legacy traffic
+ and so no AVB is available in this queue.
- Configure Credit Base Shaper (if AVB Mode selected):
- snps,send_slope: enable Low Power Interface
- snps,idle_slope: unlock on WoL
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 43361f3..c1c6319 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1880,7 +1880,8 @@ static void stmmac_configure_cbs(struct stmmac_priv *priv)
u32 mode_to_use;
u32 queue;
 
-   for (queue = 0; queue < tx_queues_count; queue++) {
+   /* queue 0 is reserved for legacy traffic */
+   for (queue = 1; queue < tx_queues_count; queue++) {
mode_to_use = priv->plat->tx_queues_cfg[queue].mode_to_use;
if (mode_to_use == MTL_QUEUE_DCB)
continue;
-- 
2.9.3

[PATCH] net: stmmac: fix cbs configuration

[Joao Pinto]

The QoS IP does not accept AVB capabilities to default/queue 0, this way we
guarantee 75% bandwidth for AVB. This patch assures that only queues >= 1
gets CBS confgured. Additional info was also added to stmmac.txt.

Reported-by: Niklas Cassel 
Signed-off-by: Joao Pinto 
---
 Documentation/devicetree/bindings/net/stmmac.txt  | 2 ++
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
b/Documentation/devicetree/bindings/net/stmmac.txt
index 784d988..f652b0c 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -103,6 +103,8 @@ Optional properties:
- Choose one of these modes:
- snps,dcb-algorithm: TX queue will be working in DCB
- snps,avb-algorithm: TX queue will be working in AVB
+ [Attention] Queue 0 is reserved for legacy traffic
+ and so no AVB is available in this queue.
- Configure Credit Base Shaper (if AVB Mode selected):
- snps,send_slope: enable Low Power Interface
- snps,idle_slope: unlock on WoL
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 43361f3..c1c6319 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1880,7 +1880,8 @@ static void stmmac_configure_cbs(struct stmmac_priv *priv)
u32 mode_to_use;
u32 queue;
 
-   for (queue = 0; queue < tx_queues_count; queue++) {
+   /* queue 0 is reserved for legacy traffic */
+   for (queue = 1; queue < tx_queues_count; queue++) {
mode_to_use = priv->plat->tx_queues_cfg[queue].mode_to_use;
if (mode_to_use == MTL_QUEUE_DCB)
continue;
-- 
2.9.3

Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues

[Joao Pinto]

Às 11:14 AM de 3/31/2017, Joao Pinto escreveu:
> Às 6:48 PM de 3/30/2017, David Miller escreveu:
>> From: Thierry Reding <tred...@nvidia.com>
>> Date: Thu, 30 Mar 2017 16:34:36 +0200
>>
>>> On Thu, Mar 30, 2017 at 09:45:36AM +0200, Corentin Labbe wrote:
>>>> On Tue, Mar 28, 2017 at 06:01:05PM -0700, David Miller wrote:
>>>>> From: Arnd Bergmann <a...@arndb.de>
>>>>> Date: Tue, 28 Mar 2017 11:48:21 +0200
>>>>>
>>>>>> A driver must not access the two fields directly but should instead use
>>>>>> the helper functions to set the values and keep a consistent internal
>>>>>> state:
>>>>>>
>>>>>> ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_dvr_probe':
>>>>>> ethernet/stmicro/stmmac/stmmac_main.c:4083:8: error: 'struct net_device' 
>>>>>> has no member named 'real_num_rx_queues'; did you mean 
>>>>>> 'real_num_tx_queues'?
>>>>>>
>>>>>> Fixes: a8f5102af2a7 ("net: stmmac: TX and RX queue priority 
>>>>>> configuration")
>>>>>> Signed-off-by: Arnd Bergmann <a...@arndb.de>
>>>>>
>>>>> Applied.
>>>>
>>>> This break my revert patch. (since it patch ("net: stmmac: enable multiple 
>>>> buffers").
>>>> Since dwmac-sunxi is still broken, what can I do ? send two revert patch ? 
>>>> or adapt the reverting patch.
>>>
>>> Have you tried if the kcalloc() patch I sent on Tuesday fixes things the
>>> issues introduced by the multiple buffers patch? Niklas reported that it
>>> restores functionality on his setup.
>>
>> I think he said yesterday that he did indeed test all of your patches and it
>> did not fix things for him.
>>
>> http://marc.info/?l=linux-kernel=149076922813085=2
>>
>> I am going to revert the enable multiple buffers commit, and I would ask that
>> all involved parties work together in the background to resolve all of this.

@David: Could you please create a branch in your git tree for us to work on it
until the multiple buffers get stable for everyone? This way the patches could
circulate in the mailing-list with a different target, like stmmac-next or 
similar.

What do you think?

Joao

>>
>> Thank you.
>>
> 
> @David: Agreed.
> 
> @Corentin: Please check if the DMA Engine is well configured and if the dma
> rx/tx has started. This is done by dumping the DMA Registers.
> Please also check the MAC related registers and dump them in order to have a
> clear picture if the IP is being well configured.
> This is critial to analise what's hapenning in your setup.
> 
> Joao
> 

Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues

[Joao Pinto]

Às 11:14 AM de 3/31/2017, Joao Pinto escreveu:
> Às 6:48 PM de 3/30/2017, David Miller escreveu:
>> From: Thierry Reding 
>> Date: Thu, 30 Mar 2017 16:34:36 +0200
>>
>>> On Thu, Mar 30, 2017 at 09:45:36AM +0200, Corentin Labbe wrote:
>>>> On Tue, Mar 28, 2017 at 06:01:05PM -0700, David Miller wrote:
>>>>> From: Arnd Bergmann 
>>>>> Date: Tue, 28 Mar 2017 11:48:21 +0200
>>>>>
>>>>>> A driver must not access the two fields directly but should instead use
>>>>>> the helper functions to set the values and keep a consistent internal
>>>>>> state:
>>>>>>
>>>>>> ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_dvr_probe':
>>>>>> ethernet/stmicro/stmmac/stmmac_main.c:4083:8: error: 'struct net_device' 
>>>>>> has no member named 'real_num_rx_queues'; did you mean 
>>>>>> 'real_num_tx_queues'?
>>>>>>
>>>>>> Fixes: a8f5102af2a7 ("net: stmmac: TX and RX queue priority 
>>>>>> configuration")
>>>>>> Signed-off-by: Arnd Bergmann 
>>>>>
>>>>> Applied.
>>>>
>>>> This break my revert patch. (since it patch ("net: stmmac: enable multiple 
>>>> buffers").
>>>> Since dwmac-sunxi is still broken, what can I do ? send two revert patch ? 
>>>> or adapt the reverting patch.
>>>
>>> Have you tried if the kcalloc() patch I sent on Tuesday fixes things the
>>> issues introduced by the multiple buffers patch? Niklas reported that it
>>> restores functionality on his setup.
>>
>> I think he said yesterday that he did indeed test all of your patches and it
>> did not fix things for him.
>>
>> http://marc.info/?l=linux-kernel=149076922813085=2
>>
>> I am going to revert the enable multiple buffers commit, and I would ask that
>> all involved parties work together in the background to resolve all of this.

@David: Could you please create a branch in your git tree for us to work on it
until the multiple buffers get stable for everyone? This way the patches could
circulate in the mailing-list with a different target, like stmmac-next or 
similar.

What do you think?

Joao

>>
>> Thank you.
>>
> 
> @David: Agreed.
> 
> @Corentin: Please check if the DMA Engine is well configured and if the dma
> rx/tx has started. This is done by dumping the DMA Registers.
> Please also check the MAC related registers and dump them in order to have a
> clear picture if the IP is being well configured.
> This is critial to analise what's hapenning in your setup.
> 
> Joao
> 

Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues

[Joao Pinto]

Às 6:48 PM de 3/30/2017, David Miller escreveu:
> From: Thierry Reding 
> Date: Thu, 30 Mar 2017 16:34:36 +0200
> 
>> On Thu, Mar 30, 2017 at 09:45:36AM +0200, Corentin Labbe wrote:
>>> On Tue, Mar 28, 2017 at 06:01:05PM -0700, David Miller wrote:
 From: Arnd Bergmann 
 Date: Tue, 28 Mar 2017 11:48:21 +0200

> A driver must not access the two fields directly but should instead use
> the helper functions to set the values and keep a consistent internal
> state:
>
> ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_dvr_probe':
> ethernet/stmicro/stmmac/stmmac_main.c:4083:8: error: 'struct net_device' 
> has no member named 'real_num_rx_queues'; did you mean 
> 'real_num_tx_queues'?
>
> Fixes: a8f5102af2a7 ("net: stmmac: TX and RX queue priority 
> configuration")
> Signed-off-by: Arnd Bergmann 

 Applied.
>>>
>>> This break my revert patch. (since it patch ("net: stmmac: enable multiple 
>>> buffers").
>>> Since dwmac-sunxi is still broken, what can I do ? send two revert patch ? 
>>> or adapt the reverting patch.
>>
>> Have you tried if the kcalloc() patch I sent on Tuesday fixes things the
>> issues introduced by the multiple buffers patch? Niklas reported that it
>> restores functionality on his setup.
> 
> I think he said yesterday that he did indeed test all of your patches and it
> did not fix things for him.
> 
> http://marc.info/?l=linux-kernel=149076922813085=2
> 
> I am going to revert the enable multiple buffers commit, and I would ask that
> all involved parties work together in the background to resolve all of this.
> 
> Thank you.
> 

@David: Agreed.

@Corentin: Please check if the DMA Engine is well configured and if the dma
rx/tx has started. This is done by dumping the DMA Registers.
Please also check the MAC related registers and dump them in order to have a
clear picture if the IP is being well configured.
This is critial to analise what's hapenning in your setup.

Joao

Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues

[Joao Pinto]

Às 6:48 PM de 3/30/2017, David Miller escreveu:
> From: Thierry Reding 
> Date: Thu, 30 Mar 2017 16:34:36 +0200
> 
>> On Thu, Mar 30, 2017 at 09:45:36AM +0200, Corentin Labbe wrote:
>>> On Tue, Mar 28, 2017 at 06:01:05PM -0700, David Miller wrote:
 From: Arnd Bergmann 
 Date: Tue, 28 Mar 2017 11:48:21 +0200

> A driver must not access the two fields directly but should instead use
> the helper functions to set the values and keep a consistent internal
> state:
>
> ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_dvr_probe':
> ethernet/stmicro/stmmac/stmmac_main.c:4083:8: error: 'struct net_device' 
> has no member named 'real_num_rx_queues'; did you mean 
> 'real_num_tx_queues'?
>
> Fixes: a8f5102af2a7 ("net: stmmac: TX and RX queue priority 
> configuration")
> Signed-off-by: Arnd Bergmann 

 Applied.
>>>
>>> This break my revert patch. (since it patch ("net: stmmac: enable multiple 
>>> buffers").
>>> Since dwmac-sunxi is still broken, what can I do ? send two revert patch ? 
>>> or adapt the reverting patch.
>>
>> Have you tried if the kcalloc() patch I sent on Tuesday fixes things the
>> issues introduced by the multiple buffers patch? Niklas reported that it
>> restores functionality on his setup.
> 
> I think he said yesterday that he did indeed test all of your patches and it
> did not fix things for him.
> 
> http://marc.info/?l=linux-kernel=149076922813085=2
> 
> I am going to revert the enable multiple buffers commit, and I would ask that
> all involved parties work together in the background to resolve all of this.
> 
> Thank you.
> 

@David: Agreed.

@Corentin: Please check if the DMA Engine is well configured and if the dma
rx/tx has started. This is done by dumping the DMA Registers.
Please also check the MAC related registers and dump them in order to have a
clear picture if the IP is being well configured.
This is critial to analise what's hapenning in your setup.

Joao

Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues

[Joao Pinto]

Às 5:35 PM de 3/30/2017, Niklas Cassel escreveu:
> On 03/30/2017 04:34 PM, Thierry Reding wrote:
>> On Thu, Mar 30, 2017 at 09:45:36AM +0200, Corentin Labbe wrote:
>>> On Tue, Mar 28, 2017 at 06:01:05PM -0700, David Miller wrote:
 From: Arnd Bergmann 
 Date: Tue, 28 Mar 2017 11:48:21 +0200

> A driver must not access the two fields directly but should instead use
> the helper functions to set the values and keep a consistent internal
> state:
>
> ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_dvr_probe':
> ethernet/stmicro/stmmac/stmmac_main.c:4083:8: error: 'struct net_device' 
> has no member named 'real_num_rx_queues'; did you mean 
> 'real_num_tx_queues'?
>
> Fixes: a8f5102af2a7 ("net: stmmac: TX and RX queue priority 
> configuration")
> Signed-off-by: Arnd Bergmann 

 Applied.
>>>
>>> This break my revert patch. (since it patch ("net: stmmac: enable multiple 
>>> buffers").
>>> Since dwmac-sunxi is still broken, what can I do ? send two revert patch ? 
>>> or adapt the reverting patch.
>>
>> Have you tried if the kcalloc() patch I sent on Tuesday fixes things the
>> issues introduced by the multiple buffers patch? Niklas reported that it
>> restores functionality on his setup.
>>
>> If it makes things work for you as well, we could maybe avoid the revert
>> altogether.
> 
> Thierry, I know that you are using DWMAC CORE 4.XX
> How many RX queues and how many TX queues have you got?
> 
> I'm also using DWMAC CORE 4.XX
> We have 2 TX queues and 1 RX queue.
> 
> I think that Corentin is using DWMAC CORE 3.XX
> 
> I know that Joao is using an IP Prototyping Kit that uses
> DWMAC CORE 4.XX (connected via PCIe).
> It would be nice if Joao could get an IP Prototyping Kit
> based on DWMAC CORE 3.XX.
> 
> Doesn't Synopsys have an IP Prototyping Kit based on
> DWMAC CORE 3.XX laying around somewhere? :)
> 

I requested a prototyping platform with MAC 100 or a MAC 1000 in order to make
more tests, but I don't have an ETA for it yet.

The implication of the multiple buffers patch in 3.xx is some flow change in the
configuration of dma op mode or similar. I would recomend Corentin to dump the
dma & mac registers in the end of the _open function in order to see if the DMA
is really being well configured and is really started.

Thanks.

Joao

Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues

[Joao Pinto]

Às 5:35 PM de 3/30/2017, Niklas Cassel escreveu:
> On 03/30/2017 04:34 PM, Thierry Reding wrote:
>> On Thu, Mar 30, 2017 at 09:45:36AM +0200, Corentin Labbe wrote:
>>> On Tue, Mar 28, 2017 at 06:01:05PM -0700, David Miller wrote:
 From: Arnd Bergmann 
 Date: Tue, 28 Mar 2017 11:48:21 +0200

> A driver must not access the two fields directly but should instead use
> the helper functions to set the values and keep a consistent internal
> state:
>
> ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_dvr_probe':
> ethernet/stmicro/stmmac/stmmac_main.c:4083:8: error: 'struct net_device' 
> has no member named 'real_num_rx_queues'; did you mean 
> 'real_num_tx_queues'?
>
> Fixes: a8f5102af2a7 ("net: stmmac: TX and RX queue priority 
> configuration")
> Signed-off-by: Arnd Bergmann 

 Applied.
>>>
>>> This break my revert patch. (since it patch ("net: stmmac: enable multiple 
>>> buffers").
>>> Since dwmac-sunxi is still broken, what can I do ? send two revert patch ? 
>>> or adapt the reverting patch.
>>
>> Have you tried if the kcalloc() patch I sent on Tuesday fixes things the
>> issues introduced by the multiple buffers patch? Niklas reported that it
>> restores functionality on his setup.
>>
>> If it makes things work for you as well, we could maybe avoid the revert
>> altogether.
> 
> Thierry, I know that you are using DWMAC CORE 4.XX
> How many RX queues and how many TX queues have you got?
> 
> I'm also using DWMAC CORE 4.XX
> We have 2 TX queues and 1 RX queue.
> 
> I think that Corentin is using DWMAC CORE 3.XX
> 
> I know that Joao is using an IP Prototyping Kit that uses
> DWMAC CORE 4.XX (connected via PCIe).
> It would be nice if Joao could get an IP Prototyping Kit
> based on DWMAC CORE 3.XX.
> 
> Doesn't Synopsys have an IP Prototyping Kit based on
> DWMAC CORE 3.XX laying around somewhere? :)
> 

I requested a prototyping platform with MAC 100 or a MAC 1000 in order to make
more tests, but I don't have an ETA for it yet.

The implication of the multiple buffers patch in 3.xx is some flow change in the
configuration of dma op mode or similar. I would recomend Corentin to dump the
dma & mac registers in the end of the _open function in order to see if the DMA
is really being well configured and is really started.

Thanks.

Joao

Re: [PATCH] PCI: dwc: fix crash seen due to missing ops

[Joao Pinto]

Às 7:19 AM de 3/23/2017, Niklas Cassel escreveu:
> On 03/22/2017 04:47 PM, Joao Pinto wrote:
>> Hi Niklas,
>>
>> Às 2:43 PM de 3/21/2017, Niklas Cassel escreveu:
>>> From: Niklas Cassel <niklas.cas...@axis.com>
>>>
>>> Fix the following crash, seen in dwc/pcie-artpec6.
>>>
>>>   Unable to handle kernel NULL pointer dereference at virtual address 
>>> 0004
>>>   pgd = c0204000
>>>   [0004] *pgd=
>>>   Internal error: Oops: 5 [#1] SMP ARM
>>>   Modules linked in:
>>>   CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc3-next-20170321 #1
>>>   Hardware name: Axis ARTPEC-6 Platform
>>>   task: db098000 task.stack: db096000
>>>   PC is at dw_pcie_writel_dbi+0x2c/0xd0
>>>   ...
>>>
>>> While at it, fix the same problem for pcie-designware-plat.
>>>
>>> Fixes: 442ec4c04d12 ("PCI: dwc: all: Split struct pcie_port into host-only 
>>> and core structures")
>>> Signed-off-by: Niklas Cassel <niklas.cas...@axis.com>
>>> ---
>>>  drivers/pci/dwc/pcie-artpec6.c | 4 
>>>  drivers/pci/dwc/pcie-designware-plat.c | 4 
>>>  2 files changed, 8 insertions(+)
>>>
>>> diff --git a/drivers/pci/dwc/pcie-artpec6.c b/drivers/pci/dwc/pcie-artpec6.c
>>> index fcd3ef845883..6d23683c0892 100644
>>> --- a/drivers/pci/dwc/pcie-artpec6.c
>>> +++ b/drivers/pci/dwc/pcie-artpec6.c
>>> @@ -234,6 +234,9 @@ static int artpec6_add_pcie_port(struct artpec6_pcie 
>>> *artpec6_pcie,
>>> return 0;
>>>  }
>>>  
>>> +static const struct dw_pcie_ops dw_pcie_ops = {
>>> +};
>>> +
>>>  static int artpec6_pcie_probe(struct platform_device *pdev)
>>>  {
>>> struct device *dev = >dev;
>>> @@ -252,6 +255,7 @@ static int artpec6_pcie_probe(struct platform_device 
>>> *pdev)
>>> return -ENOMEM;
>>>  
>>> pci->dev = dev;
>>> +   pci->ops = _pcie_ops;
>>>  
>>> artpec6_pcie->pci = pci;
>>>  
>>> diff --git a/drivers/pci/dwc/pcie-designware-plat.c 
>>> b/drivers/pci/dwc/pcie-designware-plat.c
>>> index b6c832ba39dd..f20d494922ab 100644
>>> --- a/drivers/pci/dwc/pcie-designware-plat.c
>>> +++ b/drivers/pci/dwc/pcie-designware-plat.c
>>> @@ -86,6 +86,9 @@ static int dw_plat_add_pcie_port(struct pcie_port *pp,
>>> return 0;
>>>  }
>>>  
>>> +static const struct dw_pcie_ops dw_pcie_ops = {
>>> +};
>>> +
>>>  static int dw_plat_pcie_probe(struct platform_device *pdev)
>>>  {
>>> struct device *dev = >dev;
>>> @@ -103,6 +106,7 @@ static int dw_plat_pcie_probe(struct platform_device 
>>> *pdev)
>>> return -ENOMEM;
>>>  
>>> pci->dev = dev;
>>> +   pci->ops = _pcie_ops;
>>>  
>>> dw_plat_pcie->pci = pci;
>>>  
>>>
>> In the case of pcie-designware-plat you have the declaration of pci->ops:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_helgaas_pci.git_tree_drivers_pci_dwc_pcie-2Ddesignware-2Dplat.c-23n78=DwID-g=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=28B2KMSJPmdGukxJhVcT-K6O76mP27iVn-XTqDwJ4p0=glxSZ800DErbgYPvxr-U26UBSVliExhaYEW-MIYIs7U=
>>  
>>
>> and in artpec6 in here:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_helgaas_pci.git_tree_drivers_pci_dwc_pcie-2Dartpec6.c-23n226=DwID-g=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=28B2KMSJPmdGukxJhVcT-K6O76mP27iVn-XTqDwJ4p0=_9PXmcF7fsBh4pqYI4lOl4kwCY48xSyUzg6VlCDIy9w=
>>  
>>
>> Both declarations are made previously of calling dw_pcie_host_init(), so why 
>> do
>> you need this dummy ops in the probe function? I never had that necessity.
> 
> Hello Joao
> 
> Since commit 442ec4c04d12, we now have two different ops,
> dw_pcie_ops (ops for dw_pcie) and dw_pcie_host_ops (ops for a pcie_port),
> note that they are different. The dw_pcie_ops is missing for pcie-artpec6
> and pcie-designware-plat (since we are using the generic link-up function).
> 
> Before commit 442ec4c04d12, dw_pcie_writel_dbi had dw_pcie_host_ops as
> parameter, after the commit it has dw_pcie_ops as parameter.
> It should crash on pcie-designware-plat as well, since there are other
> functions, like dw_pcie_link_up, that assumes that pci->ops != null.
> 
> Another alternative to adding the dummy ops would be to add null checks
> for all uses off pci->ops in pcie-designware.c.
> I don't like the idea to sprinkle null checks everywhere pci->ops is used.
> 
> One could add a null check in dw_pcie_host_init, but without a dummy ops
> we would still fail this check, so our drivers would still be non-functional
> in Linus's tree.

Agree.
Acked-by: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH] PCI: dwc: fix crash seen due to missing ops

[Joao Pinto]

Às 7:19 AM de 3/23/2017, Niklas Cassel escreveu:
> On 03/22/2017 04:47 PM, Joao Pinto wrote:
>> Hi Niklas,
>>
>> Às 2:43 PM de 3/21/2017, Niklas Cassel escreveu:
>>> From: Niklas Cassel 
>>>
>>> Fix the following crash, seen in dwc/pcie-artpec6.
>>>
>>>   Unable to handle kernel NULL pointer dereference at virtual address 
>>> 0004
>>>   pgd = c0204000
>>>   [0004] *pgd=
>>>   Internal error: Oops: 5 [#1] SMP ARM
>>>   Modules linked in:
>>>   CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc3-next-20170321 #1
>>>   Hardware name: Axis ARTPEC-6 Platform
>>>   task: db098000 task.stack: db096000
>>>   PC is at dw_pcie_writel_dbi+0x2c/0xd0
>>>   ...
>>>
>>> While at it, fix the same problem for pcie-designware-plat.
>>>
>>> Fixes: 442ec4c04d12 ("PCI: dwc: all: Split struct pcie_port into host-only 
>>> and core structures")
>>> Signed-off-by: Niklas Cassel 
>>> ---
>>>  drivers/pci/dwc/pcie-artpec6.c | 4 
>>>  drivers/pci/dwc/pcie-designware-plat.c | 4 
>>>  2 files changed, 8 insertions(+)
>>>
>>> diff --git a/drivers/pci/dwc/pcie-artpec6.c b/drivers/pci/dwc/pcie-artpec6.c
>>> index fcd3ef845883..6d23683c0892 100644
>>> --- a/drivers/pci/dwc/pcie-artpec6.c
>>> +++ b/drivers/pci/dwc/pcie-artpec6.c
>>> @@ -234,6 +234,9 @@ static int artpec6_add_pcie_port(struct artpec6_pcie 
>>> *artpec6_pcie,
>>> return 0;
>>>  }
>>>  
>>> +static const struct dw_pcie_ops dw_pcie_ops = {
>>> +};
>>> +
>>>  static int artpec6_pcie_probe(struct platform_device *pdev)
>>>  {
>>> struct device *dev = >dev;
>>> @@ -252,6 +255,7 @@ static int artpec6_pcie_probe(struct platform_device 
>>> *pdev)
>>> return -ENOMEM;
>>>  
>>> pci->dev = dev;
>>> +   pci->ops = _pcie_ops;
>>>  
>>> artpec6_pcie->pci = pci;
>>>  
>>> diff --git a/drivers/pci/dwc/pcie-designware-plat.c 
>>> b/drivers/pci/dwc/pcie-designware-plat.c
>>> index b6c832ba39dd..f20d494922ab 100644
>>> --- a/drivers/pci/dwc/pcie-designware-plat.c
>>> +++ b/drivers/pci/dwc/pcie-designware-plat.c
>>> @@ -86,6 +86,9 @@ static int dw_plat_add_pcie_port(struct pcie_port *pp,
>>> return 0;
>>>  }
>>>  
>>> +static const struct dw_pcie_ops dw_pcie_ops = {
>>> +};
>>> +
>>>  static int dw_plat_pcie_probe(struct platform_device *pdev)
>>>  {
>>> struct device *dev = >dev;
>>> @@ -103,6 +106,7 @@ static int dw_plat_pcie_probe(struct platform_device 
>>> *pdev)
>>> return -ENOMEM;
>>>  
>>> pci->dev = dev;
>>> +   pci->ops = _pcie_ops;
>>>  
>>> dw_plat_pcie->pci = pci;
>>>  
>>>
>> In the case of pcie-designware-plat you have the declaration of pci->ops:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_helgaas_pci.git_tree_drivers_pci_dwc_pcie-2Ddesignware-2Dplat.c-23n78=DwID-g=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=28B2KMSJPmdGukxJhVcT-K6O76mP27iVn-XTqDwJ4p0=glxSZ800DErbgYPvxr-U26UBSVliExhaYEW-MIYIs7U=
>>  
>>
>> and in artpec6 in here:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_helgaas_pci.git_tree_drivers_pci_dwc_pcie-2Dartpec6.c-23n226=DwID-g=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=28B2KMSJPmdGukxJhVcT-K6O76mP27iVn-XTqDwJ4p0=_9PXmcF7fsBh4pqYI4lOl4kwCY48xSyUzg6VlCDIy9w=
>>  
>>
>> Both declarations are made previously of calling dw_pcie_host_init(), so why 
>> do
>> you need this dummy ops in the probe function? I never had that necessity.
> 
> Hello Joao
> 
> Since commit 442ec4c04d12, we now have two different ops,
> dw_pcie_ops (ops for dw_pcie) and dw_pcie_host_ops (ops for a pcie_port),
> note that they are different. The dw_pcie_ops is missing for pcie-artpec6
> and pcie-designware-plat (since we are using the generic link-up function).
> 
> Before commit 442ec4c04d12, dw_pcie_writel_dbi had dw_pcie_host_ops as
> parameter, after the commit it has dw_pcie_ops as parameter.
> It should crash on pcie-designware-plat as well, since there are other
> functions, like dw_pcie_link_up, that assumes that pci->ops != null.
> 
> Another alternative to adding the dummy ops would be to add null checks
> for all uses off pci->ops in pcie-designware.c.
> I don't like the idea to sprinkle null checks everywhere pci->ops is used.
> 
> One could add a null check in dw_pcie_host_init, but without a dummy ops
> we would still fail this check, so our drivers would still be non-functional
> in Linus's tree.

Agree.
Acked-by: Joao Pinto 

Re: stmmac: Performance regression after commit aff3d9eff843 "net: stmmac: enable multiple buffers"

[Joao Pinto]

Às 10:56 AM de 3/23/2017, Joao Pinto escreveu:
> Às 10:51 AM de 3/23/2017, Giuseppe CAVALLARO escreveu:
>> On 3/23/2017 11:48 AM, Giuseppe CAVALLARO wrote:
>>> Hello
>>>
>>> On 3/23/2017 11:20 AM, Corentin Labbe wrote:
>>>>> I have a 4.21 QoS Core with 4 RX + 4 TX and detected no regression.
>>>>>> Could you please share the iperf cmds you are using in order for me to
>>>>> reproduce
>>>>>> in my side?
>>>

HW Version: 4.21 QoS Core in HAPS DX7 (FPGA)
The connection between the FPGA and PC where stmmac is running is PCIe.
My configurations are done in stmmac_pci. Here they are:

@@ -68,10 +70,52 @@ static void stmmac_default_data(struct plat_stmmacenet_data
*plat)
 {
plat->bus_id = 1;
plat->phy_addr = 0;
-   plat->interface = PHY_INTERFACE_MODE_GMII;
-   plat->clk_csr = 2;  /* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
-   plat->has_gmac = 1;
-   plat->force_sf_dma_mode = 1;
+   plat->interface = PHY_INTERFACE_MODE_SGMII;
+   plat->clk_csr = 0x5;
+   plat->has_gmac = 0;
+   plat->has_gmac4 = 1;
+   plat->force_sf_dma_mode = 0;
+
+   plat->rx_queues_to_use = 4;
+   plat->tx_queues_to_use = 4;
+
+   plat->rx_sched_algorithm = MTL_RX_ALGORITHM_SP;
+
+   plat->rx_queues_cfg[0].mode_to_use = MTL_QUEUE_AVB;
+   plat->rx_queues_cfg[1].mode_to_use = MTL_QUEUE_DCB;
+   plat->rx_queues_cfg[2].mode_to_use = MTL_QUEUE_DCB;
+   plat->rx_queues_cfg[3].mode_to_use = MTL_QUEUE_DCB;
+
+   plat->tx_queues_cfg[0].mode_to_use = MTL_QUEUE_DCB;
+   plat->tx_queues_cfg[1].mode_to_use = MTL_QUEUE_AVB;
+   plat->tx_queues_cfg[2].mode_to_use = MTL_QUEUE_DCB;
+   plat->tx_queues_cfg[3].mode_to_use = MTL_QUEUE_DCB;
+
+   plat->tx_queues_cfg[1].send_slope = 0xCCC;
+   plat->tx_queues_cfg[1].idle_slope = 0x1333;
+   plat->tx_queues_cfg[1].high_credit = 0x4B;
+   plat->tx_queues_cfg[1].low_credit = 0xFFB5;
+
+   plat->rx_queues_cfg[0].chan = 0;
+   plat->rx_queues_cfg[1].chan = 1;
+   plat->rx_queues_cfg[2].chan = 2;
+   plat->rx_queues_cfg[3].chan = 3;
+
+   plat->tx_sched_algorithm = MTL_TX_ALGORITHM_WRR;
+   plat->tx_queues_cfg[0].weight = 0x10;
+   plat->tx_queues_cfg[1].weight = 0x11;
+   plat->tx_queues_cfg[2].weight = 0x12;
+   plat->tx_queues_cfg[3].weight = 0x13;
+
+   /* Disable Priority config by default */
+   plat->tx_queues_cfg[0].use_prio = false;
+   plat->rx_queues_cfg[0].use_prio = false;
+
+   /* Disable RX queues routing by default */
+   plat->rx_queues_cfg[0].pkt_route = 0x0;
+   plat->rx_queues_cfg[1].pkt_route = 0x0;
+   plat->rx_queues_cfg[2].pkt_route = 0x0;
+   plat->rx_queues_cfg[3].pkt_route = 0x0;

plat->mdio_bus_data->phy_reset = NULL;
plat->mdio_bus_data->phy_mask = 0;
@@ -83,22 +127,14 @@ static void stmmac_default_data(struct plat_stmmacenet_data
*plat)
/* Set default value for multicast hash bins */
plat->multicast_filter_bins = HASH_TABLE_SIZE;

+   plat->dma_cfg->fixed_burst = 0;
+   plat->dma_cfg->aal = 0;
+
/* Set default value for unicast filter entries */
plat->unicast_filter_entries = 1;

/* Set the maxmtu to a default of JUMBO_LEN */
plat->maxmtu = JUMBO_LEN;
-
-   /* Set default number of RX and TX queues to use */
-   plat->tx_queues_to_use = 1;
-   plat->rx_queues_to_use = 1;
-
-   /* Disable Priority config by default */
-   plat->tx_queues_cfg[0].use_prio = false;
-   plat->rx_queues_cfg[0].use_prio = false;
-
-   /* Disable RX queues routing by default */
-   plat->rx_queues_cfg[0].pkt_route = 0x0;
 }


*** TESTS ***


*TEST 1: File (linux-next tarball) transfer of ~1.4G by scp to the DUT*

scp net-next-20170323.tar.gz x@XXX:/home/synopsys/
The authenticity of host 'X' can't be established.
ECDSA key fingerprint is SHA256:/XX.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'XX' (ECDSA) to the list of known hosts.
XX@X's password:
net-next20170323.tar.gz

 100% 1366MB  79.3MB/s   00:17

ifconfig after transfer:

eth1  Link encap:Ethernet  HWaddr 
  inet addr:  Bcast:  Mask:
  inet6 addr: X Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:1026614 errors:0 dropped:0 overruns:0 frame:0
  TX packets:56804 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:1502856063 (1.5 GB)  TX bytes:4224767 (4.2 MB)
  Interrupt:16

*stmmac Log after transfer:

#:~/temp$ dmesg | grep stmmac
[0.

Re: stmmac: Performance regression after commit aff3d9eff843 "net: stmmac: enable multiple buffers"

[Joao Pinto]

Às 10:56 AM de 3/23/2017, Joao Pinto escreveu:
> Às 10:51 AM de 3/23/2017, Giuseppe CAVALLARO escreveu:
>> On 3/23/2017 11:48 AM, Giuseppe CAVALLARO wrote:
>>> Hello
>>>
>>> On 3/23/2017 11:20 AM, Corentin Labbe wrote:
>>>>> I have a 4.21 QoS Core with 4 RX + 4 TX and detected no regression.
>>>>>> Could you please share the iperf cmds you are using in order for me to
>>>>> reproduce
>>>>>> in my side?
>>>

HW Version: 4.21 QoS Core in HAPS DX7 (FPGA)
The connection between the FPGA and PC where stmmac is running is PCIe.
My configurations are done in stmmac_pci. Here they are:

@@ -68,10 +70,52 @@ static void stmmac_default_data(struct plat_stmmacenet_data
*plat)
 {
plat->bus_id = 1;
plat->phy_addr = 0;
-   plat->interface = PHY_INTERFACE_MODE_GMII;
-   plat->clk_csr = 2;  /* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
-   plat->has_gmac = 1;
-   plat->force_sf_dma_mode = 1;
+   plat->interface = PHY_INTERFACE_MODE_SGMII;
+   plat->clk_csr = 0x5;
+   plat->has_gmac = 0;
+   plat->has_gmac4 = 1;
+   plat->force_sf_dma_mode = 0;
+
+   plat->rx_queues_to_use = 4;
+   plat->tx_queues_to_use = 4;
+
+   plat->rx_sched_algorithm = MTL_RX_ALGORITHM_SP;
+
+   plat->rx_queues_cfg[0].mode_to_use = MTL_QUEUE_AVB;
+   plat->rx_queues_cfg[1].mode_to_use = MTL_QUEUE_DCB;
+   plat->rx_queues_cfg[2].mode_to_use = MTL_QUEUE_DCB;
+   plat->rx_queues_cfg[3].mode_to_use = MTL_QUEUE_DCB;
+
+   plat->tx_queues_cfg[0].mode_to_use = MTL_QUEUE_DCB;
+   plat->tx_queues_cfg[1].mode_to_use = MTL_QUEUE_AVB;
+   plat->tx_queues_cfg[2].mode_to_use = MTL_QUEUE_DCB;
+   plat->tx_queues_cfg[3].mode_to_use = MTL_QUEUE_DCB;
+
+   plat->tx_queues_cfg[1].send_slope = 0xCCC;
+   plat->tx_queues_cfg[1].idle_slope = 0x1333;
+   plat->tx_queues_cfg[1].high_credit = 0x4B;
+   plat->tx_queues_cfg[1].low_credit = 0xFFB5;
+
+   plat->rx_queues_cfg[0].chan = 0;
+   plat->rx_queues_cfg[1].chan = 1;
+   plat->rx_queues_cfg[2].chan = 2;
+   plat->rx_queues_cfg[3].chan = 3;
+
+   plat->tx_sched_algorithm = MTL_TX_ALGORITHM_WRR;
+   plat->tx_queues_cfg[0].weight = 0x10;
+   plat->tx_queues_cfg[1].weight = 0x11;
+   plat->tx_queues_cfg[2].weight = 0x12;
+   plat->tx_queues_cfg[3].weight = 0x13;
+
+   /* Disable Priority config by default */
+   plat->tx_queues_cfg[0].use_prio = false;
+   plat->rx_queues_cfg[0].use_prio = false;
+
+   /* Disable RX queues routing by default */
+   plat->rx_queues_cfg[0].pkt_route = 0x0;
+   plat->rx_queues_cfg[1].pkt_route = 0x0;
+   plat->rx_queues_cfg[2].pkt_route = 0x0;
+   plat->rx_queues_cfg[3].pkt_route = 0x0;

plat->mdio_bus_data->phy_reset = NULL;
plat->mdio_bus_data->phy_mask = 0;
@@ -83,22 +127,14 @@ static void stmmac_default_data(struct plat_stmmacenet_data
*plat)
/* Set default value for multicast hash bins */
plat->multicast_filter_bins = HASH_TABLE_SIZE;

+   plat->dma_cfg->fixed_burst = 0;
+   plat->dma_cfg->aal = 0;
+
/* Set default value for unicast filter entries */
plat->unicast_filter_entries = 1;

/* Set the maxmtu to a default of JUMBO_LEN */
plat->maxmtu = JUMBO_LEN;
-
-   /* Set default number of RX and TX queues to use */
-   plat->tx_queues_to_use = 1;
-   plat->rx_queues_to_use = 1;
-
-   /* Disable Priority config by default */
-   plat->tx_queues_cfg[0].use_prio = false;
-   plat->rx_queues_cfg[0].use_prio = false;
-
-   /* Disable RX queues routing by default */
-   plat->rx_queues_cfg[0].pkt_route = 0x0;
 }


*** TESTS ***


*TEST 1: File (linux-next tarball) transfer of ~1.4G by scp to the DUT*

scp net-next-20170323.tar.gz x@XXX:/home/synopsys/
The authenticity of host 'X' can't be established.
ECDSA key fingerprint is SHA256:/XX.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'XX' (ECDSA) to the list of known hosts.
XX@X's password:
net-next20170323.tar.gz

 100% 1366MB  79.3MB/s   00:17

ifconfig after transfer:

eth1  Link encap:Ethernet  HWaddr 
  inet addr:  Bcast:  Mask:
  inet6 addr: X Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:1026614 errors:0 dropped:0 overruns:0 frame:0
  TX packets:56804 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:1502856063 (1.5 GB)  TX bytes:4224767 (4.2 MB)
  Interrupt:16

*stmmac Log after transfer:

#:~/temp$ dmesg | grep stmmac
[0.

Re: stmmac: Performance regression after commit aff3d9eff843 "net: stmmac: enable multiple buffers"

[Joao Pinto]

Às 10:51 AM de 3/23/2017, Giuseppe CAVALLARO escreveu:
> On 3/23/2017 11:48 AM, Giuseppe CAVALLARO wrote:
>> Hello
>>
>> On 3/23/2017 11:20 AM, Corentin Labbe wrote:
 I have a 4.21 QoS Core with 4 RX + 4 TX and detected no regression.
 >Could you please share the iperf cmds you are using in order for me to
 reproduce
 >in my side?
>>
>> Joao, you have a really powerful HW integration with multiple channels for
>> both RX and TX.
>> Often this is not the same for other setup where, usually just a DMA0 is
>> present or, sometime, there
>> is just one RX extra channel.
>>
>> My question is, what happens on this kind of configurations? Are we still
>> guarantying the best performances?
>>
>> Also we have to guarantee, that the TSO and SG are always working. Another
>> point is the buffer sizes that
>> can be different among platforms.
>>
>> The problem  below reported by Corentin push me to think that there is a bug,
>> so we should
>> understand when this has been introduced and if likely fixed by some
>> configuration we are
>> not take care right now.
>>
>> ndesc_get_rx_status: Oversized frame spanned multiple buffers"
> 
> I wonder if this could be easily triggered by getting a big file via FTP. So 
> not
> properly related on performance benchs

I am going to do that test and check it out and also run iperf a couple of
times. I am counting on doing this today and send you later the results. If
anyone gets results sooner please share.

> 
> peppe
> 
>>
>>
>> Best Regards
>> Peppe
>>
> 

Thanks.

Re: stmmac: Performance regression after commit aff3d9eff843 "net: stmmac: enable multiple buffers"

[Joao Pinto]

Às 10:51 AM de 3/23/2017, Giuseppe CAVALLARO escreveu:
> On 3/23/2017 11:48 AM, Giuseppe CAVALLARO wrote:
>> Hello
>>
>> On 3/23/2017 11:20 AM, Corentin Labbe wrote:
 I have a 4.21 QoS Core with 4 RX + 4 TX and detected no regression.
 >Could you please share the iperf cmds you are using in order for me to
 reproduce
 >in my side?
>>
>> Joao, you have a really powerful HW integration with multiple channels for
>> both RX and TX.
>> Often this is not the same for other setup where, usually just a DMA0 is
>> present or, sometime, there
>> is just one RX extra channel.
>>
>> My question is, what happens on this kind of configurations? Are we still
>> guarantying the best performances?
>>
>> Also we have to guarantee, that the TSO and SG are always working. Another
>> point is the buffer sizes that
>> can be different among platforms.
>>
>> The problem  below reported by Corentin push me to think that there is a bug,
>> so we should
>> understand when this has been introduced and if likely fixed by some
>> configuration we are
>> not take care right now.
>>
>> ndesc_get_rx_status: Oversized frame spanned multiple buffers"
> 
> I wonder if this could be easily triggered by getting a big file via FTP. So 
> not
> properly related on performance benchs

I am going to do that test and check it out and also run iperf a couple of
times. I am counting on doing this today and send you later the results. If
anyone gets results sooner please share.

> 
> peppe
> 
>>
>>
>> Best Regards
>> Peppe
>>
> 

Thanks.

Re: stmmac: Performance regression after commit aff3d9eff843 "net: stmmac: enable multiple buffers"

[Joao Pinto]

Hi Peppe,

Às 10:48 AM de 3/23/2017, Giuseppe CAVALLARO escreveu:
> Hello
> 
> On 3/23/2017 11:20 AM, Corentin Labbe wrote:
>>> I have a 4.21 QoS Core with 4 RX + 4 TX and detected no regression.
>>> >Could you please share the iperf cmds you are using in order for me to
>>> reproduce
>>> >in my side?
> 
> Joao, you have a really powerful HW integration with multiple channels for 
> both
> RX and TX.
> Often this is not the same for other setup where, usually just a DMA0 is 
> present
> or, sometime, there
> is just one RX extra channel.

My opinion is that we should not have problems, since the majority of features
introduced are used if you configure rx queues > 1 or tx queues > 1, so if you
use the default (=1) those confiogurations will not take place.

> 
> My question is, what happens on this kind of configurations? Are we still
> guarantying the best performances?
> 
> Also we have to guarantee, that the TSO and SG are always working. Another 
> point
> is the buffer sizes that
> can be different among platforms.

We have to pay attention to the RX buffer size, since I had problems with DHCP
messages not being received because of little buffer size.
Currently TX buffer size is not configurable and in the future it should be
useful to include it too.

> 
> The problem  below reported by Corentin push me to think that there is a bug, 
> so
> we should
> understand when this has been introduced and if likely fixed by some
> configuration we are
> not take care right now.

Of course.

> 
> ndesc_get_rx_status: Oversized frame spanned multiple buffers"
> 
> 
> Best Regards
> Peppe

Thanks,
Joao

Re: stmmac: Performance regression after commit aff3d9eff843 "net: stmmac: enable multiple buffers"

[Joao Pinto]

Hi Peppe,

Às 10:48 AM de 3/23/2017, Giuseppe CAVALLARO escreveu:
> Hello
> 
> On 3/23/2017 11:20 AM, Corentin Labbe wrote:
>>> I have a 4.21 QoS Core with 4 RX + 4 TX and detected no regression.
>>> >Could you please share the iperf cmds you are using in order for me to
>>> reproduce
>>> >in my side?
> 
> Joao, you have a really powerful HW integration with multiple channels for 
> both
> RX and TX.
> Often this is not the same for other setup where, usually just a DMA0 is 
> present
> or, sometime, there
> is just one RX extra channel.

My opinion is that we should not have problems, since the majority of features
introduced are used if you configure rx queues > 1 or tx queues > 1, so if you
use the default (=1) those confiogurations will not take place.

> 
> My question is, what happens on this kind of configurations? Are we still
> guarantying the best performances?
> 
> Also we have to guarantee, that the TSO and SG are always working. Another 
> point
> is the buffer sizes that
> can be different among platforms.

We have to pay attention to the RX buffer size, since I had problems with DHCP
messages not being received because of little buffer size.
Currently TX buffer size is not configurable and in the future it should be
useful to include it too.

> 
> The problem  below reported by Corentin push me to think that there is a bug, 
> so
> we should
> understand when this has been introduced and if likely fixed by some
> configuration we are
> not take care right now.

Of course.

> 
> ndesc_get_rx_status: Oversized frame spanned multiple buffers"
> 
> 
> Best Regards
> Peppe

Thanks,
Joao

Re: stmmac: Performance regression after commit aff3d9eff843 "net: stmmac: enable multiple buffers"

[Joao Pinto]

Às 10:20 AM de 3/23/2017, Corentin Labbe escreveu:
> On Thu, Mar 23, 2017 at 10:12:18AM +0000, Joao Pinto wrote:
>>
>> Hi Corentin,
>>
>> Às 10:08 AM de 3/23/2017, Corentin Labbe escreveu:
>>> Hello
>>>
>>> Using next-20170323 produce a huge performance regression on my sunxi 
>>> boards.
>>> On dwmac-sun8i, iperf goes from 94mbs/s to 37 when sending.
>>>
>>> On cubieboard2(dwmac-sunxi), iperf made the kernel flood with 
>>> "ndesc_get_rx_status: Oversized frame spanned multiple buffers"
>>> and network is lost after.
>>>
>>> Reverting aff3d9eff84399e433c4aca65a9bb236581bc082 fix the issue.
>>> I still try to found which part of this patch mades the performance lower.
>>>
>>> Regards
>>> Corentin Labbe
>>>
>>
>> I have a 4.21 QoS Core with 4 RX + 4 TX and detected no regression.
>> Could you please share the iperf cmds you are using in order for me to 
>> reproduce
>> in my side?
> 
> simple iperf -c serverip for both board
> 

Ok, I am going to run my tests with a fresh net-next and come back to you soon.

Thanks,
Joao

Re: stmmac: Performance regression after commit aff3d9eff843 "net: stmmac: enable multiple buffers"

[Joao Pinto]

Às 10:20 AM de 3/23/2017, Corentin Labbe escreveu:
> On Thu, Mar 23, 2017 at 10:12:18AM +0000, Joao Pinto wrote:
>>
>> Hi Corentin,
>>
>> Às 10:08 AM de 3/23/2017, Corentin Labbe escreveu:
>>> Hello
>>>
>>> Using next-20170323 produce a huge performance regression on my sunxi 
>>> boards.
>>> On dwmac-sun8i, iperf goes from 94mbs/s to 37 when sending.
>>>
>>> On cubieboard2(dwmac-sunxi), iperf made the kernel flood with 
>>> "ndesc_get_rx_status: Oversized frame spanned multiple buffers"
>>> and network is lost after.
>>>
>>> Reverting aff3d9eff84399e433c4aca65a9bb236581bc082 fix the issue.
>>> I still try to found which part of this patch mades the performance lower.
>>>
>>> Regards
>>> Corentin Labbe
>>>
>>
>> I have a 4.21 QoS Core with 4 RX + 4 TX and detected no regression.
>> Could you please share the iperf cmds you are using in order for me to 
>> reproduce
>> in my side?
> 
> simple iperf -c serverip for both board
> 

Ok, I am going to run my tests with a fresh net-next and come back to you soon.

Thanks,
Joao

Re: stmmac: Performance regression after commit aff3d9eff843 "net: stmmac: enable multiple buffers"

[Joao Pinto]

Hi Corentin,

Às 10:08 AM de 3/23/2017, Corentin Labbe escreveu:
> Hello
> 
> Using next-20170323 produce a huge performance regression on my sunxi boards.
> On dwmac-sun8i, iperf goes from 94mbs/s to 37 when sending.
> 
> On cubieboard2(dwmac-sunxi), iperf made the kernel flood with 
> "ndesc_get_rx_status: Oversized frame spanned multiple buffers"
> and network is lost after.
> 
> Reverting aff3d9eff84399e433c4aca65a9bb236581bc082 fix the issue.
> I still try to found which part of this patch mades the performance lower.
> 
> Regards
> Corentin Labbe
> 

I have a 4.21 QoS Core with 4 RX + 4 TX and detected no regression.
Could you please share the iperf cmds you are using in order for me to reproduce
in my side?

@stmmac users: It would be great if people that have a setup could also perform
teh same iperf test in order to clean in up for everyone.

Thanks,
Joao

Re: stmmac: Performance regression after commit aff3d9eff843 "net: stmmac: enable multiple buffers"

[Joao Pinto]

Hi Corentin,

Às 10:08 AM de 3/23/2017, Corentin Labbe escreveu:
> Hello
> 
> Using next-20170323 produce a huge performance regression on my sunxi boards.
> On dwmac-sun8i, iperf goes from 94mbs/s to 37 when sending.
> 
> On cubieboard2(dwmac-sunxi), iperf made the kernel flood with 
> "ndesc_get_rx_status: Oversized frame spanned multiple buffers"
> and network is lost after.
> 
> Reverting aff3d9eff84399e433c4aca65a9bb236581bc082 fix the issue.
> I still try to found which part of this patch mades the performance lower.
> 
> Regards
> Corentin Labbe
> 

I have a 4.21 QoS Core with 4 RX + 4 TX and detected no regression.
Could you please share the iperf cmds you are using in order for me to reproduce
in my side?

@stmmac users: It would be great if people that have a setup could also perform
teh same iperf test in order to clean in up for everyone.

Thanks,
Joao

Re: [PATCH] PCI: dwc: fix crash seen due to missing ops

[Joao Pinto]

Hi Niklas,

Às 2:43 PM de 3/21/2017, Niklas Cassel escreveu:
> From: Niklas Cassel 
> 
> Fix the following crash, seen in dwc/pcie-artpec6.
> 
>   Unable to handle kernel NULL pointer dereference at virtual address 0004
>   pgd = c0204000
>   [0004] *pgd=
>   Internal error: Oops: 5 [#1] SMP ARM
>   Modules linked in:
>   CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc3-next-20170321 #1
>   Hardware name: Axis ARTPEC-6 Platform
>   task: db098000 task.stack: db096000
>   PC is at dw_pcie_writel_dbi+0x2c/0xd0
>   ...
> 
> While at it, fix the same problem for pcie-designware-plat.
> 
> Fixes: 442ec4c04d12 ("PCI: dwc: all: Split struct pcie_port into host-only 
> and core structures")
> Signed-off-by: Niklas Cassel 
> ---
>  drivers/pci/dwc/pcie-artpec6.c | 4 
>  drivers/pci/dwc/pcie-designware-plat.c | 4 
>  2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-artpec6.c b/drivers/pci/dwc/pcie-artpec6.c
> index fcd3ef845883..6d23683c0892 100644
> --- a/drivers/pci/dwc/pcie-artpec6.c
> +++ b/drivers/pci/dwc/pcie-artpec6.c
> @@ -234,6 +234,9 @@ static int artpec6_add_pcie_port(struct artpec6_pcie 
> *artpec6_pcie,
>   return 0;
>  }
>  
> +static const struct dw_pcie_ops dw_pcie_ops = {
> +};
> +
>  static int artpec6_pcie_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
> @@ -252,6 +255,7 @@ static int artpec6_pcie_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>  
>   pci->dev = dev;
> + pci->ops = _pcie_ops;
>  
>   artpec6_pcie->pci = pci;
>  
> diff --git a/drivers/pci/dwc/pcie-designware-plat.c 
> b/drivers/pci/dwc/pcie-designware-plat.c
> index b6c832ba39dd..f20d494922ab 100644
> --- a/drivers/pci/dwc/pcie-designware-plat.c
> +++ b/drivers/pci/dwc/pcie-designware-plat.c
> @@ -86,6 +86,9 @@ static int dw_plat_add_pcie_port(struct pcie_port *pp,
>   return 0;
>  }
>  
> +static const struct dw_pcie_ops dw_pcie_ops = {
> +};
> +
>  static int dw_plat_pcie_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
> @@ -103,6 +106,7 @@ static int dw_plat_pcie_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>  
>   pci->dev = dev;
> + pci->ops = _pcie_ops;
>  
>   dw_plat_pcie->pci = pci;
>  
> 

In the case of pcie-designware-plat you have the declaration of pci->ops:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/tree/drivers/pci/dwc/pcie-designware-plat.c#n78

and in artpec6 in here:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/tree/drivers/pci/dwc/pcie-artpec6.c#n226

Both declarations are made previously of calling dw_pcie_host_init(), so why do
you need this dummy ops in the probe function? I never had that necessity.

Thanks,
Joao

Thanks,

Re: [PATCH] PCI: dwc: fix crash seen due to missing ops

[Joao Pinto]

Hi Niklas,

Às 2:43 PM de 3/21/2017, Niklas Cassel escreveu:
> From: Niklas Cassel 
> 
> Fix the following crash, seen in dwc/pcie-artpec6.
> 
>   Unable to handle kernel NULL pointer dereference at virtual address 0004
>   pgd = c0204000
>   [0004] *pgd=
>   Internal error: Oops: 5 [#1] SMP ARM
>   Modules linked in:
>   CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc3-next-20170321 #1
>   Hardware name: Axis ARTPEC-6 Platform
>   task: db098000 task.stack: db096000
>   PC is at dw_pcie_writel_dbi+0x2c/0xd0
>   ...
> 
> While at it, fix the same problem for pcie-designware-plat.
> 
> Fixes: 442ec4c04d12 ("PCI: dwc: all: Split struct pcie_port into host-only 
> and core structures")
> Signed-off-by: Niklas Cassel 
> ---
>  drivers/pci/dwc/pcie-artpec6.c | 4 
>  drivers/pci/dwc/pcie-designware-plat.c | 4 
>  2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-artpec6.c b/drivers/pci/dwc/pcie-artpec6.c
> index fcd3ef845883..6d23683c0892 100644
> --- a/drivers/pci/dwc/pcie-artpec6.c
> +++ b/drivers/pci/dwc/pcie-artpec6.c
> @@ -234,6 +234,9 @@ static int artpec6_add_pcie_port(struct artpec6_pcie 
> *artpec6_pcie,
>   return 0;
>  }
>  
> +static const struct dw_pcie_ops dw_pcie_ops = {
> +};
> +
>  static int artpec6_pcie_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
> @@ -252,6 +255,7 @@ static int artpec6_pcie_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>  
>   pci->dev = dev;
> + pci->ops = _pcie_ops;
>  
>   artpec6_pcie->pci = pci;
>  
> diff --git a/drivers/pci/dwc/pcie-designware-plat.c 
> b/drivers/pci/dwc/pcie-designware-plat.c
> index b6c832ba39dd..f20d494922ab 100644
> --- a/drivers/pci/dwc/pcie-designware-plat.c
> +++ b/drivers/pci/dwc/pcie-designware-plat.c
> @@ -86,6 +86,9 @@ static int dw_plat_add_pcie_port(struct pcie_port *pp,
>   return 0;
>  }
>  
> +static const struct dw_pcie_ops dw_pcie_ops = {
> +};
> +
>  static int dw_plat_pcie_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
> @@ -103,6 +106,7 @@ static int dw_plat_pcie_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>  
>   pci->dev = dev;
> + pci->ops = _pcie_ops;
>  
>   dw_plat_pcie->pci = pci;
>  
> 

In the case of pcie-designware-plat you have the declaration of pci->ops:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/tree/drivers/pci/dwc/pcie-designware-plat.c#n78

and in artpec6 in here:
https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/tree/drivers/pci/dwc/pcie-artpec6.c#n226

Both declarations are made previously of calling dw_pcie_host_init(), so why do
you need this dummy ops in the probe function? I never had that necessity.

Thanks,
Joao

Thanks,

Re: [PATCH 3/3] net: stmmac: Use AVB mode by default

[Joao Pinto]

Às 4:50 PM de 3/21/2017, Joao Pinto escreveu:
> Às 4:42 PM de 3/21/2017, Thierry Reding escreveu:
>> On Tue, Mar 21, 2017 at 03:23:00PM +0000, Joao Pinto wrote:
>>> Às 3:12 PM de 3/21/2017, Thierry Reding escreveu:
>>>> From: Thierry Reding <tred...@nvidia.com>
>>>>
>>>> Prior to the recent multi-queue changes the driver would configure the
>>>> queues to use the AVB mode, but the mode then got switched to DCB. The
>>>> hardware still works fine in DCB mode, but my testing capabilities are
>>>> limited, so it's safer to revert to the prior setting anyway.
>>>>
>>>> Signed-off-by: Thierry Reding <tred...@nvidia.com>
>>>> ---
>>>>  include/linux/stmmac.h | 4 ++--
>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
>>>> index be47b859e954..8349a5c1537b 100644
>>>> --- a/include/linux/stmmac.h
>>>> +++ b/include/linux/stmmac.h
>>>> @@ -56,8 +56,8 @@
>>>>  #define MTL_RX_ALGORITHM_WSP  0x5
>>>>  
>>>>  /* RX/TX Queue Mode */
>>>> -#define MTL_QUEUE_DCB 0x0
>>>> -#define MTL_QUEUE_AVB 0x1
>>>> +#define MTL_QUEUE_AVB 0x0
>>>> +#define MTL_QUEUE_DCB 0x1
>>>>  
>>>>  /* The MDC clock could be set higher than the IEEE 802.3
>>>>   * specified frequency limit 0f 2.5 MHz, by programming a clock divider
>>>>
>>>
>>> Thierry, I don't understand this patch. It will have 0 impact.
>>>
>>> In stmmac_platform configuration, 0 impact:
>>>
>>> if (of_property_read_bool(q_node, "snps,dcb-algorithm"))
>>> plat->rx_queues_cfg[queue].mode_to_use = MTL_QUEUE_DCB;
>>> else if (of_property_read_bool(q_node, "snps,avb-algorithm"))
>>> plat->rx_queues_cfg[queue].mode_to_use = MTL_QUEUE_AVB;
>>> else
>>> **  plat->rx_queues_cfg[queue].mode_to_use = MTL_QUEUE_DCB;
>>>
>>> In dwmac4_core, 0 impact:
>>>
>>> value &= GMAC_RX_QUEUE_CLEAR(queue);
>>> if (mode == MTL_QUEUE_AVB)
>>> value |= GMAC_RX_AV_QUEUE_ENABLE(queue);
>>> else if (mode == MTL_QUEUE_DCB)
>>> value |= GMAC_RX_DCB_QUEUE_ENABLE(queue);
>>>
>>> I think you should set the default mode in (**).
>>
>> That was my initial attempt, but then I realized that for old DTBs,
>> stmmac_mtl_setup() will already exit prematurely because of the missing
>> snps,mtl-{rx,tx}-config properties. It's pretty much for the same reason
>> as the separate assignment of the default {rx,tx}_queues_to_use. In this
>> case it's somewhat more obfuscated, though. Changing AVB to be mode 0
>> means that plat->rx_queues_cfg[].mode_to_use will contain AVB as default
>> because plat is devm_kzalloc()'ed.
>>
>> Effectively this change makes all queues use AVB by default unless they
>> are configured using the new device tree bindings.
> 
> Yes I keep forgeting that :), but you are assuming that
> plat->rx_queues_cfg[queue].mode_to_use is 0 by default, which might not be the
> case, but I agree with you that this is the simpler approach. Let's see what
> others have to say.

Forget what I said, yes devm_kzalloc() in plat guarantees this. I need a cup of
coffee :).

Acked-By: Joao Pinto <jpi...@synopsys.com>
>>
>> Thierry
>>
> 

Re: [PATCH 3/3] net: stmmac: Use AVB mode by default

[Joao Pinto]

Às 4:50 PM de 3/21/2017, Joao Pinto escreveu:
> Às 4:42 PM de 3/21/2017, Thierry Reding escreveu:
>> On Tue, Mar 21, 2017 at 03:23:00PM +0000, Joao Pinto wrote:
>>> Às 3:12 PM de 3/21/2017, Thierry Reding escreveu:
>>>> From: Thierry Reding 
>>>>
>>>> Prior to the recent multi-queue changes the driver would configure the
>>>> queues to use the AVB mode, but the mode then got switched to DCB. The
>>>> hardware still works fine in DCB mode, but my testing capabilities are
>>>> limited, so it's safer to revert to the prior setting anyway.
>>>>
>>>> Signed-off-by: Thierry Reding 
>>>> ---
>>>>  include/linux/stmmac.h | 4 ++--
>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
>>>> index be47b859e954..8349a5c1537b 100644
>>>> --- a/include/linux/stmmac.h
>>>> +++ b/include/linux/stmmac.h
>>>> @@ -56,8 +56,8 @@
>>>>  #define MTL_RX_ALGORITHM_WSP  0x5
>>>>  
>>>>  /* RX/TX Queue Mode */
>>>> -#define MTL_QUEUE_DCB 0x0
>>>> -#define MTL_QUEUE_AVB 0x1
>>>> +#define MTL_QUEUE_AVB 0x0
>>>> +#define MTL_QUEUE_DCB 0x1
>>>>  
>>>>  /* The MDC clock could be set higher than the IEEE 802.3
>>>>   * specified frequency limit 0f 2.5 MHz, by programming a clock divider
>>>>
>>>
>>> Thierry, I don't understand this patch. It will have 0 impact.
>>>
>>> In stmmac_platform configuration, 0 impact:
>>>
>>> if (of_property_read_bool(q_node, "snps,dcb-algorithm"))
>>> plat->rx_queues_cfg[queue].mode_to_use = MTL_QUEUE_DCB;
>>> else if (of_property_read_bool(q_node, "snps,avb-algorithm"))
>>> plat->rx_queues_cfg[queue].mode_to_use = MTL_QUEUE_AVB;
>>> else
>>> **  plat->rx_queues_cfg[queue].mode_to_use = MTL_QUEUE_DCB;
>>>
>>> In dwmac4_core, 0 impact:
>>>
>>> value &= GMAC_RX_QUEUE_CLEAR(queue);
>>> if (mode == MTL_QUEUE_AVB)
>>> value |= GMAC_RX_AV_QUEUE_ENABLE(queue);
>>> else if (mode == MTL_QUEUE_DCB)
>>> value |= GMAC_RX_DCB_QUEUE_ENABLE(queue);
>>>
>>> I think you should set the default mode in (**).
>>
>> That was my initial attempt, but then I realized that for old DTBs,
>> stmmac_mtl_setup() will already exit prematurely because of the missing
>> snps,mtl-{rx,tx}-config properties. It's pretty much for the same reason
>> as the separate assignment of the default {rx,tx}_queues_to_use. In this
>> case it's somewhat more obfuscated, though. Changing AVB to be mode 0
>> means that plat->rx_queues_cfg[].mode_to_use will contain AVB as default
>> because plat is devm_kzalloc()'ed.
>>
>> Effectively this change makes all queues use AVB by default unless they
>> are configured using the new device tree bindings.
> 
> Yes I keep forgeting that :), but you are assuming that
> plat->rx_queues_cfg[queue].mode_to_use is 0 by default, which might not be the
> case, but I agree with you that this is the simpler approach. Let's see what
> others have to say.

Forget what I said, yes devm_kzalloc() in plat guarantees this. I need a cup of
coffee :).

Acked-By: Joao Pinto 
>>
>> Thierry
>>
> 

Re: [PATCH 3/3] net: stmmac: Use AVB mode by default

[Joao Pinto]

Às 4:42 PM de 3/21/2017, Thierry Reding escreveu:
> On Tue, Mar 21, 2017 at 03:23:00PM +0000, Joao Pinto wrote:
>> Às 3:12 PM de 3/21/2017, Thierry Reding escreveu:
>>> From: Thierry Reding <tred...@nvidia.com>
>>>
>>> Prior to the recent multi-queue changes the driver would configure the
>>> queues to use the AVB mode, but the mode then got switched to DCB. The
>>> hardware still works fine in DCB mode, but my testing capabilities are
>>> limited, so it's safer to revert to the prior setting anyway.
>>>
>>> Signed-off-by: Thierry Reding <tred...@nvidia.com>
>>> ---
>>>  include/linux/stmmac.h | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
>>> index be47b859e954..8349a5c1537b 100644
>>> --- a/include/linux/stmmac.h
>>> +++ b/include/linux/stmmac.h
>>> @@ -56,8 +56,8 @@
>>>  #define MTL_RX_ALGORITHM_WSP   0x5
>>>  
>>>  /* RX/TX Queue Mode */
>>> -#define MTL_QUEUE_DCB  0x0
>>> -#define MTL_QUEUE_AVB  0x1
>>> +#define MTL_QUEUE_AVB  0x0
>>> +#define MTL_QUEUE_DCB  0x1
>>>  
>>>  /* The MDC clock could be set higher than the IEEE 802.3
>>>   * specified frequency limit 0f 2.5 MHz, by programming a clock divider
>>>
>>
>> Thierry, I don't understand this patch. It will have 0 impact.
>>
>> In stmmac_platform configuration, 0 impact:
>>
>>  if (of_property_read_bool(q_node, "snps,dcb-algorithm"))
>>  plat->rx_queues_cfg[queue].mode_to_use = MTL_QUEUE_DCB;
>>  else if (of_property_read_bool(q_node, "snps,avb-algorithm"))
>>  plat->rx_queues_cfg[queue].mode_to_use = MTL_QUEUE_AVB;
>>  else
>> **   plat->rx_queues_cfg[queue].mode_to_use = MTL_QUEUE_DCB;
>>
>> In dwmac4_core, 0 impact:
>>
>>  value &= GMAC_RX_QUEUE_CLEAR(queue);
>>  if (mode == MTL_QUEUE_AVB)
>>  value |= GMAC_RX_AV_QUEUE_ENABLE(queue);
>>  else if (mode == MTL_QUEUE_DCB)
>>  value |= GMAC_RX_DCB_QUEUE_ENABLE(queue);
>>
>> I think you should set the default mode in (**).
> 
> That was my initial attempt, but then I realized that for old DTBs,
> stmmac_mtl_setup() will already exit prematurely because of the missing
> snps,mtl-{rx,tx}-config properties. It's pretty much for the same reason
> as the separate assignment of the default {rx,tx}_queues_to_use. In this
> case it's somewhat more obfuscated, though. Changing AVB to be mode 0
> means that plat->rx_queues_cfg[].mode_to_use will contain AVB as default
> because plat is devm_kzalloc()'ed.
> 
> Effectively this change makes all queues use AVB by default unless they
> are configured using the new device tree bindings.

Yes I keep forgeting that :), but you are assuming that
plat->rx_queues_cfg[queue].mode_to_use is 0 by default, which might not be the
case, but I agree with you that this is the simpler approach. Let's see what
others have to say.
> 
> Thierry
>