linux-kernel - Re: [PATCH v3 2/2] i2c: exynos5: add support for ExynosAutov9 SoC

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]

Date:   Wed, 17 Nov 2021 23:17:55 +0100
From:   David Virag <virag.david003@...il.com>
To:     Chanho Park <chanho61.park@...sung.com>,
        'Sam Protsenko' <semen.protsenko@...aro.org>,
        'Jaewon Kim' <jaewon02.kim@...sung.com>
Cc:     'Krzysztof Kozlowski' <krzysztof.kozlowski@...onical.com>,
        'Wolfram Sang' <wsa@...nel.org>,
        'Rob Herring' <robh+dt@...nel.org>,
        linux-samsung-soc@...r.kernel.org, linux-i2c@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 2/2] i2c: exynos5: add support for ExynosAutov9 SoC

> Current version of USI is v2 which means there is a v1 version as well.
> It might be a non-upstream SoC so we don't need to consider it so far.

The Exynos7885 I'm working on has USI v1. It doesn't seem to be heavily
used as the SoC has just 3 USI blocks if I didn't miss anything.

The most obvious difference I saw was instead of having 3 modes (SPI,
UART, and HSI2C) It has:
 - SPI
 - HSI2C0 (meaning I2C pins are connected to the first 2 pins out of
the 4 if I understand it correctly)
 - HSI2C1 (connected to last 2 pins)
 - HSI2C0_HSI2C1 (2 I2C devices connected to first 2 and last 2 pins)
 - UART
 - UART_HSI2C1 (first 2 pins are UART, rest is I2C)

Also there doesn't seem to be any USI_CON or USI_OPTION registers in
SPI, UART, or I2C. It seems like it's just the USI driver doing all the
work (just setting up the SYSREG) and the I2C driver writing values to
the SYSREG at suspend/resume for some reason. 

>From the looks of it, it doesn't look like it'd be hard to add this to
USI v2 drivers when needed. (USI driver (if that's the way it will go)
would just need minor modifications to add v1 modes and UART/SPI/I2C
drivers may just work with non-USI compatibles/would only need SoC
specific data added).

Best Regards,
David