[PATCH 0/4] PCI: mobivel: Drop layerscape gen4 support

[PATCH 0/4] PCI: mobivel: Drop layerscape gen4 support

[Frank Li]

Only lx2160 rev1 use mobivel PCIe controller. Rev2 switch to use designware
PCIe controller. Rev2 is mass production version. Rev1 will not be
maintained and used in future. And no road map to use mobivel PCIe
controller. So drop related codes.

To: Bjorn Helgaas <bhelgaas@google.com>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
To: Krzysztof Wilczyński <kw@linux.com>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Zhiqiang.Hou@nxp.com
Cc: linux-pci@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: imx@lists.linux.dev

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Frank Li (4):
      dt-bindings: PCI: layerscape-pci: drop compatible string fsl,lx2160a-pcie
      dt-bindings: PCI: drop layerscape-pcie-gen4.txt
      PCI: mobiveil: Drop layerscape-gen4 support
      MAINTAINERS: drop NXP LAYERSCAPE GEN4 CONTROLLER

 .../bindings/pci/fsl,layerscape-pcie.yaml          |   1 -
 .../bindings/pci/layerscape-pcie-gen4.txt          |  52 -----
 MAINTAINERS                                        |   8 -
 drivers/pci/controller/mobiveil/Kconfig            |   9 -
 drivers/pci/controller/mobiveil/Makefile           |   1 -
 .../pci/controller/mobiveil/pcie-layerscape-gen4.c | 255 ---------------------
 6 files changed, 326 deletions(-)
---
base-commit: 1e391b34f6aa043c7afa40a2103163a0ef06d179
change-id: 20240808-mobivel_cleanup-8a790adcd96a

Best regards,
---
Frank Li <Frank.Li@nxp.com>

[PATCH 1/4] dt-bindings: PCI: layerscape-pci: drop compatible string fsl,lx2160a-pcie

[Frank Li]

fsl,lx2160a-pcie compatible is used for mobivel according to
Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt

fsl,layerscape-pcie.yaml is used for designware PCIe controller binding. So
drop it.

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
 Documentation/devicetree/bindings/pci/fsl,layerscape-pcie.yaml | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pci/fsl,layerscape-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,layerscape-pcie.yaml
index 793986c5af7ff..4010a53c32d2a 100644
--- a/Documentation/devicetree/bindings/pci/fsl,layerscape-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,layerscape-pcie.yaml
@@ -32,7 +32,6 @@ properties:
       - fsl,ls1043a-pcie
       - fsl,ls1012a-pcie
       - fsl,ls1028a-pcie
-      - fsl,lx2160a-pcie
 
   reg:
     maxItems: 2

-- 
2.34.1

Re: [PATCH 1/4] dt-bindings: PCI: layerscape-pci: drop compatible string fsl,lx2160a-pcie

[Krzysztof Kozlowski]

On 08/08/2024 18:02, Frank Li wrote:
> fsl,lx2160a-pcie compatible is used for mobivel according to
> Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
> 
> fsl,layerscape-pcie.yaml is used for designware PCIe controller binding. So
> drop it.
> 
> Signed-off-by: Frank Li <Frank.Li@nxp.com>

Fixes tag? You added during conversion which was neither explained in
commit msg (and commit must point such differences from pure conversion)
nor needed.

Best regards,
Krzysztof

[PATCH 2/4] dt-bindings: PCI: drop layerscape-pcie-gen4.txt

[Frank Li]

lx2160 rev1 use mobivel PCIe controller and switch to designware PCIe
controller at rev2, which is mass production version. So drop unused
document.

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
 .../bindings/pci/layerscape-pcie-gen4.txt          | 52 ----------------------
 1 file changed, 52 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt b/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
deleted file mode 100644
index b40fb5d15d3d9..0000000000000
--- a/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-NXP Layerscape PCIe Gen4 controller
-
-This PCIe controller is based on the Mobiveil PCIe IP and thus inherits all
-the common properties defined in mobiveil-pcie.txt.
-
-Required properties:
-- compatible: should contain the platform identifier such as:
-  "fsl,lx2160a-pcie"
-- reg: base addresses and lengths of the PCIe controller register blocks.
-  "csr_axi_slave": Bridge config registers
-  "config_axi_slave": PCIe controller registers
-- interrupts: A list of interrupt outputs of the controller. Must contain an
-  entry for each entry in the interrupt-names property.
-- interrupt-names: It could include the following entries:
-  "intr": The interrupt that is asserted for controller interrupts
-  "aer": Asserted for aer interrupt when chip support the aer interrupt with
-	 none MSI/MSI-X/INTx mode,but there is interrupt line for aer.
-  "pme": Asserted for pme interrupt when chip support the pme interrupt with
-	 none MSI/MSI-X/INTx mode,but there is interrupt line for pme.
-- dma-coherent: Indicates that the hardware IP block can ensure the coherency
-  of the data transferred from/to the IP block. This can avoid the software
-  cache flush/invalid actions, and improve the performance significantly.
-- msi-parent : See the generic MSI binding described in
-  Documentation/devicetree/bindings/interrupt-controller/msi.txt.
-
-Example:
-
-	pcie@3400000 {
-		compatible = "fsl,lx2160a-pcie";
-		reg = <0x00 0x03400000 0x0 0x00100000   /* controller registers */
-		       0x80 0x00000000 0x0 0x00001000>; /* configuration space */
-		reg-names = "csr_axi_slave", "config_axi_slave";
-		interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, /* AER interrupt */
-			     <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
-			     <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
-		interrupt-names = "aer", "pme", "intr";
-		#address-cells = <3>;
-		#size-cells = <2>;
-		device_type = "pci";
-		apio-wins = <8>;
-		ppio-wins = <8>;
-		dma-coherent;
-		bus-range = <0x0 0xff>;
-		msi-parent = <&its>;
-		ranges = <0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>;
-		#interrupt-cells = <1>;
-		interrupt-map-mask = <0 0 0 7>;
-		interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
-				<0000 0 0 2 &gic 0 0 GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
-				<0000 0 0 3 &gic 0 0 GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
-				<0000 0 0 4 &gic 0 0 GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
-	};

-- 
2.34.1

Re: [PATCH 2/4] dt-bindings: PCI: drop layerscape-pcie-gen4.txt

[Krzysztof Kozlowski]

On 08/08/2024 18:02, Frank Li wrote:
> lx2160 rev1 use mobivel PCIe controller and switch to designware PCIe
> controller at rev2, which is mass production version. So drop unused
> document.

Compatible is still used. Also, wrong order of patches. Dropping
bindings is THE LAST patch.

> 
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
>  .../bindings/pci/layerscape-pcie-gen4.txt          | 52 ----------------------
>  1 file changed, 52 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt b/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
> deleted file mode 100644
> index b40fb5d15d3d9..0000000000000
> --- a/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
> +++ /dev/null
> @@ -1,52 +0,0 @@
> -NXP Layerscape PCIe Gen4 controller
> -
> -This PCIe controller is based on the Mobiveil PCIe IP and thus inherits all
> -the common properties defined in mobiveil-pcie.txt.

So this explains all the confusion about your DTS patches, but this was
nowwhere explained! Nothing here mentions DTS users. Nothing in DTS
patch mentions dropping bindings with rationale.

Best regards,
Krzysztof

[PATCH 3/4] PCI: mobiveil: Drop layerscape-gen4 support

[Frank Li]

Only lx2160 rev1 use mobiveil PCIe controller. Rev2 switch to designware
PCIe controller. Rev2 is mass production chip and Rev1 will be not
supported. So drop related code.

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
 drivers/pci/controller/mobiveil/Kconfig            |   9 -
 drivers/pci/controller/mobiveil/Makefile           |   1 -
 .../pci/controller/mobiveil/pcie-layerscape-gen4.c | 255 ---------------------
 3 files changed, 265 deletions(-)

diff --git a/drivers/pci/controller/mobiveil/Kconfig b/drivers/pci/controller/mobiveil/Kconfig
index 58ce034f701ab..89b8ce9e1262f 100644
--- a/drivers/pci/controller/mobiveil/Kconfig
+++ b/drivers/pci/controller/mobiveil/Kconfig
@@ -11,15 +11,6 @@ config PCIE_MOBIVEIL_HOST
 	depends on PCI_MSI
 	select PCIE_MOBIVEIL
 
-config PCIE_LAYERSCAPE_GEN4
-	bool "Freescale Layerscape Gen4 PCIe controller"
-	depends on ARCH_LAYERSCAPE || COMPILE_TEST
-	depends on PCI_MSI
-	select PCIE_MOBIVEIL_HOST
-	help
-	  Say Y here if you want PCIe Gen4 controller support on
-	  Layerscape SoCs.
-
 config PCIE_MOBIVEIL_PLAT
 	bool "Mobiveil AXI PCIe controller"
 	depends on ARCH_ZYNQMP || COMPILE_TEST
diff --git a/drivers/pci/controller/mobiveil/Makefile b/drivers/pci/controller/mobiveil/Makefile
index 99d879de32d6e..9fb6d1c6504dc 100644
--- a/drivers/pci/controller/mobiveil/Makefile
+++ b/drivers/pci/controller/mobiveil/Makefile
@@ -2,4 +2,3 @@
 obj-$(CONFIG_PCIE_MOBIVEIL) += pcie-mobiveil.o
 obj-$(CONFIG_PCIE_MOBIVEIL_HOST) += pcie-mobiveil-host.o
 obj-$(CONFIG_PCIE_MOBIVEIL_PLAT) += pcie-mobiveil-plat.o
-obj-$(CONFIG_PCIE_LAYERSCAPE_GEN4) += pcie-layerscape-gen4.o
diff --git a/drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c b/drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
deleted file mode 100644
index 5af22bee913bd..0000000000000
--- a/drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
+++ /dev/null
@@ -1,255 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * PCIe Gen4 host controller driver for NXP Layerscape SoCs
- *
- * Copyright 2019-2020 NXP
- *
- * Author: Zhiqiang Hou <Zhiqiang.Hou@nxp.com>
- */
-
-#include <linux/kernel.h>
-#include <linux/interrupt.h>
-#include <linux/init.h>
-#include <linux/of_pci.h>
-#include <linux/of_platform.h>
-#include <linux/of_irq.h>
-#include <linux/of_address.h>
-#include <linux/pci.h>
-#include <linux/platform_device.h>
-#include <linux/resource.h>
-#include <linux/mfd/syscon.h>
-#include <linux/regmap.h>
-
-#include "pcie-mobiveil.h"
-
-/* LUT and PF control registers */
-#define PCIE_LUT_OFF			0x80000
-#define PCIE_PF_OFF			0xc0000
-#define PCIE_PF_INT_STAT		0x18
-#define PF_INT_STAT_PABRST		BIT(31)
-
-#define PCIE_PF_DBG			0x7fc
-#define PF_DBG_LTSSM_MASK		0x3f
-#define PF_DBG_LTSSM_L0			0x2d /* L0 state */
-#define PF_DBG_WE			BIT(31)
-#define PF_DBG_PABR			BIT(27)
-
-#define to_ls_g4_pcie(x)		platform_get_drvdata((x)->pdev)
-
-struct ls_g4_pcie {
-	struct mobiveil_pcie pci;
-	struct delayed_work dwork;
-	int irq;
-};
-
-static inline u32 ls_g4_pcie_pf_readl(struct ls_g4_pcie *pcie, u32 off)
-{
-	return ioread32(pcie->pci.csr_axi_slave_base + PCIE_PF_OFF + off);
-}
-
-static inline void ls_g4_pcie_pf_writel(struct ls_g4_pcie *pcie,
-					u32 off, u32 val)
-{
-	iowrite32(val, pcie->pci.csr_axi_slave_base + PCIE_PF_OFF + off);
-}
-
-static int ls_g4_pcie_link_up(struct mobiveil_pcie *pci)
-{
-	struct ls_g4_pcie *pcie = to_ls_g4_pcie(pci);
-	u32 state;
-
-	state = ls_g4_pcie_pf_readl(pcie, PCIE_PF_DBG);
-	state =	state & PF_DBG_LTSSM_MASK;
-
-	if (state == PF_DBG_LTSSM_L0)
-		return 1;
-
-	return 0;
-}
-
-static void ls_g4_pcie_disable_interrupt(struct ls_g4_pcie *pcie)
-{
-	struct mobiveil_pcie *mv_pci = &pcie->pci;
-
-	mobiveil_csr_writel(mv_pci, 0, PAB_INTP_AMBA_MISC_ENB);
-}
-
-static void ls_g4_pcie_enable_interrupt(struct ls_g4_pcie *pcie)
-{
-	struct mobiveil_pcie *mv_pci = &pcie->pci;
-	u32 val;
-
-	/* Clear the interrupt status */
-	mobiveil_csr_writel(mv_pci, 0xffffffff, PAB_INTP_AMBA_MISC_STAT);
-
-	val = PAB_INTP_INTX_MASK | PAB_INTP_MSI | PAB_INTP_RESET |
-	      PAB_INTP_PCIE_UE | PAB_INTP_IE_PMREDI | PAB_INTP_IE_EC;
-	mobiveil_csr_writel(mv_pci, val, PAB_INTP_AMBA_MISC_ENB);
-}
-
-static int ls_g4_pcie_reinit_hw(struct ls_g4_pcie *pcie)
-{
-	struct mobiveil_pcie *mv_pci = &pcie->pci;
-	struct device *dev = &mv_pci->pdev->dev;
-	u32 val, act_stat;
-	int to = 100;
-
-	/* Poll for pab_csb_reset to set and PAB activity to clear */
-	do {
-		usleep_range(10, 15);
-		val = ls_g4_pcie_pf_readl(pcie, PCIE_PF_INT_STAT);
-		act_stat = mobiveil_csr_readl(mv_pci, PAB_ACTIVITY_STAT);
-	} while (((val & PF_INT_STAT_PABRST) == 0 || act_stat) && to--);
-	if (to < 0) {
-		dev_err(dev, "Poll PABRST&PABACT timeout\n");
-		return -EIO;
-	}
-
-	/* clear PEX_RESET bit in PEX_PF0_DBG register */
-	val = ls_g4_pcie_pf_readl(pcie, PCIE_PF_DBG);
-	val |= PF_DBG_WE;
-	ls_g4_pcie_pf_writel(pcie, PCIE_PF_DBG, val);
-
-	val = ls_g4_pcie_pf_readl(pcie, PCIE_PF_DBG);
-	val |= PF_DBG_PABR;
-	ls_g4_pcie_pf_writel(pcie, PCIE_PF_DBG, val);
-
-	val = ls_g4_pcie_pf_readl(pcie, PCIE_PF_DBG);
-	val &= ~PF_DBG_WE;
-	ls_g4_pcie_pf_writel(pcie, PCIE_PF_DBG, val);
-
-	mobiveil_host_init(mv_pci, true);
-
-	to = 100;
-	while (!ls_g4_pcie_link_up(mv_pci) && to--)
-		usleep_range(200, 250);
-	if (to < 0) {
-		dev_err(dev, "PCIe link training timeout\n");
-		return -EIO;
-	}
-
-	return 0;
-}
-
-static irqreturn_t ls_g4_pcie_isr(int irq, void *dev_id)
-{
-	struct ls_g4_pcie *pcie = (struct ls_g4_pcie *)dev_id;
-	struct mobiveil_pcie *mv_pci = &pcie->pci;
-	u32 val;
-
-	val = mobiveil_csr_readl(mv_pci, PAB_INTP_AMBA_MISC_STAT);
-	if (!val)
-		return IRQ_NONE;
-
-	if (val & PAB_INTP_RESET) {
-		ls_g4_pcie_disable_interrupt(pcie);
-		schedule_delayed_work(&pcie->dwork, msecs_to_jiffies(1));
-	}
-
-	mobiveil_csr_writel(mv_pci, val, PAB_INTP_AMBA_MISC_STAT);
-
-	return IRQ_HANDLED;
-}
-
-static int ls_g4_pcie_interrupt_init(struct mobiveil_pcie *mv_pci)
-{
-	struct ls_g4_pcie *pcie = to_ls_g4_pcie(mv_pci);
-	struct platform_device *pdev = mv_pci->pdev;
-	struct device *dev = &pdev->dev;
-	int ret;
-
-	pcie->irq = platform_get_irq_byname(pdev, "intr");
-	if (pcie->irq < 0)
-		return pcie->irq;
-
-	ret = devm_request_irq(dev, pcie->irq, ls_g4_pcie_isr,
-			       IRQF_SHARED, pdev->name, pcie);
-	if (ret) {
-		dev_err(dev, "Can't register PCIe IRQ, errno = %d\n", ret);
-		return  ret;
-	}
-
-	return 0;
-}
-
-static void ls_g4_pcie_reset(struct work_struct *work)
-{
-	struct delayed_work *dwork = container_of(work, struct delayed_work,
-						  work);
-	struct ls_g4_pcie *pcie = container_of(dwork, struct ls_g4_pcie, dwork);
-	struct mobiveil_pcie *mv_pci = &pcie->pci;
-	u16 ctrl;
-
-	ctrl = mobiveil_csr_readw(mv_pci, PCI_BRIDGE_CONTROL);
-	ctrl &= ~PCI_BRIDGE_CTL_BUS_RESET;
-	mobiveil_csr_writew(mv_pci, ctrl, PCI_BRIDGE_CONTROL);
-
-	if (!ls_g4_pcie_reinit_hw(pcie))
-		return;
-
-	ls_g4_pcie_enable_interrupt(pcie);
-}
-
-static const struct mobiveil_rp_ops ls_g4_pcie_rp_ops = {
-	.interrupt_init = ls_g4_pcie_interrupt_init,
-};
-
-static const struct mobiveil_pab_ops ls_g4_pcie_pab_ops = {
-	.link_up = ls_g4_pcie_link_up,
-};
-
-static int __init ls_g4_pcie_probe(struct platform_device *pdev)
-{
-	struct device *dev = &pdev->dev;
-	struct pci_host_bridge *bridge;
-	struct mobiveil_pcie *mv_pci;
-	struct ls_g4_pcie *pcie;
-	struct device_node *np = dev->of_node;
-	int ret;
-
-	if (!of_parse_phandle(np, "msi-parent", 0)) {
-		dev_err(dev, "Failed to find msi-parent\n");
-		return -EINVAL;
-	}
-
-	bridge = devm_pci_alloc_host_bridge(dev, sizeof(*pcie));
-	if (!bridge)
-		return -ENOMEM;
-
-	pcie = pci_host_bridge_priv(bridge);
-	mv_pci = &pcie->pci;
-
-	mv_pci->pdev = pdev;
-	mv_pci->ops = &ls_g4_pcie_pab_ops;
-	mv_pci->rp.ops = &ls_g4_pcie_rp_ops;
-	mv_pci->rp.bridge = bridge;
-
-	platform_set_drvdata(pdev, pcie);
-
-	INIT_DELAYED_WORK(&pcie->dwork, ls_g4_pcie_reset);
-
-	ret = mobiveil_pcie_host_probe(mv_pci);
-	if (ret) {
-		dev_err(dev, "Fail to probe\n");
-		return  ret;
-	}
-
-	ls_g4_pcie_enable_interrupt(pcie);
-
-	return 0;
-}
-
-static const struct of_device_id ls_g4_pcie_of_match[] = {
-	{ .compatible = "fsl,lx2160a-pcie", },
-	{ },
-};
-
-static struct platform_driver ls_g4_pcie_driver = {
-	.driver = {
-		.name = "layerscape-pcie-gen4",
-		.of_match_table = ls_g4_pcie_of_match,
-		.suppress_bind_attrs = true,
-	},
-};
-
-builtin_platform_driver_probe(ls_g4_pcie_driver, ls_g4_pcie_probe);

-- 
2.34.1

Re: [PATCH 3/4] PCI: mobiveil: Drop layerscape-gen4 support

[Bjorn Helgaas]

On Thu, Aug 08, 2024 at 12:02:16PM -0400, Frank Li wrote:
> Only lx2160 rev1 use mobiveil PCIe controller. Rev2 switch to designware
> PCIe controller. Rev2 is mass production chip and Rev1 will be not
> supported. So drop related code.

I'd love to drop this, but only if you're confident that no Rev 1
controllers are in the field with people using them.  The explanation
above doesn't go quite that far.  It's not enough that Mobiveil
doesn't want to support Rev 1.  If we know that all Rev 1 controllers
have been destroyed, that would be perfect and useful to include here.

Bjorn

Re: [PATCH 3/4] PCI: mobiveil: Drop layerscape-gen4 support

[Frank Li]

On Thu, Aug 08, 2024 at 12:26:44PM -0500, Bjorn Helgaas wrote:
> On Thu, Aug 08, 2024 at 12:02:16PM -0400, Frank Li wrote:
> > Only lx2160 rev1 use mobiveil PCIe controller. Rev2 switch to designware
> > PCIe controller. Rev2 is mass production chip and Rev1 will be not
> > supported. So drop related code.
>
> I'd love to drop this, but only if you're confident that no Rev 1
> controllers are in the field with people using them.  The explanation
> above doesn't go quite that far.  It's not enough that Mobiveil
> doesn't want to support Rev 1.  If we know that all Rev 1 controllers
> have been destroyed, that would be perfect and useful to include here.

I can't guarrantee all Rev1 have been destroyed because some may left on
someone's drawer or lab. How about drop all document firstly,

and set kConfig

bool "Freescale Layerscape Gen4 PCIe controller (DEPRECATE)" if COMPILE_TEST

So layerscape gen4 will not built. Sometime later, if no one complain, we
can remove all safely.

Frank


>
> Bjorn

Re: [PATCH 3/4] PCI: mobiveil: Drop layerscape-gen4 support

[Krzysztof Kozlowski]

On 08/08/2024 20:08, Frank Li wrote:
> On Thu, Aug 08, 2024 at 12:26:44PM -0500, Bjorn Helgaas wrote:
>> On Thu, Aug 08, 2024 at 12:02:16PM -0400, Frank Li wrote:
>>> Only lx2160 rev1 use mobiveil PCIe controller. Rev2 switch to designware
>>> PCIe controller. Rev2 is mass production chip and Rev1 will be not
>>> supported. So drop related code.
>>
>> I'd love to drop this, but only if you're confident that no Rev 1
>> controllers are in the field with people using them.  The explanation
>> above doesn't go quite that far.  It's not enough that Mobiveil
>> doesn't want to support Rev 1.  If we know that all Rev 1 controllers
>> have been destroyed, that would be perfect and useful to include here.
> 
> I can't guarrantee all Rev1 have been destroyed because some may left on
> someone's drawer or lab. How about drop all document firstly,

No, documents are LAST things which are being dropped.

Best regards,
Krzysztof

[PATCH 4/4] MAINTAINERS: drop NXP LAYERSCAPE GEN4 CONTROLLER

[Frank Li]

LX2160 Rev1 use mobivel PCIe controller, but Rev2 switch to designware
PCIe controller. Rev2 is mass production chip. Rev1 will not be maintained
so drop maintainer information for that.

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
 MAINTAINERS | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1e71f97fb6749..9b683899cd088 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17556,14 +17556,6 @@ S:	Supported
 F:	Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
 F:	drivers/pci/controller/pci-tegra.c
 
-PCI DRIVER FOR NXP LAYERSCAPE GEN4 CONTROLLER
-M:	Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
-L:	linux-pci@vger.kernel.org
-L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S:	Maintained
-F:	Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
-F:	drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
-
 PCI DRIVER FOR PLDA PCIE IP
 M:	Daire McNamara <daire.mcnamara@microchip.com>
 L:	linux-pci@vger.kernel.org

-- 
2.34.1

Re: [PATCH 4/4] MAINTAINERS: drop NXP LAYERSCAPE GEN4 CONTROLLER

[Krzysztof Kozlowski]

On 08/08/2024 18:02, Frank Li wrote:
> LX2160 Rev1 use mobivel PCIe controller, but Rev2 switch to designware
> PCIe controller. Rev2 is mass production chip. Rev1 will not be maintained
> so drop maintainer information for that.
> 
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
>  MAINTAINERS | 8 --------
>  1 file changed, 8 deletions(-)

This should not be separate commit. There is no single point in that.
The moment you remove driver, the entry becomes pointless, so should be
removed THE SAME time.

Best regards,
Krzysztof

Re: [PATCH 4/4] MAINTAINERS: drop NXP LAYERSCAPE GEN4 CONTROLLER

[Manivannan Sadhasivam]

On Thu, Aug 08, 2024 at 12:02:17PM -0400, Frank Li wrote:
> LX2160 Rev1 use mobivel PCIe controller, but Rev2 switch to designware
> PCIe controller. Rev2 is mass production chip. Rev1 will not be maintained
> so drop maintainer information for that.
> 

Instead of suddenly removing the code and breaking users, you can just mark the
driver as 'Obsolete' in MAINTAINERS. Then after some point of time, we could
hopefully remove.

- Mani

> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
>  MAINTAINERS | 8 --------
>  1 file changed, 8 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1e71f97fb6749..9b683899cd088 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17556,14 +17556,6 @@ S:	Supported
>  F:	Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
>  F:	drivers/pci/controller/pci-tegra.c
>  
> -PCI DRIVER FOR NXP LAYERSCAPE GEN4 CONTROLLER
> -M:	Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> -L:	linux-pci@vger.kernel.org
> -L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> -S:	Maintained
> -F:	Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
> -F:	drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
> -
>  PCI DRIVER FOR PLDA PCIE IP
>  M:	Daire McNamara <daire.mcnamara@microchip.com>
>  L:	linux-pci@vger.kernel.org
> 
> -- 
> 2.34.1
> 
> 

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH 4/4] MAINTAINERS: drop NXP LAYERSCAPE GEN4 CONTROLLER

[Rob Herring]

On Thu, Aug 15, 2024 at 9:53 AM Manivannan Sadhasivam
<manivannan.sadhasivam@linaro.org> wrote:
>
> On Thu, Aug 08, 2024 at 12:02:17PM -0400, Frank Li wrote:
> > LX2160 Rev1 use mobivel PCIe controller, but Rev2 switch to designware
> > PCIe controller. Rev2 is mass production chip. Rev1 will not be maintained
> > so drop maintainer information for that.
> >
>
> Instead of suddenly removing the code and breaking users, you can just mark the
> driver as 'Obsolete' in MAINTAINERS. Then after some point of time, we could
> hopefully remove.

Is anyone really going to pay attention to that? It doesn't sound like
there's anyone to really care, and it is the company that made the h/w
asking to remove it. The only thing people use pre-production h/w for
once there's production h/w is as a dust collector.

If anyone complains, it's simple enough to revert these patches.

Rob

Re: [PATCH 4/4] MAINTAINERS: drop NXP LAYERSCAPE GEN4 CONTROLLER

[Manivannan Sadhasivam]

On Thu, Aug 15, 2024 at 03:15:52PM -0600, Rob Herring wrote:
> On Thu, Aug 15, 2024 at 9:53 AM Manivannan Sadhasivam
> <manivannan.sadhasivam@linaro.org> wrote:
> >
> > On Thu, Aug 08, 2024 at 12:02:17PM -0400, Frank Li wrote:
> > > LX2160 Rev1 use mobivel PCIe controller, but Rev2 switch to designware
> > > PCIe controller. Rev2 is mass production chip. Rev1 will not be maintained
> > > so drop maintainer information for that.
> > >
> >
> > Instead of suddenly removing the code and breaking users, you can just mark the
> > driver as 'Obsolete' in MAINTAINERS. Then after some point of time, we could
> > hopefully remove.
> 
> Is anyone really going to pay attention to that? It doesn't sound like
> there's anyone to really care, and it is the company that made the h/w
> asking to remove it. The only thing people use pre-production h/w for
> once there's production h/w is as a dust collector.
> 
> If anyone complains, it's simple enough to revert these patches.
> 

My comment was based on the fact that Bjorn was not comfortable in removing the
driver [1] unless no Rev1 boards are not in use and Frank said that he was not
sure about that [2].

But I think if Frank can atleast guarantee that the chip never made into mass
production or shared with customers, then we can remove the driver IMO. But that
is up to the discretion of Bjorn.

- Mani

[1] https://lore.kernel.org/linux-pci/20240808172644.GA151261@bhelgaas/
[2] https://lore.kernel.org/linux-pci/ZrUJngABI8v3pN6o@lizhi-Precision-Tower-5810/

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH 4/4] MAINTAINERS: drop NXP LAYERSCAPE GEN4 CONTROLLER

[Frank Li]

On Fri, Aug 16, 2024 at 11:12:31AM +0530, Manivannan Sadhasivam wrote:
> On Thu, Aug 15, 2024 at 03:15:52PM -0600, Rob Herring wrote:
> > On Thu, Aug 15, 2024 at 9:53 AM Manivannan Sadhasivam
> > <manivannan.sadhasivam@linaro.org> wrote:
> > >
> > > On Thu, Aug 08, 2024 at 12:02:17PM -0400, Frank Li wrote:
> > > > LX2160 Rev1 use mobivel PCIe controller, but Rev2 switch to designware
> > > > PCIe controller. Rev2 is mass production chip. Rev1 will not be maintained
> > > > so drop maintainer information for that.
> > > >
> > >
> > > Instead of suddenly removing the code and breaking users, you can just mark the
> > > driver as 'Obsolete' in MAINTAINERS. Then after some point of time, we could
> > > hopefully remove.
> >
> > Is anyone really going to pay attention to that? It doesn't sound like
> > there's anyone to really care, and it is the company that made the h/w
> > asking to remove it. The only thing people use pre-production h/w for
> > once there's production h/w is as a dust collector.
> >
> > If anyone complains, it's simple enough to revert these patches.
> >
>
> My comment was based on the fact that Bjorn was not comfortable in removing the
> driver [1] unless no Rev1 boards are not in use and Frank said that he was not
> sure about that [2].
>
> But I think if Frank can atleast guarantee that the chip never made into mass
> production or shared with customers, then we can remove the driver IMO. But that
> is up to the discretion of Bjorn.
>

I think Bjoin's request is impossible task. Generally chip company send
out some evaluted sample to parter, which use these sample to built up
some small quantity production. Chip company have not responsibility to
call back this samples. There are always some reasons to drop mobivel and
switch designware, it may be caused by some IP issues which can't match
mass production's requirememnt. Such informaiton already removed from
nxp.com. Only Rev2 left.

Leave such dead code in pci tree actually no harm for me, and clean up need
extra efforts.

I send out v2, which don't build gen4 driver default. It may a feasibility
way to do clean up. If no one complain for a while, it should be dead.

https://lore.kernel.org/imx/20240815182420.58821-1-Frank.Li@nxp.com/T/#u

Frank

> - Mani
>
> [1] https://lore.kernel.org/linux-pci/20240808172644.GA151261@bhelgaas/
> [2] https://lore.kernel.org/linux-pci/ZrUJngABI8v3pN6o@lizhi-Precision-Tower-5810/
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்

Re: [PATCH 4/4] MAINTAINERS: drop NXP LAYERSCAPE GEN4 CONTROLLER

[Bjorn Helgaas]

On Fri, Aug 16, 2024 at 01:09:50PM -0400, Frank Li wrote:
> On Fri, Aug 16, 2024 at 11:12:31AM +0530, Manivannan Sadhasivam wrote:
> > On Thu, Aug 15, 2024 at 03:15:52PM -0600, Rob Herring wrote:
> > > On Thu, Aug 15, 2024 at 9:53 AM Manivannan Sadhasivam
> > > <manivannan.sadhasivam@linaro.org> wrote:
> > > > On Thu, Aug 08, 2024 at 12:02:17PM -0400, Frank Li wrote:
> > > > > LX2160 Rev1 use mobivel PCIe controller, but Rev2 switch to designware
> > > > > PCIe controller. Rev2 is mass production chip. Rev1 will not be maintained
> > > > > so drop maintainer information for that.
> > > >
> > > > Instead of suddenly removing the code and breaking users, you can just mark the
> > > > driver as 'Obsolete' in MAINTAINERS. Then after some point of time, we could
> > > > hopefully remove.
> > >
> > > Is anyone really going to pay attention to that? It doesn't sound like
> > > there's anyone to really care, and it is the company that made the h/w
> > > asking to remove it. The only thing people use pre-production h/w for
> > > once there's production h/w is as a dust collector.
> > >
> > > If anyone complains, it's simple enough to revert these patches.
> >
> > My comment was based on the fact that Bjorn was not comfortable in removing the
> > driver [1] unless no Rev1 boards are not in use and Frank said that he was not
> > sure about that [2].
> >
> > But I think if Frank can atleast guarantee that the chip never made into mass
> > production or shared with customers, then we can remove the driver IMO. But that
> > is up to the discretion of Bjorn.
> 
> I think Bjorn's request is impossible task. Generally chip company send
> out some evaluted sample to parter, which use these sample to built up
> some small quantity production. Chip company have not responsibility to
> call back this samples. There are always some reasons to drop mobivel and
> switch designware, it may be caused by some IP issues which can't match
> mass production's requirememnt. Such informaiton already removed from
> nxp.com. Only Rev2 left.

If you're reasonably confident that nobody will notice the removal of
support for Rev1, we can include that in the commit log and just
remove it.

The original commit log basically said "we don't want to support Rev1"
without any indication of where those parts went or whether anybody
might care about them.  But if Rev1 only went to partners for
evaluation and we don't expect end users to have them, I think it's
reasonable to say that and remove the code.

Bjorn

Re: [PATCH 4/4] MAINTAINERS: drop NXP LAYERSCAPE GEN4 CONTROLLER

[Frank Li]

On Fri, Aug 16, 2024 at 01:15:00PM -0500, Bjorn Helgaas wrote:
> On Fri, Aug 16, 2024 at 01:09:50PM -0400, Frank Li wrote:
> > On Fri, Aug 16, 2024 at 11:12:31AM +0530, Manivannan Sadhasivam wrote:
> > > On Thu, Aug 15, 2024 at 03:15:52PM -0600, Rob Herring wrote:
> > > > On Thu, Aug 15, 2024 at 9:53 AM Manivannan Sadhasivam
> > > > <manivannan.sadhasivam@linaro.org> wrote:
> > > > > On Thu, Aug 08, 2024 at 12:02:17PM -0400, Frank Li wrote:
> > > > > > LX2160 Rev1 use mobivel PCIe controller, but Rev2 switch to designware
> > > > > > PCIe controller. Rev2 is mass production chip. Rev1 will not be maintained
> > > > > > so drop maintainer information for that.
> > > > >
> > > > > Instead of suddenly removing the code and breaking users, you can just mark the
> > > > > driver as 'Obsolete' in MAINTAINERS. Then after some point of time, we could
> > > > > hopefully remove.
> > > >
> > > > Is anyone really going to pay attention to that? It doesn't sound like
> > > > there's anyone to really care, and it is the company that made the h/w
> > > > asking to remove it. The only thing people use pre-production h/w for
> > > > once there's production h/w is as a dust collector.
> > > >
> > > > If anyone complains, it's simple enough to revert these patches.
> > >
> > > My comment was based on the fact that Bjorn was not comfortable in removing the
> > > driver [1] unless no Rev1 boards are not in use and Frank said that he was not
> > > sure about that [2].
> > >
> > > But I think if Frank can atleast guarantee that the chip never made into mass
> > > production or shared with customers, then we can remove the driver IMO. But that
> > > is up to the discretion of Bjorn.
> >
> > I think Bjorn's request is impossible task. Generally chip company send
> > out some evaluted sample to parter, which use these sample to built up
> > some small quantity production. Chip company have not responsibility to
> > call back this samples. There are always some reasons to drop mobivel and
> > switch designware, it may be caused by some IP issues which can't match
> > mass production's requirememnt. Such informaiton already removed from
> > nxp.com. Only Rev2 left.
>
> If you're reasonably confident that nobody will notice the removal of
> support for Rev1, we can include that in the commit log and just
> remove it.
>
> The original commit log basically said "we don't want to support Rev1"
> without any indication of where those parts went or whether anybody
> might care about them.  But if Rev1 only went to partners for
> evaluation and we don't expect end users to have them, I think it's
> reasonable to say that and remove the code.

Thanks, I just find 2020 Yang li try to drop dts part in below thread:

https://lore.kernel.org/all/CAOesGMhz8PYNG_bgMX-6gka77k1hJOZUv6xqJRqATaJ6mFbk6A@mail.gmail.com/

Olof Johansson raise concern about their HoneyComb.

I added Olof Johansson in this thread. I think HoneyComb use evaluation
chip to build some small quaitity boards.

As my best knowledge, rev1 should have some big problem. I can't find any
detail about these because rev1 informaion already cleanup totally. I don't
prefer continue use risking rev1 chip.

Frank

>
> Bjorn

Re: [PATCH 4/4] MAINTAINERS: drop NXP LAYERSCAPE GEN4 CONTROLLER

[Olof Johansson]

On Fri, Aug 16, 2024 at 12:17 PM Frank Li <Frank.li@nxp.com> wrote:
>
> On Fri, Aug 16, 2024 at 01:15:00PM -0500, Bjorn Helgaas wrote:
> > On Fri, Aug 16, 2024 at 01:09:50PM -0400, Frank Li wrote:
> > > On Fri, Aug 16, 2024 at 11:12:31AM +0530, Manivannan Sadhasivam wrote:
> > > > On Thu, Aug 15, 2024 at 03:15:52PM -0600, Rob Herring wrote:
> > > > > On Thu, Aug 15, 2024 at 9:53 AM Manivannan Sadhasivam
> > > > > <manivannan.sadhasivam@linaro.org> wrote:
> > > > > > On Thu, Aug 08, 2024 at 12:02:17PM -0400, Frank Li wrote:
> > > > > > > LX2160 Rev1 use mobivel PCIe controller, but Rev2 switch to designware
> > > > > > > PCIe controller. Rev2 is mass production chip. Rev1 will not be maintained
> > > > > > > so drop maintainer information for that.
> > > > > >
> > > > > > Instead of suddenly removing the code and breaking users, you can just mark the
> > > > > > driver as 'Obsolete' in MAINTAINERS. Then after some point of time, we could
> > > > > > hopefully remove.
> > > > >
> > > > > Is anyone really going to pay attention to that? It doesn't sound like
> > > > > there's anyone to really care, and it is the company that made the h/w
> > > > > asking to remove it. The only thing people use pre-production h/w for
> > > > > once there's production h/w is as a dust collector.
> > > > >
> > > > > If anyone complains, it's simple enough to revert these patches.
> > > >
> > > > My comment was based on the fact that Bjorn was not comfortable in removing the
> > > > driver [1] unless no Rev1 boards are not in use and Frank said that he was not
> > > > sure about that [2].
> > > >
> > > > But I think if Frank can atleast guarantee that the chip never made into mass
> > > > production or shared with customers, then we can remove the driver IMO. But that
> > > > is up to the discretion of Bjorn.
> > >
> > > I think Bjorn's request is impossible task. Generally chip company send
> > > out some evaluted sample to parter, which use these sample to built up
> > > some small quantity production. Chip company have not responsibility to
> > > call back this samples. There are always some reasons to drop mobivel and
> > > switch designware, it may be caused by some IP issues which can't match
> > > mass production's requirememnt. Such informaiton already removed from
> > > nxp.com. Only Rev2 left.
> >
> > If you're reasonably confident that nobody will notice the removal of
> > support for Rev1, we can include that in the commit log and just
> > remove it.
> >
> > The original commit log basically said "we don't want to support Rev1"
> > without any indication of where those parts went or whether anybody
> > might care about them.  But if Rev1 only went to partners for
> > evaluation and we don't expect end users to have them, I think it's
> > reasonable to say that and remove the code.
>
> Thanks, I just find 2020 Yang li try to drop dts part in below thread:
>
> https://lore.kernel.org/all/CAOesGMhz8PYNG_bgMX-6gka77k1hJOZUv6xqJRqATaJ6mFbk6A@mail.gmail.com/
>
> Olof Johansson raise concern about their HoneyComb.
>
> I added Olof Johansson in this thread. I think HoneyComb use evaluation
> chip to build some small quaitity boards.
>
> As my best knowledge, rev1 should have some big problem. I can't find any
> detail about these because rev1 informaion already cleanup totally. I don't
> prefer continue use risking rev1 chip.

I paid good money for my HoneyComb, and while it was an early system,
I certainly wouldn't expect it to stop working because some maintainer
is bored of supporting it. It's clearly been commercially sold as
systems.

Mind you, I can't remember last time I powered on my system any more,
since I mostly use the Ampere board or VMs on my Mac for ARM linux
work when needed, but that doesn't mean I want to send off the
HoneyComb to recycling.

Don't regress your users. Thanks.


-Olof