From: Mario Limonciello <superm1@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: "Jean Delvare" <jdelvare@suse.com>,
"Andi Shyti" <andi.shyti@kernel.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Mario Limonciello" <mario.limonciello@amd.com>,
"Yazen Ghannam" <yazen.ghannam@amd.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<x86@kernel.org>, "H . Peter Anvin" <hpa@zytor.com>,
"Shyam Sundar S K" <Shyam-sundar.S-k@amd.com>,
"Hans de Goede" <hdegoede@redhat.com>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
"open list" <linux-kernel@vger.kernel.org>,
"open list:I2C/SMBUS CONTROLLER DRIVERS FOR PC"
<linux-i2c@vger.kernel.org>,
"open list:AMD PMC DRIVER" <platform-driver-x86@vger.kernel.org>
Subject: Re: [PATCH v3 4/4] x86/CPU/AMD: Print the reason for the last reset
Date: Fri, 11 Apr 2025 07:12:24 -0500 [thread overview]
Message-ID: <42b7547d-c1f7-4509-a381-7bf0a485a5f5@kernel.org> (raw)
In-Reply-To: <20250411120617.GMZ_kFucLFQQ7LJkys@fat_crate.local>
On 4/11/25 07:06, Borislav Petkov wrote:
> On Thu, Apr 10, 2025 at 03:02:02PM -0500, Mario Limonciello wrote:
>> +static __init int print_s5_reset_status_mmio(void)
>> +{
>> + void __iomem *addr;
>> + unsigned long value;
>> + int bit = -1;
>> +
>> + if (!cpu_feature_enabled(X86_FEATURE_ZEN))
>> + return 0;
>> +
>> + addr = ioremap(FCH_PM_BASE + FCH_PM_S5_RESET_STATUS, sizeof(value));
>> + if (!addr)
>> + return 0;
>
> newline.
>
>> + value = ioread32(addr);
>> + iounmap(addr);
>> +
>> + do {
>> + bit = find_next_bit(&value, BITS_PER_LONG, bit + 1);
>> + } while (!s5_reset_reason_txt[bit]);
>
> What's the idea here? The highest bit is the most fitting one?
>
> So why don't you do fls() or so?
The idea was to walk all the bits and pick the first one that has a
string associated with it. I was finding that sometimes the reserved
bits are set which would get you a NULL pointer deref.
>
>> + pr_info("x86/amd: Previous system reset reason [0x%08lx]: %s\n",
>> + value, s5_reset_reason_txt[bit]);
>
> What's guaranteeing that s5_reset_reason_txt[bit] is still set here?
>
> I'd suggest you check it again and never trust the hw because we'll be fixing
> a null ptr here at some point otherwise...
>
Right; I was worried about that too but find_next_bit() will return the
size argument when it doesn't find anything.
So that should be s5_reset_reason_txt[32] which has the "Unknown" string.
next prev parent reply other threads:[~2025-04-11 12:12 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-10 20:01 [PATCH v3 0/4] AMD Zen debugging documentation Mario Limonciello
2025-04-10 20:01 ` [PATCH v3 1/4] Documentation: Add AMD Zen debugging document Mario Limonciello
2025-04-12 2:12 ` Bagas Sanjaya
2025-04-12 2:19 ` Mario Limonciello
2025-04-12 2:28 ` Bagas Sanjaya
2025-04-10 20:02 ` [PATCH v3 2/4] i2c: piix4: Move SB800_PIIX4_FCH_PM_ADDR definition to amd_node.h Mario Limonciello
2025-04-11 11:49 ` Borislav Petkov
2025-04-11 12:09 ` Mario Limonciello
2025-04-11 12:41 ` Borislav Petkov
2025-04-12 19:44 ` Ingo Molnar
2025-04-12 19:51 ` Mario Limonciello
2025-04-12 20:15 ` Ingo Molnar
2025-04-12 20:23 ` Mario Limonciello
2025-04-12 20:47 ` Ingo Molnar
2025-04-12 22:29 ` Borislav Petkov
2025-04-13 7:54 ` Ingo Molnar
2025-04-13 8:44 ` Ingo Molnar
2025-04-13 19:27 ` Mario Limonciello
2025-04-13 19:32 ` Ingo Molnar
2025-04-11 21:15 ` kernel test robot
2025-04-11 21:56 ` kernel test robot
2025-04-10 20:02 ` [PATCH v3 3/4] platform/x86/amd: pmc: use FCH_PM_BASE definition Mario Limonciello
2025-04-10 20:02 ` [PATCH v3 4/4] x86/CPU/AMD: Print the reason for the last reset Mario Limonciello
2025-04-11 12:06 ` Borislav Petkov
2025-04-11 12:12 ` Mario Limonciello [this message]
2025-04-11 12:50 ` Borislav Petkov
2025-04-11 13:25 ` Mario Limonciello
2025-04-12 19:37 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42b7547d-c1f7-4509-a381-7bf0a485a5f5@kernel.org \
--to=superm1@kernel.org \
--cc=Shyam-sundar.S-k@amd.com \
--cc=andi.shyti@kernel.org \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=hdegoede@redhat.com \
--cc=hpa@zytor.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jdelvare@suse.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=mingo@redhat.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yazen.ghannam@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®