lkml.org 
[lkml]   [2018]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH v11 03/11] firmware: xilinx: Add zynqmp IOCTL API for device control
Date
Hi Olof,

> -----Original Message-----
> From: Olof Johansson [mailto:olof@lixom.net]
> Sent: Sunday, September 23, 2018 6:11 AM
> To: Jolly Shah <JOLLYS@xilinx.com>
> Cc: Sudeep Holla <sudeep.holla@arm.com>; ard.biesheuvel@linaro.org; Ingo
> Molnar <mingo@kernel.org>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; matt@codeblueprint.co.uk;
> hkallweit1@gmail.com; Kees Cook <keescook@chromium.org>; Dmitry
> Torokhov <dmitry.torokhov@gmail.com>; Michael Turquette
> <mturquette@baylibre.com>; Stephen Boyd <sboyd@codeaurora.org>; Michal
> Simek <michals@xilinx.com>; Rob Herring <robh+dt@kernel.org>; Mark Rutland
> <mark.rutland@arm.com>; linux-clk <linux-clk@vger.kernel.org>; Rajan Vaja
> <RAJANV@xilinx.com>; Linux ARM Mailing List <linux-arm-
> kernel@lists.infradead.org>; Linux Kernel Mailing List <linux-
> kernel@vger.kernel.org>; DTML <devicetree@vger.kernel.org>
> Subject: Re: [PATCH v11 03/11] firmware: xilinx: Add zynqmp IOCTL API for
> device control
>
> Hi,
>
> Apologies for the slow responses here, I meant to follow up on this sooner.
>
> On Tue, Sep 11, 2018 at 8:20 PM, Jolly Shah <JOLLYS@xilinx.com> wrote:
> > Hi Sudeep and Olof,
> >
> > Clock driver from same patch set uses ioctl API along with other clock eemi
> APIs. As clock patches' final review is pending by Stephen, Michal only created
> pull request for rest of the patches and that doesn't require ioctl api. I will
> remove it and submit new patch set.
> >
> > For future patches which requires ioctl api, would like to understand your
> suggestion so I can make required changes. For zynqmp, EEMI interface allows
> clock, reset, power etc management through firmware but apart from those
> there are some operations which needs secure access through firmware.
> Examples are accessing some storage registers for inter agent communication,
> configuring another agent(RPU) mode, setting PLL parameters, boot device
> configuration etc. Those operations are covered as ioctls as they are very
> platform specific. Do you suggest to handle them with individual EEMI APIs
> instead of ioctl API?
>
> I'm personally less worried about whether the calls are through an ioctl API or an
> EEMI one, but if it is through ioctl, I'd prefer if it wasn't wide-open pass-through.
> I.e. that the ioctls you actually use are documented, and only those who are
> whitelisted are passed through (and not in general exported to userspace).
>
> Does that make sense?
>

Sounds perfect. I will make required changes in next incremental patchset.

Thanks,
Jolly Shah


>
> -Olof
\
 
 \ /
  Last update: 2018-09-24 20:27    [W:0.079 / U:0.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site