linux-kernel - Re: [PATCH v9 3/3] soc: qcom: rpmh: Invoke rpmh

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: <CAD=FV=VNaqwiti+UB8fLgjF5r2CD2xeF_p7qHS-_yXqf+ZDrBg@mail.gmail.com>
Date:   Thu, 5 Mar 2020 14:18:05 -0800
From:   Doug Anderson <dianders@...omium.org>
To:     Maulik Shah <mkshah@...eaurora.org>
Cc:     Stephen Boyd <swboyd@...omium.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        Evan Green <evgreen@...omium.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Andy Gross <agross@...nel.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Lina Iyer <ilina@...eaurora.org>, lsrao@...eaurora.org
Subject: Re: [PATCH v9 3/3] soc: qcom: rpmh: Invoke rpmh_flush() for dirty caches

Hi,

On Thu, Mar 5, 2020 at 1:41 AM Maulik Shah <mkshah@...eaurora.org> wrote:
 >> There are other cases like below which also gets impacted if driver
> >> don't cache anything...
> >>
> >> for example, when we don’t have dedicated ACTIVE TCS ( if we have below
> >> config with ACTIVE TCS count 0)
> >>      qcom,tcs-config = <ACTIVE_TCS  0>,
> >>                            <SLEEP_TCS   3>,
> >>                            <WAKE_TCS    3>,
> >>
> >> Now to send active data, driver may re-use/ re-purpose few of the sleep
> >> or wake TCS, to be used as ACTIVE TCS and once work is done,
> >> it will be re-allocated in SLEEP/ WAKE TCS pool accordingly. If driver
> >> don’t cache, all the SLEEP and WAKE data is lost when one
> >> of TCS is repurposed to use as ACTIVE TCS.
> > Ah, interesting.  I'll read the code more, but are you expecting this
> > type of situation to work today, or is it theoretical for the future?
> yes, we have targets which needs to work with this type of situation.

My brain is still slowly absorbing all the code, but something tells
me that targets with no ACTIVE TCS will not work properly with non-OSI
mode unless you change your patches more.  Specifically to make the
zero ACTIVE TCS case work I think you need a rpmh_flush() call after
_ALL_ calls to rpmh_write() and rpmh_write_batch() (even those
modifying ACTIVE state).  rpmh_write_async() will be yet more
interesting because you'd have to flush in rpmh_tx_done() I guess?
...and also somehow you need to inhibit entering sleep mode if an
async write was in progress?  Maybe easier to just detect the
"non-OSI-mode + 0 ACTIVE TCS" case at probe time and fail to probe?


-Doug