Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
From:   Konrad Dybcio <konradybcio@gmail.com>
Date:   Fri, 23 Oct 2020 13:55:13 +0200
Message-ID: <CAMS8qEVZFBFv4VpFtijxnR8Z5-wWFkpZx8nKOmbm6U-vah7eLg@mail.gmail.com>
Subject: Qualcomm Crypto Engine driver
To:     linux-crypto@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi,

I was investigating Qualcomm Crypto Engine support on my sdm630
smartphone and found out that the already-present driver is
compatible. In meantime I found two issues:

1. The driver doesn't seem to have a maintainer? drivers/crypto/qce
doesn't seem to exist in the MAINTAINERS file..

2. The person who first submitted it likely faced an issue with memory
allocation. On downstream (taking sdm630 as example) Qualcomm decided
to allocate 0x20000@1de0000 for the device and 0x24000@1dc4000 for
BAM, which isn't something upstream driver agrees with (these memory
regions overlap and the driver straight up doesn't probe..).
I "fixed" it by giving (QCE register) - (DMA register) memory size to
the DMA (which doesn't seem to cause any issues) and changing all the
registers in the header file by 0x1A000 (just like it is downstream
[1]), but the former person "fixed" it by offsetting the QCE node in
qcom-ipq4019.dtsi by 0x1A000.

Which fix is more correct? I'd advocate for my one as the more
accurate, but I can adapt to what's already been invented.. Test
results ("cryptsetup benchmark")  don't differ between these two
(though they are worse than without the QCE, which is most likely
related to unimplemented bus bandwidth scaling).


[1] https://github.com/sonyxperiadev/kernel/blob/aosp/LA.UM.7.1.r1/drivers/crypto/msm/qcryptohw_50.h

Konrad Dybcio