linux-kernel - Re: [PATCH v2 1/2] PM / Domains: Add GENPD_FLAG_NO

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 12 Sep 2020 22:46:03 -0500
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     Sibi Sankar <sibis@...eaurora.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Kevin Hilman <khilman@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Andy Gross <agross@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Pavel Machek <pavel@....cz>, Len Brown <len.brown@...el.com>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Doug Anderson <dianders@...omium.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        linux-kernel-owner@...r.kernel.org, clew@...eaurora.org
Subject: Re: [PATCH v2 1/2] PM / Domains: Add GENPD_FLAG_NO_SUSPEND/RESUME
 flags

On Thu 10 Sep 03:18 CDT 2020, Ulf Hansson wrote:

> On Thu, 10 Sep 2020 at 09:23, Sibi Sankar <sibis@...eaurora.org> wrote:
> >
> > On 2020-08-25 23:23, Bjorn Andersson wrote:
> > > On Tue 25 Aug 02:20 CDT 2020, Stephen Boyd wrote:
> > >> Quoting Bjorn Andersson (2020-08-24 09:42:12)
> > >> > On Fri 21 Aug 14:41 PDT 2020, Stephen Boyd wrote:
> > > [..]
> > >> > > I find it odd that this is modeled as a power domain instead of some
> > >> > > Qualcomm specific message that the remoteproc driver sends to AOSS. Is
> > >> > > there some sort of benefit the driver gets from using the power domain
> > >> > > APIs for this vs. using a custom API?
> > >> >
> > >> > We need to send "up" and "down" notifications and this needs to happen
> > >> > at the same time as other standard resources are enabled/disabled.
> > >> >
> > >> > Further more, at the time the all resources handled by the downstream
> > >> > driver was either power-domains (per above understanding) or clocks, so
> > >> > it made sense to me not to spin up a custom API.
> > >> >
> > >>
> > >> So the benefit is not spinning up a custom API? I'm not Ulf, but it
> > >> looks like this is hard to rationalize about as a power domain. It
> > >> doesn't have any benefit to model it this way besides to make it
> > >> possible to turn on with other power domains.
> > >>
> > >> This modem remoteproc drivers isn't SoC agnostic anyway, it relies on
> > >> SMEM APIs, so standing up another small qmp_remoteproc_booted() and
> > >> qmp_remoteproc_shutdown() API would avoid adding a genpd flag here
> > >> that
> > >> probably will never be used outside of this corner-case. There is also
> > >> some get/put EPROBE_DEFER sort of logic to implement, but otherwise it
> > >> would be possible to do this outside of power domains, and that seems
> > >> better given that this isn't really a power domain to start with.
> > >
> > > In later platforms a few new users of the AOSS communication interface
> > > is introduced that certainly doesn't fit any existing API/framework in
> > > the kernel. So the plan was to pretty much expose qmp_send() to these
> > > drivers.
> > >
> > > My worry with using this interface is that we'll probably have to come
> > > up with some DT binding pieces and probably we'll end up adding yet
> > > another piece of hard coded information in the remoteproc drivers.
> > >
> > > But I'm not against us doing this work in favor of not having to
> > > introduce a one-off for this corner case.
> >
> > Bjorn/Stephen,
> >
> > So the consensus is to stop modelling
> > aoss load_state as pds and expose qmp_send
> > to drivers?
> 
> Would that mean qmp_send would have to be called from generic drivers?
> Then, please no. We want to keep drivers portable.
> 

No, this is only called from Qualcomm specific drivers. So I'm okay with
that approach.

Regards,
Bjorn