> > Hi Avri, > > thanks for your comments! > > > > For RPMB, block count is a non-zero 16 bit wide number. Reject invalid > > Actually this is not what limits the number of rpmb frames to be read, > > As those are not indicated in the block_count field of the rpmb frame, > > But in CMD23. > > While it is true that by eMMCv52 RPMB_SIZE_MULT max value is 0x80, > > Which limits the RPMB are to 16M, or 65535 rpmb frames, > > I don't think that it is up to the host to validate the rpmb frame content - > > I wanted to fix the following issue: > > Currently, in to-be-removed mmc_set_blockcount() we have: > > cmd.arg = blockcount & 0x0000FFFF; > > So, sending a IOCTL with a value of 65537 will silently(!) produce a > block count of 1. I didn't like this. > > I don't have the eMMC specs on this computer but I recall it is defined > somewhere that there are 2 bytes reserved for it in the packet frame? Yes. But strangely as it may sound, this u16 in the rpmb frame should be set to 0x0 in all cases except for data write in which it may carry 1, 2, or 32. The block count for all other operations is set by CMD23. This might explain why the community people hate JEDEC guys so much. I agree - the blockcount in mmc_set_blockcount carries not the frame Content, but the mmc_ioc_cmd blocks field, which is unsigned int. So this line in mmc_set_blockcount performs an unnecessary input validation. > > But yes, standards may be extended, so I am not opposed to fill in > bigger numbers than 16 bit and let the card handle the error. > > So you suggest dropping this patch and keep the others, did I get this > right? Would be fine with me. Yes. Thanks. Cheers, Avri > > Regards, > > Wolfram
