lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180618171410.z3bshzmwu7x5yylj@camel2.lan>
Date:   Mon, 18 Jun 2018 19:14:10 +0200
From:   Matthias Reichl <hias@...us.com>
To:     Linus Walleij <linus.walleij@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>
Cc:     patches@...nsource.cirrus.com,
        Richard Fitzgerald <rf@...nsource.cirrus.com>,
        Charles Keepax <ckeepax@...nsource.cirrus.com>,
        linux-kernel@...r.kernel.org
Subject: Regression in 4.18-rc1 caused by regulator: arizona-ldo1: Look up a
 descriptor and pass to the core

Commit e1739e86f0cb9c48e8745a610e6981a4e24cadad breaks reading
the wlf,ldoena property from device tree. This causes ldo1 to
stay off and thus arizona device detection to fail:

[    4.495958] of_get_named_gpiod_flags: parsed 'wlf,reset' property of node '/s
oc/spi@...04000/wm5102@1[0]' - status (0)
[    4.509756] arizona-ldo1 arizona-ldo1: GPIO lookup for consumer wlf,ldoena
[    4.511339] arizona-ldo1 arizona-ldo1: using lookup tables for GPIO lookup
[    4.511351] arizona-ldo1 arizona-ldo1: No GPIO consumer wlf,ldoena found
[    4.511413] LDO1: supplied by RPi-Cirrus 1v8
[    4.549164] arizona spi0.1: Unknown device ID: 0

With this commit reverted the ldoena GPIO is properly found and
asserted high and the arizona device type is read successfully:

[    4.630445] of_get_named_gpiod_flags: parsed 'wlf,reset' property of node '/s
oc/spi@...04000/wm5102@1[0]' - status (0)
[    4.647622] of_get_named_gpiod_flags: parsed 'wlf,ldoena' property of node '/soc/spi@...04000/wm5102@1[0]' - status (0)
[    4.666100] arizona spi0.1: WM5102 revision C

I've tested this on a Raspberry Pi 3 with upstream 4.18-rc1,
the Cirrus Logic Audio Card from Element 14 (using a WM5102
connected via SPI) and the downstream card driver added as
a module.

Both wlf,reset and wlf,ldoena properties are defined in
the wm5102 devicetree node:

wm5102@1{
	compatible = "wlf,wm5102";
	reg = <1>;
	...
	wlf,reset = <&gpio 17 0>;
	wlf,ldoena = <&gpio 22 0>;
	...
};

If I understand the code correctly the cuplrit seems to be that
with this patch the gpio is looked up from the arizona-ldo1 dev,
which has a NULL of_node:

config.ena_gpiod = devm_gpiod_get_optional(&pdev->dev, "wlf,ldoena", ...

The old version did an of lookup in the parent (arizona) dev, which
contains the of_node with wlf,ldoena:

arizona_ldo1_common_init:
	struct device *parent_dev = pdev->dev.parent;
	struct regulator_config config = { };
	...
	config.dev = parent_dev;
	...
	arizona_ldo1_of_get_pdata(pdata, config, ...

arizona_ldo1_of_get_pdata:
	struct device_node *np = config->dev->of_node;
	...
	pdata->ldoena = of_get_named_gpio(np, "wlf,ldoena", 0);

so long,

Hias

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ