Message ID | 20221108064240.8030-1-liupeibao@loongson.cn |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp2527193wru; Mon, 7 Nov 2022 22:52:34 -0800 (PST) X-Google-Smtp-Source: AMsMyM79hA0B3qB+jygxh2caki7Ru+W5pNppVCmBoi7ax0q6Uu0oRg3VvUhmITrwsnva8jrzLbhh X-Received: by 2002:a17:90b:3ec2:b0:215:db2e:b23d with SMTP id rm2-20020a17090b3ec200b00215db2eb23dmr30086417pjb.187.1667890354333; Mon, 07 Nov 2022 22:52:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667890354; cv=none; d=google.com; s=arc-20160816; b=H71SpQu3EZjB0a8Kur431J/U8+Sxs4JeQs/AwNldiJQIFAnFrXl0lj1FpZQdLE/cqq AGYbyxDnXb95AXLS7vJs9Z7L1qAZZ8YnUgPRLtzdtrB8Opn3s4qVbVdMlKWR6bv0pUDe FxCVquhZetMYJaSyYAqr+fQ8yLcWsNR20HcUuA0o2qNf0GlPEJgcOULitwtNCbQhOPck hhi3gPDoUtzK0ww7Wl84YX4DDfJz1Q1KnOQyB+TUGmDBI1G23zfhe/tiAC3vnPgFvONO 9vXCzJalx3Hj3pBnn8AIrW4angnLtr4+sV25HapkHtkg2eIUZZr2smHu6Dr4OMCwmMwk TaLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=nTmpvITbDUB0NSipgz9su7tq4HfVNVf6kWMzDTzb35Q=; b=T6h/34N+4c7glfizf9AFJxy7oPiGIExDPkLsh/QpaM5dgQr5MF3WNPbaEQT1eaT5Jj SXYfEybctAu2Ng5wiDldBIPuqHeLvJgcLpR0gxa3U4zYpfDl+CfPaHjtcMJKE3JBKqMY kWw/fKV6k47gc7d6N0/YYvQP8BCru/wEGX+x1HkpIHZ6zdjtW8rUO3TzMRWQ3DNojztv IAZk9oRwBLgLX8CD32l/W/YWewm0DGUrmQqSQZDswOIdip1ATdv4d4CD/UEwujNA6yTT 7FyKfrrr9czSyaK+KLCGoMa6aVa8K2S0SUdc7PEHeQp0SFO0Fi6Ohhml+YBdlOiqmp9y x+BQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a8-20020a1709027d8800b00176c59140c5si11528954plm.138.2022.11.07.22.52.20; Mon, 07 Nov 2022 22:52:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233454AbiKHGmx (ORCPT <rfc822;hjfbswb@gmail.com> + 99 others); Tue, 8 Nov 2022 01:42:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46640 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232798AbiKHGmt (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 8 Nov 2022 01:42:49 -0500 Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5E9991EAD2; Mon, 7 Nov 2022 22:42:47 -0800 (PST) Received: from loongson.cn (unknown [10.20.42.77]) by gateway (Coremail) with SMTP id _____8Dx_Nhl+mljRj0FAA--.16952S3; Tue, 08 Nov 2022 14:42:45 +0800 (CST) Received: from loongson-PC.loongson.cn (unknown [10.20.42.77]) by localhost.localdomain (Coremail) with SMTP id AQAAf8CxZ1dg+mljwdAOAA--.23277S2; Tue, 08 Nov 2022 14:42:45 +0800 (CST) From: Liu Peibao <liupeibao@loongson.cn> To: Bjorn Helgaas <bhelgaas@google.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Lorenzo Pieralisi <lpieralisi@kernel.org>, =?utf-8?q?Krzysztof_Wilczy=C5=84?= =?utf-8?q?ski?= <kw@linux.com>, Jiaxun Yang <jiaxun.yang@flygoat.com>, Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Huacai Chen <chenhuacai@loongson.cn>, Jianmin Lv <lvjianmin@loongson.cn>, Yinbo Zhu <zhuyinbo@loongson.cn>, Liu Peibao <liupeibao@loongson.cn>, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH V4] PCI: loongson: Skip scanning unavailable child devices Date: Tue, 8 Nov 2022 14:42:40 +0800 Message-Id: <20221108064240.8030-1-liupeibao@loongson.cn> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf8CxZ1dg+mljwdAOAA--.23277S2 X-CM-SenderInfo: xolx1vpled0qxorr0wxvrqhubq/1tbiAQAECmNo9WQJ3wACsB X-Coremail-Antispam: 1Uk129KBjvJXoW7Kr4fWw48GFWkKw1fGr4DJwb_yoW8WrykpF W3AFWakr48tF1Ikan0q348u3Wa9F4DGas8JFZ7CwnF93ZxC345Wry8CFyFv343tr48AF1Y v3WvgF18GF4UJF7anT9S1TB71UUUUjUqnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU bSxYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_Jrv_JF1l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVW8JVW5JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwA2z4 x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJVWxJr1l n4kS14v26r1Y6r17M2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6x ACxx1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r126r1DMcIj6I8E 87Iv67AKxVW8JVWxJwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc7CjxV Aaw2AFwI0_JF0_Jw1l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1l4IxY O2xFxVAFwI0_Jrv_JF1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGV WUWwC2zVAF1VAY17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_ Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rV WUJVWUCwCI42IY6I8E87Iv67AKxVW8JVWxJwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4U JbIYCTnIWIevJa73UjIFyTuYvjxUxYiiDUUUU X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1748909796253591869?= X-GMAIL-MSGID: =?utf-8?q?1748909796253591869?= |
Series |
[V4] PCI: loongson: Skip scanning unavailable child devices
|
|
Commit Message
Liu Peibao
Nov. 8, 2022, 6:42 a.m. UTC
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@loongson.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(+)
Comments
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@loongson.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. > /* 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 >
在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@loongson.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. > >> /* 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 >>
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@loongson.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
在 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@loongson.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 > > 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
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@loongson.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
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 + /* CFG0 can only access standard space */ if (where < PCI_CFG_SPACE_SIZE && priv->cfg0_base) return cfg0_map(priv, bus, devfn, where);