alert_L module for handling oob alerts #143

nchatrad · 2025-06-13T07:48:56Z

splitting the previous PR 135

arch/arm64/boot/dts/aspeed/aspeed-bmc-amd-congo.dts

Documentation/devicetree/bindings/misc/amd,apml-alertl.yaml

include/uapi/linux/amd-apml.h

mahkurap

Please add apml_alert dts changes in Kenya and Nigeria device trees as well.
Also, change congo to Congo, morcco to Morocco in one of the commit message.

mahkurap · 2025-06-24T14:57:20Z

drivers/misc/amd-apml/apml_alertl.c

+		.of_match_table = of_match_ptr(apml_alertl_dt_ids),
+	},
+	.probe		= apml_alertl_probe,
+	.remove		= alert_remove,


for uniformity, change alret_remove to apml_alaertl_remove()

drivers/misc/amd-apml/apml_alertl.c

ojayanth · 2025-06-25T11:31:03Z

drivers/misc/amd-apml/apml_alertl.c

+	 * 0x3c, 0x4c	-> Socket 0, die 0,
+	 * 0x44		-> Socket 0, die 1,
+	 * 0x38, 0x48	-> Socket 1, die 0,
+	 * 0x4c		-> Socket 1, die 1.


Typo ? 0x45?

Yes, corrected

ojayanth · 2025-06-25T11:33:17Z

drivers/misc/amd-apml/apml_alertl.c

+	return ret;
+}
+
+static u8 static_addr_to_socket(u8 static_addr)


Is this rule is valid incase 2X1P configuration boot .

As per my understanding
2X1P and 2P can be used interchangeably.
As the PID and static address are related to Socket and Die ID which are stored in CSR registers(RO)
This should be valid.

ojayanth · 2025-06-25T11:40:37Z

drivers/misc/amd-apml/apml_alertl.c

+	return 0;
+}
+
+static irqreturn_t alert_l_irq_thread_handler(int irq, void *dev_id)


Error Handling , general: Since this is alert handling, it's better to follow a best-effort approach for error handling?

Thanks for the input.
Update the same

ojayanth · 2025-06-25T11:44:44Z

arch/arm64/boot/dts/aspeed/aspeed-bmc-amd-congo.dts

 #endif
 };

+/ {


Commit message : start with ARM64:dts:aspeed:

ojayanth · 2025-06-25T11:48:07Z

Documentation/devicetree/bindings/misc/amd,apml-alertl.yaml

@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)


Commit message Please align with upstream style : dt-bindings: misc: apml-alert

ojayanth · 2025-06-25T12:15:13Z

Please ensure your commit message style aligns with the conventions used in the relevant upstream directory

mahkurap · 2025-08-11T22:04:35Z

Documentation/devicetree/bindings/misc/amd,apml-alertl.yaml

+  gpio:
+    maxItems: 1
+    description: |
+	GPIO specifier for APML Alert_L line. Specify GPIO controller, GPIO pin


nit: white space?

will update, thanks

mahkurap · 2025-08-11T22:09:22Z

drivers/misc/amd-apml/apml_alertl.c

+
+MODULE_ALIAS("apml_alertl:" DRIVER_NAME);
+
+/* Read TSI Status register to identify the RAS error */


nit: correct the comment

drivers/misc/amd-apml/apml_alertl.c

mahkurap · 2025-08-11T22:24:04Z

drivers/misc/amd-apml/apml_alertl.c

+		return IRQ_NONE;
+
+	for (i = 0; i < oob_adata->num_of_tsi_devs; i++) {
+		rt_src = 0;


nit: can be removed. no effect statement

mahkurap · 2025-08-11T22:25:08Z

drivers/misc/amd-apml/apml_alertl.c

+		rt_src = 0;
+		/* Check for NULL pointer */
+		if (IS_ERR_OR_NULL(oob_adata->tsi_dev[i])) {
+			dev_err(dev, "TSI device does not exist\n");


Add "i", and any other data to the log, will be more helpful during debug.

Sure, added

mahkurap · 2025-08-11T22:28:15Z

drivers/misc/amd-apml/apml_alertl.c

+	msg.data_in.reg_in[REG_OFF_INDEX] = TSI_STATUS_REG;
+
+	mutex_lock(&oob_adata->tsi_dev[soc_die_num]->lock);
+	ret = regmap_read(oob_adata->tsi_dev[soc_die_num]->regmap,


if the regmap_read() fails for any reason, does *temp_status set to zero?

temp_status is initialized to zero

temp_status is initialized outside of the for loop(). In case of failures, we are checking the previously returned by the previous iteration.

mahkurap · 2025-08-11T22:29:38Z

drivers/misc/amd-apml/apml_alertl.c

+		/* Check for TSI alert */
+		ret = tsi_alert_check(oob_adata, &temp_status, i);
+		if (ret < 0)
+			dev_err(dev, "Failed to read TSI status register\n");


Additional data in the error logging will be of great help during debugging. Add more context to the logging.

mahkurap · 2025-08-11T22:30:46Z

drivers/misc/amd-apml/apml_alertl.c

+		if (ret < 0)
+			dev_err(dev, "Failed to read TSI status register\n");
+
+		if (!temp_status)


temp_status is not guaranteed to set to zero incase of failures. add this check to the previous check.

temp_status initialized to zero. On failure, temp_status remains zero

mahkurap · 2025-08-11T22:32:33Z

drivers/misc/amd-apml/apml_alertl.c

+		rt_src = (temp_status << 24);
+		static_addr = oob_adata->tsi_dev[i]->dev_static_addr;
+
+		ret = send_uevent(static_addr, rt_src, dev);


rt_src can be replaced with (temp_status << 24). rt_src is not used anywhere else. Same with the variable static_addr.

mahkurap · 2025-08-11T22:34:15Z

drivers/misc/amd-apml/apml_alertl.c

+
+		ret = send_uevent(static_addr, rt_src, dev);
+		if (ret)
+			dev_err(dev, "Failed to send TSI uevent Err: %d\n", ret);


Add (temp_status << 24), and oob_adata->tsi_dev[i]->dev_static_addr to logging.

added more info

mahkurap · 2025-08-11T22:37:11Z

drivers/misc/amd-apml/apml_alertl.c

+	struct device *dev = oob_adata->dev;
+	unsigned int ras_status = 0;
+	unsigned int temp_status = 0;
+	u32 rt_src = 0;


optimization: rt_src, and static_addr variables are not needed/

drivers/misc/amd-apml/apml_alertl.c

mahkurap · 2025-08-11T22:38:27Z

drivers/misc/amd-apml/apml_alertl.c

+
+static irqreturn_t alert_l_irq_thread_handler(int irq, void *dev_id)
+{
+	struct apml_alertl_data *oob_adata = dev_id;


no need to cast?

not necessarily. i have updated. Thanks

mahkurap · 2025-08-11T22:43:43Z

drivers/misc/amd-apml/apml_alertl.c

+
+		/* Check for TSI alert */
+		ret = tsi_alert_check(oob_adata, &temp_status, i);
+		if (ret < 0)


tsi_alrert_check() returns 0 if the input parameters are invalid. Change this condition to "<=" or change the tsi_alert_check() to return a negative integer incase of input error validation.

not required with new changes

mahkurap · 2025-08-11T22:44:24Z

drivers/misc/amd-apml/apml_alertl.c

+	int ret;
+
+	if (!oob_adata->rmi_dev[soc_die_num] || !oob_adata->rmi_dev[soc_die_num]->regmap)
+		return 0;


change to a negative value. 0 return code is ==> success

mahkurap · 2025-08-11T22:45:22Z

drivers/misc/amd-apml/apml_alertl.c

+	int ret;
+
+	if (!oob_adata->tsi_dev[soc_die_num] || !oob_adata->tsi_dev[soc_die_num]->regmap)
+		return 0;


return negative integer in case of error.

drivers/misc/amd-apml/apml_alertl.c

mahkurap

Please check comments.

drivers/misc/amd-apml/Kconfig

ojayanth · 2025-08-12T02:21:42Z

drivers/misc/amd-apml/Kconfig

+    default n
+    help
+      If you say yes here you get support for emulated alertl
+      interface on AMD SoCs with APML interface connected to a BMC device.


NIT:
Alert_L may be asserted for various conditions, including machine check
exceptions, system fatal errors, APML command completions, and thermal
alerts

thanks, updated!

ojayanth · 2025-08-12T02:23:53Z

drivers/misc/amd-apml/apml_alertl.c

@@ -0,0 +1,390 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * alert_l.c - Alert_l driver for AMD APML devices


fix file name apml_alertl.c

done, thanks

ojayanth · 2025-08-12T02:25:16Z

drivers/misc/amd-apml/apml_alertl.c

+/*
+ * alert_l.c - Alert_l driver for AMD APML devices
+ *
+ * Copyright (C) 2022-2023 Advanced Micro Devices, Inc.


ojayanth · 2025-08-12T02:29:16Z

drivers/misc/amd-apml/apml_alertl.c

+ * Copyright (C) 2022-2023 Advanced Micro Devices, Inc.
+ */
+
+#include <linux/debugfs.h>


NIT: reorder based Kernel coding style
Ordering Logic:
Core kernel headers: module.h, init.h
Platform and device-related: platform_device.h, interrupt.h, regmap.h
Peripheral interfaces: gpio, debugfs, i3c
Device tree support: of.h, of_gpio.h
Local headers: "sbrmi-common.h" comes last

#include <linux/module.h>
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/interrupt.h>
#include <linux/regmap.h>
#include <linux/gpio/consumer.h>
#include <linux/debugfs.h>
#include <linux/i3c/device.h>
#include <linux/of.h>
#include <linux/of_gpio.h>

Thanks for the info. We have been following the alphabetical order of arranging headers.

ojayanth · 2025-08-12T02:29:53Z

drivers/misc/amd-apml/apml_alertl.c

+#define DRIVER_NAME "apml_alertl"
+
+#define RAS_STATUS_REG		0x4C
+#define STATUS_REG		0x2


NIT be constient on formating.

mahkurap · 2025-08-13T11:43:58Z

[AMD Official Use Only - AMD Internal Distribution Only] Temp_status is initialized to zero outside of the loop. It will get modified in the for() loop. Imagine a case where in the first iteration of the loop is successful and the second iteration fails. Then we are checking on the temp_status updated in the last successful transaction. From: sathyapk ***@***.***> Sent: Wednesday, August 13, 2025 2:38 AM To: AMDESE/linux-aspeed ***@***.***> Cc: Kurapati, Mahesh ***@***.***>; Review requested ***@***.***> Subject: Re: [AMDESE/linux-aspeed] alert_L module for handling oob alerts (PR #143) Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. @sathyapk commented on this pull request.

________________________________ In drivers/misc/amd-apml/apml_alertl.c<#143 (comment)>:

+ return IRQ_NONE;

+ + for (i = 0; i < oob_adata->num_of_tsi_devs; i++) { + rt_src = 0; + /* Check for NULL pointer */ + if (IS_ERR_OR_NULL(oob_adata->tsi_dev[i])) { + dev_err(dev, "TSI device does not exist\n"); + return IRQ_NONE; + } + + /* Check for TSI alert */ + ret = tsi_alert_check(oob_adata, &temp_status, i); + if (ret < 0) + dev_err(dev, "Failed to read TSI status register\n"); + + if (!temp_status) temp_status initialized to zero. On failure, temp_status remains zero — Reply to this email directly, view it on GitHub<#143 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BCUUIJVER2A6ERYLZVAJHCT3NLTMFAVCNFSM6AAAAAB7HM3CZ2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTCMJUGMYTKNBRGM>. You are receiving this because your review was requested.Message ID: ***@***.******@***.***>>

mahkurap · 2025-08-13T11:47:16Z

[AMD Official Use Only - AMD Internal Distribution Only] How does the apml_library know the structure of the event? Is there a header file defined for it? Imagine a case where in the user wants to use the events directly with out the library interface. Is it not possible? Library also runs in the user space. From: sathyapk ***@***.***> Sent: Wednesday, August 13, 2025 2:39 AM To: AMDESE/linux-aspeed ***@***.***> Cc: Kurapati, Mahesh ***@***.***>; Review requested ***@***.***> Subject: Re: [AMDESE/linux-aspeed] alert_L module for handling oob alerts (PR #143) Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. @sathyapk commented on this pull request.

________________________________ In drivers/misc/amd-apml/apml_alertl.c<#143 (comment)>:

+ char sock[MAX_SOC_LEN];

+ char src[MAX_ERR_LEN]; + char *alert_source[] = { sock, src, NULL }; + + soc_die_num = static_addr_to_socket(static_address); + if (soc_die_num == 0xFF) { + dev_err(dev, "Device static address not valid\n"); + return -ENODEV; + } + + snprintf(sock, sizeof(sock), "Socket=0x%x", soc_die_num); + snprintf(src, sizeof(src), "Source=0x%x", alert_src); + + dev_err(dev, "Sending uevent: Sock:0x%x Src:0x%x\n", + soc_die_num, alert_src); + kobject_uevent_env(&dev->kobj, KOBJ_CHANGE, alert_source); apml_library is the interface to the alert_l driver. user space application should call apml library api's to interpret the data — Reply to this email directly, view it on GitHub<#143 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BCUUIJVI6KJ4DOPVIEDGKOT3NLTRPAVCNFSM6AAAAAB7HM3CZ2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTCMJUGMYTSNZXGM>. You are receiving this because your review was requested.Message ID: ***@***.******@***.***>>

mahkurap · 2025-08-13T11:53:02Z

[AMD Official Use Only - AMD Internal Distribution Only] Bottom halfs are called/handled as part of work queues as far as I remember. I could be wrong. Function tsi_alert_check() is called in “static irqreturn_t alert_l_irq_thread_handler(int irq, void *dev_id)” which is an irq handler. From: sathyapk ***@***.***> Sent: Wednesday, August 13, 2025 2:40 AM To: AMDESE/linux-aspeed ***@***.***> Cc: Kurapati, Mahesh ***@***.***>; Review requested ***@***.***> Subject: Re: [AMDESE/linux-aspeed] alert_L module for handling oob alerts (PR #143) Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. @sathyapk commented on this pull request.

________________________________ In drivers/misc/amd-apml/apml_alertl.c<#143 (comment)>:

+#define MAX_SOC_LEN 11

+#define MAX_ERR_LEN 18 + +MODULE_ALIAS("apml_alertl:" DRIVER_NAME); + +/* Read TSI Status register to identify the RAS error */ +static int tsi_alert_check(struct apml_alertl_data *oob_adata, int *temp_status, u8 soc_die_num) +{ + struct apml_message msg = { 0 }; + int ret; + + if (!oob_adata->tsi_dev[soc_die_num] || !oob_adata->tsi_dev[soc_die_num]->regmap) + return 0; + msg.data_in.reg_in[REG_OFF_INDEX] = TSI_STATUS_REG; + + mutex_lock(&oob_adata->tsi_dev[soc_die_num]->lock); Lock is called inthe bottom half of the irq, mutex lock can be invoked in bottom half. — Reply to this email directly, view it on GitHub<#143 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BCUUIJUEFFVKKDKFMC2L3CT3NLTVRAVCNFSM6AAAAAB7HM3CZ2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTCMJUGMZDEOBVGU>. You are receiving this because your review was requested.Message ID: ***@***.******@***.***>>

mahkurap · 2025-08-13T11:59:34Z

[AMD Official Use Only - AMD Internal Distribution Only] I need to understand more on how the mutexes initialized in a different driver can be accessed in this driver. Something new for me. How do you enforce the probe order()? First sbrmi, sbtsi and then apml_alertl? From: sathyapk ***@***.***> Sent: Wednesday, August 13, 2025 2:45 AM To: AMDESE/linux-aspeed ***@***.***> Cc: Kurapati, Mahesh ***@***.***>; Review requested ***@***.***> Subject: Re: [AMDESE/linux-aspeed] alert_L module for handling oob alerts (PR #143) Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. @sathyapk commented on this pull request.

________________________________ In drivers/misc/amd-apml/apml_alertl.c<#143 (comment)>:

+ /* Allocate memory as per the number of TSI devices */

+ tsi_dev = devm_kzalloc(dev, oob_alert->num_of_tsi_devs * sizeof(struct apml_sbtsi_device), + GFP_KERNEL); + if (!tsi_dev) + return -ENOMEM; + + oob_alert->tsi_dev = tsi_dev; + oob_alert->dev = dev; + + /* + * For each of the Alerts get the device associated + * Currently the ALert_L driver identification is only supported + * over I3C. We can add property in dts to identify the bus type + */ + + for (i = 0; i < oob_alert->num_of_rmi_devs; i++) { The mutex locks are initialized in respective RMI and TSI drivers. — Reply to this email directly, view it on GitHub<#143 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BCUUIJTJHUOSPXIDWSXSLEL3NLUI5AVCNFSM6AAAAAB7HM3CZ2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTCMJUGM2DCNRTHA>. You are receiving this because your review was requested.Message ID: ***@***.******@***.***>>

sathyapk · 2025-08-18T09:16:50Z

[AMD Official Use Only - AMD Internal Distribution Only] Temp_status is initialized to zero outside of the loop. It will get modified in the for() loop. Imagine a case where in the first iteration of the loop is successful and the second iteration fails. Then we are checking on the temp_status updated in the last successful transaction. From: sathyapk @.> Sent: Wednesday, August 13, 2025 2:38 AM To: AMDESE/linux-aspeed @.> Cc: Kurapati, Mahesh @.>; Review requested @.> Subject: Re: [AMDESE/linux-aspeed] alert_L module for handling oob alerts (PR #143) Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. @sathyapk commented on this pull request.
________________________________ In drivers/misc/amd-apml/apml_alertl.c<#143 (comment)>:

return IRQ_NONE;

for (i = 0; i < oob_adata->num_of_tsi_devs; i++) { + rt_src = 0; + /* Check for NULL pointer / + if (IS_ERR_OR_NULL(oob_adata->tsi_dev[i])) { + dev_err(dev, "TSI device does not exist\n"); + return IRQ_NONE; + } + + / Check for TSI alert / + ret = tsi_alert_check(oob_adata, &temp_status, i); + if (ret < 0) + dev_err(dev, "Failed to read TSI status register\n"); + + if (!temp_status) temp_status initialized to zero. On failure, temp_status remains zero — Reply to this email directly, view it on GitHub<#143 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BCUUIJVER2A6ERYLZVAJHCT3NLTMFAVCNFSM6AAAAAB7HM3CZ2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTCMJUGMYTKNBRGM. You are receiving this because your review was requested.Message ID: @.@.*>>

This is a miss, thanks for pointing it out. I will fix this.

sathyapk · 2025-08-18T11:57:26Z

[AMD Official Use Only - AMD Internal Distribution Only] Bottom halfs are called/handled as part of work queues as far as I remember. I could be wrong. Function tsi_alert_check() is called in “static irqreturn_t alert_l_irq_thread_handler(int irq, void dev_id)” which is an irq handler. From: sathyapk @.> Sent: Wednesday, August 13, 2025 2:40 AM To: AMDESE/linux-aspeed @.> Cc: Kurapati, Mahesh @.>; Review requested @.> Subject: Re: [AMDESE/linux-aspeed] alert_L module for handling oob alerts (PR #143) Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. @sathyapk commented on this pull request.
________________________________ In drivers/misc/amd-apml/apml_alertl.c<#143 (comment)>:
+#define MAX_SOC_LEN 11
+#define MAX_ERR_LEN 18 + +MODULE_ALIAS("apml_alertl:" DRIVER_NAME); + +/ Read TSI Status register to identify the RAS error / +static int tsi_alert_check(struct apml_alertl_data oob_adata, int temp_status, u8 soc_die_num) +{ + struct apml_message msg = { 0 }; + int ret; + + if (!oob_adata->tsi_dev[soc_die_num] || !oob_adata->tsi_dev[soc_die_num]->regmap) + return 0; + msg.data_in.reg_in[REG_OFF_INDEX] = TSI_STATUS_REG; + + mutex_lock(&oob_adata->tsi_dev[soc_die_num]->lock); Lock is called inthe bottom half of the irq, mutex lock can be invoked in bottom half. — Reply to this email directly, view it on GitHub<#143 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BCUUIJUEFFVKKDKFMC2L3CT3NLTVRAVCNFSM6AAAAAB7HM3CZ2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTCMJUGMZDEOBVGU. You are receiving this because your review was requested.Message ID: @.@.***>>

There are multiple ways to implement bottom half, like softirqs, tasklets, workqueue, threaded irq handler.
We are using threaded IRQ.

sathyapk · 2025-08-18T12:07:04Z

[AMD Official Use Only - AMD Internal Distribution Only] I need to understand more on how the mutexes initialized in a different driver can be accessed in this driver. Something new for me. How do you enforce the probe order()? First sbrmi, sbtsi and then apml_alertl? From: sathyapk @.> Sent: Wednesday, August 13, 2025 2:45 AM To: AMDESE/linux-aspeed @.> Cc: Kurapati, Mahesh @.>; Review requested @.> Subject: Re: [AMDESE/linux-aspeed] alert_L module for handling oob alerts (PR #143) Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. @sathyapk commented on this pull request.
________________________________ In drivers/misc/amd-apml/apml_alertl.c<#143 (comment)>:

/* Allocate memory as per the number of TSI devices */

tsi_dev = devm_kzalloc(dev, oob_alert->num_of_tsi_devs * sizeof(struct apml_sbtsi_device), + GFP_KERNEL); + if (!tsi_dev) + return -ENOMEM; + + oob_alert->tsi_dev = tsi_dev; + oob_alert->dev = dev; + + /* + * For each of the Alerts get the device associated + * Currently the ALert_L driver identification is only supported + * over I3C. We can add property in dts to identify the bus type + / + + for (i = 0; i < oob_alert->num_of_rmi_devs; i++) { The mutex locks are initialized in respective RMI and TSI drivers. — Reply to this email directly, view it on GitHub<#143 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BCUUIJTJHUOSPXIDWSXSLEL3NLUI5AVCNFSM6AAAAAB7HM3CZ2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTCMJUGM2DCNRTHA. You are receiving this because your review was requested.Message ID: @.@.*>>

Alert_l driver is dependent on rmi and tsi driver taken care in Kconfig
Probing of rmi/tsi device are not part of Alert_L driver. Alert_L driver only access the rmi/tsi device structure info updated during rmi/tsi driver init(probe).

arch/arm64/boot/dts/aspeed/aspeed-bmc-amd-congo.dts

Move out the sbtsi device structure to a common header file and add device matching helper function for I2C and I3C buses. This is required to add support for the APML Alert_L module which needs access to sbtsi device struct and device matching capability. Reviewed-by: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com> Signed-off-by: Akshay Gupta <akshay.gupta@amd.com>

Processors from AMD provide APML ALERT_L for BMC users to monitor events. APML Alert_L is asserted in multiple events, - Machine Check Exception occurs within the system - The processor alerts the SBI on system fatal error event - Set by hardware as a result of a 0x71/0x72/0x73 command completion - Set by firmware to indicate the completion of a mailbox operation - High/Low Temperature Alert APML Alert_L module define uevents to notify registered userspace processes of the alert event. Reviewed-by: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com> Signed-off-by: Akshay Gupta <akshay.gupta@amd.com> Signed-off-by: sathya priya kumar <SathyaPriya.K@amd.com>

-Add alertl node for P1 and P2 host processor in Morocco platform. -Add alertl node for P1 host processor in Congo platform. Reviewed-by: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com> Signed-off-by: Akshay Gupta <akshay.gupta@amd.com> Signed-off-by: sathya priya kumar <SathyaPriya.K@amd.com>

-Add alertl node for P1 and P2 host processor in Nigeria platform. -Add alertl node for P1 host processor in Kenya platform. Reviewed-by: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com> Signed-off-by: Akshay Gupta <akshay.gupta@amd.com> Signed-off-by: sathya priya kumar <SathyaPriya.K@amd.com>

-Document device-tree bindings for APML Alert_L driver. Reviewed-by: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com> Signed-off-by: Akshay Gupta <akshay.gupta@amd.com> Signed-off-by: sathya priya kumar <SathyaPriya.K@amd.com> (cherry picked from commit 0f54429)

nchatrad mentioned this pull request Jun 13, 2025

Review apml modules venice a0 #135

Open

akky16 requested review from mahkurap, modolaty, ojayanth, srgovard and supven01 June 23, 2025 03:36

mahkurap reviewed Jun 24, 2025

View reviewed changes

arch/arm64/boot/dts/aspeed/aspeed-bmc-amd-congo.dts Show resolved Hide resolved

mahkurap reviewed Jun 24, 2025

View reviewed changes

Documentation/devicetree/bindings/misc/amd,apml-alertl.yaml Show resolved Hide resolved

mahkurap reviewed Jun 24, 2025

View reviewed changes

Documentation/devicetree/bindings/misc/amd,apml-alertl.yaml Show resolved Hide resolved

mahkurap reviewed Jun 24, 2025

View reviewed changes

include/uapi/linux/amd-apml.h Outdated Show resolved Hide resolved

mahkurap requested changes Jun 24, 2025

View reviewed changes

ojayanth requested changes Jun 25, 2025

View reviewed changes

nchatrad force-pushed the alert_l branch from df50afb to b89dc6e Compare August 5, 2025 14:42

mahkurap reviewed Aug 11, 2025

View reviewed changes

drivers/misc/amd-apml/apml_alertl.c Outdated Show resolved Hide resolved

mahkurap reviewed Aug 11, 2025

View reviewed changes

drivers/misc/amd-apml/apml_alertl.c Show resolved Hide resolved

mahkurap reviewed Aug 11, 2025

View reviewed changes

drivers/misc/amd-apml/apml_alertl.c Show resolved Hide resolved

mahkurap reviewed Aug 12, 2025

View reviewed changes

drivers/misc/amd-apml/apml_alertl.c Show resolved Hide resolved

mahkurap requested changes Aug 12, 2025

View reviewed changes

ojayanth reviewed Aug 12, 2025

View reviewed changes

akky16 force-pushed the alert_l branch from b89dc6e to 621cbb1 Compare August 19, 2025 13:51

sathyapk force-pushed the alert_l branch from 621cbb1 to 0ab4cf6 Compare August 21, 2025 14:45

sathyapk force-pushed the alert_l branch from 0ab4cf6 to 70a9caf Compare September 9, 2025 09:22

mahkurap requested changes Sep 23, 2025

View reviewed changes

arch/arm64/boot/dts/aspeed/aspeed-bmc-amd-congo.dts Outdated Show resolved Hide resolved

sathyapk force-pushed the alert_l branch from 70a9caf to fd0f0d4 Compare September 26, 2025 09:14

akky16 and others added 4 commits September 30, 2025 10:34

sathyapk force-pushed the alert_l branch from fd0f0d4 to f92762f Compare September 30, 2025 05:17

mahkurap approved these changes Oct 15, 2025

View reviewed changes

srgovard approved these changes Oct 24, 2025

View reviewed changes

srgovard requested a review from ojayanth October 24, 2025 04:45

ojayanth approved these changes Oct 24, 2025

View reviewed changes

srgovard merged commit b27b7e8 into dev-a1 Oct 24, 2025

srgovard deleted the alert_l branch October 24, 2025 21:33

srgovard mentioned this pull request Oct 24, 2025

Revert "alert_L module for handling oob alerts" #190

Merged

sathyapk mentioned this pull request Nov 20, 2025

Alert_l: Modify APML ALERT_L to remove the dependency of RMI/TSI dts device node. #202

Open

               #endif
               };
+              / {

		@@ -0,0 +1,50 @@
		# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)


		MODULE_ALIAS("apml_alertl:" DRIVER_NAME);

		/* Read TSI Status register to identify the RAS error */

alert_L module for handling oob alerts #143

alert_L module for handling oob alerts #143

Uh oh!

Conversation

nchatrad commented Jun 13, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mahkurap left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ojayanth commented Jun 25, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mahkurap Aug 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mahkurap Aug 11, 2025 •

edited

Loading