* [PATCH 1/6] crypto: ccp: Drop TEE support for IRQ handler
2023-02-09 22:38 [PATCH 0/6] Export platform features from ccp driver Mario Limonciello
@ 2023-02-09 22:38 ` Mario Limonciello
2023-02-09 22:38 ` [PATCH 2/6] crypto: ccp: Add a header for multiple drivers to use `__psp_pa` Mario Limonciello
` (4 subsequent siblings)
5 siblings, 0 replies; 24+ messages in thread
From: Mario Limonciello @ 2023-02-09 22:38 UTC (permalink / raw)
To: Jan Dąbroś,
Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Tom Lendacky, John Allen
Cc: andriy.shevchenko, linux-i2c, linux-crypto, linux-kernel,
Mario Limonciello, David S. Miller
The only PSP mailbox that currently supports interrupt on completion
is the SEV mailbox. Drop the dead code for the TEE subdriver to
potentially call it.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
drivers/crypto/ccp/psp-dev.c | 15 ---------------
drivers/crypto/ccp/psp-dev.h | 7 -------
2 files changed, 22 deletions(-)
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index c9c741ac84421..cd8d1974726a8 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -46,9 +46,6 @@ static irqreturn_t psp_irq_handler(int irq, void *data)
if (status) {
if (psp->sev_irq_handler)
psp->sev_irq_handler(irq, psp->sev_irq_data, status);
-
- if (psp->tee_irq_handler)
- psp->tee_irq_handler(irq, psp->tee_irq_data, status);
}
/* Clear the interrupt status by writing the same value we read. */
@@ -219,18 +216,6 @@ void psp_clear_sev_irq_handler(struct psp_device *psp)
psp_set_sev_irq_handler(psp, NULL, NULL);
}
-void psp_set_tee_irq_handler(struct psp_device *psp, psp_irq_handler_t handler,
- void *data)
-{
- psp->tee_irq_data = data;
- psp->tee_irq_handler = handler;
-}
-
-void psp_clear_tee_irq_handler(struct psp_device *psp)
-{
- psp_set_tee_irq_handler(psp, NULL, NULL);
-}
-
struct psp_device *psp_get_master_device(void)
{
struct sp_device *sp = sp_get_psp_master_device();
diff --git a/drivers/crypto/ccp/psp-dev.h b/drivers/crypto/ccp/psp-dev.h
index d528eb04c3ef6..06e1f317216d2 100644
--- a/drivers/crypto/ccp/psp-dev.h
+++ b/drivers/crypto/ccp/psp-dev.h
@@ -40,9 +40,6 @@ struct psp_device {
psp_irq_handler_t sev_irq_handler;
void *sev_irq_data;
- psp_irq_handler_t tee_irq_handler;
- void *tee_irq_data;
-
void *sev_data;
void *tee_data;
@@ -53,10 +50,6 @@ void psp_set_sev_irq_handler(struct psp_device *psp, psp_irq_handler_t handler,
void *data);
void psp_clear_sev_irq_handler(struct psp_device *psp);
-void psp_set_tee_irq_handler(struct psp_device *psp, psp_irq_handler_t handler,
- void *data);
-void psp_clear_tee_irq_handler(struct psp_device *psp);
-
struct psp_device *psp_get_master_device(void);
#define PSP_CAPABILITY_SEV BIT(0)
--
2.34.1
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH 2/6] crypto: ccp: Add a header for multiple drivers to use `__psp_pa`
2023-02-09 22:38 [PATCH 0/6] Export platform features from ccp driver Mario Limonciello
2023-02-09 22:38 ` [PATCH 1/6] crypto: ccp: Drop TEE support for IRQ handler Mario Limonciello
@ 2023-02-09 22:38 ` Mario Limonciello
2023-02-14 8:40 ` Jan Dąbroś
2023-02-15 11:13 ` Sumit Garg
2023-02-09 22:38 ` [PATCH 3/6] crypto: ccp: Move some PSP mailbox bit definitions into common header Mario Limonciello
` (3 subsequent siblings)
5 siblings, 2 replies; 24+ messages in thread
From: Mario Limonciello @ 2023-02-09 22:38 UTC (permalink / raw)
To: Jan Dąbroś,
Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Sean Christopherson, Paolo Bonzini, Brijesh Singh, Tom Lendacky,
John Allen, Jarkko Nikula, Andy Shevchenko, Mika Westerberg
Cc: linux-i2c, linux-crypto, linux-kernel, Mario Limonciello,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, David S. Miller, Jens Wiklander, Sumit Garg, kvm,
op-tee
The TEE subdriver for CCP, the amdtee driver and the i2c-designware-amdpsp
drivers all include `psp-sev.h` even though they don't use SEV
functionality.
Move the definition of `__psp_pa` into a common header to be included
by all of these drivers.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
arch/x86/kvm/svm/sev.c | 1 +
drivers/crypto/ccp/sev-dev.c | 1 +
drivers/crypto/ccp/tee-dev.c | 2 +-
drivers/i2c/busses/i2c-designware-amdpsp.c | 2 +-
drivers/tee/amdtee/call.c | 2 +-
drivers/tee/amdtee/shm_pool.c | 2 +-
include/linux/psp-sev.h | 8 --------
include/linux/psp.h | 14 ++++++++++++++
8 files changed, 20 insertions(+), 12 deletions(-)
create mode 100644 include/linux/psp.h
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 86d6897f48068..ee8e9053f4468 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -11,6 +11,7 @@
#include <linux/kvm_host.h>
#include <linux/kernel.h>
#include <linux/highmem.h>
+#include <linux/psp.h>
#include <linux/psp-sev.h>
#include <linux/pagemap.h>
#include <linux/swap.h>
diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
index e2f25926eb514..28945ca7c8563 100644
--- a/drivers/crypto/ccp/sev-dev.c
+++ b/drivers/crypto/ccp/sev-dev.c
@@ -24,6 +24,7 @@
#include <linux/cpufeature.h>
#include <linux/fs.h>
#include <linux/fs_struct.h>
+#include <linux/psp.h>
#include <asm/smp.h>
#include <asm/cacheflush.h>
diff --git a/drivers/crypto/ccp/tee-dev.c b/drivers/crypto/ccp/tee-dev.c
index 5c9d47f3be375..f24fc953718a0 100644
--- a/drivers/crypto/ccp/tee-dev.c
+++ b/drivers/crypto/ccp/tee-dev.c
@@ -13,7 +13,7 @@
#include <linux/delay.h>
#include <linux/slab.h>
#include <linux/gfp.h>
-#include <linux/psp-sev.h>
+#include <linux/psp.h>
#include <linux/psp-tee.h>
#include "psp-dev.h"
diff --git a/drivers/i2c/busses/i2c-designware-amdpsp.c b/drivers/i2c/busses/i2c-designware-amdpsp.c
index 8f36167bce624..80f28a1bbbef6 100644
--- a/drivers/i2c/busses/i2c-designware-amdpsp.c
+++ b/drivers/i2c/busses/i2c-designware-amdpsp.c
@@ -4,7 +4,7 @@
#include <linux/bits.h>
#include <linux/i2c.h>
#include <linux/io-64-nonatomic-lo-hi.h>
-#include <linux/psp-sev.h>
+#include <linux/psp.h>
#include <linux/types.h>
#include <linux/workqueue.h>
diff --git a/drivers/tee/amdtee/call.c b/drivers/tee/amdtee/call.c
index cec6e70f0ac92..e8cd9aaa34675 100644
--- a/drivers/tee/amdtee/call.c
+++ b/drivers/tee/amdtee/call.c
@@ -8,7 +8,7 @@
#include <linux/tee_drv.h>
#include <linux/psp-tee.h>
#include <linux/slab.h>
-#include <linux/psp-sev.h>
+#include <linux/psp.h>
#include "amdtee_if.h"
#include "amdtee_private.h"
diff --git a/drivers/tee/amdtee/shm_pool.c b/drivers/tee/amdtee/shm_pool.c
index f87f96a291c99..f0303126f199d 100644
--- a/drivers/tee/amdtee/shm_pool.c
+++ b/drivers/tee/amdtee/shm_pool.c
@@ -5,7 +5,7 @@
#include <linux/slab.h>
#include <linux/tee_drv.h>
-#include <linux/psp-sev.h>
+#include <linux/psp.h>
#include "amdtee_private.h"
static int pool_op_alloc(struct tee_shm_pool *pool, struct tee_shm *shm,
diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
index 1595088c428b4..7fd17e82bab43 100644
--- a/include/linux/psp-sev.h
+++ b/include/linux/psp-sev.h
@@ -14,14 +14,6 @@
#include <uapi/linux/psp-sev.h>
-#ifdef CONFIG_X86
-#include <linux/mem_encrypt.h>
-
-#define __psp_pa(x) __sme_pa(x)
-#else
-#define __psp_pa(x) __pa(x)
-#endif
-
#define SEV_FW_BLOB_MAX_SIZE 0x4000 /* 16KB */
/**
diff --git a/include/linux/psp.h b/include/linux/psp.h
new file mode 100644
index 0000000000000..202162487ec3b
--- /dev/null
+++ b/include/linux/psp.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __PSP_H
+#define __PSP_H
+
+#ifdef CONFIG_X86
+#include <linux/mem_encrypt.h>
+
+#define __psp_pa(x) __sme_pa(x)
+#else
+#define __psp_pa(x) __pa(x)
+#endif
+
+#endif /* __PSP_H */
--
2.34.1
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH 2/6] crypto: ccp: Add a header for multiple drivers to use `__psp_pa`
2023-02-09 22:38 ` [PATCH 2/6] crypto: ccp: Add a header for multiple drivers to use `__psp_pa` Mario Limonciello
@ 2023-02-14 8:40 ` Jan Dąbroś
2023-02-15 11:13 ` Jarkko Nikula
2023-02-15 11:13 ` Sumit Garg
1 sibling, 1 reply; 24+ messages in thread
From: Jan Dąbroś @ 2023-02-14 8:40 UTC (permalink / raw)
To: Mario Limonciello
Cc: Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Sean Christopherson, Paolo Bonzini, Brijesh Singh, John Allen,
Jarkko Nikula, Andy Shevchenko, Mika Westerberg, linux-i2c,
linux-crypto, linux-kernel, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
David S. Miller, Jens Wiklander, Sumit Garg, kvm, op-tee
> The TEE subdriver for CCP, the amdtee driver and the i2c-designware-amdpsp
> drivers all include `psp-sev.h` even though they don't use SEV
> functionality.
>
> Move the definition of `__psp_pa` into a common header to be included
> by all of these drivers.
>
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Jan Dabros <jsd@semihalf.com>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/6] crypto: ccp: Add a header for multiple drivers to use `__psp_pa`
2023-02-14 8:40 ` Jan Dąbroś
@ 2023-02-15 11:13 ` Jarkko Nikula
0 siblings, 0 replies; 24+ messages in thread
From: Jarkko Nikula @ 2023-02-15 11:13 UTC (permalink / raw)
To: Jan Dąbroś, Mario Limonciello
Cc: Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Sean Christopherson, Paolo Bonzini, Brijesh Singh, John Allen,
Andy Shevchenko, Mika Westerberg, linux-i2c, linux-crypto,
linux-kernel, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, David S. Miller,
Jens Wiklander, Sumit Garg, kvm, op-tee
On 2/14/23 10:40, Jan Dąbroś wrote:
>> The TEE subdriver for CCP, the amdtee driver and the i2c-designware-amdpsp
>> drivers all include `psp-sev.h` even though they don't use SEV
>> functionality.
>>
>> Move the definition of `__psp_pa` into a common header to be included
>> by all of these drivers.
>>
>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>
> Reviewed-by: Jan Dabros <jsd@semihalf.com>
For the drivers/i2c/busses/i2c-designware-amdpsp.c:
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/6] crypto: ccp: Add a header for multiple drivers to use `__psp_pa`
2023-02-09 22:38 ` [PATCH 2/6] crypto: ccp: Add a header for multiple drivers to use `__psp_pa` Mario Limonciello
2023-02-14 8:40 ` Jan Dąbroś
@ 2023-02-15 11:13 ` Sumit Garg
1 sibling, 0 replies; 24+ messages in thread
From: Sumit Garg @ 2023-02-15 11:13 UTC (permalink / raw)
To: Mario Limonciello
Cc: Jan Dąbroś,
Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Sean Christopherson, Paolo Bonzini, Brijesh Singh, John Allen,
Jarkko Nikula, Andy Shevchenko, Mika Westerberg, linux-i2c,
linux-crypto, linux-kernel, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
David S. Miller, Jens Wiklander, kvm, op-tee
On Fri, 10 Feb 2023 at 04:08, Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
> The TEE subdriver for CCP, the amdtee driver and the i2c-designware-amdpsp
> drivers all include `psp-sev.h` even though they don't use SEV
> functionality.
>
> Move the definition of `__psp_pa` into a common header to be included
> by all of these drivers.
>
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
> arch/x86/kvm/svm/sev.c | 1 +
> drivers/crypto/ccp/sev-dev.c | 1 +
> drivers/crypto/ccp/tee-dev.c | 2 +-
> drivers/i2c/busses/i2c-designware-amdpsp.c | 2 +-
> drivers/tee/amdtee/call.c | 2 +-
> drivers/tee/amdtee/shm_pool.c | 2 +-
For TEE subsystem bits:
Acked-by: Sumit Garg <sumit.garg@linaro.org>
-Sumit
> include/linux/psp-sev.h | 8 --------
> include/linux/psp.h | 14 ++++++++++++++
> 8 files changed, 20 insertions(+), 12 deletions(-)
> create mode 100644 include/linux/psp.h
>
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 86d6897f48068..ee8e9053f4468 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -11,6 +11,7 @@
> #include <linux/kvm_host.h>
> #include <linux/kernel.h>
> #include <linux/highmem.h>
> +#include <linux/psp.h>
> #include <linux/psp-sev.h>
> #include <linux/pagemap.h>
> #include <linux/swap.h>
> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
> index e2f25926eb514..28945ca7c8563 100644
> --- a/drivers/crypto/ccp/sev-dev.c
> +++ b/drivers/crypto/ccp/sev-dev.c
> @@ -24,6 +24,7 @@
> #include <linux/cpufeature.h>
> #include <linux/fs.h>
> #include <linux/fs_struct.h>
> +#include <linux/psp.h>
>
> #include <asm/smp.h>
> #include <asm/cacheflush.h>
> diff --git a/drivers/crypto/ccp/tee-dev.c b/drivers/crypto/ccp/tee-dev.c
> index 5c9d47f3be375..f24fc953718a0 100644
> --- a/drivers/crypto/ccp/tee-dev.c
> +++ b/drivers/crypto/ccp/tee-dev.c
> @@ -13,7 +13,7 @@
> #include <linux/delay.h>
> #include <linux/slab.h>
> #include <linux/gfp.h>
> -#include <linux/psp-sev.h>
> +#include <linux/psp.h>
> #include <linux/psp-tee.h>
>
> #include "psp-dev.h"
> diff --git a/drivers/i2c/busses/i2c-designware-amdpsp.c b/drivers/i2c/busses/i2c-designware-amdpsp.c
> index 8f36167bce624..80f28a1bbbef6 100644
> --- a/drivers/i2c/busses/i2c-designware-amdpsp.c
> +++ b/drivers/i2c/busses/i2c-designware-amdpsp.c
> @@ -4,7 +4,7 @@
> #include <linux/bits.h>
> #include <linux/i2c.h>
> #include <linux/io-64-nonatomic-lo-hi.h>
> -#include <linux/psp-sev.h>
> +#include <linux/psp.h>
> #include <linux/types.h>
> #include <linux/workqueue.h>
>
> diff --git a/drivers/tee/amdtee/call.c b/drivers/tee/amdtee/call.c
> index cec6e70f0ac92..e8cd9aaa34675 100644
> --- a/drivers/tee/amdtee/call.c
> +++ b/drivers/tee/amdtee/call.c
> @@ -8,7 +8,7 @@
> #include <linux/tee_drv.h>
> #include <linux/psp-tee.h>
> #include <linux/slab.h>
> -#include <linux/psp-sev.h>
> +#include <linux/psp.h>
> #include "amdtee_if.h"
> #include "amdtee_private.h"
>
> diff --git a/drivers/tee/amdtee/shm_pool.c b/drivers/tee/amdtee/shm_pool.c
> index f87f96a291c99..f0303126f199d 100644
> --- a/drivers/tee/amdtee/shm_pool.c
> +++ b/drivers/tee/amdtee/shm_pool.c
> @@ -5,7 +5,7 @@
>
> #include <linux/slab.h>
> #include <linux/tee_drv.h>
> -#include <linux/psp-sev.h>
> +#include <linux/psp.h>
> #include "amdtee_private.h"
>
> static int pool_op_alloc(struct tee_shm_pool *pool, struct tee_shm *shm,
> diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
> index 1595088c428b4..7fd17e82bab43 100644
> --- a/include/linux/psp-sev.h
> +++ b/include/linux/psp-sev.h
> @@ -14,14 +14,6 @@
>
> #include <uapi/linux/psp-sev.h>
>
> -#ifdef CONFIG_X86
> -#include <linux/mem_encrypt.h>
> -
> -#define __psp_pa(x) __sme_pa(x)
> -#else
> -#define __psp_pa(x) __pa(x)
> -#endif
> -
> #define SEV_FW_BLOB_MAX_SIZE 0x4000 /* 16KB */
>
> /**
> diff --git a/include/linux/psp.h b/include/linux/psp.h
> new file mode 100644
> index 0000000000000..202162487ec3b
> --- /dev/null
> +++ b/include/linux/psp.h
> @@ -0,0 +1,14 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef __PSP_H
> +#define __PSP_H
> +
> +#ifdef CONFIG_X86
> +#include <linux/mem_encrypt.h>
> +
> +#define __psp_pa(x) __sme_pa(x)
> +#else
> +#define __psp_pa(x) __pa(x)
> +#endif
> +
> +#endif /* __PSP_H */
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 3/6] crypto: ccp: Move some PSP mailbox bit definitions into common header
2023-02-09 22:38 [PATCH 0/6] Export platform features from ccp driver Mario Limonciello
2023-02-09 22:38 ` [PATCH 1/6] crypto: ccp: Drop TEE support for IRQ handler Mario Limonciello
2023-02-09 22:38 ` [PATCH 2/6] crypto: ccp: Add a header for multiple drivers to use `__psp_pa` Mario Limonciello
@ 2023-02-09 22:38 ` Mario Limonciello
2023-02-14 9:04 ` Jan Dąbroś
2023-02-09 22:38 ` [PATCH 4/6] crypto: ccp: Add support for an interface for platform features Mario Limonciello
` (2 subsequent siblings)
5 siblings, 1 reply; 24+ messages in thread
From: Mario Limonciello @ 2023-02-09 22:38 UTC (permalink / raw)
To: Jan Dąbroś,
Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Tom Lendacky, John Allen, Brijesh Singh, Jarkko Nikula,
Andy Shevchenko, Mika Westerberg
Cc: linux-i2c, linux-crypto, linux-kernel, Mario Limonciello,
David S. Miller
Some of the bits and fields used for mailboxes communicating with the
PSP are common across all mailbox implementations (SEV, TEE, etc).
Move these bits into the common `linux/psp.h` so they don't need to
be re-defined for each implementation.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
drivers/crypto/ccp/psp-dev.h | 3 ---
drivers/crypto/ccp/sev-dev.c | 15 +++++++--------
drivers/crypto/ccp/sev-dev.h | 2 +-
drivers/crypto/ccp/tee-dev.c | 15 ++++++++-------
drivers/i2c/busses/i2c-designware-amdpsp.c | 14 ++++----------
include/linux/psp.h | 12 ++++++++++++
6 files changed, 32 insertions(+), 29 deletions(-)
diff --git a/drivers/crypto/ccp/psp-dev.h b/drivers/crypto/ccp/psp-dev.h
index 06e1f317216d2..55f54bb2b3fba 100644
--- a/drivers/crypto/ccp/psp-dev.h
+++ b/drivers/crypto/ccp/psp-dev.h
@@ -17,9 +17,6 @@
#include "sp-dev.h"
-#define PSP_CMDRESP_RESP BIT(31)
-#define PSP_CMDRESP_ERR_MASK 0xffff
-
#define MAX_PSP_NAME_LEN 16
extern struct psp_device *psp_master;
diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
index 28945ca7c8563..6440d35dfa4ee 100644
--- a/drivers/crypto/ccp/sev-dev.c
+++ b/drivers/crypto/ccp/sev-dev.c
@@ -7,6 +7,7 @@
* Author: Brijesh Singh <brijesh.singh@amd.com>
*/
+#include <linux/bitfield.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/kthread.h>
@@ -103,7 +104,7 @@ static void sev_irq_handler(int irq, void *data, unsigned int status)
/* Check if it is SEV command completion: */
reg = ioread32(sev->io_regs + sev->vdata->cmdresp_reg);
- if (reg & PSP_CMDRESP_RESP) {
+ if (FIELD_GET(PSP_CMDRESP_RESP, reg)) {
sev->int_rcvd = 1;
wake_up(&sev->int_queue);
}
@@ -347,9 +348,7 @@ static int __sev_do_cmd_locked(int cmd, void *data, int *psp_ret)
sev->int_rcvd = 0;
- reg = cmd;
- reg <<= SEV_CMDRESP_CMD_SHIFT;
- reg |= SEV_CMDRESP_IOC;
+ reg = FIELD_PREP(SEV_CMDRESP_CMD, cmd) | SEV_CMDRESP_IOC;
iowrite32(reg, sev->io_regs + sev->vdata->cmdresp_reg);
/* wait for command completion */
@@ -367,11 +366,11 @@ static int __sev_do_cmd_locked(int cmd, void *data, int *psp_ret)
psp_timeout = psp_cmd_timeout;
if (psp_ret)
- *psp_ret = reg & PSP_CMDRESP_ERR_MASK;
+ *psp_ret = FIELD_GET(PSP_CMDRESP_STS, reg);
- if (reg & PSP_CMDRESP_ERR_MASK) {
- dev_dbg(sev->dev, "sev command %#x failed (%#010x)\n",
- cmd, reg & PSP_CMDRESP_ERR_MASK);
+ if (FIELD_GET(PSP_CMDRESP_STS, reg)) {
+ dev_dbg(sev->dev, "sev command %#x failed (%#010lx)\n",
+ cmd, FIELD_GET(PSP_CMDRESP_STS, reg));
ret = -EIO;
} else {
ret = sev_write_init_ex_file_if_required(cmd);
diff --git a/drivers/crypto/ccp/sev-dev.h b/drivers/crypto/ccp/sev-dev.h
index 666c21eb81ab3..778c95155e745 100644
--- a/drivers/crypto/ccp/sev-dev.h
+++ b/drivers/crypto/ccp/sev-dev.h
@@ -25,8 +25,8 @@
#include <linux/miscdevice.h>
#include <linux/capability.h>
+#define SEV_CMDRESP_CMD GENMASK(26, 16)
#define SEV_CMD_COMPLETE BIT(1)
-#define SEV_CMDRESP_CMD_SHIFT 16
#define SEV_CMDRESP_IOC BIT(0)
struct sev_misc_dev {
diff --git a/drivers/crypto/ccp/tee-dev.c b/drivers/crypto/ccp/tee-dev.c
index f24fc953718a0..5560bf8329a12 100644
--- a/drivers/crypto/ccp/tee-dev.c
+++ b/drivers/crypto/ccp/tee-dev.c
@@ -8,6 +8,7 @@
* Copyright (C) 2019,2021 Advanced Micro Devices, Inc.
*/
+#include <linux/bitfield.h>
#include <linux/types.h>
#include <linux/mutex.h>
#include <linux/delay.h>
@@ -69,7 +70,7 @@ static int tee_wait_cmd_poll(struct psp_tee_device *tee, unsigned int timeout,
while (--nloop) {
*reg = ioread32(tee->io_regs + tee->vdata->cmdresp_reg);
- if (*reg & PSP_CMDRESP_RESP)
+ if (FIELD_GET(PSP_CMDRESP_RESP, *reg))
return 0;
usleep_range(10000, 10100);
@@ -149,9 +150,9 @@ static int tee_init_ring(struct psp_tee_device *tee)
goto free_buf;
}
- if (reg & PSP_CMDRESP_ERR_MASK) {
- dev_err(tee->dev, "tee: ring init command failed (%#010x)\n",
- reg & PSP_CMDRESP_ERR_MASK);
+ if (FIELD_GET(PSP_CMDRESP_STS, reg)) {
+ dev_err(tee->dev, "tee: ring init command failed (%#010lx)\n",
+ FIELD_GET(PSP_CMDRESP_STS, reg));
tee_free_ring(tee);
ret = -EIO;
}
@@ -179,9 +180,9 @@ static void tee_destroy_ring(struct psp_tee_device *tee)
ret = tee_wait_cmd_poll(tee, TEE_DEFAULT_TIMEOUT, ®);
if (ret) {
dev_err(tee->dev, "tee: ring destroy command timed out\n");
- } else if (reg & PSP_CMDRESP_ERR_MASK) {
- dev_err(tee->dev, "tee: ring destroy command failed (%#010x)\n",
- reg & PSP_CMDRESP_ERR_MASK);
+ } else if (FIELD_GET(PSP_CMDRESP_STS, reg)) {
+ dev_err(tee->dev, "tee: ring destroy command failed (%#010lx)\n",
+ FIELD_GET(PSP_CMDRESP_STS, reg));
}
free_ring:
diff --git a/drivers/i2c/busses/i2c-designware-amdpsp.c b/drivers/i2c/busses/i2c-designware-amdpsp.c
index 80f28a1bbbef6..85d91cb6b9056 100644
--- a/drivers/i2c/busses/i2c-designware-amdpsp.c
+++ b/drivers/i2c/busses/i2c-designware-amdpsp.c
@@ -25,12 +25,6 @@
#define PSP_I2C_REQ_STS_BUS_BUSY 0x1
#define PSP_I2C_REQ_STS_INV_PARAM 0x3
-#define PSP_MBOX_FIELDS_STS GENMASK(15, 0)
-#define PSP_MBOX_FIELDS_CMD GENMASK(23, 16)
-#define PSP_MBOX_FIELDS_RESERVED GENMASK(29, 24)
-#define PSP_MBOX_FIELDS_RECOVERY BIT(30)
-#define PSP_MBOX_FIELDS_READY BIT(31)
-
struct psp_req_buffer_hdr {
u32 total_size;
u32 status;
@@ -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);
/*
* Check for readiness of PSP mailbox in a tight loop in order to
@@ -124,7 +118,7 @@ static u32 psp_check_mbox_sts(struct psp_mbox __iomem *mbox)
cmd_reg = readl(&mbox->cmd_fields);
- return FIELD_GET(PSP_MBOX_FIELDS_STS, cmd_reg);
+ return FIELD_GET(PSP_CMDRESP_STS, cmd_reg);
}
static int psp_send_cmd(struct psp_i2c_req *req)
@@ -148,7 +142,7 @@ static int psp_send_cmd(struct psp_i2c_req *req)
writeq(req_addr, &mbox->i2c_req_addr);
/* Write command register to trigger processing */
- cmd_reg = FIELD_PREP(PSP_MBOX_FIELDS_CMD, PSP_I2C_REQ_BUS_CMD);
+ cmd_reg = FIELD_PREP(PSP_CMDRESP_CMD, PSP_I2C_REQ_BUS_CMD);
writel(cmd_reg, &mbox->cmd_fields);
if (psp_wait_cmd(mbox))
diff --git a/include/linux/psp.h b/include/linux/psp.h
index 202162487ec3b..d3424790a70eb 100644
--- a/include/linux/psp.h
+++ b/include/linux/psp.h
@@ -11,4 +11,16 @@
#define __psp_pa(x) __pa(x)
#endif
+/*
+ * Fields and bits used by most PSP mailboxes
+ *
+ * Note: Some mailboxes (such as SEV) have extra bits or different meanings
+ * and should include an appropriate local definition in their source file.
+ */
+#define PSP_CMDRESP_STS GENMASK(15, 0)
+#define PSP_CMDRESP_CMD GENMASK(23, 16)
+#define PSP_CMDRESP_RESERVED GENMASK(29, 24)
+#define PSP_CMDRESP_RECOVERY BIT(30)
+#define PSP_CMDRESP_RESP BIT(31)
+
#endif /* __PSP_H */
--
2.34.1
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH 3/6] crypto: ccp: Move some PSP mailbox bit definitions into common header
2023-02-09 22:38 ` [PATCH 3/6] crypto: ccp: Move some PSP mailbox bit definitions into common header Mario Limonciello
@ 2023-02-14 9:04 ` Jan Dąbroś
2023-02-14 22:05 ` Limonciello, Mario
0 siblings, 1 reply; 24+ messages in thread
From: Jan Dąbroś @ 2023-02-14 9:04 UTC (permalink / raw)
To: Mario Limonciello
Cc: Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
John Allen, Brijesh Singh, Jarkko Nikula, Andy Shevchenko,
Mika Westerberg, linux-i2c, linux-crypto, linux-kernel,
David S. Miller
(...)
> @@ -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.)
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: [PATCH 3/6] crypto: ccp: Move some PSP mailbox bit definitions into common header
2023-02-14 9:04 ` Jan Dąbroś
@ 2023-02-14 22:05 ` Limonciello, Mario
2023-02-16 14:23 ` Tom Lendacky
0 siblings, 1 reply; 24+ messages in thread
From: Limonciello, Mario @ 2023-02-14 22:05 UTC (permalink / raw)
To: Jan Dąbroś, Lendacky, Thomas
Cc: Grzegorz Bernacki, Thomas, Rijo-john, herbert, Allen, John,
Singh, Brijesh, Jarkko Nikula, Andy Shevchenko, Mika Westerberg,
linux-i2c, linux-crypto, linux-kernel, David S. Miller
[Public]
> -----Original Message-----
> From: Jan Dąbroś <jsd@semihalf.com>
> Sent: Tuesday, February 14, 2023 03:04
> To: Limonciello, Mario <Mario.Limonciello@amd.com>
> Cc: Grzegorz Bernacki <gjb@semihalf.com>; Thomas, Rijo-john <Rijo-
> john.Thomas@amd.com>; Lendacky, Thomas
> <Thomas.Lendacky@amd.com>; herbert@gondor.apana.org.au; Allen, John
> <John.Allen@amd.com>; Singh, Brijesh <Brijesh.Singh@amd.com>; Jarkko
> Nikula <jarkko.nikula@linux.intel.com>; Andy Shevchenko
> <andriy.shevchenko@linux.intel.com>; Mika Westerberg
> <mika.westerberg@linux.intel.com>; linux-i2c@vger.kernel.org; linux-
> crypto@vger.kernel.org; linux-kernel@vger.kernel.org; David S. Miller
> <davem@davemloft.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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 3/6] crypto: ccp: Move some PSP mailbox bit definitions into common header
2023-02-14 22:05 ` Limonciello, Mario
@ 2023-02-16 14:23 ` Tom Lendacky
0 siblings, 0 replies; 24+ messages in thread
From: Tom Lendacky @ 2023-02-16 14:23 UTC (permalink / raw)
To: Limonciello, Mario, Jan Dąbroś
Cc: Grzegorz Bernacki, Thomas, Rijo-john, herbert, Allen, John,
Singh, Brijesh, Jarkko Nikula, Andy Shevchenko, Mika Westerberg,
linux-i2c, linux-crypto, linux-kernel, David S. Miller
On 2/14/23 16:05, Limonciello, Mario wrote:
> [Public]
>
>
>
>> -----Original Message-----
>> From: Jan Dąbroś <jsd@semihalf.com>
>> Sent: Tuesday, February 14, 2023 03:04
>> To: Limonciello, Mario <Mario.Limonciello@amd.com>
>> Cc: Grzegorz Bernacki <gjb@semihalf.com>; Thomas, Rijo-john <Rijo-
>> john.Thomas@amd.com>; Lendacky, Thomas
>> <Thomas.Lendacky@amd.com>; herbert@gondor.apana.org.au; Allen, John
>> <John.Allen@amd.com>; Singh, Brijesh <Brijesh.Singh@amd.com>; Jarkko
>> Nikula <jarkko.nikula@linux.intel.com>; Andy Shevchenko
>> <andriy.shevchenko@linux.intel.com>; Mika Westerberg
>> <mika.westerberg@linux.intel.com>; linux-i2c@vger.kernel.org; linux-
>> crypto@vger.kernel.org; linux-kernel@vger.kernel.org; David S. Miller
>> <davem@davemloft.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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 4/6] crypto: ccp: Add support for an interface for platform features
2023-02-09 22:38 [PATCH 0/6] Export platform features from ccp driver Mario Limonciello
` (2 preceding siblings ...)
2023-02-09 22:38 ` [PATCH 3/6] crypto: ccp: Move some PSP mailbox bit definitions into common header Mario Limonciello
@ 2023-02-09 22:38 ` Mario Limonciello
2023-02-09 22:38 ` [PATCH 5/6] crypto: ccp: Enable platform access interface on client PSP parts Mario Limonciello
2023-02-09 22:38 ` [PATCH 6/6] i2c: designware: Use PCI PSP driver for communication Mario Limonciello
5 siblings, 0 replies; 24+ messages in thread
From: Mario Limonciello @ 2023-02-09 22:38 UTC (permalink / raw)
To: Jan Dąbroś,
Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Tom Lendacky, John Allen
Cc: andriy.shevchenko, linux-i2c, linux-crypto, linux-kernel,
Mario Limonciello, David S. Miller
Some platforms with a PSP support an interface for features that
interact directly with the PSP instead of through a SEV or TEE
environment.
Initialize this interface so that other drivers can consume it.
These drivers may either be subdrivers for the ccp module or
external modules. For external modules, export a symbol for them
to utilize.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
drivers/crypto/ccp/Makefile | 3 +-
drivers/crypto/ccp/platform-access.c | 166 +++++++++++++++++++++++++++
drivers/crypto/ccp/platform-access.h | 34 ++++++
drivers/crypto/ccp/psp-dev.c | 17 +++
drivers/crypto/ccp/psp-dev.h | 1 +
drivers/crypto/ccp/sp-dev.h | 7 ++
include/linux/psp-platform-access.h | 49 ++++++++
7 files changed, 276 insertions(+), 1 deletion(-)
create mode 100644 drivers/crypto/ccp/platform-access.c
create mode 100644 drivers/crypto/ccp/platform-access.h
create mode 100644 include/linux/psp-platform-access.h
diff --git a/drivers/crypto/ccp/Makefile b/drivers/crypto/ccp/Makefile
index db362fe472ea3..f6196495e862d 100644
--- a/drivers/crypto/ccp/Makefile
+++ b/drivers/crypto/ccp/Makefile
@@ -10,7 +10,8 @@ ccp-$(CONFIG_CRYPTO_DEV_CCP_DEBUGFS) += ccp-debugfs.o
ccp-$(CONFIG_PCI) += sp-pci.o
ccp-$(CONFIG_CRYPTO_DEV_SP_PSP) += psp-dev.o \
sev-dev.o \
- tee-dev.o
+ tee-dev.o \
+ platform-access.o
obj-$(CONFIG_CRYPTO_DEV_CCP_CRYPTO) += ccp-crypto.o
ccp-crypto-objs := ccp-crypto-main.o \
diff --git a/drivers/crypto/ccp/platform-access.c b/drivers/crypto/ccp/platform-access.c
new file mode 100644
index 0000000000000..8cd165ba915b9
--- /dev/null
+++ b/drivers/crypto/ccp/platform-access.c
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AMD Platform Security Processor (PSP) Platform Access interface
+ *
+ * Copyright (C) 2023 Advanced Micro Devices, Inc.
+ *
+ * Author: Mario Limonciello <mario.limonciello@amd.com>
+ *
+ * Some of this code is adapted from drivers/i2c/busses/i2c-designware-amdpsp.c
+ * developed by Jan Dabros <jsd@semihalf.com> and Copyright (C) 2022 Google Inc.
+ *
+ */
+
+#include <linux/bitfield.h>
+#include <linux/errno.h>
+#include <linux/iopoll.h>
+#include <linux/mutex.h>
+
+#include "platform-access.h"
+
+#define PSP_CMD_TIMEOUT_US (500 * USEC_PER_MSEC)
+
+/* Recovery field should be equal 0 to start sending commands */
+static int check_recovery(u32 __iomem *cmd)
+{
+ return FIELD_GET(PSP_CMDRESP_RECOVERY, ioread32(cmd));
+}
+
+static int wait_cmd(u32 __iomem *cmd)
+{
+ u32 tmp, expected;
+
+ /* Expect mbox_cmd to be cleared and ready bit to be set by PSP */
+ expected = FIELD_PREP(PSP_CMDRESP_RESP, 1);
+
+ /*
+ * Check for readiness of PSP mailbox in a tight loop in order to
+ * process further as soon as command was consumed.
+ */
+ return readl_poll_timeout(cmd, tmp, (tmp & expected), 0,
+ PSP_CMD_TIMEOUT_US);
+}
+
+int psp_check_platform_access_status(void)
+{
+ struct psp_device *psp = psp_get_master_device();
+
+ if (!psp || !psp->platform_access_data)
+ return -ENODEV;
+
+ return 0;
+}
+EXPORT_SYMBOL(psp_check_platform_access_status);
+
+int psp_send_platform_access_msg(enum psp_platform_access_msg msg,
+ struct psp_request *req)
+{
+ struct psp_device *psp = psp_get_master_device();
+ u32 __iomem *cmd, __iomem *lo, __iomem *hi;
+ struct psp_platform_access_device *pa_dev;
+ phys_addr_t req_addr;
+ u32 cmd_reg;
+ int ret;
+
+ if (!psp || !psp->platform_access_data)
+ return -ENODEV;
+
+ pa_dev = psp->platform_access_data;
+ cmd = psp->io_regs + pa_dev->vdata->cmdresp_reg;
+ lo = psp->io_regs + pa_dev->vdata->cmdbuff_addr_lo_reg;
+ hi = psp->io_regs + pa_dev->vdata->cmdbuff_addr_hi_reg;
+
+ mutex_lock(&pa_dev->mutex);
+
+ if (check_recovery(cmd)) {
+ dev_dbg(psp->dev, "in recovery\n");
+ ret = -EBUSY;
+ goto unlock;
+ }
+
+ if (wait_cmd(cmd)) {
+ dev_dbg(psp->dev, "not done processing command\n");
+ ret = -EBUSY;
+ goto unlock;
+ }
+
+ /*
+ * Fill mailbox with address of command-response buffer, which will be
+ * used for sending i2c requests as well as reading status returned by
+ * PSP. Use physical address of buffer, since PSP will map this region.
+ */
+ req_addr = __psp_pa(req);
+ iowrite32(lower_32_bits(req_addr), lo);
+ iowrite32(upper_32_bits(req_addr), hi);
+
+ print_hex_dump_debug("->psp ", DUMP_PREFIX_OFFSET, 16, 2, req,
+ req->header.payload_size, false);
+
+ /* Write command register to trigger processing */
+ cmd_reg = FIELD_PREP(PSP_CMDRESP_CMD, msg);
+ iowrite32(cmd_reg, cmd);
+
+ if (wait_cmd(cmd)) {
+ ret = -ETIMEDOUT;
+ goto unlock;
+ }
+
+ /* Ensure it was triggered by this driver */
+ if (ioread32(lo) != lower_32_bits(req_addr) ||
+ ioread32(hi) != upper_32_bits(req_addr)) {
+ ret = -EBUSY;
+ goto unlock;
+ }
+
+ /* Store the status in request header for caller to investigate */
+ cmd_reg = ioread32(cmd);
+ req->header.status = FIELD_GET(PSP_CMDRESP_STS, cmd_reg);
+ if (req->header.status) {
+ ret = -EIO;
+ goto unlock;
+ }
+
+ print_hex_dump_debug("<-psp ", DUMP_PREFIX_OFFSET, 16, 2, req,
+ req->header.payload_size, false);
+
+ ret = 0;
+
+unlock:
+ mutex_unlock(&pa_dev->mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(psp_send_platform_access_msg);
+
+void platform_access_dev_destroy(struct psp_device *psp)
+{
+ struct psp_platform_access_device *pa_dev = psp->platform_access_data;
+
+ if (!pa_dev)
+ return;
+
+ mutex_destroy(&pa_dev->mutex);
+ psp->platform_access_data = NULL;
+}
+
+int platform_access_dev_init(struct psp_device *psp)
+{
+ struct device *dev = psp->dev;
+ struct psp_platform_access_device *pa_dev;
+
+ pa_dev = devm_kzalloc(dev, sizeof(*pa_dev), GFP_KERNEL);
+ if (!pa_dev)
+ return -ENOMEM;
+
+ psp->platform_access_data = pa_dev;
+ pa_dev->psp = psp;
+ pa_dev->dev = dev;
+
+ pa_dev->vdata = (struct platform_access_vdata *)psp->vdata->platform_access;
+
+ mutex_init(&pa_dev->mutex);
+
+ dev_dbg(dev, "platform access enabled\n");
+
+ return 0;
+}
diff --git a/drivers/crypto/ccp/platform-access.h b/drivers/crypto/ccp/platform-access.h
new file mode 100644
index 0000000000000..56bc8eabeacc8
--- /dev/null
+++ b/drivers/crypto/ccp/platform-access.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * AMD Platform Security Processor (PSP) Platform Access interface
+ *
+ * Copyright (C) 2023 Advanced Micro Devices, Inc.
+ *
+ * Author: Mario Limonciello <mario.limonciello@amd.com>
+ */
+
+#ifndef __PSP_PLATFORM_ACCESS_H__
+#define __PSP_PLATFORM_ACCESS_H__
+
+#include <linux/device.h>
+#include <linux/miscdevice.h>
+#include <linux/mutex.h>
+#include <linux/psp-platform-access.h>
+
+#include "psp-dev.h"
+
+struct psp_platform_access_device {
+ struct device *dev;
+ struct psp_device *psp;
+
+ struct platform_access_vdata *vdata;
+
+ struct mutex mutex;
+
+ void *platform_access_data;
+};
+
+void platform_access_dev_destroy(struct psp_device *psp);
+int platform_access_dev_init(struct psp_device *psp);
+
+#endif /* __PSP_PLATFORM_ACCESS_H__ */
diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c
index cd8d1974726a8..ec98f19800de7 100644
--- a/drivers/crypto/ccp/psp-dev.c
+++ b/drivers/crypto/ccp/psp-dev.c
@@ -14,6 +14,7 @@
#include "psp-dev.h"
#include "sev-dev.h"
#include "tee-dev.h"
+#include "platform-access.h"
struct psp_device *psp_master;
@@ -102,6 +103,17 @@ static int psp_check_tee_support(struct psp_device *psp)
return 0;
}
+static void psp_init_platform_access(struct psp_device *psp)
+{
+ int ret;
+
+ ret = platform_access_dev_init(psp);
+ if (ret) {
+ dev_warn(psp->dev, "platform access init failed: %d\n", ret);
+ return;
+ }
+}
+
static int psp_init(struct psp_device *psp)
{
int ret;
@@ -118,6 +130,9 @@ static int psp_init(struct psp_device *psp)
return ret;
}
+ if (psp->vdata->platform_access)
+ psp_init_platform_access(psp);
+
return 0;
}
@@ -198,6 +213,8 @@ void psp_dev_destroy(struct sp_device *sp)
tee_dev_destroy(psp);
+ platform_access_dev_destroy(psp);
+
sp_free_psp_irq(sp, psp);
if (sp->clear_psp_master_device)
diff --git a/drivers/crypto/ccp/psp-dev.h b/drivers/crypto/ccp/psp-dev.h
index 55f54bb2b3fba..505e4bdeaca84 100644
--- a/drivers/crypto/ccp/psp-dev.h
+++ b/drivers/crypto/ccp/psp-dev.h
@@ -39,6 +39,7 @@ struct psp_device {
void *sev_data;
void *tee_data;
+ void *platform_access_data;
unsigned int capability;
};
diff --git a/drivers/crypto/ccp/sp-dev.h b/drivers/crypto/ccp/sp-dev.h
index 20377e67f65df..5ec6c219a731b 100644
--- a/drivers/crypto/ccp/sp-dev.h
+++ b/drivers/crypto/ccp/sp-dev.h
@@ -53,9 +53,16 @@ struct tee_vdata {
const unsigned int ring_rptr_reg;
};
+struct platform_access_vdata {
+ const unsigned int cmdresp_reg;
+ const unsigned int cmdbuff_addr_lo_reg;
+ const unsigned int cmdbuff_addr_hi_reg;
+};
+
struct psp_vdata {
const struct sev_vdata *sev;
const struct tee_vdata *tee;
+ const struct platform_access_vdata *platform_access;
const unsigned int feature_reg;
const unsigned int inten_reg;
const unsigned int intsts_reg;
diff --git a/include/linux/psp-platform-access.h b/include/linux/psp-platform-access.h
new file mode 100644
index 0000000000000..60bfd5f0b045e
--- /dev/null
+++ b/include/linux/psp-platform-access.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __PSP_PLATFORM_ACCESS_H
+#define __PSP_PLATFORM_ACCESS_H
+
+#include <linux/psp.h>
+
+enum psp_platform_access_msg {
+ PSP_CMD_NONE = 0x0,
+};
+
+struct psp_req_buffer_hdr {
+ u32 payload_size;
+ u32 status;
+} __packed;
+
+struct psp_request {
+ struct psp_req_buffer_hdr header;
+ void *buf;
+} __packed;
+
+/**
+ * psp_send_platform_access_msg() - Send a message to control platform features
+ *
+ * This function is intended to be used by drivers outside of ccp to determine
+ * if platform features has initialized.
+ *
+ * Returns:
+ * 0: success
+ * -%EBUSY: mailbox in recovery or in use
+ * -%ENODEV: driver not bound with PSP device
+ * -%ETIMEDOUT: request timed out
+ * -%EIO: unknown error (see kernel log)
+ */
+int psp_send_platform_access_msg(enum psp_platform_access_msg, struct psp_request *req);
+
+/**
+ * psp_check_platform_access_status() - Checks whether platform features is ready
+ *
+ * This function is intended to be used by drivers outside of ccp to determine
+ * if platform features has initialized.
+ *
+ * Returns:
+ * 0 platform features is ready
+ * -%ENODEV platform features is not ready or present
+ */
+int psp_check_platform_access_status(void);
+
+#endif /* __PSP_PLATFORM_ACCESS_H */
--
2.34.1
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH 5/6] crypto: ccp: Enable platform access interface on client PSP parts
2023-02-09 22:38 [PATCH 0/6] Export platform features from ccp driver Mario Limonciello
` (3 preceding siblings ...)
2023-02-09 22:38 ` [PATCH 4/6] crypto: ccp: Add support for an interface for platform features Mario Limonciello
@ 2023-02-09 22:38 ` Mario Limonciello
2023-02-09 22:38 ` [PATCH 6/6] i2c: designware: Use PCI PSP driver for communication Mario Limonciello
5 siblings, 0 replies; 24+ messages in thread
From: Mario Limonciello @ 2023-02-09 22:38 UTC (permalink / raw)
To: Jan Dąbroś,
Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Tom Lendacky, John Allen
Cc: andriy.shevchenko, linux-i2c, linux-crypto, linux-kernel,
Mario Limonciello, David S. Miller
Client PSP parts support the platform access interface. Add
the register offsets so that client parts will initialize this
interface.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
drivers/crypto/ccp/sp-pci.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c
index cde33b2ac71b2..18aa902eb5ce9 100644
--- a/drivers/crypto/ccp/sp-pci.c
+++ b/drivers/crypto/ccp/sp-pci.c
@@ -361,6 +361,12 @@ static const struct tee_vdata teev1 = {
.ring_rptr_reg = 0x10554, /* C2PMSG_21 */
};
+static const struct platform_access_vdata pa_v1 = {
+ .cmdresp_reg = 0x10570, /* C2PMSG_28 */
+ .cmdbuff_addr_lo_reg = 0x10574, /* C2PMSG_29 */
+ .cmdbuff_addr_hi_reg = 0x10578, /* C2PMSG_30 */
+};
+
static const struct psp_vdata pspv1 = {
.sev = &sevv1,
.feature_reg = 0x105fc, /* C2PMSG_63 */
@@ -377,6 +383,7 @@ static const struct psp_vdata pspv2 = {
static const struct psp_vdata pspv3 = {
.tee = &teev1,
+ .platform_access = &pa_v1,
.feature_reg = 0x109fc, /* C2PMSG_63 */
.inten_reg = 0x10690, /* P2CMSG_INTEN */
.intsts_reg = 0x10694, /* P2CMSG_INTSTS */
--
2.34.1
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH 6/6] i2c: designware: Use PCI PSP driver for communication
2023-02-09 22:38 [PATCH 0/6] Export platform features from ccp driver Mario Limonciello
` (4 preceding siblings ...)
2023-02-09 22:38 ` [PATCH 5/6] crypto: ccp: Enable platform access interface on client PSP parts Mario Limonciello
@ 2023-02-09 22:38 ` Mario Limonciello
2023-02-10 10:43 ` Andy Shevchenko
2023-02-16 13:27 ` Jarkko Nikula
5 siblings, 2 replies; 24+ messages in thread
From: Mario Limonciello @ 2023-02-09 22:38 UTC (permalink / raw)
To: Jan Dąbroś,
Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Jarkko Nikula, Andy Shevchenko, Mika Westerberg
Cc: linux-i2c, linux-crypto, linux-kernel, Mario Limonciello
Currently the PSP semaphore communication base address is discovered
by using an MSR that is not architecturally guaranteed for future
platforms. Also the mailbox that is utilized for communication with
the PSP may have other consumers in the kernel, so it's better to
make all communication go through a single driver.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-designware-amdpsp.c | 141 +-------------------
drivers/i2c/busses/i2c-designware-core.h | 1 -
drivers/i2c/busses/i2c-designware-platdrv.c | 1 -
include/linux/psp-platform-access.h | 1 +
5 files changed, 9 insertions(+), 137 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index a7bfddf08fa7b..9e2202ca73ec7 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -566,9 +566,9 @@ config I2C_DESIGNWARE_PLATFORM
config I2C_DESIGNWARE_AMDPSP
bool "AMD PSP I2C semaphore support"
- depends on X86_MSR
depends on ACPI
depends on I2C_DESIGNWARE_PLATFORM
+ depends on CRYPTO_DEV_SP_PSP && !(I2C_DESIGNWARE_PLATFORM=y && CRYPTO_DEV_CCP_DD=m)
help
This driver enables managed host access to the selected I2C bus shared
between AMD CPU and AMD PSP.
diff --git a/drivers/i2c/busses/i2c-designware-amdpsp.c b/drivers/i2c/busses/i2c-designware-amdpsp.c
index 85d91cb6b9056..f72c403cd28f9 100644
--- a/drivers/i2c/busses/i2c-designware-amdpsp.c
+++ b/drivers/i2c/busses/i2c-designware-amdpsp.c
@@ -1,11 +1,8 @@
// SPDX-License-Identifier: GPL-2.0
-#include <linux/bitfield.h>
-#include <linux/bits.h>
#include <linux/i2c.h>
-#include <linux/io-64-nonatomic-lo-hi.h>
+#include <linux/psp-platform-access.h>
#include <linux/psp.h>
-#include <linux/types.h>
#include <linux/workqueue.h>
#include <asm/msr.h>
@@ -13,23 +10,15 @@
#include "i2c-designware-core.h"
#define MSR_AMD_PSP_ADDR 0xc00110a2
-#define PSP_MBOX_OFFSET 0x10570
-#define PSP_CMD_TIMEOUT_US (500 * USEC_PER_MSEC)
#define PSP_I2C_RESERVATION_TIME_MS 100
-#define PSP_I2C_REQ_BUS_CMD 0x64
#define PSP_I2C_REQ_RETRY_CNT 400
#define PSP_I2C_REQ_RETRY_DELAY_US (25 * USEC_PER_MSEC)
#define PSP_I2C_REQ_STS_OK 0x0
#define PSP_I2C_REQ_STS_BUS_BUSY 0x1
#define PSP_I2C_REQ_STS_INV_PARAM 0x3
-struct psp_req_buffer_hdr {
- u32 total_size;
- u32 status;
-};
-
enum psp_i2c_req_type {
PSP_I2C_REQ_ACQUIRE,
PSP_I2C_REQ_RELEASE,
@@ -41,119 +30,12 @@ struct psp_i2c_req {
enum psp_i2c_req_type type;
};
-struct psp_mbox {
- u32 cmd_fields;
- u64 i2c_req_addr;
-} __packed;
-
static DEFINE_MUTEX(psp_i2c_access_mutex);
static unsigned long psp_i2c_sem_acquired;
-static void __iomem *mbox_iomem;
static u32 psp_i2c_access_count;
static bool psp_i2c_mbox_fail;
static struct device *psp_i2c_dev;
-/*
- * Implementation of PSP-x86 i2c-arbitration mailbox introduced for AMD Cezanne
- * family of SoCs.
- */
-
-static int psp_get_mbox_addr(unsigned long *mbox_addr)
-{
- unsigned long long psp_mmio;
-
- if (rdmsrl_safe(MSR_AMD_PSP_ADDR, &psp_mmio))
- return -EIO;
-
- *mbox_addr = (unsigned long)(psp_mmio + PSP_MBOX_OFFSET);
-
- return 0;
-}
-
-static int psp_mbox_probe(void)
-{
- unsigned long mbox_addr;
- int ret;
-
- ret = psp_get_mbox_addr(&mbox_addr);
- if (ret)
- return ret;
-
- mbox_iomem = ioremap(mbox_addr, sizeof(struct psp_mbox));
- if (!mbox_iomem)
- return -ENOMEM;
-
- return 0;
-}
-
-/* Recovery field should be equal 0 to start sending commands */
-static int psp_check_mbox_recovery(struct psp_mbox __iomem *mbox)
-{
- u32 tmp;
-
- tmp = readl(&mbox->cmd_fields);
-
- return FIELD_GET(PSP_CMDRESP_RECOVERY, tmp);
-}
-
-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_CMDRESP_RESP, 1);
-
- /*
- * Check for readiness of PSP mailbox in a tight loop in order to
- * process further as soon as command was consumed.
- */
- return readl_poll_timeout(&mbox->cmd_fields, tmp, (tmp == expected),
- 0, PSP_CMD_TIMEOUT_US);
-}
-
-/* Status equal to 0 means that PSP succeed processing command */
-static u32 psp_check_mbox_sts(struct psp_mbox __iomem *mbox)
-{
- u32 cmd_reg;
-
- cmd_reg = readl(&mbox->cmd_fields);
-
- return FIELD_GET(PSP_CMDRESP_STS, cmd_reg);
-}
-
-static int psp_send_cmd(struct psp_i2c_req *req)
-{
- struct psp_mbox __iomem *mbox = mbox_iomem;
- phys_addr_t req_addr;
- u32 cmd_reg;
-
- if (psp_check_mbox_recovery(mbox))
- return -EIO;
-
- if (psp_wait_cmd(mbox))
- return -EBUSY;
-
- /*
- * Fill mailbox with address of command-response buffer, which will be
- * used for sending i2c requests as well as reading status returned by
- * PSP. Use physical address of buffer, since PSP will map this region.
- */
- req_addr = __psp_pa((void *)req);
- writeq(req_addr, &mbox->i2c_req_addr);
-
- /* Write command register to trigger processing */
- cmd_reg = FIELD_PREP(PSP_CMDRESP_CMD, PSP_I2C_REQ_BUS_CMD);
- writel(cmd_reg, &mbox->cmd_fields);
-
- if (psp_wait_cmd(mbox))
- return -ETIMEDOUT;
-
- if (psp_check_mbox_sts(mbox))
- return -EIO;
-
- return 0;
-}
-
/* Helper to verify status returned by PSP */
static int check_i2c_req_sts(struct psp_i2c_req *req)
{
@@ -182,10 +64,10 @@ static int psp_send_check_i2c_req(struct psp_i2c_req *req)
* 2. i2c-requests - PSP refuses to grant i2c arbitration to x86 for too
* long.
* In order to distinguish between these two in error handling code, all
- * errors on the first level (returned by psp_send_cmd) are shadowed by
+ * errors on the first level (returned by psp_send_platform_access_msg) are shadowed by
* -EIO.
*/
- if (psp_send_cmd(req))
+ if (psp_send_platform_access_msg(PSP_I2C_REQ_BUS_CMD, (struct psp_request *)req))
return -EIO;
return check_i2c_req_sts(req);
@@ -202,7 +84,7 @@ static int psp_send_i2c_req(enum psp_i2c_req_type i2c_req_type)
if (!req)
return -ENOMEM;
- req->hdr.total_size = sizeof(*req);
+ req->hdr.payload_size = sizeof(*req);
req->type = i2c_req_type;
start = jiffies;
@@ -381,8 +263,6 @@ static const struct i2c_lock_operations i2c_dw_psp_lock_ops = {
int i2c_dw_amdpsp_probe_lock_support(struct dw_i2c_dev *dev)
{
- int ret;
-
if (!dev)
return -ENODEV;
@@ -393,11 +273,10 @@ int i2c_dw_amdpsp_probe_lock_support(struct dw_i2c_dev *dev)
if (psp_i2c_dev)
return -EEXIST;
- psp_i2c_dev = dev->dev;
+ if (psp_check_platform_access_status())
+ return -EPROBE_DEFER;
- ret = psp_mbox_probe();
- if (ret)
- return ret;
+ psp_i2c_dev = dev->dev;
dev_info(psp_i2c_dev, "I2C bus managed by AMD PSP\n");
@@ -411,9 +290,3 @@ int i2c_dw_amdpsp_probe_lock_support(struct dw_i2c_dev *dev)
return 0;
}
-
-/* Unmap area used as a mailbox with PSP */
-void i2c_dw_amdpsp_remove_lock_support(struct dw_i2c_dev *dev)
-{
- iounmap(mbox_iomem);
-}
diff --git a/drivers/i2c/busses/i2c-designware-core.h b/drivers/i2c/busses/i2c-designware-core.h
index 95ebc5eaa5d12..d85d34c6bce10 100644
--- a/drivers/i2c/busses/i2c-designware-core.h
+++ b/drivers/i2c/busses/i2c-designware-core.h
@@ -382,7 +382,6 @@ int i2c_dw_baytrail_probe_lock_support(struct dw_i2c_dev *dev);
#if IS_ENABLED(CONFIG_I2C_DESIGNWARE_AMDPSP)
int i2c_dw_amdpsp_probe_lock_support(struct dw_i2c_dev *dev);
-void i2c_dw_amdpsp_remove_lock_support(struct dw_i2c_dev *dev);
#endif
int i2c_dw_validate_speed(struct dw_i2c_dev *dev);
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index ba043b5473936..99f54fe583e13 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -214,7 +214,6 @@ static const struct i2c_dw_semaphore_callbacks i2c_dw_semaphore_cb_table[] = {
#ifdef CONFIG_I2C_DESIGNWARE_AMDPSP
{
.probe = i2c_dw_amdpsp_probe_lock_support,
- .remove = i2c_dw_amdpsp_remove_lock_support,
},
#endif
{}
diff --git a/include/linux/psp-platform-access.h b/include/linux/psp-platform-access.h
index 60bfd5f0b045e..106791839ceb3 100644
--- a/include/linux/psp-platform-access.h
+++ b/include/linux/psp-platform-access.h
@@ -7,6 +7,7 @@
enum psp_platform_access_msg {
PSP_CMD_NONE = 0x0,
+ PSP_I2C_REQ_BUS_CMD = 0x64,
};
struct psp_req_buffer_hdr {
--
2.34.1
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH 6/6] i2c: designware: Use PCI PSP driver for communication
2023-02-09 22:38 ` [PATCH 6/6] i2c: designware: Use PCI PSP driver for communication Mario Limonciello
@ 2023-02-10 10:43 ` Andy Shevchenko
2023-02-16 13:27 ` Jarkko Nikula
1 sibling, 0 replies; 24+ messages in thread
From: Andy Shevchenko @ 2023-02-10 10:43 UTC (permalink / raw)
To: Mario Limonciello
Cc: Jan Dąbroś,
Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Jarkko Nikula, Mika Westerberg, linux-i2c, linux-crypto,
linux-kernel
On Thu, Feb 09, 2023 at 04:38:08PM -0600, Mario Limonciello wrote:
> Currently the PSP semaphore communication base address is discovered
> by using an MSR that is not architecturally guaranteed for future
> platforms. Also the mailbox that is utilized for communication with
> the PSP may have other consumers in the kernel, so it's better to
> make all communication go through a single driver.
...
> #if IS_ENABLED(CONFIG_I2C_DESIGNWARE_AMDPSP)
> int i2c_dw_amdpsp_probe_lock_support(struct dw_i2c_dev *dev);
> -void i2c_dw_amdpsp_remove_lock_support(struct dw_i2c_dev *dev);
> #endif
...
> #ifdef CONFIG_I2C_DESIGNWARE_AMDPSP
> {
> .probe = i2c_dw_amdpsp_probe_lock_support,
> - .remove = i2c_dw_amdpsp_remove_lock_support,
> },
> #endif
Personally I found better to have empty stub for the sake of symmetry of API.
But at the end it's not my decision, just felt that I have to express this.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 6/6] i2c: designware: Use PCI PSP driver for communication
2023-02-09 22:38 ` [PATCH 6/6] i2c: designware: Use PCI PSP driver for communication Mario Limonciello
2023-02-10 10:43 ` Andy Shevchenko
@ 2023-02-16 13:27 ` Jarkko Nikula
2023-02-16 13:29 ` Mario Limonciello
1 sibling, 1 reply; 24+ messages in thread
From: Jarkko Nikula @ 2023-02-16 13:27 UTC (permalink / raw)
To: Mario Limonciello, Jan Dąbroś,
Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Andy Shevchenko, Mika Westerberg
Cc: linux-i2c, linux-crypto, linux-kernel
On 2/10/23 00:38, Mario Limonciello wrote:
> Currently the PSP semaphore communication base address is discovered
> by using an MSR that is not architecturally guaranteed for future
> platforms. Also the mailbox that is utilized for communication with
> the PSP may have other consumers in the kernel, so it's better to
> make all communication go through a single driver.
>
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
> drivers/i2c/busses/Kconfig | 2 +-
> drivers/i2c/busses/i2c-designware-amdpsp.c | 141 +-------------------
> drivers/i2c/busses/i2c-designware-core.h | 1 -
> drivers/i2c/busses/i2c-designware-platdrv.c | 1 -
> include/linux/psp-platform-access.h | 1 +
> 5 files changed, 9 insertions(+), 137 deletions(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index a7bfddf08fa7b..9e2202ca73ec7 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -566,9 +566,9 @@ config I2C_DESIGNWARE_PLATFORM
>
> config I2C_DESIGNWARE_AMDPSP
> bool "AMD PSP I2C semaphore support"
> - depends on X86_MSR
> depends on ACPI
> depends on I2C_DESIGNWARE_PLATFORM
> + depends on CRYPTO_DEV_SP_PSP && !(I2C_DESIGNWARE_PLATFORM=y && CRYPTO_DEV_CCP_DD=m)
> help
Would this look better if split? I.e.
depends on CRYPTO_DEV_SP_PSP
depends on !(I2C_DESIGNWARE_PLATFORM=y && CRYPTO_DEV_CCP_DD=m)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 6/6] i2c: designware: Use PCI PSP driver for communication
2023-02-16 13:27 ` Jarkko Nikula
@ 2023-02-16 13:29 ` Mario Limonciello
2023-02-16 14:56 ` Andy Shevchenko
0 siblings, 1 reply; 24+ messages in thread
From: Mario Limonciello @ 2023-02-16 13:29 UTC (permalink / raw)
To: Jarkko Nikula, Jan Dąbroś,
Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Andy Shevchenko, Mika Westerberg
Cc: linux-i2c, linux-crypto, linux-kernel
On 2/16/23 07:27, Jarkko Nikula wrote:
> On 2/10/23 00:38, Mario Limonciello wrote:
>> Currently the PSP semaphore communication base address is discovered
>> by using an MSR that is not architecturally guaranteed for future
>> platforms. Also the mailbox that is utilized for communication with
>> the PSP may have other consumers in the kernel, so it's better to
>> make all communication go through a single driver.
>>
>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>> ---
>> drivers/i2c/busses/Kconfig | 2 +-
>> drivers/i2c/busses/i2c-designware-amdpsp.c | 141 +-------------------
>> drivers/i2c/busses/i2c-designware-core.h | 1 -
>> drivers/i2c/busses/i2c-designware-platdrv.c | 1 -
>> include/linux/psp-platform-access.h | 1 +
>> 5 files changed, 9 insertions(+), 137 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
>> index a7bfddf08fa7b..9e2202ca73ec7 100644
>> --- a/drivers/i2c/busses/Kconfig
>> +++ b/drivers/i2c/busses/Kconfig
>> @@ -566,9 +566,9 @@ config I2C_DESIGNWARE_PLATFORM
>> config I2C_DESIGNWARE_AMDPSP
>> bool "AMD PSP I2C semaphore support"
>> - depends on X86_MSR
>> depends on ACPI
>> depends on I2C_DESIGNWARE_PLATFORM
>> + depends on CRYPTO_DEV_SP_PSP && !(I2C_DESIGNWARE_PLATFORM=y &&
>> CRYPTO_DEV_CCP_DD=m)
>> help
>
> Would this look better if split? I.e.
>
> depends on CRYPTO_DEV_SP_PSP
> depends on !(I2C_DESIGNWARE_PLATFORM=y && CRYPTO_DEV_CCP_DD=m)
Yes, thanks I'll change that for next version.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 6/6] i2c: designware: Use PCI PSP driver for communication
2023-02-16 13:29 ` Mario Limonciello
@ 2023-02-16 14:56 ` Andy Shevchenko
2023-02-16 20:55 ` Limonciello, Mario
0 siblings, 1 reply; 24+ messages in thread
From: Andy Shevchenko @ 2023-02-16 14:56 UTC (permalink / raw)
To: Mario Limonciello
Cc: Jarkko Nikula, Jan Dąbroś,
Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Mika Westerberg, linux-i2c, linux-crypto, linux-kernel
On Thu, Feb 16, 2023 at 07:29:53AM -0600, Mario Limonciello wrote:
> On 2/16/23 07:27, Jarkko Nikula wrote:
> > On 2/10/23 00:38, Mario Limonciello wrote:
...
> > > config I2C_DESIGNWARE_AMDPSP
> > > bool "AMD PSP I2C semaphore support"
> > > - depends on X86_MSR
> > > depends on ACPI
> > > depends on I2C_DESIGNWARE_PLATFORM
> > > + depends on CRYPTO_DEV_SP_PSP && !(I2C_DESIGNWARE_PLATFORM=y &&
> > > CRYPTO_DEV_CCP_DD=m)
> > > help
> >
> > Would this look better if split? I.e.
> >
> > depends on CRYPTO_DEV_SP_PSP
> > depends on !(I2C_DESIGNWARE_PLATFORM=y && CRYPTO_DEV_CCP_DD=m)
> Yes, thanks I'll change that for next version.
I'm wondering if this is homegrown implementation of 'imply' keyword?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 6/6] i2c: designware: Use PCI PSP driver for communication
2023-02-16 14:56 ` Andy Shevchenko
@ 2023-02-16 20:55 ` Limonciello, Mario
2023-02-16 20:59 ` Andy Shevchenko
0 siblings, 1 reply; 24+ messages in thread
From: Limonciello, Mario @ 2023-02-16 20:55 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jarkko Nikula, Jan Dąbroś,
Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Mika Westerberg, linux-i2c, linux-crypto, linux-kernel
On 2/16/2023 08:56, Andy Shevchenko wrote:
> On Thu, Feb 16, 2023 at 07:29:53AM -0600, Mario Limonciello wrote:
>> On 2/16/23 07:27, Jarkko Nikula wrote:
>>> On 2/10/23 00:38, Mario Limonciello wrote:
>
> ...
>
>>>> config I2C_DESIGNWARE_AMDPSP
>>>> bool "AMD PSP I2C semaphore support"
>>>> - depends on X86_MSR
>>>> depends on ACPI
>>>> depends on I2C_DESIGNWARE_PLATFORM
>>>> + depends on CRYPTO_DEV_SP_PSP && !(I2C_DESIGNWARE_PLATFORM=y &&
>>>> CRYPTO_DEV_CCP_DD=m)
>>>> help
>>>
>>> Would this look better if split? I.e.
>>>
>>> depends on CRYPTO_DEV_SP_PSP
>>> depends on !(I2C_DESIGNWARE_PLATFORM=y && CRYPTO_DEV_CCP_DD=m)
>> Yes, thanks I'll change that for next version.
>
> I'm wondering if this is homegrown implementation of 'imply' keyword?
>
Like this?
config I2C_DESIGNWARE_AMDPSP
depends on CRYPTO_DEV_SP_PSP
depends on CRYPTO_DEV_CCP_DD
config CRYPTO_DEV_CCP_DD
imply I2C_DESIGNWARE_PLATFORM
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 6/6] i2c: designware: Use PCI PSP driver for communication
2023-02-16 20:55 ` Limonciello, Mario
@ 2023-02-16 20:59 ` Andy Shevchenko
2023-02-16 21:01 ` Limonciello, Mario
0 siblings, 1 reply; 24+ messages in thread
From: Andy Shevchenko @ 2023-02-16 20:59 UTC (permalink / raw)
To: Limonciello, Mario
Cc: Jarkko Nikula, Jan Dąbroś,
Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Mika Westerberg, linux-i2c, linux-crypto, linux-kernel
On Thu, Feb 16, 2023 at 02:55:07PM -0600, Limonciello, Mario wrote:
> On 2/16/2023 08:56, Andy Shevchenko wrote:
> > On Thu, Feb 16, 2023 at 07:29:53AM -0600, Mario Limonciello wrote:
> > > On 2/16/23 07:27, Jarkko Nikula wrote:
> > > > On 2/10/23 00:38, Mario Limonciello wrote:
...
> > > > > config I2C_DESIGNWARE_AMDPSP
> > > > > bool "AMD PSP I2C semaphore support"
> > > > > - depends on X86_MSR
> > > > > depends on ACPI
> > > > > depends on I2C_DESIGNWARE_PLATFORM
> > > > > + depends on CRYPTO_DEV_SP_PSP && !(I2C_DESIGNWARE_PLATFORM=y &&
> > > > > CRYPTO_DEV_CCP_DD=m)
> > > > > help
> > > >
> > > > Would this look better if split? I.e.
> > > >
> > > > depends on CRYPTO_DEV_SP_PSP
> > > > depends on !(I2C_DESIGNWARE_PLATFORM=y && CRYPTO_DEV_CCP_DD=m)
> > > Yes, thanks I'll change that for next version.
> >
> > I'm wondering if this is homegrown implementation of 'imply' keyword?
> >
>
> Like this?
>
> config I2C_DESIGNWARE_AMDPSP
> depends on CRYPTO_DEV_SP_PSP
> depends on CRYPTO_DEV_CCP_DD
>
> config CRYPTO_DEV_CCP_DD
> imply I2C_DESIGNWARE_PLATFORM
Looks okay, but I'm not familiar with this code. The documentation about
'imply' can be found here:
https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html#menu-attributes
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 6/6] i2c: designware: Use PCI PSP driver for communication
2023-02-16 20:59 ` Andy Shevchenko
@ 2023-02-16 21:01 ` Limonciello, Mario
2023-02-16 21:16 ` Andy Shevchenko
0 siblings, 1 reply; 24+ messages in thread
From: Limonciello, Mario @ 2023-02-16 21:01 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jarkko Nikula, Jan Dąbroś,
Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Mika Westerberg, linux-i2c, linux-crypto, linux-kernel
On 2/16/2023 14:59, Andy Shevchenko wrote:
> On Thu, Feb 16, 2023 at 02:55:07PM -0600, Limonciello, Mario wrote:
>> On 2/16/2023 08:56, Andy Shevchenko wrote:
>>> On Thu, Feb 16, 2023 at 07:29:53AM -0600, Mario Limonciello wrote:
>>>> On 2/16/23 07:27, Jarkko Nikula wrote:
>>>>> On 2/10/23 00:38, Mario Limonciello wrote:
>
> ...
>
>>>>>> config I2C_DESIGNWARE_AMDPSP
>>>>>> bool "AMD PSP I2C semaphore support"
>>>>>> - depends on X86_MSR
>>>>>> depends on ACPI
>>>>>> depends on I2C_DESIGNWARE_PLATFORM
>>>>>> + depends on CRYPTO_DEV_SP_PSP && !(I2C_DESIGNWARE_PLATFORM=y &&
>>>>>> CRYPTO_DEV_CCP_DD=m)
>>>>>> help
>>>>>
>>>>> Would this look better if split? I.e.
>>>>>
>>>>> depends on CRYPTO_DEV_SP_PSP
>>>>> depends on !(I2C_DESIGNWARE_PLATFORM=y && CRYPTO_DEV_CCP_DD=m)
>>>> Yes, thanks I'll change that for next version.
>>>
>>> I'm wondering if this is homegrown implementation of 'imply' keyword?
>>>
>>
>> Like this?
>>
>> config I2C_DESIGNWARE_AMDPSP
>> depends on CRYPTO_DEV_SP_PSP
>> depends on CRYPTO_DEV_CCP_DD
>>
>> config CRYPTO_DEV_CCP_DD
>> imply I2C_DESIGNWARE_PLATFORM
>
> Looks okay, but I'm not familiar with this code. The documentation about
> 'imply' can be found here:
>
> https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html#menu-attributes
>
>
Yeah I found that, but this was my first time using imply, so I was
hoping someone who has used it could validate I interpreted it correctly.
Following the example CRYPTO_DEV_CCP_DD would be FOO and
I2C_DESIGNWARE_PLATFORM would be BAZ so I thought so.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 6/6] i2c: designware: Use PCI PSP driver for communication
2023-02-16 21:01 ` Limonciello, Mario
@ 2023-02-16 21:16 ` Andy Shevchenko
2023-02-16 21:27 ` Limonciello, Mario
0 siblings, 1 reply; 24+ messages in thread
From: Andy Shevchenko @ 2023-02-16 21:16 UTC (permalink / raw)
To: Limonciello, Mario
Cc: Jarkko Nikula, Jan Dąbroś,
Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Mika Westerberg, linux-i2c, linux-crypto, linux-kernel
On Thu, Feb 16, 2023 at 03:01:35PM -0600, Limonciello, Mario wrote:
> On 2/16/2023 14:59, Andy Shevchenko wrote:
> > On Thu, Feb 16, 2023 at 02:55:07PM -0600, Limonciello, Mario wrote:
> > > On 2/16/2023 08:56, Andy Shevchenko wrote:
> > > > On Thu, Feb 16, 2023 at 07:29:53AM -0600, Mario Limonciello wrote:
> > > > > On 2/16/23 07:27, Jarkko Nikula wrote:
> > > > > > On 2/10/23 00:38, Mario Limonciello wrote:
...
> > > > > > > config I2C_DESIGNWARE_AMDPSP
> > > > > > > bool "AMD PSP I2C semaphore support"
> > > > > > > - depends on X86_MSR
> > > > > > > depends on ACPI
> > > > > > > depends on I2C_DESIGNWARE_PLATFORM
> > > > > > > + depends on CRYPTO_DEV_SP_PSP && !(I2C_DESIGNWARE_PLATFORM=y &&
> > > > > > > CRYPTO_DEV_CCP_DD=m)
> > > > > > > help
> > > > > >
> > > > > > Would this look better if split? I.e.
> > > > > >
> > > > > > depends on CRYPTO_DEV_SP_PSP
> > > > > > depends on !(I2C_DESIGNWARE_PLATFORM=y && CRYPTO_DEV_CCP_DD=m)
> > > > > Yes, thanks I'll change that for next version.
> > > >
> > > > I'm wondering if this is homegrown implementation of 'imply' keyword?
> > >
> > > Like this?
> > >
> > > config I2C_DESIGNWARE_AMDPSP
> > > depends on CRYPTO_DEV_SP_PSP
> > > depends on CRYPTO_DEV_CCP_DD
> > >
> > > config CRYPTO_DEV_CCP_DD
> > > imply I2C_DESIGNWARE_PLATFORM
> >
> > Looks okay, but I'm not familiar with this code. The documentation about
> > 'imply' can be found here:
> >
> > https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html#menu-attributes
>
> Yeah I found that, but this was my first time using imply, so I was hoping
> someone who has used it could validate I interpreted it correctly.
>
> Following the example CRYPTO_DEV_CCP_DD would be FOO and
> I2C_DESIGNWARE_PLATFORM would be BAZ so I thought so.
'imply' == weak 'select', it means that the target option may or may not be
selected. I.o.w. "optional" dependency.
Does CRYPTO_DEV_CCP_DD use I2C DesignWare code?
If I understand correctly the "depends on !(I2C_DESIGNWARE_PLATFORM=y &&
CRYPTO_DEV_CCP_DD=m)" you want to have IS_REACHABLE() in your code and actually
"imply CRYPTO_DEV_CCP_DD" in the I2C_DESIGNWARE_AMDPSP.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 6/6] i2c: designware: Use PCI PSP driver for communication
2023-02-16 21:16 ` Andy Shevchenko
@ 2023-02-16 21:27 ` Limonciello, Mario
2023-02-17 11:05 ` Andy Shevchenko
0 siblings, 1 reply; 24+ messages in thread
From: Limonciello, Mario @ 2023-02-16 21:27 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jarkko Nikula, Jan Dąbroś,
Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Mika Westerberg, linux-i2c, linux-crypto, linux-kernel
On 2/16/2023 15:16, Andy Shevchenko wrote:
> On Thu, Feb 16, 2023 at 03:01:35PM -0600, Limonciello, Mario wrote:
>> On 2/16/2023 14:59, Andy Shevchenko wrote:
>>> On Thu, Feb 16, 2023 at 02:55:07PM -0600, Limonciello, Mario wrote:
>>>> On 2/16/2023 08:56, Andy Shevchenko wrote:
>>>>> On Thu, Feb 16, 2023 at 07:29:53AM -0600, Mario Limonciello wrote:
>>>>>> On 2/16/23 07:27, Jarkko Nikula wrote:
>>>>>>> On 2/10/23 00:38, Mario Limonciello wrote:
>
> ...
>
>>>>>>>> config I2C_DESIGNWARE_AMDPSP
>>>>>>>> bool "AMD PSP I2C semaphore support"
>>>>>>>> - depends on X86_MSR
>>>>>>>> depends on ACPI
>>>>>>>> depends on I2C_DESIGNWARE_PLATFORM
>>>>>>>> + depends on CRYPTO_DEV_SP_PSP && !(I2C_DESIGNWARE_PLATFORM=y &&
>>>>>>>> CRYPTO_DEV_CCP_DD=m)
>>>>>>>> help
>>>>>>>
>>>>>>> Would this look better if split? I.e.
>>>>>>>
>>>>>>> depends on CRYPTO_DEV_SP_PSP
>>>>>>> depends on !(I2C_DESIGNWARE_PLATFORM=y && CRYPTO_DEV_CCP_DD=m)
>>>>>> Yes, thanks I'll change that for next version.
>>>>>
>>>>> I'm wondering if this is homegrown implementation of 'imply' keyword?
>>>>
>>>> Like this?
>>>>
>>>> config I2C_DESIGNWARE_AMDPSP
>>>> depends on CRYPTO_DEV_SP_PSP
>>>> depends on CRYPTO_DEV_CCP_DD
>>>>
>>>> config CRYPTO_DEV_CCP_DD
>>>> imply I2C_DESIGNWARE_PLATFORM
>>>
>>> Looks okay, but I'm not familiar with this code. The documentation about
>>> 'imply' can be found here:
>>>
>>> https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html#menu-attributes
>>
>> Yeah I found that, but this was my first time using imply, so I was hoping
>> someone who has used it could validate I interpreted it correctly.
>>
>> Following the example CRYPTO_DEV_CCP_DD would be FOO and
>> I2C_DESIGNWARE_PLATFORM would be BAZ so I thought so.
>
> 'imply' == weak 'select', it means that the target option may or may not be
> selected. I.o.w. "optional" dependency.
>
> Does CRYPTO_DEV_CCP_DD use I2C DesignWare code?
>
> If I understand correctly the "depends on !(I2C_DESIGNWARE_PLATFORM=y &&
> CRYPTO_DEV_CCP_DD=m)" you want to have IS_REACHABLE() in your code and actually
> "imply CRYPTO_DEV_CCP_DD" in the I2C_DESIGNWARE_AMDPSP.
>
>
Allowing that combination and using IS_REACHABLE means that it's going
to actually load earlier that expected, so I suppose it needs to be
something like this then in the probe code for i2c-designware-amdpsp.c:
if (!IS_REACHABLE()
return -EPROBE_DEFER;
Right?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 6/6] i2c: designware: Use PCI PSP driver for communication
2023-02-16 21:27 ` Limonciello, Mario
@ 2023-02-17 11:05 ` Andy Shevchenko
2023-02-17 11:05 ` Andy Shevchenko
0 siblings, 1 reply; 24+ messages in thread
From: Andy Shevchenko @ 2023-02-17 11:05 UTC (permalink / raw)
To: Limonciello, Mario
Cc: Jarkko Nikula, Jan Dąbroś,
Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Mika Westerberg, linux-i2c, linux-crypto, linux-kernel
On Thu, Feb 16, 2023 at 03:27:35PM -0600, Limonciello, Mario wrote:
> On 2/16/2023 15:16, Andy Shevchenko wrote:
> > On Thu, Feb 16, 2023 at 03:01:35PM -0600, Limonciello, Mario wrote:
> > > On 2/16/2023 14:59, Andy Shevchenko wrote:
> > > > On Thu, Feb 16, 2023 at 02:55:07PM -0600, Limonciello, Mario wrote:
> > > > > On 2/16/2023 08:56, Andy Shevchenko wrote:
> > > > > > On Thu, Feb 16, 2023 at 07:29:53AM -0600, Mario Limonciello wrote:
> > > > > > > On 2/16/23 07:27, Jarkko Nikula wrote:
> > > > > > > > On 2/10/23 00:38, Mario Limonciello wrote:
...
> > > > > > > > Would this look better if split? I.e.
> > > > > > > >
> > > > > > > > depends on CRYPTO_DEV_SP_PSP
> > > > > > > > depends on !(I2C_DESIGNWARE_PLATFORM=y && CRYPTO_DEV_CCP_DD=m)
> > > > > > > Yes, thanks I'll change that for next version.
> > > > > >
> > > > > > I'm wondering if this is homegrown implementation of 'imply' keyword?
> > > > >
> > > > > Like this?
> > > > >
> > > > > config I2C_DESIGNWARE_AMDPSP
> > > > > depends on CRYPTO_DEV_SP_PSP
> > > > > depends on CRYPTO_DEV_CCP_DD
> > > > >
> > > > > config CRYPTO_DEV_CCP_DD
> > > > > imply I2C_DESIGNWARE_PLATFORM
> > > >
> > > > Looks okay, but I'm not familiar with this code. The documentation about
> > > > 'imply' can be found here:
> > > >
> > > > https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html#menu-attributes
> > >
> > > Yeah I found that, but this was my first time using imply, so I was hoping
> > > someone who has used it could validate I interpreted it correctly.
> > >
> > > Following the example CRYPTO_DEV_CCP_DD would be FOO and
> > > I2C_DESIGNWARE_PLATFORM would be BAZ so I thought so.
> >
> > 'imply' == weak 'select', it means that the target option may or may not be
> > selected. I.o.w. "optional" dependency.
> >
> > Does CRYPTO_DEV_CCP_DD use I2C DesignWare code?
> >
> > If I understand correctly the "depends on !(I2C_DESIGNWARE_PLATFORM=y &&
> > CRYPTO_DEV_CCP_DD=m)" you want to have IS_REACHABLE() in your code and actually
> > "imply CRYPTO_DEV_CCP_DD" in the I2C_DESIGNWARE_AMDPSP.
>
> Allowing that combination and using IS_REACHABLE means that it's going to
> actually load earlier that expected, so I suppose it needs to be something
> like this then in the probe code for i2c-designware-amdpsp.c:
>
> if (!IS_REACHABLE()
> return -EPROBE_DEFER;
>
> Right?
Hmm... I'm not sure. IS_REACHABLE() should be done with a compilation
dependencies. What you put here is functional dependency, moreover since
you mentioned the boot / load ordering doesn't it mean that the architecture
of all of this is not good enough and requires some redesign?
Perhaps you need to use component framework actually?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 6/6] i2c: designware: Use PCI PSP driver for communication
2023-02-17 11:05 ` Andy Shevchenko
@ 2023-02-17 11:05 ` Andy Shevchenko
0 siblings, 0 replies; 24+ messages in thread
From: Andy Shevchenko @ 2023-02-17 11:05 UTC (permalink / raw)
To: Limonciello, Mario
Cc: Jarkko Nikula, Jan Dąbroś,
Grzegorz Bernacki, Thomas Rijo-john, Lendacky Thomas, herbert,
Mika Westerberg, linux-i2c, linux-crypto, linux-kernel
On Fri, Feb 17, 2023 at 01:05:03PM +0200, Andy Shevchenko wrote:
> On Thu, Feb 16, 2023 at 03:27:35PM -0600, Limonciello, Mario wrote:
> > On 2/16/2023 15:16, Andy Shevchenko wrote:
> > > On Thu, Feb 16, 2023 at 03:01:35PM -0600, Limonciello, Mario wrote:
> > > > On 2/16/2023 14:59, Andy Shevchenko wrote:
> > > > > On Thu, Feb 16, 2023 at 02:55:07PM -0600, Limonciello, Mario wrote:
> > > > > > On 2/16/2023 08:56, Andy Shevchenko wrote:
> > > > > > > On Thu, Feb 16, 2023 at 07:29:53AM -0600, Mario Limonciello wrote:
> > > > > > > > On 2/16/23 07:27, Jarkko Nikula wrote:
> > > > > > > > > On 2/10/23 00:38, Mario Limonciello wrote:
...
> > > > > > > > > Would this look better if split? I.e.
> > > > > > > > >
> > > > > > > > > depends on CRYPTO_DEV_SP_PSP
> > > > > > > > > depends on !(I2C_DESIGNWARE_PLATFORM=y && CRYPTO_DEV_CCP_DD=m)
> > > > > > > > Yes, thanks I'll change that for next version.
> > > > > > >
> > > > > > > I'm wondering if this is homegrown implementation of 'imply' keyword?
> > > > > >
> > > > > > Like this?
> > > > > >
> > > > > > config I2C_DESIGNWARE_AMDPSP
> > > > > > depends on CRYPTO_DEV_SP_PSP
> > > > > > depends on CRYPTO_DEV_CCP_DD
> > > > > >
> > > > > > config CRYPTO_DEV_CCP_DD
> > > > > > imply I2C_DESIGNWARE_PLATFORM
> > > > >
> > > > > Looks okay, but I'm not familiar with this code. The documentation about
> > > > > 'imply' can be found here:
> > > > >
> > > > > https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html#menu-attributes
> > > >
> > > > Yeah I found that, but this was my first time using imply, so I was hoping
> > > > someone who has used it could validate I interpreted it correctly.
> > > >
> > > > Following the example CRYPTO_DEV_CCP_DD would be FOO and
> > > > I2C_DESIGNWARE_PLATFORM would be BAZ so I thought so.
> > >
> > > 'imply' == weak 'select', it means that the target option may or may not be
> > > selected. I.o.w. "optional" dependency.
> > >
> > > Does CRYPTO_DEV_CCP_DD use I2C DesignWare code?
> > >
> > > If I understand correctly the "depends on !(I2C_DESIGNWARE_PLATFORM=y &&
> > > CRYPTO_DEV_CCP_DD=m)" you want to have IS_REACHABLE() in your code and actually
> > > "imply CRYPTO_DEV_CCP_DD" in the I2C_DESIGNWARE_AMDPSP.
> >
> > Allowing that combination and using IS_REACHABLE means that it's going to
> > actually load earlier that expected, so I suppose it needs to be something
> > like this then in the probe code for i2c-designware-amdpsp.c:
> >
> > if (!IS_REACHABLE()
> > return -EPROBE_DEFER;
> >
> > Right?
>
> Hmm... I'm not sure. IS_REACHABLE() should be done with a compilation
s/with/without/
> dependencies. What you put here is functional dependency, moreover since
> you mentioned the boot / load ordering doesn't it mean that the architecture
> of all of this is not good enough and requires some redesign?
>
> Perhaps you need to use component framework actually?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 24+ messages in thread