Message ID | 20250407145546.270683-12-herve.codina@bootlin.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | lan966x pci device: Add support for SFPs | expand |
On Mon, Apr 07, 2025 at 04:55:40PM +0200, Herve Codina wrote: > PCI drivers can use a device-tree overlay to describe the hardware > available on the PCI board. This is the case, for instance, of the > LAN966x PCI device driver. > > Adding some more nodes in the device-tree overlay adds some more > consumer/supplier relationship between devices instantiated from this > overlay. > > Those fw_node consumer/supplier relationships are handled by fw_devlink > and are created based on the device-tree parsing done by the > of_fwnode_add_links() function. > > Those consumer/supplier links are needed in order to ensure a correct PM > runtime management and a correct removal order between devices. > > For instance, without those links a supplier can be removed before its > consumers is removed leading to all kind of issue if this consumer still > want the use the already removed supplier. > > The support for the usage of an overlay from a PCI driver has been added > on x86 systems in commit 1f340724419ed ("PCI: of: Create device tree PCI > host bridge node"). > > In the past, support for fw_devlink on x86 had been tried but this > support has been removed in commit 4a48b66b3f52 ("of: property: Disable > fw_devlink DT support for X86"). Indeed, this support was breaking some > x86 systems such as OLPC system and the regression was reported in [0]. > > Instead of disabling this support for all x86 system, use a finer grain > and disable this support only for the possible problematic subset of x86 > system mixing ACPI and device-tree at boot time (i.e. OLPC and CE4100). This is incorrect, they never had ACPI to begin with. Also there is third platform that are using DT on x86 core — SpreadTrum based phones. And not sure about AMD stuff (Geode?). > [0] https://lore.kernel.org/lkml/3c1f2473-92ad-bfc4-258e-a5a08ad73dd0@web.de/ Can you make this to be a Link tag? Link: https://lore.kernel.org/lkml/3c1f2473-92ad-bfc4-258e-a5a08ad73dd0@web.de/ [0] > Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Hi Andy, On Mon, 7 Apr 2025 18:36:28 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > On Mon, Apr 07, 2025 at 04:55:40PM +0200, Herve Codina wrote: > > PCI drivers can use a device-tree overlay to describe the hardware > > available on the PCI board. This is the case, for instance, of the > > LAN966x PCI device driver. > > > > Adding some more nodes in the device-tree overlay adds some more > > consumer/supplier relationship between devices instantiated from this > > overlay. > > > > Those fw_node consumer/supplier relationships are handled by fw_devlink > > and are created based on the device-tree parsing done by the > > of_fwnode_add_links() function. > > > > Those consumer/supplier links are needed in order to ensure a correct PM > > runtime management and a correct removal order between devices. > > > > For instance, without those links a supplier can be removed before its > > consumers is removed leading to all kind of issue if this consumer still > > want the use the already removed supplier. > > > > The support for the usage of an overlay from a PCI driver has been added > > on x86 systems in commit 1f340724419ed ("PCI: of: Create device tree PCI > > host bridge node"). > > > > In the past, support for fw_devlink on x86 had been tried but this > > support has been removed in commit 4a48b66b3f52 ("of: property: Disable > > fw_devlink DT support for X86"). Indeed, this support was breaking some > > x86 systems such as OLPC system and the regression was reported in [0]. > > > > Instead of disabling this support for all x86 system, use a finer grain > > and disable this support only for the possible problematic subset of x86 > > > system mixing ACPI and device-tree at boot time (i.e. OLPC and CE4100). > > This is incorrect, they never had ACPI to begin with. Also there is third > platform that are using DT on x86 core — SpreadTrum based phones. I will rework the commit log to avoid 'mixing ACPI and device-tree' For "SpreadTrum based phones", do you have an idea about the Kconfig symbol I could use to filter our this x86 systems? Anything I find upstream related to SpreadTrum seems base on ARM cpus. I probably miss something. > > And not sure about AMD stuff (Geode?). Same here, if some AMD devices need to be filtered out, is there a specific Kconfig symbol I can use ? > > > [0] https://lore.kernel.org/lkml/3c1f2473-92ad-bfc4-258e-a5a08ad73dd0@web.de/ > > Can you make this to be a Link tag? > > Link: https://lore.kernel.org/lkml/3c1f2473-92ad-bfc4-258e-a5a08ad73dd0@web.de/ [0] > Yes, of course, I will do that in the next iteration. Best regards, Hervé
On Tue, Apr 08, 2025 at 03:49:25PM +0200, Herve Codina wrote: > On Mon, 7 Apr 2025 18:36:28 +0300 > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Mon, Apr 07, 2025 at 04:55:40PM +0200, Herve Codina wrote: ... > > This is incorrect, they never had ACPI to begin with. Also there is third > > platform that are using DT on x86 core — SpreadTrum based phones. > > I will rework the commit log to avoid 'mixing ACPI and device-tree' > > For "SpreadTrum based phones", do you have an idea about the Kconfig symbol > I could use to filter our this x86 systems? Hmm... good question. I don't think it was anything. The Airmont core just works and doesn't require anything special to be set. And platform is x86 with the devices that are established on ARM, so nothing special in device tree either, I suppose. Basically any x86 platform with OF should be excluded, rather think of what should be included. But I see that as opposite requirements to the same function. I have no idea how to solve this. Perhaps find that SpreadTrum Intel Atom-based device? Would be really hard, I believe. Especially if we want to install a custom kernel there... > Anything I find upstream related to SpreadTrum seems base on ARM cpus. > I probably miss something. There were two SoCs that were Intel Atom based [1]. And some patches [2] to x86 DT code were made to support those cases. > > And not sure about AMD stuff (Geode?). > > Same here, if some AMD devices need to be filtered out, is there a specific > Kconfig symbol I can use ? This is question to AMD people. I have no clue. [1]: https://www.anandtech.com/show/11196/mwc-2017-spreadtrum-launches-8core-intel-airmontbased-soc-with-cat-7-lte-for-smartphones [2]: 4e07db9c8db8 ("x86/devicetree: Use CPU description from Device Tree") and co. `git log --no-merges 4e07db9c8db8 -- arch/x86/kernel/devicetree.c
diff --git a/drivers/of/property.c b/drivers/of/property.c index c1feb631e383..a4b367d056b8 100644 --- a/drivers/of/property.c +++ b/drivers/of/property.c @@ -1605,7 +1605,7 @@ static int of_fwnode_add_links(struct fwnode_handle *fwnode) const struct property *p; struct device_node *con_np = to_of_node(fwnode); - if (IS_ENABLED(CONFIG_X86)) + if (IS_ENABLED(CONFIG_X86_INTEL_CE) || IS_ENABLED(CONFIG_OLPC)) return 0; if (!con_np)
PCI drivers can use a device-tree overlay to describe the hardware available on the PCI board. This is the case, for instance, of the LAN966x PCI device driver. Adding some more nodes in the device-tree overlay adds some more consumer/supplier relationship between devices instantiated from this overlay. Those fw_node consumer/supplier relationships are handled by fw_devlink and are created based on the device-tree parsing done by the of_fwnode_add_links() function. Those consumer/supplier links are needed in order to ensure a correct PM runtime management and a correct removal order between devices. For instance, without those links a supplier can be removed before its consumers is removed leading to all kind of issue if this consumer still want the use the already removed supplier. The support for the usage of an overlay from a PCI driver has been added on x86 systems in commit 1f340724419ed ("PCI: of: Create device tree PCI host bridge node"). In the past, support for fw_devlink on x86 had been tried but this support has been removed in commit 4a48b66b3f52 ("of: property: Disable fw_devlink DT support for X86"). Indeed, this support was breaking some x86 systems such as OLPC system and the regression was reported in [0]. Instead of disabling this support for all x86 system, use a finer grain and disable this support only for the possible problematic subset of x86 system mixing ACPI and device-tree at boot time (i.e. OLPC and CE4100). [0] https://lore.kernel.org/lkml/3c1f2473-92ad-bfc4-258e-a5a08ad73dd0@web.de/ Signed-off-by: Herve Codina <herve.codina@bootlin.com> --- drivers/of/property.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)