[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3d79dd24-b11b-7a21-d24b-3c6f85d54c0a@huawei.com>
Date: Fri, 21 Nov 2025 10:40:30 +0800
From: Hanjun Guo <guohanjun@...wei.com>
To: Will Deacon <will@...nel.org>, Punit Agrawal
<punit.agrawal@....qualcomm.com>
CC: <catalin.marinas@....com>, <chenl311@...natelecom.cn>,
<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm64: acpi: Fix incorrect check for default console
message
On 2025/10/30 22:21, Will Deacon wrote:
> On Mon, Oct 27, 2025 at 02:19:41PM +0000, Punit Agrawal wrote:
>> bad3fa2fb920 ("ACPI: Suppress misleading SPCR console message when
>> SPCR table is absent") mistakenly assumes acpi_parse_spcr() returning
>> 0 to indicate a failure to parse SPCR and prints a message to the
>> kernel logs accordingly. In reality acpi_parse_spcr() returns 0 on
>> success and -ERRNO on failure.
>>
>> Fix the faulty check to output the correct logging message.
>>
>> Fixes: bad3fa2fb920 ("ACPI: Suppress misleading SPCR console message when SPCR table is absent")
>> Signed-off-by: Punit Agrawal <punit.agrawal@....qualcomm.com>
>> ---
>> Hi,
>>
>> After sending a patch to fix incorrect parsing of SPCR[0], I was still
>> seeing inconsistent logging on arm64. The result is this nugget.
>>
>> Considering the pointless churn - I wondered if it isn't better to
>> drop the message? If others agree, I can send a patch (and revert
>> bad3fa2fb920 while at it).
>
> I'd be happy dropping the message as it looks pretty useless to me,
> especially given that the current logic is broken.
Fine with me as well, in the acpi_parse_spcr() there is a default
pr_info() for the console information, we can drop it here.
Thanks
Hanjun
Powered by blists - more mailing lists