| Message ID | 20241129092415.29437-2-manivannan.sadhasivam@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Migrate PCI Endpoint Subsystem tests to Kselftest | expand |
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? > > > Fixes: f55fee56a631 ("PCI: qcom-ep: Add Qualcomm PCIe Endpoint controller driver") Yes, having a sha1 that has that "feature addition" would be great, surely that isn't 6.13-rc1, is it? thanks, greg k-h
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:
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 *
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. Cc: stable+noautosel@kernel.org # depends on patch introducing only_64bit flag 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(+)