Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1700133 > unrolled thread

Re: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table Wolfram Sang <wsa@the-dreams.de> - 2017-07-31 17:40 +0200
    Re: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table Javier Martinez Canillas <javier@dowhile0.org> - 2017-07-31 18:20 +0200

#1700133 — Re: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table

[Multipart message — attachments visible in raw view] — view raw

> 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
need to wait until all DTS patches are upstream, right? I can pick patch
1, though. We can already document it.

[toc] | [next] | [standalone]

#1700167

Hello Wolfram,

On Mon, Jul 31, 2017 at 5:30 PM, Wolfram Sang <wsa@the-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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web