[PATCH v5 0/7] staging: vchiq_core: Refactor vchiq_bulk_transfer() logic
Umang Jain
umang.jain at ideasonboard.com
Mon Sep 9 22:04:39 PDT 2024
On 09/09/24 11:38 pm, Stefan Wahren wrote:
> Am 09.09.24 um 08:14 schrieb Umang Jain:
>> Series mostly refactors vchiq_bulk_transfer() code according
>> to Arnd's review comment from [1]:
>>
>>> You can also wrap vchiq_bulk_transfer() in order to have
>>> four separate functions based on the different 'mode'
>>> values and have them only take the arguments they actually
>>> need.
>> I didn't wrap vchiq_bulk_transfer(), instead created four
>> differnet function, one for each mode.
>> This will pave the way to address his second comment:
>>
>>> Ideally this should be cleaned up in a way that completely
>>> avoids passing both user and kernel data at the same time.
>> which is not part of this series and will be done on top as
>> arguments shuffling will have to fix the sparse warnings
>> that exists currently.
>>
>> Patch 1/7 first moves the VCHIQ_BULK_MODE_WAITING logic out
>> of vchiq_bulk_transfer
>>
>> Patch 2/7 then moves the core logic to vchiq_bulk_transfer()
>> which can be shared in subsequent patches
>>
>> Patch 3/7 and 4/7 refactors remaining bulk transfer modes
>>
>> Patch 5/7 finally drops the vchiq_bulk_transfer() as not needed
>>
>> patch 6/7 and 7/7 are drive by patches, noticed during development.
>>
>> [1]:
>> https://lore.kernel.org/linux-staging/3d3b7368-93b2-4c0d-845e-4099c2de9dc1@app.fastmail.com/
>>
>> changes in v5:
>> - Fix regression for VCHIQ_BULK_MODE_BLOCKING in 3/7
>> (Fixes strange hang from v4 with 'vchiq_test -p')
>
> The whole series is
>
> Tested-by: Stefan Wahren <wahrenst at gmx.net>
Thanks for testing and especially catching the strange hang!
The 2/7 review comment will be addressed in v6 (shortly)
More information about the linux-rpi-kernel
mailing list