On 04/05/2013 01:37 PM, Simon Glass wrote: > HI Wolfram, > > On Wed, Apr 3, 2013 at 12:19 PM, Wolfram Sang <wsa@xxxxxxxxxxxxx> 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-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
