Received-SPF: pass (google.com: domain of linux-kernel+bounces-74579-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <cd3fe134-1df6-4a6a-96f5-1ab91c7bf5a8@collabora.com>
Date: Wed, 21 Feb 2024 12:59:53 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 1/2] ASoC: SOF: amd: Move signed_fw_image to struct
 acp_quirk_entry
Content-Language: en-US
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>,
 Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
 Liam Girdwood <lgirdwood@gmail.com>,
 Peter Ujfalusi <peter.ujfalusi@linux.intel.com>,
 Bard Liao <yung-chuan.liao@linux.intel.com>,
 Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
 Daniel Baluta <daniel.baluta@nxp.com>,
 Kai Vehmanen <kai.vehmanen@linux.intel.com>, Mark Brown
 <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
 Takashi Iwai <tiwai@suse.com>,
 Venkata Prasad Potturu <venkataprasad.potturu@amd.com>
Cc: sound-open-firmware@alsa-project.org, linux-sound@vger.kernel.org,
 linux-kernel@vger.kernel.org, kernel@collabora.com
References: <20240220201623.438944-1-cristian.ciocaltea@collabora.com>
 <20240220201623.438944-2-cristian.ciocaltea@collabora.com>
 <54c35628-9897-4415-86c0-cf81c897840e@collabora.com>
 <dfea1acd-8cca-4840-b1d2-1891a15c8d5a@collabora.com>
 <9bac55ff-0720-4ecb-9dcb-59a5397c7077@collabora.com>
From: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
In-Reply-To: <9bac55ff-0720-4ecb-9dcb-59a5397c7077@collabora.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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