[PATCH 4/9] mci: add RPMB support

[Ahmad Fatoum]

On 3/19/25 16:29, Sascha Hauer wrote:
> On Tue, Mar 18, 2025 at 12:33:05PM +0100, Sascha Hauer wrote:
>> On Mon, Mar 17, 2025 at 04:18:32PM +0100, Ahmad Fatoum wrote:
>>> Hello Sascha,
>>>
>>> On 3/12/25 13:16, Sascha Hauer wrote:
>>>> +
>>>> +int mci_rpmb_route_frames(struct mci *mci, void *req, unsigned long reqlen,
>>>> +			  void *rsp, unsigned long rsplen)
>>>> +{
>>>> +	/*
>>>> +	 * Whoever crafted the data supplied to this function knows how to
>>>> +	 * format the PRMB frames and which response is expected. If
>>>> +	 * there's some unexpected mismatch it's more helpful to report an
>>>> +	 * error immediately than trying to guess what was the intention
>>>> +	 * and possibly just delay an eventual error which will be harder
>>>> +	 * to track down.
>>>> +	 */
>>>> +	void *rpmb_data = NULL;
>>>> +	int ret;
>>>> +
>>>> +	mci_blk_part_switch(mci->rpmb_part);
>>>> +
>>>> +	if (!IS_ALIGNED((uintptr_t)req, ARCH_DMA_MINALIGN)) {
>>>
>>> Even if alignment happens to be correct, there is no guarantee that
>>> there is no other data sharing a cache line.
>>
>> reqlen is expected to be a single block of 512 bytes, so indeed when req
>> is aligned then the end is cacheline aligned as well. We could check
>> reqlen as well, but I actually never ran into this case, so we can just
>> return an error for now as you suggested.
> 
> I was wrong here. the request is placed directly behind a 6 byte struct,
> so it's guaranteed to be unaligned. We always have to copy it.
> 
> The response might be unaligned as well, but must be aligned to pass it
> to the mmc layer. In my tests the response was always aligned, but
> better safe than sorry, so I'll add an alignment check here as well,
> this time including a check for the length.



> 
> Sascha
>