Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
is possible to test-build any driver which depends on OF on any
architecture by explicitly selecting OF. Therefore depending on
COMPILE_TEST as an alternative is no longer needed.
It is actually better to always build such drivers with OF enabled,
so that the test builds are closer to how each driver will actually be
built on its intended target. Building them without OF may not test
much as the compiler will optimize out potentially large parts of the
code. In the worst case, this could even pop false positive warnings.
Dropping COMPILE_TEST here improves the quality of our testing and
avoids wasting time on non-existent issues.
As a minor optimization, this also lets us drop several occurrences of
of_match_ptr(), __maybe_unused and some ifdef guarding, as we now know
what all of this will resolve to, we might as well save cpp some work.
Signed-off-by: Jean Delvare <[email protected]>
Cc: Liam Girdwood <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Icenowy Zheng <[email protected]>
---
drivers/regulator/Kconfig | 10 +++++-----
drivers/regulator/fan53880.c | 16 +++++++---------
drivers/regulator/mp886x.c | 2 +-
drivers/regulator/sy8106a-regulator.c | 4 ++--
drivers/regulator/sy8824x.c | 2 +-
drivers/regulator/sy8827n.c | 4 +---
6 files changed, 17 insertions(+), 21 deletions(-)
--- linux-6.0.orig/drivers/regulator/Kconfig
+++ linux-6.0/drivers/regulator/Kconfig
@@ -377,7 +377,7 @@ config REGULATOR_FAN53555
config REGULATOR_FAN53880
tristate "Fairchild FAN53880 Regulator"
- depends on I2C && (OF || COMPILE_TEST)
+ depends on I2C && OF
select REGMAP_I2C
help
This driver supports Fairchild (ON Semiconductor) FAN53880
@@ -743,7 +743,7 @@ config REGULATOR_MP8859
config REGULATOR_MP886X
tristate "MPS MP8869 regulator driver"
- depends on I2C && (OF || COMPILE_TEST)
+ depends on I2C && OF
select REGMAP_I2C
help
This driver supports the MP8869 voltage regulator.
@@ -1269,21 +1269,21 @@ config REGULATOR_SY7636A
config REGULATOR_SY8106A
tristate "Silergy SY8106A regulator"
- depends on I2C && (OF || COMPILE_TEST)
+ depends on I2C && OF
select REGMAP_I2C
help
This driver supports SY8106A single output regulator.
config REGULATOR_SY8824X
tristate "Silergy SY8824C/SY8824E regulator"
- depends on I2C && (OF || COMPILE_TEST)
+ depends on I2C && OF
select REGMAP_I2C
help
This driver supports SY8824C single output regulator.
config REGULATOR_SY8827N
tristate "Silergy SY8827N regulator"
- depends on I2C && (OF || COMPILE_TEST)
+ depends on I2C && OF
select REGMAP_I2C
help
This driver supports SY8827N single output regulator.
--- linux-6.0.orig/drivers/regulator/fan53880.c
+++ linux-6.0/drivers/regulator/fan53880.c
@@ -42,8 +42,8 @@ static const struct regulator_ops fan538
#define FAN53880_LDO(_num, _supply, _default) \
[FAN53880_LDO ## _num] = { \
.name = "LDO"#_num, \
- .of_match = of_match_ptr("LDO"#_num), \
- .regulators_node = of_match_ptr("regulators"), \
+ .of_match = "LDO"#_num, \
+ .regulators_node = "regulators", \
.type = REGULATOR_VOLTAGE, \
.owner = THIS_MODULE, \
.linear_ranges = (struct linear_range[]) { \
@@ -68,8 +68,8 @@ static const struct regulator_desc fan53
FAN53880_LDO(4, "VIN4", 1800000),
[FAN53880_BUCK] = {
.name = "BUCK",
- .of_match = of_match_ptr("BUCK"),
- .regulators_node = of_match_ptr("regulators"),
+ .of_match = "BUCK",
+ .regulators_node = "regulators",
.type = REGULATOR_VOLTAGE,
.owner = THIS_MODULE,
.linear_ranges = (struct linear_range[]) {
@@ -88,8 +88,8 @@ static const struct regulator_desc fan53
},
[FAN53880_BOOST] = {
.name = "BOOST",
- .of_match = of_match_ptr("BOOST"),
- .regulators_node = of_match_ptr("regulators"),
+ .of_match = "BOOST",
+ .regulators_node = "regulators",
.type = REGULATOR_VOLTAGE,
.owner = THIS_MODULE,
.linear_ranges = (struct linear_range[]) {
@@ -157,13 +157,11 @@ static int fan53880_i2c_probe(struct i2c
return 0;
}
-#ifdef CONFIG_OF
static const struct of_device_id fan53880_dt_ids[] = {
{ .compatible = "onnn,fan53880", },
{}
};
MODULE_DEVICE_TABLE(of, fan53880_dt_ids);
-#endif
static const struct i2c_device_id fan53880_i2c_id[] = {
{ "fan53880", },
@@ -174,7 +172,7 @@ MODULE_DEVICE_TABLE(i2c, fan53880_i2c_id
static struct i2c_driver fan53880_regulator_driver = {
.driver = {
.name = "fan53880",
- .of_match_table = of_match_ptr(fan53880_dt_ids),
+ .of_match_table = fan53880_dt_ids,
},
.probe_new = fan53880_i2c_probe,
.id_table = fan53880_i2c_id,
--- linux-6.0.orig/drivers/regulator/mp886x.c
+++ linux-6.0/drivers/regulator/mp886x.c
@@ -362,7 +362,7 @@ MODULE_DEVICE_TABLE(i2c, mp886x_id);
static struct i2c_driver mp886x_regulator_driver = {
.driver = {
.name = "mp886x-regulator",
- .of_match_table = of_match_ptr(mp886x_dt_ids),
+ .of_match_table = mp886x_dt_ids,
},
.probe_new = mp886x_i2c_probe,
.id_table = mp886x_id,
--- linux-6.0.orig/drivers/regulator/sy8106a-regulator.c
+++ linux-6.0/drivers/regulator/sy8106a-regulator.c
@@ -123,7 +123,7 @@ static int sy8106a_i2c_probe(struct i2c_
return 0;
}
-static const struct of_device_id __maybe_unused sy8106a_i2c_of_match[] = {
+static const struct of_device_id sy8106a_i2c_of_match[] = {
{ .compatible = "silergy,sy8106a" },
{ },
};
@@ -138,7 +138,7 @@ MODULE_DEVICE_TABLE(i2c, sy8106a_i2c_id)
static struct i2c_driver sy8106a_regulator_driver = {
.driver = {
.name = "sy8106a",
- .of_match_table = of_match_ptr(sy8106a_i2c_of_match),
+ .of_match_table = sy8106a_i2c_of_match,
},
.probe_new = sy8106a_i2c_probe,
.id_table = sy8106a_i2c_id,
--- linux-6.0.orig/drivers/regulator/sy8824x.c
+++ linux-6.0/drivers/regulator/sy8824x.c
@@ -233,7 +233,7 @@ MODULE_DEVICE_TABLE(i2c, sy8824_id);
static struct i2c_driver sy8824_regulator_driver = {
.driver = {
.name = "sy8824-regulator",
- .of_match_table = of_match_ptr(sy8824_dt_ids),
+ .of_match_table = sy8824_dt_ids,
},
.probe_new = sy8824_i2c_probe,
.id_table = sy8824_id,
--- linux-6.0.orig/drivers/regulator/sy8827n.c
+++ linux-6.0/drivers/regulator/sy8827n.c
@@ -170,7 +170,6 @@ static int sy8827n_i2c_probe(struct i2c_
return ret;
}
-#ifdef CONFIG_OF
static const struct of_device_id sy8827n_dt_ids[] = {
{
.compatible = "silergy,sy8827n",
@@ -178,7 +177,6 @@ static const struct of_device_id sy8827n
{ }
};
MODULE_DEVICE_TABLE(of, sy8827n_dt_ids);
-#endif
static const struct i2c_device_id sy8827n_id[] = {
{ "sy8827n", },
@@ -189,7 +187,7 @@ MODULE_DEVICE_TABLE(i2c, sy8827n_id);
static struct i2c_driver sy8827n_regulator_driver = {
.driver = {
.name = "sy8827n-regulator",
- .of_match_table = of_match_ptr(sy8827n_dt_ids),
+ .of_match_table = sy8827n_dt_ids,
},
.probe_new = sy8827n_i2c_probe,
.id_table = sy8827n_id,
--
Jean Delvare
SUSE L3 Support
On Thu, Nov 24, 2022 at 02:47:08PM +0100, Jean Delvare wrote:
> It is actually better to always build such drivers with OF enabled,
> so that the test builds are closer to how each driver will actually be
> built on its intended target. Building them without OF may not test
> much as the compiler will optimize out potentially large parts of the
> code. In the worst case, this could even pop false positive warnings.
Having the ability to build without OF doesn't preclude testing with OF
of course.
On Thu, 24 Nov 2022 14:47:08 +0100, Jean Delvare wrote:
> Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
> is possible to test-build any driver which depends on OF on any
> architecture by explicitly selecting OF. Therefore depending on
> COMPILE_TEST as an alternative is no longer needed.
>
> It is actually better to always build such drivers with OF enabled,
> so that the test builds are closer to how each driver will actually be
> built on its intended target. Building them without OF may not test
> much as the compiler will optimize out potentially large parts of the
> code. In the worst case, this could even pop false positive warnings.
> Dropping COMPILE_TEST here improves the quality of our testing and
> avoids wasting time on non-existent issues.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Thanks!
[1/1] regulator: Drop obsolete dependencies on COMPILE_TEST
commit: c4b02c92d9673ef4704fd0c8f008fec183517b64
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark