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  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:   Sun, 12 Apr 2020 19:40:52 +0530
From:   Maulik Shah <>
To:     Doug Anderson <>,
        Stephen Boyd <>
Cc:     Bjorn Andersson <>,
        Evan Green <>,
        LKML <>,
        linux-arm-msm <>,
        Andy Gross <>,
        Matthias Kaehlcke <>,
        Rajendra Nayak <>,
        Lina Iyer <>,
Subject: Re: [PATCH v16 4/6] soc: qcom: rpmh: Invoke rpmh_flush() for dirty


On 4/10/2020 8:22 PM, Doug Anderson wrote:
> Hi,
> On Thu, Apr 9, 2020 at 9:15 PM Stephen Boyd <> wrote:
>>>   int rpmh_flush(struct rpmh_ctrlr *ctrlr)
>> This function name keeps throwing me off. Can we please call it
>> something like rpmh_configure_tcs_sleep_wake()? The word "flush" seems
>> to imply there's some sort of cache going on, but that's not really the
>> case. We're programming a couple TCS FIFOs so that they can be used
>> across deep CPU sleep states.
> I'm hoping this rename can be deferred until Maulik's series and my
> cleanup series land.  While I agree that rpmh_flush() is a bit of a
> confusing name, it's not a new name and renaming it midway through
> when there are a bunch of patches in-flight is going to be a hassle.
> Assuming others agree, my thought is that Maulik will do one more v17
> spin with small nits fixed up, then his series can land early next
> week when (presumably) -rc1 comes out.  If my current cleanup doesn't
> apply cleanly (or if Bjorn/Andy don't want to fix the two nits in
> commit messages when applying) I can repost my series and that can
> land in short order.  Once those land:
> * Maulik can post this rpmh_flush() rename atop.
> * I can post the patch to remove the "pm_lock" that was introduced in
> this series.  A preview at <>.
> * Maulik can post some of the cleanups that Maulik wanted to do in
> rpmh.c with regards to __fill_rpmh_msg()
> ...assuming those are not controversial perhaps they can be reviewed
> quickly and land quickly?  I suppose I can always dream...
> -Doug

Agree, I can defer rename until this series lands and then post above 
listed changes.


QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Powered by blists - more mailing lists