linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: Daniel Scally <djrscally@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Platform Driver <platform-driver-x86@vger.kernel.org>,
	Hans de Goede <hdegoede@redhat.com>,
	Mark Gross <mgross@linux.intel.com>,
	Maximilian Luz <luzmaximilian@gmail.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	kieran.bingham@ideasonboard.com
Subject: Re: [RFC PATCH 0/2] Add software node support to regulator framework
Date: Mon, 12 Jul 2021 19:08:23 +0300	[thread overview]
Message-ID: <CAHp75VcQUUDdLYbpvTXSMPvjBzbHtBxywVBPS_xfY5JXyo9XxA@mail.gmail.com> (raw)
In-Reply-To: <20210712133428.GD4435@sirena.org.uk>

On Mon, Jul 12, 2021 at 4:35 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Mon, Jul 12, 2021 at 04:01:05PM +0300, Andy Shevchenko wrote:
>
> > The software nodes shouldn't appear on its own in the generic code.
> > When we use software nodes API in it, it means that we have tried
> > other providers _explicitly_ and haven't found what we are looking for
> > and hence we have to check if software nodes are providing the same.
> > For example, here it's done that way:
> > https://elixir.bootlin.com/linux/v5.14-rc1/source/kernel/irq/irqdomain.c#L178.
>
> > In all other cases it shouldn't be called explicitly.
>
> But why?  I'm not seeing the advantage over providing platform data
> based on DMI quirks here, it seems like a bunch of work for no reason.

What do you mean by additional work? It's exactly opposite since most
of the drivers in the kernel are using the fwnode interface rather
than platform data. Why should we _add_ the specific platform data
handling code in the certain drivers instead of not touching them at
all?

-- 
With Best Regards,
Andy Shevchenko

  reply	other threads:[~2021-07-12 16:09 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-08 22:42 [RFC PATCH 0/2] Add software node support to regulator framework Daniel Scally
2021-07-08 22:42 ` [RFC PATCH 1/2] regulator: Add support for software node connections Daniel Scally
2021-07-09 17:26   ` Mark Brown
2021-07-08 22:42 ` [RFC PATCH 2/2] platform/surface: Add Surface Go 2 board file Daniel Scally
2021-07-09 17:40   ` Mark Brown
2021-07-09 17:04 ` [RFC PATCH 0/2] Add software node support to regulator framework Mark Brown
2021-07-10 22:48   ` Daniel Scally
2021-07-12 14:15     ` Mark Brown
2021-07-12 16:55       ` Laurent Pinchart
2021-07-12 17:32         ` Mark Brown
2021-07-11  9:37   ` Andy Shevchenko
2021-07-12 12:42     ` Mark Brown
2021-07-12 13:01       ` Andy Shevchenko
2021-07-12 13:34         ` Mark Brown
2021-07-12 16:08           ` Andy Shevchenko [this message]
2021-07-12 17:01             ` Mark Brown
2021-07-12 23:32               ` Daniel Scally
2021-07-13 15:24                 ` Mark Brown
2021-07-13 15:42                   ` Laurent Pinchart
2021-07-13 16:02                     ` Mark Brown
2021-07-13 16:06                       ` Laurent Pinchart
2021-07-13 18:24                         ` Mark Brown
2021-07-13 15:55                   ` Andy Shevchenko
2021-07-13 18:18                     ` Mark Brown
2021-07-13 19:46                       ` Andy Shevchenko
2021-07-14 16:05                         ` Mark Brown
2021-07-14  7:25                       ` Laurent Pinchart
2021-07-14 16:59                         ` Mark Brown
2021-07-14 17:18                           ` Laurent Pinchart
2021-07-14 17:28                             ` Mark Brown
2021-07-14 17:41                               ` Laurent Pinchart
2021-07-14 19:18                                 ` Mark Brown
2021-07-14 21:53                                   ` Laurent Pinchart
2021-07-13 22:06                   ` Daniel Scally
2021-07-10 22:28 ` Laurent Pinchart
2021-07-10 22:54   ` Daniel Scally
2021-07-11 16:55     ` Laurent Pinchart
2021-07-12  8:13       ` Daniel Scally
2021-07-12 11:50         ` Laurent Pinchart
2021-07-12 13:23         ` Mark Brown

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=CAHp75VcQUUDdLYbpvTXSMPvjBzbHtBxywVBPS_xfY5JXyo9XxA@mail.gmail.com \
    --to=andy.shevchenko@gmail.com \
    --cc=broonie@kernel.org \
    --cc=djrscally@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luzmaximilian@gmail.com \
    --cc=mgross@linux.intel.com \
    --cc=platform-driver-x86@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).