Re: [Devel] [PATCH 5/6] acpi/cppc: Add support for optional CPPC registers
by Rafael J. Wysocki
On Friday, March 29, 2019 9:18:04 PM CET Ghannam, Yazen wrote:
> > -----Original Message-----
> > From: linux-acpi-owner(a)vger.kernel.org <linux-acpi-owner(a)vger.kernel.org> On Behalf Of Pandruvada, Srinivas
> > Sent: Wednesday, March 27, 2019 10:48 AM
> > To: linux-kernel(a)vger.kernel.org; devel(a)acpica.org; Natarajan, Janakarajan <Janakarajan.Natarajan(a)amd.com>; linux-
> > acpi(a)vger.kernel.org; linux-pm(a)vger.kernel.org
> > Cc: Ghannam, Yazen <Yazen.Ghannam(a)amd.com>; lenb(a)kernel.org; viresh.kumar(a)linaro.org; Moore, Robert
> > <robert.moore(a)intel.com>; Schmauss, Erik <erik.schmauss(a)intel.com>; rjw(a)rjwysocki.net
> > Subject: Re: [PATCH 5/6] acpi/cppc: Add support for optional CPPC registers
> >
> > On Fri, 2019-03-22 at 20:26 +0000, Natarajan, Janakarajan wrote:
> > > From: Yazen Ghannam <Yazen.Ghannam(a)amd.com>
> > >
> > > Newer AMD processors support a subset of the optional CPPC registers.
> > > Create show, store and helper routines for supported CPPC registers.
> > >
> > > Signed-off-by: Yazen Ghannam <Yazen.Ghannam(a)amd.com>
> > > [ carved out into a patch, cleaned up, productized ]
> > > Signed-off-by: Janakarajan Natarajan <Janakarajan.Natarajan(a)amd.com>
> > >
> >
> > [..]
> >
> > > + /* desired_perf is the only mandatory value in perf_ctrls */
> > > + if (cpc_read(cpu, desired_reg, &desired))
> > > + ret = -EFAULT;
> > > +
> > > + if (CPC_SUPPORTED(max_reg) && cpc_read(cpu, max_reg, &max))
> > > + ret = -EFAULT;
> > > +
> > We should create and use different macro other than CPPC_SUPPORTED.
> > CPC_SUPPORTED doesn't validate the correctness of object type for a
> > field. For example "Maximum Performance Register" can only be buffer
> > not integer. In this way invalid field definitions can be ignored.
> >
>
> So create something like "CPPC_SUPPORTED_BUFFER" for buffer-only registers?
>
> And then buffer/integer registers will continue to use "CPPC_SUPPORTED".
>
> These seem to be the only two cases at this time. Is this okay?
Yes, something like that.
Thanks,
Rafael
2 years, 9 months
ACPICA version 20190329 released
by Moore, Robert
29 March 2019. Summary of changes for version 20190329:
This release is available at https://acpica.org/downloads
1) ACPICA kernel-resident subsystem:
Namespace support: Remove the address nodes from global list after method termination. The global address list contains pointers to namespace nodes that represent Operation Regions. This change properly removes Operation Region namespace nodes that are declared dynamically during method execution.
Linux: Use a different debug default than ACPICA. There was a divergence between Linux and the ACPICA codebases. In order to resolve this divergence, Linux now declares its own debug default in aclinux.h
Renamed some internal macros to improve code understanding and maintenance. The macros below all operate on single 4-character ACPI NameSegs, not generic strings (old -> new):
ACPI_NAME_SIZE -> ACPI_NAMESEG_SIZE
ACPI_COMPARE_NAME -> ACPI_COMPARE_NAMESEG
ACPI_MOVE_NAME -> ACPI_COPY_NAMESEG
Fix for missing comma in array declaration for the AcpiGbl_GenericNotify table.
Test suite: Update makefiles, add PCC operation region support
2) iASL Compiler/Disassembler and Tools:
iASL: Implemented additional illegal forward reference detection. Now detect and emit an error upon detection of a forward reference from a Field to an Operation Region. This will fail at runtime if allowed to pass the compiler.
AcpiExec: Add an address list check for dynamic Operation Regions. This feature performs a sanity test for each node the global address list. This is done in order to ensure that all dynamic operation regions are properly removed from the global address list and no dangling pointers are left behind.
Disassembler: Improved generation of resource pathnames. This change improves the code that generates resource descriptor and resource tag pathnames. The original code used a bunch of str* C library functions that caused warnings on some compilers.
iASL: Removed some uses of strncpy and replaced with memmove. The strncpy function can overwrite buffers if the calling code is not very careful. In the case of generating a module/table header, use of memmove is a better implementation.
3) Status of new features that have not been completed at this time:
iASL: Implementing an enhanced multiple file compilation into a single namespace feature (Status): This feature will be released soon, and allows multiple ASL files to be compiled into the same single namespace. By doing so, any unresolved external declarations as well as duplicate named object declarations can be detected during compilation (rather than later during runtime). The following commands are examples that utilize this feature:
iasl dsdt.asl ssdt.asl
iasl dsdt.asl ssdt1.asl ssdt2.asl
iasl dsdt.asl ssdt*.asl
ASL tutorial status: Feedback is being gathered internally and the current plan is to publish this tutorial on the ACPICA website after a final review by a tech writer.
2 years, 9 months
Re: [Devel] [PATCH] drivers/acpi: Clear status of an event before enabling it
by Rafael J. Wysocki
On Thu, Mar 28, 2019 at 1:46 AM Furquan Shaikh <furquan(a)google.com> wrote:
>
> On Wed, Mar 27, 2019 at 5:24 AM Rafael J. Wysocki <rafael(a)kernel.org> wrote:
> >
> > On Thu, Mar 21, 2019 at 3:16 AM Furquan Shaikh <furquan(a)google.com> wrote:
> > >
> > > On Wed, Mar 20, 2019 at 5:11 PM Rafael J. Wysocki <rafael(a)kernel.org> wrote:
> > > >
> > > > On Wed, Mar 20, 2019 at 11:34 PM Furquan Shaikh <furquan(a)google.com> wrote:
> > > > >
> > > > > Commit 18996f2db918 ("ACPICA: Events: Stop unconditionally
> > > > > clearing ACPI IRQs during suspend/resume") was added to stop clearing
> > > > > of event status bits unconditionally on suspend and resume paths. This
> > > > > was done because of an issue
> > > > > reported (https://bugzilla.kernel.org/show_bug.cgi?id=196249) where
> > > > > lid status stays closed even on resume (which happens because event
> > > > > status bits are cleared unconditionally on resume). Though this change
> > > > > fixed the issue on suspend path, it introduced regressions on several
> > > > > resume paths.
> > > > >
> > > > > First regression was reported and fixed on S5 path by the following
> > > > > change: commit fa85015c0d95 ("ACPICA: Clear status of all events when
> > > > > entering S5"). Next regression was reported and fixed on all legacy
> > > > > sleep paths by the commit f317c7dc12b7 ("ACPICA: Clear status of all
> > > > > events when entering sleep states"). However, regression still exists
> > > > > on S0ix sleep path since it does not follow the legacy sleep path.
> > > >
> > > > What exactly is failing?
> > >
> > > Here is the failure scenario:
> > >
> > > 1. Consider the case of trackpad which acts as a wake source.
> > > 2. Since the pad is configured for SCI, GPE_STS gets set for that pad
> > > during normal interrupts as well (i.e. during probe at boot or when
> > > using the trackpad)
> >
> > I don't quite understand this.
> >
> > Is the same GPE used for signaling trackpad events in the system
> > working state and for wakeup?
>
> Yes. The same pad is being configured for interrupts (i.e. routed to
> APIC) during S0 as well as configured for GPE (i.e. routed for SCI) to
> cause wakes when in S0ix/S3. This pad is externally connected to
> trackpad interrupt line.
And the way the system is wired up causes the GPE status to be set
when it is enabled, I suppose?
So effectively, you need to disable the active-state IRQ, then clear
the GPE status and enable it for wakeup.
OK, I'll queue up the patch (and talk to the upstream ACPICA people
about taking it in there).
Thanks!
2 years, 10 months
Re: [Devel] [PATCH] drivers/acpi: Clear status of an event before enabling it
by Rafael J. Wysocki
On Thu, Mar 21, 2019 at 3:16 AM Furquan Shaikh <furquan(a)google.com> wrote:
>
> On Wed, Mar 20, 2019 at 5:11 PM Rafael J. Wysocki <rafael(a)kernel.org> wrote:
> >
> > On Wed, Mar 20, 2019 at 11:34 PM Furquan Shaikh <furquan(a)google.com> wrote:
> > >
> > > Commit 18996f2db918 ("ACPICA: Events: Stop unconditionally
> > > clearing ACPI IRQs during suspend/resume") was added to stop clearing
> > > of event status bits unconditionally on suspend and resume paths. This
> > > was done because of an issue
> > > reported (https://bugzilla.kernel.org/show_bug.cgi?id=196249) where
> > > lid status stays closed even on resume (which happens because event
> > > status bits are cleared unconditionally on resume). Though this change
> > > fixed the issue on suspend path, it introduced regressions on several
> > > resume paths.
> > >
> > > First regression was reported and fixed on S5 path by the following
> > > change: commit fa85015c0d95 ("ACPICA: Clear status of all events when
> > > entering S5"). Next regression was reported and fixed on all legacy
> > > sleep paths by the commit f317c7dc12b7 ("ACPICA: Clear status of all
> > > events when entering sleep states"). However, regression still exists
> > > on S0ix sleep path since it does not follow the legacy sleep path.
> >
> > What exactly is failing?
>
> Here is the failure scenario:
>
> 1. Consider the case of trackpad which acts as a wake source.
> 2. Since the pad is configured for SCI, GPE_STS gets set for that pad
> during normal interrupts as well (i.e. during probe at boot or when
> using the trackpad)
I don't quite understand this.
Is the same GPE used for signaling trackpad events in the system
working state and for wakeup?
> 3. Now, when the platform decides to enter S0ix, it enables the wake
> on trackpad by enabling appropriate GPE_EN bit.
> 4. So, at this point, we are in a situation where GPE_EN as well as
> GPE_STS are set.
> 5. Now, if the platform enters S0ix, having GPE_STS set will result in
> unwanted wakes because of stale events.
>
> This is similar to what was fixed on the legacy sleep path:
> https://lkml.org/lkml/2018/8/12/42. However, as S0ix does not follow
> the legacy sleep path, clearing of GPE status does not happen. Thus,
> it is causing failures to go into S0ix on our platforms because of the
> stale wake events as described above.
>
> >
> > > In case of S0ix, events are enabled as part of device suspend path. If
> > > status bits for the events are set when they are enabled, it could
> > > result in premature wake from S0ix. This change ensures that status is
> > > cleared for any event that is being enabled so that any stale events
> > > are cleared out.
> > >
> > > Signed-off-by: Furquan Shaikh <furquan(a)google.com>
> > > ---
> > > drivers/acpi/acpica/evgpe.c | 6 +++++-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/acpi/acpica/evgpe.c b/drivers/acpi/acpica/evgpe.c
> > > index 62d3aa74277b4..61455ab42fc87 100644
> > > --- a/drivers/acpi/acpica/evgpe.c
> > > +++ b/drivers/acpi/acpica/evgpe.c
> > > @@ -81,8 +81,12 @@ acpi_status acpi_ev_enable_gpe(struct acpi_gpe_event_info *gpe_event_info)
> > >
> > > ACPI_FUNCTION_TRACE(ev_enable_gpe);
> > >
> > > - /* Enable the requested GPE */
> > > + /* Clear the GPE (of stale events) */
> > > + status = acpi_hw_clear_gpe(gpe_event_info);
> > > + if (ACPI_FAILURE(status))
> > > + return_ACPI_STATUS(status);
> >
> > Well, this may cause events to be missed.
>
> Won't those be stale events?
They need not be stale, the device may have already detected some
activity before the GPE is enabled.
> i.e. any event that has occurred before GPE is enabled should be ignored.
But this is a good point.
>
> >
> > >
> > > + /* Enable the requested GPE */
> > > status = acpi_hw_low_set_gpe(gpe_event_info, ACPI_GPE_ENABLE);
> > > return_ACPI_STATUS(status);
> > > }
> > > --
2 years, 10 months
Re: [Devel] PROBLEM: Calling ObjectType on buffer field reports type integer
by Schmauss, Erik
> -----Original Message-----
> From: Maximilian Luz [mailto:luzmaximilian@gmail.com]
> Sent: Friday, March 22, 2019 1:55 PM
> To: Schmauss, Erik <erik.schmauss(a)intel.com>; Moore, Robert
> <robert.moore(a)intel.com>; Wysocki, Rafael J
> <rafael.j.wysocki(a)intel.com>
> Cc: linux-acpi(a)vger.kernel.org; devel(a)acpica.org
> Subject: Re: PROBLEM: Calling ObjectType on buffer field reports type
> integer
>
>
>
> On 3/19/19 9:19 PM, Schmauss, Erik wrote:
> >
> >
> >> -----Original Message-----
> >> From: Maximilian Luz [mailto:luzmaximilian@gmail.com]
> >> Sent: Tuesday, March 19, 2019 9:30 AM
> >> To: Schmauss, Erik <erik.schmauss(a)intel.com>; Moore, Robert
> >> <robert.moore(a)intel.com>; Wysocki, Rafael J
> >> <rafael.j.wysocki(a)intel.com>
> >> Cc: linux-acpi(a)vger.kernel.org; devel(a)acpica.org
> >> Subject: Re: PROBLEM: Calling ObjectType on buffer field reports
> type
> >> integer
> >>
> >>
> >>
> >> On 3/18/19 11:28 PM, Schmauss, Erik wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: linux-acpi-owner(a)vger.kernel.org [mailto:linux-acpi-
> >>>> owner(a)vger.kernel.org] On Behalf Of Schmauss, Erik
> >>>> Sent: Thursday, March 14, 2019 10:19 AM
> >>>> To: Maximilian Luz <luzmaximilian(a)gmail.com>; Moore, Robert
> >>>> <robert.moore(a)intel.com>; Wysocki, Rafael J
> >>>> <rafael.j.wysocki(a)intel.com>
> >>>> Cc: linux-acpi(a)vger.kernel.org; devel(a)acpica.org
> >>>> Subject: RE: PROBLEM: Calling ObjectType on buffer field reports
> >> type
> >>>> integer
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Maximilian Luz [mailto:luzmaximilian@gmail.com]
> >>>>> Sent: Thursday, March 14, 2019 7:24 AM
> >>>>> To: Moore, Robert <robert.moore(a)intel.com>; Schmauss, Erik
> >>>>> <erik.schmauss(a)intel.com>; Wysocki, Rafael J
> >>>>> <rafael.j.wysocki(a)intel.com>
> >>>>> Cc: linux-acpi(a)vger.kernel.org; devel(a)acpica.org
> >>>>> Subject: PROBLEM: Calling ObjectType on buffer field reports
> type
> >>>>> integer
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> it seems that buffer fields (created via CreateField) are
> >>>>> incorrectly reported as being of type integer (via ObjectType)
> >> when
> >>>>> they are
> >>>> small
> >>>>> enough to allow for that.
> >>>>>
> >>>>> As far as I know all kernel versions are affected by this, I have
> >>>>> specifically checked 5.0 (5.0.2), 4.20, 4.19 and 4.18.
> >>>>>
> >>>>> In more detail: On the Microsoft Surface Book 2, Surface Pro
> >> (2017),
> >>>>> Surface Pro 6, Surface Laptop and Surface Laptop 2 devices
> there
> >> is
> >>>>> the following piece of AML code:
> >>>>>
> >>>>> Local0 = ^^_SAN.RQST (0x02, One, One, Zero, One)
> >>>>> If ((ObjectType (Local0) != 0x03))
> >>>>> {
> >>>>> // Error path
> >>>>> }
> >>>>> Else
> >>>>> {
> >>>>> // Success path
> >>>>> }
> >>>>>
> >>>>> Which executes a command (RQST) and then checks the type of
> >> the
> >>>>> returned field to determine if that command was successful
> (i.e.
> >>>>> returned a buffer object) or failed (i.e. returned any other type,
> >>>>> including integer). The buffer field that is being returned by
> >>>>> RQST is crated as
> >>>>> follows:
> >>>>>
> >>>>> CreateField (RQBF, 0x20, Local3, ARB)
> >>>>> Local4 = ARB /* \_SB_._SAN.RQSX.ARB_ */
> >>>>> ...
> >>>>> Return (Local4)
> >>>>>
> >>>>> If the returned buffer field is small enough (smaller than
> >>>>> acpi_gbl_integer_byte_width), the error-path will always be
> >>>> executed.
> >>>>>
> >>>>> The full DSDT for the Surface Book 2 can be found here:
> >>>>> https://github.com/qzed/surfacebook2-
> >>>>>
> >>>>
> >>
> dsdt/blob/fa0ca7c7cba8fb0da1e79c282f9a9f4a12eaaa17/dsdt.dsl#L153
> >>>>> 96
> >>>>>
> >>>>> I have attached a patch (for 5.0) that fixes this issue and has
> >>>>> been in use on the affected devices for a few months now via
> >>>>>
> >>>>> https://github.com/qzed/linux-surfacegen5-acpi and
> >>>>> https://github.com/jakeday/linux-surface/
> >>>>>
> >>>>> I'm not aware of any issues regarding the patch, but then again
> >> this
> >>>>> has, to my knowledge, only been tested on Microsoft Surface
> >>>> devices.
> >>>>
> >>>> I'll take a look at this and test the behavior on windows OS.
> >>>> Surface laptops tend to have interesting firmware that expose
> these
> >>>> differences.
> >>>
> >>> I decided to run the following code on windows
> >>>
> >>> Name (BUF1, Buffer() {0x32, 0x56, 0x12, 0xff, 0x12, 0xd1,
> >>> 0xd0,
> >> 0xd6, 0x54})
> >>> Name (BUF2, Buffer(0x09) {})
> >>> Method (DS00)
> >>> {
> >>> CreateField (BUF1, 1, 1, FLD0)
> >>> local0 = FLD0
> >>> return (ObjectType(Local0))
> >>> }
> >>> Method (DS01)
> >>> {
> >>> CreateField (BUF1, 0, 72, FLD1)
> >>> local1 = FLD1
> >>> return (ObjectType(Local1))
> >>> }
> >>> Method (DS02)
> >>> {
> >>> CreateField (BUF2, 0, 72, FLD2)
> >>> local2 = FLD2
> >>> return (ObjectType(Local2))
> >>> }
> >>>
> >>> Here's an output from windbg
> >>>
> >>> AMLI(? for help)-> run \ds00
> >>> run \ds00
> >>>
> >>> \DS00 completed successfully with object data:
> >>> Integer(:Value=0x3[3])
> >>>
> >>> AMLI(? for help)-> run \ds01
> >>> run \ds01
> >>>
> >>> \DS01 completed successfully with object data:
> >>> Integer(:Value=0x3[3])
> >>>
> >>> AMLI(? for help)-> run \ds02
> >>> run \ds02
> >>>
> >>> \DS02 completed successfully with object data:
> >>> Integer(:Value=0x3[3])
> >>>
> >>> AMLI(? for help)->
> >>>
> >>> So it does seem like windows AML interpreter is doing what you
> >> expect it to do.
> >>> After I applied your patch with a small modification below and it
> >>> causes some regressions in our AML test suite. I would like to take
> >>> time to look at each of these to make sure that all of the
> >>> behavioral
> >> Differences are expected. Bob will be back in the office so I'll
> >> discuss this with him as well.
> >>
> >> Thank you for the update!
> >>
> >> I mainly choose this solution because it was the first one I came up
> >> with, I'm not that experienced with acpica so yours may very well
> be
> >> better. What I found a bit odd though and why I stuck with this
> >> solution was that AML_FIELD_ACCESS_BUFFER did not seem to be
> used
> >> anywhere (in contrast to the other field access types).
> >>
> >> I've tried your modification. However, just replacing the check with
> >>
> >> obj_desc->common.type == ACPI_TYPE_BUFFER_FIELD
> >>
> >> did seem to break things for me, but I may be missing something.
> >>
> >> More specifics on what is being broken: The communication via the
> >> OperationRegion does not seem to work properly any more. There
> is a
> >
> > Yeah, that's what I was thinking... After discussions with Bob, this
> > whole Behavior is an issue with Winodws AML interpreter not
> following the spec.
> >
> > Page 927 of ACPI 6.3 specification states the following:
> >
> > "If the Buffer Field is smaller than or equal to the size of an Integer
> (in bits), it will be treated as an Integer. Otherwise, it will be treated as
> a Buffer."
> >
> > So windows is not following this rule here. This rule is also the same
> > for field units so our next step is to check windows behavior for
> > this. It would be nice to file a bug against windows but they've never
> > responded to these reports in the past....
> >
> > For the record, windows does detect the object type of CreateField
> correctly.
> >
> > Method (SS02)
> > {
> > CreateField (BUF2, 0, 72, FLD2)
> > return (ObjectType(FLD2))
> > }
> >
> > This method returns 0xE as expected.
>
> Thanks for the reference. Indeed looks like Microsoft is doing their
> own thing here, I should have figured as much. How are things like this
> being handled? Adopt Microsoft's behavior?
I've been discussing this with Bob. I've decided to file a bug against Microsoft
internally. I would like to wait and see what they say... I've never done such
things so I don't know how long the process takes to get a response form them.
I'll post updates when I get them but feel free to ping us again in a few
weeks if you don't hear back. We're still investigating their operation region
behavior as well...
Erik
>
> Maximilian
>
> >
> >> status flag in the communication buffer that should get cleared and
> >> it looks like it isn't. My current theory is:
> >>
> >> The flag being checked is a byte field in the communication buffer,
> >> created via CreateByteField (RQBF, 0x00, VSTS). Thus it should have
> >> type ACPI_TYPE_BUFFER_FIELD (?). Due to this, your change seems
> to
> >> create a buffer instead of an integer object in
> >> acpi_ex_read_data_from_field.
> >> When this field is now evaluated for the communication check via
> >>
> >> If ((VSTS == Zero)) { /* success */ } Else { /* failure */ }
> >>
> >> the check in acpi_ex_do_logical_op exmisc.c converts the second
> >> argument to a buffer of size acpi_gbl_integer_byte_width. The
> buffer
> >> sizes are then different as VSTS has size 1 and thus the check fails,
> >> getting misinterpreted as communication-failure.
> >>
> >> Maximilian
> >>
> >>>
> >>> Thanks,
> >>> Erik
> >>>>
> >>>> Erik
> >>>>>
> >>>>> Maximilian
> >>>>>
> >>>>> Signed-off-by: Maximilian Luz <luzmaximilian(a)gmail.com>
> >>>>> ---
> >>>>> drivers/acpi/acpica/dsopcode.c | 2 +-
> >>>>> drivers/acpi/acpica/exfield.c | 12 +++++++++---
> >>>>> 2 files changed, 10 insertions(+), 4 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/acpi/acpica/dsopcode.c
> >>>>> b/drivers/acpi/acpica/dsopcode.c index
> >> 78f9de260d5f..0cd858520f5b
> >>>>> 100644
> >>>>> --- a/drivers/acpi/acpica/dsopcode.c
> >>>>> +++ b/drivers/acpi/acpica/dsopcode.c
> >>>>> @@ -123,7 +123,7 @@ acpi_ds_init_buffer_field(u16
> >> aml_opcode,
> >>>>>
> >>>>> /* Offset is in bits, count is in bits */
> >>>>>
> >>>>> - field_flags = AML_FIELD_ACCESS_BYTE;
> >>>>> + field_flags = AML_FIELD_ACCESS_BUFFER;
> >>>>> bit_offset = offset;
> >>>>> bit_count = (u32) length_desc->integer.value;
> >>>>>
> >>>>> diff --git a/drivers/acpi/acpica/exfield.c
> >>>>> b/drivers/acpi/acpica/exfield.c index
> e5798f15793a..55abd9e035a0
> >>>>> 100644
> >>>>> --- a/drivers/acpi/acpica/exfield.c
> >>>>> +++ b/drivers/acpi/acpica/exfield.c
> >>>>> @@ -98,6 +98,7 @@ acpi_ex_read_data_from_field(struct
> >>>>> acpi_walk_state *walk_state,
> >>>>> union acpi_operand_object *buffer_desc;
> >>>>> void *buffer;
> >>>>> u32 buffer_length;
> >>>>> + u8 field_flags;
> >>>>>
> >>>>>
> ACPI_FUNCTION_TRACE_PTR(ex_read_data_from_field,
> >>>>> obj_desc);
> >>>>>
> >>>>> @@ -146,11 +147,16 @@ acpi_ex_read_data_from_field(struct
> >>>>> acpi_walk_state *walk_state,
> >>>>> * Note: Field.length is in bits.
> >>>>> */
> >>>>> buffer_length =
> >>>>> -
> (acpi_size)ACPI_ROUND_BITS_UP_TO_BYTES(obj_desc-
> >>>>>> field.bit_length);
> >>>>> +
> (acpi_size)ACPI_ROUND_BITS_UP_TO_BYTES(obj_desc-
> >>>>>> common_field.bit_length);
> >>>>> + field_flags = obj_desc->common_field.field_flags;
> >>>>>
> >>>>> - if (buffer_length > acpi_gbl_integer_byte_width) {
> >>>>> + if (buffer_length > acpi_gbl_integer_byte_width ||
> >>>>> + (field_flags & AML_FIELD_ACCESS_TYPE_MASK) ==
> >>>>> +AML_FIELD_ACCESS_BUFFER) {
> >>>
> >>> Rather than using field_flags at all, we can do something like
> >>>
> >>> if ((BufferLength > AcpiGbl_IntegerByteWidth) || (ObjDesc-
> >>> Common.Type == ACPI_TYPE_BUFFER_FIELD))
> >>>
> >>> This will restrict translations to the CreateField but your solution
> >> might also be valid...
> >>> I'll run a few more test cases tomorrow.
> >>>>>
> >>>>> - /* Field is too large for an Integer, create a
> Buffer
> >>>>> instead */
> >>>>> + /*
> >>>>> + * Field is either too large for an Integer, or a
> actually of
> >>>>> type
> >>>>> + * buffer, so create a Buffer.
> >>>>> + */
> >>>>>
> >>>>> buffer_desc =
> >>>>> acpi_ut_create_buffer_object(buffer_length);
> >>>>> if (!buffer_desc) {
> >>>>> --
> >>>>> 2.20.1
> >>>>>
> >>>
2 years, 10 months
Re: [Devel] [PATCH] drivers/acpi: Clear status of an event before enabling it
by Rafael J. Wysocki
On Wed, Mar 20, 2019 at 11:34 PM Furquan Shaikh <furquan(a)google.com> wrote:
>
> Commit 18996f2db918 ("ACPICA: Events: Stop unconditionally
> clearing ACPI IRQs during suspend/resume") was added to stop clearing
> of event status bits unconditionally on suspend and resume paths. This
> was done because of an issue
> reported (https://bugzilla.kernel.org/show_bug.cgi?id=196249) where
> lid status stays closed even on resume (which happens because event
> status bits are cleared unconditionally on resume). Though this change
> fixed the issue on suspend path, it introduced regressions on several
> resume paths.
>
> First regression was reported and fixed on S5 path by the following
> change: commit fa85015c0d95 ("ACPICA: Clear status of all events when
> entering S5"). Next regression was reported and fixed on all legacy
> sleep paths by the commit f317c7dc12b7 ("ACPICA: Clear status of all
> events when entering sleep states"). However, regression still exists
> on S0ix sleep path since it does not follow the legacy sleep path.
What exactly is failing?
> In case of S0ix, events are enabled as part of device suspend path. If
> status bits for the events are set when they are enabled, it could
> result in premature wake from S0ix. This change ensures that status is
> cleared for any event that is being enabled so that any stale events
> are cleared out.
>
> Signed-off-by: Furquan Shaikh <furquan(a)google.com>
> ---
> drivers/acpi/acpica/evgpe.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/acpica/evgpe.c b/drivers/acpi/acpica/evgpe.c
> index 62d3aa74277b4..61455ab42fc87 100644
> --- a/drivers/acpi/acpica/evgpe.c
> +++ b/drivers/acpi/acpica/evgpe.c
> @@ -81,8 +81,12 @@ acpi_status acpi_ev_enable_gpe(struct acpi_gpe_event_info *gpe_event_info)
>
> ACPI_FUNCTION_TRACE(ev_enable_gpe);
>
> - /* Enable the requested GPE */
> + /* Clear the GPE (of stale events) */
> + status = acpi_hw_clear_gpe(gpe_event_info);
> + if (ACPI_FAILURE(status))
> + return_ACPI_STATUS(status);
Well, this may cause events to be missed.
>
> + /* Enable the requested GPE */
> status = acpi_hw_low_set_gpe(gpe_event_info, ACPI_GPE_ENABLE);
> return_ACPI_STATUS(status);
> }
> --
> 2.21.0.225.g810b269d1ac-goog
>
2 years, 10 months
Re: [Devel] PROBLEM: Calling ObjectType on buffer field reports type integer
by Schmauss, Erik
> -----Original Message-----
> From: Maximilian Luz [mailto:luzmaximilian@gmail.com]
> Sent: Tuesday, March 19, 2019 9:30 AM
> To: Schmauss, Erik <erik.schmauss(a)intel.com>; Moore, Robert
> <robert.moore(a)intel.com>; Wysocki, Rafael J
> <rafael.j.wysocki(a)intel.com>
> Cc: linux-acpi(a)vger.kernel.org; devel(a)acpica.org
> Subject: Re: PROBLEM: Calling ObjectType on buffer field reports type
> integer
>
>
>
> On 3/18/19 11:28 PM, Schmauss, Erik wrote:
> >
> >
> >> -----Original Message-----
> >> From: linux-acpi-owner(a)vger.kernel.org [mailto:linux-acpi-
> >> owner(a)vger.kernel.org] On Behalf Of Schmauss, Erik
> >> Sent: Thursday, March 14, 2019 10:19 AM
> >> To: Maximilian Luz <luzmaximilian(a)gmail.com>; Moore, Robert
> >> <robert.moore(a)intel.com>; Wysocki, Rafael J
> >> <rafael.j.wysocki(a)intel.com>
> >> Cc: linux-acpi(a)vger.kernel.org; devel(a)acpica.org
> >> Subject: RE: PROBLEM: Calling ObjectType on buffer field reports
> type
> >> integer
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Maximilian Luz [mailto:luzmaximilian@gmail.com]
> >>> Sent: Thursday, March 14, 2019 7:24 AM
> >>> To: Moore, Robert <robert.moore(a)intel.com>; Schmauss, Erik
> >>> <erik.schmauss(a)intel.com>; Wysocki, Rafael J
> >>> <rafael.j.wysocki(a)intel.com>
> >>> Cc: linux-acpi(a)vger.kernel.org; devel(a)acpica.org
> >>> Subject: PROBLEM: Calling ObjectType on buffer field reports type
> >>> integer
> >>>
> >>> Hi all,
> >>>
> >>> it seems that buffer fields (created via CreateField) are
> >>> incorrectly reported as being of type integer (via ObjectType)
> when
> >>> they are
> >> small
> >>> enough to allow for that.
> >>>
> >>> As far as I know all kernel versions are affected by this, I have
> >>> specifically checked 5.0 (5.0.2), 4.20, 4.19 and 4.18.
> >>>
> >>> In more detail: On the Microsoft Surface Book 2, Surface Pro
> (2017),
> >>> Surface Pro 6, Surface Laptop and Surface Laptop 2 devices there
> is
> >>> the following piece of AML code:
> >>>
> >>> Local0 = ^^_SAN.RQST (0x02, One, One, Zero, One)
> >>> If ((ObjectType (Local0) != 0x03))
> >>> {
> >>> // Error path
> >>> }
> >>> Else
> >>> {
> >>> // Success path
> >>> }
> >>>
> >>> Which executes a command (RQST) and then checks the type of
> the
> >>> returned field to determine if that command was successful (i.e.
> >>> returned a buffer object) or failed (i.e. returned any other type,
> >>> including integer). The buffer field that is being returned by RQST
> >>> is crated as
> >>> follows:
> >>>
> >>> CreateField (RQBF, 0x20, Local3, ARB)
> >>> Local4 = ARB /* \_SB_._SAN.RQSX.ARB_ */
> >>> ...
> >>> Return (Local4)
> >>>
> >>> If the returned buffer field is small enough (smaller than
> >>> acpi_gbl_integer_byte_width), the error-path will always be
> >> executed.
> >>>
> >>> The full DSDT for the Surface Book 2 can be found here:
> >>> https://github.com/qzed/surfacebook2-
> >>>
> >>
> dsdt/blob/fa0ca7c7cba8fb0da1e79c282f9a9f4a12eaaa17/dsdt.dsl#L153
> >>> 96
> >>>
> >>> I have attached a patch (for 5.0) that fixes this issue and has been
> >>> in use on the affected devices for a few months now via
> >>>
> >>> https://github.com/qzed/linux-surfacegen5-acpi and
> >>> https://github.com/jakeday/linux-surface/
> >>>
> >>> I'm not aware of any issues regarding the patch, but then again
> this
> >>> has, to my knowledge, only been tested on Microsoft Surface
> >> devices.
> >>
> >> I'll take a look at this and test the behavior on windows OS. Surface
> >> laptops tend to have interesting firmware that expose these
> >> differences.
> >
> > I decided to run the following code on windows
> >
> > Name (BUF1, Buffer() {0x32, 0x56, 0x12, 0xff, 0x12, 0xd1, 0xd0,
> 0xd6, 0x54})
> > Name (BUF2, Buffer(0x09) {})
> > Method (DS00)
> > {
> > CreateField (BUF1, 1, 1, FLD0)
> > local0 = FLD0
> > return (ObjectType(Local0))
> > }
> > Method (DS01)
> > {
> > CreateField (BUF1, 0, 72, FLD1)
> > local1 = FLD1
> > return (ObjectType(Local1))
> > }
> > Method (DS02)
> > {
> > CreateField (BUF2, 0, 72, FLD2)
> > local2 = FLD2
> > return (ObjectType(Local2))
> > }
> >
> > Here's an output from windbg
> >
> > AMLI(? for help)-> run \ds00
> > run \ds00
> >
> > \DS00 completed successfully with object data:
> > Integer(:Value=0x3[3])
> >
> > AMLI(? for help)-> run \ds01
> > run \ds01
> >
> > \DS01 completed successfully with object data:
> > Integer(:Value=0x3[3])
> >
> > AMLI(? for help)-> run \ds02
> > run \ds02
> >
> > \DS02 completed successfully with object data:
> > Integer(:Value=0x3[3])
> >
> > AMLI(? for help)->
> >
> > So it does seem like windows AML interpreter is doing what you
> expect it to do.
> > After I applied your patch with a small modification below and it
> > causes some regressions in our AML test suite. I would like to take
> > time to look at each of these to make sure that all of the behavioral
> Differences are expected. Bob will be back in the office so I'll discuss
> this with him as well.
>
> Thank you for the update!
>
> I mainly choose this solution because it was the first one I came up
> with, I'm not that experienced with acpica so yours may very well be
> better. What I found a bit odd though and why I stuck with this
> solution was that AML_FIELD_ACCESS_BUFFER did not seem to be
> used anywhere (in contrast to the other field access types).
>
> I've tried your modification. However, just replacing the check with
>
> obj_desc->common.type == ACPI_TYPE_BUFFER_FIELD
>
> did seem to break things for me, but I may be missing something.
>
> More specifics on what is being broken: The communication via the
> OperationRegion does not seem to work properly any more. There is a
Yeah, that's what I was thinking... After discussions with Bob, this whole
Behavior is an issue with Winodws AML interpreter not following the spec.
Page 927 of ACPI 6.3 specification states the following:
"If the Buffer Field is smaller than or equal to the size of an Integer (in bits), it will be treated as an Integer. Otherwise, it will be treated as a Buffer."
So windows is not following this rule here. This rule is also the same for
field units so our next step is to check windows behavior for this. It would
be nice to file a bug against windows but they've never responded to these
reports in the past....
For the record, windows does detect the object type of CreateField correctly.
Method (SS02)
{
CreateField (BUF2, 0, 72, FLD2)
return (ObjectType(FLD2))
}
This method returns 0xE as expected.
> status flag in the communication buffer that should get cleared and it
> looks like it isn't. My current theory is:
>
> The flag being checked is a byte field in the communication buffer,
> created via CreateByteField (RQBF, 0x00, VSTS). Thus it should have
> type ACPI_TYPE_BUFFER_FIELD (?). Due to this, your change seems to
> create a buffer instead of an integer object in
> acpi_ex_read_data_from_field.
> When this field is now evaluated for the communication check via
>
> If ((VSTS == Zero)) { /* success */ } Else { /* failure */ }
>
> the check in acpi_ex_do_logical_op exmisc.c converts the second
> argument to a buffer of size acpi_gbl_integer_byte_width. The buffer
> sizes are then different as VSTS has size 1 and thus the check fails,
> getting misinterpreted as communication-failure.
>
> Maximilian
>
> >
> > Thanks,
> > Erik
> >>
> >> Erik
> >>>
> >>> Maximilian
> >>>
> >>> Signed-off-by: Maximilian Luz <luzmaximilian(a)gmail.com>
> >>> ---
> >>> drivers/acpi/acpica/dsopcode.c | 2 +-
> >>> drivers/acpi/acpica/exfield.c | 12 +++++++++---
> >>> 2 files changed, 10 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/acpi/acpica/dsopcode.c
> >>> b/drivers/acpi/acpica/dsopcode.c index
> 78f9de260d5f..0cd858520f5b
> >>> 100644
> >>> --- a/drivers/acpi/acpica/dsopcode.c
> >>> +++ b/drivers/acpi/acpica/dsopcode.c
> >>> @@ -123,7 +123,7 @@ acpi_ds_init_buffer_field(u16
> aml_opcode,
> >>>
> >>> /* Offset is in bits, count is in bits */
> >>>
> >>> - field_flags = AML_FIELD_ACCESS_BYTE;
> >>> + field_flags = AML_FIELD_ACCESS_BUFFER;
> >>> bit_offset = offset;
> >>> bit_count = (u32) length_desc->integer.value;
> >>>
> >>> diff --git a/drivers/acpi/acpica/exfield.c
> >>> b/drivers/acpi/acpica/exfield.c index e5798f15793a..55abd9e035a0
> >>> 100644
> >>> --- a/drivers/acpi/acpica/exfield.c
> >>> +++ b/drivers/acpi/acpica/exfield.c
> >>> @@ -98,6 +98,7 @@ acpi_ex_read_data_from_field(struct
> >>> acpi_walk_state *walk_state,
> >>> union acpi_operand_object *buffer_desc;
> >>> void *buffer;
> >>> u32 buffer_length;
> >>> + u8 field_flags;
> >>>
> >>> ACPI_FUNCTION_TRACE_PTR(ex_read_data_from_field,
> >>> obj_desc);
> >>>
> >>> @@ -146,11 +147,16 @@ acpi_ex_read_data_from_field(struct
> >>> acpi_walk_state *walk_state,
> >>> * Note: Field.length is in bits.
> >>> */
> >>> buffer_length =
> >>> - (acpi_size)ACPI_ROUND_BITS_UP_TO_BYTES(obj_desc-
> >>>> field.bit_length);
> >>> + (acpi_size)ACPI_ROUND_BITS_UP_TO_BYTES(obj_desc-
> >>>> common_field.bit_length);
> >>> + field_flags = obj_desc->common_field.field_flags;
> >>>
> >>> - if (buffer_length > acpi_gbl_integer_byte_width) {
> >>> + if (buffer_length > acpi_gbl_integer_byte_width ||
> >>> + (field_flags & AML_FIELD_ACCESS_TYPE_MASK) ==
> >>> +AML_FIELD_ACCESS_BUFFER) {
> >
> > Rather than using field_flags at all, we can do something like
> >
> > if ((BufferLength > AcpiGbl_IntegerByteWidth) || (ObjDesc-
> >Common.Type
> > == ACPI_TYPE_BUFFER_FIELD))
> >
> > This will restrict translations to the CreateField but your solution
> might also be valid...
> > I'll run a few more test cases tomorrow.
> >>>
> >>> - /* Field is too large for an Integer, create a Buffer
> >>> instead */
> >>> + /*
> >>> + * Field is either too large for an Integer, or a actually of
> >>> type
> >>> + * buffer, so create a Buffer.
> >>> + */
> >>>
> >>> buffer_desc =
> >>> acpi_ut_create_buffer_object(buffer_length);
> >>> if (!buffer_desc) {
> >>> --
> >>> 2.20.1
> >>>
> >
2 years, 10 months
[pm:bleeding-edge 5/6] include/acpi/acoutput.h:153: warning: "ACPI_DEBUG_DEFAULT" redefined
by kbuild test robot
tree: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
head: 5a044158d4606fdf905c4dfd3038db62d0b08537
commit: 3b06fd9bb2cf42d58eab47b3bd73af6cc6291545 [5/6] ACPI: bus: Use different default debug value than ACPICA
config: riscv-tinyconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 8.1.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 3b06fd9bb2cf42d58eab47b3bd73af6cc6291545
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=riscv
All warnings (new ones prefixed by >>):
In file included from include/acpi/acpi.h:29,
from include/linux/acpi.h:34,
from drivers/base/core.c:11:
>> include/acpi/acoutput.h:153: warning: "ACPI_DEBUG_DEFAULT" redefined
#define ACPI_DEBUG_DEFAULT (ACPI_LV_INIT | ACPI_LV_DEBUG_OBJECT | ACPI_LV_EVALUATION | ACPI_LV_REPAIR)
In file included from include/acpi/platform/acenv.h:152,
from include/acpi/acpi.h:22,
from include/linux/acpi.h:34,
from drivers/base/core.c:11:
include/acpi/platform/aclinux.h:88: note: this is the location of the previous definition
#define ACPI_DEBUG_DEFAULT (ACPI_LV_INFO | ACPI_LV_REPAIR)
vim +/ACPI_DEBUG_DEFAULT +153 include/acpi/acoutput.h
^1da177e Linus Torvalds 2005-04-16 152
4c1379d7 Bob Moore 2018-12-13 @153 #define ACPI_DEBUG_DEFAULT (ACPI_LV_INIT | ACPI_LV_DEBUG_OBJECT | ACPI_LV_EVALUATION | ACPI_LV_REPAIR)
3a58176e Bob Moore 2009-12-11 154 #define ACPI_NORMAL_DEFAULT (ACPI_LV_INIT | ACPI_LV_DEBUG_OBJECT | ACPI_LV_REPAIR)
^1da177e Linus Torvalds 2005-04-16 155 #define ACPI_DEBUG_ALL (ACPI_LV_AML_DISASSEMBLE | ACPI_LV_ALL_EXCEPTIONS | ACPI_LV_ALL)
^1da177e Linus Torvalds 2005-04-16 156
:::::: The code at line 153 was first introduced by commit
:::::: 4c1379d7bb42fa664e0784539208ed74108c53f1 ACPICA: Debug output: Add option to display method/object evaluation
:::::: TO: Bob Moore <robert.moore(a)intel.com>
:::::: CC: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
2 years, 10 months
Re: [Devel] PROBLEM: Calling ObjectType on buffer field reports type integer
by Schmauss, Erik
> -----Original Message-----
> From: Maximilian Luz [mailto:luzmaximilian@gmail.com]
> Sent: Thursday, March 14, 2019 7:24 AM
> To: Moore, Robert <robert.moore(a)intel.com>; Schmauss, Erik
> <erik.schmauss(a)intel.com>; Wysocki, Rafael J
> <rafael.j.wysocki(a)intel.com>
> Cc: linux-acpi(a)vger.kernel.org; devel(a)acpica.org
> Subject: PROBLEM: Calling ObjectType on buffer field reports type
> integer
>
> Hi all,
>
> it seems that buffer fields (created via CreateField) are incorrectly
> reported as being of type integer (via ObjectType) when they are small
> enough to allow for that.
>
> As far as I know all kernel versions are affected by this, I have
> specifically checked 5.0 (5.0.2), 4.20, 4.19 and 4.18.
>
> In more detail: On the Microsoft Surface Book 2, Surface Pro (2017),
> Surface Pro 6, Surface Laptop and Surface Laptop 2 devices there is the
> following piece of AML code:
>
> Local0 = ^^_SAN.RQST (0x02, One, One, Zero, One)
> If ((ObjectType (Local0) != 0x03))
> {
> // Error path
> }
> Else
> {
> // Success path
> }
>
> Which executes a command (RQST) and then checks the type of the
> returned field to determine if that command was successful (i.e.
> returned a buffer object) or failed (i.e. returned any other type,
> including integer). The buffer field that is being returned by RQST is
> crated as
> follows:
>
> CreateField (RQBF, 0x20, Local3, ARB)
> Local4 = ARB /* \_SB_._SAN.RQSX.ARB_ */
> ...
> Return (Local4)
>
> If the returned buffer field is small enough (smaller than
> acpi_gbl_integer_byte_width), the error-path will always be executed.
>
> The full DSDT for the Surface Book 2 can be found here:
> https://github.com/qzed/surfacebook2-
> dsdt/blob/fa0ca7c7cba8fb0da1e79c282f9a9f4a12eaaa17/dsdt.dsl#L153
> 96
>
> I have attached a patch (for 5.0) that fixes this issue and has been in
> use on the affected devices for a few months now via
>
> https://github.com/qzed/linux-surfacegen5-acpi and
> https://github.com/jakeday/linux-surface/
>
> I'm not aware of any issues regarding the patch, but then again this
> has, to my knowledge, only been tested on Microsoft Surface devices.
I'll take a look at this and test the behavior on windows OS. Surface laptops
tend to have interesting firmware that expose these differences.
Erik
>
> Maximilian
>
> Signed-off-by: Maximilian Luz <luzmaximilian(a)gmail.com>
> ---
> drivers/acpi/acpica/dsopcode.c | 2 +-
> drivers/acpi/acpica/exfield.c | 12 +++++++++---
> 2 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/acpica/dsopcode.c
> b/drivers/acpi/acpica/dsopcode.c index 78f9de260d5f..0cd858520f5b
> 100644
> --- a/drivers/acpi/acpica/dsopcode.c
> +++ b/drivers/acpi/acpica/dsopcode.c
> @@ -123,7 +123,7 @@ acpi_ds_init_buffer_field(u16 aml_opcode,
>
> /* Offset is in bits, count is in bits */
>
> - field_flags = AML_FIELD_ACCESS_BYTE;
> + field_flags = AML_FIELD_ACCESS_BUFFER;
> bit_offset = offset;
> bit_count = (u32) length_desc->integer.value;
>
> diff --git a/drivers/acpi/acpica/exfield.c b/drivers/acpi/acpica/exfield.c
> index e5798f15793a..55abd9e035a0 100644
> --- a/drivers/acpi/acpica/exfield.c
> +++ b/drivers/acpi/acpica/exfield.c
> @@ -98,6 +98,7 @@ acpi_ex_read_data_from_field(struct
> acpi_walk_state *walk_state,
> union acpi_operand_object *buffer_desc;
> void *buffer;
> u32 buffer_length;
> + u8 field_flags;
>
> ACPI_FUNCTION_TRACE_PTR(ex_read_data_from_field,
> obj_desc);
>
> @@ -146,11 +147,16 @@ acpi_ex_read_data_from_field(struct
> acpi_walk_state *walk_state,
> * Note: Field.length is in bits.
> */
> buffer_length =
> - (acpi_size)ACPI_ROUND_BITS_UP_TO_BYTES(obj_desc-
> >field.bit_length);
> + (acpi_size)ACPI_ROUND_BITS_UP_TO_BYTES(obj_desc-
> >common_field.bit_length);
> + field_flags = obj_desc->common_field.field_flags;
>
> - if (buffer_length > acpi_gbl_integer_byte_width) {
> + if (buffer_length > acpi_gbl_integer_byte_width ||
> + (field_flags & AML_FIELD_ACCESS_TYPE_MASK) ==
> +AML_FIELD_ACCESS_BUFFER) {
>
> - /* Field is too large for an Integer, create a Buffer
> instead */
> + /*
> + * Field is either too large for an Integer, or a actually of
> type
> + * buffer, so create a Buffer.
> + */
>
> buffer_desc =
> acpi_ut_create_buffer_object(buffer_length);
> if (!buffer_desc) {
> --
> 2.20.1
>
2 years, 10 months