From: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
To: Tom Lendacky <thomas.lendacky@amd.com>
Cc: linux-kernel@vger.kernel.org,
Brijesh Singh <brijesh.singh@amd.com>,
"Kalra, Ashish" <ashish.kalra@amd.com>,
linux-crypto@vger.kernel.org
Subject: Re: [PATCH v1 6/8] crypto: ccp - Add vdata for platform device
Date: Wed, 8 Feb 2023 13:45:10 +0100 [thread overview]
Message-ID: <3ed3234e-e811-71ef-41f9-d7999066b62d@linux.microsoft.com> (raw)
In-Reply-To: <b4b8e49c-ea5d-916c-5808-7c6aefa44dd2@amd.com>
On 06/02/2023 20:13, Tom Lendacky wrote:
> On 2/1/23 13:24, Jeremi Piotrowski wrote:
>> On Tue, Jan 31, 2023 at 02:36:01PM -0600, Tom Lendacky wrote:
>>> On 1/23/23 09:22, Jeremi Piotrowski wrote:
>>>> When matching the "psp" platform_device, determine the register offsets
>>>> at runtime from the ASP ACPI table. Pass the parsed register offsets
>>> >from the ASPT through platdata.
>>>>
>>>> To support this scenario, mark the members of 'struct sev_vdata' and
>>>> 'struct psp_vdata' non-const so that the probe function can write the
>>>> values. This does not affect the other users of sev_vdata/psp_vdata as
>>>> they define the whole struct const and the pointer in struct
>>>> sp_dev_vdata stays const too.
>>>>
>>>> Signed-off-by: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
>>>> ---
>>>> arch/x86/kernel/psp.c | 3 ++
>>>> drivers/crypto/ccp/sp-dev.h | 12 +++----
>>>> drivers/crypto/ccp/sp-platform.c | 57 +++++++++++++++++++++++++++++++-
>>>> 3 files changed, 65 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/arch/x86/kernel/psp.c b/arch/x86/kernel/psp.c
>>>> index 24181d132bae..68511a14df63 100644
>>>> --- a/arch/x86/kernel/psp.c
>>>> +++ b/arch/x86/kernel/psp.c
>>>> @@ -199,6 +199,9 @@ static int __init psp_init_platform_device(void)
>>>> if (err)
>>>> return err;
>>>> err = platform_device_add_resources(&psp_device, res, 2);
>>>> + if (err)
>>>> + return err;
>>>> + err = platform_device_add_data(&psp_device, &pdata, sizeof(pdata));
>>>> if (err)
>>>> return err;
>>>> diff --git a/drivers/crypto/ccp/sp-dev.h b/drivers/crypto/ccp/sp-dev.h
>>>> index 20377e67f65d..aaa651364425 100644
>>>> --- a/drivers/crypto/ccp/sp-dev.h
>>>> +++ b/drivers/crypto/ccp/sp-dev.h
>>>> @@ -40,9 +40,9 @@ struct ccp_vdata {
>>>> };
>>>> struct sev_vdata {
>>>> - const unsigned int cmdresp_reg;
>>>> - const unsigned int cmdbuff_addr_lo_reg;
>>>> - const unsigned int cmdbuff_addr_hi_reg;
>>>> + unsigned int cmdresp_reg;
>>>> + unsigned int cmdbuff_addr_lo_reg;
>>>> + unsigned int cmdbuff_addr_hi_reg;
>>>> };
>>>> struct tee_vdata {
>>>> @@ -56,9 +56,9 @@ struct tee_vdata {
>>>> struct psp_vdata {
>>>> const struct sev_vdata *sev;
>>>> const struct tee_vdata *tee;
>>>> - const unsigned int feature_reg;
>>>> - const unsigned int inten_reg;
>>>> - const unsigned int intsts_reg;
>>>> + unsigned int feature_reg;
>>>> + unsigned int inten_reg;
>>>> + unsigned int intsts_reg;
>>>> };
>>>> /* Structure to hold SP device data */
>>>> diff --git a/drivers/crypto/ccp/sp-platform.c b/drivers/crypto/ccp/sp-platform.c
>>>> index ea8926e87981..281dbf6b150c 100644
>>>> --- a/drivers/crypto/ccp/sp-platform.c
>>>> +++ b/drivers/crypto/ccp/sp-platform.c
>>>> @@ -22,6 +22,7 @@
>>>> #include <linux/of.h>
>>>> #include <linux/of_address.h>
>>>> #include <linux/acpi.h>
>>>> +#include <linux/platform_data/psp.h>
>>>> #include "ccp-dev.h"
>>>> @@ -30,11 +31,31 @@ struct sp_platform {
>>>> unsigned int irq_count;
>>>> };
>>>> +#ifdef CONFIG_CRYPTO_DEV_SP_PSP
>>>> +static struct sev_vdata sev_platform = {
>>>> + .cmdresp_reg = -1,
>>>> + .cmdbuff_addr_lo_reg = -1,
>>>> + .cmdbuff_addr_hi_reg = -1,
>>>> +};
>>>> +static struct psp_vdata psp_platform = {
>>>> + .sev = &sev_platform,
>>>> + .feature_reg = -1,
>>>> + .inten_reg = -1,
>>>> + .intsts_reg = -1,
>>>> +};
>>>> +#endif
>>>> +
>>>> static const struct sp_dev_vdata dev_vdata[] = {
>>>> {
>>>> .bar = 0,
>>>> #ifdef CONFIG_CRYPTO_DEV_SP_CCP
>>>> .ccp_vdata = &ccpv3_platform,
>>>> +#endif
>>>> + },
>>>> + {
>>>> + .bar = 0,
>>>> +#ifdef CONFIG_CRYPTO_DEV_SP_PSP
>>>> + .psp_vdata = &psp_platform,
>>>> #endif
>>>> },
>>>> };
>>>> @@ -57,7 +78,7 @@ MODULE_DEVICE_TABLE(of, sp_of_match);
>>>> #endif
>>>> static const struct platform_device_id sp_plat_match[] = {
>>>> - { "psp" },
>>>> + { "psp", (kernel_ulong_t)&dev_vdata[1] },
>>>> { },
>>>> };
>>>> MODULE_DEVICE_TABLE(platform, sp_plat_match);
>>>> @@ -86,6 +107,38 @@ static struct sp_dev_vdata *sp_get_acpi_version(struct platform_device *pdev)
>>>> return NULL;
>>>> }
>>>> +static struct sp_dev_vdata *sp_get_plat_version(struct platform_device *pdev)
>>>> +{
>>>> + struct sp_dev_vdata *drvdata = (struct sp_dev_vdata *)pdev->id_entry->driver_data;
>>>
>>> s/drvdata/vdata/
>>>
>>
>> ok
>>
>>>> + struct device *dev = &pdev->dev;
>>>> +
>>>
>>> Should check for null vdata and return NULL, e.g.:
>>>
>>> if (!vdata)
>>> return NULL;
>>>
>>
>> ok
>>
>>>> + if (drvdata == &dev_vdata[1]) {
>>>
>>> This should be a check for vdata->psp_vdata being non-NULL and
>>> vdata->psp_vdata->sev being non-NULL, e.g.:
>>>
>>> if (vdata->psp_vdata && vdata->psp_vdata->sev) {
>>>
>>>> + struct psp_platform_data *pdata = dev_get_platdata(dev);
>>>> +
>>>> + if (!pdata) {
>>>> + dev_err(dev, "missing platform data\n");
>>>> + return NULL;
>>>> + }
>>>> +#ifdef CONFIG_CRYPTO_DEV_SP_PSP
>>>
>>> No need for this with the above checks
>>>
>>>> + psp_platform.feature_reg = pdata->feature_reg;
>>>
>>> These should then be:
>>>
>>> vdata->psp_vdata->inten_reg = pdata->feature_reg;
>>> ...
>>
>> I see where you're going with this and the above suggestions, but
>> the psp_vdata pointer is const in struct sp_dev_vdata and so is the
>> sev pointer in struct psp_vdata. I find these consts to be important
>> and doing it this way would require casting away the const. I don't
>> think that's worth doing.
>
> Ok, then maybe it would be better to kmalloc a vdata structure that you fill in and then assign that to dev_vdata field for use. That could eliminate the removal of the "const" notations in one of the previous patches. I just don't think you should be changing the underlying module data that isn't expected to be changed.
>
I can do that and undo the removal of consts from the
struct (sev|psp)_vdata members, but the outcome would look something
like this:
static void sp_platform_fill_vdata(struct sp_dev_vdata *vdata,
struct psp_vdata *psp,
struct sev_vdata *sev,
const struct psp_platform_data *pdata)
{
struct sev_vdata sevtmp = {
.cmdbuff_addr_hi_reg = pdata->sev_cmd_buf_hi_reg,
.cmdbuff_addr_lo_reg = pdata->sev_cmd_buf_lo_reg,
.cmdresp_reg = pdata->sev_cmd_resp_reg,
};
struct psp_vdata psptmp = {
.feature_reg = pdata->feature_reg,
.inten_reg = pdata->irq_en_reg,
.intsts_reg = pdata->irq_st_reg,
.sev = sev,
};
memcpy(sev, &sevtmp, sizeof(*sev));
memcpy(psp, &psptmp, sizeof(*psp));
vdata->psp_vdata = psp;
}
static struct sp_dev_vdata *sp_get_platform_version(struct sp_device *sp)
{
struct sp_platform *sp_platform = sp->dev_specific;
struct psp_platform_data *pdata;
struct device *dev = sp->dev;
struct sp_dev_vdata *vdata;
struct psp_vdata *psp;
struct sev_vdata *sev;
pdata = dev_get_platdata(dev);
if (!pdata) {
dev_err(dev, "missing platform data\n");
return NULL;
}
sp_platform->is_platform_device = true;
vdata = devm_kzalloc(dev, sizeof(*vdata) + sizeof(*psp) + sizeof(*sev), GFP_KERNEL);
if (!vdata)
return NULL;
psp = (void *)vdata + sizeof(*vdata);
sev = (void *)psp + sizeof(*psp);
sp_platform_fill_vdata(vdata, psp, sev, pdata);
/* elided debug print */
...
return vdata;
}
with the const fields in the struct it's not possible to assign in any
other way than on initialization, so I need to use the helper function,
tmp structs and memcpy.
Could you ack that you like this approach before I post a v2?
next prev parent reply other threads:[~2023-02-08 12:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-23 15:22 [PATCH v1 0/8] Support ACPI PSP on Hyper-V Jeremi Piotrowski
2023-01-23 15:22 ` [PATCH v1 1/8] include/acpi: add definition of ASPT table Jeremi Piotrowski
2023-01-23 19:56 ` Rafael J. Wysocki
2023-01-24 16:05 ` Jeremi Piotrowski
2023-01-23 15:22 ` [PATCH v1 2/8] ACPI: ASPT: Add helper to parse table Jeremi Piotrowski
2023-01-23 15:22 ` [PATCH v1 3/8] x86/psp: Register PSP platform device when ASP table is present Jeremi Piotrowski
2023-01-31 18:49 ` Tom Lendacky
2023-02-01 14:09 ` Jeremi Piotrowski
2023-02-01 14:57 ` Tom Lendacky
2023-01-23 15:22 ` [PATCH v1 4/8] x86/psp: Add IRQ support Jeremi Piotrowski
2023-01-31 19:45 ` Tom Lendacky
2023-01-23 15:22 ` [PATCH v1 5/8] crypto: cpp - Bind to psp platform device on x86 Jeremi Piotrowski
2023-01-31 19:51 ` Tom Lendacky
2023-02-08 12:48 ` Jeremi Piotrowski
2023-01-23 15:22 ` [PATCH v1 6/8] crypto: ccp - Add vdata for platform device Jeremi Piotrowski
2023-01-31 20:36 ` Tom Lendacky
2023-02-01 19:24 ` Jeremi Piotrowski
2023-02-06 19:13 ` Tom Lendacky
2023-02-08 12:45 ` Jeremi Piotrowski [this message]
2023-02-08 17:23 ` Tom Lendacky
2023-01-23 15:22 ` [PATCH v1 7/8] crypto: ccp - Skip DMA coherency check for platform psp Jeremi Piotrowski
2023-01-31 20:42 ` Tom Lendacky
2023-02-08 12:56 ` Jeremi Piotrowski
2023-01-23 15:22 ` [PATCH v1 8/8] crypto: ccp - Allow platform device to be psp master device Jeremi Piotrowski
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=3ed3234e-e811-71ef-41f9-d7999066b62d@linux.microsoft.com \
--to=jpiotrowski@linux.microsoft.com \
--cc=ashish.kalra@amd.com \
--cc=brijesh.singh@amd.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=thomas.lendacky@amd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.