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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221110231351.GA681551@bhelgaas>
Date:   Thu, 10 Nov 2022 17:13:51 -0600
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Jiaxun Yang <jiaxun.yang@...goat.com>
Cc:     Liu Peibao <liupeibao@...ngson.cn>,
        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 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?

It would be nice to say something in this commit log about whether
these are issues on your platform.

> >>  	/* CFG0 can only access standard space */
> >>  	if (where < PCI_CFG_SPACE_SIZE && priv->cfg0_base)
> >>  		return cfg0_map(priv, bus, devfn, where);
> >> -- 
> >> 2.20.1
> >>
> 
> -- 
> - Jiaxun

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ