RE: [RFC PATCH 0/5] RPMB internal and user-space API + WIP virtio-rpmb frontend

[Avri Altman]

> Avri Altman <avri.altman@xxxxxxx> 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.
Yes.  It took us a while to clean those tools to perform by-spec rpmb access.

Anyway, I do see value in Tomas's/your approach, 
that will refrain from the need to register a designated block device.
Provided that each host is allowed to register its own ops.
Those ops can be a super-set of the various device types.
For ufs and mmc rpmb ops contains 7 operations.

Thanks,
Avri