> 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
