| Message ID | 20250407145546.270683-12-herve.codina@bootlin.com |
|---|---|
| State | New |
| Headers | show |
| Series | [01/16] Revert "treewide: Fix probing of devices in DT overlays" | expand |
Hi Andy, On Tue, 8 Apr 2025 17:34:54 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > 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 > I have tried to find a solution for this topic. Indeed, this patch enables fw_devlink based on device-tree on all x86 platform except OLPC and CE4100. You have mentioned some other x86 based system that could have issues with fw_devlink and it seems to be hard to have a complete list of systems for which we should not enable fw_devlink (potential issues and so regression against current kernel behavior). As you also proposed, we can thing on the opposite direction and enable fw_devlink on x86 systems that need it. We need it because we need the device-tree description over PCI device feature (CONFIG_PCI_DYNAMIC_OF_NODES) on x86 in order to support the LAN966x use case. What do you think about the following condition? if (IS_ENABLED(CONFIG_X86) && !IS_ENABLED(CONFIG_PCI_DYNAMIC_OF_NODES)) return 0; /* Not enabled */ CONFIG_PCI_DYNAMIC_OF_NODES has already to set explicitly by the user. Do you think it makes sense and could be a good alternative instead of filtering out a list of x86 systems ? Best regards, Hervé
On Tue, Apr 8, 2025, at 15:49, Herve Codina wrote: > On Mon, 7 Apr 2025 18:36:28 +0300 >> 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? > > Anything I find upstream related to SpreadTrum seems base on ARM cpus. > I probably miss something. This is the Intel SOFIA platform with chips from both Spreadtrum (now Unisoc) and Rockchips, using a port of the arch/arm/ code DT on x86, about 10 years ago. That code was never upstreamed, and is long abandoned by everyone. >> 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 ? The only one I can think of is CONFIG_OLPC, the XO-1 was a Geode LX, while XO-1.5 used a VIA C7, both with actual open firmware (not just fdt). Arnd
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(-)