Re: [PATCH 00/25] clk: sunxi-ng: clk parent rewrite part 1

Hi Stephen,

On Mon, May 20, 2019 at 5:03 PM Maxime Ripard [off-list ref] wrote:

On Mon, May 20, 2019 at 04:03:56PM +0800, Chen-Yu Tsai wrote:

quoted

From: Chen-Yu Tsai <redacted>

Hi everyone,

This is series is the first part of a large series (I haven't done the
rest) of patches to rewrite the clk parent relationship handling within
the sunxi-ng clk driver. This is based on Stephen's recent work allowing
clk drivers to specify clk parents using struct clk_hw * or parsing DT
phandles in the clk node.

This series can be split into a few major parts:

1) The first patch is a small fix for clk debugfs representation. This
   was done before commit 1a079560b145 ("clk: Cache core in
   clk_fetch_parent_index() without names") was posted, so it might or
   might not be needed. Found this when checking my work using
   clk_possible_parents.

2) A bunch of CLK_HW_INIT_* helper macros are added. These cover the
   situations I encountered, or assume I will encounter, such as single
   internal (struct clk_hw *) parent, single DT (struct clk_parent_data
   .fw_name), multiple internal parents, and multiple mixed (internal +
   DT) parents. A special variant for just an internal single parent is
   added, CLK_HW_INIT_HWS, which lets the driver share the singular
   list, instead of having the compiler create a compound literal every
   time. It might even make sense to only keep this variant.

3) A bunch of CLK_FIXED_FACTOR_* helper macros are added. The rationale
   is the same as the single parent CLK_HW_INIT_* helpers.

4) Bulk conversion of CLK_FIXED_FACTOR to use local parent references,
   either struct clk_hw * or DT .fw_name types, whichever the hardware
   requires.

5) The beginning of SUNXI_CCU_GATE conversion to local parent
   references. This part is not done. They are included as justification
   and examples for the shared list of clk parents case.

That series is pretty neat. As far as sunxi is concerned, you can add my
Acked-by: Maxime Ripard <redacted>

quoted

I realize this is going to be many patches every time I convert a clock
type. Going forward would the people involved prefer I send out
individual patches like this series, or squash them all together?

For bisection, I guess it would be good to keep the approach you've
had in this series. If this is really too much, I guess we can always
change oru mind later on.

Any thoughts on this series and how to proceed?

Thanks
ChenYu

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel