From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Herve Codina <herve.codina@bootlin.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Andi Shyti <andi.shyti@kernel.org>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
Peter Rosin <peda@axentia.se>,
Derek Kiernan <derek.kiernan@amd.com>,
Dragan Cvetic <dragan.cvetic@amd.com>,
Arnd Bergmann <arnd@arndb.de>, Rob Herring <robh@kernel.org>,
Saravana Kannan <saravanak@google.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Mark Brown <broonie@kernel.org>, Len Brown <lenb@kernel.org>,
Daniel Scally <djrscally@gmail.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Wolfram Sang <wsa@kernel.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org,
linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-pci@vger.kernel.org, linux-spi@vger.kernel.org,
linux-acpi@vger.kernel.org,
Allan Nielsen <allan.nielsen@microchip.com>,
Horatiu Vultur <horatiu.vultur@microchip.com>,
Steen Hegelund <steen.hegelund@microchip.com>,
Luca Ceresoli <luca.ceresoli@bootlin.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH 11/16] of: property: Allow fw_devlink device-tree support for x86
Date: Sat, 19 Apr 2025 18:30:31 +0300 [thread overview]
Message-ID: <aAPBl7qdbUizMQko@smile.fi.intel.com> (raw)
In-Reply-To: <20250418151036.719f982b@bootlin.com>
On Fri, Apr 18, 2025 at 03:10:36PM +0200, Herve Codina wrote:
> 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 ?
At least this won't break old platforms that won't set that configuration
option. Ideally, of course, it would be nice to have some kind of detection
at run-time...
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2025-04-19 15:30 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-07 14:55 [PATCH 00/16] lan966x pci device: Add support for SFPs Herve Codina
2025-04-07 14:55 ` [PATCH 01/16] Revert "treewide: Fix probing of devices in DT overlays" Herve Codina
2025-04-07 15:17 ` Andy Shevchenko
2025-04-07 14:55 ` [PATCH 02/16] driver core: Rename get_dev_from_fwnode() wrapper to get_device_from_fwnode() Herve Codina
2025-04-07 15:19 ` Andy Shevchenko
2025-04-07 22:51 ` Saravana Kannan
2025-04-08 10:17 ` Luca Ceresoli
2025-04-07 14:55 ` [PATCH 03/16] of: dynamic: Fix overlayed devices not probing because of fw_devlink Herve Codina
2025-04-07 15:18 ` Andy Shevchenko
2025-04-07 14:55 ` [PATCH 04/16] driver core: Avoid warning when removing a device while its supplier is unbinding Herve Codina
2025-04-07 14:55 ` [PATCH 05/16] bus: simple-pm-bus: Populate child nodes at probe Herve Codina
2025-04-07 14:55 ` [PATCH 06/16] PCI: of: Set fwnode.dev of newly created PCI device nodes Herve Codina
2025-04-07 15:30 ` Andy Shevchenko
2025-04-08 12:51 ` Herve Codina
2025-04-07 14:55 ` [PATCH 07/16] PCI: of: Remove fwnode_dev_initialized() call for a PCI root bridge node Herve Codina
2025-04-07 14:55 ` [PATCH 08/16] i2c: core: Introduce i2c_get_adapter_supplier() Herve Codina
2025-04-07 15:27 ` Andy Shevchenko
2025-04-08 13:08 ` Herve Codina
2025-04-08 13:47 ` Andy Shevchenko
2025-04-08 14:29 ` Herve Codina
2025-04-07 14:55 ` [PATCH 09/16] i2c: mux: Set adapter supplier Herve Codina
2025-04-07 14:55 ` [PATCH 10/16] i2c: mux: Create missing devlink between mux and " Herve Codina
2025-04-07 14:55 ` [PATCH 11/16] of: property: Allow fw_devlink device-tree support for x86 Herve Codina
2025-04-07 15:36 ` Andy Shevchenko
2025-04-08 13:49 ` Herve Codina
2025-04-08 14:34 ` Andy Shevchenko
2025-04-18 13:10 ` Herve Codina
2025-04-19 15:30 ` Andy Shevchenko [this message]
2025-04-22 12:00 ` Arnd Bergmann
2025-04-07 14:55 ` [PATCH 12/16] clk: lan966x: Add MCHP_LAN966X_PCI dependency Herve Codina
2025-04-07 15:38 ` Andy Shevchenko
2025-04-08 14:03 ` Herve Codina
2025-04-07 14:55 ` [PATCH 13/16] i2c: busses: at91: " Herve Codina
2025-04-07 15:42 ` Andy Shevchenko
2025-04-08 14:05 ` Herve Codina
2025-04-07 14:55 ` [PATCH 14/16] misc: lan966x_pci: Fix dtso nodes ordering Herve Codina
2025-04-07 14:55 ` [PATCH 15/16] misc: lan966x_pci: Add dtso nodes in order to support SFPs Herve Codina
2025-04-07 20:05 ` Andrew Lunn
2025-04-08 14:26 ` Herve Codina
2025-04-08 14:45 ` Andrew Lunn
2025-04-08 15:13 ` Thomas Petazzoni
2025-04-08 15:38 ` Andrew Lunn
2025-04-09 7:44 ` Thomas Petazzoni
2025-04-09 8:27 ` Geert Uytterhoeven
2025-04-09 14:04 ` Andrew Lunn
2025-04-09 14:14 ` Thomas Petazzoni
2025-04-09 15:03 ` Andrew Lunn
2025-04-10 6:48 ` Thomas Petazzoni
2025-04-16 9:18 ` Herve Codina
2025-04-16 12:05 ` Andrew Lunn
2025-04-07 14:55 ` [PATCH 16/16] misc: lan966x_pci: Add drivers needed to support SFPs in Kconfig help Herve Codina
2025-04-07 15:43 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aAPBl7qdbUizMQko@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=allan.nielsen@microchip.com \
--cc=andi.shyti@kernel.org \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=broonie@kernel.org \
--cc=dakr@kernel.org \
--cc=derek.kiernan@amd.com \
--cc=devicetree@vger.kernel.org \
--cc=djrscally@gmail.com \
--cc=dragan.cvetic@amd.com \
--cc=festevam@gmail.com \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=herve.codina@bootlin.com \
--cc=horatiu.vultur@microchip.com \
--cc=imx@lists.linux.dev \
--cc=kernel@pengutronix.de \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=luca.ceresoli@bootlin.com \
--cc=mturquette@baylibre.com \
--cc=peda@axentia.se \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=sakari.ailus@linux.intel.com \
--cc=saravanak@google.com \
--cc=sboyd@kernel.org \
--cc=shawnguo@kernel.org \
--cc=steen.hegelund@microchip.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=wsa+renesas@sang-engineering.com \
--cc=wsa@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.