From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753418AbbBSSW6 (ORCPT ); Thu, 19 Feb 2015 13:22:58 -0500 Received: from ns.iliad.fr ([212.27.33.1]:58840 "EHLO ns.iliad.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752913AbbBSSWz (ORCPT ); Thu, 19 Feb 2015 13:22:55 -0500 Message-ID: <1424370174.13604.18.camel@sakura.staff.proxad.net> Subject: Re: [PATCH 2/4] of: DT quirks infrastructure From: Maxime Bizon Reply-To: mbizon@freebox.fr To: Sylvain Rochet Cc: Pantelis Antoniou , Mark Rutland , "devicetree@vger.kernel.org" , Tony Lindgren , Koen Kooi , Nicolas Ferre , "linux-kernel@vger.kernel.org" , Grant Likely , Ludovic Desroches , "linux-arm-kernel@lists.infradead.org" , Matt Porter , frowand.list@gmail.com, Guenter Roeck Date: Thu, 19 Feb 2015 19:22:54 +0100 In-Reply-To: <20150219181218.GA5048@gradator.net> References: <1424271576-1952-3-git-send-email-pantelis.antoniou@konsulko.com> <20150218154106.GC29429@leverpostej> <20150218173115.GG29429@leverpostej> <76BD1B22-BAED-4205-9B34-186907CE0217@konsulko.com> <54E613E7.2020405@gmail.com> <670D0881-DBF0-45E8-A502-A6DB2B77A750@konsulko.com> <54E61DD2.3060002@gmail.com> <53F2F94C-0C43-4A54-B8CD-EEC454A0AC19@konsulko.com> <1424368919.13604.9.camel@sakura.staff.proxad.net> <20150219181218.GA5048@gradator.net> Organization: Freebox Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2015-02-19 at 19:12 +0100, Sylvain Rochet wrote: > Or use a 1-wire or I2C EEPROM to store your board information. no, you don't reduce the human error probability. eeprom needs to be preprogrammed, factory will at some point have a lot of eeprom with different version, and will potentially equip the wrong one. much more error prone than them putting the resistor at the wrong place. > Or, even better, if you have an I2C device, just chose a different > address on each board for this device and then probe I2C devices in your > boot loader until you found one you are looking for, this way, you don't > need spare GPIO at all. You don't even need to populate the same I2C > device on all boards, you can actually probe anything. I'm not a fan of schemes where not probing something is not a definitive sign of hardware failure. -- Maxime From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Bizon Subject: Re: [PATCH 2/4] of: DT quirks infrastructure Date: Thu, 19 Feb 2015 19:22:54 +0100 Message-ID: <1424370174.13604.18.camel@sakura.staff.proxad.net> References: <1424271576-1952-3-git-send-email-pantelis.antoniou@konsulko.com> <20150218154106.GC29429@leverpostej> <20150218173115.GG29429@leverpostej> <76BD1B22-BAED-4205-9B34-186907CE0217@konsulko.com> <54E613E7.2020405@gmail.com> <670D0881-DBF0-45E8-A502-A6DB2B77A750@konsulko.com> <54E61DD2.3060002@gmail.com> <53F2F94C-0C43-4A54-B8CD-EEC454A0AC19@konsulko.com> <1424368919.13604.9.camel@sakura.staff.proxad.net> <20150219181218.GA5048@gradator.net> Reply-To: mbizon@freebox.fr Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150219181218.GA5048@gradator.net> Sender: linux-kernel-owner@vger.kernel.org To: Sylvain Rochet Cc: Pantelis Antoniou , Mark Rutland , "devicetree@vger.kernel.org" , Tony Lindgren , Koen Kooi , Nicolas Ferre , "linux-kernel@vger.kernel.org" , Grant Likely , Ludovic Desroches , "linux-arm-kernel@lists.infradead.org" , Matt Porter , frowand.list@gmail.com, Guenter Roeck List-Id: devicetree@vger.kernel.org On Thu, 2015-02-19 at 19:12 +0100, Sylvain Rochet wrote: > Or use a 1-wire or I2C EEPROM to store your board information. no, you don't reduce the human error probability. eeprom needs to be preprogrammed, factory will at some point have a lot of eeprom with different version, and will potentially equip the wrong one. much more error prone than them putting the resistor at the wrong place. > Or, even better, if you have an I2C device, just chose a different > address on each board for this device and then probe I2C devices in your > boot loader until you found one you are looking for, this way, you don't > need spare GPIO at all. You don't even need to populate the same I2C > device on all boards, you can actually probe anything. I'm not a fan of schemes where not probing something is not a definitive sign of hardware failure. -- Maxime From mboxrd@z Thu Jan 1 00:00:00 1970 From: mbizon@freebox.fr (Maxime Bizon) Date: Thu, 19 Feb 2015 19:22:54 +0100 Subject: [PATCH 2/4] of: DT quirks infrastructure In-Reply-To: <20150219181218.GA5048@gradator.net> References: <1424271576-1952-3-git-send-email-pantelis.antoniou@konsulko.com> <20150218154106.GC29429@leverpostej> <20150218173115.GG29429@leverpostej> <76BD1B22-BAED-4205-9B34-186907CE0217@konsulko.com> <54E613E7.2020405@gmail.com> <670D0881-DBF0-45E8-A502-A6DB2B77A750@konsulko.com> <54E61DD2.3060002@gmail.com> <53F2F94C-0C43-4A54-B8CD-EEC454A0AC19@konsulko.com> <1424368919.13604.9.camel@sakura.staff.proxad.net> <20150219181218.GA5048@gradator.net> Message-ID: <1424370174.13604.18.camel@sakura.staff.proxad.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, 2015-02-19 at 19:12 +0100, Sylvain Rochet wrote: > Or use a 1-wire or I2C EEPROM to store your board information. no, you don't reduce the human error probability. eeprom needs to be preprogrammed, factory will at some point have a lot of eeprom with different version, and will potentially equip the wrong one. much more error prone than them putting the resistor at the wrong place. > Or, even better, if you have an I2C device, just chose a different > address on each board for this device and then probe I2C devices in your > boot loader until you found one you are looking for, this way, you don't > need spare GPIO at all. You don't even need to populate the same I2C > device on all boards, you can actually probe anything. I'm not a fan of schemes where not probing something is not a definitive sign of hardware failure. -- Maxime