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

  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(-)
  

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
>
  

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?
  

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.
  

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.
  

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.
  

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!
  

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.