linux-kernel - Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

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: <515F2E28.2090105@wwwdotorg.org>
Date:	Fri, 05 Apr 2013 14:03:52 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Wolfram Sang <wsa@...-dreams.de>
CC:	Simon Glass <sjg@...omium.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Daniel Kurtz <djkurtz@...omium.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Stephen Warren <swarren@...dia.com>,
	Ben Dooks <ben.dooks@...ethink.co.uk>,
	u.kleine-koenig@...gutronix.de,
	Grant Grundler <grundler@...omium.org>,
	Devicetree Discuss <devicetree-discuss@...ts.ozlabs.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Jean Delvare <khali@...ux-fr.org>,
	"Ben Dooks (embedded platforms)" <ben-linux@...ff.org>,
	Girish Shivananjappa <girish.shivananjappa@...aro.org>,
	"bhushan.r" <bhushan.r@...sung.com>,
	Naveen Krishna Chatradhi <ch.naveen@...sung.com>,
	"sreekumar.c" <sreekumar.c@...sung.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Peter Korsgaard <peter.korsgaard@...co.com>,
	Yuvaraj Kumar <yuvaraj.cd@...il.com>,
	Prashanth G <prashanth.g@...sung.com>
Subject: Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

On 04/05/2013 01:37 PM, Simon Glass wrote:
> HI Wolfram,
> 
> On Wed, Apr 3, 2013 at 12:19 PM, Wolfram Sang <wsa@...-dreams.de> wrote:
>> Doug,
>>
>>> Separately from a discussion of the technical merits, I'd say that
>>> this patch is needed because the Embedded Controller (EC) on the ARM
>>> Chromebook shipped expecting to communicate with this scheme.  While
>>
>> Uhrm, with all respect, "we already shipped it" is not a convincing
>> argument regarding inclusion. Benefit for the kernel is.

I'm not quite sure why that isn't a convincing argument.

The hardware has shipped. I don't know whether the EC microcode can be
updated in the field; it seems risky to do so even if it's possible. So,
it either gets supported or not; the HW/ucode isn't going to change I
suspect.

Hence, it seems that the decision would be:

a) Disallow the implementation of the arbitration scheme in the kernel,
and hence don't support this board in the kernel. (or at least some very
core features of this board)

b) Allow the implementation of the arbitration scheme in the kernel, and
hence make possible support this board in the kernel.

>From that perspective, the benefit for the kernel question comes down
to: do we see a benefit for the kernel to support this board? I can't
see why that wouldn't be a benefit.

The only disadvantage would be having to carrying code to support that
board. That same argument can be made for any board, and I think
typically doesn't cause any issue. The code for this I2C mux seems
pretty self-contained, so even if it was absolutely terrible (which I
don't think it is), it still wouldn't cause any wide-spread issues, I think.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/