> Date: Tue, 28 Jul 2020 13:46:34 +1000
> From: Jonathan Matthew <jonat...@d14n.org>
>
> On Mon, Jul 27, 2020 at 05:16:47PM +0200, Mark Kettenis wrote:
> > > Date: Mon, 27 Jul 2020 17:02:41 +0200 (CEST)
> > > From: Mark Kettenis <mark.kette...@xs4all.nl>
> > >
> > > Recent ACPI versions have deprecated "Processor()" nodes in favout of
> > > "Device()" nodes with a _HID() method that returns "ACPI0007". This
> > > diff tries to support machines with firmware that implements this. If
> > > you see something like:
> > >
> > > "ACPI0007" at acpi0 not configured
> > >
> > > please try the following diff and report back with an updated dmesg.
> > >
> > > Cheers,
> > >
> > > Mark
> >
> > And now with the right diff...
>
> On a dell r6415, it looks like this:
>
> acpicpu0 at acpi0copyvalue: 6: C1(@1 halt!)
> all the way up to
> acpicpu127 at acpi0copyvalue: 6: no cpu matching ACPI ID 127
>
> which I guess means aml_copyvalue() needs to learn how to copy
> AML_OBJTYPE_DEVICE.
Yes. It is not immediately obvious how this should work. Do we need
to copy the aml_node pointer or not? We don't do that for
AML_OBJTYPE_PROCESSOR and AML_OBJTYPE_POWERRSRC types which are
similar to AML_OBJTYPE_DEVICE. But AML_OBJTYPE_DEVICE object don't
carry any additional information. So we end up with just an empty
case to avoid the warning.
Does this work on the Dell machines?
Index: dev/acpi/dsdt.c
===================================================================
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.252
diff -u -p -r1.252 dsdt.c
--- dev/acpi/dsdt.c 21 Jul 2020 03:48:06 -0000 1.252
+++ dev/acpi/dsdt.c 28 Jul 2020 09:04:15 -0000
@@ -996,6 +996,8 @@ aml_copyvalue(struct aml_value *lhs, str
lhs->v_objref = rhs->v_objref;
aml_addref(lhs->v_objref.ref, "");
break;
+ case AML_OBJTYPE_DEVICE:
+ break;
default:
printf("copyvalue: %x", rhs->type);
break;
