[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240923100741.11277439@bootlin.com>
Date: Mon, 23 Sep 2024 10:07:41 +0200
From: Herve Codina <herve.codina@...tlin.com>
To: Lee Jones <lee@...nel.org>, Arnd Bergmann <arnd@...db.de>, Steen
Hegelund <Steen.Hegelund@...rochip.com>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>, Andy Shevchenko
<andy.shevchenko@...il.com>, Simon Horman <horms@...nel.org>, Derek Kiernan
<derek.kiernan@....com>, Dragan Cvetic <dragan.cvetic@....com>, Greg
Kroah-Hartman <gregkh@...uxfoundation.org>, Bjorn Helgaas
<bhelgaas@...gle.com>, Philipp Zabel <p.zabel@...gutronix.de>, Lars Povlsen
<lars.povlsen@...rochip.com>, Daniel Machon <daniel.machon@...rochip.com>,
UNGLinuxDriver@...rochip.com, Rob Herring <robh@...nel.org>, Saravana
Kannan <saravanak@...gle.com>, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo
Abeni <pabeni@...hat.com>, Horatiu Vultur <horatiu.vultur@...rochip.com>,
Andrew Lunn <andrew@...n.ch>, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, linux-pci@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org, Allan
Nielsen <allan.nielsen@...rochip.com>, Luca Ceresoli
<luca.ceresoli@...tlin.com>, Thomas Petazzoni
<thomas.petazzoni@...tlin.com>, Clément Léger
<clement.leger@...tlin.com>
Subject: Re: [PATCH v5 3/8] mfd: syscon: Add reference counting and device
managed support
Hi,
On Thu, 12 Sep 2024 15:37:40 +0100
Lee Jones <lee@...nel.org> wrote:
> On Mon, 09 Sep 2024, Herve Codina wrote:
>
> > Hi Lee, Arnd,
> >
> > On Tue, 3 Sep 2024 18:01:16 +0200
> > Herve Codina <herve.codina@...tlin.com> wrote:
> >
> > > Hi Lee,
> > >
> > > On Tue, 3 Sep 2024 16:38:39 +0100
> > > Lee Jones <lee@...nel.org> wrote:
> > >
> > > > On Thu, 08 Aug 2024, Herve Codina wrote:
> > > >
> > > > > From: Clément Léger <clement.leger@...tlin.com>
> > > > >
> > > > > Syscon releasing is not supported.
> > > > > Without release function, unbinding a driver that uses syscon whether
> > > > > explicitly or due to a module removal left the used syscon in a in-use
> > > > > state.
> > > > >
> > > > > For instance a syscon_node_to_regmap() call from a consumer retrieves a
> > > > > syscon regmap instance. Internally, syscon_node_to_regmap() can create
> > > > > syscon instance and add it to the existing syscon list. No API is
> > > > > available to release this syscon instance, remove it from the list and
> > > > > free it when it is not used anymore.
> > > > >
> > > > > Introduce reference counting in syscon in order to keep track of syscon
> > > > > usage using syscon_{get,put}() and add a device managed version of
> > > > > syscon_regmap_lookup_by_phandle(), to automatically release the syscon
> > > > > instance on the consumer removal.
> > > > >
> > > > > Signed-off-by: Clément Léger <clement.leger@...tlin.com>
> > > > > Signed-off-by: Herve Codina <herve.codina@...tlin.com>
> > > > > ---
> > > > > drivers/mfd/syscon.c | 138 ++++++++++++++++++++++++++++++++++---
> > > > > include/linux/mfd/syscon.h | 16 +++++
> > > > > 2 files changed, 144 insertions(+), 10 deletions(-)
> > > >
> > > > This doesn't look very popular.
> > > >
> > > > What are the potential ramifications for existing users?
> > > >
> > >
> > > Existing user don't use devm_syscon_regmap_lookup_by_phandle() nor
> > > syscon_put_regmap().
> > >
> > > So refcount is incremented but never decremented. syscon is never
> > > released. Exactly the same as current implementation.
> > > Nothing change for existing users.
> > >
> > > Best regards,
> > > Hervé
> >
> > I hope I answered to Lee's question related to possible impacts on
> > existing drivers.
> >
> > Is there anything else that blocks this patch from being applied ?
>
> Arnd usually takes care of Syscon reviews.
>
> Perhaps he's out on vacation.
>
> Let's wait a little longer, since it's too late for this cycle anyway.
>
Discussed the topic with Arnd Bergmann at Linux Plumbers Conference.
Adding ref-counting and support for removal in syscon is rejected by Arnd.
For my LAN966x use case (syscon is used only by the reset controller), the
solution is to remove the syscon device and handle directly the reset protect
register in the reset controller itself.
I will propose modifications in that way in the next iteration.
Regards,
Hervé
Powered by blists - more mailing lists