RE: [PATCH v18 05/19] ACPI:RAS2: Add ACPI RAS2 driver

[Shiju Jose <shiju.jose@huawei.com>]

>-----Original Message-----
>From: Daniel Ferguson <danielf@os.amperecomputing.com>
>Sent: 21 January 2025 23:01
>To: Shiju Jose <shiju.jose@huawei.com>; linux-edac@vger.kernel.org; linux-
>cxl@vger.kernel.org; linux-acpi@vger.kernel.org; linux-mm@kvack.org; linux-
>kernel@vger.kernel.org
>Cc: bp@alien8.de; tony.luck@intel.com; rafael@kernel.org; lenb@kernel.org;
>mchehab@kernel.org; dan.j.williams@intel.com; dave@stgolabs.net; Jonathan
>Cameron <jonathan.cameron@huawei.com>; dave.jiang@intel.com;
>alison.schofield@intel.com; vishal.l.verma@intel.com; ira.weiny@intel.com;
>david@redhat.com; Vilas.Sridharan@amd.com; leo.duran@amd.com;
>Yazen.Ghannam@amd.com; rientjes@google.com; jiaqiyan@google.com;
>Jon.Grimm@amd.com; dave.hansen@linux.intel.com;
>naoya.horiguchi@nec.com; james.morse@arm.com; jthoughton@google.com;
>somasundaram.a@hpe.com; erdemaktas@google.com; pgonda@google.com;
>duenwen@google.com; gthelen@google.com;
>wschwartz@amperecomputing.com; dferguson@amperecomputing.com;
>wbs@os.amperecomputing.com; nifan.cxl@gmail.com; tanxiaofei
><tanxiaofei@huawei.com>; Zengtao (B) <prime.zeng@hisilicon.com>; Roberto
>Sassu <roberto.sassu@huawei.com>; kangkang.shen@futurewei.com;
>wanghuiqiang <wanghuiqiang@huawei.com>; Linuxarm
><linuxarm@huawei.com>
>Subject: Re: [PATCH v18 05/19] ACPI:RAS2: Add ACPI RAS2 driver
>
>
>
>On 1/6/2025 4:10 AM, shiju.jose@huawei.com wrote:
>> +static int ras2_report_cap_error(u32 cap_status) {
>> +	switch (cap_status) {
>> +	case ACPI_RAS2_NOT_VALID:
>> +	case ACPI_RAS2_NOT_SUPPORTED:
>> +		return -EPERM;
>> +	case ACPI_RAS2_BUSY:
>> +		return -EBUSY;
>> +	case ACPI_RAS2_FAILED:
>> +	case ACPI_RAS2_ABORTED:
>> +	case ACPI_RAS2_INVALID_DATA:
>> +		return -EINVAL;
>> +	default: /* 0 or other, Success */
>> +		return 0;
>> +	}
>> +}
>> +
>> +static int ras2_check_pcc_chan(struct ras2_pcc_subspace
>> +*pcc_subspace) {
>> +	struct acpi_ras2_shared_memory __iomem *generic_comm_base =
>pcc_subspace->pcc_comm_addr;
>> +	ktime_t next_deadline = ktime_add(ktime_get(), pcc_subspace-
>>deadline);
>> +	u32 cap_status;
>> +	u16 status;
>> +	u32 ret;
>> +
>> +	while (!ktime_after(ktime_get(), next_deadline)) {
>> +		/*
>> +		 * As per ACPI spec, the PCC space will be initialized by
>> +		 * platform and should have set the command completion bit
>when
>> +		 * PCC can be used by OSPM
>> +		 */
>> +		status = readw_relaxed(&generic_comm_base->status);
>> +		if (status & RAS2_PCC_CMD_ERROR) {
>> +			cap_status = readw_relaxed(&generic_comm_base-
>>set_capabilities_status);
>> +			ret = ras2_report_cap_error(cap_status);
>
>There is some new information:
>
>The Scrub parameter block intends to get its own Status field, and the
>set_capabilities_status field is being deprecated. This also causes a revision
>bump in the spec.
>
>See [1]
>
>Assuming this change is ratified (not guaranteed, still pending):
>This change implies that we cannot centrally decode errors, as is done here and
>now. Instead error decoding must be done after some feature-specific routine
>calls ras2_send_pcc_cmd. It should be the case that each new feature, moving
>forward, will likely have their own status.
>
>Please see my follow up comment on [PATCH v18 06/19]
>
>---
>[1] https://github.com/tianocore/edk2/issues/10540

Hi Daniel,

Thanks for the information and suggested modifications.

We will track the change and assuming it lands as an ECN
will try to add support in backwards compatible fashion.

>---
>
>> +
[...]
>
Thanks,
Shiju