* [PATCH 0/3] ARM: omap: randconfig warning fixes
@ 2016-02-23 13:57 ` Arnd Bergmann
0 siblings, 0 replies; 20+ messages in thread
From: Arnd Bergmann @ 2016-02-23 13:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tony,
Here are three patches to fix the remaining warnings I get
in OMAP randconfig builds. The problems are all harmless,
and the patches are just shutting up the compiler, but I
think it's still worthwhile to include them to reduce the
noise.
Arnd
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 1/3] ARM: omap2: mark unused functions as __maybe_unused
2016-02-23 13:57 ` Arnd Bergmann
@ 2016-02-23 13:57 ` Arnd Bergmann
-1 siblings, 0 replies; 20+ messages in thread
From: Arnd Bergmann @ 2016-02-23 13:57 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-arm-kernel, linux-omap, Arnd Bergmann, linux-kernel
The omap_generic_init() and omap_hwmod_init_postsetup() functions are
used in the initialization for all OMAP2+ SoC types, but in the
extreme case that those are all disabled, we get a warning about
unused code:
arch/arm/mach-omap2/io.c:412:123: error: 'omap_hwmod_init_postsetup' defined but not used [-Werror=unused-function]
arch/arm/mach-omap2/board-generic.c:30:123: error: 'omap_generic_init' defined but not used [-Werror=unused-function]
This annotates both as __maybe_unused to shut up that warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-omap2/board-generic.c | 2 +-
arch/arm/mach-omap2/io.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index bab814d2f37d..d75ec64ae0b5 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -28,7 +28,7 @@ static const struct of_device_id omap_dt_match_table[] __initconst = {
{ }
};
-static void __init omap_generic_init(void)
+static void __init __maybe_unused omap_generic_init(void)
{
omapdss_early_init_of();
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 3c87e40650cf..f192fc7fd4f7 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -409,7 +409,7 @@ static int _set_hwmod_postsetup_state(struct omap_hwmod *oh, void *data)
return omap_hwmod_set_postsetup_state(oh, *(u8 *)data);
}
-static void __init omap_hwmod_init_postsetup(void)
+static void __init __maybe_unused omap_hwmod_init_postsetup(void)
{
u8 postsetup_state;
--
2.7.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH 1/3] ARM: omap2: mark unused functions as __maybe_unused
@ 2016-02-23 13:57 ` Arnd Bergmann
0 siblings, 0 replies; 20+ messages in thread
From: Arnd Bergmann @ 2016-02-23 13:57 UTC (permalink / raw)
To: linux-arm-kernel
The omap_generic_init() and omap_hwmod_init_postsetup() functions are
used in the initialization for all OMAP2+ SoC types, but in the
extreme case that those are all disabled, we get a warning about
unused code:
arch/arm/mach-omap2/io.c:412:123: error: 'omap_hwmod_init_postsetup' defined but not used [-Werror=unused-function]
arch/arm/mach-omap2/board-generic.c:30:123: error: 'omap_generic_init' defined but not used [-Werror=unused-function]
This annotates both as __maybe_unused to shut up that warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-omap2/board-generic.c | 2 +-
arch/arm/mach-omap2/io.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index bab814d2f37d..d75ec64ae0b5 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -28,7 +28,7 @@ static const struct of_device_id omap_dt_match_table[] __initconst = {
{ }
};
-static void __init omap_generic_init(void)
+static void __init __maybe_unused omap_generic_init(void)
{
omapdss_early_init_of();
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 3c87e40650cf..f192fc7fd4f7 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -409,7 +409,7 @@ static int _set_hwmod_postsetup_state(struct omap_hwmod *oh, void *data)
return omap_hwmod_set_postsetup_state(oh, *(u8 *)data);
}
-static void __init omap_hwmod_init_postsetup(void)
+static void __init __maybe_unused omap_hwmod_init_postsetup(void)
{
u8 postsetup_state;
--
2.7.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH 1/3] ARM: omap2: mark unused functions as __maybe_unused
2016-02-23 13:57 ` Arnd Bergmann
@ 2016-02-23 16:07 ` Tony Lindgren
-1 siblings, 0 replies; 20+ messages in thread
From: Tony Lindgren @ 2016-02-23 16:07 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, linux-omap, linux-kernel
* Arnd Bergmann <arnd@arndb.de> [160223 05:58]:
> The omap_generic_init() and omap_hwmod_init_postsetup() functions are
> used in the initialization for all OMAP2+ SoC types, but in the
> extreme case that those are all disabled, we get a warning about
> unused code:
>
> arch/arm/mach-omap2/io.c:412:123: error: 'omap_hwmod_init_postsetup' defined but not used [-Werror=unused-function]
> arch/arm/mach-omap2/board-generic.c:30:123: error: 'omap_generic_init' defined but not used [-Werror=unused-function]
>
> This annotates both as __maybe_unused to shut up that warning.
Looks OK to me:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 1/3] ARM: omap2: mark unused functions as __maybe_unused
@ 2016-02-23 16:07 ` Tony Lindgren
0 siblings, 0 replies; 20+ messages in thread
From: Tony Lindgren @ 2016-02-23 16:07 UTC (permalink / raw)
To: linux-arm-kernel
* Arnd Bergmann <arnd@arndb.de> [160223 05:58]:
> The omap_generic_init() and omap_hwmod_init_postsetup() functions are
> used in the initialization for all OMAP2+ SoC types, but in the
> extreme case that those are all disabled, we get a warning about
> unused code:
>
> arch/arm/mach-omap2/io.c:412:123: error: 'omap_hwmod_init_postsetup' defined but not used [-Werror=unused-function]
> arch/arm/mach-omap2/board-generic.c:30:123: error: 'omap_generic_init' defined but not used [-Werror=unused-function]
>
> This annotates both as __maybe_unused to shut up that warning.
Looks OK to me:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 2/3] ARM: omap1: avoid unused variable warning
2016-02-23 13:57 ` Arnd Bergmann
@ 2016-02-23 13:57 ` Arnd Bergmann
-1 siblings, 0 replies; 20+ messages in thread
From: Arnd Bergmann @ 2016-02-23 13:57 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-arm-kernel, linux-omap, Arnd Bergmann, linux-kernel
The osk_mistral_init() contains code that is only compiled when
CONFIG_PM is set, but it uses a variable that is declared outside
of the #ifdef:
arch/arm/mach-omap1/board-osk.c: In function 'osk_mistral_init':
arch/arm/mach-omap1/board-osk.c:513:7: warning: unused variable 'ret' [-Wunused-variable]
This puts the variable in the same #ifdef to avoid the warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-omap1/board-osk.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index 209aecb0df68..fcc5c0650429 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -510,7 +510,9 @@ static void __init osk_mistral_init(void)
*/
omap_cfg_reg(N15_1610_MPUIO2);
if (gpio_request(OMAP_MPUIO(2), "wakeup") == 0) {
+#ifdef CONFIG_PM
int ret = 0;
+#endif
int irq = gpio_to_irq(OMAP_MPUIO(2));
gpio_direction_input(OMAP_MPUIO(2));
--
2.7.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH 2/3] ARM: omap1: avoid unused variable warning
@ 2016-02-23 13:57 ` Arnd Bergmann
0 siblings, 0 replies; 20+ messages in thread
From: Arnd Bergmann @ 2016-02-23 13:57 UTC (permalink / raw)
To: linux-arm-kernel
The osk_mistral_init() contains code that is only compiled when
CONFIG_PM is set, but it uses a variable that is declared outside
of the #ifdef:
arch/arm/mach-omap1/board-osk.c: In function 'osk_mistral_init':
arch/arm/mach-omap1/board-osk.c:513:7: warning: unused variable 'ret' [-Wunused-variable]
This puts the variable in the same #ifdef to avoid the warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-omap1/board-osk.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index 209aecb0df68..fcc5c0650429 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -510,7 +510,9 @@ static void __init osk_mistral_init(void)
*/
omap_cfg_reg(N15_1610_MPUIO2);
if (gpio_request(OMAP_MPUIO(2), "wakeup") == 0) {
+#ifdef CONFIG_PM
int ret = 0;
+#endif
int irq = gpio_to_irq(OMAP_MPUIO(2));
gpio_direction_input(OMAP_MPUIO(2));
--
2.7.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH 2/3] ARM: omap1: avoid unused variable warning
2016-02-23 13:57 ` Arnd Bergmann
@ 2016-02-23 16:10 ` Tony Lindgren
-1 siblings, 0 replies; 20+ messages in thread
From: Tony Lindgren @ 2016-02-23 16:10 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, linux-omap, linux-kernel
* Arnd Bergmann <arnd@arndb.de> [160223 05:58]:
> The osk_mistral_init() contains code that is only compiled when
> CONFIG_PM is set, but it uses a variable that is declared outside
> of the #ifdef:
>
> arch/arm/mach-omap1/board-osk.c: In function 'osk_mistral_init':
> arch/arm/mach-omap1/board-osk.c:513:7: warning: unused variable 'ret' [-Wunused-variable]
>
> This puts the variable in the same #ifdef to avoid the warning.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/mach-omap1/board-osk.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
> index 209aecb0df68..fcc5c0650429 100644
> --- a/arch/arm/mach-omap1/board-osk.c
> +++ b/arch/arm/mach-omap1/board-osk.c
> @@ -510,7 +510,9 @@ static void __init osk_mistral_init(void)
> */
> omap_cfg_reg(N15_1610_MPUIO2);
> if (gpio_request(OMAP_MPUIO(2), "wakeup") == 0) {
> +#ifdef CONFIG_PM
> int ret = 0;
> +#endif
> int irq = gpio_to_irq(OMAP_MPUIO(2));
>
> gpio_direction_input(OMAP_MPUIO(2));
Let's just remove the #ifdef CONFIG_PM in osk_mistral_init()
instead. That's for the wake-up button and I'm not aware
of any other use cases for that button.
Regards,
Tony
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 2/3] ARM: omap1: avoid unused variable warning
@ 2016-02-23 16:10 ` Tony Lindgren
0 siblings, 0 replies; 20+ messages in thread
From: Tony Lindgren @ 2016-02-23 16:10 UTC (permalink / raw)
To: linux-arm-kernel
* Arnd Bergmann <arnd@arndb.de> [160223 05:58]:
> The osk_mistral_init() contains code that is only compiled when
> CONFIG_PM is set, but it uses a variable that is declared outside
> of the #ifdef:
>
> arch/arm/mach-omap1/board-osk.c: In function 'osk_mistral_init':
> arch/arm/mach-omap1/board-osk.c:513:7: warning: unused variable 'ret' [-Wunused-variable]
>
> This puts the variable in the same #ifdef to avoid the warning.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/mach-omap1/board-osk.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
> index 209aecb0df68..fcc5c0650429 100644
> --- a/arch/arm/mach-omap1/board-osk.c
> +++ b/arch/arm/mach-omap1/board-osk.c
> @@ -510,7 +510,9 @@ static void __init osk_mistral_init(void)
> */
> omap_cfg_reg(N15_1610_MPUIO2);
> if (gpio_request(OMAP_MPUIO(2), "wakeup") == 0) {
> +#ifdef CONFIG_PM
> int ret = 0;
> +#endif
> int irq = gpio_to_irq(OMAP_MPUIO(2));
>
> gpio_direction_input(OMAP_MPUIO(2));
Let's just remove the #ifdef CONFIG_PM in osk_mistral_init()
instead. That's for the wake-up button and I'm not aware
of any other use cases for that button.
Regards,
Tony
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 2/3] ARM: omap1: avoid unused variable warning
2016-02-23 13:57 ` Arnd Bergmann
@ 2016-02-23 23:40 ` Aaro Koskinen
-1 siblings, 0 replies; 20+ messages in thread
From: Aaro Koskinen @ 2016-02-23 23:40 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Tony Lindgren, linux-arm-kernel, linux-omap, linux-kernel
On Tue, Feb 23, 2016 at 02:57:52PM +0100, Arnd Bergmann wrote:
> The osk_mistral_init() contains code that is only compiled when
> CONFIG_PM is set, but it uses a variable that is declared outside
> of the #ifdef:
>
> arch/arm/mach-omap1/board-osk.c: In function 'osk_mistral_init':
> arch/arm/mach-omap1/board-osk.c:513:7: warning: unused variable 'ret' [-Wunused-variable]
>
> This puts the variable in the same #ifdef to avoid the warning.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
A.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 2/3] ARM: omap1: avoid unused variable warning
@ 2016-02-23 23:40 ` Aaro Koskinen
0 siblings, 0 replies; 20+ messages in thread
From: Aaro Koskinen @ 2016-02-23 23:40 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 23, 2016 at 02:57:52PM +0100, Arnd Bergmann wrote:
> The osk_mistral_init() contains code that is only compiled when
> CONFIG_PM is set, but it uses a variable that is declared outside
> of the #ifdef:
>
> arch/arm/mach-omap1/board-osk.c: In function 'osk_mistral_init':
> arch/arm/mach-omap1/board-osk.c:513:7: warning: unused variable 'ret' [-Wunused-variable]
>
> This puts the variable in the same #ifdef to avoid the warning.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
A.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 3/3] ARM: omap1/ams-delta: warn about failed regulator enable
2016-02-23 13:57 ` Arnd Bergmann
@ 2016-02-23 13:57 ` Arnd Bergmann
-1 siblings, 0 replies; 20+ messages in thread
From: Arnd Bergmann @ 2016-02-23 13:57 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-arm-kernel, linux-omap, Arnd Bergmann, linux-kernel
The modem pm handler in the ams-delta board uses regulator_enable()
but does not check for a successful return code:
board-ams-delta.c:521:3: error: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result [-Werror=unused-result]
It is not easy to propagate that return code to the callers in
uart_configure_port/uart_suspend_port/uart_resume_port, unless
we change all UART drivers, and it is unclear what those would
do with the return code.
Instead, this patch uses a runtime warning to replace the
compiletime warning. I have checked that the regulator in question
is hardcoded to a fixed-voltage GPIO regulator, and that should
never fail to get enabled if I understand the code right.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-omap1/board-ams-delta.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index 6613a6ff5dbc..6cbc69c92913 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -510,6 +510,7 @@ static void __init ams_delta_init(void)
static void modem_pm(struct uart_port *port, unsigned int state, unsigned old)
{
struct modem_private_data *priv = port->private_data;
+ int ret;
if (IS_ERR(priv->regulator))
return;
@@ -518,9 +519,16 @@ static void modem_pm(struct uart_port *port, unsigned int state, unsigned old)
return;
if (state == 0)
- regulator_enable(priv->regulator);
+ ret = regulator_enable(priv->regulator);
else if (old == 0)
- regulator_disable(priv->regulator);
+ ret = regulator_disable(priv->regulator);
+ else
+ ret = 0;
+
+ if (ret)
+ dev_warn(port->dev,
+ "ams_delta modem_pm: failed to %sable regulator: %d\n",
+ state ? "dis" : "en", ret);
}
static struct plat_serial8250_port ams_delta_modem_ports[] = {
--
2.7.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH 3/3] ARM: omap1/ams-delta: warn about failed regulator enable
@ 2016-02-23 13:57 ` Arnd Bergmann
0 siblings, 0 replies; 20+ messages in thread
From: Arnd Bergmann @ 2016-02-23 13:57 UTC (permalink / raw)
To: linux-arm-kernel
The modem pm handler in the ams-delta board uses regulator_enable()
but does not check for a successful return code:
board-ams-delta.c:521:3: error: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result [-Werror=unused-result]
It is not easy to propagate that return code to the callers in
uart_configure_port/uart_suspend_port/uart_resume_port, unless
we change all UART drivers, and it is unclear what those would
do with the return code.
Instead, this patch uses a runtime warning to replace the
compiletime warning. I have checked that the regulator in question
is hardcoded to a fixed-voltage GPIO regulator, and that should
never fail to get enabled if I understand the code right.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-omap1/board-ams-delta.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index 6613a6ff5dbc..6cbc69c92913 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -510,6 +510,7 @@ static void __init ams_delta_init(void)
static void modem_pm(struct uart_port *port, unsigned int state, unsigned old)
{
struct modem_private_data *priv = port->private_data;
+ int ret;
if (IS_ERR(priv->regulator))
return;
@@ -518,9 +519,16 @@ static void modem_pm(struct uart_port *port, unsigned int state, unsigned old)
return;
if (state == 0)
- regulator_enable(priv->regulator);
+ ret = regulator_enable(priv->regulator);
else if (old == 0)
- regulator_disable(priv->regulator);
+ ret = regulator_disable(priv->regulator);
+ else
+ ret = 0;
+
+ if (ret)
+ dev_warn(port->dev,
+ "ams_delta modem_pm: failed to %sable regulator: %d\n",
+ state ? "dis" : "en", ret);
}
static struct plat_serial8250_port ams_delta_modem_ports[] = {
--
2.7.0
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH 3/3] ARM: omap1/ams-delta: warn about failed regulator enable
2016-02-23 13:57 ` Arnd Bergmann
@ 2016-02-23 16:10 ` Tony Lindgren
-1 siblings, 0 replies; 20+ messages in thread
From: Tony Lindgren @ 2016-02-23 16:10 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, linux-omap, linux-kernel
* Arnd Bergmann <arnd@arndb.de> [160223 05:58]:
> The modem pm handler in the ams-delta board uses regulator_enable()
> but does not check for a successful return code:
>
> board-ams-delta.c:521:3: error: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result [-Werror=unused-result]
>
> It is not easy to propagate that return code to the callers in
> uart_configure_port/uart_suspend_port/uart_resume_port, unless
> we change all UART drivers, and it is unclear what those would
> do with the return code.
>
> Instead, this patch uses a runtime warning to replace the
> compiletime warning. I have checked that the regulator in question
> is hardcoded to a fixed-voltage GPIO regulator, and that should
> never fail to get enabled if I understand the code right.
Looks OK to me:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 3/3] ARM: omap1/ams-delta: warn about failed regulator enable
@ 2016-02-23 16:10 ` Tony Lindgren
0 siblings, 0 replies; 20+ messages in thread
From: Tony Lindgren @ 2016-02-23 16:10 UTC (permalink / raw)
To: linux-arm-kernel
* Arnd Bergmann <arnd@arndb.de> [160223 05:58]:
> The modem pm handler in the ams-delta board uses regulator_enable()
> but does not check for a successful return code:
>
> board-ams-delta.c:521:3: error: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result [-Werror=unused-result]
>
> It is not easy to propagate that return code to the callers in
> uart_configure_port/uart_suspend_port/uart_resume_port, unless
> we change all UART drivers, and it is unclear what those would
> do with the return code.
>
> Instead, this patch uses a runtime warning to replace the
> compiletime warning. I have checked that the regulator in question
> is hardcoded to a fixed-voltage GPIO regulator, and that should
> never fail to get enabled if I understand the code right.
Looks OK to me:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 3/3] ARM: omap1/ams-delta: warn about failed regulator enable
2016-02-23 16:10 ` Tony Lindgren
@ 2016-02-23 16:15 ` One Thousand Gnomes
-1 siblings, 0 replies; 20+ messages in thread
From: One Thousand Gnomes @ 2016-02-23 16:15 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Arnd Bergmann, linux-arm-kernel, linux-omap, linux-kernel
> > It is not easy to propagate that return code to the callers in
> > uart_configure_port/uart_suspend_port/uart_resume_port, unless
> > we change all UART drivers, and it is unclear what those would
> > do with the return code.
> >
> > Instead, this patch uses a runtime warning to replace the
> > compiletime warning. I have checked that the regulator in question
> > is hardcoded to a fixed-voltage GPIO regulator, and that should
> > never fail to get enabled if I understand the code right.
>
> Looks OK to me:
If it was a concern for a real driver I think I'd perform a hangup on the
port at that moment. That's what happens if for example you hot unplug a
serial port which would be approximately the same as finding out you
can't power it back up.
Alan
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 3/3] ARM: omap1/ams-delta: warn about failed regulator enable
@ 2016-02-23 16:15 ` One Thousand Gnomes
0 siblings, 0 replies; 20+ messages in thread
From: One Thousand Gnomes @ 2016-02-23 16:15 UTC (permalink / raw)
To: linux-arm-kernel
> > It is not easy to propagate that return code to the callers in
> > uart_configure_port/uart_suspend_port/uart_resume_port, unless
> > we change all UART drivers, and it is unclear what those would
> > do with the return code.
> >
> > Instead, this patch uses a runtime warning to replace the
> > compiletime warning. I have checked that the regulator in question
> > is hardcoded to a fixed-voltage GPIO regulator, and that should
> > never fail to get enabled if I understand the code right.
>
> Looks OK to me:
If it was a concern for a real driver I think I'd perform a hangup on the
port at that moment. That's what happens if for example you hot unplug a
serial port which would be approximately the same as finding out you
can't power it back up.
Alan
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 3/3] ARM: omap1/ams-delta: warn about failed regulator enable
2016-02-23 13:57 ` Arnd Bergmann
@ 2016-02-23 23:40 ` Aaro Koskinen
-1 siblings, 0 replies; 20+ messages in thread
From: Aaro Koskinen @ 2016-02-23 23:40 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Tony Lindgren, linux-arm-kernel, linux-omap, linux-kernel
On Tue, Feb 23, 2016 at 02:57:53PM +0100, Arnd Bergmann wrote:
> The modem pm handler in the ams-delta board uses regulator_enable()
> but does not check for a successful return code:
>
> board-ams-delta.c:521:3: error: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result [-Werror=unused-result]
>
> It is not easy to propagate that return code to the callers in
> uart_configure_port/uart_suspend_port/uart_resume_port, unless
> we change all UART drivers, and it is unclear what those would
> do with the return code.
>
> Instead, this patch uses a runtime warning to replace the
> compiletime warning. I have checked that the regulator in question
> is hardcoded to a fixed-voltage GPIO regulator, and that should
> never fail to get enabled if I understand the code right.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
A.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 3/3] ARM: omap1/ams-delta: warn about failed regulator enable
@ 2016-02-23 23:40 ` Aaro Koskinen
0 siblings, 0 replies; 20+ messages in thread
From: Aaro Koskinen @ 2016-02-23 23:40 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 23, 2016 at 02:57:53PM +0100, Arnd Bergmann wrote:
> The modem pm handler in the ams-delta board uses regulator_enable()
> but does not check for a successful return code:
>
> board-ams-delta.c:521:3: error: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result [-Werror=unused-result]
>
> It is not easy to propagate that return code to the callers in
> uart_configure_port/uart_suspend_port/uart_resume_port, unless
> we change all UART drivers, and it is unclear what those would
> do with the return code.
>
> Instead, this patch uses a runtime warning to replace the
> compiletime warning. I have checked that the regulator in question
> is hardcoded to a fixed-voltage GPIO regulator, and that should
> never fail to get enabled if I understand the code right.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
A.
^ permalink raw reply [flat|nested] 20+ messages in thread