kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-15 19:56:03 +00:00
Code Issues Releases Packages Activity
linux/drivers/regulator/dummy.c

72 lines
1.6 KiB
Raw Normal View History

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152 Based on 1 normalized pattern(s): 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 either version 2 of the license or at your option any later version extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 3029 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-27 08:55:01 +02:00
regulator: Provide optional dummy regulator for consumers In order to ease transitions with drivers are boards start using regulators provide an option to cause all regulator_get() calls to succeed, with a dummy always on regulator being supplied where one has not been configured. A warning is printed whenever the dummy regulator is used to aid system development. This regulator does not implement any regulator operations but will allow simple consumers which only do enable() and disable() calls to run. It is kept separate from the fixed voltage regulator to avoid Kconfig confusion on the part of users when it is extended to allow boards to explicitly use the dummy regulator to simplify cases where the majority of supplies are from fixed regulators without software control. This option is currently only effective for systems which do not specify full constriants. If required an override could also be provided to allow these systems to use the dummy regulator, though it is likely that unconfigured supplies on such systems will lead to error due to regulators being powered down more aggressively when not in use. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
2010-02-12 10:18:08 +00:00
regulator: Add export.h for THIS_MODULE to dummy.c So that THIS_MODULE is still in scope once we clean up the presence of module.h being everywhere. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-07-17 15:48:22 -04:00
regulator: dummy: convert to use the faux device interface The dummy regulator driver does not need to create a platform device, it only did so because it was simple to do. Change it over to use the faux bus instead as this is NOT a real platform device, and it makes the code even smaller than before. Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/2025021027-outclass-stress-59dd@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-10 13:30:27 +01:00
regulator: Provide optional dummy regulator for consumers In order to ease transitions with drivers are boards start using regulators provide an option to cause all regulator_get() calls to succeed, with a dummy always on regulator being supplied where one has not been configured. A warning is printed whenever the dummy regulator is used to aid system development. This regulator does not implement any regulator operations but will allow simple consumers which only do enable() and disable() calls to run. It is kept separate from the fixed voltage regulator to avoid Kconfig confusion on the part of users when it is extended to allow boards to explicitly use the dummy regulator to simplify cases where the majority of supplies are from fixed regulators without software control. This option is currently only effective for systems which do not specify full constriants. If required an override could also be provided to allow these systems to use the dummy regulator, though it is likely that unconfigured supplies on such systems will lead to error due to regulators being powered down more aggressively when not in use. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
2010-02-12 10:18:08 +00:00
regulator: dummy: Constify dummy_initdata and dummy_ops The only usage of dummy_initdata is to assign its address to the init_data field of the regulator_config struct and the only usage dummy_ops is to assign its address to the ops field in the regulator_desc struct, both which are const pointers. Make them const to allow the compiler to put them in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20200913084114.8851-2-rikard.falkeborn@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-13 10:41:10 +02:00
regulator: dummy: Should be always-on Regulator dummy does not have any enable operations. So it is always_on. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-02-25 11:03:46 +01:00
regulator: Provide optional dummy regulator for consumers In order to ease transitions with drivers are boards start using regulators provide an option to cause all regulator_get() calls to succeed, with a dummy always on regulator being supplied where one has not been configured. A warning is printed whenever the dummy regulator is used to aid system development. This regulator does not implement any regulator operations but will allow simple consumers which only do enable() and disable() calls to run. It is kept separate from the fixed voltage regulator to avoid Kconfig confusion on the part of users when it is extended to allow boards to explicitly use the dummy regulator to simplify cases where the majority of supplies are from fixed regulators without software control. This option is currently only effective for systems which do not specify full constriants. If required an override could also be provided to allow these systems to use the dummy regulator, though it is likely that unconfigured supplies on such systems will lead to error due to regulators being powered down more aggressively when not in use. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
2010-02-12 10:18:08 +00:00
regulator: dummy: Constify dummy_initdata and dummy_ops The only usage of dummy_initdata is to assign its address to the init_data field of the regulator_config struct and the only usage dummy_ops is to assign its address to the ops field in the regulator_desc struct, both which are const pointers. Make them const to allow the compiler to put them in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20200913084114.8851-2-rikard.falkeborn@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-13 10:41:10 +02:00
regulator: Provide optional dummy regulator for consumers In order to ease transitions with drivers are boards start using regulators provide an option to cause all regulator_get() calls to succeed, with a dummy always on regulator being supplied where one has not been configured. A warning is printed whenever the dummy regulator is used to aid system development. This regulator does not implement any regulator operations but will allow simple consumers which only do enable() and disable() calls to run. It is kept separate from the fixed voltage regulator to avoid Kconfig confusion on the part of users when it is extended to allow boards to explicitly use the dummy regulator to simplify cases where the majority of supplies are from fixed regulators without software control. This option is currently only effective for systems which do not specify full constriants. If required an override could also be provided to allow these systems to use the dummy regulator, though it is likely that unconfigured supplies on such systems will lead to error due to regulators being powered down more aggressively when not in use. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
2010-02-12 10:18:08 +00:00
regulator: dummy: Make regulator_desc array const The regulator_register() expects array of 'regulator_desc' to be const. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2014-10-27 16:44:11 +01:00
regulator: make the dummy regulator's print_constraint more helpful This prevents the output of just dummy: in the boot log. Now it says: regulator-dummy: no parameters which at least doesn't make it look like an accidental printk and also doesn't only use "dummy" which could mean anything. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-08-07 21:01:37 +02:00
regulator: Provide optional dummy regulator for consumers In order to ease transitions with drivers are boards start using regulators provide an option to cause all regulator_get() calls to succeed, with a dummy always on regulator being supplied where one has not been configured. A warning is printed whenever the dummy regulator is used to aid system development. This regulator does not implement any regulator operations but will allow simple consumers which only do enable() and disable() calls to run. It is kept separate from the fixed voltage regulator to avoid Kconfig confusion on the part of users when it is extended to allow boards to explicitly use the dummy regulator to simplify cases where the majority of supplies are from fixed regulators without software control. This option is currently only effective for systems which do not specify full constriants. If required an override could also be provided to allow these systems to use the dummy regulator, though it is likely that unconfigured supplies on such systems will lead to error due to regulators being powered down more aggressively when not in use. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
2010-02-12 10:18:08 +00:00
regulator: dummy: convert to use the faux device interface The dummy regulator driver does not need to create a platform device, it only did so because it was simple to do. Change it over to use the faux bus instead as this is NOT a real platform device, and it makes the code even smaller than before. Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/2025021027-outclass-stress-59dd@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-10 13:30:27 +01:00
regulator: Properly register dummy regulator driver Recent changes in the driver core appear to mean that the data structures for the driver core are not fully initialised unless the driver is bound. Make sure the driver core knows the dummy driver is in use by binding it to a driver. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
2011-06-07 23:36:18 +01:00
regulator: core: Use a struct to pass in regulator runtime configuration Rather than adding new arguments to regulator_register() every time we want to add a new bit of dynamic information at runtime change the function to take these via a struct. By doing this we avoid needing to do further changes like the recent addition of device tree support which required each regulator driver to be updated to take an additional parameter. The regulator_desc which should (mostly) be static data is still passed separately as most drivers are able to configure this statically at build time. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-04 00:50:22 +01:00
regulator: Properly register dummy regulator driver Recent changes in the driver core appear to mean that the data structures for the driver core are not fully initialised unless the driver is bound. Make sure the driver core knows the dummy driver is in use by binding it to a driver. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
2011-06-07 23:36:18 +01:00
regulator: dummy: convert to use the faux device interface The dummy regulator driver does not need to create a platform device, it only did so because it was simple to do. Change it over to use the faux bus instead as this is NOT a real platform device, and it makes the code even smaller than before. Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/2025021027-outclass-stress-59dd@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-10 13:30:27 +01:00
regulator: core: Use a struct to pass in regulator runtime configuration Rather than adding new arguments to regulator_register() every time we want to add a new bit of dynamic information at runtime change the function to take these via a struct. By doing this we avoid needing to do further changes like the recent addition of device tree support which required each regulator driver to be updated to take an additional parameter. The regulator_desc which should (mostly) be static data is still passed separately as most drivers are able to configure this statically at build time. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-04 00:50:22 +01:00
regulator: dummy: convert to use the faux device interface The dummy regulator driver does not need to create a platform device, it only did so because it was simple to do. Change it over to use the faux bus instead as this is NOT a real platform device, and it makes the code even smaller than before. Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/2025021027-outclass-stress-59dd@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-10 13:30:27 +01:00
regulator: dummy: Use devm_regulator_register() debugfs code complained at boot time that debugfs: Directory 'reg-dummy-regulator-dummy' with parent 'regulator' already present! if we compile kernel with DEBUG_TEST_DRIVER_REMOVE. The problem is that we don't provide .remove() method for dummy_regulator_driver, which should invoke regulator_unregister() on device teardown to properly free things. Though it's harmless as dummy_pdev never gets unbound in practice, let's use devm_regulator_register() to get rid of the inconsistency. Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20210925035507.1904-1-yuzenghui@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-25 11:55:07 +08:00
regulator: Properly register dummy regulator driver Recent changes in the driver core appear to mean that the data structures for the driver core are not fully initialised unless the driver is bound. Make sure the driver core knows the dummy driver is in use by binding it to a driver. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
2011-06-07 23:36:18 +01:00
regulator: dummy: convert to use the faux device interface The dummy regulator driver does not need to create a platform device, it only did so because it was simple to do. Change it over to use the faux bus instead as this is NOT a real platform device, and it makes the code even smaller than before. Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/2025021027-outclass-stress-59dd@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-10 13:30:27 +01:00
regulator: Properly register dummy regulator driver Recent changes in the driver core appear to mean that the data structures for the driver core are not fully initialised unless the driver is bound. Make sure the driver core knows the dummy driver is in use by binding it to a driver. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
2011-06-07 23:36:18 +01:00
regulator: dummy: convert to use the faux device interface The dummy regulator driver does not need to create a platform device, it only did so because it was simple to do. Change it over to use the faux bus instead as this is NOT a real platform device, and it makes the code even smaller than before. Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/2025021027-outclass-stress-59dd@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-10 13:30:27 +01:00
regulator: Provide optional dummy regulator for consumers In order to ease transitions with drivers are boards start using regulators provide an option to cause all regulator_get() calls to succeed, with a dummy always on regulator being supplied where one has not been configured. A warning is printed whenever the dummy regulator is used to aid system development. This regulator does not implement any regulator operations but will allow simple consumers which only do enable() and disable() calls to run. It is kept separate from the fixed voltage regulator to avoid Kconfig confusion on the part of users when it is extended to allow boards to explicitly use the dummy regulator to simplify cases where the majority of supplies are from fixed regulators without software control. This option is currently only effective for systems which do not specify full constriants. If required an override could also be provided to allow these systems to use the dummy regulator, though it is likely that unconfigured supplies on such systems will lead to error due to regulators being powered down more aggressively when not in use. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
2010-02-12 10:18:08 +00:00
regulator: dummy: convert to use the faux device interface The dummy regulator driver does not need to create a platform device, it only did so because it was simple to do. Change it over to use the faux bus instead as this is NOT a real platform device, and it makes the code even smaller than before. Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/2025021027-outclass-stress-59dd@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-10 13:30:27 +01:00
regulator: Provide optional dummy regulator for consumers In order to ease transitions with drivers are boards start using regulators provide an option to cause all regulator_get() calls to succeed, with a dummy always on regulator being supplied where one has not been configured. A warning is printed whenever the dummy regulator is used to aid system development. This regulator does not implement any regulator operations but will allow simple consumers which only do enable() and disable() calls to run. It is kept separate from the fixed voltage regulator to avoid Kconfig confusion on the part of users when it is extended to allow boards to explicitly use the dummy regulator to simplify cases where the majority of supplies are from fixed regulators without software control. This option is currently only effective for systems which do not specify full constriants. If required an override could also be provided to allow these systems to use the dummy regulator, though it is likely that unconfigured supplies on such systems will lead to error due to regulators being powered down more aggressively when not in use. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
2010-02-12 10:18:08 +00:00