lkml.org 
[lkml]   [2018]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v4 1/8] clk: clkdev/of_clk - add managed lookup and provider registrations
    Hello Stephen & All,

    I created v5 where I fixed obvious issues. I'll send it in few minutes.
    Please note following topics:

    On Fri, Nov 30, 2018 at 12:50:22PM +0200, Matti Vaittinen wrote:
    >
    > On Fri, Nov 30, 2018 at 12:54:10AM -0800, Stephen Boyd wrote:
    > > Quoting Matti Vaittinen (2018-11-13 03:55:58)
    > > >
    > > > -int devm_of_clk_add_hw_provider(struct device *dev,
    > > > +static int __devm_of_clk_add_hw_provider(struct device *dev,
    > > > struct clk_hw *(*get)(struct of_phandle_args *clkspec,
    > > > void *data),
    > > > - void *data)
    > > > + struct device_node *of_node, void *data)
    > > > {
    > > > - struct device_node **ptr, *np;
    > > > + struct device_node **ptr;
    > > > int ret;
    > > >
    > > > ptr = devres_alloc(devm_of_clk_release_provider, sizeof(*ptr),
    > > > @@ -3906,10 +3906,9 @@ int devm_of_clk_add_hw_provider(struct device *dev,
    > > > if (!ptr)
    > > > return -ENOMEM;
    > > >
    > > > - np = dev->of_node;
    > > > - ret = of_clk_add_hw_provider(np, get, data);
    > > > + *ptr = of_node;
    > > > + ret = of_clk_add_hw_provider(of_node, get, data);
    > > > if (!ret) {
    > > > - *ptr = np;
    > >
    > > Why is this moved outside of the if condition?
    > I completely removed the local variable np and just unconditionally set
    > the allocated devres to point at the node (if allocation succeeded). We
    > could of course only do this if the provider registration succeeded and
    > save one assignment - but I guess I intended to remove the curly braces
    > and thus decided to go for one liner after if. But apparently I didn't
    > remove the braces O_o. Well, I can put the assignment inside the
    > condition if you prefer that.
    >
    > > In fact, why isn't just
    > > the first line in this hunk deleted and passed to this function as
    > > struct device_node *np?
    >
    > I am sorry but I don't quite follow your suggestion here. Do you mean we
    > could just pass the struct device_node *np in devres_add()? I thought
    > the pointer passed to devress_add() should be allocated using
    > devres_alloc. Can you please elaborate what you mean?

    I could not really spot what to fix in patched code (see below).

    static int __devm_of_clk_add_hw_provider(struct device *dev,
    struct clk_hw *(*get)(struct of_phandle_args *clkspec,
    void *data),
    struct device_node *of_node, void *data)
    {
    struct device_node **ptr;
    int ret;

    ptr = devres_alloc(devm_of_clk_release_provider, sizeof(*ptr),
    GFP_KERNEL);
    if (!ptr)
    return -ENOMEM;

    *ptr = of_node;
    ret = of_clk_add_hw_provider(of_node, get, data);
    if (!ret)
    devres_add(dev, ptr);
    else
    devres_free(ptr);

    return ret;
    }

    As far as I understand we need to allocate the ptr using devres_alloc.
    We also need to pass this ptr to of_clk_add_hw_provider - and we must
    assign our node to the *ptr. (I removed the extra braces - this change
    is laso included in v5 but I don't see how we should improve). Can you
    please explain me if you still wish to me change this further?

    > > > +int devm_of_clk_add_parent_hw_provider(struct device *dev,
    > > > + struct clk_hw *(*get)(struct of_phandle_args *clkspec,
    > > > + void *data),
    > > > + void *data)
    > > > +{
    > > > + return __devm_of_clk_add_hw_provider(dev, get, dev->parent->of_node,
    > >
    > > I'm wondering if we can somehow auto-detect this in
    > > devm_of_clk_add_hw_provider() by looking for #clock-cells in the node.
    > > If it isn't there, then we go to the parent node and look for a
    > > #clock-cells property there in the DT node for that device. Does that
    > > make sense? Then there isn't any new API and we can attach the lifetime
    > > of the devm registration to the presence of the property indicating this
    > > is a clk controller or not.
    >
    > Huh. I don't know why but building this kind of logic in core is a bit
    > scary to me. I guess I can try implementing something like this - but I
    > am not really a fan of this. (Accidentally) omit the #clock-cells from
    > node and we go to parent node - I am a novice on this area but this
    > sounds like a potential hazard to me. I believe the driver should know
    > if it's properties should be in own or parent node - and if they are
    > not, then there should be no guessing but error. The lifetime is topic
    > where I would like to get information from you who know the kernel
    > better than I do =) But I guess the parent node is there at least as
    > long as the child device is alive. So for me the life time of
    > get-callback is more crucial - but as I said, I don't understand the
    > kernel in details so you probably know it better than me. But please let
    > me know your final take on this and I will follow the guidance =)

    I did not put the 'auto-detection' for provider node in the patch v5 as
    it really gives me bad vibes :) Maybe it is just my pessimistic nature
    but I do expect that problems will arise when we accidentally end up in
    parent node when this is not the purpose. I would rather keep this
    simple by adding one specific API function more - and keeping the
    existing API specific as well. But I can do v5 if you insist on having
    this auto-detection.

    --
    Matti Vaittinen
    ROHM Semiconductors

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

    \
     
     \ /
      Last update: 2018-12-03 13:17    [W:4.487 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site