Work in PCI mode, but not with SDIO ACPI (All recent Chuwi tablets) #80

Open
Tikilou opened this Issue Jun 26, 2016 · 64 comments

Projects

None yet
@Tikilou
Tikilou commented Jun 26, 2016 edited

Hello, i have a Chuwi Hi10 Tablet DualOS, the drivers work correctly if i set UEFI setting SDIO ACPI to PCI, but with that, Android Freeze with the connexion is active, and Windows have somes troubles, and battery drain.

Can you add inside drivers ACPI ID's hardware for using this driver with ACPI mode ? After that this driver gonna fully support Chuwi Hi8/Hi10/Hi12/HiBook tablets

I have dumped the ACPI table and uploaded it here : http://vavar60.online.fr/share/tablet/chuwi_hi10/ACPI_Table_Dump_Chuwi-Hi10-DualOS.7z

@lwfinger
Collaborator

Does this require a patch to the kernel, or what do you want changed?

If the kernel, please submit a patch.

@Tikilou
Tikilou commented Jun 26, 2016

I don't know if it's possible, but with the same internal audio soc of my tablet (on Microsoft Surface 3), someone have gived the ACPI ID : https://bugzilla.kernel.org/show_bug.cgi?id=98001#c12

After that, an other have purposed a patch who give the possibility to an existant driver to detect ACPI ID of this SOC and use this driver with it : https://bugzilla.kernel.org/show_bug.cgi?id=98001#c18

It is possible to add something like that on this Wireless driver ?

Here it's a setting bios capture of my tablet : https://osremix.com/download/chuwi-Hi10/captures/20160606_142223.jpg

If i let "SCC SDIO Support" to "ACPI", your rtl8723bs driver is not usable, but if i choose PCI it's working. I wan't to know if you can do something about that ? (Unfortunatly, i'm not a developer, otherwise i would be happy to do something about that, and other hardware support problems...)
It's can be good with PCI setting, but unfortunatly it's causing many problems for others systems.

Can you help us please ? :) (Not just me, we are somes people would like to run GNU/Linux perfectly on this tablet, it's a long long way... : http://techtablets.com/forum/topic/linux-mint-on-a-chuwi-hi10-tablet/ )

@lwfinger
Collaborator

I know how to add ACPI IDs to the driver, but I have no interest in digging through all those tables you dumped to find the IDs that belong to the RTL8723BS. If you want the code modified, you will need to provide them.

@Tikilou
Tikilou commented Jun 27, 2016 edited

Thanks !

I'm thinking i'm found it ! :)

             Device (RTLW)
            {
                Name (AHID, "RTL8723")
                Name (ACID, "RTL8723")
                Name (_ADR, One)  // _ADR: Address
                Name (_DEP, Package (0x02)  // _DEP: Dependencies
                {
                    GPO1, 
                    GPO2
                })
                Method (_STA, 0, NotSerialized)  // _STA: Status
                {
                    Return (0x0F)
                }

              Method (_RMV, 0, NotSerialized)  // _RMV: Removal Status
                {
                    Return (Zero)
                }

                Name (_S4W, 0x02)  // _S4W: S4 Device Wake State
                Name (_S0W, 0x02)  // _S0W: S0 Device Wake State
                Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
                {
                    Name (RBUF, ResourceTemplate ()
                    {
                        GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullDown, 0x0000,
                            "\\_SB.GPO2", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x000A
                            }
                        GpioIo (Exclusive, PullNone, 0x0000, 0x0000, IoRestrictionOutputOnly,
                            "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x0034
                            }
                    })
                    Return (RBUF) /* \_SB_.PCI0.SDHB.RTLW._CRS.RBUF */
                }

                Method (APS3, 0, NotSerialized)
                {
                    If (^^^^GPO1.AVBL == One)
                    {
                        ^^^^GPO1.WLD3 = Zero
                    }
                }

                Method (_PS3, 0, NotSerialized)  // _PS3: Power State 3
                {
                    If (^^^^GPO1.AVBL == One)
                    {
                        ^^^^GPO1.WLD3 = Zero
                    }
                }

                Method (_PS2, 0, NotSerialized)  // _PS2: Power State 2
                {
                }

                Method (_PS0, 0, NotSerialized)  // _PS0: Power State 0
                {
                    If (^^^^GPO1.AVBL == One)
                    {
                        ^^^^GPO1.WLD3 = One
                    }
                }

                Method (APS0, 0, NotSerialized)
                {
                    If (^^^^GPO1.AVBL == One)
                    {
                        ^^^^GPO1.WLD3 = One
                    }
                }
            }

`
It's good ?

@lwfinger
Collaborator

I expected ACPI IDs of the form 0x0bdaXXXX, where the 0bda is for Realtek and the XXXX is for the device ID. With these numbers, the system will recognize the device in the same way that SDIO, USB, or PCI devices are found.

@Tikilou
Tikilou commented Jun 27, 2016

Okay thanks, do you know a tool for found ACPI IDs with your form ?

I've found this after [decompiling :

        Scope (URT1)
        {
            Device (BTH3)
            {
                Name (_HID, "OBDA8723")  // _HID: Hardware ID
                Method (_STA, 0, NotSerialized)  // _STA: Status
                {
                    Return (0x0F)
                }

                Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
                {
                    Name (ABUF, ResourceTemplate ()
                    {
                        UartSerialBusV2 (0x0001C200, DataBitsEight, StopBitsOne,
                            0xC0, LittleEndian, ParityTypeEven, FlowControlHardware,
                            0x0020, 0x0020, "\\_SB.PCI0.URT1",
                            0x00, ResourceConsumer, , Exclusive,
                            )
                        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                            "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x0004
                            }
                        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                            "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x0008
                            }
                        GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullDown, 0x0000,
                            "\\_SB.GPO0", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x005A
                            }
                    })
                    Name (WBUF, ResourceTemplate ()
                    {
                        UartSerialBusV2 (0x0001C200, DataBitsEight, StopBitsOne,
                            0xC0, LittleEndian, ParityTypeEven, FlowControlHardware,
                            0x0020, 0x0020, "\\_SB.PCI0.URT1",
                            0x00, ResourceConsumer, , Exclusive,
                            )
                        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                            "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x0004
                            }
                        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                            "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x0008
                            }
                        GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullDown, 0x0000,
                            "\\_SB.GPO0", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x005A
                            }
                    })
                    If (OSYS == 0x07DF)
                    {
                        Return (WBUF) /* \_SB_.PCI0.URT1.BTH3._CRS.WBUF */
                    }

                    Return (ABUF) /* \_SB_.PCI0.URT1.BTH3._CRS.ABUF */
                }
            }
        }

Maybe 0xOBDA8723 ?

@hadess
Owner
hadess commented Jun 27, 2016

This is likely a 8723be, which this driver does not support.

@lwfinger
Collaborator

I'm not sure that it is an 8723BE. If that were the case, it would only work as a PCI device.

In any case, I will prepare a patch with the ACPI description above and we will see what happens.

@Tikilou
Tikilou commented Jun 27, 2016 edited

Thanks ! ^^
On windows, official driver indicate 8723BS, same with android drivers modules.

@protectivedad

Just a note the HP Stream 7 identifies the rtl8723bs as an ACPI OBDA8723.

@franciscopaniskaseker

@lwfinger Did you write the patch?

We have a Cherry Trail x5-Z8300 and it has a Realtek RTL8723 SDIO Wifi/BT. It also has a eMMC and SD device on SDIO and I see on dmesg both of them being probed by sdhci_acpi. (80860F14:00 and 80860F14:03). The driver we are trying to use is this https://github.com/hadess/rtl8723bs and from the information we got in the issues is the device must be listed in /sys/bus/sdio/ first of all. And that's not the case for us. So we are looking into the reason the wifi device is not listed in /sys/bus/sdio/.

In /sys/bus/acpi/devices we see 80860F14:00, 80860F14:01, 80860F14:02 and 80860F14:03, and 'cat /sys/bus/acpi/devices/80860F14:01/devices:50/path' outputs SB.PCI0.SDHB.RTLW, which is the path to RTL8723.

What we don't understand is why 80860F14:01 is not probed by sdhci_acpi. Looking at the code in http://lxr.free-electrons.com/source/drivers/mmc/host/sdhci-acpi.c#L328 we see the sdhci_acpi_uids table and with

{ "80860F14" , "1" , &sdhci_acpi_slot_int_emmc },
{ "80860F14" , "3" , &sdhci_acpi_slot_int_sd },

We noticed it has an emmc slot and an sd slot, but it skips the sdio slot. We have tried adding

{ "80860F14" ,"2" , &sdhci_acpi_slot_int_sdio},

but nothing happened.

We are using last stable kernel. We are following 4.7rc news and trying to get info from Intel, but now news until now. We have CONFIG_PINCTRL_CHERRYVIEW=y and CONFIG_MMC_DEBUG=y. No relevant log until now.

DSDT excerpt:

            Device (RTLW)
            {
                Name (AHID, "RTL8723")
                Name (ACID, "RTL8723")
                Name (_ADR, One)  // _ADR: Address
                Name (_DEP, Package (0x02)  // _DEP: Dependencies
                {
                    GPO1, 
                    GPO2
                })
                Method (_STA, 0, NotSerialized)  // _STA: Status
                {
                    If (LEqual (BDID, One))
                    {
                        If (LEqual (WLTY, One))
                        {
                            Return (0x0F)
                        }
                    }

                    Return (Zero)
                }

                Method (_RMV, 0, NotSerialized)  // _RMV: Removal Status
                {
                    Return (Zero)
                }

                Name (_S4W, 0x02)  // _S4W: S4 Device Wake State
                Name (_S0W, 0x02)  // _S0W: S0 Device Wake State
                Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
                {
                    Name (RBUF, ResourceTemplate ()
                    {
                        GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullDown, 0x0000,
                            "\\_SB.GPO2", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x000A
                            }
                        GpioIo (Exclusive, PullNone, 0x0000, 0x0000, IoRestrictionOutputOnly,
                            "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x0017
                            }
                    })
                    Return (RBUF)
                }

                Method (APS3, 0, NotSerialized)
                {
                    If (LEqual (^^^^GPO1.AVBL, One))
                    {
                        Store (Zero, ^^^^GPO1.WLD3)
                    }
                }

                Method (_PS3, 0, NotSerialized)  // _PS3: Power State 3
                {
                    If (LEqual (^^^^GPO1.AVBL, One))
                    {
                        Store (Zero, PSTS)
                    }
                }

                Method (_PS2, 0, NotSerialized)  // _PS2: Power State 2
                {
                }

                Method (_PS0, 0, NotSerialized)  // _PS0: Power State 0
                {
                    If (LEqual (PSTS, Zero))
                    {
                        If (LEqual (^^^^GPO1.AVBL, One))
                        {
                            Store (One, ^^^^GPO1.WLD3)
                            Store (One, PSTS)
                        }
                    }
                }

                Method (APS0, 0, NotSerialized)
                {
                    If (LEqual (^^^^GPO1.AVBL, One))
                    {
                        Store (One, ^^^^GPO1.WLD3)
                    }
                }
            }
        Scope (URT1)
        {
            Device (BTH3)
            {
                Name (_HID, "OBDA8723")  // _HID: Hardware ID
                Method (_STA, 0, NotSerialized)  // _STA: Status
                {
                    If (LEqual (BDID, One))
                    {
                        If (LEqual (BTTY, One))
                        {
                            Return (0x0F)
                        }
                    }

                    Return (Zero)
                }

                Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
                {
                    Name (ABUF, ResourceTemplate ()
                    {
                        UartSerialBus (0x0001C200, DataBitsEight, StopBitsOne,
                            0xC0, LittleEndian, ParityTypeEven, FlowControlHardware,
                            0x0020, 0x0020, "\\_SB.PCI0.URT1",
                            0x00, ResourceConsumer, ,
                            )
                        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                            "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x0001
                            }
                        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                            "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x001B
                            }
                        GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullDown, 0x0000,
                            "\\_SB.GPO3", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x002E
                            }
                    })
                    Name (WBUF, ResourceTemplate ()
                    {
                        UartSerialBus (0x0001C200, DataBitsEight, StopBitsOne,
                            0xC0, LittleEndian, ParityTypeEven, FlowControlHardware,
                            0x0020, 0x0020, "\\_SB.PCI0.URT1",
                            0x00, ResourceConsumer, ,
                            )
                        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                            "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x001B
                            }
                        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                            "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x0001
                            }
                        GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullDown, 0x0000,
                            "\\_SB.GPO3", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x002E
                            }
                    })
                    If (LEqual (OSID, One))
                    {
                        Return (WBUF)
                    }

                    Return (ABUF)
                }
            }

            Device (BTHA)
            {
                Name (_HID, "BCM2E74")  // _HID: Hardware ID
                Method (_STA, 0, NotSerialized)  // _STA: Status
                {
                    If (LEqual (BDID, One))
                    {
                        If (LEqual (BTTY, 0x03))
                        {
                            Return (0x0F)
                        }
                    }

                    Return (Zero)
                }

                Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
                {
                    Name (BBUF, ResourceTemplate ()
                    {
                        UartSerialBus (0x0001C200, DataBitsEight, StopBitsOne,
                            0xFC, LittleEndian, ParityTypeEven, FlowControlHardware,
                            0x0020, 0x0020, "\\_SB.PCI0.URT1",
                            0x00, ResourceConsumer, ,
                            )
                        GpioInt (Level, ActiveLow, Exclusive, PullNone, 0x0000,
                            "\\_SB.GPO3", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x002E
                            }
                        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                            "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x0001
                            }
                        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                            "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x001B
                            }
                    })
                    Return (BBUF)
                }
            }

            Device (BTHB)
            {
                Name (_HID, "BCM2E95")  // _HID: Hardware ID
                Method (_STA, 0, NotSerialized)  // _STA: Status
                {
                    If (LEqual (BDID, One))
                    {
                        If (LEqual (BTTY, 0x04))
                        {
                            Return (0x0F)
                        }
                    }

                    Return (Zero)
                }

                Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
                {
                    Name (BBUF, ResourceTemplate ()
                    {
                        UartSerialBus (0x0001C200, DataBitsEight, StopBitsOne,
                            0xFC, LittleEndian, ParityTypeEven, FlowControlHardware,
                            0x0020, 0x0020, "\\_SB.PCI0.URT1",
                            0x00, ResourceConsumer, ,
                            )
                        GpioInt (Level, ActiveLow, Exclusive, PullNone, 0x0000,
                            "\\_SB.GPO3", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x002E
                            }
                        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                            "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x0001
                            }
                        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                            "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x001B
                            }
                    })
                    Return (BBUF)
                }
            }
        }
@speculatrix
speculatrix commented Jul 7, 2016 edited

please, when you raise problems, you must say what version of the kernel, where you got the sources (from www.kernel.org or from your distro) and what if any patches have you applied on top.

some versions of the kernel have had completely broken SDIO and thus this WiFi driver hasn't got a hope of working!

@franciscopaniskaseker

as I said:

We are using last stable kernel.

I mean last stable kernel from kernel official repo.

We applied all patches from patches_4.5 directory.

thank you!

@speculatrix

sorry, I missed that. it's still worth being explicit that you're using 4.6 because today's stable kernel is tomorrows old stable, so your message will age.

@ZoliN
ZoliN commented Aug 17, 2016 edited

Couldn't it be a problem that the SDHB.RTLW device is under PCI0 node in the DSDT?
It would be good if someone with working 8723BS on cherry trail posted his DSDT. Like techlast x98 plus.

Interestingly in Android (where wifi works of course) the wifi device appears under /sys/bus/sdio/RTL8723, while in linux it is under /sys/bus/sdio/80860F14:01/devices:4C.

I have no idea about acpi or kernel drivers, I am just posting my observations...

@franciscopaniskaseker

We ware using Cherrytrail z8300 and we solved the problem mapping SCC SDIO Support to PCI.

@ZoliN
ZoliN commented Aug 17, 2016

Please tell us how to do that.
Thanks in advance!

@franciscopaniskaseker

This is a BIOS setting. We asked our ODM to change that. If you do not have this option, then 8723BS will not work.

@ZoliN
ZoliN commented Aug 17, 2016

Oh I thought you had a workaround in kernel:(
The PCI setting in bios is said to cause problems in Android, so I want to avoid it.

@franciscopaniskaseker

I thought Android don't use ACPI. Am I wrong?

If you do not have implementation on ACPI, kernel can not do anything.

@ZoliN
ZoliN commented Aug 17, 2016

I thought this driver had ACPI support, but looks like I was totally wrong. No "acpi" word in the whole source code:). On the other hand looking at the android driver in a hex editor, I can see stuff like acpi_bus_get_device so I assume it is acpi compatible. Driver version is 4.3.6.2, a bit newer than this one.

@ZoliN
ZoliN commented Aug 18, 2016

version 4.3.6.2 is here:
#32

@ZoliN
ZoliN commented Aug 23, 2016

No, v4.3.6.2 didn't help at all.

However looking at intel's baytrail patches at
https://github.com/android-ia/device_intel_gmin-kernel/blob/master/x86_64/src.tgz
I think the following 2 patches are needed at least
0001-sdio-add-the-regulator-platform-device-register-for-.patch:
and the first part of 0002-Realtek-Added-RTL8723-support-for-wifi-bt-combo-ic.patch

I can see messages coming from platform_sdio_regulator.c at the beginning of Android dmesg, it is probably needed for acpi power up of wifi.

@ZoliN
ZoliN commented Aug 25, 2016

Lol I was wrong again. Actually wifi works even in ACPI mode with speculatrix's 4.5.7 kernel on my chuwi hibook, it just needed a reboot after the install of the wifi module. A simple modprobe didn't work for some reason. And I think it will work with my self compiled ubuntu 4.7 kernel too, because RTL8723 is enumerated correctly in /sys/bus/acpi/devices. I just need to build the wifi module.
Performance looks to be very inconsistent in firefox though. Sometimes I get max speed, sometimes it just hangs and does nothing for half a minute. But probably this is a completely different issue.

@speculatrix

kernel 4.5.7 gives me steady performance, I tried newer kernels but found performance very variable.
When the newer kernels proved unstable I didn't want to invest much effort anyway in other issues.

My main conclusion in all of this is that the Z37xx series Baytrail SoCs may never be better than second rate platforms for running Linux on.

@lwfinger
Collaborator

Obviously, Linux stability will never happen until people with the hardware are willing to devote the effort!

@ZoliN
ZoliN commented Aug 26, 2016

Compiled a v4.3.6.2 8723BS driver for ubuntu 4.7 kernel, and it works with SDIO set to ACPI in BIOS. I am sure the driver on this page would work too.
Applied Laszlo's patch to kernel, found here:
#76

Some packets are lost, but that happens in stock Android too. Incredible how that can happen as I am sitting 1 meter away from my router.

Unfortunately not much else work on my cherry trail tablet in linux, no brightness setting, no battery info, no touchscreen stc...

@hebrewd
hebrewd commented Aug 28, 2016

Hey,
Thank you for putting that much effort to get this working.
I hope I'm not hijacking this issue report, but I do believe I'm facing the same issue on different hardware and hope to maybe help discover more information and maybe even have this resolved.
I'm using the wintel pro z8300 -> http://www.gearbest.com/tv-box-mini-pc/pp_324845.html
(It doesn't seem like there is an official product page, so this is the closest I found)

It came with win10, wifi worked there and I installed debian on it. I upgraded to a kernel from backports and build this module, the build complete successfully but the device doesn't seem to appear. I tried speculatrix's 4.5.7 kernel as well, tried following the same step on ubuntu 16.04 lts to no avail.

dmesg: http://ix.io/1hIQ
lshw: http://ix.io/1hIR

Thanks for any sort of feeback!

@speculatrix

@hewbrewd I can't see any sign from the dmesg of the kernel being loaded. You did copy the .ko to the right place, do a depmod -a, and a modprobe?

@lwfinger
Collaborator

I cannot help yet, but I just ordered one of the Wintel Pro Z8300 devices. I found a Flash Sale and got it for $70. Once it comes, I'll try to determine what it takes to get the wifi working under Linux.

@hebrewd
hebrewd commented Aug 29, 2016 edited

@speculatrix Sorry, I guess I did send the wrong dmesg, this one does have the module load log in it as well.
http://ix.io/1hXu
As per the installation, I used make install after building the module from source.
@lwfinger That's awesome, thank you both for the feedback, if you have any idea of something you would like me to try, let me know, I wouldn't mind giving it a shot.

For now I guess I will try a precompiled module and see if I get different results.

EDIT: I did try the precompiled module with the same results.
EDIT2: just to confirm, I used the kernel at http://www.zaurus.org.uk/download/toshiba_click_mini_l9w/
version 4.5.7

@tgharib
tgharib commented Sep 18, 2016

@lwfinger: Make sure to check you got the realtek one in Windows's device manager before wiping Windows. There are actually two Wintel CX-W8 Pro models under the same model number: one has a realtek wifi chip and the other has broadcom.

@tagorereddy
tagorereddy commented Oct 7, 2016 edited

I don't know if this helps anyone, but I found a solution for my device.

I have a similar Hardware to this running on x5-z8300 SoC. I've managed to isolate the problem on my netbook.
The 'sdhci-acpi' driver couldn't detect a platform device for the SDIO Controller(80860F14:01 in my case).
The platform device is supposed to be created at system boot but it wasn't because the SDIO Controller is being attached to a physical node via PCI 80862280.
This should happen only if SDIO is in PCI mode and not ACPI mode. Preventing this from happening at boot is simple but somehow the enumeration of this PCI is key for Display driver to work as both are on same bus.
So I made a work-around.

First to confirm if your case is same as mine, just comfirm if your SDIO controller has a physical node:

tree /sys/bus/acpi/devices/80860F14:01

You should see if it has any physical nodes. If that is the case, then this workaround applies to you.
In my case, the physical node is pci 0000:00:00.0 whose VID is 8086 and PID is 2280.

Now, the work-around involves patching your kernel and rebuilding it entirely.
Check the patch for modifications and rebuild the kernel.

From: T-Chan
Subject: [PATCH] Rudimentary bypass fix Atom CherryTrail SoCs with  problems enumerating SDIO Controller in ACPI mode

Changes to be committed:
    modified:   drivers/mmc/host/sdhci-acpi.c
    modified:   drivers/acpi/acpi_platform.c
---
 drivers/mmc/host/sdhci-acpi.c            | 18 ++++++++++++++++++
 drivers/acpi/acpi_platform.c            |  9 ++++++++--
 2 files changed, 25 insertions(+), 2 deletions(-)

--- a/drivers/acpi/acpi_platform.c  
+++ b/drivers/acpi/acpi_platform.c  
@@ -68,8 +68,13 @@

    /* If the ACPI node already has a physical device attached, skip it. */
    if (adev->physical_node_count)
-       return NULL;
-
+   {
+       if(!strcmp(acpi_device_hid(adev),"80860F14") && !strcmp(adev->pnp.unique_id,"2"))
+               dev_info(&adev->dev,"Physical node found. Proceeding anyway\n");
+       else
+               return NULL;        
+   }
+       
    if (!acpi_match_device_ids(adev, forbidden_id_list))
        return ERR_PTR(-EINVAL);

--- a/drivers/mmc/host/sdhci-acpi.c
+++ b/drivers/mmc/host/ssdhci-acpi.c
@@ -48,6 +48,9 @@
 #endif

 #include "sdhci.h"
+#include <linux/pci.h>
+
+void patch(struct acpi_device *adev);

 enum {
    SDHCI_ACPI_SD_CD        = BIT(0),
@@ -405,6 +408,10 @@
    hid = acpi_device_hid(device);
    uid = device->pnp.unique_id;

+   /*Apply patch if you find the sibling device.*/
+   if (!strcmp(hid, "80860F14") && !strcmp(uid, "1"))
+       patch(device);
+   
    iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
    if (!iomem)
        return -ENOMEM;
@@ -571,6 +578,17 @@
 };

 module_platform_driver(sdhci_acpi_driver);
+
+/*Custom patch for a specific SDIO Controller*/
+void patch(struct acpi_device *adev)
+{
+       struct pci_dev *pcidev = NULL;
+       
+       pcidev = pci_get_device(0x8086,0x2280,NULL);
+       if(!pcidev)
+           return;
+       pci_stop_and_remove_bus_device(pcidev);
+}

 MODULE_DESCRIPTION("Secure Digital Host Controller Interface ACPI driver");
 MODULE_AUTHOR("Adrian Hunter");

The next part involves fixing display driver if in case it has not been initiated.
Add this to /etc/init.d/boot.local or similar file according to your distro.

echo "1" > /sys/bus/pci/rescan
modprobe -r i915
modprobe i915
echo "1" > /sys/bus/pci/devices/0000\:00\:00.0/remove

Choose the display driver and pci device appropriately according to your device.
I have not tested this with sleep/hibernate functions.

@lwfinger
Collaborator
lwfinger commented Oct 8, 2016

Your patch is interesting, but it did not work at all on my CherryTrail device. On the other hand, I am working on the ACPI module interface. I am likely quite a ways from getting it to work; however, the device is being recognized. It is a promising start!

I will keep the list informed.

@tagorereddy

@lwfinger the patch was simply a guideline as to what to do. By reading the code you can interpret what I was doing and replicate in your kernel. For me, the device is detected under /sys/bus/platform/devices as 80860F14:01. Later the SDHCI controller is installed and enumerated mmc device under /sys/bus/sdio/devices. Then the wifi driver takes over and works perfectly. BTW, I've not used any of the patches on the kernel. It's 4.8 final.

Please check if your pci device is still attached and appropriate HID or CID of the SDIO is listed in sdhci-acpi. Its a simple straight forward patch. It has to work.

Also I'm close to getting the i2c-designware PUNIT semaphore problem solved. I find the IOSF-MBI driver inadequate as it enumerates PCI and not ACPI devices.

@tagorereddy
tagorereddy commented Oct 9, 2016 edited

@lwfinger My apologies. Slight logical error in the sdhci patch. Fixed it now.
Also it would help if u omit sdhci-acpi in initrd and include drm. That way you can load display driver before sdhci driver which will let you skip etc/init.d part.

@aszlig aszlig added a commit to openlab-aux/vuizvui that referenced this issue Oct 13, 2016
@aszlig aszlig hardware/t100ha: Fix support for SDIO WiFi card
While I had terse Internet connectivity these days, I haven't checked
T100HA hardware related news/patchs very often.

Meanwhile a small patch by @tagorereddy popped up on hadess/rtl8723bs#80
which works around the SDIO detection.

On some devices the BIOS has an option to map the SDIO controller to PCI
instead of ACPI, but the T100HA doesn't have this option.

IIUC the issue here is that the controller is already being attached via
PCI device ID 80862280, which prevented the platform device from being
attached via ACPI.

The patch circumvents that by removing PCI device ID 80862280 while
probing for ACPI devices in SDHCI (yes, very hacky but works) and forces
the ACPI platform device to be initialized if the HID is 80860F14:02.

I've rebased and tidied up the original patch a bit to prevent warnings
during build.

Other than this patch, we now need to add the right firmware and the
corresponding parameters to hardware.firmware, so that the actual driver
for the WiFi card can be loaded.

The firmware parameters are stored in EFI on the host itself:

/sys/firmware/efi/efivars/nvram-74b00bd9-805a-4d61-b51f-43268123d113

So I added a copy of it to prevent impurities.

Signed-off-by: aszlig <aszlig@redmoonstudios.org>
992f5d8
@escalade

@lwfinger

Did you get anywhere with the Wintel Pro? I've got the CX-W8 (guessing it's the same you ordered), would be nice to get wireless and bluetooth going.

@lwfinger

I've tried your patch and @aszlig's version without success. When I set the SCC SDIO devices to PCI in the EFI setup I can see them with lspci, but nothing happens when loading r8723bs (or the newer 8723bs from @anthonywong). Nothing shows up in /sys/bus/sdio/devices with SCC set to either ACPI or PCI.

My dmesg with SCC @ PCI: http://sprunge.us/dBbe

Any ideas?

@lwfinger
Collaborator

I have learned a lot about ACPI drivers, but I'm not there yet. My code recognizes the card and creates a platform device, but I am stuck at the next step.

I'm surprised that the device was not recognized after you set the SDIO devices to PCI. That option does not appear in my BIOS.

@tgharib
tgharib commented Oct 27, 2016

I have a Wintel CX-W8 Pro (Realtek version) and the option does appear in my BIOS. For me, it's under Advanced Tab --> Chipset Configuration --> SCC Configuration.

img_20161027_123108
img_20161027_123147
img_20161027_123156
img_20161027_123213

@escalade

@lwfinger

Yeah, I was surprised as well as seeing as other devices have success with PCI mode. Could it be that it's not an RTL8723? Apparently it can have either that or AP6234, which I can't seem to find any information or drivers for.

@tgharib

Sadly I forgot to check before wiping Windows, any other way to check? Is the AP6234 a broadcom? I've tried the brcmfmac driver but that doesn't work either. Have you gotten wireless/bluetooth/sd working at all?

@lwfinger
Collaborator

It turns out my BIOS was set to PCI mode, but the device was not recognized in the driver.

You can check what device you have in /sys/bus/platform/devices/. The Realtek device will be listed as OBDA8723. (That first character is a capital O, not a zero.). My ACPI driver is now reaching the probe routine. Next I have to figure out what is needed there.

@escalade

@lwfinger

There's no OBDA8723 for me. I'm in PCI mode though, would that make it not show? At work atm so can't change it to check.

I do see a BCM2E74 though, but I guess that could be Bluetooth?

@lwfinger
Collaborator

On my system, I get the OBDA8723 in /sys/bus/platform/devices/ whether it is using ACPI or PCI mode. One thing I have learned is that my new code that creates the rtl8723bs device in that directory seems to work the same in both modes. The main difference is whether the SD Host controller shows up in the lspci list.

That BCM device could be Bluetooth, but the wifi and BT are usually in the same device to reduce the number of radios.

@escalade

Here's the complete list: http://sprunge.us/EQHX

Nothing like the OBDA8723 or similar exists for me. Could there still be a 8723 there connected to the bluetooth chip somehow? And if there were, could the code you are working on work for me as well?

@tgharib can you check yours?

@dsd
Contributor
dsd commented Dec 1, 2016

Just to offer a few suggestions, hopefully useful:

I think the choice you have in the BIOS here is relating to how the OS is expected to detect the SDIO host controller, it doesn't relate to how it detects the realtek wifi card. So I don't expect that your efforts to make the rtl7823bs be probe-able as an ACPI device will go anywhere.

The underlying RTL8723 is a SDIO card, and there's no escaping that, so even once you have convinced Linux that it exists on the system, the only way you're going to have Linux communicate with the card is over a SDIO bus. And as soon as Linux knows about this SDIO bus it can just send a message out to the card asking it to identify itself, and that way it will be automatically handed to the rtl8723bs driver as is done in the case where this driver is working.

If changing this BIOS option is making wifi work or not, I suggest instead focusing on the presence and detection of the mmc buses. For example lines similar to the following in dmesg:

 mmc0: SDHCI controller on ACPI [80860F14:00] using ADMA
 mmc1: SDHCI controller on ACPI [80860F14:01] using ADMA
 mmc2: SDHCI controller on ACPI [80860F14:03] using ADMA

Look for differences in the 2 configurations and work backwards from there.

In the case of the Cherry Trail product I have here, which does not have any BIOS options related to this but instead simply didn't recognise the Broadcom wifi hardware in any configuration tried, the challenges were:

  1. The ACPI definition of the SDIO bus using a device ID unknown to Linux - fixed with http://marc.info/?l=linux-mmc&m=148062439306661&w=2
  2. The bad _ADR value that @tagorereddy described above, which made Linux think the SDIO bus node was related to the PCI host bridge for which a driver was already loaded
  3. After the SDIO bus was detected, no card was detected on the bus. The wifi card was powered down by default, but the vendor told us which GPIO needs to be brought high in order to send power, also their latest BIOS seems to have the wifi card power enabled by default.

@tagorereddy, can you explain more about the PUNIT problem?

@amuramatsu amuramatsu added a commit to amuramatsu/debian-kernel-mod that referenced this issue Dec 11, 2016
@amuramatsu amuramatsu fix sdhci-sdio patch based on tagorereddy's patch at ad51b62
@amuramatsu amuramatsu added a commit to amuramatsu/debian-kernel-mod that referenced this issue Dec 14, 2016
@amuramatsu amuramatsu add sdhci-sdio patch based on tagorereddy's patch at 449f540
@jwrdegoede
Contributor

I'm seeing the same issue (rtl8732bs wifi only works when sdio is set to pci-mode in bios) on a cube iwork8 air tablet (cherrytrail z8300 soc).

Inspired by this bus I was looking under /sys/bus/acpi/devices/INT33BBL00 and I notice that there are child-devices for both broadcom-wifi + brcm bluetooth as well as for the actual realtek wifi + bluetooth, which may explain why things are not working, not sure what to do about this though.

For my tablet "not working in acpi mode" means that the tablet completely freezes as soon as the rtl8723bs driver gets loaded, are others seeing this too ?

@lwfinger
Collaborator

In my case, the device is not recognized and the driver is never loaded. Doing a manual load does nothing.

@jwrdegoede
Contributor
@jwrdegoede
Contributor

Hi,

I've managed to fix the problem on my tablet by making sure that the code to enable acpi-children in sdhci-acpi.c only calls the _PS0 method on children whos _STA (status methode) returns non 0.

See the attached patch.

Regards,

Hans

0001-mmc-sdhci-acpi-Only-powered-up-enabled-acpi-child-de.patch.zip

@tagorereddy

@dsd Regarding PUNIT

The problem is with the IOSF Sideband fabric device. The linux driver iosf-mbi is written for a pci block device. But on most cherrytrails, IOSF is acpi block. So, there's effectively no driver handling the device for now. And further complicating things, the current IOSF-MBI driver which was written for a pci device, is loading in spite of the unavailability of the device 0x2280.

So, it is important to write a driver for IOSF-MBI acpi device which in-turn would allow us to test i2c related PUNIT semaphore.

I've written a rudimentary driver for IOSF-MBI in acpi mode, but its not working yet. May be I will have to test it against other devices using IOSF-MBI like Thermal Engine. I'm on it right now.

@jwrdegoede
Contributor
@fengguang fengguang added a commit to 0day-ci/linux that referenced this issue Dec 21, 2016
@jwrdegoede @fengguang jwrdegoede + fengguang mmc: sdhci-acpi: Only powered up enabled acpi child devices
Commit e5bbf30 ("mmc: sdhci-acpi: Ensure connected devices are
powered when probing") introduced code to powerup any acpi child
nodes listed in the dstd. But some dstd-s list all possible devices
used on some board variants, while reporting if the device is actually
present and enabled in the status field of the device.

So we end up calling the acpi _PS0 (power-on) method for devices which
are not actually present. This does not always end well, e.g. on my
cube iwork8 air tablet, this results in freezing the entire tablet as
soon as the r8723bs module is loaded.

This commit fixes this by checking the child device's status.present
and status.enabled bits and only call acpi_device_fix_up_power()
if both are set.

Fixes: e5bbf30 ("mmc: sdhci-acpi: Ensure connected devices are powered when probing")
BugLink: hadess/rtl8723bs#80
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
4b6fb1b
@jwrdegoede
Contributor

Offtopic:

Forget my previous comment saying:

Note that bug also has a (likely working) patch attached for the not binding to iosf_mbi devices in acpi mode issue.

The current iosf_mbi driver simply binds to the pci host bridge, which always work, so there is no problem with the iosf_mbi driver.

There is an issue on cherry-trail devices with the punit bus semaphore, I've posted patches fixing this upstream, for more details see: https://bugzilla.kernel.org/show_bug.cgi?id=155241 and for the patches: https://git.linuxtv.org/hgoede/gspca.git/log/?h=drm-intel-next-queued (they will be dropped from there once they are upstream).

@jwrdegoede
Contributor

@tagorereddy and others with the problem with the 80860F14 uid "2"
0001-ACPI-LPSS-Work-around-wrong-sdio-_ADR-0-entry-on-som.patch.zip
0001-ACPI-LPSS-Work-around-wrong-sdio-_ADR-0-entry-on-som.patch.zip
0001-ACPI-LPSS-Work-around-wrong-sdio-_ADR-0-entry-on-som.patch.zip

mmc controller not showing up at all due to it having a bogus _ADR 0 entry in the firmware (I think this is meant as an sdio function address, but it is in the wrong place for that), yesterday the jumper ezpad mini3 I ordered arrived and it has the same issue.

I'm attaching a patch fixing this.

@tagorereddy

@jwrdegoede Thanks Hans.

@jwrdegoede
Contributor
@fengguang fengguang added a commit to 0day-ci/linux that referenced this issue Dec 25, 2016
@jwrdegoede @fengguang jwrdegoede + fengguang ACPI / LPSS: Work around wrong sdio _ADR 0 entry on some byt/cht devices
The firmware on some cherrytrail devices wrongly adds _ADR 0 to their
entry describing the 80860F14 uid "2" sd-controller.

I believe the firmware writers intended this as a sdio function address,
but it is in the wrong place for this, so it gets interpreted as a pci
address, causing the node describing the sd-controller used for the
sdio-wifi to get seen as a firmware_node for the pci host bridge, rather
then being stand-alone device.

This commit adds a byt_sdio_setup function which detects this scenario
and removes the wrong firmware_node link from the pci host bridge, which
fixes acpi_create_platform_device returning NULL, leading to non-working
sdio-wifi.

BugLink: hadess/rtl8723bs#80
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
d72d961
@tagorereddy
tagorereddy commented Dec 27, 2016 edited

@jwrdegoede My device is a laptop with no USB charging or OTG. So, I'd tried only SDIO _ADR patch, i2c and axp288_fuel_gauge patches. Everything works well for upto 3 mins after boot, then the device freezes. I hadn't tried any drm patches BTW. Here's the log:

[drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake ack request.
[drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake ack request.
[drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake ack request.
[drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake ack request.
clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large:
clocksource:                       'refined-jiffies' wd_now: 10002ee30 wd_last: 10002edb8 mask: ffffffff
clocksource:                       'tsc' cs_now: 16ac2c7744a cs_last: 16a8d9bd8f2 mask: ffffffffffffffff
clocksource: Switched to clocksource refined-jiffies
usb 1-2: reset high-speed USB device number 2 using xhci_hcd
i2c_designware 808622C1:06: punit semaphore timed out, resetting
i2c_designware 808622C1:06: PUNIT SEM: 2
i2c_designware 808622C1:06: couldn't acquire bus ownership
axp288_fuel_gauge axp288_fuel_gauge: axp288 reg read err:-110
axp288_fuel_gauge axp288_fuel_gauge: PWR STAT read failed:-110
usb 1-2: reset high-speed USB device number 2 using xhci_hcd
usb 1-2: reset high-speed USB device number 2 using xhci_hcd
usb 1-2: reset high-speed USB device number 2 using xhci_hcd
i2c_designware 808622C1:06: punit semaphore timed out, resetting
i2c_designware 808622C1:06: PUNIT SEM: 0
i2c_designware 808622C1:06: couldn't acquire bus ownership
axp288_fuel_gauge axp288_fuel_gauge: IIO channel read error: fffffffb, 0
power_supply axp288_fuel_gauge: driver failed to report `voltage_now' property: -5
***SYSTEM FREEZE***

UPDATE: I'd disabled i915 module during boot to only find that device runs perfectly fine and axp288-fuel-gauge cause no issue. So, I guess current set of patches(i2c or axp2) are conflicting with i915 or its related modules(drm, i2c-algo-bit).

@jwrdegoede
Contributor
@tagorereddy

@jwrdegoede Yes. It is a cherrytrail device. x5-z8300 based SoC.

Without any of your patches, i2c-designware-batrail trips at wrong PUNIT address. After applying your patches, axp288 battery only works if i915 module(and its dependencies) is not loaded. If i unload axp288-fuel-gauge then i can load i915 with no problems. But when both modules are loaded, something is going haywire and leading to ultimate system freeze.

As you can see in the log, the bug is causing clock to go haywire and ultimately all modules that depend on jiffies are malfunctioning. Naturally its leading to i2c-designware related system freeze.

can some module be accessing wrong i2c bus? Both drm and axp288 are located on i2c busses.

@jwrdegoede
Contributor
@jwrdegoede jwrdegoede added a commit to jwrdegoede/linux-sunxi that referenced this issue Jan 1, 2017
@jwrdegoede jwrdegoede ACPI / LPSS: Work around wrong sdio _ADR 0 entry on some byt/cht devices
The firmware on some cherrytrail devices wrongly adds _ADR 0 to their
entry describing the 80860F14 uid "2" sd-controller.

I believe the firmware writers intended this as a sdio function address,
but it is in the wrong place for this, so it gets interpreted as a pci
address, causing the node describing the sd-controller used for the
sdio-wifi to get seen as a firmware_node for the pci host bridge, rather
then being stand-alone device.

This commit adds a byt_sdio_setup function which detects this scenario
and removes the wrong firmware_node link from the pci host bridge, which
fixes acpi_create_platform_device returning NULL, leading to non-working
sdio-wifi.

BugLink: hadess/rtl8723bs#80
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2c89e8a
@jwrdegoede
Contributor

Hi,

Here:

0001-ACPI-scan-Prefer-devices-without-_HID-_CID-for-_ADR-.patch.zip

Is a new patch from upstream discussion of my _ADR 0 fix, which fixes this problem in a more generic manner.

Regards,

Hans

@sudipm-mukherjee sudipm-mukherjee pushed a commit to sudipm-mukherjee/parport that referenced this issue Jan 13, 2017
@jwrdegoede @storulf jwrdegoede + storulf mmc: sdhci-acpi: Only powered up enabled acpi child devices
Commit e5bbf30 ("mmc: sdhci-acpi: Ensure connected devices are
powered when probing") introduced code to powerup any acpi child
nodes listed in the dstd. But some dstd-s list all possible devices
used on some board variants, while reporting if the device is actually
present and enabled in the status field of the device.

So we end up calling the acpi _PS0 (power-on) method for devices which
are not actually present. This does not always end well, e.g. on my
cube iwork8 air tablet, this results in freezing the entire tablet as
soon as the r8723bs module is loaded.

This commit fixes this by checking the child device's status.present
and status.enabled bits and only call acpi_device_fix_up_power()
if both are set.

Fixes: e5bbf30 ("mmc: sdhci-acpi: Ensure connected devices are powered when probing")
BugLink: hadess/rtl8723bs#80
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
e1d070c
@electrikjesus electrikjesus pushed a commit to BlissRoms-x86/kernel_common that referenced this issue Jan 19, 2017
@jwrdegoede jwrdegoede mmc: sdhci-acpi: Only powered up enabled acpi child devices
Commit e5bbf30 ("mmc: sdhci-acpi: Ensure connected devices are
powered when probing") introduced code to powerup any acpi child
nodes listed in the dstd. But some dstd-s list all possible devices
used on some board variants, while reporting if the device is actually
present and enabled in the status field of the device.

So we end up calling the acpi _PS0 (power-on) method for devices which
are not actually present. This does not always end well, e.g. on my
cube iwork8 air tablet, this results in freezing the entire tablet as
soon as the r8723bs module is loaded.

This commit fixes this by checking the child device's status.present
and status.enabled bits and only call acpi_device_fix_up_power()
if both are set.

Fixes: e5bbf30 ("mmc: sdhci-acpi: Ensure connected devices are powered when probing")
BugLink: hadess/rtl8723bs#80
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
bf607b5
@electrikjesus electrikjesus pushed a commit to BlissRoms-x86/kernel_common that referenced this issue Jan 19, 2017
@jwrdegoede jwrdegoede mmc: sdhci-acpi: Only powered up enabled acpi child devices
Commit e5bbf30 ("mmc: sdhci-acpi: Ensure connected devices are
powered when probing") introduced code to powerup any acpi child
nodes listed in the dstd. But some dstd-s list all possible devices
used on some board variants, while reporting if the device is actually
present and enabled in the status field of the device.

So we end up calling the acpi _PS0 (power-on) method for devices which
are not actually present. This does not always end well, e.g. on my
cube iwork8 air tablet, this results in freezing the entire tablet as
soon as the r8723bs module is loaded.

This commit fixes this by checking the child device's status.present
and status.enabled bits and only call acpi_device_fix_up_power()
if both are set.

Fixes: e5bbf30 ("mmc: sdhci-acpi: Ensure connected devices are powered when probing")
BugLink: hadess/rtl8723bs#80
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
89ea652
@jwrdegoede jwrdegoede added a commit to jwrdegoede/linux-sunxi that referenced this issue Jan 22, 2017
@jwrdegoede jwrdegoede mmc: sdhci-acpi: Only powered up enabled acpi child devices
Commit e5bbf30 ("mmc: sdhci-acpi: Ensure connected devices are
powered when probing") introduced code to powerup any acpi child
nodes listed in the dstd. But some dstd-s list all possible devices
used on some board variants, while reporting if the device is actually
present and enabled in the status field of the device.

So we end up calling the acpi _PS0 (power-on) method for devices which
are not actually present. This does not always end well, e.g. on my
cube iwork8 air tablet, this results in freezing the entire tablet as
soon as the r8723bs module is loaded.

This commit fixes this by checking the child device's status.present
and status.enabled bits and only call acpi_device_fix_up_power()
if both are set.

Fixes: e5bbf30 ("mmc: sdhci-acpi: Ensure connected devices are powered when probing")
BugLink: hadess/rtl8723bs#80
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
bff7229
@Tuxman2 Tuxman2 referenced this issue in burzumishi/linux-baytrail-flexx10 Jan 25, 2017
Open

Battery is not supported #11

@brgl brgl added a commit to brgl/linux that referenced this issue Jan 25, 2017
@jwrdegoede @brgl jwrdegoede + brgl mmc: sdhci-acpi: Only powered up enabled acpi child devices
Commit e5bbf30 ("mmc: sdhci-acpi: Ensure connected devices are
powered when probing") introduced code to powerup any acpi child
nodes listed in the dstd. But some dstd-s list all possible devices
used on some board variants, while reporting if the device is actually
present and enabled in the status field of the device.

So we end up calling the acpi _PS0 (power-on) method for devices which
are not actually present. This does not always end well, e.g. on my
cube iwork8 air tablet, this results in freezing the entire tablet as
soon as the r8723bs module is loaded.

This commit fixes this by checking the child device's status.present
and status.enabled bits and only call acpi_device_fix_up_power()
if both are set.

Fixes: e5bbf30 ("mmc: sdhci-acpi: Ensure connected devices are powered when probing")
BugLink: hadess/rtl8723bs#80
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
caaabcb
@woodsts woodsts pushed a commit to woodsts/linux-stable that referenced this issue Jan 26, 2017
@jwrdegoede @gregkh jwrdegoede + gregkh mmc: sdhci-acpi: Only powered up enabled acpi child devices
commit e1d070c upstream.

Commit e5bbf30 ("mmc: sdhci-acpi: Ensure connected devices are
powered when probing") introduced code to powerup any acpi child
nodes listed in the dstd. But some dstd-s list all possible devices
used on some board variants, while reporting if the device is actually
present and enabled in the status field of the device.

So we end up calling the acpi _PS0 (power-on) method for devices which
are not actually present. This does not always end well, e.g. on my
cube iwork8 air tablet, this results in freezing the entire tablet as
soon as the r8723bs module is loaded.

This commit fixes this by checking the child device's status.present
and status.enabled bits and only call acpi_device_fix_up_power()
if both are set.

Fixes: e5bbf30 ("mmc: sdhci-acpi: Ensure connected devices are powered when probing")
BugLink: hadess/rtl8723bs#80
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
c1274ee
@evil-god evil-god added a commit to evil-god/linux-lts-4.9.y that referenced this issue Jan 26, 2017
@jwrdegoede @evil-god jwrdegoede + evil-god mmc: sdhci-acpi: Only powered up enabled acpi child devices
commit e1d070c3793a2766122865a7c2142853b48808c5 upstream.

Commit e5bbf30 ("mmc: sdhci-acpi: Ensure connected devices are
powered when probing") introduced code to powerup any acpi child
nodes listed in the dstd. But some dstd-s list all possible devices
used on some board variants, while reporting if the device is actually
present and enabled in the status field of the device.

So we end up calling the acpi _PS0 (power-on) method for devices which
are not actually present. This does not always end well, e.g. on my
cube iwork8 air tablet, this results in freezing the entire tablet as
soon as the r8723bs module is loaded.

This commit fixes this by checking the child device's status.present
and status.enabled bits and only call acpi_device_fix_up_power()
if both are set.

Fixes: e5bbf30 ("mmc: sdhci-acpi: Ensure connected devices are powered when probing")
BugLink: hadess/rtl8723bs#80
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
b36730f
@dsd
Contributor
dsd commented Feb 1, 2017

Thanks Hans! I tested the upstream version of the _ADR fix and it works fine on an affected unit here.
BTW on one model that I have here, the original BIOS had a SDHB._ADR value of 0x00110000. That worked fine since Linux didn't find any corresponding PCI device at that address. In a BIOS update that came later it was changed to 0. Just another hint that this bad value likely comes from Intel and perhaps even seems to have been introduced during the evolution of the platform.

@tagorereddy

@dsd Hello Drake, I know you were working on ES8316 codec for CHT. Any update on the status of it please?

@evan-a-a evan-a-a added a commit to evan-a-a/linux-braswell that referenced this issue Feb 6, 2017
@jwrdegoede @evan-a-a jwrdegoede + evan-a-a mmc: sdhci-acpi: Only powered up enabled acpi child devices
Commit e5bbf30 ("mmc: sdhci-acpi: Ensure connected devices are
powered when probing") introduced code to powerup any acpi child
nodes listed in the dstd. But some dstd-s list all possible devices
used on some board variants, while reporting if the device is actually
present and enabled in the status field of the device.

So we end up calling the acpi _PS0 (power-on) method for devices which
are not actually present. This does not always end well, e.g. on my
cube iwork8 air tablet, this results in freezing the entire tablet as
soon as the r8723bs module is loaded.

This commit fixes this by checking the child device's status.present
and status.enabled bits and only call acpi_device_fix_up_power()
if both are set.

Fixes: e5bbf30 ("mmc: sdhci-acpi: Ensure connected devices are powered when probing")
BugLink: hadess/rtl8723bs#80
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
b731235
@riverzhou riverzhou pushed a commit to riverzhou/miix28kernel that referenced this issue Feb 14, 2017
@jwrdegoede jwrdegoede ACPI / LPSS: Work around wrong sdio _ADR 0 entry on some byt/cht devices
The firmware on some cherrytrail devices wrongly adds _ADR 0 to their
entry describing the 80860F14 uid "2" sd-controller.

I believe the firmware writers intended this as a sdio function address,
but it is in the wrong place for this, so it gets interpreted as a pci
address, causing the node describing the sd-controller used for the
sdio-wifi to get seen as a firmware_node for the pci host bridge, rather
then being stand-alone device.

This commit adds a byt_sdio_setup function which detects this scenario
and removes the wrong firmware_node link from the pci host bridge, which
fixes acpi_create_platform_device returning NULL, leading to non-working
sdio-wifi.

BugLink: hadess/rtl8723bs#80
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2bb9ec3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment