Re: [PATCH v2 1/4] PCI: qcom-ep: Mark BAR0/BAR2 as 64bit BARs and BAR1/BAR3 as RESERVED

Manivannan Sadhasivam
2024-12-02T12:59:01Z

On Fri, Nov 29, 2024 at 01:55:37PM -0600, Bjorn Helgaas wrote:
> On Fri, Nov 29, 2024 at 02:54:12PM +0530, Manivannan Sadhasivam wrote:
> > On all Qcom endpoint SoCs, BAR0/BAR2 are 64bit BARs by default and software
> > cannot change the type. So mark the those BARs as 64bit BARs and also mark
> > the successive BAR1/BAR3 as RESERVED BARs so that the EPF drivers cannot
> > use them.
>
> "Default" implies an initial setting that can be changed, but you say
> "by default" and also "software cannot change the type." Can they be
> anything *other* than 64-bit BARs?
>
> If they're hardwired to be 64-bit BARs, I would just say that.
>
> > Cc: stable+noautosel@kernel.org # depends on patch introducing only_64bit flag
>
> If stable maintainers need to act on this, do they need to search for
> the patch introducing only_64bit flag? That seems onerous; is there a
> SHA1 that would make it easier?
>

But that's not the point of having noautosel tag, AFAIK.

Documentation/process/stable-kernel-rules.rst clearly says that this tag is to
be used when we do not want the stable team to backport the commit due to a
missing dependency.

If we really want stable team to backport the change with dependencies, then the
dependencies should be mentioned using the SHAs:

From Documentation/process/stable-kernel-rules.rst:

```
* Specify any additional patch prerequisites for cherry picking::

Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
Cc: <stable@vger.kernel.org> # 3.3.x
Signed-off-by: Ingo Molnar <mingo@elte.hu>

The tag sequence has the meaning of::

git cherry-pick a1f84a3
git cherry-pick 1b9508f
git cherry-pick fd21073
git cherry-pick <this commit>
```

Here I did not intend to backport this change with commit adding only_64bit flag
because, I'm not sure if that dependency alone would be sufficient. If someone
really cares about backporting this change, then they should figure out the
dependencies, test the functionality and then ask the stable team.

- Mani

> > Fixes: f55fee56a631 ("PCI: qcom-ep: Add Qualcomm PCIe Endpoint controller driver")
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > ---
> > drivers/pci/controller/dwc/pcie-qcom-ep.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-qcom-ep.c b/drivers/pci/controller/dwc/pcie-qcom-ep.c
> > index e588fcc54589..f925c4ad4294 100644
> > --- a/drivers/pci/controller/dwc/pcie-qcom-ep.c
> > +++ b/drivers/pci/controller/dwc/pcie-qcom-ep.c
> > @@ -823,6 +823,10 @@ static const struct pci_epc_features qcom_pcie_epc_features = {
> > .msi_capable = true,
> > .msix_capable = false,
> > .align = SZ_4K,
> > + .bar[BAR_0] = { .only_64bit = true, },
> > + .bar[BAR_1] = { .type = BAR_RESERVED, },
> > + .bar[BAR_2] = { .only_64bit = true, },
> > + .bar[BAR_3] = { .type = BAR_RESERVED, },
> > };
> >
> > static const struct pci_epc_features *
> > --
> > 2.25.1
> >

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