Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
References: <20210303135500.24673-1-alex.bennee@linaro.org>
 <20210309132725.638205-1-avri.altman@wdc.com>
User-agent: mu4e 1.5.8; emacs 28.0.50
From:   Alex =?utf-8?Q?Benn=C3=A9e?= <alex.bennee@linaro.org>
To:     Avri Altman <avri.altman@wdc.com>
Cc:     Matti.Moell@opensynergy.com, arnd@linaro.org, bing.zhu@intel.com,
        hmo@opensynergy.com, ilias.apalodimas@linaro.org,
        joakim.bech@linaro.org, linux-kernel@vger.kernel.org,
        linux-mmc@vger.kernel.org, linux-nvme@vger.kernel.org,
        linux-scsi@vger.kernel.org, maxim.uvarov@linaro.org,
        ruchika.gupta@linaro.org, tomas.winkler@intel.com,
        yang.huang@intel.com
Subject: Re: [RFC PATCH  0/5] RPMB internal and user-space API + WIP
 virtio-rpmb frontend
Date:   Wed, 10 Mar 2021 14:29:15 +0000
In-reply-to: <20210309132725.638205-1-avri.altman@wdc.com>
Message-ID: <87y2ev6pkw.fsf@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


Avri Altman <avri.altman@wdc.com> writes:

> The mmc driver has some hooks to support rpmb access, but access is
> mainly facilitated from user space, e.g. mmc-utils.
>
> The ufs driver has no concept of rpmb access - it is facilitated via
> user space, e.g. ufs-utils and similar.
>
> Both for ufs and mmc, rpmb access is defined in their applicable jedec
> specs. This is the case for few years now - AFAIK No new rpmb-related
> stuff is expected to be introduced in the near future.
>
> What problems, as far as mmc and ufs, are you trying to solve by this
> new subsystem?

Well in my case the addition of virtio-rpmb. As yet another RPMB device
which only supports RPMB transactions and isn't part of a wider block
device. The API dissonance comes into play when looking to implement it
as part of wider block device stacks and then having to do things like
fake 0 length eMMC devices with just an RPMB partition to use existing
tools.

I guess that was the original attraction of having a common kernel
subsystem to interact with RPMB functionality regardless of the
underlying HW. However from the other comments it seems the preference
is just to leave it to user-space and domain specific tools for each
device type.

>
> Thanks,
> Avri


--=20
Alex Benn=C3=A9e