Re: [PATCH 571/606] serial: sc16is7xx: Convert to i2c's .probe_new()

[Jiri Slaby]

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@xxxxxxxxxxxxxx>
> > >
> > > .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@xxxxxxxxxxxxxxxxx/,
> 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