Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Jianmin Lv <lvjianmin@loongson.cn>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
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: Mon, 5 Jun 2023 08:59:23 +0800	[thread overview]
Message-ID: <ad969019-e763-b06f-d557-be4e672c68db@loongson.cn> (raw)
In-Reply-To: <20230604085500.ioaos3ydehvqq24i@skbuf>



On 2023/6/4 下午4:55, Vladimir Oltean wrote:
> 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.
> 

For a multi-function device, if func 0 is not allowed to be scanned, as 
I said in way of 2, the other funcs of the device will be described as 
platform devices instead of pci and be not scanned either, which is 
acceptable for Loongson. The main goal by any way for us is to resolve 
the problem that shared pins can not be used simultaneously by devices 
sharing them. IMO, configure them in DT one by one may be reasonable, 
but adapting each driver will be bothered.

Any way, let's listen to opinions from Bjorn and Rob.


  reply	other threads:[~2023-06-05  0:59 UTC|newest]

Thread overview: 25+ 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
     [not found]             ` <ZHetDo5PozWdtrxP@bhelgaas>
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
2023-06-05  0:59                                   ` Jianmin Lv [this message]
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=ad969019-e763-b06f-d557-be4e672c68db@loongson.cn \
    --to=lvjianmin@loongson.cn \
    --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=michael@walle.cc \
    --cc=netdev@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=vladimir.oltean@nxp.com \
    --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