linux-kernel - Re: [PATCH v13 2/3] i2c: octeon: remove 10-bit addressing support

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: <beqo7xnbo3obxxkop6rq3awzsdcjb7sioeapqj3naekqes2bk4@3ojtbocdejca>
Date: Wed, 19 Mar 2025 10:47:40 +0100
From: Andi Shyti <andi.shyti@...nel.org>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>, 
	Aryan Srivastava <aryan.srivastava@...iedtelesis.co.nz>, Andy Shevchenko <andy.shevchenko@...il.com>, 
	Markus Elfring <Markus.Elfring@....de>, linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Robert Richter <rric@...nel.org>
Subject: Re: [PATCH v13 2/3] i2c: octeon: remove 10-bit addressing support

On Wed, Mar 19, 2025 at 06:41:24AM +0100, Wolfram Sang wrote:
> > The datasheet I have isn't very clear on this part. Also, I'd
> > like to know if there's any product line that could be negatively
> > impacted by this patch.
> 
> In my whole I2C life, I have neither seen a target supporting 10-bit
> addressing nor a a system that uses 10-bit addressing.

mmhhh... I have to work with my memory and dig into my
documentations, but I think I've seen some STM sensors supporting
also 10 bit addresses.

> I am even tempted
> to remove support from the kernel omce in a while. If the support is
> broken in this driver, it can be removed.

The documentation I have is in line with the patch (I had to read
it twice, though), but I didn't want to exclude corner cases.

> A working version (if
> possible) can be added again by someone who needs it. I am taking bets
> it will be "never". Besides, the driver never set I2C_FUNC_10BIT_ADDR,
> so it really shouldn't have been used anywhere.
> 
> Reviewed-by: Wolfram Sang <wsa+renesas@...g-engineering.com>

OK, I had a little hesitation here, but if you are sure about it
(and Andy as well) I'll take it in.

Thanks, Wolfram!
Andi