linux-kernel - Re: [PATCH v5 3/5] clk: meson: a1: add support for Amlogic A1 PLL 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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 9 Jan 2020 15:55:17 +0800
From:   Jian Hu <jian.hu@...ogic.com>
To:     Martin Blumenstingl <martin.blumenstingl@...glemail.com>
CC:     Jerome Brunet <jbrunet@...libre.com>,
        Neil Armstrong <narmstrong@...libre.com>,
        Kevin Hilman <khilman@...libre.com>,
        Rob Herring <robh@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Qiufang Dai <qiufang.dai@...ogic.com>,
        Jianxin Pan <jianxin.pan@...ogic.com>,
        Victor Wan <victor.wan@...ogic.com>,
        Chandle Zou <chandle.zou@...ogic.com>,
        <linux-clk@...r.kernel.org>, <linux-amlogic@...ts.infradead.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 3/5] clk: meson: a1: add support for Amlogic A1 PLL
 clock driver



On 2019/12/28 1:04, Martin Blumenstingl wrote:
> Hi Jian,
> 
> On Fri, Dec 27, 2019 at 10:46 AM Jian Hu <jian.hu@...ogic.com> wrote:
> [...]
>> +               .parent_data = &(const struct clk_parent_data){
>> +                       .fw_name = "xtal_fixpll",
>> +               },
> in the Meson8b and G12A (I assume it's the same on GXBB, I didn't
> check it) we have a space between " clk_parent_data)" and "{"
> this applies to at least one more occurrence below
> 
I have checked G12A and Meson8b, there is a space.The space is missing 
here, the same as other place. I will fix it in next version.
> [...]
>> +               /*
>> +                * This clock is used by APB bus which setted in Romcode
> nit-pick: I'm not sure about the grammar here: setted -> "is set"?
> and to make sure I understand this correctly: do you mean the "boot
> ROM" with "Romcode"?
You are right, it is a mistake here. 'is set' is right.
Yes, Romcode means boot ROM. I will change it to 'boot ROM code'
> 
> [...]
>> +static int meson_a1_pll_probe(struct platform_device *pdev)
>> +{
>> +       const struct meson_eeclkc_data *data;
> what do you need this "data" variable for?
> 
>> +       struct device *dev = &pdev->dev;
>> +       struct resource *res;
>> +       void __iomem *base;
>> +       struct regmap *map;
>> +       int ret, i;
>> +
>> +       data = of_device_get_match_data(dev);
>> +       if (!data)
>> +               return -EINVAL;
>> +
>> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +
>> +       base = devm_ioremap_resource(dev, res);
>> +       if (IS_ERR(base))
>> +               return PTR_ERR(base);
>> +
>> +       map = devm_regmap_init_mmio(dev, base, &clkc_regmap_config);
>> +       if (IS_ERR(map))
>> +              return PTR_ERR(map);
>> +
>> +       /* Populate regmap for the regmap backed clocks */
>> +       for (i = 0; i < data->regmap_clk_num; i++)
>> +               data->regmap_clks[i]->map = map;
> why can't we use a1_pll_regmaps directly here?
> 
OK, I will use it directly .
>> +
>> +       for (i = 0; i < data->hw_onecell_data->num; i++) {
>> +               /* array might be sparse */
>> +               if (!data->hw_onecell_data->hws[i])
>> +                       continue;
>> +
>> +               ret = devm_clk_hw_register(dev, data->hw_onecell_data->hws[i]);
> and why can't we use a1_pll_hw_onecell_data directly here?
> 
OK, I will use it directly.
> [...]
>> +static const struct meson_eeclkc_data a1_pll_data = {
>> +               .regmap_clks = a1_pll_regmaps,
>> +               .regmap_clk_num = ARRAY_SIZE(a1_pll_regmaps),
>> +               .hw_onecell_data = &a1_pll_hw_onecell_data,
>> +};
> if _probe would access these directly then you can drop meson_eeclkc_data
> that is a good thing in my opinion because I was confused by the
> "eeclk" since the patch description says that there's no EE or AO
> domain on the A1 SoCs
> 
OK, I will remove it and verify it.
> 
> Martin
> 
> .
>