[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABxcv=mdbE0QGjoi3aLzxRqM3-MbkQ_Ai6fShcGVUGSNNqqrqw@mail.gmail.com>
Date: Mon, 31 Jul 2017 18:17:38 +0200
From: Javier Martinez Canillas <javier@...hile0.org>
To: Wolfram Sang <wsa@...-dreams.de>
Cc: Linux Kernel <linux-kernel@...r.kernel.org>,
Rob Herring <robh@...nel.org>, Florian Larysch <fl@...1.de>,
David Lechner <david@...hnology.com>,
Rob Herring <robh+dt@...nel.org>,
Andy Shevchenko <andy.shevchenko@...il.com>,
Catalin Marinas <catalin.marinas@....com>,
Sören Brinkmann <soren.brinkmann@...inx.com>,
Simon Horman <horms@...ge.net.au>,
Michal Simek <michal.simek@...inx.com>,
Dinh Nguyen <dinguyen@...nel.org>,
Russell King <linux@...linux.org.uk>,
Will Deacon <will.deacon@....com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Sekhar Nori <nsekhar@...com>, Scott Wood <oss@...error.net>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Joachim Eastwood <manabian@...il.com>,
Mark Rutland <mark.rutland@....com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
Michael Ellerman <mpe@...erman.id.au>,
Santosh Shilimkar <ssantosh@...nel.org>,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
Paul Mackerras <paulus@...ba.org>,
Magnus Damm <magnus.damm@...il.com>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
Uwe Kleine-König <kernel@...gutronix.de>,
Linux I2C <linux-i2c@...r.kernel.org>
Subject: Re: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table
Hello Wolfram,
On Mon, Jul 31, 2017 at 5:30 PM, Wolfram Sang <wsa@...-dreams.de> 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
Powered by blists - more mailing lists