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:   Fri, 07 Aug 2020 14:42:43 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Michael Turquette <mturquette@...libre.com>,
        Taniya Das <tdas@...eaurora.org>
Cc:     David Brown <david.brown@...aro.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
        Andy Gross <agross@...nel.org>, devicetree@...r.kernel.org,
        robh@...nel.org, robh+dt@...nel.org
Subject: Re: [PATCH v5 4/4] clk: qcom: lpass: Add support for LPASS clock controller for SC7180

Quoting Taniya Das (2020-08-05 22:23:05)
> On 8/6/2020 1:54 AM, Stephen Boyd wrote:
> >> +                               .hw = &core_clk_src.clkr.hw,
> >> +                       },
> >> +                       .num_parents = 1,
> >> +                       .flags = CLK_SET_RATE_PARENT,
> >> +                       .ops = &clk_branch2_ops,
> >> +               },
> >> +       },
> >> +};
> >> +
> >> +static struct clk_regmap *lpass_core_cc_sc7180_clocks[] = {
> >> +       [EXT_MCLK0_CLK_SRC] = &ext_mclk0_clk_src.clkr,
> >> +       [LPAIF_PRI_CLK_SRC] = &lpaif_pri_clk_src.clkr,
> >> +       [LPAIF_SEC_CLK_SRC] = &lpaif_sec_clk_src.clkr,
> >> +       [CORE_CLK_SRC] = &core_clk_src.clkr,
> > 
> > And all of these, can they have LPASS_ prefix on the defines? Seems
> > like we're missing a namespace otherwise.
> > 
> 
> These are generated as they are in the HW plan. Do you still think I 
> should update them?
> 

As long as there aren't going to be conflicts in the clk names I guess
it's OK to do nothing here.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ