On Wed, May 06, 2020 at 02:11:45PM -0500, Rob Herring wrote: > On Thu, Apr 30, 2020 at 12:23 PM Cristian Marussi > <[email protected]> wrote: > > > > Hi Rob > > > > thanks for the feedback. > > Plain text for maillists please. > Yes I know, sorry, used wrong client by mistake.
> > > > > On top of this a new SCMI driver has been developed which registers for > > > ---- > > > such System Power notification and acts accordingly to satisfy such > > > plaform system-state transition requests that can be of forceful or > > > graceful kind. > > > > > I needed this 7 years ago. :) (hb_keys_notifier in > > > arch/arm/mach-highbank/highbank.c) > > > > ...better later than never > > > > > Such alternative, if deemed worth, should clearly be configurable via DT > > > (also in terms of which signals to use), BUT all of this work is not done > > > in this series: and that's the reason for the RFC tag: does it make sense > > > to add such a configurable additional option ? > > > > >Which process signal to use in DT? I don't think so. > > > > ... beside the awkward bad idea of mine of configuring it via DT > > (which I'll drop possibly using modparams for this config), my question > > was more about if it makes sense at all to have another alternative > > mechanism > > (other than orderly_poweroof/reboot)) based on signals to gracefully ask > > userspace > > to shutdown > > gregkh will tell you no to module params. > > If the signal is not standard, then we probably shouldn't go that route. > Before this reply, I posted a v2 with alternative signal-method configurable by modparam; it's anyway a small addition which I can easily remove in a v3. Thanks Cristian
