All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matti Vaittinen <mazziesaccount@gmail.com>
To: Stephen Boyd <sboyd@kernel.org>
Cc: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
	broonie@kernel.org, lee.jones@linaro.org, lgirdwood@gmail.com,
	mark.rutland@arm.com, mazziesaccount@gmail.com,
	mturquette@baylibre.com, robh+dt@kernel.org,
	linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, mikko.mutanen@fi.rohmeurope.com,
	heikki.haikola@fi.rohmeurope.com
Subject: Re: [PATCH v4 5/6] clk: bd71837: Add driver for BD71837 PMIC clock
Date: Fri, 1 Jun 2018 10:31:56 +0300	[thread overview]
Message-ID: <20180601073156.GC5150@localhost.localdomain> (raw)
In-Reply-To: <152777943977.144038.10971658990200651749@swboyd.mtv.corp.google.com>

First of all - Thanks for looking at this!

On Thu, May 31, 2018 at 08:10:39AM -0700, Stephen Boyd wrote:
> Quoting Matti Vaittinen (2018-05-30 01:43:19)
> > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> > index 41492e980ef4..4b045699bb5e 100644
> > --- a/drivers/clk/Kconfig
> > +++ b/drivers/clk/Kconfig
> > @@ -279,6 +279,15 @@ config COMMON_CLK_STM32H7
> >         ---help---
> >           Support for stm32h7 SoC family clocks
> >  
> > +config COMMON_CLK_BD71837
> > +       tristate "Clock driver for ROHM BD71837 PMIC MFD"
> > +       depends on MFD_BD71837
> > +       depends on I2C=y
> 
> Why depend on I2C=y?

I added this because the PMIC is connected via i2c. But as you ask this
- and as you probably knew my answer - I guess this is not correct. So
I guess depends on MFD_BD71837 should be sufficient and the MFD portion
should hide the fact we sit on I2C? If this is the case - I will remove
this.

> 
> > +       depends on OF
> 
> Why depend on OF?

You're right. This is not needed. I'll remove this.

> 
> > +       help
> > +         This driver supports ROHM BD71837 PMIC clock.
> > +
> > +
> >  source "drivers/clk/bcm/Kconfig"
> >  source "drivers/clk/hisilicon/Kconfig"
> >  source "drivers/clk/imgtec/Kconfig"
> > diff --git a/drivers/clk/clk-bd71837.c b/drivers/clk/clk-bd71837.c
> > new file mode 100644
> > index 000000000000..91456d1077ac
> > --- /dev/null
> > +++ b/drivers/clk/clk-bd71837.c
> > @@ -0,0 +1,151 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (C) 2018 ROHM Semiconductors
> > +// bd71837.c  -- ROHM BD71837MWV clock driver
> > +
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/init.h>
> > +#include <linux/err.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/slab.h>
> > +#include <linux/mfd/bd71837.h>
> > +#include <linux/clk-provider.h>
> > +#include <linux/clkdev.h>
> > +
> > +static int bd71837_clk_enable(struct clk_hw *hw);
> > +static void bd71837_clk_disable(struct clk_hw *hw);
> > +static int bd71837_clk_is_enabled(struct clk_hw *hw);
> > +
> > +struct bd71837_clk {
> > +       struct clk_hw hw;
> > +       uint8_t reg;
> > +       uint8_t mask;
> > +       unsigned long rate;
> > +       struct platform_device *pdev;
> > +       struct bd71837 *mfd;
> > +};
> > +
> > +static unsigned long bd71837_clk_recalc_rate(struct clk_hw *hw,
> > +                                            unsigned long parent_rate);
> > +
> > +static const struct clk_ops bd71837_clk_ops = {
> > +       .recalc_rate = &bd71837_clk_recalc_rate,
> > +       .prepare = &bd71837_clk_enable,
> > +       .unprepare = &bd71837_clk_disable,
> > +       .is_prepared = &bd71837_clk_is_enabled,
> > +};
> 
> Move this structure after the function definitions. And drop the forward
> declared functions.

Allright.

> 
> > +
> > +static int bd71837_clk_set(struct clk_hw *hw, int status)
> > +{
> > +       struct bd71837_clk *c = container_of(hw, struct bd71837_clk, hw);
> > +
> > +       return bd71837_update_bits(c->mfd, c->reg, c->mask, status);
> > +}
> > +
> > +static void bd71837_clk_disable(struct clk_hw *hw)
> > +{
> > +       int rv;
> > +       struct bd71837_clk *c = container_of(hw, struct bd71837_clk, hw);
> > +
> > +       rv = bd71837_clk_set(hw, 0);
> > +       if (rv)
> > +               dev_err(&c->pdev->dev, "Failed to disable 32K clk (%d)\n", rv);
> 
> Why is a disable error message more important than an enable error
> message?  Please drop this message and rely on callers to indicate if
> enabling their clk didn't work for some reason.

Reason is that the disable function is not returning error. So if I drop
the print there will be no indication of error, right?

> 
> > +}
> > +
> > +static int bd71837_clk_enable(struct clk_hw *hw)
> > +{
> > +       return bd71837_clk_set(hw, 1);
> > +}
> > +
> > +static int bd71837_clk_is_enabled(struct clk_hw *hw)
> > +{
> > +       struct bd71837_clk *c = container_of(hw, struct bd71837_clk, hw);
> > +
> > +       return c->mask & bd71837_reg_read(c->mfd, c->reg);
> 
> Please put this on two or more lines so we know what the type of
> bd71837_reg_read() returns:
> 
> 	u32 reg = bd71837_reg_read(....)
> 
> 	return c->mask & reg;
> 

Right. I'll do this.

> 
> > +}
> > +
> > +static unsigned long bd71837_clk_recalc_rate(struct clk_hw *hw,
> > +                                            unsigned long parent_rate)
> > +{
> > +       struct bd71837_clk *c = container_of(hw, struct bd71837_clk, hw);
> > +
> > +       return c->rate;
> 
> Recalc rate should read the hardware instead of returning a cached rate
> unless it can't actually read hardware.

We can't read the rate from HW. And actually, as this is fixed rate
clock generator - is the recalc_rate needed at all?

> 
> > +}
> > +
> > +static int bd71837_clk_probe(struct platform_device *pdev)
> > +{
> > +       struct bd71837_clk *c;
> > +       int rval = -ENOMEM;
> > +       struct bd71837 *mfd = dev_get_drvdata(pdev->dev.parent);
> > +       const char *errstr = "memory allocation for bd71837 data failed";
> 
> We don't need allocation error messages.

Correct. I'll remove.

> 
> > +       struct clk_init_data init = {
> > +               .name = "bd71837-32k-out",
> > +               .ops = &bd71837_clk_ops,
> > +       };
> > +
> > +       c = kzalloc(sizeof(struct bd71837_clk), GFP_KERNEL);
> 
> Use sizeof(*c) instead so we don't have to worry about type mismatches.

Ok.

> 
> > +       if (!c)
> > +               goto err_out;
> > +
> > +       c->reg = BD71837_REG_OUT32K;
> > +       c->mask = BD71837_OUT32K_EN;
> > +       c->rate = BD71837_CLK_RATE;
> 
> Is the plan to have more clks supported by this driver in the future?
> Because right now it seems to make a structure up and then hardcode the
> members for a single clk so I'm not sure why those registers aren't just
> hardcoded in the clk_ops functions that use them.

(At least) one more chip from this series is coming and I am planning to
support it with this driver. I am not sure if the registers will stay
the same. Hence I rather not hardcode the register values.

> 
> > +       c->mfd = mfd;
> > +       c->pdev = pdev;
> > +
> > +       if (pdev->dev.of_node)
> 
> If there isn't an of_node it would be NULL, and then calling the
> function below would cause it to not update the init name? Seems like it
> could be called unconditionally.

Right.

> 
> > +               of_property_read_string_index(pdev->dev.of_node,
> > +                                             "clock-output-names", 0,
> > +                                             &init.name);
> > +
> > +       c->hw.init = &init;
> > +
> > +       errstr = "failed to register 32K clk";
> 
> The 'errstr' thing is not standard. Please just call dev_err() directly
> with the string you want to print. And consider not printing anything at
> all.

I think this technique is actually used in many places at net side. I
guess i have adobted this habit from some netlink message handling code.
I can change this to in-place prints if it fits environment better
though.

> 
> > +       rval = clk_hw_register(&pdev->dev, &c->hw);
> > +       if (rval)
> > +               goto err_free;
> > +
> > +       errstr = "failed to register clkdev for bd71837";
> > +       rval = clk_hw_register_clkdev(&c->hw, init.name, NULL);
> 
> Are you using the clkdev lookup? Or this is just added for backup
> purposes? If this is a mostly DT driver then please drop this part of
> the patch and rely on of_clk_hw_add_provider() to handle the lookup
> instead.

I did this because this is how I get the clk_get to work in my test
driver. Problem is that I don't know how this clock is going to be used
- and I lack of knowledge how these things are usually done. I don't
know the clock consumer code so this was best I could think of. But if
this is not how things are usually handled I can remove the clkdev and
rely on of_clk_add_hw_provider. Would this be correct then:

> 
> > +       if (rval)
> > +               goto err_unregister;
> > +
> > +       platform_set_drvdata(pdev, c);
> > +       dev_dbg(&pdev->dev, "bd71837_clk successfully probed\n");
> 
> There's a pr_debug() in really_probe() for this.

Oh, thanks. I'll remove this debug.

> 
> > +
> > +       return 0;
> > +
> > +err_unregister:
> > +       clk_hw_unregister(&c->hw);
> > +err_free:
> > +       kfree(c);
> > +err_out:
> > +       dev_err(&pdev->dev, "%s\n", errstr);
> > +       return rval;
> > +}
> > +
> > +static int bd71837_clk_remove(struct platform_device *pdev)
> > +{
> > +       struct bd71837_clk *c = platform_get_drvdata(pdev);
> > +
> > +       if (c) {
> > +               clk_hw_unregister(&c->hw);
> 
> Use devm to register clks.
> 
> > +               kfree(c);
> 
> and devm_kzalloc()

Right. Thanks - devm makes this simpler.

> 
> > +               platform_set_drvdata(pdev, NULL);
> 
> This doesn't need to be done. Drop it.

Allright. Will drop.

> 
> > +       }
> > +       return 0;
> > +}
> > +



Br,
	Matti Vaittinen

  reply	other threads:[~2018-06-01  7:31 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-30  8:41 [PATCH v4 0/6] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver Matti Vaittinen
2018-05-30  8:41 ` [PATCH v4 1/6] mfd: bd71837: mfd driver for ROHM BD71837 PMIC Matti Vaittinen
2018-05-30  8:42 ` [PATCH v4 2/6] mfd: bd71837: Devicetree bindings " Matti Vaittinen
2018-05-31  3:01   ` Rob Herring
2018-05-31  7:17     ` Matti Vaittinen
2018-05-31 10:23       ` Matti Vaittinen
2018-05-31 14:07         ` Rob Herring
2018-05-31 14:57           ` Stephen Boyd
2018-05-31 14:57             ` Stephen Boyd
2018-06-01 10:51             ` Matti Vaittinen
2018-06-02  6:30               ` Stephen Boyd
2018-06-02  6:30                 ` Stephen Boyd
2018-06-02  6:30                 ` Stephen Boyd
2018-06-01  6:25           ` Matti Vaittinen
2018-06-01 17:32             ` Rob Herring
2018-06-04 11:32               ` Matti Vaittinen
2018-06-05 15:46                 ` Rob Herring
2018-06-06  7:34                   ` Matti Vaittinen
2018-06-06 15:16                     ` Rob Herring
2018-06-07 11:12                       ` Matti Vaittinen
2018-06-15 13:20                         ` Matti Vaittinen
2018-05-30  8:42 ` [PATCH v4 3/6] regulator: bd71837: Devicetree bindings for BD71837 regulators Matti Vaittinen
2018-05-31  3:04   ` Rob Herring
2018-05-31  7:21     ` Matti Vaittinen
2018-05-31 14:00       ` Rob Herring
2018-05-31 14:00         ` Rob Herring
2018-05-30  8:42 ` [PATCH v4 4/6] clk: bd71837: Devicetree bindings for ROHM BD71837 PMIC Matti Vaittinen
2018-05-31  3:05   ` Rob Herring
2018-05-30  8:43 ` [PATCH v4 5/6] clk: bd71837: Add driver for BD71837 PMIC clock Matti Vaittinen
2018-05-31 15:10   ` Stephen Boyd
2018-05-31 15:10     ` Stephen Boyd
2018-06-01  7:31     ` Matti Vaittinen [this message]
2018-06-01 17:11       ` Stephen Boyd
2018-06-01 17:11         ` Stephen Boyd
2018-06-01 17:11         ` Stephen Boyd
2018-05-30  8:43 ` [PATCH v4 6/6] regulator: bd71837: BD71837 PMIC regulator driver Matti Vaittinen
2018-05-30 11:02   ` Applied "regulator: bd71837: BD71837 PMIC regulator driver" to the regulator tree Mark Brown
2018-05-30 11:02     ` Mark Brown
2018-05-30 11:14     ` Matti Vaittinen
2018-05-30 11:17       ` Mark Brown
2018-05-30 12:58         ` Matti Vaittinen
2018-05-30 14:34           ` Mark Brown
2018-05-30  9:05 ` [PATCH v4 0/6] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver Matti Vaittinen
2018-05-30 11:00   ` Mark Brown
2018-05-30 12:56     ` Matti Vaittinen
2018-05-30 15:41       ` Mark Brown

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=20180601073156.GC5150@localhost.localdomain \
    --to=mazziesaccount@gmail.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=heikki.haikola@fi.rohmeurope.com \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=matti.vaittinen@fi.rohmeurope.com \
    --cc=mikko.mutanen@fi.rohmeurope.com \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@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 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.