Thread (11 messages) 11 messages, 2 authors, 2024-09-10

Re: [PATCH v5 0/7] staging: vchiq_core: Refactor vchiq_bulk_transfer() logic

From: Stefan Wahren <wahrenst@gmx.net>
Date: 2024-09-09 18:09:43
Also in: linux-staging

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]:
quoted
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:
quoted
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/ (local)

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@gmx.net>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help