All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Jerome Brunet <jbrunet@baylibre.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Jan Dakinevich <jan.dakinevich@salutedevices.com>,
	linux-kernel@vger.kernel.org, linux-amlogic@lists.infradead.org,
	linux-clk@vger.kernel.org
Subject: Re: [PATCH 7/8] reset: amlogic: add auxiliary reset driver support
Date: Mon, 15 Jul 2024 12:30:21 -0700	[thread overview]
Message-ID: <7db2d8ae07a9ef1a226dfd08a3f88f8a.sboyd@kernel.org> (raw)
In-Reply-To: <1jv81cgv4z.fsf@starbuckisacylon.baylibre.com>

Quoting Jerome Brunet (2024-07-11 02:01:16)
> On Wed 10 Jul 2024 at 15:49, Stephen Boyd <sboyd@kernel.org> wrote:
> 
> > Quoting Jerome Brunet (2024-07-10 09:25:16)
> >> diff --git a/drivers/reset/reset-meson.c b/drivers/reset/reset-meson.c
> >> index e34a10b15593..5cc767d50e8f 100644
> >> --- a/drivers/reset/reset-meson.c
> >> +++ b/drivers/reset/reset-meson.c
> > [...]
> >> +
> >> +int devm_meson_rst_aux_register(struct device *dev,
> >> +                               struct regmap *map,
> >> +                               const char *adev_name)
> >> +{
> >> +       struct meson_reset_adev *raux;
> >> +       struct auxiliary_device *adev;
> >> +       int ret;
> >> +
> >> +       raux = kzalloc(sizeof(*raux), GFP_KERNEL);
> >> +       if (!raux)
> >> +               return -ENOMEM;
> >> +
> >> +       ret = ida_alloc(&meson_rst_aux_ida, GFP_KERNEL);
> >
> > Do we expect more than one device with the same name? I wonder if the
> > IDA can be skipped.
> 
> I've wondered about that too.
> 
> I don't think it is the case right now but I'm not 100% sure.
> Since I spent time thinking about it, I thought it would just be safer (and
> relatively cheap) to put in and enough annoying debugging the
> expectation does not hold true.
> 
> I don't have a strong opinion on this. What do you prefer ?

I don't have a strong opinion either so it's fine to leave it there.

> >> diff --git a/include/soc/amlogic/meson-auxiliary-reset.h b/include/soc/amlogic/meson-auxiliary-reset.h
> >> new file mode 100644
> >> index 000000000000..8fdb02b18d8c
> >> --- /dev/null
> >> +++ b/include/soc/amlogic/meson-auxiliary-reset.h
> >> @@ -0,0 +1,23 @@
> >> +/* SPDX-License-Identifier: GPL-2.0 */
> >> +#ifndef __SOC_AMLOGIC_MESON_AUX_RESET_H
> >> +#define __SOC_AMLOGIC_MESON_AUX_RESET_H
> >> +
> >> +#include <linux/err.h>
> >> +
> >> +struct device;
> >> +struct regmap;
> >> +
> >> +#ifdef CONFIG_RESET_MESON
> >> +int devm_meson_rst_aux_register(struct device *dev,
> >> +                               struct regmap *map,
> >> +                               const char *adev_name);
> >> +#else
> >> +static inline int devm_meson_rst_aux_register(struct device *dev,
> >> +                                             struct regmap *map,
> >> +                                             const char *adev_name)
> >> +{
> >> +       return -EOPNOTSUPP;
> >
> > Shouldn't this be 'return 0' so that the clk driver doesn't have to care
> > about the config?
> 
> I don't think the system (in general) would be able function without the reset
> driver, so the question is rather phylosophical.
> 
> Let's say it could, if this returns 0, consumers of the reset controller
> will defer indefinitely ... which is always a bit more difficult to sort
> out.
> 
> If it returns an error, the problem is pretty obvious, helping people
> solve it quickly.
> 
> Also the actual device we trying to register provides clocks and reset.
> It is not like the reset is an optional part we don't care about.
> 
> On this instance it starts from clock, but it could have been the other
> way around. Both are equally important.
> 
> I'd prefer if it returns an error when the registration can't even start.
> 

Ok. Fair enough.

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@kernel.org>
To: Jerome Brunet <jbrunet@baylibre.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Jan Dakinevich <jan.dakinevich@salutedevices.com>,
	linux-kernel@vger.kernel.org, linux-amlogic@lists.infradead.org,
	linux-clk@vger.kernel.org
Subject: Re: [PATCH 7/8] reset: amlogic: add auxiliary reset driver support
Date: Mon, 15 Jul 2024 12:30:21 -0700	[thread overview]
Message-ID: <7db2d8ae07a9ef1a226dfd08a3f88f8a.sboyd@kernel.org> (raw)
In-Reply-To: <1jv81cgv4z.fsf@starbuckisacylon.baylibre.com>

Quoting Jerome Brunet (2024-07-11 02:01:16)
> On Wed 10 Jul 2024 at 15:49, Stephen Boyd <sboyd@kernel.org> wrote:
> 
> > Quoting Jerome Brunet (2024-07-10 09:25:16)
> >> diff --git a/drivers/reset/reset-meson.c b/drivers/reset/reset-meson.c
> >> index e34a10b15593..5cc767d50e8f 100644
> >> --- a/drivers/reset/reset-meson.c
> >> +++ b/drivers/reset/reset-meson.c
> > [...]
> >> +
> >> +int devm_meson_rst_aux_register(struct device *dev,
> >> +                               struct regmap *map,
> >> +                               const char *adev_name)
> >> +{
> >> +       struct meson_reset_adev *raux;
> >> +       struct auxiliary_device *adev;
> >> +       int ret;
> >> +
> >> +       raux = kzalloc(sizeof(*raux), GFP_KERNEL);
> >> +       if (!raux)
> >> +               return -ENOMEM;
> >> +
> >> +       ret = ida_alloc(&meson_rst_aux_ida, GFP_KERNEL);
> >
> > Do we expect more than one device with the same name? I wonder if the
> > IDA can be skipped.
> 
> I've wondered about that too.
> 
> I don't think it is the case right now but I'm not 100% sure.
> Since I spent time thinking about it, I thought it would just be safer (and
> relatively cheap) to put in and enough annoying debugging the
> expectation does not hold true.
> 
> I don't have a strong opinion on this. What do you prefer ?

I don't have a strong opinion either so it's fine to leave it there.

> >> diff --git a/include/soc/amlogic/meson-auxiliary-reset.h b/include/soc/amlogic/meson-auxiliary-reset.h
> >> new file mode 100644
> >> index 000000000000..8fdb02b18d8c
> >> --- /dev/null
> >> +++ b/include/soc/amlogic/meson-auxiliary-reset.h
> >> @@ -0,0 +1,23 @@
> >> +/* SPDX-License-Identifier: GPL-2.0 */
> >> +#ifndef __SOC_AMLOGIC_MESON_AUX_RESET_H
> >> +#define __SOC_AMLOGIC_MESON_AUX_RESET_H
> >> +
> >> +#include <linux/err.h>
> >> +
> >> +struct device;
> >> +struct regmap;
> >> +
> >> +#ifdef CONFIG_RESET_MESON
> >> +int devm_meson_rst_aux_register(struct device *dev,
> >> +                               struct regmap *map,
> >> +                               const char *adev_name);
> >> +#else
> >> +static inline int devm_meson_rst_aux_register(struct device *dev,
> >> +                                             struct regmap *map,
> >> +                                             const char *adev_name)
> >> +{
> >> +       return -EOPNOTSUPP;
> >
> > Shouldn't this be 'return 0' so that the clk driver doesn't have to care
> > about the config?
> 
> I don't think the system (in general) would be able function without the reset
> driver, so the question is rather phylosophical.
> 
> Let's say it could, if this returns 0, consumers of the reset controller
> will defer indefinitely ... which is always a bit more difficult to sort
> out.
> 
> If it returns an error, the problem is pretty obvious, helping people
> solve it quickly.
> 
> Also the actual device we trying to register provides clocks and reset.
> It is not like the reset is an optional part we don't care about.
> 
> On this instance it starts from clock, but it could have been the other
> way around. Both are equally important.
> 
> I'd prefer if it returns an error when the registration can't even start.
> 

Ok. Fair enough.

  reply	other threads:[~2024-07-15 19:30 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-10 16:25 [PATCH 0/8] reset: amlogic: move audio reset drivers out of CCF Jerome Brunet
2024-07-10 16:25 ` Jerome Brunet
2024-07-10 16:25 ` [PATCH 1/8] reset: amlogic: convert driver to regmap Jerome Brunet
2024-07-10 16:25   ` Jerome Brunet
2024-07-18  2:39   ` Jan Dakinevich
2024-07-18  2:39     ` Jan Dakinevich
2024-07-18  7:19     ` Jerome Brunet
2024-07-18  7:19       ` Jerome Brunet
2024-07-18 11:01       ` Jan Dakinevich
2024-07-18 11:01         ` Jan Dakinevich
2024-07-18 19:29         ` Stephen Boyd
2024-07-18 19:29           ` Stephen Boyd
2024-08-08 10:15           ` Jerome Brunet
2024-08-08 10:15             ` Jerome Brunet
2024-07-10 16:25 ` [PATCH 2/8] reset: amlogic: add driver parameters Jerome Brunet
2024-07-10 16:25   ` Jerome Brunet
2024-07-10 22:34   ` Stephen Boyd
2024-07-10 22:34     ` Stephen Boyd
2024-07-10 16:25 ` [PATCH 3/8] reset: amlogic: split the device and platform probe Jerome Brunet
2024-07-10 16:25   ` Jerome Brunet
2024-07-10 22:38   ` Stephen Boyd
2024-07-10 22:38     ` Stephen Boyd
2024-07-15 22:48   ` Jan Dakinevich
2024-07-15 22:48     ` Jan Dakinevich
2024-07-16 12:17     ` Jerome Brunet
2024-07-16 12:17       ` Jerome Brunet
2024-07-10 16:25 ` [PATCH 4/8] reset: amlogic: use reset number instead of register count Jerome Brunet
2024-07-10 16:25   ` Jerome Brunet
2024-07-10 16:25 ` [PATCH 5/8] reset: amlogic: add reset status support Jerome Brunet
2024-07-10 16:25   ` Jerome Brunet
2024-07-10 22:40   ` Stephen Boyd
2024-07-10 22:40     ` Stephen Boyd
2024-07-11  8:41     ` Jerome Brunet
2024-07-11  8:41       ` Jerome Brunet
2024-07-10 16:25 ` [PATCH 6/8] reset: amlogic: add toggle reset support Jerome Brunet
2024-07-10 16:25   ` Jerome Brunet
2024-07-10 16:25 ` [PATCH 7/8] reset: amlogic: add auxiliary reset driver support Jerome Brunet
2024-07-10 16:25   ` Jerome Brunet
2024-07-10 22:49   ` Stephen Boyd
2024-07-10 22:49     ` Stephen Boyd
2024-07-11  9:01     ` Jerome Brunet
2024-07-11  9:01       ` Jerome Brunet
2024-07-15 19:30       ` Stephen Boyd [this message]
2024-07-15 19:30         ` Stephen Boyd
2024-07-18  7:05         ` Jerome Brunet
2024-07-18  7:05           ` Jerome Brunet
2024-07-11 13:02   ` kernel test robot
2024-07-11 13:02     ` kernel test robot
2024-07-11 19:03   ` kernel test robot
2024-07-11 19:03     ` kernel test robot
2024-07-10 16:25 ` [PATCH 8/8] clk: amlogic: axg-audio: use the auxiliary reset driver Jerome Brunet
2024-07-10 16:25   ` Jerome Brunet
2024-07-15 22:45 ` [PATCH 0/8] reset: amlogic: move audio reset drivers out of CCF Jan Dakinevich
2024-07-15 22:45   ` Jan Dakinevich

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=7db2d8ae07a9ef1a226dfd08a3f88f8a.sboyd@kernel.org \
    --to=sboyd@kernel.org \
    --cc=jan.dakinevich@salutedevices.com \
    --cc=jbrunet@baylibre.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=p.zabel@pengutronix.de \
    /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.