On Wed, Nov 29, 2023 at 11:41:51AM +0100, Heiner Kallweit wrote:
> The current codes uses the sw_control path in set_baseline_state() when
> called from netdev_trig_activate() even if we're hw-controlled. This
> may result in errors when led_set_brightness() is called because we may
> not have set_brightness led ops (if hw doesn't support setting a LED
> to ON).
Not having software on/off control of the LED is a problem. It breaks
the whole concept of offloading/accelerating. If we cannot control the
LED, there is nothing to accelerate. What do we do when the user
selects a configuration which is not supported by the hardware? The
API is not atomic, you cannot set multiple things at once. So the user
might be trying to get from one offloadable configuration to another
offloadable configuration, but needs to go via an configuration which
is not offloadable. Do we return -EOPNOTSUPP?
Before we accept patches like this, we need to discuss the concept of
how we support LEDs which cannot be controlled in software.
Andrew
