From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Cristian Ciocaltea <cristian.ciocaltea@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
Subject: Re: [PATCH v3 1/2] ASoC: SOF: amd: Move signed_fw_image to struct acp_quirk_entry
Date: Wed, 21 Feb 2024 11:35:41 +0100 [thread overview]
Message-ID: <9bac55ff-0720-4ecb-9dcb-59a5397c7077@collabora.com> (raw)
In-Reply-To: <dfea1acd-8cca-4840-b1d2-1891a15c8d5a@collabora.com>
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.
>>>
>>> No functional changes intended.
>>>
>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>>> ---
>>> sound/soc/sof/amd/acp-loader.c | 2 +-
>>> sound/soc/sof/amd/acp.c | 47 ++++++++++++++++++----------------
>>> sound/soc/sof/amd/acp.h | 6 ++++-
>>> sound/soc/sof/amd/vangogh.c | 9 +++++--
>>> 4 files changed, 38 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/sound/soc/sof/amd/acp-loader.c
>>> b/sound/soc/sof/amd/acp-loader.c
>>> index d2d21478399e..aad904839b81 100644
>>> --- a/sound/soc/sof/amd/acp-loader.c
>>> +++ b/sound/soc/sof/amd/acp-loader.c
>>> @@ -173,7 +173,7 @@ int acp_dsp_pre_fw_run(struct snd_sof_dev *sdev)
>>> adata = sdev->pdata->hw_pdata;
>>> - if (adata->signed_fw_image)
>>> + if (adata->quirks && adata->quirks->signed_fw_image)
>>> size_fw = adata->fw_bin_size - ACP_FIRMWARE_SIGNATURE;
>>> else
>>> size_fw = adata->fw_bin_size;
>>> diff --git a/sound/soc/sof/amd/acp.c b/sound/soc/sof/amd/acp.c
>>> index 9b3c26210db3..9d9197fa83ed 100644
>>> --- a/sound/soc/sof/amd/acp.c
>>> +++ b/sound/soc/sof/amd/acp.c
>>> @@ -20,12 +20,14 @@
>>> #include "acp.h"
>>> #include "acp-dsp-offset.h"
>>> -#define SECURED_FIRMWARE 1
>>> -
>>> static bool enable_fw_debug;
>>> module_param(enable_fw_debug, bool, 0444);
>>> MODULE_PARM_DESC(enable_fw_debug, "Enable Firmware debug");
>>> +static struct acp_quirk_entry quirk_valve_galileo = {
>>> + .signed_fw_image = true,
>>
>> Hello Cristian,
>>
>> 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.
>> 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 :-)
Cheers,
Angelo
next prev parent reply other threads:[~2024-02-21 10:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-20 20:16 [PATCH v3 0/2] ASoC: SOF: amd: Skip IRAM/DRAM size modification for Steam Deck OLED Cristian Ciocaltea
2024-02-20 20:16 ` [PATCH v3 1/2] ASoC: SOF: amd: Move signed_fw_image to struct acp_quirk_entry Cristian Ciocaltea
2024-02-21 6:14 ` Venkata Prasad Potturu
2024-02-21 8:55 ` Cristian Ciocaltea
2024-02-21 7:28 ` Venkata Prasad Potturu
2024-02-21 9:35 ` AngeloGioacchino Del Regno
2024-02-21 10:29 ` Cristian Ciocaltea
2024-02-21 10:35 ` AngeloGioacchino Del Regno [this message]
2024-02-21 10:59 ` Cristian Ciocaltea
2024-02-20 20:16 ` [PATCH v3 2/2] ASoC: SOF: amd: Skip IRAM/DRAM size modification for Steam Deck OLED Cristian Ciocaltea
2024-03-04 19:11 ` [PATCH v3 0/2] " Cristian Ciocaltea
2024-03-04 19:12 ` Mark Brown
2024-03-15 22:04 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9bac55ff-0720-4ecb-9dcb-59a5397c7077@collabora.com \
--to=angelogioacchino.delregno@collabora.com \
--cc=broonie@kernel.org \
--cc=cristian.ciocaltea@collabora.com \
--cc=daniel.baluta@nxp.com \
--cc=kai.vehmanen@linux.intel.com \
--cc=kernel@collabora.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=peter.ujfalusi@linux.intel.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=ranjani.sridharan@linux.intel.com \
--cc=sound-open-firmware@alsa-project.org \
--cc=tiwai@suse.com \
--cc=venkataprasad.potturu@amd.com \
--cc=yung-chuan.liao@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox