netdev - Re: [PATCH pci] PCI: don't skip probing entire device if first fn OF node has status = "disabled"

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]

Date: Fri, 16 Jun 2023 10:12:29 +0800
From: Jianmin Lv <lvjianmin@...ngson.cn>
To: Vladimir Oltean <vladimir.oltean@....com>
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 2023/6/5 下午5:34, Vladimir Oltean wrote:
> 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?
> 

E.g. there are two functions , func0 is HDA controller and func1 is I2S 
controller and they have shared pins.
When HDA or I2S is used, both are disabled for PCI enumeration in BIOS 
(e.g. by filling PCI header with 0xffffffff), and mem space has been 
reserved from host bridge window for them in BIOS, of cause, reserved 
space will not be seen by kernel because it has been removed in host 
bridge mem range when passed to kernel in DT. Then the reserved mem base 
is passed into kernel by DT, CPU will use remapped address of the mem 
base, and these devices will not be enumerated in PCI bus. The way is 
only used for PCI devices (share common pins and exist on bus 0) 
integrated in Loongson CPU or chipset.