linux-kernel - Re: [PATCH v6 09/11] firmware: xilinx: Add debugfs for clock control APIs

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]

Message-ID: <5bcc47f7-3352-f0e6-29c5-78d5be96c1d1@arm.com>
Date:   Thu, 10 May 2018 15:31:18 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Jolly Shah <jolly.shah@...inx.com>, ard.biesheuvel@...aro.org,
        mingo@...nel.org, gregkh@...uxfoundation.org,
        matt@...eblueprint.co.uk, hkallweit1@...il.com,
        keescook@...omium.org, dmitry.torokhov@...il.com,
        mturquette@...libre.com, sboyd@...eaurora.org,
        michal.simek@...inx.com, robh+dt@...nel.org, mark.rutland@....com,
        linux-clk@...r.kernel.org
Cc:     Sudeep Holla <sudeep.holla@....com>, rajanv@...inx.com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, Jolly Shah <jollys@...inx.com>
Subject: Re: [PATCH v6 09/11] firmware: xilinx: Add debugfs for clock control
 APIs



On 10/04/18 20:38, Jolly Shah wrote:
> From: Rajan Vaja <rajanv@...inx.com>
> 
> Add debugfs file to control clocks using firmware APIs
> through debugfs interface.
> 
> Signed-off-by: Rajan Vaja <rajanv@...inx.com>
> Signed-off-by: Jolly Shah <jollys@...inx.com>
> ---
>  drivers/firmware/xilinx/zynqmp-debug.c | 48 ++++++++++++++++++++++++++++++++++
>  1 file changed, 48 insertions(+)
> 
> diff --git a/drivers/firmware/xilinx/zynqmp-debug.c b/drivers/firmware/xilinx/zynqmp-debug.c
> index 1cb69f7..837fcd1 100644
> --- a/drivers/firmware/xilinx/zynqmp-debug.c
> +++ b/drivers/firmware/xilinx/zynqmp-debug.c
> @@ -34,6 +34,15 @@ static struct pm_api_info pm_api_list[] = {
>  	PM_API(PM_GET_API_VERSION),
>  	PM_API(PM_IOCTL),
>  	PM_API(PM_QUERY_DATA),
> +	PM_API(PM_CLOCK_ENABLE),
> +	PM_API(PM_CLOCK_DISABLE),
> +	PM_API(PM_CLOCK_GETSTATE),
> +	PM_API(PM_CLOCK_SETDIVIDER),
> +	PM_API(PM_CLOCK_GETDIVIDER),
> +	PM_API(PM_CLOCK_SETRATE),
> +	PM_API(PM_CLOCK_GETRATE),
> +	PM_API(PM_CLOCK_SETPARENT),
> +	PM_API(PM_CLOCK_GETPARENT),
>  };
>  
>  /**
> @@ -87,6 +96,7 @@ static int process_api_request(u32 pm_id, u64 *pm_api_arg, u32 *pm_api_ret)
>  	const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
>  	u32 pm_api_version;
>  	int ret;
> +	u64 rate;
>  
>  	if (!eemi_ops)
>  		return -ENXIO;
> @@ -132,6 +142,44 @@ static int process_api_request(u32 pm_id, u64 *pm_api_arg, u32 *pm_api_ret)
>  				pm_api_ret[2], pm_api_ret[3]);
>  		break;
>  	}
> +	case PM_CLOCK_ENABLE:
> +		ret = eemi_ops->clock_enable(pm_api_arg[0]);
> +		break;

As I mentioned in earlier patch, I don't see the need for this debugfs
interface. Clock lay has read-only interface in debugfs already. Also if
you want to debug clocks, you can do so using the driver which uses
these clocks. Do you really want to manage clocks in user-space ?
The whole idea of EEMI kind of interface is to abstract and hide the
fine details even from non-trusted rich OS like Linux kernel, but by
providing this you are doing exactly opposite.

-- 
Regards,
Sudeep