[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<PH7PR16MB6196D9CB65C664259C166D65E51FA@PH7PR16MB6196.namprd16.prod.outlook.com>
Date: Thu, 25 Sep 2025 15:45:28 +0000
From: Avri Altman <Avri.Altman@...disk.com>
To: Bean Huo <beanhuo@...pp.de>, "avri.altman@....com" <avri.altman@....com>,
"bvanassche@....org" <bvanassche@....org>, "alim.akhtar@...sung.com"
<alim.akhtar@...sung.com>, "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
"martin.petersen@...cle.com" <martin.petersen@...cle.com>,
"can.guo@....qualcomm.com" <can.guo@....qualcomm.com>,
"ulf.hansson@...aro.org" <ulf.hansson@...aro.org>, "beanhuo@...ron.com"
<beanhuo@...ron.com>, "jens.wiklander@...aro.org" <jens.wiklander@...aro.org>
CC: "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v1 1/3] rpmb: move rpmb_frame struct and constants to
common header
> On Wed, 2025-09-24 at 06:12 +0000, Avri Altman wrote:
> > > From: Bean Huo <beanhuo@...ron.com>
> > >
> > > Move struct rpmb_frame and RPMB operation constants from MMC block
> > > driver to include/linux/rpmb.h for reuse across different RPMB
> > > implementations (UFS, NVMe, etc.).
> > UFS RPMB differs from mmc RPMB in several levels:
> > - 9 vs. 5 operations
> > - frame structure: extended 4k
> > - rpmb unit descriptor
> > etc.
> > And as time goes on, this gap is likely to become larger, As mmc is
> > not very likely to introduce major changes.
> >
> > Thus, you might want to consider having an internal ufs header - will
> > simplify things in the future.
> >
> > Thanks,
> > Avri
>
>
> Avri,
>
> thanks, I got your points.
>
> In normal mode, UFS RPMB uses the same 512-byte frame format as eMMC
> RPMB, with the same fields (MAC, nonce, counter, address, etc.). That’s why it
> makes sense to keep a single definition of the frame struct in
> include/linux/rpmb.h, so both eMMC and UFS RPMB drivers can reuse it
> without duplication.
>
> The major differences only exist in UFS RPMB advanced mode, correct?
>
> For advanced mode, our plan is to introduce a UFS-specific header for the
> additional features (extended 4K frame, new opcodes, descriptors), so that
> UFS can evolve independently without breaking the shared interface.
>
> let's firstly enable UFS RPMB in normal mode, since its OP-TEE application is
> avaiable in OP-TEE OS, the custoemr can use it simply. As discussed with Jens,
> we can move next step for advanced RPMB for UFS, is this ok for you?
Yes. Sound good.
Thanks,
Avri
>
>
> Kind regards,
> Bean
>
Powered by blists - more mailing lists