sof-ctl: Allow setting arbitrary size for controls

[lkoenig]

sof-ctl assumed the binary control were of size of a
multiple of unsigned integer.
This caused the control byte array to be truncated when the
size of the control was 6 bytes.
This change allow setting any size of control in binary form.
Using CSV will always end up with a number of unsigned integer size.

I tested this change using the Google RTC Audio processing with control size of
6 bytes, 2 bytes and 4 bytes.

Signed-off-by: Lionel Koenig lionelk@google.com

[lgirdwood]

@lkoenig I assume no impact for userspace clients or FW ABI that may use this command ?

[lkoenig]

FW ABI is unchanged.
Userspace command line is unchanged. I do not understand what you meant by userspace clients ?
What changed is that if someone call sof-ctl to set a binary control, the binary file will be read as is (all the bytes) and passed as is to the control via the ALSA interface.

Prior this change sof-ctl read those binary files in unsigned int assuming the size of the binary file would be a multiple of 4 bytes. When I tried to set a 2 bytes control it got rounded to 0 bytes control.
The firmware already supports no multiple of 4 bytes control as the ABI header specify the size of the data in bytes.
Hopefully I am clear in my explaination.

[cujomalainey]

just thinking for the arm folk, if this is running on arm 32-bit, isn't an unsigned int 16bits? Shouldnt this be uint32_t?

[lgirdwood]

@dbaluta @paulstelian97 @afq984 @kuanhsuncheng any comments here for ARM32 ?

[afq984]

if this is running on arm 32-bit, isn't an unsigned int 16bits?

I believe it depends on the toolchain (edit: or ABI?), but it's 4 on clang 11 and gcc 11: https://godbolt.org/z/bo8r5as1b

The comment use unsigned int to ensure alignment sounds a bit confusing to me. It doesn't ensure a misaligned pointer can't be stored into the buffer such as buffer = (unsigned int*)(uintptr_t)3.
Does it mean access to the buffer must be have an address of a multiple of 4?

[paulstelian97]

@lgirdwood I have no idea about 32-bit ARM issues since all the variants of i.MX8 are 64-bit.

[lgirdwood]

Using the uint32_t and friends here would guarantee compliance no matter the underlying architecture. @lkoenig is this something you can update ?

[cujomalainey]

Agreed, I think we should in general be defaulting to inttypes

[lkoenig]

I did some update there.

[lgirdwood]

Thanks @lkoenig - this should be fine for 32bit users.