Skip to content

Conversation

@sathyapk
Copy link
Collaborator

The PR has AMD APML Alert_L driver architecture by replacing static device tree-based device discovery with a dynamic, centralized device registration system. This enhancement improves maintainability, reduces DTS complexity, and enables flexible multi-socket configurations.

Key changes:

  1. Add centralized device registration system for AMD APML devices. Provides global
    device list where SBRMI and SBTSI drivers can register themselves, enabling the Alert_L driver
    to discover and safely process alerts from registered devices.
  2. Remove explicit sbrmi and sbtsi device references from Alert_L device tree nodes.
  3. Add device registration/unregistration calls to SBTSI/SBRMI drivers during probe/remove.

Existing implementation #143 - Reviewed and tested:
a70993b dt-bindings: misc: apml-alertl: Add APML Alert_L bindings
dc5a9b9 arm64: dts: aspeed: Alert_L changes for Kenya & Nigeria
cd8ab36 arm64: dts: aspeed: Alert_L changes for Morocco & Congo
d46dd8b misc: amd-apml: Add support for AMD APML Alert_L platform driver
7e25856 misc: amd-apml: Create common header for sbtsi device

New dynamic discovery design changes:

a3cab62 misc: amd-apml: Update Alert_L driver to use global device registry
5edd96b misc: amd-apml: Integrate SBRMI with common device registration framework
05e6627 misc: amd-apml: Integrate SBTSI with common device registration framework
a9bb359 misc: amd-apml: Add common device registration framework
cbbea02 arm64: dts: aspeed: Update alert_l node for Nigeria and Kenya
0a39fca arm64: dts: aspeed: Update alert_l node for Morocco & Congo

Attaching test report from QA: Tested on 1P and 2P sytsems
Alertl_Test_Report.xlsx

akky16 and others added 5 commits November 20, 2025 08:57
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)
Copy link
Collaborator

@nchatrad nchatrad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reviewed offline,
this changeset avoids the need for dts in alert_l module. makes it more scalable for multihost type setups aswell

Remove explicit sbrmi and sbtsi device references from Alert_L device
tree nodes. The updated Alert_L driver now uses dynamic device discovery
through the global APML device registry instead of DTS-based device parsing.

Reviewed-by: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com>
Signed-off-by: sathya priya kumar <SathyaPriya.K@amd.com>
Signed-off-by: Akshay Gupta <akshay.gupta@amd.com>
Remove explicit sbrmi and sbtsi device references from Alert_L device
tree nodes. The updated Alert_L driver now uses dynamic device discovery
through the global APML device registry instead of DTS-based device parsing.

Reviewed-by: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com>
Signed-off-by: sathya priya kumar <SathyaPriya.K@amd.com>
Signed-off-by: Akshay Gupta <akshay.gupta@amd.com>
Add centralized device registration system for AMD APML devices.
Provides global device list where SBRMI and SBTSI drivers can
register themselves, enabling the Alert_L driver to discover and
safely process alerts from registered devices.

Reviewed-by: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com>
Signed-off-by: sathya priya kumar <SathyaPriya.K@amd.com>
Signed-off-by: Akshay Gupta <akshay.gupta@amd.com>
…work

Add device registration/unregistration calls to SBTSI drivers. This
enables Alert_L driver to discover and safely access registered TSI
devices for processing temperature alerts.

Reviewed-by: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com>
Signed-off-by: sathya priya kumar <SathyaPriya.K@amd.com>
Signed-off-by: Akshay Gupta <akshay.gupta@amd.com>
…work

Add device registration/unregistration calls to SBRMI drivers. This
enables Alert_L driver to discover and safely access registered RMI
devices for processing RAS event.

Reviewed-by: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com>
Signed-off-by: sathya priya kumar <SathyaPriya.K@amd.com>
Signed-off-by: Akshay Gupta <akshay.gupta@amd.com>
@sathyapk sathyapk force-pushed the alertl-nodts branch 2 times, most recently from 954ada6 to 73f75f1 Compare November 26, 2025 13:23
Modify device tree-based device discovery in Alert_L driver with
centralized device registry from apml_common module. This provides
more reliable to sbrmi/sbtsi device access for processing alerts
and eliminates DTS parsing.

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 changes 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>
gpios = <&ltpi0_gpio 20 GPIO_ACTIVE_LOW>;
sbrmi = <&sbrmi_p0_iod0>;
sbtsi = <&sbtsi_p0_iod0>;
socket-num = /bits/ 8 <1>;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the earlier change there is a mention about sbtsi device on the socket 0. A generic question, if this alert_l line is used for communication with the SBTSI as well, I think this should be mentioned in the description along with SBRMI.


dev_dbg(dev, "Sending uevent: Sock:0x%x Src:0x%x\n",
soc_die_num, alert_src);
dev_info(dev, "Sending uevent: addr:0x%x Src:0x%08x\n bus:%d pid: 0x%llx\n",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change this to dev_dbg() so that the user can enable the logging at runtime if needed for debug purposes. Otherwise for every uevent log might overwhelm the journalctl.


/* Send a uevent to userspace for an APML alert */
static int send_uevent(u8 static_address, u32 alert_src, struct device *dev)
static int send_uevent(u8 address, u8 bus_num, u32 alert_src,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how about adding a comment on what is alert_src, and how it is different from address? Is the alret_src the gpio number? Should the user space application need to know about it? All the user space application should know about is the PID, and the socket number. I dont think the user space application need to know about the bus_num also. I dont want to question the requirements at this point, late in the game.

int ret;

dev = oob_adata->dev;
mutex_lock(&apml_devices_lock);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add a comment which describes the reason to have a top level mutex for all the APML devices, and an individual lock for RMI and TSI.

dev = oob_adata->dev;
mutex_lock(&apml_devices_lock);
list_for_each_entry(device_node, &apml_devices, list) {
/* Get a safe reference to the device node */
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: indentation

/* APML_ALERTL Sends uevent to userspace for temparature
/* APML_ALERTL Sends uevent to userspace for temperature
* alert and RAS (fatal and non-fatal) error, including
* environmental data such as socket/die and alertl source
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the uevent does not contain the socket/die numbers. do we need correct the comment here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants