From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Frank Li <Frank.Li@nxp.com>
Cc: bhelgaas@google.com, imx@lists.linux.dev, kw@linux.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, lpieralisi@kernel.org,
minghuan.Lian@nxp.com, mingkai.hu@nxp.com, robh@kernel.org,
roy.zang@nxp.com
Subject: Re: [PATCH v3 2/4] PCI: layerscape: Add suspend/resume for ls1021a
Date: Thu, 2 Nov 2023 22:58:09 +0530 [thread overview]
Message-ID: <20231102172809.GD20943@thinkpad> (raw)
In-Reply-To: <20231017193145.3198380-3-Frank.Li@nxp.com>
On Tue, Oct 17, 2023 at 03:31:43PM -0400, Frank Li wrote:
> ls1021a add suspend/resume support.
>
> Implement callback ls1021a_pcie_send_turnoff_msg(), which write scfg's
> SCFG_PEXPMWRCR to issue PME_Turn_off message.
>
> Implement ls1021a_pcie_exit_from_l2() to let controller exit L2 state.
>
I'd like to reword it to better reflect what the patch does:
"In the suspend path, PME_Turn_Off message is sent to the endpoint to transition
the link to L2/L3_Ready state. In this SoC, there is no way to check if the
controller has received the PME_To_Ack from the endpoint or not. So to be on the
safer side, the driver just waits for PCIE_PME_TO_L2_TIMEOUT_US before asserting
the SoC specific PMXMTTURNOFF bit to complete the PME_Turn_Off handshake. This
link would then enter L2/L3 state depending on the VAUX supply.
In the resume path, the link is brought back from L2 to L0 by doing a software
reset."
Although I do have questions on the resume behavior below.
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
>
> Notes:
> Change from v2 to v3
> - update according to mani's feedback
> change from v1 to v2
> - change subject 'a' to 'A'
>
> drivers/pci/controller/dwc/pci-layerscape.c | 86 ++++++++++++++++++++-
> 1 file changed, 85 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
> index aea89926bcc4f..6f47cfe146c44 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape.c
> @@ -35,11 +35,21 @@
> #define PF_MCR_PTOMR BIT(0)
> #define PF_MCR_EXL2S BIT(1)
>
> +/* LS1021A PEXn PM Write Control Register */
> +#define SCFG_PEXPMWRCR(idx) (0x5c + (idx) * 0x64)
> +#define PMXMTTURNOFF BIT(31)
> +#define SCFG_PEXSFTRSTCR 0x190
> +#define PEXSR(idx) BIT(idx)
> +
> #define PCIE_IATU_NUM 6
>
> +#define LS_PCIE_DRV_SCFG BIT(0)
> +
> struct ls_pcie_drvdata {
> const u32 pf_off;
> + const struct dw_pcie_host_ops *ops;
> int (*exit_from_l2)(struct dw_pcie_rp *pp);
> + int flags;
Why not "bool scfg_support"?
> bool pm_support;
> };
>
> @@ -47,6 +57,8 @@ struct ls_pcie {
> struct dw_pcie *pci;
> const struct ls_pcie_drvdata *drvdata;
> void __iomem *pf_base;
> + struct regmap *scfg;
> + int index;
> bool big_endian;
> };
>
> @@ -171,13 +183,65 @@ static int ls_pcie_host_init(struct dw_pcie_rp *pp)
> return 0;
> }
>
> +static void ls1021a_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct ls_pcie *pcie = to_ls_pcie(pci);
> + u32 val;
> +
> + /* Send PME_Turn_Off message */
> + regmap_read(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), &val);
> + val |= PMXMTTURNOFF;
> + regmap_write(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), val);
> +
> + /*
> + * There is no specific register to check for PME_To_Ack from endpoint.
> + * So on the safe side, wait for PCIE_PME_TO_L2_TIMEOUT_US.
> + */
> + mdelay(PCIE_PME_TO_L2_TIMEOUT_US/1000);
> +
> + /*
> + * Layerscape hardware reference manual recommends clearing the PMXMTTURNOFF bit
> + * to complete the PME_Turn_Off handshake.
> + */
> + regmap_read(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), &val);
> + val &= ~PMXMTTURNOFF;
> + regmap_write(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), val);
> +}
> +
> +static int ls1021a_pcie_exit_from_l2(struct dw_pcie_rp *pp)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct ls_pcie *pcie = to_ls_pcie(pci);
> + u32 val;
> +
> + /* Only way exit from l2 is that do software reset */
So, what does exactly "software reset" mean? Are you resetting the endpoint or
some specific registers/blocks in the controller?
Also, what if the link goes to L3 in the case of no VAUX?
> + regmap_read(pcie->scfg, SCFG_PEXSFTRSTCR, &val);
> + val |= PEXSR(pcie->index);
> + regmap_write(pcie->scfg, SCFG_PEXSFTRSTCR, val);
> +
> + regmap_read(pcie->scfg, SCFG_PEXSFTRSTCR, &val);
> + val &= ~PEXSR(pcie->index);
> + regmap_write(pcie->scfg, SCFG_PEXSFTRSTCR, val);
> +
> + return 0;
> +}
> +
> static const struct dw_pcie_host_ops ls_pcie_host_ops = {
> .host_init = ls_pcie_host_init,
> .pme_turn_off = ls_pcie_send_turnoff_msg,
> };
>
> +static const struct dw_pcie_host_ops ls1021a_pcie_host_ops = {
> + .host_init = ls_pcie_host_init,
> + .pme_turn_off = ls1021a_pcie_send_turnoff_msg,
> +};
> +
> static const struct ls_pcie_drvdata ls1021a_drvdata = {
> - .pm_support = false,
> + .pm_support = true,
> + .ops = &ls1021a_pcie_host_ops,
> + .exit_from_l2 = ls1021a_pcie_exit_from_l2,
> + .flags = LS_PCIE_DRV_SCFG,
> };
>
> static const struct ls_pcie_drvdata layerscape_drvdata = {
> @@ -205,6 +269,8 @@ static int ls_pcie_probe(struct platform_device *pdev)
> struct dw_pcie *pci;
> struct ls_pcie *pcie;
> struct resource *dbi_base;
> + u32 index[2];
> + int ret;
>
> pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
> if (!pcie)
> @@ -220,6 +286,7 @@ static int ls_pcie_probe(struct platform_device *pdev)
> pci->pp.ops = &ls_pcie_host_ops;
>
> pcie->pci = pci;
> + pci->pp.ops = pcie->drvdata->ops ? pcie->drvdata->ops : &ls_pcie_host_ops;
>
> dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> @@ -230,6 +297,23 @@ static int ls_pcie_probe(struct platform_device *pdev)
>
> pcie->pf_base = pci->dbi_base + pcie->drvdata->pf_off;
>
> + if (pcie->drvdata->flags & LS_PCIE_DRV_SCFG) {
> +
Remove extra newline.
- Mani
--
மணிவண்ணன் சதாசிவம்
WARNING: multiple messages have this Message-ID (diff)
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Frank Li <Frank.Li@nxp.com>
Cc: imx@lists.linux.dev, kw@linux.com, linux-pci@vger.kernel.org,
lpieralisi@kernel.org, linux-kernel@vger.kernel.org,
minghuan.Lian@nxp.com, mingkai.hu@nxp.com, roy.zang@nxp.com,
bhelgaas@google.com, linuxppc-dev@lists.ozlabs.org,
robh@kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 2/4] PCI: layerscape: Add suspend/resume for ls1021a
Date: Thu, 2 Nov 2023 22:58:09 +0530 [thread overview]
Message-ID: <20231102172809.GD20943@thinkpad> (raw)
In-Reply-To: <20231017193145.3198380-3-Frank.Li@nxp.com>
On Tue, Oct 17, 2023 at 03:31:43PM -0400, Frank Li wrote:
> ls1021a add suspend/resume support.
>
> Implement callback ls1021a_pcie_send_turnoff_msg(), which write scfg's
> SCFG_PEXPMWRCR to issue PME_Turn_off message.
>
> Implement ls1021a_pcie_exit_from_l2() to let controller exit L2 state.
>
I'd like to reword it to better reflect what the patch does:
"In the suspend path, PME_Turn_Off message is sent to the endpoint to transition
the link to L2/L3_Ready state. In this SoC, there is no way to check if the
controller has received the PME_To_Ack from the endpoint or not. So to be on the
safer side, the driver just waits for PCIE_PME_TO_L2_TIMEOUT_US before asserting
the SoC specific PMXMTTURNOFF bit to complete the PME_Turn_Off handshake. This
link would then enter L2/L3 state depending on the VAUX supply.
In the resume path, the link is brought back from L2 to L0 by doing a software
reset."
Although I do have questions on the resume behavior below.
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
>
> Notes:
> Change from v2 to v3
> - update according to mani's feedback
> change from v1 to v2
> - change subject 'a' to 'A'
>
> drivers/pci/controller/dwc/pci-layerscape.c | 86 ++++++++++++++++++++-
> 1 file changed, 85 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
> index aea89926bcc4f..6f47cfe146c44 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape.c
> @@ -35,11 +35,21 @@
> #define PF_MCR_PTOMR BIT(0)
> #define PF_MCR_EXL2S BIT(1)
>
> +/* LS1021A PEXn PM Write Control Register */
> +#define SCFG_PEXPMWRCR(idx) (0x5c + (idx) * 0x64)
> +#define PMXMTTURNOFF BIT(31)
> +#define SCFG_PEXSFTRSTCR 0x190
> +#define PEXSR(idx) BIT(idx)
> +
> #define PCIE_IATU_NUM 6
>
> +#define LS_PCIE_DRV_SCFG BIT(0)
> +
> struct ls_pcie_drvdata {
> const u32 pf_off;
> + const struct dw_pcie_host_ops *ops;
> int (*exit_from_l2)(struct dw_pcie_rp *pp);
> + int flags;
Why not "bool scfg_support"?
> bool pm_support;
> };
>
> @@ -47,6 +57,8 @@ struct ls_pcie {
> struct dw_pcie *pci;
> const struct ls_pcie_drvdata *drvdata;
> void __iomem *pf_base;
> + struct regmap *scfg;
> + int index;
> bool big_endian;
> };
>
> @@ -171,13 +183,65 @@ static int ls_pcie_host_init(struct dw_pcie_rp *pp)
> return 0;
> }
>
> +static void ls1021a_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct ls_pcie *pcie = to_ls_pcie(pci);
> + u32 val;
> +
> + /* Send PME_Turn_Off message */
> + regmap_read(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), &val);
> + val |= PMXMTTURNOFF;
> + regmap_write(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), val);
> +
> + /*
> + * There is no specific register to check for PME_To_Ack from endpoint.
> + * So on the safe side, wait for PCIE_PME_TO_L2_TIMEOUT_US.
> + */
> + mdelay(PCIE_PME_TO_L2_TIMEOUT_US/1000);
> +
> + /*
> + * Layerscape hardware reference manual recommends clearing the PMXMTTURNOFF bit
> + * to complete the PME_Turn_Off handshake.
> + */
> + regmap_read(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), &val);
> + val &= ~PMXMTTURNOFF;
> + regmap_write(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), val);
> +}
> +
> +static int ls1021a_pcie_exit_from_l2(struct dw_pcie_rp *pp)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct ls_pcie *pcie = to_ls_pcie(pci);
> + u32 val;
> +
> + /* Only way exit from l2 is that do software reset */
So, what does exactly "software reset" mean? Are you resetting the endpoint or
some specific registers/blocks in the controller?
Also, what if the link goes to L3 in the case of no VAUX?
> + regmap_read(pcie->scfg, SCFG_PEXSFTRSTCR, &val);
> + val |= PEXSR(pcie->index);
> + regmap_write(pcie->scfg, SCFG_PEXSFTRSTCR, val);
> +
> + regmap_read(pcie->scfg, SCFG_PEXSFTRSTCR, &val);
> + val &= ~PEXSR(pcie->index);
> + regmap_write(pcie->scfg, SCFG_PEXSFTRSTCR, val);
> +
> + return 0;
> +}
> +
> static const struct dw_pcie_host_ops ls_pcie_host_ops = {
> .host_init = ls_pcie_host_init,
> .pme_turn_off = ls_pcie_send_turnoff_msg,
> };
>
> +static const struct dw_pcie_host_ops ls1021a_pcie_host_ops = {
> + .host_init = ls_pcie_host_init,
> + .pme_turn_off = ls1021a_pcie_send_turnoff_msg,
> +};
> +
> static const struct ls_pcie_drvdata ls1021a_drvdata = {
> - .pm_support = false,
> + .pm_support = true,
> + .ops = &ls1021a_pcie_host_ops,
> + .exit_from_l2 = ls1021a_pcie_exit_from_l2,
> + .flags = LS_PCIE_DRV_SCFG,
> };
>
> static const struct ls_pcie_drvdata layerscape_drvdata = {
> @@ -205,6 +269,8 @@ static int ls_pcie_probe(struct platform_device *pdev)
> struct dw_pcie *pci;
> struct ls_pcie *pcie;
> struct resource *dbi_base;
> + u32 index[2];
> + int ret;
>
> pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
> if (!pcie)
> @@ -220,6 +286,7 @@ static int ls_pcie_probe(struct platform_device *pdev)
> pci->pp.ops = &ls_pcie_host_ops;
>
> pcie->pci = pci;
> + pci->pp.ops = pcie->drvdata->ops ? pcie->drvdata->ops : &ls_pcie_host_ops;
>
> dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> @@ -230,6 +297,23 @@ static int ls_pcie_probe(struct platform_device *pdev)
>
> pcie->pf_base = pci->dbi_base + pcie->drvdata->pf_off;
>
> + if (pcie->drvdata->flags & LS_PCIE_DRV_SCFG) {
> +
Remove extra newline.
- Mani
--
மணிவண்ணன் சதாசிவம்
WARNING: multiple messages have this Message-ID (diff)
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Frank Li <Frank.Li@nxp.com>
Cc: bhelgaas@google.com, imx@lists.linux.dev, kw@linux.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, lpieralisi@kernel.org,
minghuan.Lian@nxp.com, mingkai.hu@nxp.com, robh@kernel.org,
roy.zang@nxp.com
Subject: Re: [PATCH v3 2/4] PCI: layerscape: Add suspend/resume for ls1021a
Date: Thu, 2 Nov 2023 22:58:09 +0530 [thread overview]
Message-ID: <20231102172809.GD20943@thinkpad> (raw)
In-Reply-To: <20231017193145.3198380-3-Frank.Li@nxp.com>
On Tue, Oct 17, 2023 at 03:31:43PM -0400, Frank Li wrote:
> ls1021a add suspend/resume support.
>
> Implement callback ls1021a_pcie_send_turnoff_msg(), which write scfg's
> SCFG_PEXPMWRCR to issue PME_Turn_off message.
>
> Implement ls1021a_pcie_exit_from_l2() to let controller exit L2 state.
>
I'd like to reword it to better reflect what the patch does:
"In the suspend path, PME_Turn_Off message is sent to the endpoint to transition
the link to L2/L3_Ready state. In this SoC, there is no way to check if the
controller has received the PME_To_Ack from the endpoint or not. So to be on the
safer side, the driver just waits for PCIE_PME_TO_L2_TIMEOUT_US before asserting
the SoC specific PMXMTTURNOFF bit to complete the PME_Turn_Off handshake. This
link would then enter L2/L3 state depending on the VAUX supply.
In the resume path, the link is brought back from L2 to L0 by doing a software
reset."
Although I do have questions on the resume behavior below.
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
>
> Notes:
> Change from v2 to v3
> - update according to mani's feedback
> change from v1 to v2
> - change subject 'a' to 'A'
>
> drivers/pci/controller/dwc/pci-layerscape.c | 86 ++++++++++++++++++++-
> 1 file changed, 85 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
> index aea89926bcc4f..6f47cfe146c44 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape.c
> @@ -35,11 +35,21 @@
> #define PF_MCR_PTOMR BIT(0)
> #define PF_MCR_EXL2S BIT(1)
>
> +/* LS1021A PEXn PM Write Control Register */
> +#define SCFG_PEXPMWRCR(idx) (0x5c + (idx) * 0x64)
> +#define PMXMTTURNOFF BIT(31)
> +#define SCFG_PEXSFTRSTCR 0x190
> +#define PEXSR(idx) BIT(idx)
> +
> #define PCIE_IATU_NUM 6
>
> +#define LS_PCIE_DRV_SCFG BIT(0)
> +
> struct ls_pcie_drvdata {
> const u32 pf_off;
> + const struct dw_pcie_host_ops *ops;
> int (*exit_from_l2)(struct dw_pcie_rp *pp);
> + int flags;
Why not "bool scfg_support"?
> bool pm_support;
> };
>
> @@ -47,6 +57,8 @@ struct ls_pcie {
> struct dw_pcie *pci;
> const struct ls_pcie_drvdata *drvdata;
> void __iomem *pf_base;
> + struct regmap *scfg;
> + int index;
> bool big_endian;
> };
>
> @@ -171,13 +183,65 @@ static int ls_pcie_host_init(struct dw_pcie_rp *pp)
> return 0;
> }
>
> +static void ls1021a_pcie_send_turnoff_msg(struct dw_pcie_rp *pp)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct ls_pcie *pcie = to_ls_pcie(pci);
> + u32 val;
> +
> + /* Send PME_Turn_Off message */
> + regmap_read(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), &val);
> + val |= PMXMTTURNOFF;
> + regmap_write(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), val);
> +
> + /*
> + * There is no specific register to check for PME_To_Ack from endpoint.
> + * So on the safe side, wait for PCIE_PME_TO_L2_TIMEOUT_US.
> + */
> + mdelay(PCIE_PME_TO_L2_TIMEOUT_US/1000);
> +
> + /*
> + * Layerscape hardware reference manual recommends clearing the PMXMTTURNOFF bit
> + * to complete the PME_Turn_Off handshake.
> + */
> + regmap_read(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), &val);
> + val &= ~PMXMTTURNOFF;
> + regmap_write(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), val);
> +}
> +
> +static int ls1021a_pcie_exit_from_l2(struct dw_pcie_rp *pp)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct ls_pcie *pcie = to_ls_pcie(pci);
> + u32 val;
> +
> + /* Only way exit from l2 is that do software reset */
So, what does exactly "software reset" mean? Are you resetting the endpoint or
some specific registers/blocks in the controller?
Also, what if the link goes to L3 in the case of no VAUX?
> + regmap_read(pcie->scfg, SCFG_PEXSFTRSTCR, &val);
> + val |= PEXSR(pcie->index);
> + regmap_write(pcie->scfg, SCFG_PEXSFTRSTCR, val);
> +
> + regmap_read(pcie->scfg, SCFG_PEXSFTRSTCR, &val);
> + val &= ~PEXSR(pcie->index);
> + regmap_write(pcie->scfg, SCFG_PEXSFTRSTCR, val);
> +
> + return 0;
> +}
> +
> static const struct dw_pcie_host_ops ls_pcie_host_ops = {
> .host_init = ls_pcie_host_init,
> .pme_turn_off = ls_pcie_send_turnoff_msg,
> };
>
> +static const struct dw_pcie_host_ops ls1021a_pcie_host_ops = {
> + .host_init = ls_pcie_host_init,
> + .pme_turn_off = ls1021a_pcie_send_turnoff_msg,
> +};
> +
> static const struct ls_pcie_drvdata ls1021a_drvdata = {
> - .pm_support = false,
> + .pm_support = true,
> + .ops = &ls1021a_pcie_host_ops,
> + .exit_from_l2 = ls1021a_pcie_exit_from_l2,
> + .flags = LS_PCIE_DRV_SCFG,
> };
>
> static const struct ls_pcie_drvdata layerscape_drvdata = {
> @@ -205,6 +269,8 @@ static int ls_pcie_probe(struct platform_device *pdev)
> struct dw_pcie *pci;
> struct ls_pcie *pcie;
> struct resource *dbi_base;
> + u32 index[2];
> + int ret;
>
> pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
> if (!pcie)
> @@ -220,6 +286,7 @@ static int ls_pcie_probe(struct platform_device *pdev)
> pci->pp.ops = &ls_pcie_host_ops;
>
> pcie->pci = pci;
> + pci->pp.ops = pcie->drvdata->ops ? pcie->drvdata->ops : &ls_pcie_host_ops;
>
> dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> @@ -230,6 +297,23 @@ static int ls_pcie_probe(struct platform_device *pdev)
>
> pcie->pf_base = pci->dbi_base + pcie->drvdata->pf_off;
>
> + if (pcie->drvdata->flags & LS_PCIE_DRV_SCFG) {
> +
Remove extra newline.
- Mani
--
மணிவண்ணன் சதாசிவம்
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-11-02 17:28 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-17 19:31 [PATCH v3 0/4] PCI: layerscape: Add suspend/resume support for ls1043 and ls1021 Frank Li
2023-10-17 19:31 ` Frank Li
2023-10-17 19:31 ` Frank Li
2023-10-17 19:31 ` [PATCH v3 1/4] PCI: layerscape: Add function pointer for exit_from_l2() Frank Li
2023-10-17 19:31 ` Frank Li
2023-10-17 19:31 ` Frank Li
2023-11-02 16:58 ` Manivannan Sadhasivam
2023-11-02 16:58 ` Manivannan Sadhasivam
2023-11-02 16:58 ` Manivannan Sadhasivam
2023-11-02 18:01 ` Frank Li
2023-11-02 18:01 ` Frank Li
2023-11-02 18:01 ` Frank Li
2023-10-17 19:31 ` [PATCH v3 2/4] PCI: layerscape: Add suspend/resume for ls1021a Frank Li
2023-10-17 19:31 ` Frank Li
2023-10-17 19:31 ` Frank Li
2023-11-02 17:28 ` Manivannan Sadhasivam [this message]
2023-11-02 17:28 ` Manivannan Sadhasivam
2023-11-02 17:28 ` Manivannan Sadhasivam
2023-11-02 18:14 ` Frank Li
2023-11-02 18:14 ` Frank Li
2023-11-02 18:14 ` Frank Li
2023-10-17 19:31 ` [PATCH v3 3/4] PCI: layerscape: Rename pf_* as pf_lut_* Frank Li
2023-10-17 19:31 ` Frank Li
2023-10-17 19:31 ` Frank Li
2023-11-02 17:33 ` Manivannan Sadhasivam
2023-11-02 17:33 ` Manivannan Sadhasivam
2023-11-02 17:33 ` Manivannan Sadhasivam
2023-11-02 18:21 ` Frank Li
2023-11-02 18:21 ` Frank Li
2023-11-02 18:21 ` Frank Li
2023-10-17 19:31 ` [PATCH v3 4/4] PCI: layerscape: Add suspend/resume for ls1043a Frank Li
2023-10-17 19:31 ` Frank Li
2023-10-17 19:31 ` Frank Li
2023-11-02 17:39 ` Manivannan Sadhasivam
2023-11-02 17:39 ` Manivannan Sadhasivam
2023-11-02 17:39 ` Manivannan Sadhasivam
2023-11-02 18:29 ` Frank Li
2023-11-02 18:29 ` Frank Li
2023-11-02 18:29 ` Frank Li
2023-10-27 16:27 ` [PATCH v3 0/4] PCI: layerscape: Add suspend/resume support for ls1043 and ls1021 Frank Li
2023-10-27 16:27 ` Frank Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231102172809.GD20943@thinkpad \
--to=manivannan.sadhasivam@linaro.org \
--cc=Frank.Li@nxp.com \
--cc=bhelgaas@google.com \
--cc=imx@lists.linux.dev \
--cc=kw@linux.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lpieralisi@kernel.org \
--cc=minghuan.Lian@nxp.com \
--cc=mingkai.hu@nxp.com \
--cc=robh@kernel.org \
--cc=roy.zang@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.