linux-kernel - Re: [PATCH 571/606] serial: sc16is7xx: Convert to i2c's .probe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0bfea903-5efd-a76d-5944-16a2c9362adb@kernel.org>
Date:   Wed, 23 Nov 2022 07:36:52 +0100
From:   Jiri Slaby <jirislaby@...nel.org>
To:     Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
Cc:     Uwe Kleine-König <uwe@...ine-koenig.org>,
        Angel Iglesias <ang.iglesiasg@...il.com>,
        Lee Jones <lee.jones@...aro.org>,
        Grant Likely <grant.likely@...aro.org>,
        Wolfram Sang <wsa@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
        linux-i2c@...r.kernel.org, kernel@...gutronix.de
Subject: Re: [PATCH 571/606] serial: sc16is7xx: Convert to i2c's .probe_new()

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@...gutronix.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