linux-kernel - Re: [PATCH v3 1/2] ASoC: SOF: amd: Move signed_fw_image to struct acp_quirk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cd3fe134-1df6-4a6a-96f5-1ab91c7bf5a8@collabora.com>
Date: Wed, 21 Feb 2024 12:59:53 +0200
From: Cristian Ciocaltea <cristian.ciocaltea@...labora.com>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
 Liam Girdwood <lgirdwood@...il.com>,
 Peter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
 Bard Liao <yung-chuan.liao@...ux.intel.com>,
 Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
 Daniel Baluta <daniel.baluta@....com>,
 Kai Vehmanen <kai.vehmanen@...ux.intel.com>, Mark Brown
 <broonie@...nel.org>, Jaroslav Kysela <perex@...ex.cz>,
 Takashi Iwai <tiwai@...e.com>,
 Venkata Prasad Potturu <venkataprasad.potturu@....com>
Cc: sound-open-firmware@...a-project.org, linux-sound@...r.kernel.org,
 linux-kernel@...r.kernel.org, kernel@...labora.com
Subject: Re: [PATCH v3 1/2] ASoC: SOF: amd: Move signed_fw_image to struct
 acp_quirk_entry

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! :-)