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:   Mon, 6 Aug 2018 15:55:53 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Mark Brown <broonie@...nel.org>, Andy Gross <andy.gross@...aro.org>
Cc:     David Collins <collinsd@...eaurora.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        devicetree@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Stephen Boyd <sboyd@...nel.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        Olof Johansson <olof@...om.net>
Subject: Re: [PATCH v9 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings

Mark,

On Thu, Jul 26, 2018 at 11:39 AM, Andy Gross <andy.gross@...aro.org> wrote:
> + olof
>
> On Tue, Jul 24, 2018 at 05:59:42PM +0100, Mark Brown wrote:
>> On Tue, Jul 24, 2018 at 08:43:46AM -0700, Doug Anderson wrote:
>> > On Tue, Jul 24, 2018 at 8:25 AM, Mark Brown <broonie@...nel.org> wrote:
>>
>> > > There was also some other thing called command DB as well which was a
>> > > separate series.  Ideally there'd be a branch I could pull as there's a
>> > > build dependency on rpmh so I can't apply until the code has landed in
>> > > my tree, don't know what command DB is exactly.
>>
>> > Yup.  That one landed in May and is already in mainline Linux.  Refer
>> > to commit 312416d9171a ("drivers: qcom: add command DB driver").
>>
>> That's good at least - the cover letter said it was still under review,
>> guess it just hadn't been updated.
>>
>> > Adding Andy to this thread (I guess he wasn't on it?).  Hopefully he
>> > can provide you with the branch.
>>
> Mark,
>
> The arm-soc guys merged the Qualcomm pull requests.  So you can just use my
> qcom-drivers-for-4.19 tag.  That won't change at this point.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git
> qcom-drivers-for-4.19

Did Andy's idea of using the above tag work for you?  It appears that
there are a few patches you don't need there, but it shouldn't hurt to
pick them up too I think?  Here's what I see:

---

$ git log --oneline linux/master..qcom-drivers-for-4.19
78ee559d7fc6 (tag: qcom-drivers-for-4.19) soc: qcom: rmtfs-mem: fix
memleak in probe error paths
4da3b0452bc6 soc: qcom: llc-slice: Add missing MODULE_LICENSE()
6c805adf17d4 drivers: qcom: rpmh: fix unwanted error check for get_tcs_of_type()
efa1c257b3fc drivers: qcom: rpmh-rsc: fix the loop index check in
get_req_from_tcs
a0b1561f8461 firmware: qcom: scm: add a dummy qcom_scm_assign_mem()
fdd102b52cfd drivers: qcom: rpmh-rsc: Check cmd_db_ready() to help children
2de4b8d33eab drivers: qcom: rpmh-rsc: allow active requests from wake TCS
c8790cb6da58 drivers: qcom: rpmh: add support for batch RPMH request
564b5e24ccd4 drivers: qcom: rpmh: allow requests to be sent asynchronously
600513dfeef3 drivers: qcom: rpmh: cache sleep/wake state requests
9a3afcfbc0cc drivers: qcom: rpmh-rsc: allow invalidation of sleep/wake TCS
fa460e453a83 drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS
c1038456b02b drivers: qcom: rpmh: add RPMH helper functions
fc087fe5a45e drivers: qcom: rpmh-rsc: log RPMH requests in FTRACE
2e4690a09fca dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs
658628e7ef78 drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs
a3134fb09e0b drivers: soc: Add LLCC driver
7e5700ae64f6 dt-bindings: Documentation for qcom, llcc
0b65c59e3a54 soc: qcom: smem: Correct check for global partition

---

It seems like it's too late to land RPMh-regulator for 4.19, so I
guess we'll have to aim for 4.20.  I'm not sure if that means you're
going to want to wait until 4.20-rc1 comes out to use as a base before
thinking about landing RPMh-regulator?  If so then I guess we've got
~3 weeks before something could land and we could start landing device
tree bits using RPMh-regulator.  If that's the plan then we'll
probably just start landing things in the Chrome OS tree now and suck
up the extra work of trying to resolve differences later...

Thanks!

-Doug

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ