kernel/drivers/regulator/cpcap-regulator.c, branch linux-rolling-stable

regulator: Explicitly include correct DT includes

2023-07-14T19:52:54Z

The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20230714174930.4063320-1-robh@kernel.org Signed-off-by: Mark Brown

regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14

2023-03-20T13:11:25Z

Probing of regulators can be a slow operation and can contribute to slower boot times. This is especially true if a regulator is turned on at probe time (with regulator-boot-on or regulator-always-on) and the regulator requires delays (off-on-time, ramp time, etc). While the overall kernel is not ready to switch to async probe by default, as per the discussion on the mailing lists [1] it is believed that the regulator subsystem is in good shape and we can move regulator drivers over wholesale. There is no way to just magically opt in all regulators (regulators are just normal drivers like platform_driver), so we set PROBE_PREFER_ASYNCHRONOUS for all regulators found in 'drivers/regulator' individually. Given the number of drivers touched and the impossibility to test this ahead of time, it wouldn't be shocking at all if this caused a regression for someone. If there is a regression caused by this patch, it's likely to be one of the cases talked about in [1]. As a "quick fix", drivers involved in the regression could be fixed by changing them to PROBE_FORCE_SYNCHRONOUS. That being said, the correct fix would be to directly fix the problem that caused the issue with async probe. The approach here follows a similar approach that was used for the mmc subsystem several years ago [2]. In fact, I ran nearly the same python script to auto-generate the changes. The only thing I changed was to search for "i2c_driver", "spmi_driver", and "spi_driver" in addition to "platform_driver". [1] https://lore.kernel.org/r/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk [2] https://lore.kernel.org/r/20200903232441.2694866-1-dianders@chromium.org/ Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20230316125351.1.I2a4677392a38db5758dee0788b2cea5872562a82@changeid Signed-off-by: Mark Brown

treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_30.RULE (part 2)

2022-06-10T12:51:35Z

Based on the normalized pattern: this program is free software you can redistribute it and/or modify it under the terms of the gnu general public license as published by the free software foundation version 2 this program is distributed as is without any warranty of any kind whether express or implied without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference. Reviewed-by: Allison Randal Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

regulator: cpcap-regulator: Demote kerneldoc header to standard comment

2020-06-25T19:11:16Z

Nothing about this comment identifies it as a kerneldoc header. They're missing all of their struct's property descriptions and the correct 'struct *' header. Fixes the following W=1 warning(s): drivers/regulator/cpcap-regulator.c:99: warning: cannot understand function prototype: 'struct cpcap_regulator ' drivers/regulator/cpcap-regulator.c:337: warning: cannot understand function prototype: 'const struct cpcap_regulator omap4_regulators[] = ' Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20200625163614.4001403-9-lee.jones@linaro.org Signed-off-by: Mark Brown

regulator: cpcap-regulator: Remove declared and set, but never used variable 'ignore'

2020-06-25T19:11:15Z

It's okay to not check the return value that you're not conserned about, however it is not okay to assign a variable and not check or use the result. Fixes W=1 warnings(s): drivers/regulator/cpcap-regulator.c:172:13: warning: variable ‘ignore’ set but not used [-Wunused-but-set-variable] 172 | int error, ignore; | ^~~~~~ drivers/regulator/cpcap-regulator.c: In function ‘cpcap_regulator_disable’: drivers/regulator/cpcap-regulator.c:196:13: warning: variable ‘ignore’ set but not used [-Wunused-but-set-variable] 196 | int error, ignore; | ^~~~~~ Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20200625163614.4001403-8-lee.jones@linaro.org Signed-off-by: Mark Brown

regulator: cpcap: Constify cpcap_regulator_ops

2020-06-18T12:47:32Z

cpcap_regulator_ops is not modified and can be made const to allow the compiler to put it in read-only memory. Before: text data bss dec hex filename 14472 236 0 14708 3974 drivers/regulator/cpcap-regulator.o After: text data bss dec hex filename 14604 104 0 14708 3974 drivers/regulator/cpcap-regulator.o Signed-off-by: Rikard Falkeborn Link: https://lore.kernel.org/r/20200617223247.25566-3-rikard.falkeborn@gmail.com Signed-off-by: Mark Brown

regulator: cpcap: Spelling s/configuraion/configuration/

2019-06-07T12:14:37Z

Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown

regulator: cpcap: Convert to use of_device_get_match_data

2019-03-18T12:10:31Z

Use of_device_get_match_data to simplify the code a bit. Signed-off-by: Axel Lin Signed-off-by: Mark Brown

regulator: cpcap: Remove unneeded init_data setting

2019-03-18T12:10:16Z

This driver is using regulator core's simplified DT parsing code, so regulator will call regulator_of_get_init_data() to get init_data. No need to set config.init_data. In additional, current code does not properly set the init_data setting, so just remove it. Signed-off-by: Axel Lin Signed-off-by: Mark Brown

regulator: cpcap: Constify omap4_regulators and xoom_regulators

2019-02-26T16:32:06Z

They should never change, make them const. Signed-off-by: Axel Lin Acked-by: Tony Lindgren Reviewed-by: Sebastian Reichel Signed-off-by: Mark Brown