On Fri, Mar 12, 2021 at 10:05 AM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> On Thu, 11 Mar 2021 at 20:08, Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
> > On Thu, Mar 11, 2021 at 02:48:23PM +0100, Linus Walleij wrote:
> >
> > It happens in the same place, cqhci-crypto.c. Mediatek's eMMC inline encryption
> > hardware follows the eMMC standard fairly closely, so Peng's patch series just
> > sets MMC_CAP2_CRYPTO to make it use the standard cqhci crypto code, and does a
> > couple extra things to actually enable the hardware's crypto support on Mediatek
> > platforms since it isn't enabled by default. (*Why* it requires an SMC call to
> > enable instead of just working as expected, I don't know though.)
>
> As I have probably indicated earlier, I am starting to become more and
> more annoyed with these arm_smccc_smc() calls in generic drivers.
>
> As a matter of fact, I think the situation is about to explode. Just
> do a "git grep arm_smccc_smc" and you will find that it's not only SoC
> specific drivers that call them. In general we want to keep drivers
> portable and this is clearly moving in the wrong direction. Or maybe
> it's just me being grumpy and having a bad day. :-)
I agree, this really does feel underspecified, as there is no way to
actually know which smc interfaces are available, or which ones belong
to a particular driver. Simply calling them is not that different from
using an ioremap() on a hardwired physical address just because you
know where a device is on a given SoC. Or another way of looking at
it is that these are function calls that are arbitrarily moved out from
the kernel into a piece of (usually) closed source software running on
the same chip.
A first step toward managing this better might be to enforce namespaces
of the smc calls, if we can find a way to limit arm_smccc_smc() calls
those that have the first argument defined in a central header file.
Arnd
