2019-12-04 23:31:47

by Jolly Shah

[permalink] [raw]
Subject: [PATCH 0/5] firmware: xilinx: Add xilinx specific sysfs interface

This patch series adds xilinx specific sysfs interface for below
purposes:
- Register access
- Set shutdown scope
- Set boot health status bit

Rajan Vaja (5):
firmware: xilinx: Adds new eemi call for reg access
firmware: xilinx: Add sysfs interface
firmware: xilinx: Add system shutdown API interface
firmware: xilinx: Add sysfs to set shutdown scope
firmware: xilinx: Add sysfs and IOCTL to set boot health status

Documentation/ABI/stable/sysfs-firmware-zynqmp | 103 +++++++
drivers/firmware/xilinx/Makefile | 2 +-
drivers/firmware/xilinx/zynqmp-ggs.c | 289 ++++++++++++++++++
drivers/firmware/xilinx/zynqmp.c | 392 +++++++++++++++++++++++++
include/linux/firmware/xlnx-zynqmp.h | 37 ++-
5 files changed, 821 insertions(+), 2 deletions(-)
create mode 100644 Documentation/ABI/stable/sysfs-firmware-zynqmp
create mode 100644 drivers/firmware/xilinx/zynqmp-ggs.c

--
2.7.4


2020-01-02 21:04:09

by Jolly Shah

[permalink] [raw]
Subject: RE: [PATCH 0/5] firmware: xilinx: Add xilinx specific sysfs interface

Hi Sudeep,

Thanks for the review.

> -----Original Message-----
> From: Sudeep Holla <[email protected]>
> Sent: Wednesday, December 18, 2019 6:46 AM
> To: Jolly Shah <[email protected]>
> Cc: [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; Michal Simek <[email protected]>; Rajan Vaja
> <[email protected]>; [email protected]; linux-
> [email protected]; Sudeep Holla <[email protected]>
> Subject: Re: [PATCH 0/5] firmware: xilinx: Add xilinx specific sysfs interface
>
> On Wed, Dec 04, 2019 at 03:29:14PM -0800, Jolly Shah wrote:
> > This patch series adds xilinx specific sysfs interface for below
> > purposes:
> > - Register access
> > - Set shutdown scope
> > - Set boot health status bit
>
> This series defeats the whole abstraction EEMI provides. By providing
> direct register accesses, you are allowing user-space to do whatever it
> wants. I had NACKed this idea before. Has anything changed ?
>

Firmware checks for allowed accesses only and rejects rest.

> If you need it for testing firmware, better put them in debugfs which is
> off on production builds.

Sure. Will reanalyze use cases and move to debugfs only if that suffices.

Thanks,
Jolly Shah


>
> --
> Regards,
> Sudeep

2020-01-03 11:33:09

by Sudeep Holla

[permalink] [raw]
Subject: Re: [PATCH 0/5] firmware: xilinx: Add xilinx specific sysfs interface

On Thu, Jan 02, 2020 at 09:01:58PM +0000, Jolly Shah wrote:
> Hi Sudeep,
>
> Thanks for the review.
>
> > -----Original Message-----
> > From: Sudeep Holla <[email protected]>
> > Sent: Wednesday, December 18, 2019 6:46 AM
> > To: Jolly Shah <[email protected]>
> > Cc: [email protected]; [email protected];
> > [email protected]; [email protected];
> > [email protected]; [email protected];
> > [email protected]; Michal Simek <[email protected]>; Rajan Vaja
> > <[email protected]>; [email protected]; linux-
> > [email protected]; Sudeep Holla <[email protected]>
> > Subject: Re: [PATCH 0/5] firmware: xilinx: Add xilinx specific sysfs interface
> >
> > On Wed, Dec 04, 2019 at 03:29:14PM -0800, Jolly Shah wrote:
> > > This patch series adds xilinx specific sysfs interface for below
> > > purposes:
> > > - Register access
> > > - Set shutdown scope
> > > - Set boot health status bit
> >
> > This series defeats the whole abstraction EEMI provides. By providing
> > direct register accesses, you are allowing user-space to do whatever it
> > wants. I had NACKed this idea before. Has anything changed ?
> >
>
> Firmware checks for allowed accesses only and rejects rest.
>

If that is always the case, why not abstract them and remove this direct
register access completely. It must go or we must remove EEMI abstraction
and just provide direct register access to the entire space. I really
don't like this mix-n-match approach here.

> > If you need it for testing firmware, better put them in debugfs which is
> > off on production builds.
>
> Sure. Will reanalyze use cases and move to debugfs only if that suffices.
>

Thanks.

--
Regards,
Sudeep