From: "Alex Bennée" <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 [thread overview]
Message-ID: <87y2ev6pkw.fsf@linaro.org> (raw)
In-Reply-To: <20210309132725.638205-1-avri.altman@wdc.com>
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
--
Alex Bennée
next prev parent reply other threads:[~2021-03-10 14:39 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-03 13:54 [RFC PATCH 0/5] RPMB internal and user-space API + WIP virtio-rpmb frontend Alex Bennée
2021-03-03 13:54 ` [RFC PATCH 1/5] rpmb: add Replay Protected Memory Block (RPMB) subsystem Alex Bennée
2021-03-03 15:28 ` Ulf Hansson
2021-03-03 19:37 ` Alex Bennée
2021-03-04 20:56 ` Arnd Bergmann
2021-03-05 7:51 ` Joakim Bech
2021-03-05 8:44 ` Arnd Bergmann
2021-03-08 16:20 ` Linus Walleij
2021-03-09 17:12 ` David Howells
2021-03-10 4:54 ` Sumit Garg
2021-03-10 9:33 ` Linus Walleij
2021-03-09 21:09 ` Hector Martin
2021-03-10 5:14 ` Sumit Garg
2021-03-10 8:47 ` Hector Martin
2021-03-10 9:48 ` Linus Walleij
2021-03-10 13:52 ` Hector Martin
2021-03-11 0:36 ` Linus Walleij
2021-03-11 9:22 ` Hector Martin
2021-03-11 14:06 ` Linus Walleij
2021-03-11 20:02 ` Hector Martin
2021-03-12 9:22 ` Linus Walleij
2021-03-10 10:29 ` Sumit Garg
2021-03-11 0:49 ` Linus Walleij
2021-03-11 1:07 ` James Bottomley
2021-03-11 9:45 ` Hector Martin
2021-03-11 14:31 ` Linus Walleij
2021-03-11 20:29 ` Hector Martin
2021-03-11 20:57 ` Alex Bennée
2021-03-12 10:00 ` Linus Walleij
2021-03-12 9:47 ` Linus Walleij
2021-03-12 11:59 ` Sumit Garg
2021-03-12 12:08 ` Ilias Apalodimas
2021-03-03 13:54 ` [RFC PATCH 2/5] char: rpmb: provide a user space interface Alex Bennée
2021-03-04 7:01 ` Winkler, Tomas
2021-03-04 10:19 ` Alex Bennée
2021-03-04 10:34 ` Winkler, Tomas
2021-03-04 17:52 ` Alex Bennée
2021-03-04 19:54 ` Winkler, Tomas
2021-03-04 21:43 ` Arnd Bergmann
2021-03-05 6:31 ` Winkler, Tomas
2021-03-04 21:08 ` Arnd Bergmann
2021-03-03 13:54 ` [RFC PATCH 3/5] tools rpmb: add RPBM access tool Alex Bennée
2021-03-03 13:54 ` [RFC PATCH 4/5] rpmb: create virtio rpmb frontend driver [WIP] Alex Bennée
2021-03-03 13:55 ` [RFC PATCH 5/5] tools/rpmb: simple test sequence Alex Bennée
2021-03-09 13:27 ` [RFC PATCH 0/5] RPMB internal and user-space API + WIP virtio-rpmb frontend Avri Altman
2021-03-10 14:29 ` Alex Bennée [this message]
2021-03-11 13:45 ` Avri Altman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y2ev6pkw.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=Matti.Moell@opensynergy.com \
--cc=arnd@linaro.org \
--cc=avri.altman@wdc.com \
--cc=bing.zhu@intel.com \
--cc=hmo@opensynergy.com \
--cc=ilias.apalodimas@linaro.org \
--cc=joakim.bech@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-nvme@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=maxim.uvarov@linaro.org \
--cc=ruchika.gupta@linaro.org \
--cc=tomas.winkler@intel.com \
--cc=yang.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox