linux-kernel - Re: [RFC PATCH 0/3] SCMI System Power Support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 6 May 2020 14:11:45 -0500
From:   Rob Herring <robh@...nel.org>
To:     Cristian Marussi <Cristian.Marussi@....com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        "james.quinlan@...adcom.com" <james.quinlan@...adcom.com>,
        Lukasz Luba <Lukasz.Luba@....com>,
        Sudeep Holla <Sudeep.Holla@....com>
Subject: Re: [RFC PATCH 0/3] SCMI System Power Support

On Thu, Apr 30, 2020 at 12:23 PM Cristian Marussi
<Cristian.Marussi@....com> wrote:
>
> Hi Rob
>
> thanks for the feedback.

Plain text for maillists please.

>
> > 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.

Rob