On Mon, 24 Aug 2020, Ben Levinsky wrote: > > -----Original Message----- > > From: [email protected] <linux-remoteproc- > > [email protected]> On Behalf Of Ben Levinsky > > Sent: Tuesday, August 18, 2020 7:24 AM > > To: Stefano Stabellini <[email protected]> > > Cc: Michal Simek <[email protected]>; [email protected]; > > [email protected]; Ed T. Mooring <[email protected]>; linux- > > [email protected]; [email protected]; > > [email protected]; Jiaying Liang <[email protected]>; linux-arm- > > [email protected] > > Subject: RE: [PATCH v8 2/5] firmware: xilinx: Add shutdown/wakeup APIs > > > > > > > > > -----Original Message----- > > > From: Stefano Stabellini <[email protected]> > > > Sent: Thursday, August 13, 2020 1:36 PM > > > To: Ben Levinsky <[email protected]> > > > Cc: Stefano Stabellini <[email protected]>; Michal Simek > > > <[email protected]>; [email protected]; > > > [email protected]; Ed T. Mooring <[email protected]>; linux- > > > [email protected]; [email protected]; > > > [email protected]; Jiaying Liang <[email protected]>; linux-arm- > > > [email protected] > > > Subject: Re: [PATCH v8 2/5] firmware: xilinx: Add shutdown/wakeup APIs > > > > > > On Mon, 10 Aug 2020, Ben Levinsky wrote: > > > > Add shutdown/wakeup a resource eemi operations to shutdown > > > > or bringup a resource. > > > > > > > > Signed-off-by: Ben Levinsky <[email protected]> > > > > --- > > > > v3: > > > > - add xilinx-related platform mgmt fn's instead of wrapping around > > > > function pointer in xilinx eemi ops struct > > > > - fix formatting > > > > v4: > > > > - add default values for enumv3: > > > > - add xilinx-related platform mgmt fn's instead of wrapping around > > > > function pointer in xilinx eemi ops struct > > > > - fix formatting > > > > v4: > > > > - add default values for enum > > > > --- > > > > drivers/firmware/xilinx/zynqmp.c | 35 > > ++++++++++++++++++++++++++++ > > > > include/linux/firmware/xlnx-zynqmp.h | 22 +++++++++++++++++ > > > > 2 files changed, 57 insertions(+) > > > > > > > > diff --git a/drivers/firmware/xilinx/zynqmp.c > > > b/drivers/firmware/xilinx/zynqmp.c > > > > index 8d1ff2454e2e..f1a0bd35deeb 100644 > > > > --- a/drivers/firmware/xilinx/zynqmp.c > > > > +++ b/drivers/firmware/xilinx/zynqmp.c > > > > @@ -846,6 +846,41 @@ int zynqmp_pm_release_node(const u32 node) > > > > } > > > > EXPORT_SYMBOL_GPL(zynqmp_pm_release_node); > > > > > > > > +/** > > > > + * zynqmp_pm_force_powerdown - PM call to request for another PU or > > > subsystem to > > > > + * be powered down forcefully > > > > + * @target: Node ID of the targeted PU or subsystem > > > > + * @ack: Flag to specify whether acknowledge is requested > > > > + * > > > > + * Return: status, either success or error+reason > > > > + */ > > > > +int zynqmp_pm_force_powerdown(const u32 target, > > > > > > If the target is really the node id, why not calling it "node", the same > > > way as below? > > [Ben Levinsky] good point. Will change to "target" in v9 > > > > > > > > > > + const enum zynqmp_pm_request_ack ack) > > > > +{ > > > > + return zynqmp_pm_invoke_fn(PM_FORCE_POWERDOWN, target, ack, > > > 0, 0, NULL); > > > > +} > > > > +EXPORT_SYMBOL_GPL(zynqmp_pm_force_powerdown); > > > > + > > > > +/** > > > > + * zynqmp_pm_request_wakeup - PM call to wake up selected master or > > > subsystem > > > > + * @node: Node ID of the master or subsystem > > > > + * @set_addr: Specifies whether the address argument is relevant > > > > + * @address: Address from which to resume when woken up > > > > + * @ack: Flag to specify whether acknowledge requested > > > > + * > > > > + * Return: status, either success or error+reason > > > > + */ > > > > +int zynqmp_pm_request_wakeup(const u32 node, > > > > + const bool set_addr, > > > > + const u64 address, > > > > + const enum zynqmp_pm_request_ack ack) > > > > +{ > > > > + /* set_addr flag is encoded into 1st bit of address */ > > > > + return zynqmp_pm_invoke_fn(PM_REQUEST_WAKEUP, node, address > > > | set_addr, > > > > + address >> 32, ack, NULL); > > > > +} > > > > +EXPORT_SYMBOL_GPL(zynqmp_pm_request_wakeup); > > > > + > > > > /** > > > > * zynqmp_pm_set_requirement() - PM call to set requirement for PM > > > slaves > > > > * @node: Node ID of the slave > > > > diff --git a/include/linux/firmware/xlnx-zynqmp.h > > > b/include/linux/firmware/xlnx-zynqmp.h > > > > index bb347dfe4ba4..4d83a7d69c4c 100644 > > > > --- a/include/linux/firmware/xlnx-zynqmp.h > > > > +++ b/include/linux/firmware/xlnx-zynqmp.h > > > > @@ -64,6 +64,8 @@ > > > > > > > > enum pm_api_id { > > > > PM_GET_API_VERSION = 1, > > > > + PM_FORCE_POWERDOWN = 8, > > > > + PM_REQUEST_WAKEUP = 10, > > > > PM_SYSTEM_SHUTDOWN = 12, > > > > PM_REQUEST_NODE = 13, > > > > PM_RELEASE_NODE, > > > > @@ -376,6 +378,12 @@ int zynqmp_pm_write_pggs(u32 index, u32 > > value); > > > > int zynqmp_pm_read_pggs(u32 index, u32 *value); > > > > int zynqmp_pm_system_shutdown(const u32 type, const u32 subtype); > > > > int zynqmp_pm_set_boot_health_status(u32 value); > > > > +int zynqmp_pm_force_powerdown(const u32 target, > > > > + const enum zynqmp_pm_request_ack ack); > > > > +int zynqmp_pm_request_wakeup(const u32 node, > > > > + const bool set_addr, > > > > + const u64 address, > > > > + const enum zynqmp_pm_request_ack ack); > > > > #else > > > > static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void) > > > > { > > > > @@ -526,6 +534,20 @@ static inline int > > > zynqmp_pm_set_boot_health_status(u32 value) > > > > { > > > > return -ENODEV; > > > > } > > > > + > > > > +static inline int zynqmp_pm_force_powerdown(const u32 target, > > > > + const enum zynqmp_pm_request_ack > > > > ack) > > > > +{ > > > > + return -ENODEV; > > > > +} > > > > + > > > > +static inline int zynqmp_pm_request_wakeup(const u32 node, > > > > + const bool set_addr, > > > > + const u64 address, > > > > + const enum zynqmp_pm_request_ack ack) > > > > > > code style > [Ben Levinsky] for this, the argument goes over 80 chars if aligned like the > others. With that in mind for style, is it better to have the set_addr and > address args aligned with ack or to push ack to the right but have the >80 > chars style issue?
I don't have an opinion on code style -- anything that passes scripts/checkpatch.pl is fine for me.
