From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752366AbdGaQRm (ORCPT ); Mon, 31 Jul 2017 12:17:42 -0400 Received: from mail-io0-f182.google.com ([209.85.223.182]:36108 "EHLO mail-io0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751997AbdGaQRj (ORCPT ); Mon, 31 Jul 2017 12:17:39 -0400 MIME-Version: 1.0 X-Originating-IP: [149.170.218.226] In-Reply-To: <20170731153009.xkjknygpmckv2pfp@ninjato> References: <20170615185418.13980-1-javier@dowhile0.org> <20170731153009.xkjknygpmckv2pfp@ninjato> From: Javier Martinez Canillas Date: Mon, 31 Jul 2017 18:17:38 +0200 Message-ID: Subject: Re: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table To: Wolfram Sang Cc: Linux Kernel , Rob Herring , Florian Larysch , David Lechner , Rob Herring , Andy Shevchenko , Catalin Marinas , =?UTF-8?Q?S=C3=B6ren_Brinkmann?= , Simon Horman , Michal Simek , Dinh Nguyen , Russell King , Will Deacon , "devicetree@vger.kernel.org" , Sekhar Nori , Scott Wood , Benjamin Herrenschmidt , Joachim Eastwood , Mark Rutland , "linux-arm-kernel@lists.infradead.org" , Masahiro Yamada , Michael Ellerman , Santosh Shilimkar , Linux-Renesas , Paul Mackerras , Magnus Damm , linuxppc-dev , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , Linux I2C Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Wolfram, On Mon, Jul 31, 2017 at 5:30 PM, Wolfram Sang wrote: > >> Patches can be applied independently since the DTS changes without driver >> changes are no-op and the OF table won't be used without the DTS changes. > > But there is a dependency, no? If I apply the driver patch, > non-converted device trees will not find their eeproms anymore. So, I I don't think that's correct. If you apply this patch before the DTS changes, the driver will still match using the I2C device ID table like it has been doing it until today. IOW, this is what will happen: 1- an OF device is registered with the wrong compatible (not found in the OF table) 2- the I2C core strips the vendor part and fills the struct i2c_client .name with the device part. 3- i2c_device_match() will be called since a new device has been registered 4- i2c_of_match_device() will fail because there's no OF entry that matches the device compatible 5- the I2C core fallbacks to i2c_match_id() and matches using the I2C device ID table. So no noticeable difference AFAICT in that case. Best regards, Javier From mboxrd@z Thu Jan 1 00:00:00 1970 From: Javier Martinez Canillas Subject: Re: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table Date: Mon, 31 Jul 2017 18:17:38 +0200 Message-ID: References: <20170615185418.13980-1-javier@dowhile0.org> <20170731153009.xkjknygpmckv2pfp@ninjato> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20170731153009.xkjknygpmckv2pfp@ninjato> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Wolfram Sang Cc: Linux Kernel , Rob Herring , Florian Larysch , David Lechner , Rob Herring , Andy Shevchenko , Catalin Marinas , =?UTF-8?Q?S=C3=B6ren_Brinkmann?= , Simon Horman , Michal Simek , Dinh Nguyen , Russell King , Will Deacon , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Sekhar Nori , Scott Wood , Benjamin Herrenschmidt , Joachim Eastwood , Mark Rutland List-Id: devicetree@vger.kernel.org Hello Wolfram, On Mon, Jul 31, 2017 at 5:30 PM, Wolfram Sang wrote: > >> Patches can be applied independently since the DTS changes without driver >> changes are no-op and the OF table won't be used without the DTS changes. > > But there is a dependency, no? If I apply the driver patch, > non-converted device trees will not find their eeproms anymore. So, I I don't think that's correct. If you apply this patch before the DTS changes, the driver will still match using the I2C device ID table like it has been doing it until today. IOW, this is what will happen: 1- an OF device is registered with the wrong compatible (not found in the OF table) 2- the I2C core strips the vendor part and fills the struct i2c_client .name with the device part. 3- i2c_device_match() will be called since a new device has been registered 4- i2c_of_match_device() will fail because there's no OF entry that matches the device compatible 5- the I2C core fallbacks to i2c_match_id() and matches using the I2C device ID table. So no noticeable difference AFAICT in that case. Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: javier@dowhile0.org (Javier Martinez Canillas) Date: Mon, 31 Jul 2017 18:17:38 +0200 Subject: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table In-Reply-To: <20170731153009.xkjknygpmckv2pfp@ninjato> References: <20170615185418.13980-1-javier@dowhile0.org> <20170731153009.xkjknygpmckv2pfp@ninjato> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hello Wolfram, On Mon, Jul 31, 2017 at 5:30 PM, Wolfram Sang wrote: > >> Patches can be applied independently since the DTS changes without driver >> changes are no-op and the OF table won't be used without the DTS changes. > > But there is a dependency, no? If I apply the driver patch, > non-converted device trees will not find their eeproms anymore. So, I I don't think that's correct. If you apply this patch before the DTS changes, the driver will still match using the I2C device ID table like it has been doing it until today. IOW, this is what will happen: 1- an OF device is registered with the wrong compatible (not found in the OF table) 2- the I2C core strips the vendor part and fills the struct i2c_client .name with the device part. 3- i2c_device_match() will be called since a new device has been registered 4- i2c_of_match_device() will fail because there's no OF entry that matches the device compatible 5- the I2C core fallbacks to i2c_match_id() and matches using the I2C device ID table. So no noticeable difference AFAICT in that case. Best regards, Javier