public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
	 "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	 Jakub Kicinski <kuba@kernel.org>,
	Paolo Abeni <pabeni@redhat.com>, Vinod Koul <vkoul@kernel.org>,
	 Neil Armstrong <neil.armstrong@linaro.org>,
	Liam Girdwood <lgirdwood@gmail.com>, Lee Jones <lee@kernel.org>,
	 Pavel Machek <pavel@kernel.org>, Peter Rosin <peda@axentia.se>,
	Andrew Lunn <andrew@lunn.ch>,
	 Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	 Moritz Fischer <mdf@kernel.org>, Xu Yilun <yilun.xu@intel.com>,
	Tom Rix <trix@redhat.com>,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	 Danilo Krummrich <dakr@kernel.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	 linux-phy@lists.infradead.org, linux-spi@vger.kernel.org,
	linux-leds@vger.kernel.org,  linux-fpga@vger.kernel.org,
	driver-core@lists.linux.dev
Subject: Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
Date: Mon, 23 Mar 2026 14:39:35 -0700	[thread overview]
Message-ID: <acGxgkWiPLy8XePz@google.com> (raw)
In-Reply-To: <55abcc68-747a-468a-abdf-b6340d658c4f@sirena.org.uk>

On Mon, Mar 23, 2026 at 07:58:14PM +0000, Mark Brown wrote:
> On Mon, Mar 23, 2026 at 12:41:59PM -0700, Dmitry Torokhov wrote:
> > On Mon, Mar 23, 2026 at 07:05:13PM +0000, Mark Brown wrote:
> 
> > > I think this is a worrying idea for core code like this, we have
> > > specific firmware bindings for specific firmware interfaces with the
> > > different interfaces having very different ideas of how things should be
> > > modelled.  The chances that firmware agnostic code is going to do the
> > > right thing seem low, and encouraging the use of generic APIs that might
> > > happen to run OK raises the risk that we'll get firmware vendors relying
> > > on them and leaving us with a conceptual mishmash to sort through.
> 
> > Firmware vendors can introduce incompatible DT bindings and have them in
> > their devices too and we have to deal with that... 
> 
> The case that's worrying me is mixing the ACPI and DT design models in
> one system, and especially having that happen to actually work without
> modification purely by luck rather than by design.
> 
> > I think if this pushes closer ACPI and OF schemas for at least some
> > subsystems closer to each other it would not be a bad thing.
> 
> I think we shouldn't be encouraging people to just throw random stuff at
> the wall and see if it happens to run OK with whatever OS they tried
> booting.  The differences between ACPI and DT in areas like the
> regulator bindings are fundamental conceptual ones.  There's some areas
> where things are closer and it winds up being fine actually, especially
> for leaf devices, but there's others where that's less likely.

Maybe we should just have explicit checks with nice comments at the
beginning of the schema parsing stating that this schema is
intentionally restricted to OF (or ACPI) in cases where we ave distinct
schemas? This way it is explicit that it is a thought out decision and
not simply a legacy artefact.

I think we want to hanel software nodes because they do not
form their own schemas, they follow the existing ones (DT usually).

-- 
Dmitry

  reply	other threads:[~2026-03-23 21:39 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-23  1:54 [PATCH 00/10] Remove class_find_device_by_of_node in favor of finding by firmware node Dmitry Torokhov
2026-03-23  1:54 ` [PATCH net-next 01/10] net: wan: framer: switch to using class_find_device_by_fwnode() Dmitry Torokhov
2026-03-23  1:54 ` [PATCH 02/10] phy: core: " Dmitry Torokhov
2026-03-23  1:54 ` [PATCH 03/10] spi: " Dmitry Torokhov
2026-03-23 13:58   ` Mark Brown
2026-03-23 17:16   ` Mark Brown
2026-03-23 18:25     ` Dmitry Torokhov
2026-03-23  1:54 ` [PATCH 04/10] regulator: of: " Dmitry Torokhov
2026-03-23 14:00   ` Mark Brown
2026-03-23 18:28     ` Dmitry Torokhov
2026-03-23 19:05       ` Mark Brown
2026-03-23 19:41         ` Dmitry Torokhov
2026-03-23 19:58           ` Mark Brown
2026-03-23 21:39             ` Dmitry Torokhov [this message]
2026-03-23 20:01         ` Andrew Lunn
2026-03-23 21:36           ` Mark Brown
2026-03-23 21:41             ` Dmitry Torokhov
2026-03-23 22:11               ` Andrew Lunn
2026-03-23 22:27                 ` Dmitry Torokhov
2026-03-23 22:39                   ` Andrew Lunn
2026-03-23 22:48                     ` Dmitry Torokhov
2026-03-24 13:50                       ` Andrew Lunn
2026-03-24  0:17           ` Russell King (Oracle)
2026-03-23  1:54 ` [PATCH 05/10] leds: led-class: " Dmitry Torokhov
2026-03-23  1:54 ` [PATCH 06/10] mux: " Dmitry Torokhov
2026-03-23  1:54 ` [PATCH net-next 07/10] net: phy: " Dmitry Torokhov
2026-03-23  2:54   ` Andrew Lunn
2026-03-23  5:17     ` Dmitry Torokhov
2026-03-23  8:59       ` Russell King (Oracle)
2026-03-23 18:33         ` Dmitry Torokhov
2026-03-23 18:39           ` Russell King (Oracle)
2026-03-23 19:35             ` Dmitry Torokhov
2026-03-23 20:15             ` Andrew Lunn
2026-03-23 21:49               ` Dmitry Torokhov
2026-03-23 22:00                 ` Andrew Lunn
2026-03-23 22:20                   ` Dmitry Torokhov
2026-03-23  1:54 ` [PATCH 08/10] fpga: bridge: " Dmitry Torokhov
2026-03-23  1:54 ` [PATCH 09/10] fpga: manager: " Dmitry Torokhov
2026-03-23  1:54 ` [PATCH 10/10] driver core: class: remove class_find_device_by_of_node() Dmitry Torokhov
2026-03-23  7:43   ` Greg Kroah-Hartman

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=acGxgkWiPLy8XePz@google.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrew@lunn.ch \
    --cc=broonie@kernel.org \
    --cc=dakr@kernel.org \
    --cc=davem@davemloft.net \
    --cc=driver-core@lists.linux.dev \
    --cc=edumazet@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=lee@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-fpga@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mdf@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pavel@kernel.org \
    --cc=peda@axentia.se \
    --cc=rafael@kernel.org \
    --cc=trix@redhat.com \
    --cc=vkoul@kernel.org \
    --cc=yilun.xu@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox