Re: [RFC PATCH 1/2] leds: core: Add support for led-instance property

[Andriy Shevencho <andriy.shevchenko@linux.intel.com>]

On Sun, Dec 28, 2025 at 06:43:18PM +0000, Jonathan Brophy wrote:
> >But this will be called unconditionally even if the
> 
> >function/function-enumerator is present. Wouldn't these be conflicting options?
> >
> Good point! You're right that function-enumerator and led-instance could
> conflict. I'll make them mutually exclusive.
> 
> The semantic difference is:
> - function-enumerator: Numeric instances (0, 1, 2...) ^[$B"*^[(B "lan:green-5"
> - led-instance: Semantic instances ("port23") ^[$B"*^[(B "lan:green:port23"
> 
> Having both would create "lan:green-5:port23" which is confusing.
> 
> I can add validation to reject DT nodes that specify both:
> 
>   if (props->func_enum_present && instance) {
>       dev_err(dev, "'led-instance' and 'function-enumerator' are mutually exclusive\n");
>       return -EINVAL;
>   }

Dunno. Maybe Lee can comment and/or suggest on this...

> And document this in the DT binding:
> 
>   "This property cannot be used together with function-enumerator.
>    Use function-enumerator for numeric instances (0, 1, 2) or
>    led-instance for semantic instances (port0, battery, usb)."
> 
> would this be ok ?

In DT as far as I know the special syntax is used for the mutually exclusive
properties. But not an expert, better to wait the answer by DT people.

-- 
With Best Regards,
Andy Shevchenko