public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>, Jerome Brunet <jbrunet@baylibre.com>
Cc: 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:21:52 -0800	[thread overview]
Message-ID: <c9556de589e289cb1d278d41014791a6.sboyd@kernel.org> (raw)
In-Reply-To: <0f07300a-8b32-4d3e-a447-b3fe3cf1ca81@app.fastmail.com>

Quoting Arnd Bergmann (2024-12-03 04:43:03)
> On Tue, Dec 3, 2024, at 03:53, Stephen Boyd wrote:
> > Quoting Arnd Bergmann (2024-11-28 07:34:46)
> >> On Thu, Nov 28, 2024, at 16:06, Jerome Brunet wrote:
> >> Stephen, can you please take a look here and see if you
> >> have a better idea for either decoupling the two drivers
> >> enough to avoid the link time dependency, or to reintegrate
> >> the reset controller code into the clk driver and avoid
> >> the complexity?
> >
> > 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. The regmap can be acquired
> > from the parent device in the auxiliary driver probe with
> > dev_get_regmap(adev->parent).
> 
> I like the idea. Two questions about the interface:
> 
>  - should there be a 'void *platform_data' argument anyway?
>    Even if this can be looked up from the parent, it seems
>    useful enough

Sure. Probably that can be added as some variant like
devm_auxiliary_device_create_pdata() when/if it's needed.

> 
>  - What is the scope of the 'ida' number? My impression was
>    this should be local to one parent device, but I don't
>    know how the number is used in the end, so maybe a global
>    number allocator is sufficient.
> 

From what I can tell it's only used for the device name and not for
driver matching. That's probably to make it so we don't get conflicts in
sysfs with devices because they all share the same bus. I'd guess that a
global allocator is sufficient.

      reply	other threads:[~2024-12-03 20:21 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
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 [this message]

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=c9556de589e289cb1d278d41014791a6.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