Re: [PATCH v4 7/7] riscv: dts: ultrarisc: Add Milk-V Titan board device tree

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]

On Tue, Oct 20, 2026 at 09:43:59AM +0800, Xincheng Ji wrote:
> Hi,
> 
> On 2026-10-19 08:08 +0000, sashiko-bot@kernel.org wrote:
> > Should the label properties be dropped from led@1 and led@2 here?
> > 
> > When the PHY driver probes phy0, the call chain:
> > 
> >   of_phy_leds() ->
> >     of_phy_led() ->
> >       devm_led_classdev_register_ext() ->
> >         led_classdev_register_ext() ->
> >           led_compose_name() ->
> >             led_parse_fwnode_props()
> > 
> > checks for the deprecated label property first in
> > drivers/leds/led-core.c:led_parse_fwnode_props():
> > 
> > 	if (fwnode_property_present(fwnode, "label")) {
> > 		ret = fwnode_property_read_string(fwnode, "label", &props->label);
> > 		if (ret)
> > 			dev_err(dev, "Error parsing 'label' property (%d)\n", ret);
> > 		return;
> > 	}
> > 
> > Because led_parse_fwnode_props() returns early when label is present, the
> > color and function properties on led@1 and led@2 are never parsed and are
> > completely ignored at runtime.
> > 
> > In addition, Documentation/devicetree/bindings/leds/common.yaml deprecates
> > label for new bindings in favor of color and function.
> > 
> > Would it make sense to remove label from both nodes so that the LED core
> > uses color and function to compose the standard LED names?
> > 
> Thank you for the review. I understand that label is deprecated in favor
> of color and function.Since the LED core still supports parsing label, 
> would you consider removing these properties necessary for this patch,
> or more of a naming convention cleanup?

You're asking a bot that will never reply to you.

I'd say that if the analysis provided is correct, then yes you should
since the deprecated property overrides the replacement properties.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]