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

[Jianmin Lv]

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.