linux-kernel - Re: [PATCH v8 2/4] i2c: tegra: Add HS mode 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] [day] [month] [year] [list]

Message-ID: <a85af39b-166a-4eff-a6c1-4721e7374c73@nvidia.com>
Date: Thu, 18 Sep 2025 18:33:37 +0100
From: Jon Hunter <jonathanh@...dia.com>
To: Akhil R <akhilrajeev@...dia.com>
Cc: andi.shyti@...nel.org, conor+dt@...nel.org, devicetree@...r.kernel.org,
 digetx@...il.com, kkartik@...dia.com, krzk+dt@...nel.org,
 ldewangan@...dia.com, linux-i2c@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org, robh@...nel.org,
 smangipudi@...dia.com, thierry.reding@...il.com
Subject: Re: [PATCH v8 2/4] i2c: tegra: Add HS mode support


On 18/09/2025 18:12, Akhil R wrote:

...

>> OK, I see now. So we need to program the normal timings first and then
>> we are re-using the variables to then program the HS timings. And
>> because of that we cannot setup the HS timing values in the existing
>> case statement?
>>
>>> So, I am not sure if moving this section to the switch block will add
>>> any benefit. We might end up making it more complicated that it is now.
>>
>> Yes that's true. It was really this else part that caught my eye ...
>>
>>    } else if (t->bus_freq_hz > I2C_MAX_FAST_MODE_PLUS_FREQ) {
>>     	t->bus_freq_hz = I2C_MAX_FAST_MODE_PLUS_FREQ;
>>    }
>>
>> It feels like at least this part should be handled as part of the case
>> statement.
> 
> Yes. That makes sense. If you agree, we can remove the else part because
> we weren't doing this before when HS mode support was not there. It is not
> directly related to the HS mode support as well. We can add this at a later
> point in a separate patch if found required.

Hmmm ... I am not sure because then we could potentially program the 
packet header incorrectly later on. May be that will never happen? 
However, I think it would be better to not make any assumptions here and 
make the code as robust as possible.

Jon

-- 
nvpublic