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: <587c61a76c8547d0a36dd11071bfcb2d@nokia-sbell.com>
Date:   Mon, 15 Nov 2021 10:41:06 +0000
From:   "Wang, Lawrence (NSB - CN/Hangzhou)" <lawrence.wang@...ia-sbell.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
CC:     "jarkko.nikula@...ux.intel.com" <jarkko.nikula@...ux.intel.com>,
        "mika.westerberg@...ux.intel.com" <mika.westerberg@...ux.intel.com>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Wang@...inb193.emea.nsn-net.net" <Wang@...inb193.emea.nsn-net.net>
Subject: RE: [PATCH] i2c: designware: Get HCNT/LCNT values from dts

Hello Shevchenko

Thanks for your quick reply.

Besides the fact it misses DT schema update, why this is needed at all? 
------> we need a interface to configure the HCNT/LCNT via dts (current we just have ACPI to config it).
What's wrong with the existing DT timings? 
--------> the HCNT/LCNT value calculated by code is not accuracy. This is similar changes as the ACPI interface.
	i2c_dw_acpi_params(device, "SSCN", &dev->ss_hcnt, &dev->ss_lcnt, &ss_ht);
	i2c_dw_acpi_params(device, "FPCN", &dev->fp_hcnt, &dev->fp_lcnt, &fp_ht);
	i2c_dw_acpi_params(device, "HSCN", &dev->hs_hcnt, &dev->hs_lcnt, &hs_ht);
	i2c_dw_acpi_params(device, "FMCN", &dev->fs_hcnt, &dev->fs_lcnt, &fs_ht);
										   
- i2c-scl-falling-time-ns
- i2c-scl-internal-delay-ns
- i2c-scl-rising-time-ns
- i2c-sda-falling-time-ns
Yeah, I know those properties. But those are common for i2c.
My changes is for the specific HW controller(designware) for configuring its two register HCNT/LCNT.
In this case, still we need one property per each value?


--
With Best Regards,
Lawrence, Wang

-----Original Message-----
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com> 
Sent: 2021年11月15日 18:28
To: Wang, Lawrence (NSB - CN/Hangzhou) <lawrence.wang@...ia-sbell.com>
Cc: jarkko.nikula@...ux.intel.com; mika.westerberg@...ux.intel.com; linux-i2c@...r.kernel.org; linux-kernel@...r.kernel.org; Wang@...inb193.emea.nsn-net.net
Subject: Re: [PATCH] i2c: designware: Get HCNT/LCNT values from dts

On Mon, Nov 15, 2021 at 12:19:26PM +0200, Andy Shevchenko wrote:
> On Mon, Nov 15, 2021 at 10:35:55AM +0100, Lawrence,Wang wrote:
> > From: "Wang, Lawrence" <lawrence.wang@...ia-sbell.com>
> > 
> > Current code support config the HCNT/LCNT only via ACPI method. for 
> > those platform that not support ACPI, will get the HCNT/LCNT value 
> > based on input clock. But it is not always accuracy. for example in 
> > some platform will get lower speed(320khz) in fast mode, and get 
> > faster speed(105khz/even more) in standard mode.
> > 
> > This patch makes it possible for the non-ACPI platform to pass more 
> > optimal HCNT/LCNT values to the core driver via dts if they are known beforehand.
> > If these are not set we use the calculated values.
> 
> Besides the fact it misses DT schema update, why this is needed at all?
> What's wrong with the existing DT timings?

Just for your convenience an excerpt from Documentation/devicetree/bindings/i2c/i2c.txt

- i2c-scl-falling-time-ns
Number of nanoseconds the SCL signal takes to fall; t(f) in the I2C specification.

- i2c-scl-internal-delay-ns
Number of nanoseconds the IP core additionally needs to setup SCL.

- i2c-scl-rising-time-ns
Number of nanoseconds the SCL signal takes to rise; t(r) in the I2C specification.

- i2c-sda-falling-time-ns
Number of nanoseconds the SDA signal takes to fall; t(f) in the I2C specification.

--
With Best Regards,
Andy Shevchenko


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ