Re: [PATCH v3 1/2] ASoC: SOF: amd: Move signed_fw_image to struct acp_quirk_entry

[Cristian Ciocaltea]

On 2/21/24 12:35, AngeloGioacchino Del Regno wrote:
> Il 21/02/24 11:29, Cristian Ciocaltea ha scritto:
>> On 2/21/24 11:35, AngeloGioacchino Del Regno wrote:
>>> Il 20/02/24 21:16, Cristian Ciocaltea ha scritto:
>>>> The signed_fw_image member of struct sof_amd_acp_desc is used to enable
>>>> signed firmware support in the driver via the acp_sof_quirk_table.
>>>>
>>>> In preparation to support additional use cases of the quirk table (i.e.
>>>> adding new flags), move signed_fw_image to a new struct acp_quirk_entry
>>>> and update all references to it accordingly.
>>>>

[...]

>>> are you sure that a structure holding "quirks" is the right choice here?
>>>
>>> That probably comes as a personal preference, but I would simply pass a
>>> `u32 flags`
>>> and structure the quirks as bits.
>>>
>>> #define ACP_SIGNED_FW_IMAGE    BIT(0)
>>> #define ACP_SOMETHING_ELSE    BIT(1)
>>>
>>> flags = BIT(SIGNED_FW_IMAGE) | BIT(SOMETHING_ELSE);
> 
> That should've been
>   flags = SIGNED_FW_IMAGE | SOMETHING_ELSE;
> 
>>>
>>> if (flags & BIT(SIGNED_FW_IMAGE))
> 
> and this
>    if (flags & SIGNED_FW_IMAGE)
> 
> ... I have no idea why I added a nested BIT(BIT()) in there, something in
> my brain started ticking sideways, lol.

Yeah, don't worry about that, it's perfectly clear what you initially
meant.. :-)

>>>     do_something()
>>>
>>> What do you think?
>>
>> Hi Angelo,
>>
>> The flags approach was actually my first thought and I think that would
>> have been the best choice if the quirks usage was limited to a single
>> file (acp.c).
>>
>> Since they need to be exposed externally as well (acp-loader.c,
>> vangogh.c) and already using a dedicated member in struct
>> sof_amd_acp_desc related to the existing quirk, I found the "quirks"
>> struct solution a bit more natural/convenient to follow (I've done a bit
>> of research before and noticed other drivers having similar handling).
>>
>> However, as you already pointed out, it may also come down to individual
>> preferences, so I'm open to using the flags if there is not enough
>> reasoning to stick with the current implementation.
> 
> Of course the definitions should be put in a "common header" for that to
> actually work in your described situation, but it's not a big deal.
> 
> Mine wasn't a strong opinion: that does actually matter in case you expect
> more quirks (or something that is not a quirk, but a functional flag
> instead)
> to eventually get there... but otherwise, it's actually the same.
> 
> It's your choice in the end, I'm fine with both anyway :-)

Great, thanks! :-)