| Message ID | 1523389127-14243-1-git-send-email-jollys@xilinx.com |
|---|---|
| Headers | show |
| Series | drivers: Introduce firmware dnd clock river for ZynqMP core | expand |
On 10/04/18 20:38, Jolly Shah wrote: > From: Rajan Vaja <rajanv@xilinx.com> > > This patch is adding communication layer with firmware. > Firmware driver provides an interface to firmware APIs. > Interface APIs can be used by any driver to communicate to > PMUFW(Platform Management Unit). All requests go through ATF. > > Signed-off-by: Rajan Vaja <rajanv@xilinx.com> > Signed-off-by: Jolly Shah <jollys@xilinx.com> > --- [...] > + > +/** > + * get_set_conduit_method() - Choose SMC or HVC based communication > + * @np: Pointer to the device_node structure > + * > + * Use SMC or HVC-based functions to communicate with EL2/EL3. > + * > + * Return: Returns 0 on success or error code > + */ > +static int get_set_conduit_method(struct device_node *np) > +{ > + const char *method; > + > + if (of_property_read_string(np, "method", &method)) { > + pr_warn("%s missing \"method\" property\n", __func__); > + return -ENXIO; > + } > + > + if (!strcmp("hvc", method)) { > + do_fw_call = do_fw_call_hvc; > + } else if (!strcmp("smc", method)) { > + do_fw_call = do_fw_call_smc; > + } else { > + pr_warn("%s Invalid \"method\" property: %s\n", > + __func__, method); > + return -EINVAL; > + } > + Mark R did some cleanup around SMCCC conduits[1]. It makes sense to base this on top that. But if you manage to push this for v4.18, then you may need to wait for that to be merged and clean it up after v4.18
On 10/04/18 20:38, Jolly Shah wrote: > From: Rajan Vaja <rajanv@xilinx.com> > > Add ZynqMP firmware IOCTL API to control and configure > devices like PLLs, SD, Gem, etc. > > Signed-off-by: Rajan Vaja <rajanv@xilinx.com> > Signed-off-by: Jolly Shah <jollys@xilinx.com> > --- > drivers/firmware/xilinx/zynqmp.c | 20 ++++++++++++++++++++ > include/linux/firmware/xlnx-zynqmp.h | 2 ++ > 2 files changed, 22 insertions(+) > > diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c > index 490561a..44b43fa 100644 > --- a/drivers/firmware/xilinx/zynqmp.c > +++ b/drivers/firmware/xilinx/zynqmp.c > @@ -239,8 +239,28 @@ static int get_set_conduit_method(struct device_node *np) > return 0; > } > > +/** > + * zynqmp_pm_ioctl() - PM IOCTL API for device control and configs > + * @node_id: Node ID of the device > + * @ioctl_id: ID of the requested IOCTL > + * @arg1: Argument 1 to requested IOCTL call > + * @arg2: Argument 2 to requested IOCTL call > + * @out: Returned output value > + * > + * This function calls IOCTL to firmware for device control and configuration. > + * > + * Return: Returns status, either success or error+reason > + */ > +static int zynqmp_pm_ioctl(u32 node_id, u32 ioctl_id, u32 arg1, u32 arg2, > + u32 *out) > +{ > + return zynqmp_pm_invoke_fn(PM_IOCTL, node_id, ioctl_id, > + arg1, arg2, out); > +} > + > static const struct zynqmp_eemi_ops eemi_ops = { > .get_api_version = zynqmp_pm_get_api_version, > + .ioctl = zynqmp_pm_ioctl, > }; > > /** > diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h > index cb63bed..2eec6e7 100644 > --- a/include/linux/firmware/xlnx-zynqmp.h > +++ b/include/linux/firmware/xlnx-zynqmp.h > @@ -34,6 +34,7 @@ > > enum pm_api_id { > PM_GET_API_VERSION = 1, > + PM_IOCTL = 34, I am not for this API. IIUC there are more fined grained well defined APIs(if I am not wrong from enum 2 upto 33). This is open ended API which allows user to do whatever setting it needs. And that defeats the purpose of other APIs. I will look through the series for the usage of this to understand this better, but I am guessing how it can be (ab)used.
On 10/04/18 20:38, Jolly Shah wrote: > From: Rajan Vaja <rajanv@xilinx.com> > > Add ZynqMP firmware query data API to query platform > specific information(clocks, pins) from firmware. > > Signed-off-by: Rajan Vaja <rajanv@xilinx.com> > Signed-off-by: Jolly Shah <jollys@xilinx.com> > --- > drivers/firmware/xilinx/zynqmp.c | 14 ++++++++++++++ > include/linux/firmware/xlnx-zynqmp.h | 20 ++++++++++++++++++++ > 2 files changed, 34 insertions(+) > > diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c > index 44b43fa..ef09c44 100644 > --- a/drivers/firmware/xilinx/zynqmp.c > +++ b/drivers/firmware/xilinx/zynqmp.c > @@ -258,9 +258,23 @@ static int zynqmp_pm_ioctl(u32 node_id, u32 ioctl_id, u32 arg1, u32 arg2, > arg1, arg2, out); > } > > +/** > + * zynqmp_pm_query_data() - Get query data from firmware > + * @qdata: Variable to the zynqmp_pm_query_data structure > + * @out: Returned output value > + * > + * Return: Returns status, either success or error+reason > + */ > +static int zynqmp_pm_query_data(struct zynqmp_pm_query_data qdata, u32 *out) > +{ > + return zynqmp_pm_invoke_fn(PM_QUERY_DATA, qdata.qid, qdata.arg1, > + qdata.arg2, qdata.arg3, out); > +} > + > static const struct zynqmp_eemi_ops eemi_ops = { > .get_api_version = zynqmp_pm_get_api_version, > .ioctl = zynqmp_pm_ioctl, > + .query_data = zynqmp_pm_query_data, Can you give more insight into this ? How will be this used ? How this aligns with data we get from DT ? I am just trying to understand how is this information split between this API and DT for example.
On 10/04/18 20:38, Jolly Shah wrote: > From: Rajan Vaja <rajanv@xilinx.com> > > Firmware-debug provides debugfs interface to all APIs. > Debugfs can be used to call firmware APIs with required > parameters. > > Usage: > * Calling firmware API through debugfs: > # echo "<api-name> <arg1> .. <argn>" > /sys/.../zynqmp-firmware/pm > > * Read output of last called firmware API: > # cat /sys/.../zynqmp-firmware/pm > > Refer ug1200 for more information on these APIs: > * https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf > > Add basic debugfs file to get API version. Who are the users of this apart from debugging ? I am bit over sensitive as this remote processor manages/controls the power and other shared resources in the system. Giving such fine grained access to user space is not a good idea. I assume you want this DEBUGFS off by default on production images ?
On 10/04/18 20:38, Jolly Shah wrote: > From: Rajan Vaja <rajanv@xilinx.com> > > Add debugfs file to control clocks using firmware APIs > through debugfs interface. > > Signed-off-by: Rajan Vaja <rajanv@xilinx.com> > Signed-off-by: Jolly Shah <jollys@xilinx.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.
Hi Sudeep, > -----Original Message----- > From: Sudeep Holla [mailto:sudeep.holla@arm.com] > Sent: Thursday, May 10, 2018 7:05 AM > To: Jolly Shah <JOLLYS@xilinx.com>; ard.biesheuvel@linaro.org; > mingo@kernel.org; gregkh@linuxfoundation.org; matt@codeblueprint.co.uk; > hkallweit1@gmail.com; keescook@chromium.org; > dmitry.torokhov@gmail.com; mturquette@baylibre.com; > sboyd@codeaurora.org; michal.simek@xilinx.com; robh+dt@kernel.org; > mark.rutland@arm.com; linux-clk@vger.kernel.org > Cc: Sudeep Holla <sudeep.holla@arm.com>; Rajan Vaja <RAJANV@xilinx.com>; > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; > devicetree@vger.kernel.org; Jolly Shah <JOLLYS@xilinx.com> > Subject: Re: [PATCH v6 02/11] firmware: xilinx: Add Zynqmp firmware driver > > > > On 10/04/18 20:38, Jolly Shah wrote: > > From: Rajan Vaja <rajanv@xilinx.com> > > > > This patch is adding communication layer with firmware. > > Firmware driver provides an interface to firmware APIs. > > Interface APIs can be used by any driver to communicate to > > PMUFW(Platform Management Unit). All requests go through ATF. > > > > Signed-off-by: Rajan Vaja <rajanv@xilinx.com> > > Signed-off-by: Jolly Shah <jollys@xilinx.com> > > --- > > [...] > > > + > > +/** > > + * get_set_conduit_method() - Choose SMC or HVC based communication > > + * @np: Pointer to the device_node structure > > + * > > + * Use SMC or HVC-based functions to communicate with EL2/EL3. > > + * > > + * Return: Returns 0 on success or error code */ static int > > +get_set_conduit_method(struct device_node *np) { > > + const char *method; > > + > > + if (of_property_read_string(np, "method", &method)) { > > + pr_warn("%s missing \"method\" property\n", __func__); > > + return -ENXIO; > > + } > > + > > + if (!strcmp("hvc", method)) { > > + do_fw_call = do_fw_call_hvc; > > + } else if (!strcmp("smc", method)) { > > + do_fw_call = do_fw_call_smc; > > + } else { > > + pr_warn("%s Invalid \"method\" property: %s\n", > > + __func__, method); > > + return -EINVAL; > > + } > > + > > Mark R did some cleanup around SMCCC conduits[1]. It makes sense to base this > on top that. But if you manage to push this for v4.18, then you may need to wait > for that to be merged and clean it up after v4.18 > > -- > Regards, > Sudeep Mark R did change for SMCCC enums and we are not using any SMCCC enums so we don't have any dependency on that. Thanks, Jolly Shah > > [1] https://www.spinics.net/lists/arm-kernel/msg650305.html
Hi Sudeep, > -----Original Message----- > From: Sudeep Holla [mailto:sudeep.holla@arm.com] > Sent: Thursday, May 10, 2018 7:09 AM > To: Jolly Shah <JOLLYS@xilinx.com>; ard.biesheuvel@linaro.org; > mingo@kernel.org; gregkh@linuxfoundation.org; matt@codeblueprint.co.uk; > hkallweit1@gmail.com; keescook@chromium.org; > dmitry.torokhov@gmail.com; mturquette@baylibre.com; > sboyd@codeaurora.org; michal.simek@xilinx.com; robh+dt@kernel.org; > mark.rutland@arm.com; linux-clk@vger.kernel.org > Cc: Sudeep Holla <sudeep.holla@arm.com>; Rajan Vaja <RAJANV@xilinx.com>; > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; > devicetree@vger.kernel.org; Jolly Shah <JOLLYS@xilinx.com> > Subject: Re: [PATCH v6 03/11] firmware: xilinx: Add zynqmp IOCTL API for device > control > > > > On 10/04/18 20:38, Jolly Shah wrote: > > From: Rajan Vaja <rajanv@xilinx.com> > > > > Add ZynqMP firmware IOCTL API to control and configure devices like > > PLLs, SD, Gem, etc. > > > > Signed-off-by: Rajan Vaja <rajanv@xilinx.com> > > Signed-off-by: Jolly Shah <jollys@xilinx.com> > > --- > > drivers/firmware/xilinx/zynqmp.c | 20 ++++++++++++++++++++ > > include/linux/firmware/xlnx-zynqmp.h | 2 ++ > > 2 files changed, 22 insertions(+) > > > > diff --git a/drivers/firmware/xilinx/zynqmp.c > > b/drivers/firmware/xilinx/zynqmp.c > > index 490561a..44b43fa 100644 > > --- a/drivers/firmware/xilinx/zynqmp.c > > +++ b/drivers/firmware/xilinx/zynqmp.c > > @@ -239,8 +239,28 @@ static int get_set_conduit_method(struct > device_node *np) > > return 0; > > } > > > > +/** > > + * zynqmp_pm_ioctl() - PM IOCTL API for device control and configs > > + * @node_id: Node ID of the device > > + * @ioctl_id: ID of the requested IOCTL > > + * @arg1: Argument 1 to requested IOCTL call > > + * @arg2: Argument 2 to requested IOCTL call > > + * @out: Returned output value > > + * > > + * This function calls IOCTL to firmware for device control and configuration. > > + * > > + * Return: Returns status, either success or error+reason */ static > > +int zynqmp_pm_ioctl(u32 node_id, u32 ioctl_id, u32 arg1, u32 arg2, > > + u32 *out) > > +{ > > + return zynqmp_pm_invoke_fn(PM_IOCTL, node_id, ioctl_id, > > + arg1, arg2, out); > > +} > > + > > static const struct zynqmp_eemi_ops eemi_ops = { > > .get_api_version = zynqmp_pm_get_api_version, > > + .ioctl = zynqmp_pm_ioctl, > > }; > > > > /** > > diff --git a/include/linux/firmware/xlnx-zynqmp.h > > b/include/linux/firmware/xlnx-zynqmp.h > > index cb63bed..2eec6e7 100644 > > --- a/include/linux/firmware/xlnx-zynqmp.h > > +++ b/include/linux/firmware/xlnx-zynqmp.h > > @@ -34,6 +34,7 @@ > > > > enum pm_api_id { > > PM_GET_API_VERSION = 1, > > + PM_IOCTL = 34, > > I am not for this API. IIUC there are more fined grained well defined APIs(if I am > not wrong from enum 2 upto 33). This is open ended API which allows user to do > whatever setting it needs. And that defeats the purpose of other APIs. > > I will look through the series for the usage of this to understand this better, but I > am guessing how it can be (ab)used. > > -- > Regards, > Sudeep There are well defined APIs for general clock controls. Ioctl is for some specific operations which may not apply to all platforms. For clock driver, ioctl is used to get/set Pll fraction/integer mode and data. Thanks, Jolly Shah
HI Sudeep, > -----Original Message----- > From: Sudeep Holla [mailto:sudeep.holla@arm.com] > Sent: Thursday, May 10, 2018 7:12 AM > To: Jolly Shah <JOLLYS@xilinx.com>; ard.biesheuvel@linaro.org; > mingo@kernel.org; gregkh@linuxfoundation.org; matt@codeblueprint.co.uk; > hkallweit1@gmail.com; keescook@chromium.org; > dmitry.torokhov@gmail.com; mturquette@baylibre.com; > sboyd@codeaurora.org; michal.simek@xilinx.com; robh+dt@kernel.org; > mark.rutland@arm.com; linux-clk@vger.kernel.org > Cc: Sudeep Holla <sudeep.holla@arm.com>; Rajan Vaja <RAJANV@xilinx.com>; > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; > devicetree@vger.kernel.org; Jolly Shah <JOLLYS@xilinx.com> > Subject: Re: [PATCH v6 04/11] firmware: xilinx: Add query data API > > > > On 10/04/18 20:38, Jolly Shah wrote: > > From: Rajan Vaja <rajanv@xilinx.com> > > > > Add ZynqMP firmware query data API to query platform specific > > information(clocks, pins) from firmware. > > > > Signed-off-by: Rajan Vaja <rajanv@xilinx.com> > > Signed-off-by: Jolly Shah <jollys@xilinx.com> > > --- > > drivers/firmware/xilinx/zynqmp.c | 14 ++++++++++++++ > > include/linux/firmware/xlnx-zynqmp.h | 20 ++++++++++++++++++++ > > 2 files changed, 34 insertions(+) > > > > diff --git a/drivers/firmware/xilinx/zynqmp.c > > b/drivers/firmware/xilinx/zynqmp.c > > index 44b43fa..ef09c44 100644 > > --- a/drivers/firmware/xilinx/zynqmp.c > > +++ b/drivers/firmware/xilinx/zynqmp.c > > @@ -258,9 +258,23 @@ static int zynqmp_pm_ioctl(u32 node_id, u32 > ioctl_id, u32 arg1, u32 arg2, > > arg1, arg2, out); > > } > > > > +/** > > + * zynqmp_pm_query_data() - Get query data from firmware > > + * @qdata: Variable to the zynqmp_pm_query_data structure > > + * @out: Returned output value > > + * > > + * Return: Returns status, either success or error+reason */ static > > +int zynqmp_pm_query_data(struct zynqmp_pm_query_data qdata, u32 *out) > > +{ > > + return zynqmp_pm_invoke_fn(PM_QUERY_DATA, qdata.qid, > qdata.arg1, > > + qdata.arg2, qdata.arg3, out); > > +} > > + > > static const struct zynqmp_eemi_ops eemi_ops = { > > .get_api_version = zynqmp_pm_get_api_version, > > .ioctl = zynqmp_pm_ioctl, > > + .query_data = zynqmp_pm_query_data, > > Can you give more insight into this ? How will be this used ? > How this aligns with data we get from DT ? I am just trying to understand how is > this information split between this API and DT for example. > > -- > Regards, > Sudeep This API is used to get clock information from firmware and register clocks accordingly in driver. In our case, firmware maintains database of all clocks available on chip. DT will provide information for off chip reference clocks only. This is to avoid duplication of clocks data in DT and firmware both as firmware anyways need clock data to manage them. Thanks, Jolly Shah
On 14/05/18 20:18, Jolly Shah wrote: > Hi Sudeep, [..] >> >> 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. > > No we don't want to manage clocks in user-space. This debugfs is > meant for developer who wants to debug APIs behavior in case > something doesn't work as expected. Debugfs should be off by default > in production images. > Good that it's not used in production image. The clock layer has *sufficient* debugfs support that will *help in debugging*. So please drop this Xilinx specific clock debugfs.
On 14/05/18 20:16, Jolly Shah wrote: > HI Sudeep, > [...] >> >> Can you give more insight into this ? How will be this used ? How >> this aligns with data we get from DT ? I am just trying to >> understand how is this information split between this API and DT >> for example. >> > > This API is used to get clock information from firmware and register > clocks accordingly in driver. In our case, firmware maintains > database of all clocks available on chip. DT will provide information > for off chip reference clocks only. This is to avoid duplication of > clocks data in DT and firmware both as firmware anyways need clock > data to manage them. > I wanted to understand the difference with example. What kind of information you get from DT and what you get from firmware ?
Hi Sudeep, > -----Original Message----- > From: Sudeep Holla [mailto:sudeep.holla@arm.com] > Sent: Tuesday, May 15, 2018 2:34 AM > To: Jolly Shah <JOLLYS@xilinx.com>; ard.biesheuvel@linaro.org; > mingo@kernel.org; gregkh@linuxfoundation.org; matt@codeblueprint.co.uk; > hkallweit1@gmail.com; keescook@chromium.org; > dmitry.torokhov@gmail.com; mturquette@baylibre.com; > sboyd@codeaurora.org; michal.simek@xilinx.com; robh+dt@kernel.org; > mark.rutland@arm.com; linux-clk@vger.kernel.org > Cc: Sudeep Holla <sudeep.holla@arm.com>; Rajan Vaja <RAJANV@xilinx.com>; > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; > devicetree@vger.kernel.org > Subject: Re: [PATCH v6 04/11] firmware: xilinx: Add query data API > > > > On 14/05/18 20:16, Jolly Shah wrote: > > HI Sudeep, > > > > [...] > > >> > >> Can you give more insight into this ? How will be this used ? How > >> this aligns with data we get from DT ? I am just trying to understand > >> how is this information split between this API and DT for example. > >> > > > > This API is used to get clock information from firmware and register > > clocks accordingly in driver. In our case, firmware maintains database > > of all clocks available on chip. DT will provide information for off > > chip reference clocks only. This is to avoid duplication of clocks > > data in DT and firmware both as firmware anyways need clock data to > > manage them. > > > > I wanted to understand the difference with example. What kind of information > you get from DT and what you get from firmware ? > > -- > Regards, > Sudeep Below is an example showing PLL and Leaf clock derivation: Input ref clocks->Mux->Multiplier/Divider->PLL* Pll1/pll2/pll3/pll4->Mux->Divider->Gate->Leaf clock1 Here Off chip input ref clock information comes from DT. Rest information for Pll/leaf clocks come from firmware using query API. For clock driver, query API is used to get topology, flags, parents etc information per clock. Thanks, Jolly Shah
Hi Sudeep, > -----Original Message----- > From: Sudeep Holla [mailto:sudeep.holla@arm.com] > Sent: Tuesday, May 15, 2018 1:58 AM > To: Jolly Shah <JOLLYS@xilinx.com>; ard.biesheuvel@linaro.org; > mingo@kernel.org; gregkh@linuxfoundation.org; matt@codeblueprint.co.uk; > hkallweit1@gmail.com; keescook@chromium.org; > dmitry.torokhov@gmail.com; mturquette@baylibre.com; > sboyd@codeaurora.org; michal.simek@xilinx.com; robh+dt@kernel.org; > mark.rutland@arm.com; linux-clk@vger.kernel.org > Cc: Sudeep Holla <sudeep.holla@arm.com>; Rajan Vaja <RAJANV@xilinx.com>; > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; > devicetree@vger.kernel.org > Subject: Re: [PATCH v6 09/11] firmware: xilinx: Add debugfs for clock control > APIs > > > > On 14/05/18 20:18, Jolly Shah wrote: > > Hi Sudeep, > > [..] > > >> > >> 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. > > > > No we don't want to manage clocks in user-space. This debugfs is meant > > for developer who wants to debug APIs behavior in case something > > doesn't work as expected. Debugfs should be off by default in > > production images. > > > > Good that it's not used in production image. The clock layer has > *sufficient* debugfs support that will *help in debugging*. So please drop this > Xilinx specific clock debugfs. > > -- > Regards, > Sudeep Ok. Will remove them in next version. Let me know if rest changes look ok and I can submit final version with suggested minor changes. Thanks, Jolly Shah