linux-kernel - Re: [PATCH v5 0/4] Add Mobileye EyeQ clock support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3412c930fdb120032478c65e90e4b971.sboyd@kernel.org>
Date: Thu, 17 Oct 2024 11:42:59 -0700
From: Stephen Boyd <sboyd@...nel.org>
To: Conor Dooley <conor+dt@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Michael Turquette <mturquette@...libre.com>, Rob Herring <robh@...nel.org>, Théo Lebrun <theo.lebrun@...tlin.com>
Cc: devicetree@...r.kernel.org, linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org, Vladimir Kondratiev <vladimir.kondratiev@...ileye.com>, Grégory Clement <gregory.clement@...tlin.com>, Thomas Petazzoni <thomas.petazzoni@...tlin.com>, Tawfik Bayouk <tawfik.bayouk@...ileye.com>, Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Subject: Re: [PATCH v5 0/4] Add Mobileye EyeQ clock support

Quoting Théo Lebrun (2024-10-15 01:50:26)
> 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@bootlin.com/
> 
> Quoting here the original email for full context:

Thanks!

> 
> 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;

This is __initconst and won't be valid after init, which is possible if
the driver probe is delayed beyond the time that init memory is freed.

> >       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.

Ah I missed that you were trying to stash the onecell data away. You can
register a clk provider for the same node more than once. The first
"early" one can return an error pointer for the clk indices that will be
registered later. The second onecell data can be registered in the
regular driver probe and return the clks that are registered later. See
of_clk_get_hw_from_clkspec() and how it keeps trying to find a clk if
the provider that matches the node didn't return a valid pointer.

> >
> > 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()).

The IO mapping code handles duplicate mappings internally by returning
the previous virtual address. It doesn't hurt to call it again.

> >
> > Can you confirm the current static linked list approach (without any
> > spinlock) will be good for next revision?
> 

Getting rid of the list will make the code simpler and avoid the driver
probe path from accessing the early data. Please do it!