From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Jianmin Lv <lvjianmin@loongson.cn>
Cc: Liu Peibao <liupeibao@loongson.cn>,
Bjorn Helgaas <helgaas@kernel.org>,
linux-pci@vger.kernel.org, netdev@vger.kernel.org,
Bjorn Helgaas <bhelgaas@google.com>,
Rob Herring <robh@kernel.org>,
Claudiu Manoil <claudiu.manoil@nxp.com>,
Michael Walle <michael@walle.cc>,
linux-kernel@vger.kernel.org,
Binbin Zhou <zhoubinbin@loongson.cn>,
Huacai Chen <chenhuacai@loongson.cn>
Subject: Re: [PATCH pci] PCI: don't skip probing entire device if first fn OF node has status = "disabled"
Date: Sun, 4 Jun 2023 11:55:00 +0300 [thread overview]
Message-ID: <20230604085500.ioaos3ydehvqq24i@skbuf> (raw)
In-Reply-To: <87f2b231-2e16-e7b8-963b-fc86c407bc96@loongson.cn>
On Sat, Jun 03, 2023 at 10:35:50AM +0800, Jianmin Lv wrote:
> > How about 3. handle of_device_is_available() in the probe function of
> > the "loongson, pci-gmac" driver? Would that not work?
> >
> This way does work only for the specified device. There are other devices,
> such as HDA, I2S, etc, which have shared pins. Then we have to add
> of_device_is_available() checking to those drivers one by one. And we are
> not sure if there are other devices in new generation chips in future. So
> I'm afraid that the way you mentioned is not suitable for us.
Got it, so you have more on-chip PCIe devices than the ones listed in
loongson64-2k1000.dtsi, and you don't want to describe them in the
device tree just to put status = "disabled" for those devices/functions
that you don't want Linux to use - although you could, and it wouldn't
be that hard or have unintended side effects.
Though you need to admit, in case you had an on-chip multi-function PCIe
device like the NXP ENETC, and you wanted Linux to not use function 0,
the strategy you're suggesting here that is acceptable for Loongson
would not have worked.
I believe we need a bit of coordination from PCIe and device tree
maintainers, to suggest what would be the encouraged best practices and
ways to solve this regression for the ENETC.
next prev parent reply other threads:[~2023-06-04 8:55 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-21 11:51 [PATCH pci] PCI: don't skip probing entire device if first fn OF node has status = "disabled" Vladimir Oltean
2023-05-29 20:48 ` Vladimir Oltean
2023-05-30 21:58 ` Bjorn Helgaas
2023-05-30 22:04 ` Vladimir Oltean
2023-05-30 22:27 ` Bjorn Helgaas
2023-05-30 23:15 ` Vladimir Oltean
2023-05-31 16:56 ` Bjorn Helgaas
2023-05-31 16:58 ` Vladimir Oltean
2023-05-31 20:24 ` Bjorn Helgaas
2023-06-01 8:11 ` Vladimir Oltean
2023-06-01 15:44 ` Bjorn Helgaas
2023-06-01 16:33 ` Vladimir Oltean
2023-06-01 17:51 ` Bjorn Helgaas
2023-06-01 22:15 ` Vladimir Oltean
2023-06-02 4:06 ` 陈华才
2023-06-02 7:21 ` Liu Peibao
2023-06-02 7:36 ` Jianmin Lv
2023-06-02 10:16 ` Vladimir Oltean
2023-06-03 2:35 ` Jianmin Lv
2023-06-04 8:55 ` Vladimir Oltean [this message]
2023-06-05 0:59 ` Jianmin Lv
2023-06-05 9:34 ` Vladimir Oltean
2023-06-16 2:12 ` Jianmin Lv
2023-06-16 17:57 ` Rob Herring
2023-08-03 10:39 ` Vladimir Oltean
2023-08-03 11:34 ` Vladimir Oltean
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230604085500.ioaos3ydehvqq24i@skbuf \
--to=vladimir.oltean@nxp.com \
--cc=bhelgaas@google.com \
--cc=chenhuacai@loongson.cn \
--cc=claudiu.manoil@nxp.com \
--cc=helgaas@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=liupeibao@loongson.cn \
--cc=lvjianmin@loongson.cn \
--cc=michael@walle.cc \
--cc=netdev@vger.kernel.org \
--cc=robh@kernel.org \
--cc=zhoubinbin@loongson.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox