SDIO wifi card is not detected with 4.5-rc kernels

SDIO wifi card is not detected with 4.5-rc kernels

[Laszlo Fiat]

Hello,

The SDIO wifi card is not detected in my Baytrail tablet with 4.5-RC kernels,
which worked fine with pre-4.5 kernels.

Kernel v4.0-4.4 versions worked nicely:

$ grep mmc dmesg-4.4.0-rc2-next-20151127.txt
[    2.421329] mmc0: SDHCI controller on ACPI [80860F14:00] using ADMA
[    2.425847] mmc1: SDHCI controller on ACPI [INT33BB:00] using ADMA
[    2.431164] mmc2: SDHCI controller on ACPI [80860F14:02] using ADMA
[    2.561342] mmc0: MAN_BKOPS_EN bit is not set
[    2.569496] mmc0: new HS200 MMC card at address 0001
[    2.571164] mmcblk0: mmc0:0001 032GE4 29.1 GiB
[    2.571453] mmcblk0boot0: mmc0:0001 032GE4 partition 1 4.00 MiB
[    2.571655] mmcblk0boot1: mmc0:0001 032GE4 partition 2 4.00 MiB
[    2.571863] mmcblk0rpmb: mmc0:0001 032GE4 partition 3 4.00 MiB
[    2.573835]  mmcblk0: p1 p2 p3 p4 p5 p6
[    2.647372] mmc1: new high speed SDIO card at address 0001
[    2.812340] mmc2: new high speed SDXC card at address 0001
[    2.812719] mmcblk1: mmc2:0001 00000 59.6 GiB

With v4.5:

$ grep mmc dmesg-4.5.0-rc4.txt
[    2.678828] mmc0: SDHCI controller on ACPI [80860F14:00] using ADMA
[    2.683332] mmc1: SDHCI controller on ACPI [INT33BB:00] using ADMA
[    2.705315] mmc2: SDHCI controller on ACPI [80860F14:02] using ADMA
[    2.850013] mmc2: new high speed SDXC card at address 0001
[    2.858675] mmcblk0: mmc2:0001 00000 59.6 GiB
[    2.871384] mmc0: MAN_BKOPS_EN bit is not set
[    2.883166] mmc0: new HS200 MMC card at address 0001
[    2.883725] mmcblk1: mmc0:0001 032GE4 29.1 GiB
[    2.884029] mmcblk1boot0: mmc0:0001 032GE4 partition 1 4.00 MiB
[    2.884322] mmcblk1boot1: mmc0:0001 032GE4 partition 2 4.00 MiB
[    2.884518] mmcblk1rpmb: mmc0:0001 032GE4 partition 3 4.00 MiB
[    2.886442]  mmcblk1: p1 p2 p3 p4 p5 p6

Notice that the following line is missing with v4.5:

mmc1: new high speed SDIO card at address 0001

And of course the out-of-tree wifi driver (rtl8723bs) cannot find the
hardware with kernel v4.5.

The hardware is a Teclast X80h Baytrail tablet.
Cpu:  Intel(R) Atom(TM) CPU  Z3735F

I've opened a bug report for it:
https://bugzilla.kernel.org/show_bug.cgi?id=112571

The full dmesg of 4.5-rc4 is available in the bug report.

Bye,
Laszlo Fiat

Re: SDIO wifi card is not detected with 4.5-rc kernels

[Fabio Estevam]

On Wed, Feb 17, 2016 at 4:06 PM, Laszlo Fiat <laszlo.fiat@gmail.com> wrote:
> Hello,
>
> The SDIO wifi card is not detected in my Baytrail tablet with 4.5-RC kernels,
> which worked fine with pre-4.5 kernels.
>
> Kernel v4.0-4.4 versions worked nicely:
>
> $ grep mmc dmesg-4.4.0-rc2-next-20151127.txt
> [    2.421329] mmc0: SDHCI controller on ACPI [80860F14:00] using ADMA
> [    2.425847] mmc1: SDHCI controller on ACPI [INT33BB:00] using ADMA
> [    2.431164] mmc2: SDHCI controller on ACPI [80860F14:02] using ADMA
> [    2.561342] mmc0: MAN_BKOPS_EN bit is not set
> [    2.569496] mmc0: new HS200 MMC card at address 0001
> [    2.571164] mmcblk0: mmc0:0001 032GE4 29.1 GiB
> [    2.571453] mmcblk0boot0: mmc0:0001 032GE4 partition 1 4.00 MiB
> [    2.571655] mmcblk0boot1: mmc0:0001 032GE4 partition 2 4.00 MiB
> [    2.571863] mmcblk0rpmb: mmc0:0001 032GE4 partition 3 4.00 MiB
> [    2.573835]  mmcblk0: p1 p2 p3 p4 p5 p6
> [    2.647372] mmc1: new high speed SDIO card at address 0001
> [    2.812340] mmc2: new high speed SDXC card at address 0001
> [    2.812719] mmcblk1: mmc2:0001 00000 59.6 GiB
>
> With v4.5:
>
> $ grep mmc dmesg-4.5.0-rc4.txt
> [    2.678828] mmc0: SDHCI controller on ACPI [80860F14:00] using ADMA
> [    2.683332] mmc1: SDHCI controller on ACPI [INT33BB:00] using ADMA
> [    2.705315] mmc2: SDHCI controller on ACPI [80860F14:02] using ADMA
> [    2.850013] mmc2: new high speed SDXC card at address 0001
> [    2.858675] mmcblk0: mmc2:0001 00000 59.6 GiB
> [    2.871384] mmc0: MAN_BKOPS_EN bit is not set
> [    2.883166] mmc0: new HS200 MMC card at address 0001
> [    2.883725] mmcblk1: mmc0:0001 032GE4 29.1 GiB
> [    2.884029] mmcblk1boot0: mmc0:0001 032GE4 partition 1 4.00 MiB
> [    2.884322] mmcblk1boot1: mmc0:0001 032GE4 partition 2 4.00 MiB
> [    2.884518] mmcblk1rpmb: mmc0:0001 032GE4 partition 3 4.00 MiB
> [    2.886442]  mmcblk1: p1 p2 p3 p4 p5 p6
>
> Notice that the following line is missing with v4.5:
>
> mmc1: new high speed SDIO card at address 0001
>
> And of course the out-of-tree wifi driver (rtl8723bs) cannot find the
> hardware with kernel v4.5.
>
> The hardware is a Teclast X80h Baytrail tablet.
> Cpu:  Intel(R) Atom(TM) CPU  Z3735F
>
> I've opened a bug report for it:
> https://bugzilla.kernel.org/show_bug.cgi?id=112571
>
> The full dmesg of 4.5-rc4 is available in the bug report.

I noticed the same on a imx6q-cubox-i board: the Broadcom Wifi chip
could not be detected with 4.5-rc.

Haven't had a chance to debug this yet.

Re: SDIO wifi card is not detected with 4.5-rc kernels

[Russell King - ARM Linux]

On Wed, Feb 17, 2016 at 04:41:04PM -0200, Fabio Estevam wrote:
> On Wed, Feb 17, 2016 at 4:06 PM, Laszlo Fiat <laszlo.fiat@gmail.com> wrote:
> > Hello,
> >
> > The SDIO wifi card is not detected in my Baytrail tablet with 4.5-RC kernels,
> > which worked fine with pre-4.5 kernels.
> >
> > Kernel v4.0-4.4 versions worked nicely:
> >
> > $ grep mmc dmesg-4.4.0-rc2-next-20151127.txt
> > [    2.421329] mmc0: SDHCI controller on ACPI [80860F14:00] using ADMA
> > [    2.425847] mmc1: SDHCI controller on ACPI [INT33BB:00] using ADMA
> > [    2.431164] mmc2: SDHCI controller on ACPI [80860F14:02] using ADMA
> > [    2.561342] mmc0: MAN_BKOPS_EN bit is not set
> > [    2.569496] mmc0: new HS200 MMC card at address 0001
> > [    2.571164] mmcblk0: mmc0:0001 032GE4 29.1 GiB
> > [    2.571453] mmcblk0boot0: mmc0:0001 032GE4 partition 1 4.00 MiB
> > [    2.571655] mmcblk0boot1: mmc0:0001 032GE4 partition 2 4.00 MiB
> > [    2.571863] mmcblk0rpmb: mmc0:0001 032GE4 partition 3 4.00 MiB
> > [    2.573835]  mmcblk0: p1 p2 p3 p4 p5 p6
> > [    2.647372] mmc1: new high speed SDIO card at address 0001
> > [    2.812340] mmc2: new high speed SDXC card at address 0001
> > [    2.812719] mmcblk1: mmc2:0001 00000 59.6 GiB
> >
> > With v4.5:
> >
> > $ grep mmc dmesg-4.5.0-rc4.txt
> > [    2.678828] mmc0: SDHCI controller on ACPI [80860F14:00] using ADMA
> > [    2.683332] mmc1: SDHCI controller on ACPI [INT33BB:00] using ADMA
> > [    2.705315] mmc2: SDHCI controller on ACPI [80860F14:02] using ADMA
> > [    2.850013] mmc2: new high speed SDXC card at address 0001
> > [    2.858675] mmcblk0: mmc2:0001 00000 59.6 GiB
> > [    2.871384] mmc0: MAN_BKOPS_EN bit is not set
> > [    2.883166] mmc0: new HS200 MMC card at address 0001
> > [    2.883725] mmcblk1: mmc0:0001 032GE4 29.1 GiB
> > [    2.884029] mmcblk1boot0: mmc0:0001 032GE4 partition 1 4.00 MiB
> > [    2.884322] mmcblk1boot1: mmc0:0001 032GE4 partition 2 4.00 MiB
> > [    2.884518] mmcblk1rpmb: mmc0:0001 032GE4 partition 3 4.00 MiB
> > [    2.886442]  mmcblk1: p1 p2 p3 p4 p5 p6
> >
> > Notice that the following line is missing with v4.5:
> >
> > mmc1: new high speed SDIO card at address 0001
> >
> > And of course the out-of-tree wifi driver (rtl8723bs) cannot find the
> > hardware with kernel v4.5.
> >
> > The hardware is a Teclast X80h Baytrail tablet.
> > Cpu:  Intel(R) Atom(TM) CPU  Z3735F
> >
> > I've opened a bug report for it:
> > https://bugzilla.kernel.org/show_bug.cgi?id=112571
> >
> > The full dmesg of 4.5-rc4 is available in the bug report.
> 
> I noticed the same on a imx6q-cubox-i board: the Broadcom Wifi chip
> could not be detected with 4.5-rc.
> 
> Haven't had a chance to debug this yet.

Looks strange - my patch series was tested on Hummingboards and
Armada38x, though that was before 4.4.  The Hummingboards have
the same Broadcom wifi chip(s) as the Cubox-i, and they worked
fine with my original set patches - here's 4.4-rc6 on a
Hummingboard:

[    0.000000] Linux version 4.4.0-rc6+ (rmk@rmk-PC.arm.linux.org.uk) (gcc version 4.7.4 (GCC) ) #1972 SMP Sat Jan 2 18:55:35 GMT 2016
[    5.158107] brcmfmac: F1 signature read @0x18000000=0x16044330
[    5.528484] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jan 23 2013 17:47:32 version 5.90.195.114 FWID 01-f9e7e464
[    5.567722] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
[    5.629961] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code

Since then, I rebased my patch series on 4.5-rc1 before re-posting
it - though I didn't test it on the Wifi capable HBs, but now that I
try, I find that there's more serious issues here: the SDHCI driver
doesn't even probe the device, returning -ENODEV.  So, something _else_
has broken in SDHCI/MMC for the Broadcom WIFI here - tracing through
the code seems to point at the pwrseq stuff being the culpret:

[   52.175162] match->alloc failed: -517
[   52.178874] sdhci-esdhc-imx 2190000.usdhc: mmc_of_parse failed: -517
[   52.185271] sdhci-esdhc-imx 2190000.usdhc: imx probe failed

-517 is -EPROBE_DEFER, and looking at what's in the clk_summary
debugfs file, my guess is that the clk_sdio gpio-gate-clock is not
being registered for some unknown reason.  Adding Michael - any
ideas why gpio-gate-clock has stopped working between 4.4 and
present?

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: SDIO wifi card is not detected with 4.5-rc kernels

[Michael Turquette]

Hi Russell, all,

On Wed, Feb 17, 2016 at 1:18 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Feb 17, 2016 at 04:41:04PM -0200, Fabio Estevam wrote:
>> On Wed, Feb 17, 2016 at 4:06 PM, Laszlo Fiat <laszlo.fiat@gmail.com> wrote:
>> > Hello,
>> >
>> > The SDIO wifi card is not detected in my Baytrail tablet with 4.5-RC kernels,
>> > which worked fine with pre-4.5 kernels.
>> >
>> > Kernel v4.0-4.4 versions worked nicely:
>> >
>> > $ grep mmc dmesg-4.4.0-rc2-next-20151127.txt
>> > [    2.421329] mmc0: SDHCI controller on ACPI [80860F14:00] using ADMA
>> > [    2.425847] mmc1: SDHCI controller on ACPI [INT33BB:00] using ADMA
>> > [    2.431164] mmc2: SDHCI controller on ACPI [80860F14:02] using ADMA
>> > [    2.561342] mmc0: MAN_BKOPS_EN bit is not set
>> > [    2.569496] mmc0: new HS200 MMC card at address 0001
>> > [    2.571164] mmcblk0: mmc0:0001 032GE4 29.1 GiB
>> > [    2.571453] mmcblk0boot0: mmc0:0001 032GE4 partition 1 4.00 MiB
>> > [    2.571655] mmcblk0boot1: mmc0:0001 032GE4 partition 2 4.00 MiB
>> > [    2.571863] mmcblk0rpmb: mmc0:0001 032GE4 partition 3 4.00 MiB
>> > [    2.573835]  mmcblk0: p1 p2 p3 p4 p5 p6
>> > [    2.647372] mmc1: new high speed SDIO card at address 0001
>> > [    2.812340] mmc2: new high speed SDXC card at address 0001
>> > [    2.812719] mmcblk1: mmc2:0001 00000 59.6 GiB
>> >
>> > With v4.5:
>> >
>> > $ grep mmc dmesg-4.5.0-rc4.txt
>> > [    2.678828] mmc0: SDHCI controller on ACPI [80860F14:00] using ADMA
>> > [    2.683332] mmc1: SDHCI controller on ACPI [INT33BB:00] using ADMA
>> > [    2.705315] mmc2: SDHCI controller on ACPI [80860F14:02] using ADMA
>> > [    2.850013] mmc2: new high speed SDXC card at address 0001
>> > [    2.858675] mmcblk0: mmc2:0001 00000 59.6 GiB
>> > [    2.871384] mmc0: MAN_BKOPS_EN bit is not set
>> > [    2.883166] mmc0: new HS200 MMC card at address 0001
>> > [    2.883725] mmcblk1: mmc0:0001 032GE4 29.1 GiB
>> > [    2.884029] mmcblk1boot0: mmc0:0001 032GE4 partition 1 4.00 MiB
>> > [    2.884322] mmcblk1boot1: mmc0:0001 032GE4 partition 2 4.00 MiB
>> > [    2.884518] mmcblk1rpmb: mmc0:0001 032GE4 partition 3 4.00 MiB
>> > [    2.886442]  mmcblk1: p1 p2 p3 p4 p5 p6
>> >
>> > Notice that the following line is missing with v4.5:
>> >
>> > mmc1: new high speed SDIO card at address 0001
>> >
>> > And of course the out-of-tree wifi driver (rtl8723bs) cannot find the
>> > hardware with kernel v4.5.
>> >
>> > The hardware is a Teclast X80h Baytrail tablet.
>> > Cpu:  Intel(R) Atom(TM) CPU  Z3735F
>> >
>> > I've opened a bug report for it:
>> > https://bugzilla.kernel.org/show_bug.cgi?id=112571
>> >
>> > The full dmesg of 4.5-rc4 is available in the bug report.
>>
>> I noticed the same on a imx6q-cubox-i board: the Broadcom Wifi chip
>> could not be detected with 4.5-rc.
>>
>> Haven't had a chance to debug this yet.
>
> Looks strange - my patch series was tested on Hummingboards and
> Armada38x, though that was before 4.4.  The Hummingboards have
> the same Broadcom wifi chip(s) as the Cubox-i, and they worked
> fine with my original set patches - here's 4.4-rc6 on a
> Hummingboard:
>
> [    0.000000] Linux version 4.4.0-rc6+ (rmk@rmk-PC.arm.linux.org.uk) (gcc version 4.7.4 (GCC) ) #1972 SMP Sat Jan 2 18:55:35 GMT 2016
> [    5.158107] brcmfmac: F1 signature read @0x18000000=0x16044330
> [    5.528484] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jan 23 2013 17:47:32 version 5.90.195.114 FWID 01-f9e7e464
> [    5.567722] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
> [    5.629961] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
>
> Since then, I rebased my patch series on 4.5-rc1 before re-posting
> it - though I didn't test it on the Wifi capable HBs, but now that I
> try, I find that there's more serious issues here: the SDHCI driver
> doesn't even probe the device, returning -ENODEV.  So, something _else_
> has broken in SDHCI/MMC for the Broadcom WIFI here - tracing through
> the code seems to point at the pwrseq stuff being the culpret:
>
> [   52.175162] match->alloc failed: -517
> [   52.178874] sdhci-esdhc-imx 2190000.usdhc: mmc_of_parse failed: -517
> [   52.185271] sdhci-esdhc-imx 2190000.usdhc: imx probe failed
>
> -517 is -EPROBE_DEFER, and looking at what's in the clk_summary
> debugfs file, my guess is that the clk_sdio gpio-gate-clock is not
> being registered for some unknown reason.  Adding Michael - any
> ideas why gpio-gate-clock has stopped working between 4.4 and
> present?

So you are missing a gpio-gate clk in v4.5-rc1 that is present in v4.4?

There isn't much to go on here, but mmc_of_parse can fail with
mmc_gpiod_request_cd and mmc_gpiod_request_ro, in addition to
mmc_pwrseq_alloc. I didn't follow the call chain to see if either of
those are capable of spitting out -EPROBE_DEFER.

clk patches affecting the gpio-gate from 4.4 to 4.5-rc1 are:

7ed88aa clk: fix clk-gpio.c with optional clock= DT property
0b2e788 clk: gpio: handle error codes for of_clk_get_parent_count()
c76eb11 clk: gpio: fix memory leak
f66541b clk: gpio: Get parent clk names in of_gpio_clk_setup()

Anyone that can reproduce, care to bisect?

For the interested, Stephen recently rewrote that driver to be a
platform_driver without relying on CLK_OF_DECLARE. Patch is here:
http://lkml.kernel.org/r/<1454533849-22206-1-git-send-email-sboyd@codeaurora.org>

Regards,
Mike

>
> --
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.



-- 
Michael Turquette
CEO
BayLibre - At the Heart of Embedded Linux
http://baylibre.com/

Re: SDIO wifi card is not detected with 4.5-rc kernels

[Russell King - ARM Linux]

On Wed, Feb 17, 2016 at 02:03:47PM -0800, Michael Turquette wrote:
> Hi Russell, all,
> 
> On Wed, Feb 17, 2016 at 1:18 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > [   52.175162] match->alloc failed: -517
> > [   52.178874] sdhci-esdhc-imx 2190000.usdhc: mmc_of_parse failed: -517
> > [   52.185271] sdhci-esdhc-imx 2190000.usdhc: imx probe failed
> >
> > -517 is -EPROBE_DEFER, and looking at what's in the clk_summary
> > debugfs file, my guess is that the clk_sdio gpio-gate-clock is not
> > being registered for some unknown reason.  Adding Michael - any
> > ideas why gpio-gate-clock has stopped working between 4.4 and
> > present?
> 
> So you are missing a gpio-gate clk in v4.5-rc1 that is present in v4.4?

It seems so.

arch/arm/boot/dts/imx6qdl-microsom.dtsi has:

        clk_sdio: sdio-clock {
                compatible = "gpio-gate-clock";
                #clock-cells = <0>;
                pinctrl-names = "default";
                pinctrl-0 = <&pinctrl_microsom_brcm_osc>;
                enable-gpios = <&gpio5 5 GPIO_ACTIVE_HIGH>;
        };

and if I boot the kernel with that:

# grep sdio /sys/kernel/debug/clk/clk_summary
#

If I look at a system with v4.4 booted:

# grep sdio /sys/kernel/debug/clk/clk_summary
 sdio-clock                               1            1           0          0    0

So, this appears to be a regression.

> There isn't much to go on here, but mmc_of_parse can fail with
> mmc_gpiod_request_cd and mmc_gpiod_request_ro, in addition to
> mmc_pwrseq_alloc. I didn't follow the call chain to see if either of
> those are capable of spitting out -EPROBE_DEFER.

Yes, there's other possible failures, but:

[   52.175162] match->alloc failed: -517

points to the mmc_pwrseq_alloc stuff - because that message is printed
from inside there.  The pwrseq stuff consists of:

        usdhc1_pwrseq: usdhc1_pwrseq {
                compatible = "mmc-pwrseq-simple";
                reset-gpios = <&gpio5 26 GPIO_ACTIVE_LOW>,
                              <&gpio6 0 GPIO_ACTIVE_LOW>;
                clocks = <&clk_sdio>;
                clock-names = "ext_clock";
        };

some GPIOs, and that clock - the GPIOs are definitely present, and the
sdio clock is clearly missing from clk_summary.

> clk patches affecting the gpio-gate from 4.4 to 4.5-rc1 are:
> 
> 7ed88aa clk: fix clk-gpio.c with optional clock= DT property
> 0b2e788 clk: gpio: handle error codes for of_clk_get_parent_count()
> c76eb11 clk: gpio: fix memory leak
> f66541b clk: gpio: Get parent clk names in of_gpio_clk_setup()
> 
> Anyone that can reproduce, care to bisect?

This isn't -next, this is 4.5-rc4 that I'm seeing the failure on.
4.5-rc4 still has clk-gpio.c with:

CLK_OF_DECLARE(gpio_gate_clk, "gpio-gate-clock", of_gpio_gate_clk_setup);

Annoyingly, it's silent in the boot log about what's going on wrt
this clock.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: SDIO wifi card is not detected with 4.5-rc kernels

[Michael Turquette]

+ linux-clk

On Wed, Feb 17, 2016 at 2:11 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Feb 17, 2016 at 02:03:47PM -0800, Michael Turquette wrote:
>> Hi Russell, all,
>>
>> On Wed, Feb 17, 2016 at 1:18 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > [   52.175162] match->alloc failed: -517
>> > [   52.178874] sdhci-esdhc-imx 2190000.usdhc: mmc_of_parse failed: -517
>> > [   52.185271] sdhci-esdhc-imx 2190000.usdhc: imx probe failed
>> >
>> > -517 is -EPROBE_DEFER, and looking at what's in the clk_summary
>> > debugfs file, my guess is that the clk_sdio gpio-gate-clock is not
>> > being registered for some unknown reason.  Adding Michael - any
>> > ideas why gpio-gate-clock has stopped working between 4.4 and
>> > present?
>>
>> So you are missing a gpio-gate clk in v4.5-rc1 that is present in v4.4?
>
> It seems so.
>
> arch/arm/boot/dts/imx6qdl-microsom.dtsi has:
>
>         clk_sdio: sdio-clock {
>                 compatible = "gpio-gate-clock";
>                 #clock-cells = <0>;
>                 pinctrl-names = "default";
>                 pinctrl-0 = <&pinctrl_microsom_brcm_osc>;
>                 enable-gpios = <&gpio5 5 GPIO_ACTIVE_HIGH>;
>         };
>
> and if I boot the kernel with that:
>
> # grep sdio /sys/kernel/debug/clk/clk_summary
> #
>
> If I look at a system with v4.4 booted:
>
> # grep sdio /sys/kernel/debug/clk/clk_summary
>  sdio-clock                               1            1           0          0    0
>
> So, this appears to be a regression.
>
>> There isn't much to go on here, but mmc_of_parse can fail with
>> mmc_gpiod_request_cd and mmc_gpiod_request_ro, in addition to
>> mmc_pwrseq_alloc. I didn't follow the call chain to see if either of
>> those are capable of spitting out -EPROBE_DEFER.
>
> Yes, there's other possible failures, but:
>
> [   52.175162] match->alloc failed: -517
>
> points to the mmc_pwrseq_alloc stuff - because that message is printed
> from inside there.  The pwrseq stuff consists of:
>
>         usdhc1_pwrseq: usdhc1_pwrseq {
>                 compatible = "mmc-pwrseq-simple";
>                 reset-gpios = <&gpio5 26 GPIO_ACTIVE_LOW>,
>                               <&gpio6 0 GPIO_ACTIVE_LOW>;
>                 clocks = <&clk_sdio>;
>                 clock-names = "ext_clock";
>         };
>
> some GPIOs, and that clock - the GPIOs are definitely present, and the
> sdio clock is clearly missing from clk_summary.
>
>> clk patches affecting the gpio-gate from 4.4 to 4.5-rc1 are:
>>
>> 7ed88aa clk: fix clk-gpio.c with optional clock= DT property
>> 0b2e788 clk: gpio: handle error codes for of_clk_get_parent_count()
>> c76eb11 clk: gpio: fix memory leak
>> f66541b clk: gpio: Get parent clk names in of_gpio_clk_setup()
>>
>> Anyone that can reproduce, care to bisect?
>
> This isn't -next, this is 4.5-rc4 that I'm seeing the failure on.
> 4.5-rc4 still has clk-gpio.c with:
>
> CLK_OF_DECLARE(gpio_gate_clk, "gpio-gate-clock", of_gpio_gate_clk_setup);

Right, the patches I posted above are v4.4..v4.5-rc1 based on your
original email stating you saw the regression when rebasing onto -rc1.
The platform_driver patch was just a random piece of info and it is
not yet landed in linux-next anyways.

Probably the best approach is for someone that can reproduce the
failure to either bisect or try to selectively revert the patches I
list above. There are multiple potential culprits in that list of
patches, as several of them touch the setup/registration functions in
clk-gpio.c.

Regards,
Mike

>
> Annoyingly, it's silent in the boot log about what's going on wrt
> this clock.

Re: SDIO wifi card is not detected with 4.5-rc kernels

[Russell King - ARM Linux]

On Wed, Feb 17, 2016 at 10:11:36PM +0000, Russell King - ARM Linux wrote:
> On Wed, Feb 17, 2016 at 02:03:47PM -0800, Michael Turquette wrote:
> > Hi Russell, all,
> > 
> > On Wed, Feb 17, 2016 at 1:18 PM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> > > [   52.175162] match->alloc failed: -517
> > > [   52.178874] sdhci-esdhc-imx 2190000.usdhc: mmc_of_parse failed: -517
> > > [   52.185271] sdhci-esdhc-imx 2190000.usdhc: imx probe failed
> > >
> > > -517 is -EPROBE_DEFER, and looking at what's in the clk_summary
> > > debugfs file, my guess is that the clk_sdio gpio-gate-clock is not
> > > being registered for some unknown reason.  Adding Michael - any
> > > ideas why gpio-gate-clock has stopped working between 4.4 and
> > > present?
> > 
> > So you are missing a gpio-gate clk in v4.5-rc1 that is present in v4.4?
> 
> It seems so.
> 
> arch/arm/boot/dts/imx6qdl-microsom.dtsi has:
> 
>         clk_sdio: sdio-clock {
>                 compatible = "gpio-gate-clock";
>                 #clock-cells = <0>;
>                 pinctrl-names = "default";
>                 pinctrl-0 = <&pinctrl_microsom_brcm_osc>;
>                 enable-gpios = <&gpio5 5 GPIO_ACTIVE_HIGH>;
>         };
> 
> and if I boot the kernel with that:
> 
> # grep sdio /sys/kernel/debug/clk/clk_summary
> #
> 
> If I look at a system with v4.4 booted:
> 
> # grep sdio /sys/kernel/debug/clk/clk_summary
>  sdio-clock                               1            1           0          0    0
> 
> So, this appears to be a regression.
> 
> > There isn't much to go on here, but mmc_of_parse can fail with
> > mmc_gpiod_request_cd and mmc_gpiod_request_ro, in addition to
> > mmc_pwrseq_alloc. I didn't follow the call chain to see if either of
> > those are capable of spitting out -EPROBE_DEFER.
> 
> Yes, there's other possible failures, but:
> 
> [   52.175162] match->alloc failed: -517
> 
> points to the mmc_pwrseq_alloc stuff - because that message is printed
> from inside there.  The pwrseq stuff consists of:
> 
>         usdhc1_pwrseq: usdhc1_pwrseq {
>                 compatible = "mmc-pwrseq-simple";
>                 reset-gpios = <&gpio5 26 GPIO_ACTIVE_LOW>,
>                               <&gpio6 0 GPIO_ACTIVE_LOW>;
>                 clocks = <&clk_sdio>;
>                 clock-names = "ext_clock";
>         };
> 
> some GPIOs, and that clock - the GPIOs are definitely present, and the
> sdio clock is clearly missing from clk_summary.
> 
> > clk patches affecting the gpio-gate from 4.4 to 4.5-rc1 are:
> > 
> > 7ed88aa clk: fix clk-gpio.c with optional clock= DT property
> > 0b2e788 clk: gpio: handle error codes for of_clk_get_parent_count()
> > c76eb11 clk: gpio: fix memory leak
> > f66541b clk: gpio: Get parent clk names in of_gpio_clk_setup()
> > 
> > Anyone that can reproduce, care to bisect?
> 
> This isn't -next, this is 4.5-rc4 that I'm seeing the failure on.
> 4.5-rc4 still has clk-gpio.c with:
> 
> CLK_OF_DECLARE(gpio_gate_clk, "gpio-gate-clock", of_gpio_gate_clk_setup);
> 
> Annoyingly, it's silent in the boot log about what's going on wrt
> this clock.

Scattering some more printk()s etc:

[    0.000000] of_gpio_gate_clk_setup: /sdio-clock
[    0.000000] of_clk_get_parent_count returned -2

which kills the registration of the clock, and this comes down to this
patch:

commit 0b2e78865d92e2d70542cb1d4d7af1d4ea0a286d
Author: Brian Norris <computersforpeace@gmail.com>
Date:   Wed Dec 16 10:35:03 2015 -0800

    clk: gpio: handle error codes for of_clk_get_parent_count()

    We might make bad memory allocations if we get (e.g.) -ENOSYS from
    of_clk_get_parent_count().

    Noticed by Coverity.

    Fixes: f66541ba02d5 ("clk: gpio: Get parent clk names in of_gpio_clk_setup()")
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Cc: Jyri Sarha <jsarha@ti.com>
    Cc: Sergej Sawazki <ce3a@gmx.de>
    Cc: Stephen Boyd <sboyd@codeaurora.org>
    Signed-off-by: Michael Turquette <mturquette@baylibre.com>

>From what I remember - I debugged a problem in this area, I sent a
_tested_ patch, which you changed before merging because you had
the above conflicting patch.  Unfortunately, the conflicting patch
is the cause of this problem...

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: SDIO wifi card is not detected with 4.5-rc kernels

[Russell King - ARM Linux]

On Wed, Feb 17, 2016 at 11:02:26PM +0000, Russell King - ARM Linux wrote:
> From what I remember - I debugged a problem in this area, I sent a
> _tested_ patch, which you changed before merging because you had
> the above conflicting patch.  Unfortunately, the conflicting patch
> is the cause of this problem...

... and, no surprises, if I undo the changes in that original patch
and implement exactly what I sent you on January 2nd, then everything
starts working again.

And we finally have a sort-of answer on the SDHCI problem: it works
here with my _original_ set of patches I sent to the MMC list, so I
don't think this is a problem with my original set of SDHCI patches.
It could be a problem introduced by Adrian modifying my patches
before applying (which, if so, sounds just like what's happened with
clk-gpio.c all over again.)

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: SDIO wifi card is not detected with 4.5-rc kernels

[Laszlo Fiat]

Hello,

The original issue I reported on 17 Feb is that the SDIO WIFI card is
not detected with 4.5RC and now mainline 4.5.0 kernel on baytrail
tablets.
BzukTuk commented on the bug report, that he has bisected the problem,
and found that reverting  patch
520bd7a8b4152aacfbd34eb7f7a447354b631039 ("mmc: core:
Optimize boot time by detecting cards simultaneously")  solves the problem.
I tested this, by compiling a 4.5.0 kernel with that patch reverted,
and the SDIO WiFi works that way.

Bye,
Laszlo Fiat

On Wed, Feb 17, 2016 at 7:06 PM, Laszlo Fiat <laszlo.fiat@gmail.com> wrote:
> Hello,
>
> The SDIO wifi card is not detected in my Baytrail tablet with 4.5-RC kernels,
> which worked fine with pre-4.5 kernels.
>
> Kernel v4.0-4.4 versions worked nicely:
>
> $ grep mmc dmesg-4.4.0-rc2-next-20151127.txt
> [    2.421329] mmc0: SDHCI controller on ACPI [80860F14:00] using ADMA
> [    2.425847] mmc1: SDHCI controller on ACPI [INT33BB:00] using ADMA
> [    2.431164] mmc2: SDHCI controller on ACPI [80860F14:02] using ADMA
> [    2.561342] mmc0: MAN_BKOPS_EN bit is not set
> [    2.569496] mmc0: new HS200 MMC card at address 0001
> [    2.571164] mmcblk0: mmc0:0001 032GE4 29.1 GiB
> [    2.571453] mmcblk0boot0: mmc0:0001 032GE4 partition 1 4.00 MiB
> [    2.571655] mmcblk0boot1: mmc0:0001 032GE4 partition 2 4.00 MiB
> [    2.571863] mmcblk0rpmb: mmc0:0001 032GE4 partition 3 4.00 MiB
> [    2.573835]  mmcblk0: p1 p2 p3 p4 p5 p6
> [    2.647372] mmc1: new high speed SDIO card at address 0001
> [    2.812340] mmc2: new high speed SDXC card at address 0001
> [    2.812719] mmcblk1: mmc2:0001 00000 59.6 GiB
>
> With v4.5:
>
> $ grep mmc dmesg-4.5.0-rc4.txt
> [    2.678828] mmc0: SDHCI controller on ACPI [80860F14:00] using ADMA
> [    2.683332] mmc1: SDHCI controller on ACPI [INT33BB:00] using ADMA
> [    2.705315] mmc2: SDHCI controller on ACPI [80860F14:02] using ADMA
> [    2.850013] mmc2: new high speed SDXC card at address 0001
> [    2.858675] mmcblk0: mmc2:0001 00000 59.6 GiB
> [    2.871384] mmc0: MAN_BKOPS_EN bit is not set
> [    2.883166] mmc0: new HS200 MMC card at address 0001
> [    2.883725] mmcblk1: mmc0:0001 032GE4 29.1 GiB
> [    2.884029] mmcblk1boot0: mmc0:0001 032GE4 partition 1 4.00 MiB
> [    2.884322] mmcblk1boot1: mmc0:0001 032GE4 partition 2 4.00 MiB
> [    2.884518] mmcblk1rpmb: mmc0:0001 032GE4 partition 3 4.00 MiB
> [    2.886442]  mmcblk1: p1 p2 p3 p4 p5 p6
>
> Notice that the following line is missing with v4.5:
>
> mmc1: new high speed SDIO card at address 0001
>
> And of course the out-of-tree wifi driver (rtl8723bs) cannot find the
> hardware with kernel v4.5.
>
> The hardware is a Teclast X80h Baytrail tablet.
> Cpu:  Intel(R) Atom(TM) CPU  Z3735F
>
> I've opened a bug report for it:
> https://bugzilla.kernel.org/show_bug.cgi?id=112571
>
> The full dmesg of 4.5-rc4 is available in the bug report.
>
> Bye,
> Laszlo Fiat

Re: SDIO wifi card is not detected with 4.5-rc kernels

[Fabio Estevam]

On Thu, Mar 24, 2016 at 2:45 PM, Laszlo Fiat <laszlo.fiat@gmail.com> wrote:
> Hello,
>
> The original issue I reported on 17 Feb is that the SDIO WIFI card is
> not detected with 4.5RC and now mainline 4.5.0 kernel on baytrail
> tablets.
> BzukTuk commented on the bug report, that he has bisected the problem,
> and found that reverting  patch
> 520bd7a8b4152aacfbd34eb7f7a447354b631039 ("mmc: core:
> Optimize boot time by detecting cards simultaneously")  solves the problem.
> I tested this, by compiling a 4.5.0 kernel with that patch reverted,
> and the SDIO WiFi works that way.

Adding Ulf on Cc.

Re: SDIO wifi card is not detected with 4.5-rc kernels

[Ulf Hansson]

+Russell, Mike

On 24 March 2016 at 18:50, Fabio Estevam <festevam@gmail.com> wrote:
> On Thu, Mar 24, 2016 at 2:45 PM, Laszlo Fiat <laszlo.fiat@gmail.com> wrote:
>> Hello,
>>
>> The original issue I reported on 17 Feb is that the SDIO WIFI card is
>> not detected with 4.5RC and now mainline 4.5.0 kernel on baytrail
>> tablets.
>> BzukTuk commented on the bug report, that he has bisected the problem,
>> and found that reverting  patch
>> 520bd7a8b4152aacfbd34eb7f7a447354b631039 ("mmc: core:
>> Optimize boot time by detecting cards simultaneously")  solves the problem.
>> I tested this, by compiling a 4.5.0 kernel with that patch reverted,
>> and the SDIO WiFi works that way.
>
> Adding Ulf on Cc.

>From earlier discussions [1], it seems like Russell pointed out a mmc
pwrseq related bug, but there seems to be yet another issue here.

The bisected bad commit 520bd7a8b415 ("mmc: core: Optimize boot time
by detecting cards simultaneously"), affects the timing and then maybe
also the order of how cards (mmc, sd, sdio) may be detected.

More precisely SD/(e)MMC cards may get different block ids (mmcblk[n])
than they had before. According the information from the logs in
bugzilla [2], a qualified guess is that the firmware to the SDIO WLAN
chip is loaded from an hardcoded path. Since that path gets changed,
the firmware can't be found and loaded, right?

So, just to be clear, there has *never* been any deterministic way to
always get the same mmc block id for a card. If hardcoded paths have
worked, it's because of luck! Let me elaborate a bit on that.

Earlier and with commit 520bd7a8b415, the probe order (a successful
probe) of the mmc host device and whether removable cards are present
or not, affects the mmc block id. The change that commit 520bd7a8b415
introduces is that card detection can now happen simultaneously, thus
it adds another parameter that affects the mmc block id.

Unless I am mistaken, the hard coded paths should be fixed to use
UUID/PARTUUID in favour of reverting 520bd7a8b415.

Kind regards
Uffe

[1]
http://comments.gmane.org/gmane.linux.kernel.mmc/36045

[2]
https://bugzilla.kernel.org/show_bug.cgi?id=112571

Re: SDIO wifi card is not detected with 4.5-rc kernels

[Laszlo Fiat]

Dear Uffe,

The problem seems to be appearing only with the rtl8723bs
 SDIO WIFI chip: [2] That one has an out-of-tree driver at [1].
As far as I can see in the kernel log, the kernel module loads the firmware to
the WIFI chip, after the module is loaded, and that happens
much later than the SD detection. SD Detection is at around 3 sec,
RTL8723BS init around 6 sec into boot (this is from a working kernel):

<...>
[    3.045290] mmc0: new HS200 MMC card at address 0001
<...>
[    3.123503] mmc1: new high speed SDIO card at address 0001
[    3.307623] mmc2: new high speed SDXC card at address 0001
<...>
[    6.120581] RTL8723BS: module init start
[    6.120590] RTL8723BS: rtl8723bs v4.3.5.5_12290.20140916_BTCOEX20140507-4E40
[    6.120593] RTL8723BS: rtl8723bs BT-Coex version = BTCOEX20140507-4E40
<...>
[    6.278909] RTL8723BS: rtw_ndev_init(wlan0)
[    6.279546] RTL8723BS: module init ret =0
<...>
[    7.035019] rtl8723bs: accquire FW from file:rtlwifi/rtl8723bs_nic.bin
<...>
[   10.748801] RTL8723BS: rtw_set_802_11_connect(wlan0)  fw_state = 0x00000008
<...>

Does it help if I create a log with MMC_DEBUG, so that we can see what
goes wrong?
Can it be a timing issue, that this chip responds too slow?

Thank you for your work.

Best regards,

Laszlo Fiat

[1]
https://github.com/hadess/rtl8723bs
[2]
https://bugzilla.kernel.org/show_bug.cgi?id=112571#c7

On Tue, Mar 29, 2016 at 12:31 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> +Russell, Mike
>
> On 24 March 2016 at 18:50, Fabio Estevam <festevam@gmail.com> wrote:
>> On Thu, Mar 24, 2016 at 2:45 PM, Laszlo Fiat <laszlo.fiat@gmail.com> wrote:
>>> Hello,
>>>
>>> The original issue I reported on 17 Feb is that the SDIO WIFI card is
>>> not detected with 4.5RC and now mainline 4.5.0 kernel on baytrail
>>> tablets.
>>> BzukTuk commented on the bug report, that he has bisected the problem,
>>> and found that reverting  patch
>>> 520bd7a8b4152aacfbd34eb7f7a447354b631039 ("mmc: core:
>>> Optimize boot time by detecting cards simultaneously")  solves the problem.
>>> I tested this, by compiling a 4.5.0 kernel with that patch reverted,
>>> and the SDIO WiFi works that way.
>>
>> Adding Ulf on Cc.
>
> From earlier discussions [1], it seems like Russell pointed out a mmc
> pwrseq related bug, but there seems to be yet another issue here.
>
> The bisected bad commit 520bd7a8b415 ("mmc: core: Optimize boot time
> by detecting cards simultaneously"), affects the timing and then maybe
> also the order of how cards (mmc, sd, sdio) may be detected.
>
> More precisely SD/(e)MMC cards may get different block ids (mmcblk[n])
> than they had before. According the information from the logs in
> bugzilla [2], a qualified guess is that the firmware to the SDIO WLAN
> chip is loaded from an hardcoded path. Since that path gets changed,
> the firmware can't be found and loaded, right?
>
> So, just to be clear, there has *never* been any deterministic way to
> always get the same mmc block id for a card. If hardcoded paths have
> worked, it's because of luck! Let me elaborate a bit on that.
>
> Earlier and with commit 520bd7a8b415, the probe order (a successful
> probe) of the mmc host device and whether removable cards are present
> or not, affects the mmc block id. The change that commit 520bd7a8b415
> introduces is that card detection can now happen simultaneously, thus
> it adds another parameter that affects the mmc block id.
>
> Unless I am mistaken, the hard coded paths should be fixed to use
> UUID/PARTUUID in favour of reverting 520bd7a8b415.
>
> Kind regards
> Uffe
>
> [1]
> http://comments.gmane.org/gmane.linux.kernel.mmc/36045
>
> [2]
> https://bugzilla.kernel.org/show_bug.cgi?id=112571