[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <42a5c36d-8b65-418f-9826-2808ab49d67a@linux.microsoft.com>
Date: Wed, 11 Oct 2023 12:56:40 -0700
From: Jarred White <jarredwhite@...ux.microsoft.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Len Brown <lenb@...nel.org>,
"open list:ACPI" <linux-acpi@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] acpi: Use access_width over register_width for system
memory accesses
On 10/3/2023 11:50 AM, Rafael J. Wysocki wrote:
> On Mon, Sep 25, 2023 at 8:06 PM Jarred White
> <jarredwhite@...ux.microsoft.com> wrote:
>> To align with ACPI 6.3+, since bit_width can be any 8-bit value, we
cannot
>> depend on it being always on a clean 8b boundary. Instead, use
access_width
>> to determine the size and use the offset and width to shift and mask the
>> bit swe want to read/write out. Make sure to add a check for system
memory
>> since pcc redefines the access_width to subspace id.
> This is fine, but what if there are systems in the field where
> bit_width is invalid, but they just happen to work because of the way
> it is currently handled?
For the kernel coding style issues, I will clean up for the v2 patch.
On the invalid bit_width for systems out there in the field, do you have
any suggestions on how to handle this particular scenario? Would it be
appropriate to add a kernel parameter flag that can revert back to the
previous implementation?
P.S. Sorry for the HTML email.
Thanks,
Jarred
Powered by blists - more mailing lists