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.
