Hello Stephen, On Mon Oct 7, 2024 at 3:49 PM CEST, Théo Lebrun wrote: > This series adds a platform driver dealing with read-only PLLs derived > from the main crystal, and some divider clocks based on those PLLs. It > also acts at the one instantiating reset and pinctrl auxiliary devices. I'd be curious to get feedback on this series? Could it make it before the next merge window? V4 fixed all your comments but one. You implied the linked list might be useless, but I am not convinced: > I had a pending question [0], asking for confirmation that the static > linked list to inherit cells from of_clk_init() stage to platform > device probe is indeed the right solution. As -rc1 got released I sent > the new revision anyway. > > [0]: https://lore.kernel.org/lkml/D4ELMFAUQYZ7.3LXGQZJSX68UF@xxxxxxxxxxx/ Quoting here the original email for full context: On Tue Sep 24, 2024 at 4:53 PM CEST, Théo Lebrun wrote: > On Wed Sep 18, 2024 at 7:28 AM CEST, Stephen Boyd wrote: > > Quoting Théo Lebrun (2024-07-30 09:04:46) > > > + list_add_tail(&priv->list, &eqc_list); > > > > The list is also kind of unnecessary. Set a bool in the match_data and > > move on? We could have some sort of static_assert() check to make sure > > if there's a CLK_OF_DECLARE_DRIVER() then the bool is set in the > > match_data for the driver. Such a design is cheaper than taking a lock, > > adding to a list. > > This list's main goal is not to know what was early-inited. Its only > reason for existence is that we want to get, at eqc_probe(), the cells > pointer allocated at eqc_init(). > > struct eqc_priv { > /* this field is why we store priv inside a linked list: */ > struct clk_hw_onecell_data *cells; > /* the rest, we don't care much: */ > const struct eqc_early_match_data *early_data; > const struct eqc_match_data *data; > void __iomem *base; > struct device_node *np; > struct list_head list; > }; > > I do not see how to do that with a bool. We could put the pointer into > the match data, but that would mean we'd have to make them writable > (currently static const data). We are talking about a linked list with > two items in the worst case (EyeQ6H), accessed twice. > > The reason we store the whole of priv: simpler code and we avoid mapping > registers twice (once at eqc_init() and once at eqc_probe()). > > Can you confirm the current static linked list approach (without any > spinlock) will be good for next revision? Thanks, -- Théo Lebrun, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
