linux-kernel - Re: [PATCH 7/9] clk: Allow parents to be specified without string names

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: <121ae6212cd555bc784af675d63f6b190c0bee10.camel@baylibre.com>
Date:   Wed, 13 Feb 2019 10:32:23 +0100
From:   Jerome Brunet <jbrunet@...libre.com>
To:     Stephen Boyd <sboyd@...nel.org>,
        Michael Turquette <mturquette@...libre.com>
Cc:     linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Russell King <linux@...linux.org.uk>
Subject: Re: [PATCH 7/9] clk: Allow parents to be specified without string
 names

On Tue, 2019-01-29 at 10:56 -0800, Stephen Boyd wrote:
> > > +/**
> > > + * struct clk_parent_data - clk parent information
> > > + * @hw: parent clk_hw pointer (used for clk providers with internal
> > > clks)
> > > + * @name: parent name local to provider registering clk
> > > + * @fallback: globally unique parent name (used as a fallback)
> > > + */
> > > +struct clk_parent_data {
> > > +     struct clk_hw   *hw;
> > > +     const char      *name;
> > > +     const char      *fallback;

One last nitpick about this structure, because I did not figure it out at
first.

'fallback' is what we known as 'name' in CCF so far.

What do you think about renaming 'fallback' to 'name' and 'name' to something
more obvious, like 'of_name' or 'fw_name' or something else ?

> > 
> > If I understand correctly, .name and .fallback will be ignored if hw is
> > provided ? Maybe this should be documented somehow ?
> 
> Sure. I'll add some documentation to the long portion of the kernel-doc
> here describing priority order.

Anyway, with this patch, I should be able to remove a lot of (ugly) code I
have been writting lately. I'll be happy to test it when you have a v2 ready.