linux-kernel - Re: [PATCH v2 6/7] 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: <ZtWnPTSu1RKmIlhK@smile.fi.intel.com>
Date: Mon, 2 Sep 2024 14:53:33 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Tali Perry <tali.perry1@...il.com>
Cc: Tyrone Ting <warp5tw@...il.com>, avifishman70@...il.com,
	tmaimon77@...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 v2 6/7] i2c: npcm: use i2c frequency table

On Sun, Sep 01, 2024 at 06:53:38PM +0300, Tali Perry wrote:
> On Fri, Aug 30, 2024 at 10:19 PM Andy Shevchenko
> <andriy.shevchenko@...ux.intel.com> wrote:
> >
> > On Fri, Aug 30, 2024 at 11:46:39AM +0800, Tyrone Ting wrote:
> > > Modify i2c frequency from table parameters
> > > for NPCM i2c modules.
> > >
> > > Supported frequencies are:
> > >
> > > 1. 100KHz
> > > 2. 400KHz
> > > 3. 1MHz
> >
> > There is no explanations "why". What's wrong with the calculations done in the
> > current code?
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
> >
> >
> Hi Andy,
> 
> 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.
> 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.
> We needed to make sure that in all valid range of load the rise time
> is compliant of the SMB spec timing requirements.
> 
> This patch include the final values after extensive testing both at
> Nuvoton as well as at customer sites.

But:
1) why is it better than do calculations?
2) can it be problematic on theoretically different PCB design in the future?

P.S. If there is a good explanations to these and more, elaborate this in the
commit message.

-- 
With Best Regards,
Andy Shevchenko