> Date: Tue, 23 Mar 2021 16:56:33 +0100
> From: Theo Buehler <[email protected]>
>
> On Tue, Mar 23, 2021 at 04:13:53PM +0100, Mark Kettenis wrote:
> > > Date: Tue, 23 Mar 2021 14:14:40 +0100
> > > From: Theo Buehler <[email protected]>
> >
> > It would help if you could try and boot a kernel that adds some debug
> > prints instead of calling aml_die(). Probably need to know the values
> > of alen, bpos, blen, mode and flag for starters.
>
> Thanks.
>
> alen 0x00, bpos 0x278, blen 0x10, mode 0x00, flag 0x605
>
> So: AML_FIELD_ACCESS(flag) == AML_FIELD_BUFFER_ACC, bpos & 0x03 == 0
> and the aml_die("Invalid GenericSerialBus access") is hit because blen
> is twice as long as it should be according to the conditional preceding
> it:
>
> if (AML_FIELD_ACCESS(flag) != AML_FIELD_BUFFERACC ||
> bpos & 0x3 || blen != 8)
Right, we need to figure out what this actually means. The ACPI
standard isn't exactly clear on this...
> If I skip the aml_die("Invalid GenericSerialBus access"), it hits the
> next aml_die("Could not find GenericSerialBus controller"); because
> node->i2c == NULL.
If I'm reading the AML and FreeBSD dmesg correctly this is an i2c
controller that attaches to PCI. I suspect that it is dwiic(4). D
you see dwiic(4) attach?
If so, the problem is that we dont't call acpi_register_gsb() for
dwiic(4) instances that attach to PCI. I'll see if I can come up with
a diff for that.
