devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Nuno Sá" <noname.nuno@gmail.com>
To: Alexandru Ardelean <aardelean@baylibre.com>,
	Alisa-Dariana Roman <alisadariana@gmail.com>
Cc: Alisa-Dariana Roman <alisa.roman@analog.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Michael Hennerich <michael.hennerich@analog.com>,
	 linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	 linux-kernel@vger.kernel.org,
	Lars-Peter Clausen <lars@metafoo.de>,
	Jonathan Cameron <jic23@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	 Conor Dooley <conor+dt@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH v6 5/6] iio: adc: ad7192: Add clock provider
Date: Wed, 26 Jun 2024 14:16:19 +0200	[thread overview]
Message-ID: <a72569f7c1f5d9a7158fe774179ec8fc76016168.camel@gmail.com> (raw)
In-Reply-To: <CA+GgBR8r_W9X0hROUEw-xePyKAhOTBjJtf=cHbfWfvUUfk5j_g@mail.gmail.com>

On Tue, 2024-06-25 at 08:48 +0300, Alexandru Ardelean wrote:
> On Mon, Jun 24, 2024 at 3:51 PM Alisa-Dariana Roman
> <alisadariana@gmail.com> wrote:
> > 
> > Internal clock of AD719X devices can be made available on MCLK2 pin. Add
> > clock provider to support this functionality.
> > 
> 
> Just a question that should be addressed by the failing of the
> clock-provider registration.
> With that addressed:
> 
> Reviewed-by: Alexandru Ardelean <aardelean@baylibre.com>
> 
> > Signed-off-by: Alisa-Dariana Roman <alisa.roman@analog.com>
> > ---
> >  drivers/iio/adc/ad7192.c | 89 ++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 89 insertions(+)
> > 
> > diff --git a/drivers/iio/adc/ad7192.c b/drivers/iio/adc/ad7192.c
> > index 940517df5429..90763c14679d 100644
> > --- a/drivers/iio/adc/ad7192.c
> > +++ b/drivers/iio/adc/ad7192.c
> > @@ -8,6 +8,7 @@
> >  #include <linux/interrupt.h>
> >  #include <linux/bitfield.h>
> >  #include <linux/clk.h>
> > +#include <linux/clk-provider.h>
> >  #include <linux/device.h>
> >  #include <linux/kernel.h>
> >  #include <linux/slab.h>
> > @@ -201,6 +202,7 @@ struct ad7192_chip_info {
> >  struct ad7192_state {
> >         const struct ad7192_chip_info   *chip_info;
> >         struct clk                      *mclk;
> > +       struct clk_hw                   int_clk_hw;
> >         u16                             int_vref_mv;
> >         u32                             aincom_mv;
> >         u32                             fclk;
> > @@ -401,6 +403,88 @@ static const char *const ad7192_clock_names[] = {
> >         "mclk"
> >  };
> > 
> > +static struct ad7192_state *clk_hw_to_ad7192(struct clk_hw *hw)
> > +{
> > +       return container_of(hw, struct ad7192_state, int_clk_hw);
> > +}
> > +
> > +static unsigned long ad7192_clk_recalc_rate(struct clk_hw *hw,
> > +                                           unsigned long parent_rate)
> > +{
> > +       return AD7192_INT_FREQ_MHZ;
> > +}
> > +
> > +static int ad7192_clk_output_is_enabled(struct clk_hw *hw)
> > +{
> > +       struct ad7192_state *st = clk_hw_to_ad7192(hw);
> > +
> > +       return st->clock_sel == AD7192_CLK_INT_CO;
> > +}
> > +
> > +static int ad7192_clk_prepare(struct clk_hw *hw)
> > +{
> > +       struct ad7192_state *st = clk_hw_to_ad7192(hw);
> > +       int ret;
> > +
> > +       st->mode &= ~AD7192_MODE_CLKSRC_MASK;
> > +       st->mode |= AD7192_CLK_INT_CO;
> > +
> > +       ret = ad_sd_write_reg(&st->sd, AD7192_REG_MODE, 3, st->mode);
> > +       if (ret)
> > +               return ret;
> > +
> > +       st->clock_sel = AD7192_CLK_INT_CO;
> > +
> > +       return 0;
> > +}
> > +
> > +static void ad7192_clk_unprepare(struct clk_hw *hw)
> > +{
> > +       struct ad7192_state *st = clk_hw_to_ad7192(hw);
> > +       int ret;
> > +
> > +       st->mode &= ~AD7192_MODE_CLKSRC_MASK;
> > +       st->mode |= AD7192_CLK_INT;
> > +
> > +       ret = ad_sd_write_reg(&st->sd, AD7192_REG_MODE, 3, st->mode);
> > +       if (ret)
> > +               return;
> > +
> > +       st->clock_sel = AD7192_CLK_INT;
> > +}
> > +
> > +static const struct clk_ops ad7192_int_clk_ops = {
> > +       .recalc_rate = ad7192_clk_recalc_rate,
> > +       .is_enabled = ad7192_clk_output_is_enabled,
> > +       .prepare = ad7192_clk_prepare,
> > +       .unprepare = ad7192_clk_unprepare,
> > +};
> > +
> > +static int ad7192_register_clk_provider(struct ad7192_state *st)
> > +{
> > +       struct device *dev = &st->sd.spi->dev;
> > +       struct clk_init_data init = {};
> > +       int ret;
> > +
> > +       if (!IS_ENABLED(CONFIG_COMMON_CLK))
> > +               return 0;
> > +
> > +       init.name = devm_kasprintf(dev, GFP_KERNEL, "%s-clk",
> > +                                  fwnode_get_name(dev_fwnode(dev)));
> > +       if (!init.name)
> > +               return -ENOMEM;
> > +
> > +       init.ops = &ad7192_int_clk_ops;
> > +
> > +       st->int_clk_hw.init = &init;
> > +       ret = devm_clk_hw_register(dev, &st->int_clk_hw);
> > +       if (ret)
> > +               return ret;
> > +
> > +       return devm_of_clk_add_hw_provider(dev, of_clk_hw_simple_get,
> > +                                          &st->int_clk_hw);
> > +}
> > +
> >  static int ad7192_clock_setup(struct ad7192_state *st)
> >  {
> >         struct device *dev = &st->sd.spi->dev;
> > @@ -412,6 +496,11 @@ static int ad7192_clock_setup(struct ad7192_state *st)
> >         if (ret < 0) {
> >                 st->clock_sel = AD7192_CLK_INT;
> >                 st->fclk = AD7192_INT_FREQ_MHZ;
> > +
> > +               ret = ad7192_register_clk_provider(st);
> > +               if (ret)
> > +                       return dev_err_probe(dev, ret,
> > +                                            "Failed to register clock
> > provider\n");
> 
> A question here: do we want to fail the probe of this driver when it
> cannot register a clock provider?
> Or should we ignore it?
> No preference from my side.

Sensible question... I would say it depends. On one side this is an optional
feature so we should not (arguably) error out. OTOH, someone may really want
(and relies on) this feature so failing makes sense.

Maybe we should have

if (!device_property_present(&spi->dev, "#clock-cells"))
	return 0;

in ad7192_register_clk_provider(). So that if we fail the function, then yes, we
should fail probing as FW wants this to be a provider. Also, not providing
#clock-cells means we don't register the clock.

Having said the above I think that failing devm_clk_hw_register() means that
something is already really wrong (or we have a bug in the driver) so likely we
should keep it simple and just always provide the clock and return an error if
we fail to do so.

my 2 cents...

- Nuno Sá



  reply	other threads:[~2024-06-26 12:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-24 12:49 [PATCH v6 0/6] iio: adc: ad7192: Improvements Alisa-Dariana Roman
2024-06-24 12:49 ` [PATCH v6 1/6] iio: adc: ad7192: use devm_regulator_get_enable_read_voltage Alisa-Dariana Roman
2024-06-30  9:41   ` Jonathan Cameron
2024-06-24 12:49 ` [PATCH v6 2/6] dt-bindings: iio: adc: ad7192: Update clock config Alisa-Dariana Roman
2024-06-24 16:17   ` Conor Dooley
2024-06-24 12:49 ` [PATCH v6 3/6] " Alisa-Dariana Roman
2024-06-25  5:30   ` Alexandru Ardelean
2024-06-30  9:45     ` Jonathan Cameron
2024-06-24 12:49 ` [PATCH v6 4/6] dt-bindings: iio: adc: ad7192: Add clock provider Alisa-Dariana Roman
2024-06-24 16:17   ` Conor Dooley
2024-06-30  9:58   ` Jonathan Cameron
2024-06-24 12:49 ` [PATCH v6 5/6] " Alisa-Dariana Roman
2024-06-25  5:48   ` Alexandru Ardelean
2024-06-26 12:16     ` Nuno Sá [this message]
2024-06-30  9:54       ` Jonathan Cameron
2024-06-30 11:43         ` Conor Dooley
2024-06-24 12:49 ` [PATCH v6 6/6] MAINTAINERS: Update AD7192 driver maintainer Alisa-Dariana Roman
2024-06-30  9:59   ` Jonathan Cameron

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=a72569f7c1f5d9a7158fe774179ec8fc76016168.camel@gmail.com \
    --to=noname.nuno@gmail.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=aardelean@baylibre.com \
    --cc=alisa.roman@analog.com \
    --cc=alisadariana@gmail.com \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jic23@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.com \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.hennerich@analog.com \
    --cc=robh@kernel.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;
as well as URLs for NNTP newsgroup(s).