linux-kernel - Re: [PATCH v1 15/30] clk: starfive: Use regmap APIs to operate registers

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:   Fri, 30 Sep 2022 14:48:21 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Hal Feng <hal.feng@...ux.starfivetech.com>,
        devicetree@...r.kernel.org, linux-clk@...r.kernel.org,
        linux-gpio@...r.kernel.org, linux-riscv@...ts.infradead.org
Cc:     Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Marc Zyngier <maz@...nel.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Michael Turquette <mturquette@...libre.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Emil Renner Berthing <kernel@...il.dk>,
        Hal Feng <hal.feng@...ux.starfivetech.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 15/30] clk: starfive: Use regmap APIs to operate registers

Quoting Hal Feng (2022-09-29 10:56:02)
> Clock registers address region is shared with reset controller
> on the new StarFive JH7110 SoC. Change to use regmap framework
> to allow base address sharing and preparation for JH7110 clock
> support.

Do the reset and clk parts share actual registers, where we would need
to lock between rmw? Or is regmap just nice to have because it wraps up
the register APIs with some extra features?

> 
> Signed-off-by: Hal Feng <hal.feng@...ux.starfivetech.com>
> ---
[...]
> diff --git a/drivers/clk/starfive/clk-starfive-jh7100.c b/drivers/clk/starfive/clk-starfive-jh7100.c
> index 014e36f17595..410aa6e06842 100644
> --- a/drivers/clk/starfive/clk-starfive-jh7100.c
> +++ b/drivers/clk/starfive/clk-starfive-jh7100.c
> @@ -10,6 +10,7 @@
>  #include <linux/clk-provider.h>
>  #include <linux/device.h>
>  #include <linux/init.h>
> +#include <linux/mfd/syscon.h>
>  #include <linux/mod_devicetable.h>
>  #include <linux/platform_device.h>
>  
> @@ -295,11 +296,13 @@ static int __init clk_starfive_jh7100_probe(struct platform_device *pdev)
>         if (!priv)
>                 return -ENOMEM;
>  
> -       spin_lock_init(&priv->rmw_lock);
>         priv->dev = &pdev->dev;
> -       priv->base = devm_platform_ioremap_resource(pdev, 0);
> -       if (IS_ERR(priv->base))
> -               return PTR_ERR(priv->base);
> +       priv->regmap = device_node_to_regmap(priv->dev->of_node);

This is sad. Why do we need to make a syscon? Can we instead use the
auxiliary bus to make a reset device that either gets a regmap made here
in this driver or uses a void __iomem * mapped with ioremap
(priv->base)?

> +       if (IS_ERR(priv->regmap)) {
> +               dev_err(priv->dev, "failed to get regmap (error %ld)\n",
> +                       PTR_ERR(priv->regmap));
> +               return PTR_ERR(priv->regmap);