user/sven/linux.git/include/linux/regulator, branch v4.19.102

regulator: ab8500: Remove SYSCLKREQ from enum ab8505_regulator_id

2020-01-23T07:21:39Z

commit 458ea3ad033fc86e291712ce50cbe60c3428cf30 upstream. Those regulators are not actually supported by the AB8500 regulator driver. There is no ab8500_regulator_info for them and no entry in ab8505_regulator_match. As such, they cannot be registered successfully, and looking them up in ab8505_regulator_match causes an out-of-bounds array read. Fixes: 547f384f33db ("regulator: ab8500: add support for ab8505") Cc: Linus Walleij Signed-off-by: Stephan Gerhold Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20191106173125.14496-2-stephan@gerhold.net Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

regulator: ab8500: Remove AB8505 USB regulator

2020-01-09T09:19:05Z

commit 99c4f70df3a6446c56ca817c2d0f9c12d85d4e7c upstream. The USB regulator was removed for AB8500 in commit 41a06aa738ad ("regulator: ab8500: Remove USB regulator"). It was then added for AB8505 in commit 547f384f33db ("regulator: ab8500: add support for ab8505"). However, there was never an entry added for it in ab8505_regulator_match. This causes all regulators after it to be initialized with the wrong device tree data, eventually leading to an out-of-bounds array read. Given that it is not used anywhere in the kernel, it seems likely that similar arguments against supporting it exist for AB8505 (it is controlled by hardware). Therefore, simply remove it like for AB8500 instead of adding an entry in ab8505_regulator_match. Fixes: 547f384f33db ("regulator: ab8500: add support for ab8505") Cc: Linus Walleij Signed-off-by: Stephan Gerhold Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20191106173125.14496-1-stephan@gerhold.net Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

regulator: Fix return value of _set_load() stub

2019-12-13T07:51:28Z

[ Upstream commit f1abf67217de91f5cd3c757ae857632ca565099a ] The stub implementation of _set_load() returns a mode value which is within the bounds of valid return codes for success (the documentation just says that failures are negative error codes) but not sensible or what the actual implementation does. Fix it to just return 0. Reported-by: Cheng-Yi Chiang Signed-off-by: Mark Brown Reviewed-by: Douglas Anderson Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: Fix 'do-nothing' value for regulators without suspend state

2018-09-03T15:10:40Z

Some regulators don't have all states defined and in such cases regulator core should not assume anything. However in current implementation of of_get_regulation_constraints() DO_NOTHING_IN_SUSPEND enable value was set only for regulators which had suspend node defined, otherwise the default 0 value was used, what means DISABLE_IN_SUSPEND. This lead to broken system suspend/resume on boards, which had simple regulator constraints definition (without suspend state nodes). To avoid further mismatches between the default and uninitialized values of the suspend enabled/disabled states, change the values of the them, so default '0' means DO_NOTHING_IN_SUSPEND. Fixes: 72069f9957a1: regulator: leave one item to record whether regulator is enabled Signed-off-by: Marek Szyprowski Signed-off-by: Mark Brown Cc: stable@vger.kernel.org

regulator: core: Change suspend_late to suspend

2018-07-05T17:07:45Z

Change suspend_late ops to suspend normal ops. The goal is to avoid requesting all the regulator drivers to be operational in suspend late phase. Signed-off-by: pascal paillet Signed-off-by: Mark Brown

regulator: Fix typo in comment of struct regulator_linear_range

2018-06-18T11:22:39Z

regulator_map_linar_range() => regulator_map_linear_range() Signed-off-by: Matthias Kaehlcke Signed-off-by: Mark Brown

regulator: pfuze100: add pfuze3001 support

2018-06-18T11:22:39Z

This extends the pfuze100 driver with pfuze3001 support. Latest datasheet: https://www.nxp.com/docs/en/data-sheet/PF3001.pdf Signed-off-by: Robin Gong Signed-off-by: Stefan Wahren Signed-off-by: Mark Brown

regulator: gpio: Revert

2018-06-07T13:23:08Z

regulator: fixed/gpio: Revert GPIO descriptor changes due to platform breakage Commit 6059577cb28 "regulator: fixed: Convert to use GPIO descriptor only" broke at least the ams-delta platform since the lookup tables added to the board files use the function name "enable" while the driver uses NULL causing the regulator to not acquire and control the enable GPIOs. Revert that and a couple of other commits that are caught up with it to fix the issue: 2b6c00c157c5bf80 "ARM: pxa, regulator: fix building ezx e680" 6059577cb28d8b15 "regulator: fixed: Convert to use GPIO descriptor only" 37bed97f00734ce3 "regulator: gpio: Get enable GPIO using GPIO descriptor" Reported-by: Janusz Krzysztofik Signed-off-by: Mark Brown

regulator: gpio: Get enable GPIO using GPIO descriptor

2018-05-29T14:55:12Z

We augment the GPIO regulator to get the *enable* regulator GPIO line (not the other lines) using a descriptor rather than a global number. We then pass this into the regulator core which has been prepared to hande enable descriptors in a separate patch. Switch over the two boardfiles using this facility and clean up so we only pass descriptors around. Cc: Philipp Zabel # HX4700/Magician maintainer Signed-off-by: Linus Walleij Signed-off-by: Mark Brown

regulator: fixed: Convert to use GPIO descriptor only

2018-05-29T14:53:17Z

As we augmented the regulator core to accept a GPIO descriptor instead of a GPIO number, we can augment the fixed GPIO regulator to look up and pass that descriptor directly from device tree or board GPIO descriptor look up tables. Some boards just auto-enumerate their fixed regulator platform devices and I have assumed they get names like "fixed-regulator.0" but it's pretty hard to guess this. I need some testing from board maintainers to be sure. Other boards are straight forward, using just plain "fixed-regulator" (ID -1) or "fixed-regulator.1" hammering down the device ID. The OMAP didn't have proper label names on its GPIO chips so I have fixed this with a separate patch to the GPIO tree, see commit 088413bc0bd5f5fb66ca22a19d66a49d7154ba4c "gpio: omap: Give unique labels to each GPIO bank/chip" It seems the da9055 and da9211 has never got around to actually passing any enable gpio into its platform data (not the in-tree code anyway) so we can just decide to simply pass a descriptor instead. The fixed GPIO-controlled regulator in mach-pxa/ezx.c was confusingly named "*_dummy_supply_device" while it is a very real device backed by a GPIO line. There is nothing dummy about it at all, so I renamed it with the infix *_regulator_* as part of this patch set. For the patch hunk hitting arch/blackfin I would say I do not expect testing, review or ACKs anymore so if it works, it works. The hunk hitting the x86 BCM43xx driver is especially tricky as the number comes out of SFI which is a mystery to me. I definately need someone to look at this. (Hi Andy.) Cc: Andy Shevchenko # Check the x86 BCM stuff Cc: Alexander Shiyan # i.MX boards user Cc: Haojian Zhuang # MMP2 maintainer Cc: Aaro Koskinen # OMAP1 maintainer Cc: Tony Lindgren # OMAP1,2,3 maintainer Cc: Mike Rapoport # EM-X270 maintainer Cc: Robert Jarzmik # EZX maintainer Cc: Philipp Zabel # Magician maintainer Cc: Daniel Mack # Raumfeld maintainer Cc: Marc Zyngier # Zeus maintainer Cc: Geert Uytterhoeven # SuperH pinctrl/GPIO maintainer Cc: Russell King # SA1100 Signed-off-by: Linus Walleij Acked-by: Andy Shevchenko Acked-by: Tony Lindgren Signed-off-by: Mark Brown