linux-kernel - Re: [PATCH V4] PCI: loongson: Skip scanning unavailable child devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 14 Nov 2022 12:03:21 +0800
From:   Liu Peibao <liupeibao@...ngson.cn>
To:     Jiaxun Yang <jiaxun.yang@...goat.com>,
        Bjorn Helgaas <helgaas@...nel.org>
Cc:     Bjorn Helgaas <bhelgaas@...gle.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        Krzysztof Wilczyński <kw@...ux.com>,
        Christophe JAILLET <christophe.jaillet@...adoo.fr>,
        Huacai Chen <chenhuacai@...ngson.cn>,
        Jianmin Lv <lvjianmin@...ngson.cn>,
        Yinbo Zhu <zhuyinbo@...ngson.cn>,
        linux-pci <linux-pci@...r.kernel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH V4] PCI: loongson: Skip scanning unavailable child devices

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@...ngson.cn>
>>>>> ---
>>>>> 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@loongson.cn/

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