public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Jerome Brunet <jbrunet@baylibre.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Kevin Hilman <khilman@baylibre.com>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	linux-amlogic@lists.infradead.org, linux-clk@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH] clk: amlogic: axg-audio: select RESET_MESON_AUX
Date: Tue, 03 Dec 2024 12:15:48 -0800	[thread overview]
Message-ID: <37b656cc8272552ba07c93c5a9a59641.sboyd@kernel.org> (raw)
In-Reply-To: <1jr06pkof6.fsf@starbuckisacylon.baylibre.com>

Quoting Jerome Brunet (2024-12-03 03:15:41)
> On Mon 02 Dec 2024 at 18:53, Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > I think the best approach is to add the reset auxilary device with a
> > function that creates the auxiliary device directly by string name and
> > does nothing else. Maybe we can have some helper in the auxiliary
> > layer that does that all for us, because it's quite a bit of boiler
> > plate that we need to write over and over again. Something like:
> >
> >   int devm_auxiliary_device_create(struct device *parent, const char *name)
> >
> > that does the whole kzalloc() + ida dance that
> > devm_meson_rst_aux_register() is doing today and wraps it all up so that
> > the device is removed when the parent driver unbinds. Then this clk
> > driver can register the reset device with a single call and not need to
> > do anything besides select AUXILIARY_BUS.
> 
> I think this is fairly close to what I proposed in the inital RFC, but
> generic instead of specific.

Ok :-/ I've realized that we need this sort of approach in more places
to logically split the device without making it SoC specific. It's only
useful to have the registration API live in the driver when we need to
call functions provided by that module from the driver registering the
auxiliary device.

> 
> I suspect the the generic path is likely to trigger more discussion.
> I'd like to be able to finish this migration, instead of leaving half
> finished like it is now.

Is the half finished migration a problem for this cycle? I was intending
to send the revert later this week and try again next cycle.

> 
> May I add back the boiler plate code in drivers/clk/meson, similar to
> what was proposed in the RFC [1] and propose the generic implementation
> in parallel ? It will just be a matter of switching when/if it is approved.

Sure. You can make devm_meson_clk_rst_aux_register() use the same
signature as I proposed above so that it's a one line patch later. And
definitely drop the imply RESET_MESON and depends on REGMAP part. Maybe
you can put it in the clkc-utils file?

  reply	other threads:[~2024-12-03 20:15 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-27 18:47 [PATCH] clk: amlogic: axg-audio: select RESET_MESON_AUX Jerome Brunet
2024-11-27 19:00 ` Mark Brown
2024-11-27 19:30 ` Arnd Bergmann
2024-11-27 20:56   ` Jerome Brunet
2024-11-27 21:23     ` Arnd Bergmann
2024-11-28 13:33       ` Jerome Brunet
2024-11-28 14:11         ` Arnd Bergmann
2024-11-28 14:39           ` Jerome Brunet
2024-11-28 14:51             ` Arnd Bergmann
2024-11-28 15:06               ` Jerome Brunet
2024-11-28 15:34                 ` Arnd Bergmann
2024-11-28 15:52                   ` Mark Brown
2024-11-28 15:57                     ` Arnd Bergmann
2024-11-28 16:02                       ` Jerome Brunet
2024-11-28 15:53                   ` Jerome Brunet
2024-11-28 17:21                     ` Arnd Bergmann
2024-12-03  2:53                   ` Stephen Boyd
2024-12-03 11:15                     ` Jerome Brunet
2024-12-03 20:15                       ` Stephen Boyd [this message]
2024-12-03 22:22                         ` Mark Brown
2024-12-03 22:32                           ` Stephen Boyd
2024-12-03 22:59                             ` Mark Brown
2024-12-04 17:19                         ` Jerome Brunet
2024-12-04 20:05                           ` Stephen Boyd
2024-12-04 20:10                           ` Arnd Bergmann
2024-12-03 12:43                     ` Arnd Bergmann
2024-12-03 20:21                       ` Stephen Boyd

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=37b656cc8272552ba07c93c5a9a59641.sboyd@kernel.org \
    --to=sboyd@kernel.org \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=jbrunet@baylibre.com \
    --cc=khilman@baylibre.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=mturquette@baylibre.com \
    --cc=neil.armstrong@linaro.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