Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe()

From: Javier Martinez Canillas <javier@dowhile0.org>
To: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
Cc: Javier Martinez Canillas <javierm@redhat.com>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	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 <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 13:26:18 +0200	[thread overview]
Message-ID: <CABxcv==_JaiX7-++MRFTHmaikWbNin_YbaWuiqiuZAAuWPgvwQ@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1807041304490.9558@fox.voss.local>

Hi Nikolaus,

On Wed, Jul 4, 2018 at 1:15 PM, Nikolaus Voss
<nikolaus.voss@loewensteinmedical.de> wrote:
> On Wed, 4 Jul 2018, Javier Martinez Canillas wrote:

[snip]

>> 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.
>
>
> Ok, in my opinion it is an elegant way of not bloating the driver when no
> explicit handling (e.g. reading DT properties) is needed. Just adding an
> of_device_id doesn't change any driver functionality then but only maps to
> an already existing i2c_table_id.
>

I disagree, in the case of OF for example a compatible string is
composed of both a vendor a device, the complete tuple is what should
be matched.

But with the fallback, only the device portion would be used so both
<foo,bar> and <baz,bar> will match against the i2c device with id
"bar". It may or may not be correct but the vendor portion is very
important to disambiguate.

>>
>> 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).
>
>
> Valid point, thanks. I will change that.
>
>>
>>> 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.
>
>
> It could have been a null pointer and device driver binding (and
> auto-loading) done just via driver.name.
>

I'm not sure I understood this comment.

> Niko
>

Best regards,
Javier