From: "Clément Léger" <clement.leger@bootlin.com>
To: Rob Herring <robh@kernel.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>,
Frank Rowand <frowand.list@gmail.com>,
Lars Povlsen <lars.povlsen@microchip.com>,
Steen Hegelund <Steen.Hegelund@microchip.com>,
UNGLinuxDriver@microchip.com,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Allan Nielsen <allan.nielsen@microchip.com>,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 0/3] add fwnode support to reset subsystem
Date: Tue, 5 Apr 2022 09:24:34 +0200 [thread overview]
Message-ID: <20220405092434.6e424ed4@fixe.home> (raw)
In-Reply-To: <Ykst0Vb4fk+iALzc@robh.at.kernel.org>
Le Mon, 4 Apr 2022 12:41:37 -0500,
Rob Herring <robh@kernel.org> a écrit :
> On Thu, Mar 24, 2022 at 03:12:34PM +0100, Clément Léger wrote:
> > This series is part of a larger series which aims at adding fwnode
> > support in multiple subsystems [1]. The goal of this series was to
> > add support for software node in various subsystem but in a first
> > time only the fwnode support had gained consensus and will be added
> > to multiple subsystems.
>
> The goal is describing a solution. What is the problem?
>
> What's the scenario where you have a reset provider not described by
> firmware providing resets to devices (consumers) also not described by
> firmware.
Hi Rob, there was a link attached to this series since there was a
previous one that was sent which described the problem. Here is a link
to the same thread but to a specific message which clarifies the
problem and the solutions that were mentionned by other maintainers
(ACPI overlays, DT overlays, software nodes and so on):
https://lore.kernel.org/netdev/20220224154040.2633a4e4@fixe.home/
>
> > For the moment ACPI node support is excluded from the fwnode support
> > to avoid creating an unspecified ACPI reset device description. With
> > these modifications, both driver that uses the fwnode_ API or the of_
> > API to register the reset controller will be usable by consumer
> > whatever the type of node that is used.
>
> Good, because controlling reset lines directly isn't how the ACPI device
> model works AFAIK.
This was based on Mark Brown feedback.
>
> > One question raised by this series is that I'm not sure if all reset
> > drivers should be modified to use the new fwnode support or keep the
> > existing device-tree support. Maintainer advice on that particular
> > question will be welcome.
>
> That would be pointless churn IMO. Why do we need to convert drivers
> which the vast majority will never use anything but DT?
To have a single interface to maintain and to remove duplicated fields
(of_node, fwnode, fwnode_xlate, of_xlate) from reset controller struct.
--
Clément Léger,
Embedded Linux and Kernel engineer at Bootlin
https://bootlin.com
next prev parent reply other threads:[~2022-04-05 7:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-24 14:12 [PATCH v2 0/3] add fwnode support to reset subsystem Clément Léger
2022-03-24 14:12 ` [PATCH v2 1/3] of: add function to convert fwnode_reference_args to of_phandle_args Clément Léger
2022-03-24 14:12 ` [PATCH v2 2/3] reset: add support for fwnode Clément Léger
2022-03-24 14:12 ` [PATCH v2 3/3] reset: mchp: sparx5: set fwnode field of reset controller Clément Léger
2022-04-04 17:41 ` [PATCH v2 0/3] add fwnode support to reset subsystem Rob Herring
2022-04-05 7:24 ` Clément Léger [this message]
2022-04-05 14:47 ` Rob Herring
2022-04-05 15:51 ` Clément Léger
2022-04-05 17:11 ` Rob Herring
2022-04-05 21:28 ` Rob Herring
2022-04-06 7:52 ` Clément Léger
2022-04-06 13:04 ` Rob Herring
2022-04-06 7:40 ` Clément Léger
2022-04-06 13:19 ` Rob Herring
2022-04-06 13:33 ` Alexandre Belloni
2022-04-06 13:36 ` Clément Léger
2022-04-08 15:48 ` Clément Léger
2022-04-25 10:21 ` Philipp Zabel
2022-04-25 11:18 ` Clément Léger
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=20220405092434.6e424ed4@fixe.home \
--to=clement.leger@bootlin.com \
--cc=Steen.Hegelund@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=allan.nielsen@microchip.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=lars.povlsen@microchip.com \
--cc=linux-kernel@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=thomas.petazzoni@bootlin.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 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.