On 11/12/22 12:06 AM, Jiaxun Yang wrote:
>
>
> 在 2022/11/10 23:13, Bjorn Helgaas 写道:
>> On Thu, Nov 10, 2022 at 11:00:45PM +0000, Jiaxun Yang wrote:
>>> 在2022年11月10日十一月 下午9:07，Bjorn Helgaas写道：
>>>> On Tue, Nov 08, 2022 at 02:42:40PM +0800, Liu Peibao wrote:
>>>>> The PCI Controller of 2k1000 could not mask devices by setting vender ID or
>>>>> device ID in configuration space header as invalid values. When there are
>>>>> pins shareable between the platform device and PCI device, if the platform
>>>>> device is preferred, we should not scan this PCI device. In the above
>>>>> scene, add `status = "disabled"` property in DT node of this PCI device.
>>>>>
>>>>> Signed-off-by: Liu Peibao <liupeibao@xxxxxxxxxxx>
>>>>> ---
>>>>> V3 -> V4: 1. get rid of the masklist and search the status property
>>>>> directly.
>>>>> 2. check the status property only when accessing the vendor ID.
>>>>> V2 -> V3: 1. use list_for_each_entry() for more clearly.
>>>>> 2. fix wrong use of sizeof().
>>>>> V1 -> V2: use existing property "status" instead of adding new property.
>>>>>
>>>>> drivers/pci/controller/pci-loongson.c | 11 +++++++++++
>>>>> 1 file changed, 11 insertions(+)
>>>>>
>>>>> diff --git a/drivers/pci/controller/pci-loongson.c b/drivers/pci/controller/pci-loongson.c
>>>>> index 05c50408f13b..efca0b3b5a29 100644
>>>>> --- a/drivers/pci/controller/pci-loongson.c
>>>>> +++ b/drivers/pci/controller/pci-loongson.c
>>>>> @@ -194,6 +194,17 @@ static void __iomem *pci_loongson_map_bus(struct pci_bus *bus,
>>>>> return NULL;
>>>>> }
>>>>> +#ifdef CONFIG_OF
>>>>> + /* Don't access disabled devices. */
>>>>> + if (pci_is_root_bus(bus) && where == PCI_VENDOR_ID) {
>>>>> + struct device_node *dn;
>>>>> +
>>>>> + dn = of_pci_find_child_device(bus->dev.of_node, devfn);
>>>>> + if (dn && !of_device_is_available(dn))
>>>>> + return NULL;
>>>>> + }
>>>>> +#endif
>>>> Looks nice and simple, thanks for trying this out.
>>> Should we make this into common PCI code?
>>> I guess Loongson won’t be the last platform having such problem.
>> I think we should wait until somebody else has this problem.
>>
>> It's not a completely trivial situation because if the device uses PCI
>> memory or I/O space, we have to worry about how that space is handled.
>> Does the BIOS assign that space? Is it included in the host bridge
>> _CRS or "ranges" properties? If the device is below any PCI bridges
>> (I don't think that's the case in your situation), how does the space
>> it requires get routed through the bridges?
>
> I believe in this case the address is assigned by BIOS and they are out of ranges
> properties of host bridge. Those are all on chip devices so there won't be any
> bridges.
>
> @Peibao, can you please confirm this? I was never able to boot mainline kernel
> on my LS2K board.
>
> Thanks.
> - Jiaxun
>
@Jiaxun,
Yes, the same as you said totally.
Did you notice the following patch? The liointc of LS2K can't work after
commit b2c4c3969fd7 ("irqchip/loongson-liointc: irqchip add 2.0 version"),
which may cause the booting failure.
https://lore.kernel.org/all/20221104110712.23300-1-liupeibao@xxxxxxxxxxx/
In fact, I am developing this on the LoongArch compatible board LS2K1000LA.
I boot the mainline kernel basing my FDT supporting patch set for LoongArch
and the BIOS following current LoongArch booting protocol :).
BR,
Peibao
>
>>
>> It would be nice to say something in this commit log about whether
>> these are issues on your platform.
>>
@Bjorn,
Thanks!
I will update commit log in the next patch to clear the issue on our platform,
which is absolutely what Jiaxun has described above.
BR,
Peibao
