[PATCH] USB: xen-hcd: Traverse host/ when CONFIG_USB_XEN_HCD is selected
If no other USB HCDs are selected when compiling a small pure virutal
machine, the Xen HCD driver cannot be built.
Fix it by traversing down host/ if CONFIG_USB_XEN_HCD is selected.
Fixes: 494ed3997d75 ("usb: Introduce Xen pvUSB frontend (xen hcd)")
Cc: sta...@vger.kernel.org # v5.17+
Signed-off-by: John Ernberg
---
drivers/usb/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 3a9a0dd4be70..949eca0adebe 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_USB_R8A66597_HCD)+= host/
obj-$(CONFIG_USB_FSL_USB2) += host/
obj-$(CONFIG_USB_FOTG210_HCD) += host/
obj-$(CONFIG_USB_MAX3421_HCD) += host/
+obj-$(CONFIG_USB_XEN_HCD) += host/
obj-$(CONFIG_USB_C67X00_HCD) += c67x00/
--
2.45.0
[PATCH] xen/arm: imx8qm: Re-license file to GPL-2.0-only
New contributions are recommended to be under GPL-2.0-only [1], since this code piece originally came from the NXP tree the original license was retained. However, as discussed both Peng [2] and I [3] are ok with GPL-2.0.-only as a license. Change the license. Cc: Peng Fan Link: https://lore.kernel.org/xen-devel/084b9ed5-1585-4802-b504-6ccd2f262...@xen.org/ [1] Link: https://lore.kernel.org/xen-devel/du0pr04mb9417a835b5d04517cc11500788...@du0pr04mb9417.eurprd04.prod.outlook.com/ [2] Link: https://lore.kernel.org/xen-devel/e3785d8a-9b16-4b74-9453-b0166bdbb...@actia.se/ [3] Signed-off-by: John Ernberg --- xen/arch/arm/platforms/imx8qm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/arm/platforms/imx8qm.c b/xen/arch/arm/platforms/imx8qm.c index 3600a073e8..9dac6af425 100644 --- a/xen/arch/arm/platforms/imx8qm.c +++ b/xen/arch/arm/platforms/imx8qm.c @@ -1,4 +1,4 @@ -/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* SPDX-License-Identifier: GPL-2.0-only */ /* * xen/arch/arm/platforms/imx8qm.c * -- 2.44.0
Re: [PATCH v4 1/3] xen/arm: Add imx8q{m,x} platform glue
Hi Julien, On 4/15/24 1:03 PM, Julien Grall wrote: > > > On 15/04/2024 11:50, Andrew Cooper wrote: >> On 15/04/2024 11:25 am, Julien Grall wrote: >>> Hi John, >>> >>> I saw this patch was committed. I have one question this may require >>> some adjustment. >>> >>> On 08/04/2024 17:11, John Ernberg wrote: >>>> --- >>>> xen/arch/arm/platforms/Makefile | 1 + >>>> xen/arch/arm/platforms/imx8qm.c | 139 >>>> >>>> 2 files changed, 140 insertions(+) >>>> create mode 100644 xen/arch/arm/platforms/imx8qm.c >>>> >>>> diff --git a/xen/arch/arm/platforms/Makefile >>>> b/xen/arch/arm/platforms/Makefile >>>> index 8632f4115f..bec6e55d1f 100644 >>>> --- a/xen/arch/arm/platforms/Makefile >>>> +++ b/xen/arch/arm/platforms/Makefile >>>> @@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT) += sunxi.o >>>> obj-$(CONFIG_ALL64_PLAT) += thunderx.o >>>> obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o >>>> obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o >>>> +obj-$(CONFIG_ALL64_PLAT) += imx8qm.o >>>> obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o >>>> obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp-eemi.o >>>> diff --git a/xen/arch/arm/platforms/imx8qm.c >>>> b/xen/arch/arm/platforms/imx8qm.c >>>> new file mode 100644 >>>> index 00..3600a073e8 >>>> --- /dev/null >>>> +++ b/xen/arch/arm/platforms/imx8qm.c >>>> @@ -0,0 +1,139 @@ >>>> +/* SPDX-License-Identifier: GPL-2.0-or-later */ >>> >>> The majority of Xen code is using GPL-2.0-only. In the early days for >>> Xen on Arm we started to use GPLv2+ which I consider it was a mistake. >>> Unfortunately this started to spread as people copied/pasted the same >>> copyright headers. >>> >>> So can you confirm whether you intended to use GPL-2.0+? If not would >>> you be able to send a patch to adjust it? (Better to it before there >>> are more modifications). >> >> Julien: I've called you out multiple times before. > > And there are multiple thread explaining why I am requesting if we can > use GPLv2-only. In fact from CONTRIBUTING: > > The recommended license of a directory will depend on the COPYING file. > If the new file is using a different license, this should be highlighted > and discussed in the commit message or cover letter introducing the > file. > Since part of the code was not written by me, but by Peng, I think both of us need to agree to a license change if one is to be made. I am personally fine with either license. >> Don't ever bully contributors into changing licensing. It is >> unacceptable behaviour, and in most cases - including this one by the >> looks of things - not legal. > > I don't think I have bullied the contributor. I have asked politely > whether it can be done. There is nothing illegal (see above). Just adding: I did not feel bullied here. > > The problematic behavior is you trying to pressure the other people to > accept your point of view by been condescending or insulting them like > you did here. > > I have reported this behavior several times to CoC. And I guess this > need to happen again. > > Cheers, > Best regards // John Ernberg
Re: [PATCH v4 1/3] xen/arm: Add imx8q{m,x} platform glue
On 4/9/24 8:47 AM, Michal Orzel wrote:
> Hi John,
>
> On 08/04/2024 18:11, John Ernberg wrote:
>>
>>
>> When using Linux for dom0 there are a bunch of drivers that need to do SMC
>> SIP calls into the firmware to enable certain hardware bits like the
>> watchdog.
>>
>> Provide a basic platform glue that implements the needed SMC forwarding.
>>
>> The format of these calls are as follows:
>> - reg 0: function ID
>> - reg 1: subfunction ID (when there's a subfunction)
>> remaining regs: args
>>
>> For now we only allow Dom0 to make these calls as they are all managing
>> hardware. There is no specification for these SIP calls, the IDs and names
>> have been extracted from the upstream linux kernel and the vendor kernel.
>>
>> Most of the SIP calls are only available for the iMX8M series of SoCs, so
>> they are easy to reject and they need to be revisited when iMX8M series
>> support is added.
> Stale paragraph. Should be removed given that the driver targets only Q{M,XP}.
>
>>
>> From the other calls we can reject CPUFREQ because Dom0 cannot make an
>> informed decision regarding CPU frequency scaling, WAKEUP_SRC is to wake
>> up from suspend, which Xen doesn't support at this time.
>>
>> This leaves the TIME SIP, OTP SIPs, BUILDINFO SIP and TEMP ALARM SIP, which
>> for now are allowed to Dom0.
> BUILDINFO, TEMP ALARM are leftovers from previous revision.
>
>>
>> NOTE: This code is based on code found in NXP Xen tree located here:
>> https://github.com/nxp-imx/imx-xen/blob/lf-5.10.y_4.13/xen/arch/arm/platforms/imx8qm.c
>>
>> Signed-off-by: Peng Fan
>> [jernberg: Add SIP call filtering]
>> Signed-off-by: John Ernberg
> Reviewed-by: Michal Orzel
>
> The commit msg can be fixed on commit.
>
> ~Michal
Apologies for forgetting to adjust that. Let me know if it's easier for
you if I do a v5 with the fixed commit message.
Thanks! // John Ernberg
[PATCH v4 2/3] xen/drivers: imx-lpuart: Replace iMX8QM compatible with iMX8QXP
Allow the uart to probe also with iMX8QXP. The ip-block is the same as in
the QM.
Since the fsl,imx8qm-lpuart compatible in Linux exists in name only and is
not used in the driver any iMX8QM device tree that can boot Linux must set
fsl,imx8qxp-lpuart compatible as well as the QM one.
Thus we replace the compatible rather than adding just another one.
Signed-off-by: John Ernberg
Acked-by: Julien Grall
---
v4:
- no changes
v3:
- no changes
v2:
- Replace the compatible rather than adding to the list (Julien Grall)
- Reword commit message to reflect the above.
- Collect Julien's ack
---
xen/drivers/char/imx-lpuart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/char/imx-lpuart.c b/xen/drivers/char/imx-lpuart.c
index 7770d158bf..cf034d7ed0 100644
--- a/xen/drivers/char/imx-lpuart.c
+++ b/xen/drivers/char/imx-lpuart.c
@@ -236,7 +236,7 @@ static int __init imx_lpuart_init(struct dt_device_node
*dev,
static const struct dt_device_match imx_lpuart_dt_compat[] __initconst =
{
-DT_MATCH_COMPATIBLE("fsl,imx8qm-lpuart"),
+DT_MATCH_COMPATIBLE("fsl,imx8qxp-lpuart"),
{ /* sentinel */ },
};
--
2.44.0
[PATCH v4 0/3] Xen: ARM: Improved NXP iMX8 platform support
The iMX lpuart driver added at 44e17aa60d47 ("xen/arm: Add i.MX lpuart driver")
is not enough to boot a Linux based dom0 when certain drivers, such as the
watchdog driver, are enabled.
We're also fixing compatibles in imx-lpuart to allow Xen to use the UART
on the QXP variant as well.
When it comes to the watchdog we're currently only implementing the support
for letting Dom0 manage it. There is also a desire for another approach
where Xen kicks the watchdog (dom0-less use-cases etc). This approach is
not covered by this patch set.
v4: (see individual patches for detailed changelog)
- Drop all SIP calls not used by iMX8Q{M,XP} (Michal Orzal)
- Sign off patch 3 (Stefano Stabellini)
v3:
https://lore.kernel.org/xen-devel/20240328163351.64808-1-john.ernb...@actia.se/
- Added a few more SIP calls
- Become a reviewer of IMX8Q{M,XP} related patches (Bertrand Marquis)
v2:
https://lore.kernel.org/xen-devel/20240214160644.3418228-1-john.ernb...@actia.se/
- Added SIP call filtering (Julien Grall)
- Replace lpuart compatible instead (Julien Grall)
v1:
https://lore.kernel.org/xen-devel/20240131114952.305805-1-john.ernb...@actia.se
John Ernberg (3):
xen/arm: Add imx8q{m,x} platform glue
xen/drivers: imx-lpuart: Replace iMX8QM compatible with iMX8QXP
MAINTAINERS: Become a reviewer of iMX8Q{M,XP} related patches
MAINTAINERS | 5 ++
xen/arch/arm/platforms/Makefile | 1 +
xen/arch/arm/platforms/imx8qm.c | 139
xen/drivers/char/imx-lpuart.c | 2 +-
4 files changed, 146 insertions(+), 1 deletion(-)
create mode 100644 xen/arch/arm/platforms/imx8qm.c
--
2.44.0
[PATCH v4 3/3] MAINTAINERS: Become a reviewer of iMX8Q{M,XP} related patches
I have experience with the IMX8QXP, and the supported parts of the IMX8QM are identical. Help review patches touching these areas. Signed-off-by: John Ernberg Acked-by: Stefano Stabellini --- v4: - Properly sign the patch off (Stefano Stabellini) - Pick up Stefano's ack v3: - New patch (Bertrand Marquis) --- MAINTAINERS | 5 + 1 file changed, 5 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 1bd22fd75f..09982241b3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -337,6 +337,11 @@ F: tools/misc/xenhypfs.c F: xen/common/hypfs.c F: xen/include/xen/hypfs.h +IMX8QM/QXP SUPPORT +R: John Ernberg +F: xen/arch/arm/platforms/imx8qm.c +F: xen/drivers/char/imx-lpuart.c + INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT) R: Lukasz Hawrylko R: Daniel P. Smith -- 2.44.0
[PATCH v4 1/3] xen/arm: Add imx8q{m,x} platform glue
When using Linux for dom0 there are a bunch of drivers that need to do SMC
SIP calls into the firmware to enable certain hardware bits like the
watchdog.
Provide a basic platform glue that implements the needed SMC forwarding.
The format of these calls are as follows:
- reg 0: function ID
- reg 1: subfunction ID (when there's a subfunction)
remaining regs: args
For now we only allow Dom0 to make these calls as they are all managing
hardware. There is no specification for these SIP calls, the IDs and names
have been extracted from the upstream linux kernel and the vendor kernel.
Most of the SIP calls are only available for the iMX8M series of SoCs, so
they are easy to reject and they need to be revisited when iMX8M series
support is added.
>From the other calls we can reject CPUFREQ because Dom0 cannot make an
informed decision regarding CPU frequency scaling, WAKEUP_SRC is to wake
up from suspend, which Xen doesn't support at this time.
This leaves the TIME SIP, OTP SIPs, BUILDINFO SIP and TEMP ALARM SIP, which
for now are allowed to Dom0.
NOTE: This code is based on code found in NXP Xen tree located here:
https://github.com/nxp-imx/imx-xen/blob/lf-5.10.y_4.13/xen/arch/arm/platforms/imx8qm.c
Signed-off-by: Peng Fan
[jernberg: Add SIP call filtering]
Signed-off-by: John Ernberg
---
v4:
- Fix coding style problems added in v3 (Michal Orzel)
- Remove all calls not currently used by Linux on imx8q{m,xp} (Michal Orzel)
- Fix {g,}printk inconsistencies, prefer gprintk (Michal Orzel)
v3:
- Adhere to style guidelines for line length and label indentation (Michal
Orzel)
- Use smccc macros to build the SIP function identifier (Michal Orzel)
- Adjust platform name to be specific to QM and QXP variants (Michal Orzel)
- Pick up additional SIPs which may be used by other Linux versions (Michal
Orzel)
- Changes to the commit message due to above
v2:
- Reword the commit message to be a bit clearer
- Include the link previously added as a context note to the commit message
(Julien Grall)
- Add Pengs signed off (Julien Grall, Peng Fan)
- Add basic SIP call filter (Julien Grall)
- Expand the commit message a whole bunch because of the changes to the code
---
xen/arch/arm/platforms/Makefile | 1 +
xen/arch/arm/platforms/imx8qm.c | 139
2 files changed, 140 insertions(+)
create mode 100644 xen/arch/arm/platforms/imx8qm.c
diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 8632f4115f..bec6e55d1f 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT) += sunxi.o
obj-$(CONFIG_ALL64_PLAT) += thunderx.o
obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o
obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o
+obj-$(CONFIG_ALL64_PLAT) += imx8qm.o
obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o
obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp-eemi.o
diff --git a/xen/arch/arm/platforms/imx8qm.c b/xen/arch/arm/platforms/imx8qm.c
new file mode 100644
index 00..3600a073e8
--- /dev/null
+++ b/xen/arch/arm/platforms/imx8qm.c
@@ -0,0 +1,139 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * xen/arch/arm/platforms/imx8qm.c
+ *
+ * i.MX 8QM setup
+ *
+ * Copyright (c) 2016 Freescale Inc.
+ * Copyright 2018-2019 NXP
+ *
+ *
+ * Peng Fan
+ */
+
+#include
+#include
+#include
+
+static const char * const imx8qm_dt_compat[] __initconst =
+{
+"fsl,imx8qm",
+"fsl,imx8qxp",
+NULL
+};
+
+#define IMX_SIP_FID(fid) \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_CONV_64, \
+ ARM_SMCCC_OWNER_SIP, \
+ (fid))
+
+#define IMX_SIP_F_CPUFREQ0x1
+#define IMX_SIP_F_TIME 0x2
+#define IMX_SIP_F_WAKEUP_SRC 0x9
+#define IMX_SIP_F_OTP_WRITE 0xB
+
+#define IMX_SIP_TIME_SF_RTC_SET_TIME 0x00
+#define IMX_SIP_TIME_SF_WDOG_START 0x01
+#define IMX_SIP_TIME_SF_WDOG_STOP0x02
+#define IMX_SIP_TIME_SF_WDOG_SET_ACT 0x03
+#define IMX_SIP_TIME_SF_WDOG_PING0x04
+#define IMX_SIP_TIME_SF_WDOG_SET_TIMEOUT 0x05
+#define IMX_SIP_TIME_SF_WDOG_GET_STAT0x06
+#define IMX_SIP_TIME_SF_WDOG_SET_PRETIME 0x07
+
+static bool imx8qm_is_sip_time_call_ok(uint32_t subfunction_id)
+{
+switch ( subfunction_id )
+{
+case IMX_SIP_TIME_SF_RTC_SET_TIME:
+return true;
+case IMX_SIP_TIME_SF_WDOG_START:
+case IMX_SIP_TIME_SF_WDOG_STOP:
+case IMX_SIP_TIME_SF_WDOG_SET_ACT:
+case IMX_SIP_TIME_SF_WDOG_PING:
+case IMX_SIP_TIME_SF_WDOG_SET_TIMEOUT:
+case IMX_SIP_TIME_SF_WDOG_GET_STAT:
+case IMX_SIP_TIME_SF_WDOG_SET_PRETIME:
+return true;
+default:
+gprintk(XENLOG_WARNING, "imx8qm: smc: time: Unknown subfunction id
%x\n",
+subfunction_id);
+return false;
+}
+}
+
+static bool imx8qm_smc(struct cpu_user_regs *regs)
+{
+uint32_t function_id = get
Re: [PATCH v3 1/3] xen/arm: Add imx8q{m,x} platform glue
Hi Michel,
Apologies for the slow reply.
On 4/2/24 9:24 AM, Michal Orzel wrote:
> Hi John,
>
> On 28/03/2024 17:34, John Ernberg wrote:
>>
>>
>> When using Linux for dom0 there are a bunch of drivers that need to do SMC
>> SIP calls into the firmware to enable certain hardware bits like the
>> watchdog.
>>
>> Provide a basic platform glue that implements the needed SMC forwarding.
>>
>> The format of these calls are as follows:
>> - reg 0: function ID
>> - reg 1: subfunction ID (when there's a subfunction)
>> remaining regs: args
>>
>> For now we only allow Dom0 to make these calls as they are all managing
>> hardware. There is no specification for these SIP calls, the IDs and names
>> have been extracted from the upstream linux kernel and the vendor kernel.
>>
>> Most of the SIP calls are only available for the iMX8M series of SoCs, so
>> they are easy to reject and they need to be revisited when iMX8M series
>> support is added.
> I just realized that you pinged me in v2 for clarification, sorry I missed
> that.
> I still believe we shouldn't list FIDs that are meant for IMX8M, given that
> the driver is written for IMX8QM/QXP.
Ack. Will take them all out and only add the known required set.
>
>>
>> From the other calls we can reject CPUFREQ because Dom0 cannot make an
>> informed decision regarding CPU frequency scaling, WAKEUP_SRC is to wake
>> up from suspend, which Xen doesn't support at this time.
>>
>> This leaves the TIME SIP, OTP SIPs, BUILDINFO SIP and TEMP ALARM SIP, which
>> for now are allowed to Dom0.
>>
>> NOTE: This code is based on code found in NXP Xen tree located here:
>> https://github.com/nxp-imx/imx-xen/blob/lf-5.10.y_4.13/xen/arch/arm/platforms/imx8qm.c
>>
>> Signed-off-by: Peng Fan
>> [jernberg: Add SIP call filtering]
>> Signed-off-by: John Ernberg
>>
>> ---
>>
>> v3:
>> - Adhere to style guidelines for line length and label indentation (Michal
>> Orzel)
>> - Use smccc macros to build the SIP function identifier (Michal Orzel)
>> - Adjust platform name to be specific to QM and QXP variants (Michal Orzel)
>> - Pick up additional SIPs which may be used by other Linux versions - for
>> review purposes
>> - Changes to the commit message due to above
>>
>> v2:
>> - Reword the commit message to be a bit clearer
>> - Include the link previously added as a context note to the commit
>> message (Julien Grall)
>> - Add Pengs signed off (Julien Grall, Peng Fan)
>> - Add basic SIP call filter (Julien Grall)
>> - Expand the commit message a whole bunch because of the changes to the
>> code
>> ---
>> xen/arch/arm/platforms/Makefile | 1 +
>> xen/arch/arm/platforms/imx8qm.c | 168
>> 2 files changed, 169 insertions(+)
>> create mode 100644 xen/arch/arm/platforms/imx8qm.c
>>
>> diff --git a/xen/arch/arm/platforms/Makefile
>> b/xen/arch/arm/platforms/Makefile
>> index 8632f4115f..bec6e55d1f 100644
>> --- a/xen/arch/arm/platforms/Makefile
>> +++ b/xen/arch/arm/platforms/Makefile
>> @@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT) += sunxi.o
>> obj-$(CONFIG_ALL64_PLAT) += thunderx.o
>> obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o
>> obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o
>> +obj-$(CONFIG_ALL64_PLAT) += imx8qm.o
>> obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o
>> obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp-eemi.o
>> diff --git a/xen/arch/arm/platforms/imx8qm.c
>> b/xen/arch/arm/platforms/imx8qm.c
>> new file mode 100644
>> index 00..0992475474
>> --- /dev/null
>> +++ b/xen/arch/arm/platforms/imx8qm.c
>> @@ -0,0 +1,168 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>> +/*
>> + * xen/arch/arm/platforms/imx8qm.c
>> + *
>> + * i.MX 8QM setup
>> + *
>> + * Copyright (c) 2016 Freescale Inc.
>> + * Copyright 2018-2019 NXP
>> + *
>> + *
>> + * Peng Fan
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +static const char * const imx8qm_dt_compat[] __initconst =
>> +{
>> +"fsl,imx8qm",
>> +"fsl,imx8qxp",
>> +NULL
>> +};
>> +
>> +#define IMX_SIP_FID(fid) \
>> +ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
>> + ARM_SMCCC_CONV_64, \
>> + ARM_SMCCC_OWNER_SIP, \
>> + fid)
> macro parameter should be enclosed with
[PATCH v3 2/3] xen/drivers: imx-lpuart: Replace iMX8QM compatible with iMX8QXP
Allow the uart to probe also with iMX8QXP. The ip-block is the same as in
the QM.
Since the fsl,imx8qm-lpuart compatible in Linux exists in name only and is
not used in the driver any iMX8QM device tree that can boot Linux must set
fsl,imx8qxp-lpuart compatible as well as the QM one.
Thus we replace the compatible rather than adding just another one.
Signed-off-by: John Ernberg
Acked-by: Julien Grall
---
v3:
- no changes
v2:
- Replace the compatible rather than adding to the list (Julien Grall)
- Reword commit message to reflect the above.
- Collect Julien's ack
---
xen/drivers/char/imx-lpuart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/char/imx-lpuart.c b/xen/drivers/char/imx-lpuart.c
index 522680a25c..9d0e0871f7 100644
--- a/xen/drivers/char/imx-lpuart.c
+++ b/xen/drivers/char/imx-lpuart.c
@@ -255,7 +255,7 @@ static int __init imx_lpuart_init(struct dt_device_node
*dev,
static const struct dt_device_match imx_lpuart_dt_compat[] __initconst =
{
-DT_MATCH_COMPATIBLE("fsl,imx8qm-lpuart"),
+DT_MATCH_COMPATIBLE("fsl,imx8qxp-lpuart"),
{ /* sentinel */ },
};
--
2.44.0
[PATCH v3 0/2] Xen: ARM: Improved NXP iMX8 platform support
The iMX lpuart driver added at 44e17aa60d47 ("xen/arm: Add i.MX lpuart driver")
is not enough to boot a Linux based dom0 when certain drivers, such as the
watchdog driver, are enabled.
We're also fixing compatibles in imx-lpuart to allow Xen to use the UART
on the QXP variant as well.
When it comes to the watchdog we're currently only implementing the support
for letting Dom0 manage it. There is also a desire for another approach
where Xen kicks the watchdog (dom0-less use-cases etc). This approach is
not covered by this patch set.
NOTE: There is still an open point about the iMX8M* related SIP calls in
the driver and the value of documenting them. There was also a few other
calls noted that weren't implemented because Linux today aren't using them.
I added these as they were part of the discussion if they should be
documented or not.
v3: (see individual patches for detailed changelog)
- Added a few more SIP calls
- Become a reviewer of IMX8Q{M,XP} related patches (Bertrand Marquis)
v2:
https://lore.kernel.org/xen-devel/20240214160644.3418228-1-john.ernb...@actia.se/
- Added SIP call filtering (Julien Grall)
- Replace lpuart compatible instead (Julien Grall)
v1:
https://lore.kernel.org/xen-devel/20240131114952.305805-1-john.ernb...@actia.se
John Ernberg (3):
xen/arm: Add imx8q{m,x} platform glue
xen/drivers: imx-lpuart: Replace iMX8QM compatible with iMX8QXP
MAINTAINERS: Become a reviewer of iMX8Q{M,XP} related patches
MAINTAINERS | 5 +
xen/arch/arm/platforms/Makefile | 1 +
xen/arch/arm/platforms/imx8qm.c | 168
xen/drivers/char/imx-lpuart.c | 2 +-
4 files changed, 175 insertions(+), 1 deletion(-)
create mode 100644 xen/arch/arm/platforms/imx8qm.c
--
2.44.0
[PATCH v3 3/3] MAINTAINERS: Become a reviewer of iMX8Q{M,XP} related patches
I have experience with the IMX8QXP, and the supported parts of the IMX8QM are identical. Help review patches touching these areas. --- v3: - New patch (Bertrand Marquis) --- MAINTAINERS | 5 + 1 file changed, 5 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 1bd22fd75f..09982241b3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -337,6 +337,11 @@ F: tools/misc/xenhypfs.c F: xen/common/hypfs.c F: xen/include/xen/hypfs.h +IMX8QM/QXP SUPPORT +R: John Ernberg +F: xen/arch/arm/platforms/imx8qm.c +F: xen/drivers/char/imx-lpuart.c + INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT) R: Lukasz Hawrylko R: Daniel P. Smith -- 2.44.0
[PATCH v3 1/3] xen/arm: Add imx8q{m,x} platform glue
When using Linux for dom0 there are a bunch of drivers that need to do SMC
SIP calls into the firmware to enable certain hardware bits like the
watchdog.
Provide a basic platform glue that implements the needed SMC forwarding.
The format of these calls are as follows:
- reg 0: function ID
- reg 1: subfunction ID (when there's a subfunction)
remaining regs: args
For now we only allow Dom0 to make these calls as they are all managing
hardware. There is no specification for these SIP calls, the IDs and names
have been extracted from the upstream linux kernel and the vendor kernel.
Most of the SIP calls are only available for the iMX8M series of SoCs, so
they are easy to reject and they need to be revisited when iMX8M series
support is added.
>From the other calls we can reject CPUFREQ because Dom0 cannot make an
informed decision regarding CPU frequency scaling, WAKEUP_SRC is to wake
up from suspend, which Xen doesn't support at this time.
This leaves the TIME SIP, OTP SIPs, BUILDINFO SIP and TEMP ALARM SIP, which
for now are allowed to Dom0.
NOTE: This code is based on code found in NXP Xen tree located here:
https://github.com/nxp-imx/imx-xen/blob/lf-5.10.y_4.13/xen/arch/arm/platforms/imx8qm.c
Signed-off-by: Peng Fan
[jernberg: Add SIP call filtering]
Signed-off-by: John Ernberg
---
v3:
- Adhere to style guidelines for line length and label indentation (Michal
Orzel)
- Use smccc macros to build the SIP function identifier (Michal Orzel)
- Adjust platform name to be specific to QM and QXP variants (Michal Orzel)
- Pick up additional SIPs which may be used by other Linux versions - for
review purposes
- Changes to the commit message due to above
v2:
- Reword the commit message to be a bit clearer
- Include the link previously added as a context note to the commit message
(Julien Grall)
- Add Pengs signed off (Julien Grall, Peng Fan)
- Add basic SIP call filter (Julien Grall)
- Expand the commit message a whole bunch because of the changes to the code
---
xen/arch/arm/platforms/Makefile | 1 +
xen/arch/arm/platforms/imx8qm.c | 168
2 files changed, 169 insertions(+)
create mode 100644 xen/arch/arm/platforms/imx8qm.c
diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 8632f4115f..bec6e55d1f 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT) += sunxi.o
obj-$(CONFIG_ALL64_PLAT) += thunderx.o
obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o
obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o
+obj-$(CONFIG_ALL64_PLAT) += imx8qm.o
obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o
obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp-eemi.o
diff --git a/xen/arch/arm/platforms/imx8qm.c b/xen/arch/arm/platforms/imx8qm.c
new file mode 100644
index 00..0992475474
--- /dev/null
+++ b/xen/arch/arm/platforms/imx8qm.c
@@ -0,0 +1,168 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * xen/arch/arm/platforms/imx8qm.c
+ *
+ * i.MX 8QM setup
+ *
+ * Copyright (c) 2016 Freescale Inc.
+ * Copyright 2018-2019 NXP
+ *
+ *
+ * Peng Fan
+ */
+
+#include
+#include
+#include
+
+static const char * const imx8qm_dt_compat[] __initconst =
+{
+"fsl,imx8qm",
+"fsl,imx8qxp",
+NULL
+};
+
+#define IMX_SIP_FID(fid) \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_CONV_64, \
+ ARM_SMCCC_OWNER_SIP, \
+ fid)
+
+#define IMX_SIP_F_GPC0x
+#define IMX_SIP_F_CPUFREQ0x0001
+#define IMX_SIP_F_TIME 0x0002
+#define IMX_SIP_F_BUILDINFO 0x0003
+#define IMX_SIP_F_DDR_DVFS 0x0004
+#define IMX_SIP_F_SRC0x0005
+#define IMX_SIP_F_GET_SOC_INFO 0x0006
+#define IMX_SIP_F_NOC0x0008
+#define IMX_SIP_F_WAKEUP_SRC 0x0009
+#define IMX_SIP_F_OTP_READ 0x000A
+#define IMX_SIP_F_OTP_WRITE 0x000B
+#define IMX_SIP_F_SET_TEMP_ALARM 0x000C
+
+#define IMX_SIP_TIME_SF_RTC_SET_TIME 0x00
+#define IMX_SIP_TIME_SF_WDOG_START 0x01
+#define IMX_SIP_TIME_SF_WDOG_STOP0x02
+#define IMX_SIP_TIME_SF_WDOG_SET_ACT 0x03
+#define IMX_SIP_TIME_SF_WDOG_PING0x04
+#define IMX_SIP_TIME_SF_WDOG_SET_TIMEOUT 0x05
+#define IMX_SIP_TIME_SF_WDOG_GET_STAT0x06
+#define IMX_SIP_TIME_SF_WDOG_SET_PRETIME 0x07
+
+static bool imx8qm_is_sip_time_call_ok(uint32_t subfunction_id)
+{
+switch ( subfunction_id )
+{
+case IMX_SIP_TIME_SF_RTC_SET_TIME:
+return true;
+case IMX_SIP_TIME_SF_WDOG_START:
+case IMX_SIP_TIME_SF_WDOG_STOP:
+case IMX_SIP_TIME_SF_WDOG_SET_ACT:
+case IMX_SIP_TIME_SF_WDOG_PING:
+case IMX_SIP_TIME_SF_WDOG_SET_TIMEOUT:
+case IMX_SIP_TIME_SF_WDOG_GET_STAT:
+case IMX_SIP_TIME_SF_WDOG_SET_PRETIME:
+return true;
+default:
+printk(XENLOG_WARNING "imx8qm: smc: time: Unknown subfunction id %x\n",
+ subfu
Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Hi Bertrand, On 3/21/24 17:15, Bertrand Marquis wrote: > Hi John, > >> On 21 Mar 2024, at 17:05, John Ernberg wrote: >> >> Hi Bertrand, >> >> On 3/21/24 08:41, Bertrand Marquis wrote: >>> Hi, >>> >>>> On 20 Mar 2024, at 18:40, Julien Grall wrote: >>>> >>>> Hi John, >>>> >>>> On 20/03/2024 16:24, John Ernberg wrote: >>>>> Hi Bertrand, >>>>> On 3/13/24 11:07, Bertrand Marquis wrote: >>>>>> Hi, >>>>>> >>>>>>> On 8 Mar 2024, at 15:04, Julien Grall wrote: >>>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> Thank you for the reply. >>>>>>> >>>>>>> On 08/03/2024 13:40, John Ernberg wrote: >>>>>>>> On 3/7/24 00:07, Julien Grall wrote: >>>>>>>>>> Ping on the watchdog discussion bits. >>>>>>>>> >>>>>>>>> Sorry for the late reply. >>>>>>>>> >>>>>>>>> On 06/03/2024 13:13, John Ernberg wrote: >>>>>>>>>> On 2/9/24 14:14, John Ernberg wrote: >>>>>>>>>>> >>>>>>>>>>>> * IMX_SIP_TIMER_*: This seems to be related to the watchdog. >>>>>>>>>>>> Shouldn't dom0 rely on the watchdog provided by Xen instead? So >>>>>>>>>>>> those >>>>>>>>>>>> call will be used by Xen. >>>>>>>>>>> >>>>>>>>>>> That is indeed a watchdog SIP, and also for setting the SoC >>>>>>>>>>> internal RTC >>>>>>>>>>> if it is being used. >>>>>>>>>>> >>>>>>>>>>> I looked around if there was previous discussion and only really >>>>>>>>>>> found [3]. >>>>>>>>>>> Is the xen/xen/include/watchdog.h header meant to be for this kind >>>>>>>>>>> of >>>>>>>>>>> watchdog support or is that more for the VM watchdog? Looking at >>>>>>>>>>> the x86 >>>>>>>>>>> ACPI NMI watchdog it seems like the former, but I have never worked >>>>>>>>>>> with >>>>>>>>>>> x86 nor ACPI. >>>>>>>>> >>>>>>>>> include/watchdog.h contains helper to configure the watchdog for Xen. >>>>>>>>> We >>>>>>>>> also have per-VM watchdog and this is configured by the hypercall >>>>>>>>> SCHEDOP_watchdog. >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Currently forwarding it to Dom0 has not caused any watchdog resets >>>>>>>>>>> with >>>>>>>>>>> our watchdog timeout settings, our specific Dom0 setup and VM count. >>>>>>>>> >>>>>>>>> IIUC, the SMC API for the watchdog would be similar to the ACPI NMI >>>>>>>>> watchdog. So I think it would make more sense if this is not exposed >>>>>>>>> to >>>>>>>>> dom0 (even if Xen is doing nothing with it). >>>>>>>>> >>>>>>>>> Can you try to hide the SMCs and check if dom0 still behave properly? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>> This SMC manages a hardware watchdog, if it's not pinged within a >>>>>>>> specific interval the entire board resets. >>>>>>> >>>>>>> Do you know what's the default interval? Is it large enough so Xen + >>>>>>> dom0 can boot (at least up to when the watchdog driver is initialized)? >>>>>>> >>>>>>>> If I block the SMCs the watchdog driver in Dom0 will fail to ping the >>>>>>>> watchdog, triggering a board reset because the system looks to have >>>>>>>> become unresponsive. The reason this patch set started is because we >>>>>>>> couldn't ping the watchdog when running with Xen. >>>>>>>> In our specifi
Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Hi Bertrand, On 3/21/24 08:41, Bertrand Marquis wrote: > Hi, > >> On 20 Mar 2024, at 18:40, Julien Grall wrote: >> >> Hi John, >> >> On 20/03/2024 16:24, John Ernberg wrote: >>> Hi Bertrand, >>> On 3/13/24 11:07, Bertrand Marquis wrote: >>>> Hi, >>>> >>>>> On 8 Mar 2024, at 15:04, Julien Grall wrote: >>>>> >>>>> Hi John, >>>>> >>>>> Thank you for the reply. >>>>> >>>>> On 08/03/2024 13:40, John Ernberg wrote: >>>>>> On 3/7/24 00:07, Julien Grall wrote: >>>>>>>> Ping on the watchdog discussion bits. >>>>>>> >>>>>>> Sorry for the late reply. >>>>>>> >>>>>>> On 06/03/2024 13:13, John Ernberg wrote: >>>>>>>> On 2/9/24 14:14, John Ernberg wrote: >>>>>>>>> >>>>>>>>>> * IMX_SIP_TIMER_*: This seems to be related to the watchdog. >>>>>>>>>> Shouldn't dom0 rely on the watchdog provided by Xen instead? So those >>>>>>>>>> call will be used by Xen. >>>>>>>>> >>>>>>>>> That is indeed a watchdog SIP, and also for setting the SoC internal >>>>>>>>> RTC >>>>>>>>> if it is being used. >>>>>>>>> >>>>>>>>> I looked around if there was previous discussion and only really >>>>>>>>> found [3]. >>>>>>>>> Is the xen/xen/include/watchdog.h header meant to be for this kind of >>>>>>>>> watchdog support or is that more for the VM watchdog? Looking at the >>>>>>>>> x86 >>>>>>>>> ACPI NMI watchdog it seems like the former, but I have never worked >>>>>>>>> with >>>>>>>>> x86 nor ACPI. >>>>>>> >>>>>>> include/watchdog.h contains helper to configure the watchdog for Xen. We >>>>>>> also have per-VM watchdog and this is configured by the hypercall >>>>>>> SCHEDOP_watchdog. >>>>>>> >>>>>>>>> >>>>>>>>> Currently forwarding it to Dom0 has not caused any watchdog resets >>>>>>>>> with >>>>>>>>> our watchdog timeout settings, our specific Dom0 setup and VM count. >>>>>>> >>>>>>> IIUC, the SMC API for the watchdog would be similar to the ACPI NMI >>>>>>> watchdog. So I think it would make more sense if this is not exposed to >>>>>>> dom0 (even if Xen is doing nothing with it). >>>>>>> >>>>>>> Can you try to hide the SMCs and check if dom0 still behave properly? >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>> This SMC manages a hardware watchdog, if it's not pinged within a >>>>>> specific interval the entire board resets. >>>>> >>>>> Do you know what's the default interval? Is it large enough so Xen + dom0 >>>>> can boot (at least up to when the watchdog driver is initialized)? >>>>> >>>>>> If I block the SMCs the watchdog driver in Dom0 will fail to ping the >>>>>> watchdog, triggering a board reset because the system looks to have >>>>>> become unresponsive. The reason this patch set started is because we >>>>>> couldn't ping the watchdog when running with Xen. >>>>>> In our specific system the bootloader enables the watchdog as early as >>>>>> possible so that we can get watchdog protection for as much of the boot >>>>>> as we possibly can. >>>>>> So, if we are to block the SMC from Dom0, then Xen needs to take over >>>>>> the pinging. It could be implemented similarly to the NMI watchdog, >>>>>> except that the system will reset if the ping is missed rather than >>>>>> backtrace. >>>>>> It would also mean that Xen will get a whole watchdog driver-category >>>>>> due to the watchdog being vendor and sometimes even SoC specific when it >>>>>> comes to Arm. >>>>>> My understanding of the domain watchdog code is that today the domain >>>>>> needs to call SCHEDOP_watchdog at
Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Hi Bertrand, On 3/13/24 11:07, Bertrand Marquis wrote: > Hi, > >> On 8 Mar 2024, at 15:04, Julien Grall wrote: >> >> Hi John, >> >> Thank you for the reply. >> >> On 08/03/2024 13:40, John Ernberg wrote: >>> On 3/7/24 00:07, Julien Grall wrote: >>>> > Ping on the watchdog discussion bits. >>>> >>>> Sorry for the late reply. >>>> >>>> On 06/03/2024 13:13, John Ernberg wrote: >>>>> On 2/9/24 14:14, John Ernberg wrote: >>>>>> >>>>>>> * IMX_SIP_TIMER_*: This seems to be related to the watchdog. >>>>>>> Shouldn't dom0 rely on the watchdog provided by Xen instead? So those >>>>>>> call will be used by Xen. >>>>>> >>>>>> That is indeed a watchdog SIP, and also for setting the SoC internal RTC >>>>>> if it is being used. >>>>>> >>>>>> I looked around if there was previous discussion and only really >>>>>> found [3]. >>>>>> Is the xen/xen/include/watchdog.h header meant to be for this kind of >>>>>> watchdog support or is that more for the VM watchdog? Looking at the x86 >>>>>> ACPI NMI watchdog it seems like the former, but I have never worked with >>>>>> x86 nor ACPI. >>>> >>>> include/watchdog.h contains helper to configure the watchdog for Xen. We >>>> also have per-VM watchdog and this is configured by the hypercall >>>> SCHEDOP_watchdog. >>>> >>>>>> >>>>>> Currently forwarding it to Dom0 has not caused any watchdog resets with >>>>>> our watchdog timeout settings, our specific Dom0 setup and VM count. >>>> >>>> IIUC, the SMC API for the watchdog would be similar to the ACPI NMI >>>> watchdog. So I think it would make more sense if this is not exposed to >>>> dom0 (even if Xen is doing nothing with it). >>>> >>>> Can you try to hide the SMCs and check if dom0 still behave properly? >>>> >>>> Cheers, >>>> >>> This SMC manages a hardware watchdog, if it's not pinged within a >>> specific interval the entire board resets. >> >> Do you know what's the default interval? Is it large enough so Xen + dom0 >> can boot (at least up to when the watchdog driver is initialized)? >> >>> If I block the SMCs the watchdog driver in Dom0 will fail to ping the >>> watchdog, triggering a board reset because the system looks to have >>> become unresponsive. The reason this patch set started is because we >>> couldn't ping the watchdog when running with Xen. >>> In our specific system the bootloader enables the watchdog as early as >>> possible so that we can get watchdog protection for as much of the boot >>> as we possibly can. >>> So, if we are to block the SMC from Dom0, then Xen needs to take over >>> the pinging. It could be implemented similarly to the NMI watchdog, >>> except that the system will reset if the ping is missed rather than >>> backtrace. >>> It would also mean that Xen will get a whole watchdog driver-category >>> due to the watchdog being vendor and sometimes even SoC specific when it >>> comes to Arm. >>> My understanding of the domain watchdog code is that today the domain >>> needs to call SCHEDOP_watchdog at least once to start the watchdog >>> timer. Since watchdog protection through the whole boot process is >>> desirable we'd need some core changes, such as an option to start the >>> domain watchdog on init. > >>> It's quite a big change to make >> >> For clarification, above you seem to mention two changes: >> >> 1) Allow Xen to use the HW watchdog >> 2) Allow the domain to use the watchdog early >> >> I am assuming by big change, you are referring to 2? >> >> , while I am not against doing it if it >>> makes sense, I now wonder if Xen should manage hardware watchdogs. >>> Looking at the domain watchdog code it looks like if a domain does not >>> get enough execution time, the watchdog will not be pinged enough and >>> the guest will be reset. So either watchdog approach requires Dom0 to >>> get execution time. Dom0 also needs to service all the PV backends it's >>> responsible for. I'm not sure it's valuable to add another layer of >>> watchdog for this scenario as the end result (checking that the entire >>> system works) is ach
Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Hi Julien, On 3/8/24 15:04, Julien Grall wrote: > Hi John, > > Thank you for the reply. > > On 08/03/2024 13:40, John Ernberg wrote: >> On 3/7/24 00:07, Julien Grall wrote: >>> > Ping on the watchdog discussion bits. >>> >>> Sorry for the late reply. >>> >>> On 06/03/2024 13:13, John Ernberg wrote: >>>> On 2/9/24 14:14, John Ernberg wrote: >>>>> >>>>>> * IMX_SIP_TIMER_*: This seems to be related to the watchdog. >>>>>> Shouldn't dom0 rely on the watchdog provided by Xen instead? So those >>>>>> call will be used by Xen. >>>>> >>>>> That is indeed a watchdog SIP, and also for setting the SoC >>>>> internal RTC >>>>> if it is being used. >>>>> >>>>> I looked around if there was previous discussion and only really >>>>> found [3]. >>>>> Is the xen/xen/include/watchdog.h header meant to be for this kind of >>>>> watchdog support or is that more for the VM watchdog? Looking at >>>>> the x86 >>>>> ACPI NMI watchdog it seems like the former, but I have never worked >>>>> with >>>>> x86 nor ACPI. >>> >>> include/watchdog.h contains helper to configure the watchdog for Xen. We >>> also have per-VM watchdog and this is configured by the hypercall >>> SCHEDOP_watchdog. >>> >>>>> >>>>> Currently forwarding it to Dom0 has not caused any watchdog resets >>>>> with >>>>> our watchdog timeout settings, our specific Dom0 setup and VM count. >>> >>> IIUC, the SMC API for the watchdog would be similar to the ACPI NMI >>> watchdog. So I think it would make more sense if this is not exposed to >>> dom0 (even if Xen is doing nothing with it). >>> >>> Can you try to hide the SMCs and check if dom0 still behave properly? >>> >>> Cheers, >>> >> >> This SMC manages a hardware watchdog, if it's not pinged within a >> specific interval the entire board resets. > > Do you know what's the default interval? Is it large enough so Xen + > dom0 can boot (at least up to when the watchdog driver is initialized)? > >> >> If I block the SMCs the watchdog driver in Dom0 will fail to ping the >> watchdog, triggering a board reset because the system looks to have >> become unresponsive. The reason this patch set started is because we >> couldn't ping the watchdog when running with Xen. >> >> In our specific system the bootloader enables the watchdog as early as >> possible so that we can get watchdog protection for as much of the boot >> as we possibly can. >> >> So, if we are to block the SMC from Dom0, then Xen needs to take over >> the pinging. It could be implemented similarly to the NMI watchdog, >> except that the system will reset if the ping is missed rather than >> backtrace. >> It would also mean that Xen will get a whole watchdog driver-category >> due to the watchdog being vendor and sometimes even SoC specific when it >> comes to Arm. >> >> My understanding of the domain watchdog code is that today the domain >> needs to call SCHEDOP_watchdog at least once to start the watchdog >> timer. Since watchdog protection through the whole boot process is >> desirable we'd need some core changes, such as an option to start the >> domain watchdog on init. > >> It's quite a big change to make > > For clarification, above you seem to mention two changes: > > 1) Allow Xen to use the HW watchdog > 2) Allow the domain to use the watchdog early > > I am assuming by big change, you are referring to 2? Both of them. I'm expecting the addition of a new driver category (hardware watchdog) to be a decent amount of work as well. > > , while I am not against doing it if it >> makes sense, I now wonder if Xen should manage hardware watchdogs. >> Looking at the domain watchdog code it looks like if a domain does not >> get enough execution time, the watchdog will not be pinged enough and >> the guest will be reset. So either watchdog approach requires Dom0 to >> get execution time. Dom0 also needs to service all the PV backends it's >> responsible for. I'm not sure it's valuable to add another layer of >> watchdog for this scenario as the end result (checking that the entire >> system works) is achieved without it as well. >> >> So, before I try to find the time to make a proposal for moving the >> hardware watchdog bit to Xen, do we really want it? > > Thanks for the details. Given that the watchdog is enabled by the > bootloader, I think we want Xen to drive the watchdog for two reasons: > 1) In true dom0less environment, dom0 would not exist > 2) You are relying on Xen + Dom0 to boot (or at least enough to get > the watchdog working) within the watchdog interval. > > Let see what the other Arm maintainer thinks. > Regards // John Ernberg
Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Hi Julien, On 3/7/24 00:07, Julien Grall wrote: > Hi John, > > > Ping on the watchdog discussion bits. > > Sorry for the late reply. > > On 06/03/2024 13:13, John Ernberg wrote: >> On 2/9/24 14:14, John Ernberg wrote: >>> >>>> * IMX_SIP_TIMER_*: This seems to be related to the watchdog. >>>> Shouldn't dom0 rely on the watchdog provided by Xen instead? So those >>>> call will be used by Xen. >>> >>> That is indeed a watchdog SIP, and also for setting the SoC internal RTC >>> if it is being used. >>> >>> I looked around if there was previous discussion and only really >>> found [3]. >>> Is the xen/xen/include/watchdog.h header meant to be for this kind of >>> watchdog support or is that more for the VM watchdog? Looking at the x86 >>> ACPI NMI watchdog it seems like the former, but I have never worked with >>> x86 nor ACPI. > > include/watchdog.h contains helper to configure the watchdog for Xen. We > also have per-VM watchdog and this is configured by the hypercall > SCHEDOP_watchdog. > >>> >>> Currently forwarding it to Dom0 has not caused any watchdog resets with >>> our watchdog timeout settings, our specific Dom0 setup and VM count. > > IIUC, the SMC API for the watchdog would be similar to the ACPI NMI > watchdog. So I think it would make more sense if this is not exposed to > dom0 (even if Xen is doing nothing with it). > > Can you try to hide the SMCs and check if dom0 still behave properly? > > Cheers, > This SMC manages a hardware watchdog, if it's not pinged within a specific interval the entire board resets. If I block the SMCs the watchdog driver in Dom0 will fail to ping the watchdog, triggering a board reset because the system looks to have become unresponsive. The reason this patch set started is because we couldn't ping the watchdog when running with Xen. In our specific system the bootloader enables the watchdog as early as possible so that we can get watchdog protection for as much of the boot as we possibly can. So, if we are to block the SMC from Dom0, then Xen needs to take over the pinging. It could be implemented similarly to the NMI watchdog, except that the system will reset if the ping is missed rather than backtrace. It would also mean that Xen will get a whole watchdog driver-category due to the watchdog being vendor and sometimes even SoC specific when it comes to Arm. My understanding of the domain watchdog code is that today the domain needs to call SCHEDOP_watchdog at least once to start the watchdog timer. Since watchdog protection through the whole boot process is desirable we'd need some core changes, such as an option to start the domain watchdog on init. It's quite a big change to make, while I am not against doing it if it makes sense, I now wonder if Xen should manage hardware watchdogs. Looking at the domain watchdog code it looks like if a domain does not get enough execution time, the watchdog will not be pinged enough and the guest will be reset. So either watchdog approach requires Dom0 to get execution time. Dom0 also needs to service all the PV backends it's responsible for. I'm not sure it's valuable to add another layer of watchdog for this scenario as the end result (checking that the entire system works) is achieved without it as well. So, before I try to find the time to make a proposal for moving the hardware watchdog bit to Xen, do we really want it? Thanks! // John Ernberg
Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Hi Julien,
On 2/9/24 14:14, John Ernberg wrote:
> Hi Julien,
>
> Apologies for the delay, I was pulled away for a bit.
>
> On 2/5/24 11:13, Julien Grall wrote:
>> Hi,
>>
>> On 04/02/2024 09:40, Peng Fan wrote:
>>>
>>>
>>>> -Original Message-
>>>> From: Julien Grall
>>>> Sent: 2024年2月2日 17:20
>>>> To: John Ernberg ; Stefano Stabellini
>>>> ; Bertrand Marquis ;
>>>> Michal Orzel ; Volodymyr Babchuk
>>>> ; Peng Fan
>>>> Cc: Jonas Blixt ; xen-devel@lists.xenproject.org
>>>> Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
>>>>
>>>> On 01/02/2024 16:17, John Ernberg wrote:
>>>>> On 2/1/24 13:20, Julien Grall wrote:
>>>>>>
>>>>>>
>>>>>> On 31/01/2024 15:32, John Ernberg wrote:
>>>>>>> Hi Julien,
>>>>>>
>>>>>> Hi John,
>>>>>>
>>>>>>> On 1/31/24 13:22, Julien Grall wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 31/01/2024 11:50, John Ernberg wrote:
> [ ... ]
>>>>>>
>>>>>>>> But even if we restrict to dom0, have you checked that none of the
>>>>>>>> SMCs use buffers?
>>>>>>> I haven't found any such instances in the Linux kernel where a
>>>>>>> buffer is used. Adding a call filtering like suggested below
>>>>>>> additions of such functions can be discovered and adapted for if
>>>>>>> they
>>>> would show up later.
>>>>>>>>
>>>>>>>> Rather than providing a blanket forward, to me it sounds more like
>>>>>>>> you want to provide an allowlist of the SMCs. This is more
>>>>>>>> futureproof and avoid the risk to expose unsafe SMCs to any domain.
>>>>>>>>
>>>>>>>> For an example, you can have a look at the EEMI mediator for
>>>>>>>> Xilinx.
>>>>>>>
>>>>>>> Ack. Do you prefer to see only on SMCCC service level or also on
>>>>>>> function level? (a1 register, per description earlier)
>>>>>>
>>>>>> I am not sure. It will depend on whether it is correct to expose
>>>>>> *all* the functions within a service level and they have the same
>>>>>> format.
>>>>>>
>>>>>> If you can't guarantee that, then you will most likely need to
>>>>>> allowlist at the function level.
>>>>>>
>>>>>> Also, do you have a spec in hand that would help to understand which
>>>>>> service/function is implemented via those SMCs?
>>>>>
>>>>> I don't have the spec unfortunately, but I will add a filter on both
>>>>> service and function for V2 and we'll take it from there.
>>>>
>>>> @Peng, do you have any specification you could share? How stable is the
>>>> interface?
>>>
>>> No specification, the use is IMX_SIP_X in linux kernel source.
>>>
>>> Such as IMX_SIP_RTC, IMX_SIP_TIMER
>>>
>>> It is stable and no change, we only add new SIP macro if needed
>>> and no change the meaning or reuse old SIP.
>>
>> Thanks for the answer. It is a bit unfortunate there are no
>> specification, but at least they are stable.
>>
>> I have searched IMX_SIP in Linux, there doesn't seem many so we could
>> allowlist them (see more below). Do you know if there are more
>> necessary that are not yet upstreamed in Linux?
>
> I took a dive into both upstream kernel and the vendor tree and found
> the following list and for which SoCs they are applicable (Please
> correct me if you can Peng)
>
> 0x8206 IMX_SIP_BUSFREQ_CHANGE [unsure, probably not imx8]
> 0xC200 IMX_SIP_GPC [only imx8m series]
> 0xC201 IMX_SIP_CPUFREQ [only imx8q{x,m} series]
> 0xC202 IMX_SIP_SRTC / IMX_SIP_TIMER [only imx8q{x,m} series]
> 0xC204 IMX_SIP_DDR_DVFS [only imx8m series]
> 0xC205 IMX_SIP_RPROC / IMX_SIP_SRC [only imx8m series]
> 0xC206 IMX_SIP_GET_SOC_INFO [only imx8m series]
> 0xC208 IMX_SIP_NOC [only imx8m series]
> 0xC209 IMX_SIP_WAKEUP_SRC [only imx8q{x,m} series]
> 0xC20B IMX_SIP_OTP_WRITE [only imx8q{x,m} series]
>>
>>
[ ... ]
>
>> * IMX_SIP_TIMER_*: This seems to be related to the watchdog.
Re: [PATCH v2 1/2] xen/arm: Add imx8q{m,x} platform glue
Hi Michal, On 2/15/24 14:53, John Ernberg wrote: > Hi Michal, > > On 2/15/24 10:02, Michal Orzel wrote: >> Hi, >> >> On 14/02/2024 17:06, John Ernberg wrote: >>> >>> >>> When using Linux for dom0 there are a bunch of drivers that need to >>> do SMC >>> SIP calls into the firmware to enable certain hardware bits like the >>> watchdog. >>> >>> Provide a basic platform glue that implements the needed SMC forwarding. >>> >>> The format of these calls are as follows: >>> - reg 0: service ID >>> - reg 1: function ID >>> remaining regs: args >>> >>> For now we only allow Dom0 to make these calls as they are all managing >>> hardware. There is no specification for these SIP calls, the IDs and >>> names >>> have been extracted from the upstream linux kernel and the vendor >>> kernel. >>> >>> Most of the SIP calls are only available for the iMX8M series of >>> SoCs, so >>> they are easy to reject and they need to be revisited when iMX8M series >>> support is added. >> Given that you named your driver *qm and you search for dt compatible >> *qm, *qxp, does it really >> make sense to add SIP calls for iMX8M? > > The idea was to be explicit about why it makes no sense to support those > SIPs on a qm/qxp implementation. > > I can take it out if that's not argument enough to have them. [ ... ] >>> +#define IMX_SIP_GET_SOC_INFO 0xC206 >>> +#define IMX_SIP_NOC 0xC208 >>> +#define IMX_SIP_WAKEUP_SRC 0xC209 >>> +#define IMX_SIP_OTP_WRITE 0xC20B >> Looking at ATF, for QM,QXP there are also: >> BUILDINFO 0xC203 >> OTP_READ 0xC20A >> SET_TEMP 0xC20C > > I can't find them in the current Linux code, perhaps deprecated. > I can add them and deny them if it makes sense. >> >>> + >>> +#define IMX_SIP_TIME_F_RTC_SET_TIME 0x00 >>> +#define IMX_SIP_TIME_F_WDOG_START 0x01 >>> +#define IMX_SIP_TIME_F_WDOG_STOP 0x02 >>> +#define IMX_SIP_TIME_F_WDOG_SET_ACT 0x03 >>> +#define IMX_SIP_TIME_F_WDOG_PING 0x04 >>> +#define IMX_SIP_TIME_F_WDOG_SET_TIMEOUT 0x05 >>> +#define IMX_SIP_TIME_F_WDOG_GET_STAT 0x06 >>> +#define IMX_SIP_TIME_F_WDOG_SET_PRETIME 0x07 >>> + Ping. Thanks! // John Ernberg
Re: [PATCH v2 1/2] xen/arm: Add imx8q{m,x} platform glue
Hi Michal,
On 2/15/24 10:02, Michal Orzel wrote:
> Hi,
>
> On 14/02/2024 17:06, John Ernberg wrote:
>>
>>
>> When using Linux for dom0 there are a bunch of drivers that need to do SMC
>> SIP calls into the firmware to enable certain hardware bits like the
>> watchdog.
>>
>> Provide a basic platform glue that implements the needed SMC forwarding.
>>
>> The format of these calls are as follows:
>> - reg 0: service ID
>> - reg 1: function ID
>> remaining regs: args
>>
>> For now we only allow Dom0 to make these calls as they are all managing
>> hardware. There is no specification for these SIP calls, the IDs and names
>> have been extracted from the upstream linux kernel and the vendor kernel.
>>
>> Most of the SIP calls are only available for the iMX8M series of SoCs, so
>> they are easy to reject and they need to be revisited when iMX8M series
>> support is added.
> Given that you named your driver *qm and you search for dt compatible *qm,
> *qxp, does it really
> make sense to add SIP calls for iMX8M?
The idea was to be explicit about why it makes no sense to support those
SIPs on a qm/qxp implementation.
I can take it out if that's not argument enough to have them.
>
>>
>> From the other calls we can reject CPUFREQ because Dom0 cannot make an
>> informed decision regarding CPU frequency scaling, WAKEUP_SRC is to wake
>> up from suspend, which Xen doesn't support at this time.
>>
>> This leaves the TIME SIP and the OTP_WRITE SIP, which for now are allowed
>> to Dom0.
>>
>> NOTE: This code is based on code found in NXP Xen tree located here:
>> https://github.com/nxp-imx/imx-xen/blob/lf-5.10.y_4.13/xen/arch/arm/platforms/imx8qm.c
>>
>> Signed-off-by: Peng Fan
>> [jernberg: Add SIP call filtering]
>> Signed-off-by: John Ernberg
>>
>> ---
>>
>> v2:
>> - Reword the commit message to be a bit clearer
>> - Include the link previously added as a context note to the commit
>> message (Julien Grall)
>> - Add Pengs signed off (Julien Grall, Peng Fan)
>> - Add basic SIP call filter (Julien Grall)
>> - Expand the commit message a whole bunch because of the changes to the
>> code
>> ---
>> xen/arch/arm/platforms/Makefile | 1 +
>> xen/arch/arm/platforms/imx8qm.c | 143
>> 2 files changed, 144 insertions(+)
>> create mode 100644 xen/arch/arm/platforms/imx8qm.c
>>
>> diff --git a/xen/arch/arm/platforms/Makefile
>> b/xen/arch/arm/platforms/Makefile
>> index 8632f4115f..bec6e55d1f 100644
>> --- a/xen/arch/arm/platforms/Makefile
>> +++ b/xen/arch/arm/platforms/Makefile
>> @@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT) += sunxi.o
>> obj-$(CONFIG_ALL64_PLAT) += thunderx.o
>> obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o
>> obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o
>> +obj-$(CONFIG_ALL64_PLAT) += imx8qm.o
>> obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o
>> obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp-eemi.o
>> diff --git a/xen/arch/arm/platforms/imx8qm.c
>> b/xen/arch/arm/platforms/imx8qm.c
>> new file mode 100644
>> index 00..4515c75935
>> --- /dev/null
>> +++ b/xen/arch/arm/platforms/imx8qm.c
>> @@ -0,0 +1,143 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>> +/*
>> + * xen/arch/arm/platforms/imx8qm.c
>> + *
>> + * i.MX 8QM setup
>> + *
>> + * Copyright (c) 2016 Freescale Inc.
>> + * Copyright 2018-2019 NXP
>> + *
>> + *
>> + * Peng Fan
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +static const char * const imx8qm_dt_compat[] __initconst =
>> +{
>> +"fsl,imx8qm",
>> +"fsl,imx8qxp",
>> +NULL
>> +};
>> +
>> +#define IMX_SIP_GPC 0xC200
> NIT: A matter of personal opinion but all the Arm64 SIP services starts with
> 0xc200,
> so you could just define a function id i.e. 1, 2, ... and use a macro similar
> to EEMI_FID(fid).
> This is just a suggestion.
Ack.
>
>> +#define IMX_SIP_CPUFREQ 0xC201
>> +#define IMX_SIP_TIME 0xC202
>> +#define IMX_SIP_DDR_DVFS 0xC204
>> +#define IMX_SIP_SRC 0xC205
>> +#define IMX_SIP_GET_SOC_INFO 0xC206
>> +#define IMX_SIP_NOC 0xC208
>> +#define IMX_SIP_WAKEUP_SRC 0xC209
>> +#define IMX_SIP_OTP_WRITE0xC20B
> Looking at ATF, for QM,QXP there are also:
> BUILDINFO 0xC203
> OTP_READ 0xC20A
> SET
[PATCH v2 2/2] xen/drivers: imx-lpuart: Replace iMX8QM compatible with iMX8QXP
Allow the uart to probe also with iMX8QXP. The ip-block is the same as in
the QM.
Since the fsl,imx8qm-lpuart compatible in Linux exists in name only and is
not used in the driver any iMX8QM device tree that can boot Linux must set
fsl,imx8qxp-lpuart compatible as well as the QM one.
Thus we replace the compatible rather than adding just another one.
Signed-off-by: John Ernberg
Acked-by: Julien Grall
---
v2:
- Replace the compatible rather than adding to the list (Julien Grall)
- Reword commit message to reflect the above.
- Collect Julien's ack
---
xen/drivers/char/imx-lpuart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/char/imx-lpuart.c b/xen/drivers/char/imx-lpuart.c
index 77f70c2719..7a9c2e3878 100644
--- a/xen/drivers/char/imx-lpuart.c
+++ b/xen/drivers/char/imx-lpuart.c
@@ -256,7 +256,7 @@ static int __init imx_lpuart_init(struct dt_device_node
*dev,
static const struct dt_device_match imx_lpuart_dt_compat[] __initconst =
{
-DT_MATCH_COMPATIBLE("fsl,imx8qm-lpuart"),
+DT_MATCH_COMPATIBLE("fsl,imx8qxp-lpuart"),
{ /* sentinel */ },
};
--
2.43.0
[PATCH v2 0/2] Xen: ARM: Improved NXP iMX8 platform support
The iMX lpuart driver added at 44e17aa60d47 ("xen/arm: Add i.MX lpuart driver")
is not enough to boot a Linux based dom0 when certain drivers, such as the
watchdog driver, are enabled.
We're also fixing compatibles in imx-lpuart to allow Xen to use the UART
on the QXP variant as well.
NOTE:
There's still an open point regarding the watchdog from v1, but I wanted
to post this series to show the filtering changes mostly because they also
clarify what exists and what we can definitely get away with blocking /
ignoring out of all the SMC SIP calls.
v2: (See each path for complete changelog)
- Added SIP call filtering (Julien Grall)
- Replace lpuart compatible instead (Julien Grall)
v1:
https://lore.kernel.org/xen-devel/20240131114952.305805-1-john.ernb...@actia.se
John Ernberg (2):
xen/arm: Add imx8q{m,x} platform glue
xen/drivers: imx-lpuart: Replace iMX8QM compatible with iMX8QXP
xen/arch/arm/platforms/Makefile | 1 +
xen/arch/arm/platforms/imx8qm.c | 143
xen/drivers/char/imx-lpuart.c | 2 +-
3 files changed, 145 insertions(+), 1 deletion(-)
create mode 100644 xen/arch/arm/platforms/imx8qm.c
--
2.43.0
[PATCH v2 1/2] xen/arm: Add imx8q{m,x} platform glue
When using Linux for dom0 there are a bunch of drivers that need to do SMC
SIP calls into the firmware to enable certain hardware bits like the
watchdog.
Provide a basic platform glue that implements the needed SMC forwarding.
The format of these calls are as follows:
- reg 0: service ID
- reg 1: function ID
remaining regs: args
For now we only allow Dom0 to make these calls as they are all managing
hardware. There is no specification for these SIP calls, the IDs and names
have been extracted from the upstream linux kernel and the vendor kernel.
Most of the SIP calls are only available for the iMX8M series of SoCs, so
they are easy to reject and they need to be revisited when iMX8M series
support is added.
>From the other calls we can reject CPUFREQ because Dom0 cannot make an
informed decision regarding CPU frequency scaling, WAKEUP_SRC is to wake
up from suspend, which Xen doesn't support at this time.
This leaves the TIME SIP and the OTP_WRITE SIP, which for now are allowed
to Dom0.
NOTE: This code is based on code found in NXP Xen tree located here:
https://github.com/nxp-imx/imx-xen/blob/lf-5.10.y_4.13/xen/arch/arm/platforms/imx8qm.c
Signed-off-by: Peng Fan
[jernberg: Add SIP call filtering]
Signed-off-by: John Ernberg
---
v2:
- Reword the commit message to be a bit clearer
- Include the link previously added as a context note to the commit message
(Julien Grall)
- Add Pengs signed off (Julien Grall, Peng Fan)
- Add basic SIP call filter (Julien Grall)
- Expand the commit message a whole bunch because of the changes to the code
---
xen/arch/arm/platforms/Makefile | 1 +
xen/arch/arm/platforms/imx8qm.c | 143
2 files changed, 144 insertions(+)
create mode 100644 xen/arch/arm/platforms/imx8qm.c
diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 8632f4115f..bec6e55d1f 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT) += sunxi.o
obj-$(CONFIG_ALL64_PLAT) += thunderx.o
obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o
obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o
+obj-$(CONFIG_ALL64_PLAT) += imx8qm.o
obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o
obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp-eemi.o
diff --git a/xen/arch/arm/platforms/imx8qm.c b/xen/arch/arm/platforms/imx8qm.c
new file mode 100644
index 00..4515c75935
--- /dev/null
+++ b/xen/arch/arm/platforms/imx8qm.c
@@ -0,0 +1,143 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * xen/arch/arm/platforms/imx8qm.c
+ *
+ * i.MX 8QM setup
+ *
+ * Copyright (c) 2016 Freescale Inc.
+ * Copyright 2018-2019 NXP
+ *
+ *
+ * Peng Fan
+ */
+
+#include
+#include
+#include
+
+static const char * const imx8qm_dt_compat[] __initconst =
+{
+"fsl,imx8qm",
+"fsl,imx8qxp",
+NULL
+};
+
+#define IMX_SIP_GPC 0xC200
+#define IMX_SIP_CPUFREQ 0xC201
+#define IMX_SIP_TIME 0xC202
+#define IMX_SIP_DDR_DVFS 0xC204
+#define IMX_SIP_SRC 0xC205
+#define IMX_SIP_GET_SOC_INFO 0xC206
+#define IMX_SIP_NOC 0xC208
+#define IMX_SIP_WAKEUP_SRC 0xC209
+#define IMX_SIP_OTP_WRITE0xC20B
+
+#define IMX_SIP_TIME_F_RTC_SET_TIME 0x00
+#define IMX_SIP_TIME_F_WDOG_START 0x01
+#define IMX_SIP_TIME_F_WDOG_STOP0x02
+#define IMX_SIP_TIME_F_WDOG_SET_ACT 0x03
+#define IMX_SIP_TIME_F_WDOG_PING0x04
+#define IMX_SIP_TIME_F_WDOG_SET_TIMEOUT 0x05
+#define IMX_SIP_TIME_F_WDOG_GET_STAT0x06
+#define IMX_SIP_TIME_F_WDOG_SET_PRETIME 0x07
+
+static bool imx8qm_is_sip_time_call_ok(uint32_t function_id)
+{
+switch ( function_id )
+{
+case IMX_SIP_TIME_F_RTC_SET_TIME:
+return true;
+case IMX_SIP_TIME_F_WDOG_START:
+case IMX_SIP_TIME_F_WDOG_STOP:
+case IMX_SIP_TIME_F_WDOG_SET_ACT:
+case IMX_SIP_TIME_F_WDOG_PING:
+case IMX_SIP_TIME_F_WDOG_SET_TIMEOUT:
+case IMX_SIP_TIME_F_WDOG_GET_STAT:
+case IMX_SIP_TIME_F_WDOG_SET_PRETIME:
+return true;
+default:
+printk(XENLOG_WARNING "imx8qm: smc: time: Unknown function id %x\n",
function_id);
+return false;
+}
+}
+
+static bool imx8qm_smc(struct cpu_user_regs *regs)
+{
+uint32_t service_id = get_user_reg(regs, 0);
+uint32_t function_id = get_user_reg(regs, 1);
+struct arm_smccc_res res;
+
+if ( !cpus_have_const_cap(ARM_SMCCC_1_1) )
+{
+printk_once(XENLOG_WARNING "no SMCCC 1.1 support. Disabling firmware
calls\n");
+
+return false;
+}
+
+/* Only hardware domain may use the SIP calls */
+if ( !is_hardware_domain(current->domain) )
+{
+gprintk(XENLOG_WARNING, "imx8qm: smc: No access\n");
+return false;
+}
+
+switch ( service_id )
+{
+case IMX_SIP_GPC: /* Only available on imx8m series */
+return false;
+case IMX_SIP_CPUFREQ: /* Dom0 can't t
Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Hi Julien,
Apologies for the delay, I was pulled away for a bit.
On 2/5/24 11:13, Julien Grall wrote:
> Hi,
>
> On 04/02/2024 09:40, Peng Fan wrote:
>>
>>
>>> -Original Message-
>>> From: Julien Grall
>>> Sent: 2024年2月2日 17:20
>>> To: John Ernberg ; Stefano Stabellini
>>> ; Bertrand Marquis ;
>>> Michal Orzel ; Volodymyr Babchuk
>>> ; Peng Fan
>>> Cc: Jonas Blixt ; xen-devel@lists.xenproject.org
>>> Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
>>>
>>> On 01/02/2024 16:17, John Ernberg wrote:
>>>> On 2/1/24 13:20, Julien Grall wrote:
>>>>>
>>>>>
>>>>> On 31/01/2024 15:32, John Ernberg wrote:
>>>>>> Hi Julien,
>>>>>
>>>>> Hi John,
>>>>>
>>>>>> On 1/31/24 13:22, Julien Grall wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 31/01/2024 11:50, John Ernberg wrote:
[ ... ]
>>>>>
>>>>>>> But even if we restrict to dom0, have you checked that none of the
>>>>>>> SMCs use buffers?
>>>>>> I haven't found any such instances in the Linux kernel where a
>>>>>> buffer is used. Adding a call filtering like suggested below
>>>>>> additions of such functions can be discovered and adapted for if they
>>> would show up later.
>>>>>>>
>>>>>>> Rather than providing a blanket forward, to me it sounds more like
>>>>>>> you want to provide an allowlist of the SMCs. This is more
>>>>>>> futureproof and avoid the risk to expose unsafe SMCs to any domain.
>>>>>>>
>>>>>>> For an example, you can have a look at the EEMI mediator for Xilinx.
>>>>>>
>>>>>> Ack. Do you prefer to see only on SMCCC service level or also on
>>>>>> function level? (a1 register, per description earlier)
>>>>>
>>>>> I am not sure. It will depend on whether it is correct to expose
>>>>> *all* the functions within a service level and they have the same
>>>>> format.
>>>>>
>>>>> If you can't guarantee that, then you will most likely need to
>>>>> allowlist at the function level.
>>>>>
>>>>> Also, do you have a spec in hand that would help to understand which
>>>>> service/function is implemented via those SMCs?
>>>>
>>>> I don't have the spec unfortunately, but I will add a filter on both
>>>> service and function for V2 and we'll take it from there.
>>>
>>> @Peng, do you have any specification you could share? How stable is the
>>> interface?
>>
>> No specification, the use is IMX_SIP_X in linux kernel source.
>>
>> Such as IMX_SIP_RTC, IMX_SIP_TIMER
>>
>> It is stable and no change, we only add new SIP macro if needed
>> and no change the meaning or reuse old SIP.
>
> Thanks for the answer. It is a bit unfortunate there are no
> specification, but at least they are stable.
>
> I have searched IMX_SIP in Linux, there doesn't seem many so we could
> allowlist them (see more below). Do you know if there are more necessary
> that are not yet upstreamed in Linux?
I took a dive into both upstream kernel and the vendor tree and found
the following list and for which SoCs they are applicable (Please
correct me if you can Peng)
0x8206 IMX_SIP_BUSFREQ_CHANGE [unsure, probably not imx8]
0xC200 IMX_SIP_GPC [only imx8m series]
0xC201 IMX_SIP_CPUFREQ [only imx8q{x,m} series]
0xC202 IMX_SIP_SRTC / IMX_SIP_TIMER [only imx8q{x,m} series]
0xC204 IMX_SIP_DDR_DVFS [only imx8m series]
0xC205 IMX_SIP_RPROC / IMX_SIP_SRC [only imx8m series]
0xC206 IMX_SIP_GET_SOC_INFO [only imx8m series]
0xC208 IMX_SIP_NOC [only imx8m series]
0xC209 IMX_SIP_WAKEUP_SRC [only imx8q{x,m} series]
0xC20B IMX_SIP_OTP_WRITE [only imx8q{x,m} series]
>
>
> Looking through the list, there are some that probably want a bit more
> discussion on whether we want to expose them:
> * IMX_SIP_CPUFREQ: Right now, dom0 is not aware of the full system.
> So it may take wrong decision.
The cpufreq function operates on the cluster level, it performs no error
checking so blocking it will be invisible to Linux. I don't know yet
what kind of impact that could have. Looking for hints about cpufreq in
Xen for ARM I found [1] and [2].
In our current setup we do not use cpufreq and it is stable enough for
our usecase.
From my point of view we can
Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
On 2/1/24 13:20, Julien Grall wrote: > > > On 31/01/2024 15:32, John Ernberg wrote: >> Hi Julien, > > Hi John, > >> On 1/31/24 13:22, Julien Grall wrote: >>> Hi, >>> >>> On 31/01/2024 11:50, John Ernberg wrote: >>>> When using Linux for dom0 there are a bunch of drivers that need to do >>>> SMC >>>> SIP calls into the PSCI provider to enable certain hardware bits >>>> like the >>>> watchdog. >>> >>> Do you know which protocol this is under the hood. Is this SCMI? >> >> I think I confused myself here when I wrote the commit log. >> >> The EL3 code in our case is ATF, and it does not appear to be SCMI, nor >> PSCI. The register usage of these SMC SIP calls are as follows: >> a0 - service >> a1 - function >> a2-a7 - args >> >> In ATF the handler is declared as a runtime service. >> >> Would the appropriate commmit message here be something along the lines >> of below? >> """ >> When using Linux for dom0 there are a bunch of drivers that need to >> do SMC >> SIP calls into the firmware to enable certain hardware bits like the >> watchdog. >> """ > > It reads better thanks. > > [...] > >>> But even if we restrict to dom0, have you checked that none of the SMCs >>> use buffers? >> I haven't found any such instances in the Linux kernel where a buffer is >> used. Adding a call filtering like suggested below additions of such >> functions can be discovered and adapted for if they would show up later. >>> >>> Rather than providing a blanket forward, to me it sounds more like you >>> want to provide an allowlist of the SMCs. This is more futureproof and >>> avoid the risk to expose unsafe SMCs to any domain. >>> >>> For an example, you can have a look at the EEMI mediator for Xilinx. >> >> Ack. Do you prefer to see only on SMCCC service level or also on >> function level? (a1 register, per description earlier) > > I am not sure. It will depend on whether it is correct to expose *all* > the functions within a service level and they have the same format. > > If you can't guarantee that, then you will most likely need to allowlist > at the function level. > > Also, do you have a spec in hand that would help to understand which > service/function is implemented via those SMCs? I don't have the spec unfortunately, but I will add a filter on both service and function for V2 and we'll take it from there. > > Cheers, > Thanks! // John Ernberg
Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Hi Peng,
On 2/1/24 05:10, Peng Fan wrote:
>> Cc: Jonas Blixt ; xen-devel@lists.xenproject.org
>> Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
>>
>> Hi Julien,
>>
>> On 1/31/24 13:22, Julien Grall wrote:
>>> Hi,
>>>
>>> On 31/01/2024 11:50, John Ernberg wrote:
>>>> When using Linux for dom0 there are a bunch of drivers that need to
>>>> do SMC SIP calls into the PSCI provider to enable certain hardware
>>>> bits like the watchdog.
>>>
>>> Do you know which protocol this is under the hood. Is this SCMI?
>>
>> I think I confused myself here when I wrote the commit log.
>>
>> The EL3 code in our case is ATF, and it does not appear to be SCMI, nor PSCI.
>> The register usage of these SMC SIP calls are as follows:
>> a0 - service
>> a1 - function
>> a2-a7 - args
>>
>> In ATF the handler is declared as a runtime service.
>>
>> Would the appropriate commmit message here be something along the lines
>> of below?
>> """
>> When using Linux for dom0 there are a bunch of drivers that need to do
>> SMC
>> SIP calls into the firmware to enable certain hardware bits like the
>> watchdog.
>> """
>>>
>>>>
>>>> Provide a basic platform glue that implements the needed SMC forwarding.
>>>>
>>>> Signed-off-by: John Ernberg
>>>> ---
>>>> NOTE: This is based on code found in NXP Xen tree located here:
>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
>>>> hub.com%2Fnxp-imx%2Fimx-xen%2Fblob%2Flf-
>> 5.10.y_4.13%2Fxen%2Farch%2Far
>>>>
>> m%2Fplatforms%2Fimx8qm.c=05%7C02%7Cpeng.fan%40nxp.com%7C
>> 573b599a
>>>>
>> 4b4143ceca1d08dc2271e5be%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C
>> 0%7C0%7
>>>>
>> C638423119777601548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
>> wMDAiLCJQI
>>>>
>> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=ZO
>> 0TXjL6
>>>> g0W7TIZo8x8lTNBXEZW%2BDNcLPndWlEf5D2A%3D=0
>>>
>>> Anything after --- will be removed while applied to the three. I think
>>> this NOTE should be written down in the commit message.
>>
>> Ack.
>>>
>>> You also possibly want a signed-off-by from Peng as this is his code.
>>
>> @Peng: May I add a sign-off from you?
>
> Yeah. You could add my sign off.
Great, thanks!
>
>>>
>>>>
>>>> xen/arch/arm/platforms/Makefile | 1 +
>>>> xen/arch/arm/platforms/imx8qm.c | 65
>>>> +
>>>> 2 files changed, 66 insertions(+)
>>>> create mode 100644 xen/arch/arm/platforms/imx8qm.c
>>>>
>>>> diff --git a/xen/arch/arm/platforms/Makefile
>>>> b/xen/arch/arm/platforms/Makefile index 8632f4115f..bec6e55d1f
>> 100644
>>>> --- a/xen/arch/arm/platforms/Makefile
>>>> +++ b/xen/arch/arm/platforms/Makefile
>>>> @@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT) += sunxi.o
>>>> obj-$(CONFIG_ALL64_PLAT) += thunderx.o
>>>> obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o
>>>> obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o
>>>> +obj-$(CONFIG_ALL64_PLAT) += imx8qm.o
>>>> obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o
>>>> obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp-eemi.o diff --git
>>>> a/xen/arch/arm/platforms/imx8qm.c
>> b/xen/arch/arm/platforms/imx8qm.c
>>>> new file mode 100644 index 00..a9cd9c3615
>>>> --- /dev/null
>>>> +++ b/xen/arch/arm/platforms/imx8qm.c
>>>> @@ -0,0 +1,65 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>>>> +/*
>>>> + * xen/arch/arm/platforms/imx8qm.c
>>>> + *
>>>> + * i.MX 8QM setup
>>>> + *
>>>> + * Copyright (c) 2016 Freescale Inc.
>>>> + * Copyright 2018-2019 NXP
>>>> + *
>>>> + *
>>>> + * Peng Fan
>>>> + */
>>>> +
>>>> +#include
>>>> +#include
>>>> +
>>>> +static const char * const imx8qm_dt_compat[] __initconst = {
>>>> + "fsl,imx8qm",
>>>> + "fsl,imx8qxp",
>>>> + NULL
>>>> +};
>>>> +
>>>> +static bool imx8qm_smc(struct cpu_user_regs *regs) {
>>>
>>> Your implementation below will not only forward SMC for dom0 but also
>>> for any non-trusted domains. Have you investigated that all the SIP
>>> calls are safe to be called by anyone?
>>
>> We use pure virtualized domUs, so we do not expect any calls to this SMC
>> interface from the guest. I'll limit it to dom0.
>
> Would you mind to share what features are supported in your DomU?
>
> Pure virtualized, you using xen pv or virtio?
Not at all. We're forwarding block and networking (and additionally
usbip over networking for USB sharing), via the Xen PV drivers.
>
> Thanks,
> Peng.
>
Thanks! // John Ernberg
Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
Hi Julien,
On 1/31/24 13:22, Julien Grall wrote:
> Hi,
>
> On 31/01/2024 11:50, John Ernberg wrote:
>> When using Linux for dom0 there are a bunch of drivers that need to do
>> SMC
>> SIP calls into the PSCI provider to enable certain hardware bits like the
>> watchdog.
>
> Do you know which protocol this is under the hood. Is this SCMI?
I think I confused myself here when I wrote the commit log.
The EL3 code in our case is ATF, and it does not appear to be SCMI, nor
PSCI. The register usage of these SMC SIP calls are as follows:
a0 - service
a1 - function
a2-a7 - args
In ATF the handler is declared as a runtime service.
Would the appropriate commmit message here be something along the lines
of below?
"""
When using Linux for dom0 there are a bunch of drivers that need to do SMC
SIP calls into the firmware to enable certain hardware bits like the
watchdog.
"""
>
>>
>> Provide a basic platform glue that implements the needed SMC forwarding.
>>
>> Signed-off-by: John Ernberg
>> ---
>> NOTE: This is based on code found in NXP Xen tree located here:
>> https://github.com/nxp-imx/imx-xen/blob/lf-5.10.y_4.13/xen/arch/arm/platforms/imx8qm.c
>
> Anything after --- will be removed while applied to the three. I think
> this NOTE should be written down in the commit message.
Ack.
>
> You also possibly want a signed-off-by from Peng as this is his code.
@Peng: May I add a sign-off from you?
>
>>
>> xen/arch/arm/platforms/Makefile | 1 +
>> xen/arch/arm/platforms/imx8qm.c | 65 +
>> 2 files changed, 66 insertions(+)
>> create mode 100644 xen/arch/arm/platforms/imx8qm.c
>>
>> diff --git a/xen/arch/arm/platforms/Makefile
>> b/xen/arch/arm/platforms/Makefile
>> index 8632f4115f..bec6e55d1f 100644
>> --- a/xen/arch/arm/platforms/Makefile
>> +++ b/xen/arch/arm/platforms/Makefile
>> @@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT) += sunxi.o
>> obj-$(CONFIG_ALL64_PLAT) += thunderx.o
>> obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o
>> obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o
>> +obj-$(CONFIG_ALL64_PLAT) += imx8qm.o
>> obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o
>> obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp-eemi.o
>> diff --git a/xen/arch/arm/platforms/imx8qm.c
>> b/xen/arch/arm/platforms/imx8qm.c
>> new file mode 100644
>> index 00..a9cd9c3615
>> --- /dev/null
>> +++ b/xen/arch/arm/platforms/imx8qm.c
>> @@ -0,0 +1,65 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>> +/*
>> + * xen/arch/arm/platforms/imx8qm.c
>> + *
>> + * i.MX 8QM setup
>> + *
>> + * Copyright (c) 2016 Freescale Inc.
>> + * Copyright 2018-2019 NXP
>> + *
>> + *
>> + * Peng Fan
>> + */
>> +
>> +#include
>> +#include
>> +
>> +static const char * const imx8qm_dt_compat[] __initconst =
>> +{
>> + "fsl,imx8qm",
>> + "fsl,imx8qxp",
>> + NULL
>> +};
>> +
>> +static bool imx8qm_smc(struct cpu_user_regs *regs)
>> +{
>
> Your implementation below will not only forward SMC for dom0 but also
> for any non-trusted domains. Have you investigated that all the SIP
> calls are safe to be called by anyone?
We use pure virtualized domUs, so we do not expect any calls to this SMC
interface from the guest. I'll limit it to dom0.
>
> But even if we restrict to dom0, have you checked that none of the SMCs
> use buffers?
I haven't found any such instances in the Linux kernel where a buffer is
used. Adding a call filtering like suggested below additions of such
functions can be discovered and adapted for if they would show up later.
>
> Rather than providing a blanket forward, to me it sounds more like you
> want to provide an allowlist of the SMCs. This is more futureproof and
> avoid the risk to expose unsafe SMCs to any domain.
>
> For an example, you can have a look at the EEMI mediator for Xilinx.
Ack. Do you prefer to see only on SMCCC service level or also on
function level? (a1 register, per description earlier)
>
> Cheers,
>
Thanks! // John Ernberg
Re: [PATCH 2/2] xen/drivers: imx-lpuart: Add iMX8QXP compatible
Hi Julien,
On 1/31/24 13:29, Julien Grall wrote:
> Hi John,
>
> On 31/01/2024 11:50, John Ernberg wrote:
>> Allow the uart to probe also with iMX8QXP. The ip-block is the same as
>> in the QM,
>> only the compatible is needed.
>>
>> Signed-off-by: John Ernberg
>
> With one remark below:
>
> Acked-by: Julien Grall
>
>> ---
>> xen/drivers/char/imx-lpuart.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/xen/drivers/char/imx-lpuart.c
>> b/xen/drivers/char/imx-lpuart.c
>> index 77f70c2719..c85e81109a 100644
>> --- a/xen/drivers/char/imx-lpuart.c
>> +++ b/xen/drivers/char/imx-lpuart.c
>> @@ -257,6 +257,7 @@ static int __init imx_lpuart_init(struct
>> dt_device_node *dev,
>> static const struct dt_device_match imx_lpuart_dt_compat[]
>> __initconst =
>> {
>> DT_MATCH_COMPATIBLE("fsl,imx8qm-lpuart"),
>> + DT_MATCH_COMPATIBLE("fsl,imx8qxp-lpuart"),
>
> IIUC the binding, the Device-Tree node compatible should have both
> fsl,imx8qm-lpuart and fsl,imx8qxp-lpuart. In fact, the Linux driver
> doesn't recognize the first compatible.
>
> So maybe we can remove the first one.
It's listed in the bindings but the Linux driver indeed never looks for
qm, it should be safe to drop. I'll drop this in V2.
>
> Cheers,
>
Thanks! // John Ernberg
[PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
When using Linux for dom0 there are a bunch of drivers that need to do SMC
SIP calls into the PSCI provider to enable certain hardware bits like the
watchdog.
Provide a basic platform glue that implements the needed SMC forwarding.
Signed-off-by: John Ernberg
---
NOTE: This is based on code found in NXP Xen tree located here:
https://github.com/nxp-imx/imx-xen/blob/lf-5.10.y_4.13/xen/arch/arm/platforms/imx8qm.c
xen/arch/arm/platforms/Makefile | 1 +
xen/arch/arm/platforms/imx8qm.c | 65 +
2 files changed, 66 insertions(+)
create mode 100644 xen/arch/arm/platforms/imx8qm.c
diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 8632f4115f..bec6e55d1f 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT) += sunxi.o
obj-$(CONFIG_ALL64_PLAT) += thunderx.o
obj-$(CONFIG_ALL64_PLAT) += xgene-storm.o
obj-$(CONFIG_ALL64_PLAT) += brcm-raspberry-pi.o
+obj-$(CONFIG_ALL64_PLAT) += imx8qm.o
obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp.o
obj-$(CONFIG_MPSOC_PLATFORM) += xilinx-zynqmp-eemi.o
diff --git a/xen/arch/arm/platforms/imx8qm.c b/xen/arch/arm/platforms/imx8qm.c
new file mode 100644
index 00..a9cd9c3615
--- /dev/null
+++ b/xen/arch/arm/platforms/imx8qm.c
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * xen/arch/arm/platforms/imx8qm.c
+ *
+ * i.MX 8QM setup
+ *
+ * Copyright (c) 2016 Freescale Inc.
+ * Copyright 2018-2019 NXP
+ *
+ *
+ * Peng Fan
+ */
+
+#include
+#include
+
+static const char * const imx8qm_dt_compat[] __initconst =
+{
+"fsl,imx8qm",
+"fsl,imx8qxp",
+NULL
+};
+
+static bool imx8qm_smc(struct cpu_user_regs *regs)
+{
+struct arm_smccc_res res;
+
+if ( !cpus_have_const_cap(ARM_SMCCC_1_1) )
+{
+printk_once(XENLOG_WARNING "no SMCCC 1.1 support. Disabling firmware
calls\n");
+
+return false;
+}
+
+arm_smccc_1_1_smc(get_user_reg(regs, 0),
+ get_user_reg(regs, 1),
+ get_user_reg(regs, 2),
+ get_user_reg(regs, 3),
+ get_user_reg(regs, 4),
+ get_user_reg(regs, 5),
+ get_user_reg(regs, 6),
+ get_user_reg(regs, 7),
+ );
+
+set_user_reg(regs, 0, res.a0);
+set_user_reg(regs, 1, res.a1);
+set_user_reg(regs, 2, res.a2);
+set_user_reg(regs, 3, res.a3);
+
+return true;
+}
+
+PLATFORM_START(imx8qm, "i.MX 8")
+.compatible = imx8qm_dt_compat,
+.smc = imx8qm_smc,
+PLATFORM_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--
2.43.0
[PATCH 2/2] xen/drivers: imx-lpuart: Add iMX8QXP compatible
Allow the uart to probe also with iMX8QXP. The ip-block is the same as in the
QM,
only the compatible is needed.
Signed-off-by: John Ernberg
---
xen/drivers/char/imx-lpuart.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/drivers/char/imx-lpuart.c b/xen/drivers/char/imx-lpuart.c
index 77f70c2719..c85e81109a 100644
--- a/xen/drivers/char/imx-lpuart.c
+++ b/xen/drivers/char/imx-lpuart.c
@@ -257,6 +257,7 @@ static int __init imx_lpuart_init(struct dt_device_node
*dev,
static const struct dt_device_match imx_lpuart_dt_compat[] __initconst =
{
DT_MATCH_COMPATIBLE("fsl,imx8qm-lpuart"),
+DT_MATCH_COMPATIBLE("fsl,imx8qxp-lpuart"),
{ /* sentinel */ },
};
--
2.43.0
[PATCH 0/2] Xen: ARM: Improved NXP iMX8 platform support
The iMX lpuart driver added at 44e17aa60d47 ("xen/arm: Add i.MX lpuart driver")
is not enough to boot a Linux based dom0 when certain drivers, such as the
watchdog driver, are enabled.
We're also adding iMX8QXP compatibles to allow Xen to use the UART on the
QXP variant as well.
John Ernberg (2):
xen/arm: Add imx8q{m,x} platform glue
xen/drivers: imx-lpuart: Add iMX8QXP compatible
xen/arch/arm/platforms/Makefile | 1 +
xen/arch/arm/platforms/imx8qm.c | 65 +
xen/drivers/char/imx-lpuart.c | 1 +
3 files changed, 67 insertions(+)
create mode 100644 xen/arch/arm/platforms/imx8qm.c
--
2.43.0
