[6/6] i2c: designware: Use PCI PSP driver for communication
Commit Message
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(-)
Comments
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.
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)
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.
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?
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
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
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.
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.
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?
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?
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?
@@ -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.
@@ -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);
-}
@@ -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);
@@ -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
{}
@@ -7,6 +7,7 @@
enum psp_platform_access_msg {
PSP_CMD_NONE = 0x0,
+ PSP_I2C_REQ_BUS_CMD = 0x64,
};
struct psp_req_buffer_hdr {