RE: [PATCH v11 03/11] firmware: xilinx: Add zynqmp IOCTL API for device control

[Jolly Shah]

Hi Olof,

> -----Original Message-----
> From: Olof Johansson [mailto:olof@xxxxxxxxx]
> Sent: Sunday, September 23, 2018 6:11 AM
> To: Jolly Shah <JOLLYS@xxxxxxxxxx>
> Cc: Sudeep Holla <sudeep.holla@xxxxxxx>; ard.biesheuvel@xxxxxxxxxx; Ingo
> Molnar <mingo@xxxxxxxxxx>; Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx>; matt@xxxxxxxxxxxxxxxxxxx;
> hkallweit1@xxxxxxxxx; Kees Cook <keescook@xxxxxxxxxxxx>; Dmitry
> Torokhov <dmitry.torokhov@xxxxxxxxx>; Michael Turquette
> <mturquette@xxxxxxxxxxxx>; Stephen Boyd <sboyd@xxxxxxxxxxxxxx>; Michal
> Simek <michals@xxxxxxxxxx>; Rob Herring <robh+dt@xxxxxxxxxx>; Mark Rutland
> <mark.rutland@xxxxxxx>; linux-clk <linux-clk@xxxxxxxxxxxxxxx>; Rajan Vaja
> <RAJANV@xxxxxxxxxx>; Linux ARM Mailing List <linux-arm-
> kernel@xxxxxxxxxxxxxxxxxxx>; Linux Kernel Mailing List <linux-
> kernel@xxxxxxxxxxxxxxx>; DTML <devicetree@xxxxxxxxxxxxxxx>
> 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@xxxxxxxxxx> 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