On the SP2017 there is no hint of a battery present: - ADP1 is the only entry in /sys/class/power_supply; no BAT* entries - "upower -d", "acpi -V", "dmidecode -t 22", and "find /sys/devices -name \*power_supply\*" all return nothing battery-related Also, "acpi --ac-adapter" and similar show the adapter as off-line even when plugged in. Battery detection and power supply queries works fine on the previous generation (Surface Pro 4) which has the same MSHW0040 HID device. Please find attached: - dmesg output - acpidump outputs - /sys/firmware/acpi/tables/* Let me know if there's anything else I can provide or try. As an aside, I've tried the various Surface Pro kernel patches and none of them resolve this either.
Created attachment 261119 [details] "dmesg" output
Created attachment 261121 [details] "acpidump" output
Created attachment 261123 [details] "acpidump -b" dsdt output
Created attachment 261125 [details] Tarball of /sys/firmware/acpi/tables/*
I've also been investigating this issue. Acpidump and dsdt.dat are identical to Steve's, as expected. Attached are my logs for extra info, as well as the decompiled DSDT. The DSDT is clearly being loaded, and other HIDs, such as the lid (PNP0C0D), are detected. I'm digging through the ACPI code to see what triggers loading of the drivers, but I don't have much experience with the kernel, unfortunately. Anybody have any pointers on where to start looking? A few lines of note from dmesg: Dec 04 18:23:11 gjbu kernel: ACPI Error: [_SB_.PCI0] Namespace lookup failure, AE_NOT_FOUND (20170728/dswload2-191) Dec 04 18:23:11 gjbu kernel: ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20170728/psobject-252) Dec 04 18:23:11 gjbu kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.UA02, AE_NOT_FOUND (20170728/psparse-550) Dec 04 18:23:11 gjbu kernel: ACPI: Executed 26 blocks of module-level executable AML code Dec 04 18:23:11 gjbu kernel: ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored I don't see how this would be directly related to the ACPI battery, however.
Created attachment 261135 [details] Decompiled DSDT
Created attachment 261137 [details] Journalctl log output
Edward, please confirm if you have the same machine as Steve. please reboot with boot option "acpi.aml_debug_output=1" and attach the dmesg output after boot.
Created attachment 261241 [details] SP2017 dmesg w/ acm_debug_output=1
Hi, this affects the Surface Book2 13" as well. If you need some debug outputs from this one, please let me know.
Hi Zhang, Yep, I own the same device as Steve. It's the Surface Pro 2017. I've attached my dmesg with aml_debug_output=1.
Created attachment 261267 [details] dmesg-out-debug
I'm seeing lines like the following: Dec 19 19:14:13 gjbu kernel: [ACPI Debug] "PSRC: _SAN.RQST error %0" Dec 19 19:14:13 gjbu kernel: [ACPI Debug] 0x0000000000000001 This error is emitted by the ACST method of ADP1 when the result of \_SB._SAN.RQST() is not of type Buffer. The print after is the value returned. Looking at _SAN.RQST(), the only way it may return 1 is if AVBL is not 1. AVBL in _SAN is default zero, and must be modified by _SAN._REG() (Region Availability). It seems like acpi/ec.c should evaluate and run the _REG methods for each given ACPI address space, so there may be an issue there.
Method (ACST, 0, Serialized) { Local2 = Zero Local0 = \_SB._SAN.RQST (0x02, 0x0D, One, Zero, One) If (ObjectType (Local0) != 0x03) { Debug = "PSRC: _SAN.RQST error %0\n" Debug = Local0 } ElseIf (SizeOf (Local0) == 0x04) { Local2 = ToInteger (Local0) } Else { Debug = "PSRC: _SAN.RQST len error %0 (expected %1)\n" Debug = SizeOf (Local0) Debug = 0x04 } Debug = "ACST: AC adapter status returns %0X\n" Debug = Local2 Return (Local2) } And according to the dmesg output [ 1.256848] ACPI Debug: "PSRC: _SAN.RQST error %0 " [ 1.256851] ACPI Debug: 0x0000000000000001 [ 1.256854] ACPI Debug: "ACST: AC adapter status returns %0X " [ 1.256857] ACPI Debug: 0x0000000000000000 [ 1.256868] ACPI Debug: "ADP1: _PSR.......returned 0" So the \_SB._SAN.RQST return value is not a buffer, and this results in the _PSR return 0 (offline).
(In reply to Edward Shin from comment #13) > I'm seeing lines like the following: > > Dec 19 19:14:13 gjbu kernel: [ACPI Debug] "PSRC: _SAN.RQST error %0" > Dec 19 19:14:13 gjbu kernel: [ACPI Debug] 0x0000000000000001 > > This error is emitted by the ACST method of ADP1 when the result of > \_SB._SAN.RQST() is not of type Buffer. The print after is the value > returned. > > Looking at _SAN.RQST(), the only way it may return 1 is if AVBL is not 1. > AVBL in _SAN is default zero, and must be modified by _SAN._REG() (Region > Availability). Good catch. > > It seems like acpi/ec.c should evaluate and run the _REG methods for each > given ACPI address space, so there may be an issue there. Why ACPI EC? Method (_REG, 2, NotSerialized) // _REG: Region Availability { If (Arg0 == 0x09) { AVBL = Arg1 Notify (ADP1, 0x80) // Status Change Notify (BAT1, 0x81) // Information Change If (CondRefOf (BAT2)) { Notify (BAT2, One) // Device Check } } } the space id is 0x09, which is ACPI_ADR_SPACE_GSBUS. So we should install address space handler for device SAN, which is MSHW0091. Further more, OperationRegion (OR01, GenericSerialBus, Zero, 0x0100) Field (OR01, BufferAcc, NoLock, Preserve) { Connection (I2Z0), AccessAs (BufferAcc, AttribRawProcessBytes (0x02)), SAN0, 8 } so there is I2C operation region for Device SAN0. So the root cause of the problem seems to be that we're missing driver support of MSHW0091. Note that MSHW0091 has a "Surface ACPI Notify Driver" in windows.
Gotcha, makes sense. What would be the correct way to approach adding driver support? Add an implementation in drivers/i2c/busses/ and call acpi_install_address_space_handler() upon a successful probe? I'm a little confused, as I don't see ACPI_ADR_SPACE_GSBUS as a handled space_id in acpica/evhandler.c.
(In reply to Edward Shin from comment #16) > Gotcha, makes sense. What would be the correct way to approach adding driver > support? Add an implementation in drivers/i2c/busses/ and call > acpi_install_address_space_handler() upon a successful probe? > > I'm a little confused, as I don't see ACPI_ADR_SPACE_GSBUS as a handled > space_id in acpica/evhandler.c. Sorry, clearly not in /busses/. Perhaps in /drivers/power/supply/.
Hi, I see this bug is still in NEEDINFO state. Is there anything I can do to provide more information? This is quite annoying as as the Laptop just switches off without notice when the battery is empty.
I would love to have this issue fixed as well. In all other ways the kernel works so well. What information can we provide to help?
The next step is to reverse engineer the MSHW0091 I2C device and write a driver for it. I may give this a shot when I have time, unless someone more experienced wants to step in. :)
It's been a couple months and I haven't seen any change from the NEEDINFO status. I'd be happy to help out in any way, or place a bounty if that's whats required to get this fixed.
well, as Edward Shin mentioned, some people needs to reverse engineer the MSHW0091 I2C driver and submit a driver for it. TBH, I don't know when this is going to happen.
It seems that we need to create the I2C driver. I have plenty of resources available (a team of developers, none with I2C or ACPI experience) but I'm not sure where to start. I have seen all of the documentation for I2C drivers in the kernel docs but it is not clear how to attach the driver to the device and how to debug it. I have explored the I2C bus on in the Surface Pro 2017 but I am not sure which device is the MSHW0091. Should I be able to communicate with it via the i2c-tools package? I am happy to dedicate time to resolve this issue but I need a bit of a push from someone to get kicked off.
(In reply to Carry Look from comment #23) > It seems that we need to create the I2C driver. I have plenty of resources > available (a team of developers, none with I2C or ACPI experience) but I'm > not sure where to start. I have seen all of the documentation for I2C > drivers in the kernel docs but it is not clear how to attach the driver to > the device and how to debug it. > > I have explored the I2C bus on in the Surface Pro 2017 but I am not sure > which device is the MSHW0091. Should I be able to communicate with it via > the i2c-tools package? > > I am happy to dedicate time to resolve this issue but I need a bit of a push > from someone to get kicked off. Hi Carry, sounds great! You might want to have a look her: https://github.com/jakeday/linux-surface Jakeday is already working on it, maybe you can get in touch with him.
I have monitored his repository but it seems like it has been a while since there has been any traction.
Is there any way I can help with NEEDINFO status? I do have the SP 2017 and some spare time to collect the necessary info and help with testing.
I have been researching this more and I have posted my findings on github. See this link for details. https://github.com/jakeday/linux-surface/issues/28#issuecomment-421102086
With some guidance I can help format code from the github repository into patches here.