On 3/19/25 16:34, Ahmad Fatoum wrote:
>
>
> 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.
Sorry about the empty mail. Can we have a generic helper for this?
Maybe dma_map_buf_is_aligned or something like that, preferably with a
device argument from the outset.
Cheers,
Ahmad
>
>
>
>>
>> Sascha
>>
>
