diff mbox series

[net-next,v5,1/1] net: dsa: hellcreek: Get rid of custom led_init_default_state_get()

Message ID 20230310163855.21757-1-andriy.shevchenko@linux.intel.com (mailing list archive)
State Superseded
Delegated to: Netdev Maintainers
Headers show
Series [net-next,v5,1/1] net: dsa: hellcreek: Get rid of custom led_init_default_state_get() | expand

Checks

Context Check Description
netdev/series_format success Single patches do not need cover letters
netdev/tree_selection success Clearly marked for net-next
netdev/fixes_present success Fixes tag not required for -next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 18 this patch: 18
netdev/cc_maintainers warning 1 maintainers not CCed: richardcochran@gmail.com
netdev/build_clang success Errors and warnings before: 18 this patch: 18
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 18 this patch: 18
netdev/checkpatch warning WARNING: line length of 86 exceeds 80 columns WARNING: line length of 90 exceeds 80 columns
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0

Commit Message

Andy Shevchenko March 10, 2023, 4:38 p.m. UTC 
LED core provides a helper to parse default state from firmware node.
Use it instead of custom implementation.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
---
v5: resent after v6.3-rc1 with proper net-next prefix
 drivers/net/dsa/hirschmann/hellcreek_ptp.c | 45 ++++++++++++----------
 1 file changed, 24 insertions(+), 21 deletions(-)

Comments

Simon Horman March 10, 2023, 6:18 p.m. UTC | #1 
On Fri, Mar 10, 2023 at 06:38:55PM +0200, Andy Shevchenko wrote:
> LED core provides a helper to parse default state from firmware node.
> Use it instead of custom implementation.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
> ---
> v5: resent after v6.3-rc1 with proper net-next prefix
>  drivers/net/dsa/hirschmann/hellcreek_ptp.c | 45 ++++++++++++----------
>  1 file changed, 24 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/net/dsa/hirschmann/hellcreek_ptp.c b/drivers/net/dsa/hirschmann/hellcreek_ptp.c
> index b28baab6d56a..793b2c296314 100644
> --- a/drivers/net/dsa/hirschmann/hellcreek_ptp.c
> +++ b/drivers/net/dsa/hirschmann/hellcreek_ptp.c
> @@ -297,7 +297,8 @@ static enum led_brightness hellcreek_led_is_gm_get(struct led_classdev *ldev)
>  static int hellcreek_led_setup(struct hellcreek *hellcreek)
>  {
>  	struct device_node *leds, *led = NULL;
> -	const char *label, *state;
> +	enum led_default_state state;
> +	const char *label;
>  	int ret = -EINVAL;
>  
>  	of_node_get(hellcreek->dev->of_node);
> @@ -318,16 +319,17 @@ static int hellcreek_led_setup(struct hellcreek *hellcreek)
>  	ret = of_property_read_string(led, "label", &label);
>  	hellcreek->led_sync_good.name = ret ? "sync_good" : label;
>  
> -	ret = of_property_read_string(led, "default-state", &state);
> -	if (!ret) {
> -		if (!strcmp(state, "on"))
> -			hellcreek->led_sync_good.brightness = 1;
> -		else if (!strcmp(state, "off"))
> -			hellcreek->led_sync_good.brightness = 0;
> -		else if (!strcmp(state, "keep"))
> -			hellcreek->led_sync_good.brightness =
> -				hellcreek_get_brightness(hellcreek,
> -							 STATUS_OUT_SYNC_GOOD);
> +	state = led_init_default_state_get(of_fwnode_handle(led));
> +	switch (state) {
> +	case LEDS_DEFSTATE_ON:
> +		hellcreek->led_sync_good.brightness = 1;
> +		break;
> +	case LEDS_DEFSTATE_KEEP:
> +		hellcreek->led_sync_good.brightness =
> +				hellcreek_get_brightness(hellcreek, STATUS_OUT_SYNC_GOOD);

nit: I think < 80 columns wide is still preferred for network code

> +		break;
> +	default:
> +		hellcreek->led_sync_good.brightness = 0;
>  	}
>  
>  	hellcreek->led_sync_good.max_brightness = 1;
> @@ -344,16 +346,17 @@ static int hellcreek_led_setup(struct hellcreek *hellcreek)
>  	ret = of_property_read_string(led, "label", &label);
>  	hellcreek->led_is_gm.name = ret ? "is_gm" : label;
>  
> -	ret = of_property_read_string(led, "default-state", &state);
> -	if (!ret) {
> -		if (!strcmp(state, "on"))
> -			hellcreek->led_is_gm.brightness = 1;
> -		else if (!strcmp(state, "off"))
> -			hellcreek->led_is_gm.brightness = 0;
> -		else if (!strcmp(state, "keep"))
> -			hellcreek->led_is_gm.brightness =
> -				hellcreek_get_brightness(hellcreek,
> -							 STATUS_OUT_IS_GM);
> +	state = led_init_default_state_get(of_fwnode_handle(led));
> +	switch (state) {
> +	case LEDS_DEFSTATE_ON:
> +		hellcreek->led_is_gm.brightness = 1;
> +		break;
> +	case LEDS_DEFSTATE_KEEP:
> +		hellcreek->led_is_gm.brightness =
> +				hellcreek_get_brightness(hellcreek, STATUS_OUT_IS_GM);
> +		break;
> +	default:
> +		hellcreek->led_is_gm.brightness = 0;
>  	}

This seems to duplicate the logic in the earlier hunk of this patch.
Could it be moved into a helper?

>  
>  	hellcreek->led_is_gm.max_brightness = 1;
> -- 
> 2.39.1
>
Andy Shevchenko March 10, 2023, 6:44 p.m. UTC | #2 
On Fri, Mar 10, 2023 at 07:18:42PM +0100, Simon Horman wrote:
> On Fri, Mar 10, 2023 at 06:38:55PM +0200, Andy Shevchenko wrote:

...

> > +		hellcreek->led_sync_good.brightness =
> > +				hellcreek_get_brightness(hellcreek, STATUS_OUT_SYNC_GOOD);
> 
> nit: I think < 80 columns wide is still preferred for network code

I can do it if it's a strict rule here.

...

> This seems to duplicate the logic in the earlier hunk of this patch.
> Could it be moved into a helper?

It's possible, but in a separate patch as it's out of scope of this one.
Do you want to create a such?
Andy Shevchenko March 10, 2023, 8:06 p.m. UTC | #3 
On Fri, Mar 10, 2023 at 08:44:05PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 10, 2023 at 07:18:42PM +0100, Simon Horman wrote:
> > On Fri, Mar 10, 2023 at 06:38:55PM +0200, Andy Shevchenko wrote:

...

> > This seems to duplicate the logic in the earlier hunk of this patch.
> > Could it be moved into a helper?
> 
> It's possible, but in a separate patch as it's out of scope of this one.
> Do you want to create a such?

FWIW, I tried and it gives us +9 lines of code. So, what would be the point?
I can send as RFC in v6.
Simon Horman March 10, 2023, 8:16 p.m. UTC | #4 
On Fri, Mar 10, 2023 at 10:06:00PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 10, 2023 at 08:44:05PM +0200, Andy Shevchenko wrote:
> > On Fri, Mar 10, 2023 at 07:18:42PM +0100, Simon Horman wrote:
> > > On Fri, Mar 10, 2023 at 06:38:55PM +0200, Andy Shevchenko wrote:
> 
> ...
> 
> > > This seems to duplicate the logic in the earlier hunk of this patch.
> > > Could it be moved into a helper?
> > 
> > It's possible, but in a separate patch as it's out of scope of this one.
> > Do you want to create a such?
> 
> FWIW, I tried and it gives us +9 lines of code. So, what would be the point?
> I can send as RFC in v6.

Less duplication is good, IMHO. But it's not a hard requirement from my side.
Simon Horman March 10, 2023, 8:17 p.m. UTC | #5 
On Fri, Mar 10, 2023 at 08:44:04PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 10, 2023 at 07:18:42PM +0100, Simon Horman wrote:
> > On Fri, Mar 10, 2023 at 06:38:55PM +0200, Andy Shevchenko wrote:
> 
> ...
> 
> > > +		hellcreek->led_sync_good.brightness =
> > > +				hellcreek_get_brightness(hellcreek, STATUS_OUT_SYNC_GOOD);
> > 
> > nit: I think < 80 columns wide is still preferred for network code
> 
> I can do it if it's a strict rule here.

I think it is more a preference than a strict rule at this point.
Andy Shevchenko March 10, 2023, 8:23 p.m. UTC | #6 
On Fri, Mar 10, 2023 at 09:16:29PM +0100, Simon Horman wrote:
> On Fri, Mar 10, 2023 at 10:06:00PM +0200, Andy Shevchenko wrote:
> > On Fri, Mar 10, 2023 at 08:44:05PM +0200, Andy Shevchenko wrote:
> > > On Fri, Mar 10, 2023 at 07:18:42PM +0100, Simon Horman wrote:
> > > > On Fri, Mar 10, 2023 at 06:38:55PM +0200, Andy Shevchenko wrote:

...

> > > > This seems to duplicate the logic in the earlier hunk of this patch.
> > > > Could it be moved into a helper?
> > > 
> > > It's possible, but in a separate patch as it's out of scope of this one.
> > > Do you want to create a such?
> > 
> > FWIW, I tried and it gives us +9 lines of code. So, what would be the point?
> > I can send as RFC in v6.
> 
> Less duplication is good, IMHO. But it's not a hard requirement from my side.

With what I see as PoC it becomes:
a) longer (+9 LoCs);
b) less understandable.

So, I would wait for maintainers to tell me if I need this at all.

Thank you for the review!
Jakub Kicinski March 11, 2023, 2:41 a.m. UTC | #7 
On Fri, 10 Mar 2023 21:17:06 +0100 Simon Horman wrote:
> > > nit: I think < 80 columns wide is still preferred for network code  
> > 
> > I can do it if it's a strict rule here.  
> 
> I think it is more a preference than a strict rule at this point.

You're right, but the longer I think about it the more I feel like 
it should be.

80 chars is an artificial constraint these day but it simply results 
in more readable code.

I can't see the entirety of "hellcreek->led_sync_good.brightness"
at once, using it as lval in 3 different places is not great.
Maybe it's my poor eyesight.
diff mbox series

Patch

diff --git a/drivers/net/dsa/hirschmann/hellcreek_ptp.c b/drivers/net/dsa/hirschmann/hellcreek_ptp.c
index b28baab6d56a..793b2c296314 100644
--- a/drivers/net/dsa/hirschmann/hellcreek_ptp.c
+++ b/drivers/net/dsa/hirschmann/hellcreek_ptp.c
@@ -297,7 +297,8 @@  static enum led_brightness hellcreek_led_is_gm_get(struct led_classdev *ldev)
 static int hellcreek_led_setup(struct hellcreek *hellcreek)
 {
 	struct device_node *leds, *led = NULL;
-	const char *label, *state;
+	enum led_default_state state;
+	const char *label;
 	int ret = -EINVAL;
 
 	of_node_get(hellcreek->dev->of_node);
@@ -318,16 +319,17 @@  static int hellcreek_led_setup(struct hellcreek *hellcreek)
 	ret = of_property_read_string(led, "label", &label);
 	hellcreek->led_sync_good.name = ret ? "sync_good" : label;
 
-	ret = of_property_read_string(led, "default-state", &state);
-	if (!ret) {
-		if (!strcmp(state, "on"))
-			hellcreek->led_sync_good.brightness = 1;
-		else if (!strcmp(state, "off"))
-			hellcreek->led_sync_good.brightness = 0;
-		else if (!strcmp(state, "keep"))
-			hellcreek->led_sync_good.brightness =
-				hellcreek_get_brightness(hellcreek,
-							 STATUS_OUT_SYNC_GOOD);
+	state = led_init_default_state_get(of_fwnode_handle(led));
+	switch (state) {
+	case LEDS_DEFSTATE_ON:
+		hellcreek->led_sync_good.brightness = 1;
+		break;
+	case LEDS_DEFSTATE_KEEP:
+		hellcreek->led_sync_good.brightness =
+				hellcreek_get_brightness(hellcreek, STATUS_OUT_SYNC_GOOD);
+		break;
+	default:
+		hellcreek->led_sync_good.brightness = 0;
 	}
 
 	hellcreek->led_sync_good.max_brightness = 1;
@@ -344,16 +346,17 @@  static int hellcreek_led_setup(struct hellcreek *hellcreek)
 	ret = of_property_read_string(led, "label", &label);
 	hellcreek->led_is_gm.name = ret ? "is_gm" : label;
 
-	ret = of_property_read_string(led, "default-state", &state);
-	if (!ret) {
-		if (!strcmp(state, "on"))
-			hellcreek->led_is_gm.brightness = 1;
-		else if (!strcmp(state, "off"))
-			hellcreek->led_is_gm.brightness = 0;
-		else if (!strcmp(state, "keep"))
-			hellcreek->led_is_gm.brightness =
-				hellcreek_get_brightness(hellcreek,
-							 STATUS_OUT_IS_GM);
+	state = led_init_default_state_get(of_fwnode_handle(led));
+	switch (state) {
+	case LEDS_DEFSTATE_ON:
+		hellcreek->led_is_gm.brightness = 1;
+		break;
+	case LEDS_DEFSTATE_KEEP:
+		hellcreek->led_is_gm.brightness =
+				hellcreek_get_brightness(hellcreek, STATUS_OUT_IS_GM);
+		break;
+	default:
+		hellcreek->led_is_gm.brightness = 0;
 	}
 
 	hellcreek->led_is_gm.max_brightness = 1;