[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d86181b5-bf73-13e3-08f7-6cab43cb3398@amd.com>
Date: Thu, 16 Feb 2023 08:23:02 -0600
From: Tom Lendacky <thomas.lendacky@....com>
To: "Limonciello, Mario" <Mario.Limonciello@....com>,
Jan Dąbroś <jsd@...ihalf.com>
Cc: Grzegorz Bernacki <gjb@...ihalf.com>,
"Thomas, Rijo-john" <Rijo-john.Thomas@....com>,
"herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
"Allen, John" <John.Allen@....com>,
"Singh, Brijesh" <Brijesh.Singh@....com>,
Jarkko Nikula <jarkko.nikula@...ux.intel.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH 3/6] crypto: ccp: Move some PSP mailbox bit definitions
into common header
On 2/14/23 16:05, Limonciello, Mario wrote:
> [Public]
>
>
>
>> -----Original Message-----
>> From: Jan Dąbroś <jsd@...ihalf.com>
>> Sent: Tuesday, February 14, 2023 03:04
>> To: Limonciello, Mario <Mario.Limonciello@....com>
>> Cc: Grzegorz Bernacki <gjb@...ihalf.com>; Thomas, Rijo-john <Rijo-
>> john.Thomas@....com>; Lendacky, Thomas
>> <Thomas.Lendacky@....com>; herbert@...dor.apana.org.au; Allen, John
>> <John.Allen@....com>; Singh, Brijesh <Brijesh.Singh@....com>; Jarkko
>> Nikula <jarkko.nikula@...ux.intel.com>; Andy Shevchenko
>> <andriy.shevchenko@...ux.intel.com>; Mika Westerberg
>> <mika.westerberg@...ux.intel.com>; linux-i2c@...r.kernel.org; linux-
>> crypto@...r.kernel.org; linux-kernel@...r.kernel.org; David S. Miller
>> <davem@...emloft.net>
>> Subject: Re: [PATCH 3/6] crypto: ccp: Move some PSP mailbox bit definitions
>> into common header
>>
>> (...)
>>> @@ -99,7 +93,7 @@ static int psp_check_mbox_recovery(struct psp_mbox
>> __iomem *mbox)
>>>
>>> tmp = readl(&mbox->cmd_fields);
>>>
>>> - return FIELD_GET(PSP_MBOX_FIELDS_RECOVERY, tmp);
>>> + return FIELD_GET(PSP_CMDRESP_RECOVERY, tmp);
>>> }
>>>
>>> static int psp_wait_cmd(struct psp_mbox __iomem *mbox)
>>> @@ -107,7 +101,7 @@ static int psp_wait_cmd(struct psp_mbox __iomem
>> *mbox)
>>> u32 tmp, expected;
>>>
>>> /* Expect mbox_cmd to be cleared and ready bit to be set by PSP */
>>> - expected = FIELD_PREP(PSP_MBOX_FIELDS_READY, 1);
>>> + expected = FIELD_PREP(PSP_CMDRESP_RESP, 1);
>>
>> What's the meaning of "PSP_CMDRESP_RESP"? I see that this new macro
>> name is currently used by other drivers, but in my opinion "READY" is
>> more descriptive. (It is also aligned to the comment above this line.)
>
> It should indicate that the PSP has responded. I think both terms work
> to describe what's going on.
>
> Tom - What's your preference?
> I'll either adjust all the drivers to use READY or fix the comment for v2.
I think the comment should be changed.
Thanks,
Tom
Powered by blists - more mailing lists