Messages in this thread | | | From | Alex Bennée <> | Subject | Re: [PATCH v2 0/4] rpmb subsystem, uapi and virtio-rpmb driver | Date | Wed, 06 Apr 2022 12:22:00 +0100 |
| |
Bean Huo <huobean@gmail.com> writes:
> On Tue, 2022-04-05 at 16:43 +0100, Alex Bennée wrote: >> >> Bean Huo <huobean@gmail.com> 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
| |