On Tue, Mar 23, 2021 at 05:28:37PM +0100, Mark Kettenis wrote: > > 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?
Two of them: dwiic0 at pci0 dev 21 function 0 "Intel 400 Series I2C" rev 0x00: apic 2 int 22 iic0 at dwiic0 dwiic1 at pci0 dev 21 function 1 "Intel 400 Series I2C" rev 0x00: apic 2 int 23 iic1 at dwiic1 > 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. Thanks a lot!
