linux-kernel - Re: [PATCH 1/2] eeprom: ee1004: Call i2c_new_scanned

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] [day] [month] [year] [list]

Message-ID: <2ecdfad0-df83-498a-b487-b8c52def0bce@roeck-us.net>
Date: Sat, 29 Jun 2024 15:26:46 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Heiner Kallweit <hkallweit1@...il.com>, linux-kernel@...r.kernel.org
Cc: Arnd Bergmann <arnd@...db.de>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Thomas Weißschuh <linux@...ssschuh.net>
Subject: Re: [PATCH 1/2] eeprom: ee1004: Call i2c_new_scanned_device to
 instantiate thermal sensor

On 6/29/24 15:00, Heiner Kallweit wrote:
> On 29.06.2024 19:37, Guenter Roeck wrote:
>> Instantiating a device by calling i2c_new_client_device() assumes that the
>> device is not already instantiated. If that is not the case, it will return
>> an error and generate a misleading kernel log message.
>>
>> i2c i2c-0: Failed to register i2c client jc42 at 0x18 (-16)
>>
>> This can be reproduced by unloading the ee1004 driver and loading it again.
>>
>> Avoid this by calling i2c_new_scanned_device() instead, which returns
>> silently if a device is already instantiated or does not exist.
>>
> However i2c_new_scanned_device() runs i2c_default_probe() on the device,
> whilst i2c_new_client_device() doesn't access the i2c bus.
> If possible I'd like to avoid this overhead.
> 

I am not as much concerned with that overhead since there are already several
other i2c accesses in both this driver and in the jc42 driver, so it seemed to
me that another quick operation does not make much of a difference. Also, I
wanted to suggest a solution which does not require changing the i2c core.
However, I am not "married" to this solution. Please feel free to suggest
something different, or to drop this patch (and the next one) entirely.

Thanks,
Guenter