linux-kernel - Re: [RFC PATCH 0/5] Add dedicated Qcom ICE driver

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: <Y+t5V1Uu702JplW1@linaro.org>
Date:   Tue, 14 Feb 2023 14:06:47 +0200
From:   Abel Vesa <abel.vesa@...aro.org>
To:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        "James E . J . Bottomley" <jejb@...ux.ibm.com>,
        "Martin K . Petersen" <martin.petersen@...cle.com>,
        Manivannan Sadhasivam <mani@...nel.org>,
        Eric Biggers <ebiggers@...gle.com>
Cc:     linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-mmc@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: [RFC PATCH 0/5] Add dedicated Qcom ICE driver

On 23-02-14 14:02:48, Abel Vesa wrote:
> As both SDCC and UFS drivers use the ICE with duplicated implementation,
> while none of the currently supported platforms make use concomitantly
> of the ICE IP block, the new SM8550 allows both UFS and SDCC to do so.
> In order to support such scenario, there is a need for a unified
> implementation and a devicetree node to be shared between both types
> of storage devices. So lets drop the duplicate implementation of the ICE
> from both SDCC and UFS and make it a dedicated (soc) driver.
> 
> This RFC should be treated as work-in-progress. Initially, its goal is
> to figure out what is the most agreeable implementation for both types
> of storage. Note that currently, only one ICE instance is supported
> (like the existing HW suggests) and it is laking refcounting and locking
> of any sort. Also missing bindings schema file for now.
> 
> Any suggestions are welcome at this point, including the location of
> such a new driver.

Forgot to mention here that I only managed to test the UFS on SM8450
HDK. Though functionally nothing should be impacted, I intend to test
the SDCC on SDM630 soon.

The devicetree sdm630 patch is here for proof-of-concept, mainly.

> 
> Abel Vesa (5):
>   soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver
>   arm64: dts: qcom: sm8450: Add the Inline Crypto Engine node
>   arm64: dts: qcom: sdm630: Add the Inline Crypto Engine node
>   scsi: ufs: ufs-qcom: Switch to the new ICE API
>   mmc: sdhci-msm: Switch to the new ICE API
> 
>  arch/arm64/boot/dts/qcom/sdm630.dtsi          |  18 +-
>  arch/arm64/boot/dts/qcom/sm8450-hdk.dts       |   4 +
>  arch/arm64/boot/dts/qcom/sm8450.dtsi          |  24 +-
>  drivers/mmc/host/sdhci-msm.c                  | 252 ++----------------
>  drivers/soc/qcom/Kconfig                      |  10 +
>  drivers/soc/qcom/Makefile                     |   1 +
>  .../ufs-qcom-ice.c => soc/qcom/qcom-ice.c}    | 247 +++++++++++------
>  drivers/ufs/host/Kconfig                      |   1 -
>  drivers/ufs/host/Makefile                     |   1 -
>  drivers/ufs/host/ufs-qcom.c                   |  42 ++-
>  drivers/ufs/host/ufs-qcom.h                   |  32 +--
>  include/soc/qcom/ice.h                        |  61 +++++
>  12 files changed, 326 insertions(+), 367 deletions(-)
>  rename drivers/{ufs/host/ufs-qcom-ice.c => soc/qcom/qcom-ice.c} (50%)
>  create mode 100644 include/soc/qcom/ice.h
> 
> -- 
> 2.34.1
>