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
