Messages in this thread | | | Date | Wed, 23 Nov 2022 07:36:52 +0100 | Subject | Re: [PATCH 571/606] serial: sc16is7xx: Convert to i2c's .probe_new() | From | 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@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
| |