All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javierm@redhat.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>,
	Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
Cc: Jonathan Cameron <jic23@kernel.org>,
	Hartmut Knaack <knaack.h@gmx.de>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Xiongfeng Wang <xiongfeng.wang@linaro.org>,
	linux-iio@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	nv@vosn.de
Subject: Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe()
Date: Wed, 4 Jul 2018 12:49:29 +0200	[thread overview]
Message-ID: <10258a21-db42-2c4e-91d6-e9227e11f53b@redhat.com> (raw)
In-Reply-To: <CAHp75VcQrd134aA54_nZtGr3YaXAtwZLXpj6Oi1=BOSMynEvVQ@mail.gmail.com>

Hi Andy,

On 07/04/2018 12:19 PM, Andy Shevchenko wrote:
> Summon Javier to the discussion.
> For my opinion he is an expert in this topic.

I wouldn't call myself an expert in anything to be honest :)

[snip]

> 
>> The table is not used by the driver, but is necessary to
>>
>> a) bind an i2c device declared via i2c_board_info with type field set
>>    to one of the names of the i2c_device_id table to this driver
>> b) bind an i2c device declared via DT or ACPI but with no match in of_id/
>>    acpi_id table but an i2c_device_id table match to this driver (fallback
>>    matching)
>> c) create the right modaliases at compile time for this driver to make
>>    module auto-loading work in case of a) and b)
>

I think Nikolaus is correct, assuming that the driver can be used on legacy
platforms that register the I2C devices using board files / platform data.
In that case you still need a I2C device ID table for (a) and (c) as he said.

I don't buy on (b) though, that's a bug in my opinion. If you register an I2C
device via DT then you must have a OF device ID entry that matches the device
and the same for ACPI. You can't rely on the I2C device table to do the match.

I would also remove the struct i2c_device_id .driver_data fields from the I2C
device ID table, since are not used and just makes reading the code confusing
(only the struct i2c_device_id .name is used as far as I can see).

> Javier, just a summary of the above. Nikolaus switched one driver to
> use ->probe_new() hook and left i2c ID table at the same time.
> My understanding that this table is not anymore in use.
> 
> But I have to admit I didn't see entire picture of this. Can you shed a light?
> 

So to shed some light, in the past even {OF,ACPI}-only drivers needed an I2C ID
table because: 1) the .probe callback had a struct i2c_device_id * parameter
and 2) the I2C core always reported a modalias of the form i2c:<foo> even for
devices registered via OF.

The .probe_new callbacks solves (1) and the I2C core now reports of:N*T*Cfoo*
solving (2). So the I2C device table isn't required anymore for {OF,ACPI}-only
drivers, but it's still required for drivers that support legacy board files
that calls i2c_register_board_info() directly. Same for the old .probe callback,
it's needed if struct i2c_device_id .driver_data is used in the probe function.

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

  reply	other threads:[~2018-07-04 10:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-03  6:34 [PATCH v2 0/2] IIO: st_sensors_i2c: improve device enumeration Nikolaus Voss
2018-07-03  5:41 ` [PATCH v2 1/2] IIO: st_accel_i2c.c: Simplify access to driver data Nikolaus Voss
2018-07-03 21:07   ` Andy Shevchenko
2018-07-04  6:56     ` Nikolaus Voss
2018-07-04  9:00       ` Andy Shevchenko
2018-07-03  6:06 ` [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe() Nikolaus Voss
2018-07-03 22:54   ` Andy Shevchenko
2018-07-04  6:37     ` Nikolaus Voss
2018-07-04  8:58       ` Andy Shevchenko
2018-07-04  9:09         ` Nikolaus Voss
2018-07-04  9:16           ` Andy Shevchenko
2018-07-04  9:42             ` Nikolaus Voss
2018-07-04 10:19               ` Andy Shevchenko
2018-07-04 10:49                 ` Javier Martinez Canillas [this message]
2018-07-04 11:15                   ` Nikolaus Voss
2018-07-04 11:26                     ` Javier Martinez Canillas
2018-07-04 11:32                       ` Javier Martinez Canillas
2018-07-04 11:46                       ` Nikolaus Voss
2018-07-04 12:09                         ` Javier Martinez Canillas
2018-07-04 12:31                           ` Nikolaus Voss
2018-07-04 12:37                             ` Javier Martinez Canillas
2018-07-04 13:24                               ` Nikolaus Voss
2018-07-04 13:44                                 ` Javier Martinez Canillas
2018-07-04 16:11                                   ` Andy Shevchenko
2018-07-04 18:53                                     ` Javier Martinez Canillas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=10258a21-db42-2c4e-91d6-e9227e11f53b@redhat.com \
    --to=javierm@redhat.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=jic23@kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.bianconi83@gmail.com \
    --cc=nikolaus.voss@loewensteinmedical.de \
    --cc=nv@vosn.de \
    --cc=pmeerw@pmeerw.net \
    --cc=xiongfeng.wang@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.