Bean Huo <huobean@xxxxxxxxx> writes: > On Tue, 2022-04-05 at 16:43 +0100, Alex Bennée wrote: >> >> Bean Huo <huobean@xxxxxxxxx> writes: >> >> > Hi Alex, >> > >> > Thanks for this unified RPMB interface, I wanted to verify this on >> > our >> > UFS, it seems you didn't add the UFS access interface in this >> > version >> > from your userspace tools, right? >> >> No I didn't but it should be easy enough to add some function pointer >> redirection everywhere one of the op_* functions calls a vrpmb_* >> function. Do you already have a UFS RPMB device driver? >> > > Hi Alex, > Thanks for your feedback. > > We now access UFS RPMB through the RPMB LUN BSG device, RPMB is a well- > known LU and we have a userspace tool to access it. > > I see that if we're going to use your interface, "static struct > rpmb_ops" should be registered from a lower-level driver, for example > in a UFS driver, yes there should be no problem with this registration, > but I don't know with the current way Compared, what are the advantages > to add a driver. maybe the main advantage is that we will have an > unified user space tool for RPMB. right? Pretty much. The main issue for virtio-rpmb is it doesn't really fit neatly into the block stack because all it does is the RPMB part so a non-block orientate API makes sense. Can you point be to where the UFS driver does it's current RPMB stuff? > > Kind regards, > Bean -- Alex Bennée
