On Tue, Nov 09, 2021 at 09:34:23PM +0100, Andrew Lunn wrote: > On Tue, Nov 09, 2021 at 03:26:01AM +0100, Ansuel Smith wrote: > > Some LEDs can be driven by hardware (for example a LED connected to > > an ethernet PHY or an ethernet switch can be configured to blink on > > activity on the network, which in software is done by the netdev trigger). > > > > To do such offloading, LED driver must support this and a supported > > trigger must be used. > > > > LED driver should declare the correct blink_mode supported and should set > > the blink_mode parameter to one of HARDWARE_CONTROLLED or > > SOFTWARE_HARDWARE_CONTROLLED. > > The trigger will check this option and fail to activate if the blink_mode > > is not supported. By default if a LED driver doesn't declare blink_mode, > > SOFTWARE_CONTROLLED is assumed. > > > > The LED must implement 3 main API: > > - trigger_offload_status(): This asks the LED driver if offload mode is > > enabled or not. > > Triggers will check if the offload mode is supported and will be > > activated accordingly. If the trigger can't run in software mode, > > return -EOPNOTSUPP as the blinking can't be simulated by software. > > I don't understand this last part. The LED controller is not > implementing software mode, other than providing a method to manually > turn the LED on and off. And there is a well defined call for that. If > that call is a NULL, it is clear it is not implemented. There is no > need to ask the driver. > > Andrew You are right I have to remove the last part as it doesn't make sense. We already use blink_mode. Will remove in v4. -- Ansuel
