> > +qca8k_cled_trigger_offload(struct led_classdev *ldev, bool enable)
> > +{
> > + struct qca8k_led *led = container_of(ldev, struct qca8k_led, cdev);
> > +
> > + struct qca8k_led_pattern_en reg_info;
> > + struct qca8k_priv *priv = led->priv;
> > + u32 val = QCA8K_LED_ALWAYS_OFF;
> > +
> > + qca8k_get_enable_led_reg(led->port_num, led->led_num, ®_info);
> > +
> > + if (enable)
> > + val = QCA8K_LED_RULE_CONTROLLED;
> > +
> > + return regmap_update_bits(priv->regmap, reg_info.reg,
> > + GENMASK(1, 0) << reg_info.shift,
> > + val << reg_info.shift);
>
> 88e151x doesn't have the ability to change in this way - we have
> a register with a 4-bit field which selects the LED mode from one
> of many, or forces the LED on/off/hi-z/blink.
>
> Not specifically for this patch, but talking generally about this
> approach, the other issue I forsee with this is that yes, 88e151x has
> three LEDs, but the LED modes are also used to implement control
> signals (e.g., on a SFP, LOS can be implemented by programming mode
> 0 on LED2 (which makes it indicate link or not.) If we expose all the
> LEDs we run the risk of the LED subsystem trampling over that
> configuration and essentially messing up such modules. So the Marvell
> PHY driver would need to know when it is appropriate to expose these
> things to the LED subsystem.
>
> I guess doing it dependent on firmware description as you do in
> this driver would work - if there's no firmware description, they're
> not exposed.
>
I expect there will always be some sort of firmware involved,
describing the hardware. Without that, we have no idea how many LEDs
are actually connected to pins of the PHY, for example.
I've not yet looked at this patchset in detail, but i hope the DT
binding code is reusable, so all PHYs will have the same basic
binding.
Andrew
