lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180903215323.GA21489@amd>
Date:   Mon, 3 Sep 2018 23:53:23 +0200
From:   Pavel Machek <pavel@....cz>
To:     Jacek Anaszewski <jacek.anaszewski@...il.com>
Cc:     bjorn.andersson@...aro.org, Baolin Wang <baolin.wang@...aro.org>,
        rteysseyre@...il.com, broonie@...nel.org, linus.walleij@...aro.org,
        linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 1/2] leds: core: Introduce LED pattern trigger

Hi!

> > +static int pattern_trig_start_pattern(struct led_classdev *led_cdev)
> > +{
> > +	struct pattern_trig_data *data = led_cdev->trigger_data;
> > +
> > +	if (!data->npatterns)
> > +		return 0;
> > +
> > +	if (data->is_hw_pattern) {
> > +		return led_cdev->pattern_set(led_cdev, data->patterns,
> > +					     data->npatterns, data->repeat);
> > +	}
> 
> I have doubts here if it is a good idea to enforce array of tuples
> as a generic interface for all hw_patterns. It may not fit well for
> every hw pattern engine. It seems that the only feasible solution will
> be allowing drivers to come up with their own interfaces, i.e. the
> approach you proposed at first for your driver. It seems that the
> ledtrig-pattern with software pattern mechanism will be just
> a nice side effect of this series :-)
> 
> Unless someone will propose a better solution.

I believe array of tuples will work for everyone. It is just a LED, it
can change intensity over time.

> We need a broader consensus here. I'd like to hear Pavel's opinion,
> since he's been always in favor of common pattern interface, and
> inspired this work.

I believe Baolin did good work here. I believe it will cover most, if
not all, hardware engines out there. I think we should merge it, and
see what happens -- it should be good enough.

(Yes, there's still more work to do, but that will be stuff like RGB
LED synchronization.)

(And yes, one of the LED chip has pattern engine that can compute
prime numbers on its own. I don't expect to support
_that_. Fortunately, nobody but me is likely to want that pattern, so
we are still okay :-) 

https://gitlab.com/tui/tui/blob/master/ofone/tests.notcc/primes.nc

)
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ