linux-kernel - Re: [PATCHv5 1/2] i2c: designware: introduce a custom scl recovery for SoCFPGA platforms

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: <b4fb0c7f-2fd9-35ff-1d09-8940e3b66455@kernel.org>
Date:   Mon, 20 Jun 2022 17:41:01 -0500
From:   Dinh Nguyen <dinguyen@...nel.org>
To:     Jarkko Nikula <jarkko.nikula@...ux.intel.com>
Cc:     andriy.shevchenko@...ux.intel.com, mika.westerberg@...ux.intel.com,
        robh+dt@...nel.org, krzk+dt@...nel.org, linux-i2c@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCHv5 1/2] i2c: designware: introduce a custom scl recovery
 for SoCFPGA platforms



On 6/17/22 07:59, Jarkko Nikula wrote:
> Hi
> 
> On 6/16/22 17:12, Dinh Nguyen wrote:
>> The I2C pins on the SoCFPGA platforms do not go through a GPIO module,
>> thus cannot be recovered by the default method of by doing a GPIO access.
>> Only a reset of the I2C IP block can a recovery be successful.
>>
> One thing what is unclear to me how does this release the I2C slave that 
> potentially keeps the SDA stuck low. Does platform specific reset 
> sequence send 9 SCL pulses, toggle HW reset of the clients or cycle 
> power of them?
> 
> If recovery is only controller point of view then worth to emphasis it 
> in the commit log and perhaps add a comment too into 
> i2c_socfpga_scl_recovery(). Some might hit an issue that I2C client is 
> stuck and wonder why recovery won't work.

The recovery is only resetting the controller itself and not the client. 
I'll add a comment in v6 to highlight this.
> 
>> The assignment of the recover_bus needs to get done before the call to
>> devm_gpiod_get_optional(), otherwise, the assignment is not taking place
>> because of an error after returning from devm_gpiod_get_optional().
>>
> This sentence no longer true after v3?

Correct...will update.

Dinh