> > cc a couple more people > > On 21/04/16 16:28, Adrian Hunter wrote: > > Hi > > > > The RPMB partition only allows certain commands. In particular, the > > tuning command (CMD21) is not allowed - refer JEDEC eMMC standard > > v5.1 section 6.2.2 Command restrictions. > > > > That means commands will begin failing if re-tuning is needed while > > switched to the RPMB partition. > > > > Here are 4 options to fix the problem: > > > > > > 1. The approach taken by this patch set: > > > > To avoid tuning for RPMB, switch to High Speed mode from HS200 or > > HS400 mode if re-tuning has been enabled. And switch back when > > leaving RPMB. > > > > Advantages: Directly does what needs to be done. > > > > Disadvantages: Assumes the mode switching will work. > > > > > > 2. Same as 1 but disable the tuning modes by removing them from > > card->mmc_avail_type and doing a full mmc_reset(). > > > > Advantages: Simpler to program > > > > Disadvantages: Doing a full reset is slower. Doing a full reset is > > not an expected consequence of accessing RPMB. > > > > > > 3. Simply disable re-tuning and attempt to recover from any errors. > > > > Disadvantages: Due to the interdependent nature of RPMB reads/writes > > it might not be possible to recover without returning an error to the > > RPMB user. Also it would be difficult to test if the recovery > > actually worked in all cases. > > > > > > 4. Do a partiton switch as part of re-tuning. > > > > Disadvantages: Makes re-tuning more complicated. Would require moving > > the control of partition switching into the core. CRC errors arising > > from the need to re-tune might break the interdependent nature of RPMB > > operations. > > > > > > As a final note, if a solution is found then we might be able to > > revert commit 4e93b9a6abc0 ("mmc: card: Don't access RPMB partitions > > for normal read/write"). > > This still doesn't bring us to that point, mostly for writing as each transaction has to have a valid MAC computed. There is another layer required I hope matching the RPMB sybsystem as we suggested. I would prefer it won't be attached to block layer as is, yet we already have legacy SW stack so I see it painfull. Thanks Tomas -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html