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]
Message-ID: <CAE-0n50z=MaEZhXRSQpN6Jo8m7nyQSS6MqikAgT5cfkH1ZvL_g@mail.gmail.com>
Date:   Sat, 21 Aug 2021 11:17:34 -0700
From:   Stephen Boyd <swboyd@...omium.org>
To:     Sibi Sankar <sibis@...eaurora.org>
Cc:     bjorn.andersson@...aro.org, mka@...omium.org, robh+dt@...nel.org,
        ulf.hansson@...aro.org, rjw@...ysocki.net, agross@...nel.org,
        ohad@...ery.com, mathieu.poirier@...aro.org,
        linux-arm-msm@...r.kernel.org, linux-remoteproc@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        dianders@...omium.org, rishabhb@...eaurora.org,
        sidgup@...eaurora.org
Subject: Re: [PATCH v5 02/13] dt-bindings: remoteproc: qcom: pas: Add QMP property

Quoting Sibi Sankar (2021-08-20 07:24:02)
> On 2021-08-20 00:25, Stephen Boyd wrote:
> > Quoting Sibi Sankar (2021-08-18 20:02:05)
> >> The load state power-domain, used by the co-processors to notify the
> >> Always on Subsystem (AOSS) that a particular co-processor is up/down,
> >> suffers from the side-effect of changing states during suspend/resume.
> >> However the co-processors enter low-power modes independent to that of
> >> the application processor and their states are expected to remain
> >> unaltered across system suspend/resume cycles. To achieve this
> >> behavior
> >> let's drop the load state power-domain and replace them with the qmp
> >> property for all SoCs supporting low power mode signalling.
> >>
> >
> > How do we drop the load state property without breaking existing DTBs?
> > Maybe we need to leave it there and then somehow make it optional? Or
> > do
> > we not care about this problem as the driver will start ignoring it?
>
> We can afford to break the bindings
> because of the following reason:
>
> * Load state in mainline is currently
>    broken i.e. it doesn't serve its
>    main purpose of signalling AOP of
>    the correct state of Q6 during
>    system suspend/resume. Thus we
>    can maintain current functionality
>    even without the load state votes
>    i.e. when a new kernel with load
>    state removed is used with an older
>    dtb the remoteproc functionality
>    will remain the same.
>

Alright. Is that reflected somewhere in the commit text? I must have
missed it. Can you please add it?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ