[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1j1puq2xb1.fsf@starbuckisacylon.baylibre.com>
Date: Fri, 21 Mar 2025 16:55:14 +0100
From: Jerome Brunet <jbrunet@...libre.com>
To: Stephen Boyd <sboyd@...nel.org>
Cc: Kevin Hilman <khilman@...libre.com>, Martin Blumenstingl
<martin.blumenstingl@...glemail.com>, Michael Turquette
<mturquette@...libre.com>, Neil Armstrong <neil.armstrong@...aro.org>,
linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-amlogic@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/3] clk: amlogic: drop clk_regmap tables
On Fri 21 Mar 2025 at 16:46, Jerome Brunet <jbrunet@...libre.com> wrote:
>>>
>>> I admit this is heavily inspired by how devres works :) but it does solve
>>> the early clock controller problem and does not scale with the number of
>>> clock registered.
>>>
>>
>> I don't know if devres is a good model. It's about tracking allocations
>> and things to undo later, not really to track things to do when called
>> initially.
>
> My point was more the decoupling it allows.
> Maybe it is me being too picky, but what I'm trying to do is related to the
> clock type, so it bothers me when it scales with the number of instances
> instead of the type.
>
> More generally, something devres-like allows to register an attribute
> and link it to a group. Then the group members come and just pick what
> they need. Whatever manages the attribute does not have to track
> them. That is pretty much aligned with what I'm trying to do.
Just to be clear, this idea is meant to live in /drivers/clk/meson, for
a start a least, not as something generic.
--
Jerome
Powered by blists - more mailing lists