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] [day] [month] [year] [list]
Date:   Mon, 23 Aug 2021 15:18:16 -0500
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-23 09:19:08)
> On 2021-08-21 23:47, Stephen Boyd wrote:
> > 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?
>
> Commit message throughout the series
> mention that the current load state
> implementation is broken but it is
> never mentioned explicitly that it
> is the reason why bindings can be
> broken. I'll wait for a couple of
> days to see if I get any more
> comments and will re-word it in the
> next re-spin.
>

Ok. You can add my Reviewed-by tag with that text updated.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ