alert_L module for handling oob alerts #143
Conversation
platform driver 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 <[email protected]> Signed-off-by: Akshay Gupta <[email protected]> Signed-off-by: sathya priya kumar <[email protected]>
-Add alertl node for morocco and congo platforms Reviewed-by: Naveen Krishna Chatradhi <[email protected]> Signed-off-by: Akshay Gupta <[email protected]> Signed-off-by: Sathya Priya Kumar <[email protected]>
Reviewed-by: Naveen Krishna Chatradhi <[email protected]> Signed-off-by: Akshay Gupta <[email protected]> Signed-off-by: sathya priya kumar <[email protected]> (cherry picked from commit 0f54429)
| status = "okay"; | ||
| gpios = <<pi0_gpio 20 GPIO_ACTIVE_LOW>; | ||
| sbrmi = <&sbrmi_p0_iod0>; | ||
| sbtsi = <&sbtsi_p0_iod0>; |
There was a problem hiding this comment.
why is &sbtsi_p0_iod1 missing for Congo platforms?
| required: | ||
| - compatible | ||
| - gpio | ||
| - sbrmi |
There was a problem hiding this comment.
please add more description for these tags. Like what is the input, parameters.. etc.
| - compatible | ||
| - gpio | ||
| - sbrmi | ||
| - sbtsi |
There was a problem hiding this comment.
I saw that in Congo there is only iod0 is mentioned, and in morocco iod1 also mentioned. Please explain more here on the parameters for this tag.
| #define BIT(n) (1U << (n)) | ||
| #endif | ||
|
|
||
| enum apml_ras_alert_src { |
There was a problem hiding this comment.
why are we calling this ras alert?
| .of_match_table = of_match_ptr(apml_alertl_dt_ids), | ||
| }, | ||
| .probe = apml_alertl_probe, | ||
| .remove = alert_remove, |
There was a problem hiding this comment.
for uniformity, change alret_remove to apml_alaertl_remove()
| return 0; | ||
| } | ||
|
|
||
| static int alert_remove(struct platform_device *pdev) |
There was a problem hiding this comment.
change name to apml_alertl_remove()
|
|
||
| snprintf(sock, sizeof(sock), "Socket=0x%x", soc_die_num); | ||
| snprintf(src, sizeof(src), "Source=0x%x", alert_src); | ||
| pr_err("apml_alertl:Sock:0x%x Src:0x%x\n", soc_die_num, alert_src); |
There was a problem hiding this comment.
do you mean to have pr_err() here? should it be pr_dbg()?
| * 0x3c, 0x4c -> Socket 0, die 0, | ||
| * 0x44 -> Socket 0, die 1, | ||
| * 0x38, 0x48 -> Socket 1, die 0, | ||
| * 0x4c -> Socket 1, die 1. |
| return ret; | ||
| } | ||
|
|
||
| static u8 static_addr_to_socket(u8 static_addr) |
There was a problem hiding this comment.
Is this rule is valid incase 2X1P configuration boot .
There was a problem hiding this comment.
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.
| return 0; | ||
| } | ||
|
|
||
| static irqreturn_t alert_l_irq_thread_handler(int irq, void *dev_id) |
There was a problem hiding this comment.
Error Handling , general: Since this is alert handling, it's better to follow a best-effort approach for error handling?
| @@ -894,6 +894,17 @@ | |||
| #endif | |||
| }; | |||
|
|
|||
| / { | |||
There was a problem hiding this comment.
Commit message : start with ARM64:dts:aspeed:
| @@ -0,0 +1,50 @@ | |||
| # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) | |||
There was a problem hiding this comment.
Commit message Please align with upstream style : dt-bindings: misc: apml-alert
|
Please ensure your commit message style aligns with the conventions used in the relevant upstream directory |
splitting the previous PR 135