From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162700Ab3DEUEA (ORCPT ); Fri, 5 Apr 2013 16:04:00 -0400 Received: from avon.wwwdotorg.org ([70.85.31.133]:56759 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1162677Ab3DEUD6 (ORCPT ); Fri, 5 Apr 2013 16:03:58 -0400 Message-ID: <515F2E28.2090105@wwwdotorg.org> Date: Fri, 05 Apr 2013 14:03:52 -0600 From: Stephen Warren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Wolfram Sang CC: Simon Glass , "linux-doc@vger.kernel.org" , Daniel Kurtz , "linux-kernel@vger.kernel.org" , "linux-i2c@vger.kernel.org" , Kukjin Kim , Stephen Warren , Ben Dooks , u.kleine-koenig@pengutronix.de, Grant Grundler , Devicetree Discuss , Rob Herring , Jean Delvare , "Ben Dooks (embedded platforms)" , Girish Shivananjappa , "bhushan.r" , Naveen Krishna Chatradhi , "sreekumar.c" , Mark Brown , Peter Korsgaard , Yuvaraj Kumar , Prashanth G Subject: Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver References: <1360957573-864-1-git-send-email-dianders@chromium.org> <1363192583-26363-1-git-send-email-dianders@chromium.org> <20130329115821.GC6359@the-dreams.de> <20130403191938.GA7875@the-dreams.de> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/05/2013 01:37 PM, Simon Glass wrote: > HI Wolfram, > > On Wed, Apr 3, 2013 at 12:19 PM, Wolfram Sang 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver Date: Fri, 05 Apr 2013 14:03:52 -0600 Message-ID: <515F2E28.2090105@wwwdotorg.org> References: <1360957573-864-1-git-send-email-dianders@chromium.org> <1363192583-26363-1-git-send-email-dianders@chromium.org> <20130329115821.GC6359@the-dreams.de> <20130403191938.GA7875@the-dreams.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-doc-owner@vger.kernel.org To: Wolfram Sang Cc: Simon Glass , "linux-doc@vger.kernel.org" , Daniel Kurtz , "linux-kernel@vger.kernel.org" , "linux-i2c@vger.kernel.org" , Kukjin Kim , Stephen Warren , Ben Dooks , u.kleine-koenig@pengutronix.de, Grant Grundler , Devicetree Discuss , Rob Herring , Jean Delvare , "Ben Dooks (embedded platforms)" , Girish Shivananjappa , "bhushan.r" , Naveen Krishna Chatradhi , "sreekumar.c" , Mark Brown , Peter Korsgaard List-Id: devicetree@vger.kernel.org On 04/05/2013 01:37 PM, Simon Glass wrote: > HI Wolfram, > > On Wed, Apr 3, 2013 at 12:19 PM, Wolfram Sang 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.