Thread (26 messages) 26 messages, 6 authors, 2018-09-24

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

From: Jolly Shah <hidden>
Date: 2018-09-24 18:26:33
Also in: linux-clk, linux-devicetree, lkml

Hi Olof,
-----Original Message-----
From: Olof Johansson [mailto:olof at lixom.net]
Sent: Sunday, September 23, 2018 6:11 AM
To: Jolly Shah <redacted>
Cc: Sudeep Holla <redacted>; ard.biesheuvel at linaro.org; Ingo
Molnar [off-list ref]; Greg Kroah-Hartman
[off-list ref]; matt at codeblueprint.co.uk;
hkallweit1 at gmail.com; Kees Cook [off-list ref]; Dmitry
Torokhov [off-list ref]; Michael Turquette
[off-list ref]; Stephen Boyd [off-list ref]; Michal
Simek [off-list ref]; Rob Herring [off-list ref]; Mark Rutland
[off-list ref]; linux-clk [off-list ref]; Rajan Vaja
[off-list ref]; Linux ARM Mailing List <linux-arm-
kernel at lists.infradead.org>; Linux Kernel Mailing List <linux-
kernel at vger.kernel.org>; DTML [off-list ref]
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 [off-list ref] wrote:
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help