linux-kernel - Re: [PATCH v5 5/6] i2c: npcm: use i2c frequency table

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: <CACD3sJZEUp3PQ=POGtHsN5su6LbXyOfUiXv5EsptiY3GxNrR7w@mail.gmail.com>
Date: Fri, 4 Oct 2024 09:51:21 +0800
From: Tyrone Ting <warp5tw@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: avifishman70@...il.com, tmaimon77@...il.com, tali.perry1@...il.com, 
	venture@...gle.com, yuenn@...gle.com, benjaminfair@...gle.com, 
	andi.shyti@...nel.org, wsa@...nel.org, rand.sec96@...il.com, 
	wsa+renesas@...g-engineering.com, tali.perry@...oton.com, 
	Avi.Fishman@...oton.com, tomer.maimon@...oton.com, KWLIU@...oton.com, 
	JJLIU0@...oton.com, kfting@...oton.com, openbmc@...ts.ozlabs.org, 
	linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 5/6] i2c: npcm: use i2c frequency table

Hi Andy:

Thank you for your comments.

Andy Shevchenko <andriy.shevchenko@...ux.intel.com> 於 2024年10月1日 週二 下午9:23寫道：
>
> On Tue, Oct 01, 2024 at 02:28:54PM +0800, Tyrone Ting wrote:
> > From: Tyrone Ting <kfting@...oton.com>
> >
> > Modify i2c frequency from table parameters
> > for NPCM i2c modules.
>
> This two lines have a too small wrapping limit.
>

I'll make the statement in one line.

> > Supported frequencies are:
> >
> > 1. 100KHz
> > 2. 400KHz
> > 3. 1MHz
> >
> > The original equations were tested on a variety of chips and base clocks.
> > Since we added devices that use higher frequencies of the module we
> > saw that there is a mismatch between the equation and the actual
> > results on the bus itself, measured on scope.
> >
> > Meanwhile, the equations were not accurate to begin with.
> > They are an approximation of the ideal value. The ideal value is
> > calculated per frequency of the core module.
> >
> > So instead of using the equations we did an optimization per module
> > frequency, verified on a device.
> >
> > Most of the work was focused on the rise time of the SCL and SDA,
> > which depends on external load of the bus and PU.
> >
> > Different PCB designs, or specifically to this case: the number
> > and type of targets on the bus, impact the required values for
> > the timing registers.
> >
> > Users can recalculate the numbers for each bus and get an even better
> > optimization, but our users chose not to.
> >
> > We manually picked values per frequency that match the entire valid
> > range of targets (from 1 to max number). Then we check against the
> > AMR described in SMB spec and make sure that none of the values
> > is exceeding.
> >
> > This process was led by the chip architect and included a lot of testing.
>
> Personally I consider table approach is not so flexible and it is definitely
> does not scale (in the result — hard to maintain for all customers), but if
> it's hard to calculate all necessary data and there are other pros of it,
> I'm fine.
>
> TL;DR: I don't like this patch, but I don't want to stop you, hence no tags
> from me.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>

Thank you again.

Regards,
Tyrone