Hi Olof, > -----Original Message----- > From: Olof Johansson [mailto:[email protected]] > Sent: Sunday, September 23, 2018 6:11 AM > To: Jolly Shah <[email protected]> > Cc: Sudeep Holla <[email protected]>; [email protected]; Ingo > Molnar <[email protected]>; Greg Kroah-Hartman > <[email protected]>; [email protected]; > [email protected]; Kees Cook <[email protected]>; Dmitry > Torokhov <[email protected]>; Michael Turquette > <[email protected]>; Stephen Boyd <[email protected]>; Michal > Simek <[email protected]>; Rob Herring <[email protected]>; Mark Rutland > <[email protected]>; linux-clk <[email protected]>; Rajan Vaja > <[email protected]>; Linux ARM Mailing List <linux-arm- > [email protected]>; Linux Kernel Mailing List <linux- > [email protected]>; DTML <[email protected]> > 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 <[email protected]> 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
