[PATCH 2/4] cpuidle: riscv-sbi: Use scoped device node handling to simplify error paths

Jonathan Cameron Jonathan.Cameron at Huawei.com
Wed Aug 21 04:48:02 PDT 2024


On Tue, 20 Aug 2024 11:36:32 +0200
Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:

> On 19/08/2024 18:19, Jonathan Cameron wrote:
> > On Mon, 19 Aug 2024 17:13:13 +0100
> > Jonathan Cameron <Jonathan.Cameron at Huawei.com> wrote:
> >   
> >> On Fri, 16 Aug 2024 17:09:29 +0200
> >> Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org> wrote:
> >>  
> >>> Obtain the device node reference with scoped/cleanup.h to reduce error
> >>> handling and make the code a bit simpler.
> >>>
> >>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>    
> >> The original code looks suspect. See below.  
> > 
> > Whilst here...  Why not do similar for state_node to avoid
> > the delayed return check.
> > Existing code
> > 	{
> > 		state_node = of_get_cpu_state_node(cpu_node, i - 1);
> > 		if (!state_node)
> > 			break;  
> 
> I don't see how __free() helps here. You can return regardless of __free().
> 
> > 
> > 		ret = sbi_dt_parse_state_node(state_node, &states[i]);
> > 		of_node_put(state_node);  
> 
> ... and this code is quite easy to read: you get reference and
> immediately release it.
> 
> > 
> > 		if (ret)
> > 			//another bug here on holding cpu_node btw.
> > 			return ret;
> > 		pr_debug("sbi-state %#x index %d\n", states[i], i);
> > 	}
> > //I think only path to this is is early break above.
> > 	if (i != state_count) {
> > 		ret = -ENODEV;
> > 		goto fail;
> > 	}
> > Can be something like
> > 
> > 	{
> > 		struct device_node *state_node __free(device_node) =
> > 			= of_get-cpu_State_nod(cpu_node, i - 1);
> > 	
> > 		if (!state_node)
> > 			return -ENODEV;
> > 
> > 		ret = sbi_dt_parse_state_node(state_node, &states[i]);
> > 		if (ret)
> > 			return ret;
> > 
> > 		pr_debug("sbi-state %#x index %d\n", states[i], i);
> > 	}
> > 		  
> 
> Maybe I miss something, but I do not see how the __free() simplifies
> here anything.

Personal preference.  To my eyes, it does, but indeed not a huge
advantage.

Jonathan

> 
> Best regards,
> Krzysztof
> 




More information about the linux-riscv mailing list