[RFC v4 06/21] ath10k: sdio support
Kalle Valo
kvalo at qca.qualcomm.com
Sat Mar 11 07:04:42 PST 2017
Erik Stromdahl <erik.stromdahl at gmail.com> writes:
>> You are right, there is definitely a memory leak (and there are similar problems
>> in a couple of other functions as well as you have pointed out).
>>
>> This was introduced in version 3 of the
>> RFC when I removed the bounce buffer from ath6kl. Instead I introduced a bunch of
>> local "bounce" buffers in order to make sure that the buffers passed to the sdio
>> subsystem is dma-able (malloc'ed buffer instead of stack allocated).
>>
>> Regarding endianess: That particular code construct is an artifact from ath6kl.
>> I am not sure it makes any sense to use a u32 in that particular case.
>> A u8 array is most likely more convenient.
>>
>> It is really nice you have found some time to review the patches!
>
> After doing some reviewing myself I have found some more endianess related issues.
> I will fix those (and the memory leaks) and submit v5 some time next week.
Actually let me send v5 (for the sdio part, I'm ignoring usb for now). I
have made some small changes while looking at the patches.
--
Kalle Valo
More information about the ath10k
mailing list