On Wed, 1 May 2019 01:02:15 +0200
Pavel Machek <pavel@xxxxxx> wrote:
> Hi!
>
> > >@@ -166,10 +174,19 @@ static int omnia_leds_probe(struct i2c_client *client,
> > > static int omnia_leds_remove(struct i2c_client *client)
> > > {
> > >+ u8 buf[5];
> > >+
> > > /* put all LEDs into default (HW triggered) mode */
> > > i2c_smbus_write_byte_data(client, CMD_LED_MODE,
> > > CMD_LED_MODE_LED(OMNIA_BOARD_LEDS));
> > >+ /* set all LEDs color to [255, 255, 255] */
> > >+ buf[0] = CMD_LED_COLOR;
> > >+ buf[1] = OMNIA_BOARD_LEDS;
> > >+ buf[2] = buf[3] = buf[4] = 255;
> > >+
> > >+ i2c_master_send(client, buf, 5);
> > >+
> > > return 0;
> > > }
> >
> > I wonder if we're doing right merging this driver in this form.
> > We break the rule one-led-class-device-per-one-channel.
> > We don't have LED multi color support yet, so this should support
> > RGB LEDs in the old manner. Or switch to using LED multi color
> > class.
>
> Fair point.
>
> We treat it as a white LED instead of RGB LED at this
> point. One-led-per-channel would be problematic, as hardware
> "triggers" are common for all three channels.
>
> So I thought we could go from "white" led to multicolor, when it
> becomes available, without going through One-led-per-channel...
>
> I agree this is not quite standard.
>
> Pavel
Hi,
I am aware of this issue. I plan to change the driver to multicolor led
class as soon as it is available. But from the discussions I have read
it does not seem it will be available in the next kernel release. I
would like at least full brigthness for the next release and maybe hw
triggering, for which the first version I plan to send this week...
Marek
