There is an additional functionality, which is require the host lock to be held for several write commands - the FFU. In case of FFU, the FW can be download/write in several iterations of Write command (CMD25). This sequence should not be interrupted by regular Write requests. In current driver, both FFU and RPMB can be sent by using mmc_blk_ioctl_multi_cmd().
Thanks, Alex > On Apr 15, 2017, at 10:24 PM, Avri Altman <[email protected]> wrote: > > You can see how it's done in mmc_blk_ioctl_rpmb_cmd(). > > The RPMB protocol defines 6 types of accesses: > Accesses that performs read operation (read counter, read data, and read > configuration) - requires sending 2 requests. > Accesses that performs write operation (program key, write data, write > configuration) - requires sending 3 requests, > But you must do read counter beforehand (accept from program key), hence the > 5 different requests. > > The standard does not define a "special" request that does it all in once, > but expects a pre-define series of cmd18 & cmd25 for each access type, > in which the payload are 512 bytes frames in a pre-defined structure. > > Cheers, > Avri > >> -----Original Message----- >> From: Linus Walleij [mailto:[email protected]] >> Sent: Saturday, April 15, 2017 9:35 PM >> To: Avri Altman <[email protected]> >> Cc: Arnd Bergmann <[email protected]>; Ulf Hansson >> <[email protected]>; [email protected]; linux- >> [email protected]; Jens Axboe <[email protected]>; Christoph Hellwig >> <[email protected]>; Adrian Hunter <[email protected]>; Paolo Valente >> <[email protected]> >> Subject: Re: Outstanding MQ questions from MMC >> >> On Fri, Apr 14, 2017 at 8:41 PM, Avri Altman <[email protected]> >> wrote: >>> [Me] >>>> 2. Turn RPMB and other ioctl() MMC operations into mmc_queue_req >>>> things and funnel them into the block scheduler >>>> using REQ_OP_DRV_IN/OUT requests. >>>> >>> >>> Accessing the RPMB is done via a strange protocol, in which each access is >> comprised of several requests. >>> For example, writing to the RPMB will require sending 5 different requests: >>> 2 requests to read the write counter, and then 3 more requests for the >> write operation itself. >>> >>> Once the sequence has started, it should not get interfered by other >> requests, or the operation will fail. >> >> So I guess currently something takes a host lock and then performs the >> 5 requests. >> >> Thus we need to send a single custom request containing a list of 5 things to >> do, and return after that. >> >> Or do you mean that we return to userspace inbetween these different >> requests and the sequencing is done in userspace? >> >> I hope not because that sounds fragile, like userspace could crash and leave >> the host lock dangling :/ >> >> Yours, >> Linus Walleij > ��칻 �&�~�&���+-��ݶ��w��˛���m�b��f�ȧ���ܨ}���Ơz�&j:+v�������zZ+��+zf���h���~����i���z� �w���?����&�)ߢf
