linux-clk.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
To: Stephen Boyd <sboyd@kernel.org>
Cc: mazziesaccount@gmail.com, mturquette@baylibre.com,
	cw00.choi@samsung.com, krzk@kernel.org, b.zolnierkie@samsung.com,
	linux@armlinux.org.uk, andy.gross@linaro.org,
	david.brown@linaro.org, pavel@ucw.cz, andrew.smirnov@gmail.com,
	pombredanne@nexb.com, sjhuang@iluvatar.ai, akshu.agrawal@amd.com,
	djkurtz@chromium.org, rafael.j.wysocki@intel.com,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 03/10] clk: of-provider: look at parent if registered device has no provider info
Date: Wed, 5 Dec 2018 09:00:46 +0200	[thread overview]
Message-ID: <20181205070046.GD31204@localhost.localdomain> (raw)
In-Reply-To: <154395229720.88331.16585219136189943316@swboyd.mtv.corp.google.com>

Hello Stephen,

I copied some parts of the v4 discussion here as well. Let's continue
them under this one email thread. (and yep, this is my bad we now have
multiple email threads - I did these new patches without waiting for
the final conclusion. I should try to be more patient in the future...)

> > > I think we should use parent device's node, not the paren node in DT,        
> > > right? But I agree, we should only look "one level up in the chain".         
                                                                                 
> > Are these two things different? I'm suggesting looking at                      
> > device_node::parent and trying to find a #clock-cells property.                
                                                                                 
> I thought that MFD sub-devices may completely lack the DT node but I
> will verify this tomorrow.

So yep. It appears that the DT node for MFD sub-device is left NULL.
This is quite logical as there really is no clk sub-node in MFD (pmic)
node. The option to "hack around" this would be setting the of_node to
parent node in driver code. But this feels wrong. Drivers should not
mess with the "dt node ownership" - and it also feels a bit odd when
many devices use same DT node. I think we may hit in problems when
obtaining resources or doing reference counting. Hence I think we should
keep the of_node NULL for sub-device if the sub-device does not have own
node inside the main devie node. And I think Rob was not a fan of having
own nodes for sub-devices inside the MFD node (AFAIR my first driver
draft for this device had it but Rob and you thought that was not correct).

On Tue, Dec 04, 2018 at 11:38:17AM -0800, Stephen Boyd wrote:
> Quoting Matti Vaittinen (2018-12-04 03:34:53)
> > It seems to be usual for MFD devices that the created 'clock sub-device'
> > do not have own DT node. The clock provider information is usually in the
> > main device node which is owned by the MFD device. Change the devm variant
> > of clk of-provider registration to check the parent device node if given
> > device has no own node or if the node does not contain the #clock-cells
> > property. In such case use the parent node if it contains the #clock-cells.
> > 
> > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> > ---
> >  drivers/clk/clk.c | 27 +++++++++++++++++++++++----
> >  1 file changed, 23 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index 78c90913f987..66dc7c1483d7 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -3893,6 +3893,11 @@ static void devm_of_clk_release_provider(struct device *dev, void *res)
> >         of_clk_del_provider(*(struct device_node **)res);
> >  }
> >  
> > +static int of_is_clk_provider(struct device_node *np)
> > +{
> > +       return !!of_find_property(np, "#clock-cells", NULL);
> > +}
> > +
> >  /**
> >   * devm_of_clk_add_hw_provider() - Managed clk provider node registration
> >   * @dev: Device acting as the clock provider. Used for DT node and lifetime.
> > @@ -3901,8 +3906,11 @@ static void devm_of_clk_release_provider(struct device *dev, void *res)
> >   *
> >   * Returns 0 on success or an errno on failure.
> >   *
> > - * Registers clock provider for given device's node. Provider is automatically
> > - * released at device exit.
> > + * Registers clock provider for given device's node. If the device has no DT
> > + * node or if the device node lacks of clock provider information (#clock-cells)
> > + * then the parent device's node is scanned for this information. If parent node
> > + * has the #clock-cells then it is used in registration. Provider is
> > + * automatically released at device exit.
> >   */
> >  int devm_of_clk_add_hw_provider(struct device *dev,
> >                         struct clk_hw *(*get)(struct of_phandle_args *clkspec,
> > @@ -3912,12 +3920,17 @@ int devm_of_clk_add_hw_provider(struct device *dev,
> >         struct device_node **ptr, *np;
> >         int ret;
> >  
> > +       np = dev->of_node;
> > +
> > +       if (!of_is_clk_provider(dev->of_node))
> > +               if (of_is_clk_provider(dev->parent->of_node))
> > +                       np = dev->parent->of_node;
> 
> As said on v5, let's just modify of_clk_add_provider() to do the parent
> search.

But that won't solve the issue if we don't do "dirty hacks" in driver.
The devm interface still only gets the device-pointer, not the DT node
as argument. And if DT node for device is NULL (like in MFD cases) -
then there is no parent node, only parent device with a node. For plain
of_clk_add_provider() the driver can just give the parent's node pointer
in cases where it knows it is the parent who has the provider data in
DT. But our original problem is in devm interfaces.

Br,
	Matti Vaittinen

-- 
Matti Vaittinen
ROHM Semiconductors

~~~ "I don't think so," said Rene Descartes.  Just then, he vanished ~~~

  reply	other threads:[~2018-12-05  7:00 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-04 11:31 [PATCH v6 00/10] clk: clkdev/of_clk - add managed lookup and provider registrations Matti Vaittinen
2018-12-04 11:33 ` [PATCH v6 01/10] clkdev: add managed clkdev lookup registration Matti Vaittinen
2018-12-04 11:33 ` [PATCH v6 02/10] clk: Add kerneldoc to managed of-provider interfaces Matti Vaittinen
2018-12-04 19:39   ` Stephen Boyd
2018-12-04 11:34 ` [PATCH v6 03/10] clk: of-provider: look at parent if registered device has no provider info Matti Vaittinen
2018-12-04 19:38   ` Stephen Boyd
2018-12-05  7:00     ` Matti Vaittinen [this message]
2018-12-05 17:19       ` Stephen Boyd
2018-12-05 18:20         ` Matti Vaittinen
2018-12-05 18:28           ` Matti Vaittinen
2018-12-05 19:35           ` Stephen Boyd
2018-12-04 11:35 ` [PATCH v6 04/10] clk: clk-max77686: Clean clkdev lookup leak and use devm Matti Vaittinen
2018-12-04 11:37 ` [PATCH v6 05/10] clk: clk-st: avoid clkdev lookup leak at remove Matti Vaittinen
2018-12-04 11:37 ` [PATCH v6 06/10] clk: clk-hi655x: Free of_provider " Matti Vaittinen
2018-12-05 17:25   ` Stephen Boyd
2018-12-04 11:38 ` [PATCH v6 07/10] clk: rk808: use managed version of of_provider registration Matti Vaittinen
2018-12-05 17:25   ` Stephen Boyd
2018-12-04 11:38 ` [PATCH v6 08/10] clk: clk-twl6040: Free of_provider at remove Matti Vaittinen
2018-12-05 17:25   ` Stephen Boyd
2018-12-04 11:39 ` [PATCH v6 09/10] clk: apcs-msm8916: simplify probe cleanup by using devm Matti Vaittinen
2018-12-05 17:25   ` Stephen Boyd
2018-12-04 11:39 ` [PATCH v6 10/10] clk: bd718x7: Initial support for ROHM bd71837/bd71847 PMIC clock Matti Vaittinen
2018-12-05 17:28   ` Stephen Boyd
2018-12-05 18:24     ` Matti Vaittinen
2018-12-05 20:17     ` Pavel Machek
2018-12-04 11:45 ` [PATCH v6 00/10] clk: clkdev/of_clk - add managed lookup and provider registrations Matti Vaittinen

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=20181205070046.GD31204@localhost.localdomain \
    --to=matti.vaittinen@fi.rohmeurope.com \
    --cc=akshu.agrawal@amd.com \
    --cc=andrew.smirnov@gmail.com \
    --cc=andy.gross@linaro.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=cw00.choi@samsung.com \
    --cc=david.brown@linaro.org \
    --cc=djkurtz@chromium.org \
    --cc=krzk@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mazziesaccount@gmail.com \
    --cc=mturquette@baylibre.com \
    --cc=pavel@ucw.cz \
    --cc=pombredanne@nexb.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=sboyd@kernel.org \
    --cc=sjhuang@iluvatar.ai \
    /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).