linux-kernel - Re: [PATCH v7 00/24] i2c mux cleanup and locking update

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-next>] [day] [month] [year] [list]

Message-ID: <AM4PR02MB1299DD7DBCE30E8EFE9E1259BC6F0@AM4PR02MB1299.eurprd02.prod.outlook.com>
Date:	Fri, 22 Apr 2016 07:54:12 +0000
From:	Peter Rosin <peda@...ntia.se>
To:	Wolfram Sang <wsa@...-dreams.de>, Peter Rosin <peda@...ntia.se>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Jonathan Corbet" <corbet@....net>,
	Peter Korsgaard <peter.korsgaard@...co.com>,
	"Guenter Roeck" <linux@...ck-us.net>,
	Jonathan Cameron <jic23@...nel.org>,
	"Hartmut Knaack" <knaack.h@....de>,
	Lars-Peter Clausen <lars@...afoo.de>,
	"Peter Meerwald" <pmeerw@...erw.net>,
	Antti Palosaari <crope@....fi>,
	"Mauro Carvalho Chehab" <mchehab@....samsung.com>,
	Rob Herring <robh+dt@...nel.org>,
	"Frank Rowand" <frowand.list@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Kalle Valo" <kvalo@...eaurora.org>, Jiri Slaby <jslaby@...e.com>,
	Daniel Baluta <daniel.baluta@...el.com>,
	Lucas De Marchi <lucas.demarchi@...el.com>,
	Adriana Reus <adriana.reus@...el.com>,
	Matt Ranostay <matt.ranostay@...el.com>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Hans Verkuil <hans.verkuil@...co.com>,
	Terry Heo <terryheo@...gle.com>,
	"Arnd Bergmann" <arnd@...db.de>,
	Tommi Rantala <tt.rantala@...il.com>,
	"Crestez Dan Leonard" <leonard.crestez@...el.com>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
	"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Peter Rosin <peda@...ator.liu.se>
Subject: Re: [PATCH v7 00/24] i2c mux cleanup and locking update

Hi Wolfram,

Wolfram Sang wrote:
> This was the diff of v6:
> 
> >  32 files changed, 1277 insertions(+), 915 deletions(-)
> 
> This is v7:
> 
> >  32 files changed, 1225 insertions(+), 916 deletions(-)
> 
> So, we gained a little overall. And while the individual drivers have a
> few lines more now, I still think it is more readable.
> 
> So, thanks for doing that!

Most, if not all, of these ~50 lines gained in v7 come from removing
i2c_mux_reserve_adapters and realloc. I.e., I think we might even have
lost a few lines with the i2c_mux_one_adapter removal, but not that many.
If the doc patch is taken out of the equation, we gain new functionality,
fix a bug and lose lines of code. Feels good!
However, this is not why I'm writing this message...

> I'll give people some time for testing. I'll have a further look, too.
> Hopefully, I can pick up patches 1-14 by the end of the week.

The reason for this message is that I just realized a couple of things.

First, you have suggested to merge patches 1-14 about now, and I assumed
that implied merging with Linus for 4.6, but on rereading I realize that
you have consistently targeted 4.7. I must be sloppy, and that had escaped
me. Is it really necessary to be that cautious? Maybe I'm overly confident,
but is 1-14 really such a big deal that it has to float in next for a whole
cycle?

The problem with waiting until 4.8 with the rest of the series is that it
will likely go stale, e.g. patch 22 ([media] rtl2832: change the i2c gate
to be mux-locked) touches a ton of register accesses in that driver since
it removes a regmap wrapper that is rendered obsolete. Expecting that
patch to work for 4.8 is overly optimistic, and while patching things up
is (probably) easy, it also renders any previous testing suspect.

That said, maybe I'm just impatient and reckless?

Second, should we not add 15-24 to the next branch now as well to get
testing going asap, even if we do not intend to merge it just yet or even
in that exact form? Or is that abusing the next branch?

Third, should we deprecate the old i2c_add_mux_adapter, so that new
users do not crop up behind our backs in the transition? Or not bother?

Fourth, I forgot to change patch 8 (iio: imu: inv_mpu6050: convert to
use an explicit i2c mux core) to not change i2c_get_clientdata() ->
dev_get_drvdata() as requested by Jonathan Cameron. How should I handle
that? There are also some new Tested-by tags that I have added to my
local branch but have not pushed anywhere. I'm ready to push all that
to a new branch once you are ready to take it.

Cheers,
Peter