Re: [PATCH v2 1/7] clk: Add a generic clock infrastructure

From: Turquette, Mike
Date: Fri Oct 14 2011 - 14:14:40 EST


On Thu, Sep 22, 2011 at 3:26 PM, Mike Turquette <mturquette@xxxxxx> wrote:
> From: Jeremy Kerr <jeremy.kerr@xxxxxxxxxxxxx>
>  struct clk_hw_ops {
>        int             (*prepare)(struct clk_hw *);
>        void            (*unprepare)(struct clk_hw *);
>        int             (*enable)(struct clk_hw *);
>        void            (*disable)(struct clk_hw *);
>        unsigned long   (*recalc_rate)(struct clk_hw *);

In implementing recalc for divider clocks, I started to wonder, "why
not just pass struct clk *clk into the clk_hw_ops func ptrs?".

recalc is an obvious example whereby we need access to parent->rate.
The code usually ends up looking something like:

unsigned long omap_recalc_rate(struct clk_hw *hw)
{
struct clk *parent;
struct clk_hw_omap *oclk;

parent = hw->clk->parent;
oclk = to_clk_omap(hw);
...
}

That's a bit of a song and dance to have to do in almost every op, and
often these ops will need access to stuff like clk->rate also. Is
there any opposition to just passing in struct clk? e.g:

unsigned long omap_recalc_rate(struct clk *clk)
{
struct clk *parent;
struct clk_hw_omap *oclk;

parent = clk->parent;
oclk = to_clk_omap(clk->hw);
...
}

It is a small nitpick, but it affects the API for everybody so best to
get it right now before folks start migrating over to it.

Thanks,
Mike

>        int             (*set_rate)(struct clk_hw *,
>                                        unsigned long, unsigned long *);
>        long            (*round_rate)(struct clk_hw *, unsigned long);
>        int             (*set_parent)(struct clk_hw *, struct clk *);
>        struct clk *    (*get_parent)(struct clk_hw *);
>  };
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/