[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230605093459.gpwtsr5h73eonxt5@skbuf>
Date: Mon, 5 Jun 2023 12:34:59 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: Jianmin Lv <lvjianmin@...ngson.cn>
Cc: Liu Peibao <liupeibao@...ngson.cn>,
Bjorn Helgaas <helgaas@...nel.org>, linux-pci@...r.kernel.org,
netdev@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>,
Rob Herring <robh@...nel.org>,
Claudiu Manoil <claudiu.manoil@....com>,
Michael Walle <michael@...le.cc>, linux-kernel@...r.kernel.org,
Binbin Zhou <zhoubinbin@...ngson.cn>,
Huacai Chen <chenhuacai@...ngson.cn>
Subject: Re: [PATCH pci] PCI: don't skip probing entire device if first fn OF
node has status = "disabled"
On Mon, Jun 05, 2023 at 08:59:23AM +0800, Jianmin Lv wrote:
> 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.
Could you give an example of PCIe functions being described as platform
devices, and how does that work for Loongson? Are you saying that there
will be 2 drivers for the same hardware, one pci_driver and one platform_driver?
In the case of the platform_driver, who will do the PCI-specific stuff
required by the IP, like function level reset and enabling the memory space?
Powered by blists - more mailing lists