Re: [PATCH] clk: zynqmp: Warn user if clock user are more than allowed

From: Stephen Boyd
Date: Thu Nov 07 2019 - 14:23:20 EST


Quoting Rajan Vaja (2019-11-07 01:58:14)
> Warn user if clock is used by more than allowed devices.
> This check is done by firmware and returns respective
> error code. Upon receiving error code for excessive user,
> warn user for the same.
>
> This change is done to restrict VPLL use count. It is
> assumed that VPLL is used by one user only.
>
> Signed-off-by: Rajan Vaja <rajan.vaja@xxxxxxxxxx>
> Signed-off-by: Michal Simek <michal.simek@xxxxxxxxxx>

This sign off chain is incorrect.

> ---
> drivers/clk/zynqmp/pll.c | 9 ++++++---
> drivers/firmware/xilinx/zynqmp.c | 2 ++
> include/linux/firmware/xlnx-zynqmp.h | 1 +
> 3 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/zynqmp/pll.c b/drivers/clk/zynqmp/pll.c
> index a541397..2f4ccaa 100644
> --- a/drivers/clk/zynqmp/pll.c
> +++ b/drivers/clk/zynqmp/pll.c
> @@ -188,9 +188,12 @@ static int zynqmp_pll_set_rate(struct clk_hw *hw, unsigned long rate,
> frac = (parent_rate * f) / FRAC_DIV;
>
> ret = eemi_ops->clock_setdivider(clk_id, m);
> - if (ret)
> - pr_warn_once("%s() set divider failed for %s, ret = %d\n",
> - __func__, clk_name, ret);
> + if (ret) {
> + if (ret == -EUSERS)
> + WARN(1, "More than allowed devices are using the %s, which is forbidden\n", clk_name);
> + pr_err("%s() set divider failed for %s, ret = %d\n",
> + __func__, clk_name, ret);
> + }

Shouldn't we catch this much earlier when clk_get() is called or
something like that?

>
> eemi_ops->ioctl(0, IOCTL_SET_PLL_FRAC_DATA, clk_id, f, NULL);
>
> diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
> index 75bdfaa..74d9f13 100644
> --- a/drivers/firmware/xilinx/zynqmp.c
> +++ b/drivers/firmware/xilinx/zynqmp.c
> @@ -48,6 +48,8 @@ static int zynqmp_pm_ret_code(u32 ret_status)
> return -EACCES;
> case XST_PM_ABORT_SUSPEND:
> return -ECANCELED;
> + case XST_PM_MULT_USER:
> + return -EUSERS;

This is for filesystem quotas? It's a weird error return value.

> case XST_PM_INTERNAL:
> case XST_PM_CONFLICT:
> case XST_PM_INVALID_NODE: