linux-kernel - Re: [PATCH 05/10] clk: qcom: add Global Clock controller (GCC) driver for IPQ5332 SoC

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]

Date:   Wed, 25 Jan 2023 12:54:37 -0800
From:   Stephen Boyd <sboyd@...nel.org>
To:     Kathiravan Thirumoorthy <quic_kathirav@...cinc.com>,
        agross@...nel.org, andersson@...nel.org, arnd@...db.de,
        bhupesh.sharma@...aro.org, broonie@...nel.org,
        catalin.marinas@....com, devicetree@...r.kernel.org,
        dmitry.baryshkov@...aro.org, konrad.dybcio@...aro.org,
        krzysztof.kozlowski+dt@...aro.org, linus.walleij@...aro.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
        linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mmc@...r.kernel.org, marcel.ziswiler@...adex.com,
        mturquette@...libre.com, nfraprado@...labora.com,
        quic_gurus@...cinc.com, robh+dt@...nel.org, robimarko@...il.com,
        shawnguo@...nel.org, ulf.hansson@...aro.org, will@...nel.org
Cc:     Kathiravan T <quic_kathirav@...cinc.com>
Subject: Re: [PATCH 05/10] clk: qcom: add Global Clock controller (GCC) driver for IPQ5332 SoC

Quoting Kathiravan Thirumoorthy (2023-01-25 02:45:15)
> diff --git a/drivers/clk/qcom/gcc-ipq5332.c b/drivers/clk/qcom/gcc-ipq5332.c
> new file mode 100644
> index 000000000000..8351096a4d32
> --- /dev/null
> +++ b/drivers/clk/qcom/gcc-ipq5332.c
> @@ -0,0 +1,3954 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/regmap.h>
[...]
> +
> +static const struct freq_tbl ftbl_gcc_pcnoc_bfdcd_clk_src[] = {
> +       F(24000000, P_XO, 1, 0, 0),
> +       F(50000000, P_GPLL0_OUT_MAIN, 16, 0, 0),
> +       F(100000000, P_GPLL0_OUT_MAIN, 8, 0, 0),
> +       { }
> +};
> +
> +static struct clk_rcg2 gcc_pcnoc_bfdcd_clk_src = {
> +       .cmd_rcgr = 0x31004,
> +       .mnd_width = 0,
> +       .hid_width = 5,
> +       .parent_map = gcc_parent_map_0,
> +       .freq_tbl = ftbl_gcc_pcnoc_bfdcd_clk_src,
> +       .clkr.hw.init = &(const struct clk_init_data){
> +               .name = "gcc_pcnoc_bfdcd_clk_src",
> +               .parent_data = gcc_parent_data_0,
> +               .num_parents = ARRAY_SIZE(gcc_parent_data_0),
> +               .ops = &clk_rcg2_ops,
> +               .flags = CLK_IS_CRITICAL,

Why not just turn these clks on in probe and never register them with
the framework? That saves some memory for clks that there is no desire
to control from linux. This is an RCG, so in theory the frequency can
change, but does it really? Usually bus clks are controlled by the
interconnect driver.