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
