linux-kernel - Re: [v8] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

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] [day] [month] [year] [list]

Date:   Tue, 08 May 2018 10:43:54 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Taniya Das <tdas@...eaurora.org>
Cc:     Andy Gross <andy.gross@...aro.org>,
        David Brown <david.brown@...aro.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Amit Nischal <anischal@...eaurora.org>,
        linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [v8] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

Quoting Taniya Das (2018-05-08 09:57:36)
> On 5/8/2018 5:58 AM, Stephen Boyd wrote:
> > Quoting Taniya Das (2018-05-07 03:48:06)
> >> Will be okay, if I can the following?
> >>
> >> _probe...
> >> {
> >>          struct clk_rpmh_desc *hw_desc_data;
> >>          ....
> >>
> >>          hw_desc_data = kmemdup(desc, sizeof(*desc), GFP_KERNEL);
> >>
> >>          ...
> >>          ret = devm_of_clk_add_hw_provider(&pdev->dev,     of_clk_rpmh_hw_get,
> >> hw_desc_data);
> >>           ....
> >>
> >> }
> >>
> >> And also I fix the "getter" function.
> > 
> > I'd rather see the check for out of bounds number just go away, unless
> > that's helping something. The kmemdup() doesn't look good.
> > 
> 
> I think it is better to copy the desc data to "clk_hw_onecell_data", as 
> I would also have to fix the "getter" function to check for out of bound 
> numbers (idx >= num_clks).
> 

Hmm ok. It would be nicer if we didn't have to duplicate the pointers
just because of const though. I'd rather have the cast away of const and
a comment indicating we know what we're doing. Maybe in the future we
can make the getter function take a const void pointer.