| 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
| ||
|
Message-Id: <20220108012515.D1213C36AEB@smtp.kernel.org>
Date: Fri, 07 Jan 2022 17:25:14 -0800
From: Stephen Boyd <sboyd@...nel.org>
To: Arnd Bergmann <arnd@...db.de>, Daniel Palmer <daniel@...f.com>,
Michael Turquette <mturquette@...libre.com>,
Rob Herring <robh+dt@...nel.org>,
Romain Perier <romain.perier@...il.com>,
linux-clk@...r.kernel.org
Cc: devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, Willy Tarreau <w@....eu>
Subject: Re: [PATCH v2 2/9] clk: mstar: msc313 cpupll clk driver
Quoting Romain Perier (2022-01-02 08:57:23)
> diff --git a/drivers/clk/mstar/Kconfig b/drivers/clk/mstar/Kconfig
> index de37e1bce2d2..a44ca2b180ff 100644
> --- a/drivers/clk/mstar/Kconfig
> +++ b/drivers/clk/mstar/Kconfig
> @@ -7,3 +7,10 @@ config MSTAR_MSC313_MPLL
> help
> Support for the MPLL PLL and dividers block present on
> MStar/Sigmastar SoCs.
> +
> +config MSTAR_MSC313_CPUPLL
Can this file be sorted on Kconfig name?
> + bool "MStar CPUPLL driver"
> + depends on ARCH_MSTARV7 || COMPILE_TEST
> + default ARCH_MSTARV7
> + help
> + Support for the CPU PLL present on MStar/Sigmastar SoCs.
> diff --git a/drivers/clk/mstar/Makefile b/drivers/clk/mstar/Makefile
> index f8dcd25ede1d..9f05b73a0619 100644
> --- a/drivers/clk/mstar/Makefile
> +++ b/drivers/clk/mstar/Makefile
> @@ -4,3 +4,4 @@
> #
>
> obj-$(CONFIG_MSTAR_MSC313_MPLL) += clk-msc313-mpll.o
> +obj-$(CONFIG_MSTAR_MSC313_CPUPLL) += clk-msc313-cpupll.o
> diff --git a/drivers/clk/mstar/clk-msc313-cpupll.c b/drivers/clk/mstar/clk-msc313-cpupll.c
> new file mode 100644
> index 000000000000..2229b16475eb
> --- /dev/null
> +++ b/drivers/clk/mstar/clk-msc313-cpupll.c
> @@ -0,0 +1,227 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 Daniel Palmer <daniel@...ngy.jp>
> + */
> +
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/clk-provider.h>
> +#include <linux/clkdev.h>
Is this include used? Please drop unused includes.
> +#include <linux/of_address.h>
> +#include <linux/module.h>
It isn't a module though.
> +#include <linux/kernel.h>
Preferably sort includes alphabetically too.
> +
> +/*
> + * This IP is not documented outside of the messy vendor driver.
> + * Below is what we think the registers look like based on looking at
> + * the vendor code and poking at the hardware:
> + *
> + * 0x140 -- LPF low. Seems to store one half of the clock transition
> + * 0x144 /
> + * 0x148 -- LPF high. Seems to store one half of the clock transition
> + * 0x14c /
> + * 0x150 -- vendor code says "toggle lpf enable"
> + * 0x154 -- mu?
> + * 0x15c -- lpf_update_count?
> + * 0x160 -- vendor code says "switch to LPF". Clock source config? Register bank?
> + * 0x164 -- vendor code says "from low to high" which seems to mean transition from LPF low to
> + * LPF high.
> + * 0x174 -- Seems to be the PLL lock status bit
> + * 0x180 -- Seems to be the current frequency, this might need to be populated by software?
> + * 0x184 / The vendor driver uses these to set the initial value of LPF low
> + *
> + * Frequency seems to be calculated like this:
> + * (parent clock (432mhz) / register_magic_value) * 16 * 524288
> + * Only the lower 24 bits of the resulting value will be used. In addition, the
> + * PLL doesn't seem to be able to lock on frequencies lower than 220 MHz, as
> + * divisor 0xfb586f (220 MHz) works but 0xfb7fff locks up.
> + *
> + * Vendor values:
> + * frequency - register value
> + *
> + * 400000000 - 0x0067AE14
> + * 600000000 - 0x00451EB8,
> + * 800000000 - 0x0033D70A,
> + * 1000000000 - 0x002978d4,
> + */
> +
> +#define REG_LPF_LOW_L 0x140
> +#define REG_LPF_LOW_H 0x144
> +#define REG_LPF_HIGH_BOTTOM 0x148
> +#define REG_LPF_HIGH_TOP 0x14c
> +#define REG_LPF_TOGGLE 0x150
> +#define REG_LPF_MYSTERYTWO 0x154
> +#define REG_LPF_UPDATE_COUNT 0x15c
> +#define REG_LPF_MYSTERYONE 0x160
> +#define REG_LPF_TRANSITIONCTRL 0x164
> +#define REG_LPF_LOCK 0x174
> +#define REG_CURRENT 0x180
> +
> +#define MULTIPLIER_1 16
> +#define MULTIPLIER_2 524288
> +#define MULTIPLIER (MULTIPLIER_1 * MULTIPLIER_2)
> +
> +struct msc313_cpupll {
> + void __iomem *base;
> + struct clk_hw clk_hw;
> +};
> +
> +#define to_cpupll(_hw) container_of(_hw, struct msc313_cpupll, clk_hw)
> +
> +static u32 msc313_cpupll_reg_read32(struct msc313_cpupll *cpupll, unsigned int reg)
> +{
> + u32 value;
> +
> + value = ioread16(cpupll->base + reg + 4) << 16;
> + value |= ioread16(cpupll->base + reg);
> +
> + return value;
> +}
> +
> +static void msc313_cpupll_reg_write32(struct msc313_cpupll *cpupll, unsigned int reg, u32 value)
> +{
> + u16 l = value & 0xffff, h = (value >> 16) & 0xffff;
> +
> + iowrite16(l, cpupll->base + reg);
We don't usually see 16-bit accesses but if that's what the hardware
wants then OK.
> + iowrite16(h, cpupll->base + reg + 4);
> +}
> +
> +static void msc313_cpupll_setfreq(struct msc313_cpupll *cpupll, u32 regvalue)
> +{
> + msc313_cpupll_reg_write32(cpupll, REG_LPF_HIGH_BOTTOM, regvalue);
> +
> + iowrite16(0x1, cpupll->base + REG_LPF_MYSTERYONE);
> + iowrite16(0x6, cpupll->base + REG_LPF_MYSTERYTWO);
> + iowrite16(0x8, cpupll->base + REG_LPF_UPDATE_COUNT);
> + iowrite16(BIT(12), cpupll->base + REG_LPF_TRANSITIONCTRL);
> +
> + iowrite16(0, cpupll->base + REG_LPF_TOGGLE);
> + iowrite16(1, cpupll->base + REG_LPF_TOGGLE);
> +
> + while (!(ioread16(cpupll->base + REG_LPF_LOCK)))
> + cpu_relax();
Any timeout? Can this use the io read timeout APIs?
> +
> + iowrite16(0, cpupll->base + REG_LPF_TOGGLE);
> +
> + msc313_cpupll_reg_write32(cpupll, REG_LPF_LOW_L, regvalue);
> +}
> +
> +static unsigned long msc313_cpupll_frequencyforreg(u32 reg, unsigned long parent_rate)
> +{
> + unsigned long long prescaled = ((unsigned long long)parent_rate) * MULTIPLIER;
> + unsigned long long scaled;
> +
> + if (prescaled == 0 || reg == 0)
> + return 0;
> + scaled = DIV_ROUND_DOWN_ULL(prescaled, reg);
> +
> + return scaled;
Just
return DIV_ROUND_DOWN_ULL(...);
> +}
> +
> +static u32 msc313_cpupll_regforfrequecy(unsigned long rate, unsigned long parent_rate)
> +{
> + unsigned long long prescaled = ((unsigned long long)parent_rate) * MULTIPLIER;
> + unsigned long long scaled;
> + u32 reg;
> +
> + if (prescaled == 0 || rate == 0)
> + return 0;
> +
> + scaled = DIV_ROUND_UP_ULL(prescaled, rate);
> + reg = scaled;
> +
> + return reg;
Just
return DIV_ROUND_UP_ULL(...);
> +}
> +
> +static unsigned long msc313_cpupll_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
> +{
> + struct msc313_cpupll *cpupll = to_cpupll(hw);
> +
> + return msc313_cpupll_frequencyforreg(msc313_cpupll_reg_read32(cpupll, REG_LPF_LOW_L),
> + parent_rate);
> +}
> +
> +static long msc313_cpupll_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *parent_rate)
> +{
> + u32 reg = msc313_cpupll_regforfrequecy(rate, *parent_rate);
> + long rounded = msc313_cpupll_frequencyforreg(reg, *parent_rate);
> +
> + /*
> + * This is my poor attempt at making sure the resulting
> + * rate doesn't overshoot the requested rate.
If you want better bounds you can use determine_rate and then look at
the min/max constraints to make sure you don't overshoot. But otherwise
round_rate implementation is up to the provider to figure out what
should happen, i.e. overshooting could be OK if the provider intends for
it.
> + */
> + for (; rounded >= rate && reg > 0; reg--)
> + rounded = msc313_cpupll_frequencyforreg(reg, *parent_rate);
> +
> + return rounded;
> +}
> +
> +static int msc313_cpupll_set_rate(struct clk_hw *hw, unsigned long rate, unsigned long parent_rate)
> +{
> + struct msc313_cpupll *cpupll = to_cpupll(hw);
> + u32 reg = msc313_cpupll_regforfrequecy(rate, parent_rate);
> +
> + msc313_cpupll_setfreq(cpupll, reg);
> +
> + return 0;
> +}
> +
> +static const struct clk_ops msc313_cpupll_ops = {
> + .recalc_rate = msc313_cpupll_recalc_rate,
> + .round_rate = msc313_cpupll_round_rate,
> + .set_rate = msc313_cpupll_set_rate,
> +};
> +
> +static const struct of_device_id msc313_cpupll_of_match[] = {
> + {
> + .compatible = "mstar,msc313-cpupll",
> + },
> + {}
This can and should be less lines
{ .compatible = "mstar,msc313-cpupll", },
{}
> +};
> +
> +static const struct clk_parent_data cpupll_parent = {
> + .index = 0,
> +};
> +
> +static int msc313_cpupll_probe(struct platform_device *pdev)
> +{
> + struct clk_init_data clk_init = {};
> + struct device *dev = &pdev->dev;
> + struct msc313_cpupll *cpupll;
> + int ret;
> +
> + cpupll = devm_kzalloc(&pdev->dev, sizeof(*cpupll), GFP_KERNEL);
> + if (!cpupll)
> + return -ENOMEM;
> +
> + cpupll->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(cpupll->base))
> + return PTR_ERR(cpupll->base);
> +
> + /* LPF might not contain the current frequency so fix that up */
> + msc313_cpupll_reg_write32(cpupll, REG_LPF_LOW_L,
> + msc313_cpupll_reg_read32(cpupll, REG_CURRENT));
> +
> + clk_init.name = dev_name(dev);
> + clk_init.ops = &msc313_cpupll_ops;
> + clk_init.flags = CLK_IS_CRITICAL;
Why is it critical? Can we have a comment? The clk ops don't have enable
or disable so it seems like the flag won't do anything.
> + clk_init.parent_data = &cpupll_parent;
> + clk_init.num_parents = 1;
> + cpupll->clk_hw.init = &clk_init;
> +
> + ret = devm_clk_hw_register(dev, &cpupll->clk_hw);
> + if (ret)
> + return ret;
> +
> + return of_clk_add_hw_provider(pdev->dev.of_node, of_clk_hw_simple_get, &cpupll->clk_hw);
> +}
> +
> +static struct platform_driver msc313_cpupll_driver = {
> + .driver = {
> + .name = "mstar-msc313-cpupll",
> + .of_match_table = msc313_cpupll_of_match,
> + },
> + .probe = msc313_cpupll_probe,
> +};
> +builtin_platform_driver(msc313_cpupll_driver);
Powered by blists - more mailing lists