lkml.org 
[lkml]   [2022]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 571/606] serial: sc16is7xx: Convert to i2c's .probe_new()
From
Hi,

On 21. 11. 22, 8:07, Uwe Kleine-König wrote:
> Hello Jiri,
>
> On Mon, Nov 21, 2022 at 07:03:41AM +0100, Jiri Slaby wrote:
>> On 18. 11. 22, 23:45, Uwe Kleine-König wrote:
>>> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>>>
>>> .probe_new() doesn't get the i2c_device_id * parameter, so determine
>>> that explicitly in the probe function.
>>
>> I wonder why -- is this a new approach to probe functions? Or is only i2c
>> affected? And why? Could you point to the commit introducing and describing
>> the change in the i2c core?
>
> I didn't sent the cover letter to all recipents of the individual
> patches, so flow of information is a bit rough. Sorry about that.
>
> You can find it at
> https://lore.kernel.org/lkml/20221118224540.619276-1-uwe@kleine-koenig.org/,
> it should answer your question.

Yes, I looked up that beforehand, but was no more clever after reading it.

> The short version is: The i2c framework does a more or less expensive
> lookup for each call to .probe() to provide the id parameter. A relevant
> part of the drivers however doesn't use this parameter, so the idea is
> to let the drivers who actually need it, determine it themselves.
>
> Statistics for the current state of this series in my tree:
> Among the 602 converted drivers, 404 don't make use of the parameter.

So doesn't it make sense to provide both probe with no id and "probe_id"
then? 200 is quite a few (a third to be precise).

BTW is this a performance issue? I.e. does it slow down the boot?

thanks,
--
js
suse labs

\
 
 \ /
  Last update: 2022-11-23 07:37    [W:0.330 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site