[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e93522bc-aa6e-5b6d-8dd0-c9c926d292c5@mm-sol.com>
Date: Thu, 7 Nov 2019 11:40:18 +0200
From: Stanimir Varbanov <svarbanov@...sol.com>
To: Bjorn Andersson <bjorn.andersson@...aro.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Andrew Murray <andrew.murray@....com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
linux-arm-msm@...r.kernel.org, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] PCI: qcom: Fix the fixup of PCI_VENDOR_ID_QCOM
Hi,
On 11/7/19 11:32 AM, Stanimir Varbanov wrote:
> Hi Bjorn,
>
> On 11/6/19 10:23 PM, Bjorn Andersson wrote:
>> On Mon 04 Nov 05:00 PST 2019, Stanimir Varbanov wrote:
>>
>>> Hi Bjorn,
>>>
>>> Thanks for the fix!
>>>
>>> On 11/2/19 2:24 AM, Bjorn Andersson wrote:
>>>> There exists non-bridge PCIe devices with PCI_VENDOR_ID_QCOM, so limit
>>>> the fixup to only affect the PCIe 2.0 (0x106) and PCIe 3.0 (0x107)
>>>> bridges.
>>>
>>> Are you sure that this will not break ops_1_0_0 (Qcom IP rev.: 1.0.0
>>> Synopsys IP rev.: 4.11a) i.e. apq8084 ?
>
> OK, I've checked DEVICE IDs for all supported SoCs in pcie-qcom driver:
>
> apq8084 0x101
> ipq8064 0x101
> apq8064 0x101
> msm8996 0x104
> ipq8074 0x302
> ipq4019 0x1001
> qcs404 ??? (can you check for this SoC)
>
> As you can see they are various, so I don't think we have to expose them
> in pci_ids.h. See my proposal below.
>
> Of course the last word will be from PCI maintainers.
>
>>>
>>
>> I am not, I've only tested this on db820c and db845c. Unfortunately I'm
>> unable to find a branch with the necessary dts snippets to test it. Do
>> you perhaps have a branch somewhere?
>>
>> Regards,
>> Bjorn
>>
>>>>
>>>> Cc: stable@...r.kernel.org
>>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@...aro.org>
>>>> ---
>>>> drivers/pci/controller/dwc/pcie-qcom.c | 3 ++-
>>>> include/linux/pci_ids.h | 2 ++
>>>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
>>>> index 35f4980480bb..b91abf4d4905 100644
>>>> --- a/drivers/pci/controller/dwc/pcie-qcom.c
>>>> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
>>>> @@ -1441,7 +1441,8 @@ static void qcom_fixup_class(struct pci_dev *dev)
>>>> {
>>>> dev->class = PCI_CLASS_BRIDGE_PCI << 8;
>>>> }
>>>> -DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, PCI_ANY_ID, qcom_fixup_class);
>>>> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, PCIE_DEVICE_ID_QCOM_PCIE20, qcom_fixup_class);
>>>> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, PCIE_DEVICE_ID_QCOM_PCIE30, qcom_fixup_class);
>
> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, 0x0101, qcom_fixup_class);
> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, 0x0104, qcom_fixup_class);
> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, 0x0106, qcom_fixup_class);
> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, 0x0107, qcom_fixup_class);
> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, 0x0302, qcom_fixup_class);
> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_QCOM, 0x1001, qcom_fixup_class);
>
>>>>
>>>> static struct platform_driver qcom_pcie_driver = {
>>>> .probe = qcom_pcie_probe,
>>>> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
>>>> index 21a572469a4e..3d0724ee4d2f 100644
>>>> --- a/include/linux/pci_ids.h
>>>> +++ b/include/linux/pci_ids.h
>>>> @@ -2413,6 +2413,8 @@
>>>> #define PCI_VENDOR_ID_LENOVO 0x17aa
>>>>
>>>> #define PCI_VENDOR_ID_QCOM 0x17cb
>>>> +#define PCIE_DEVICE_ID_QCOM_PCIE20 0x0106
>>>> +#define PCIE_DEVICE_ID_QCOM_PCIE30 0x0107
I looked in pci_ids.h, and it looks like this is the right place for
DEVICE_IDs so instead of pcie gen we could list the SoCs names?
#define PCIE_DEVICE_ID_QCOM_APQ8084 0x0101
#define PCIE_DEVICE_ID_QCOM_APQ8064 0x0101
....
--
regards,
Stan
Powered by blists - more mailing lists