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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxx>
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@xxxxxxxxx>
Cc: Jyri Sarha <jsarha@xxxxxx>
Cc: Sergej Sawazki <ce3a@xxxxxx>
Cc: Stephen Boyd <sboyd@xxxxxxxxxxxxxx>
Signed-off-by: Michael Turquette <mturquette@xxxxxxxxxxxx>
>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.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
