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: <501265638c16ffa06a77be37e1feeb2c9cb732bb.camel@fi.rohmeurope.com>
Date:   Sun, 10 May 2020 18:51:53 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "sebastian.reichel@...labora.com" <sebastian.reichel@...labora.com>
CC:     "mazziesaccount@...il.com" <mazziesaccount@...il.com>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "brendanhiggins@...gle.com" <brendanhiggins@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: [PATCH v12 00/11] Support ROHM BD99954 charger IC

Thanks a lot Sebastian and Mark!

On Sun, 2020-05-10 at 18:04 +0200, Sebastian Reichel wrote:
> Hi,
> 
> On Fri, May 08, 2020 at 06:38:17PM +0300, Matti Vaittinen wrote:
> > Please note that this series should be applied to two trees.
> > Patches
> > 1-4 (or 1-5 as suggested by Sebastian) should go to regulator tree.
> > Perhaps Mark can provide an immutable branch to Sebastian? Rest of
> > the
> > patches can then go to power-supply tree.
> 
> Thanks, I merged the pull-request from Mark and queued patches 5-11.
> 

I think it's fair to point out also for Sebastian that Mark spotted a
compile time warning from linear_ranges when it is compiled as a
module. This is only occurring when linear_ranges is compiled as a
module. And that requires CONFIG_REGULATOR to be n and linear_ranges
test to be m. I guess this is unlikely as I think enabling
linear_ranges test code is not common for setups that are not using
linear ranges - but for sure some test setup hits this somewhere.

Problem is that linear_ranges can be compiled as module (it's tristated
in Kconfig) but does not declare MODULE_LICENCE macro.

I sent this incremental patch which should fix the issue:
https://lore.kernel.org/lkml/20200509151519.GA7100@localhost.localdomain/

 - but does applying it to either power-supply or regulator cause a
conflict?

I just wanted to point this out - sorry for the trouble! And please let
me know if you wish me to send some other fix. I will gladly do so and
correct my bugs :)

--Matti

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ