Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2662789imm; Fri, 24 Aug 2018 03:13:14 -0700 (PDT) X-Google-Smtp-Source: ANB0VdbFbLJOSggvo4KXbRsIdBrNCUcwGX2h4mDM3IkbvsrkU22TOXmBiaWIV+lI8GHakxjl+d5W X-Received: by 2002:a17:902:1001:: with SMTP id b1-v6mr1050138pla.155.1535105594186; Fri, 24 Aug 2018 03:13:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535105594; cv=none; d=google.com; s=arc-20160816; b=AbiFumfL/bpO+QDCdIh6U/J/Raa0TGKO06lOf3/SMHjet3sUd+WeLjFShC8NwwztoZ z43i2d3gxmbyZnjmOyZn5Wklp4zibuKrDVCxzjF/gV/aM+kXP9fFd6wlfnP5jYJeNau5 hymHCyeX9EYENG/KGpMU5ep7fxMj2p/ysc8/dVqXpPF5H1Ud5XW6dUZf3NmxaTtjCnU7 KoMpq9ej725Eq/gqmMBzwxnBbEsVdBrip1zLxESiZS8Msn+0XQ+dAmpdSxecwikG+TXT aPQMkVFU23fr1voYYouxyJ3BEyi5OFsTJfzkl17Gkj/lhpjqW4t7vnKLbebrxDjlQMVe CZyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=bg4w/BYTlfFal1zosdwE3BDE6tyLLxKzVQIaM7vIo9g=; b=pNzQYzci3UD1M/L736hu3HcFtHaewbgnEeYSAUNcIHrjze9j2esRh2fbNBmxX43BSa Z3wWgbdx3rKbZomaADy7xLhfx0a9YF7WDZaUYYIYmSbRJ4lw8yLOqxR+sbp4DbjgcgCD PCFzpdp0M/5s9nEtJZndpiuZTmH+uPnZ389A+zYdKBR/YeiNjcWZLBL3QGolyK8pCc2A Pk4Hx6D2KC0YLWCOhNTjb1putWyrTelN1sLbCJ7mW0755h50qRHEGYHBxFqXAOdvtRXw 1ghCIeZLW1WHSxfT9j3pNAovI8eyZllHgyEZtaxf1u6jp/e1aPq3VVLgNzqW7c7CEHW7 v8IQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x18-v6si6341098pll.88.2018.08.24.03.12.58; Fri, 24 Aug 2018 03:13:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726573AbeHXNpt (ORCPT + 99 others); Fri, 24 Aug 2018 09:45:49 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:36117 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726243AbeHXNpt (ORCPT ); Fri, 24 Aug 2018 09:45:49 -0400 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id 924EE83DF6; Fri, 24 Aug 2018 12:11:50 +0200 (CEST) Date: Fri, 24 Aug 2018 12:11:45 +0200 From: Pavel Machek To: Jacek Anaszewski Cc: Baolin Wang , rteysseyre@gmail.com, bjorn.andersson@linaro.org, broonie@kernel.org, linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 1/2] leds: core: Introduce LED pattern trigger Message-ID: <20180824101145.GA1510@amd> References: <1dc5d394324b2bf1ffe229b8e42691fab6d749e0.1533556992.git.baolin.wang@linaro.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > I think that it would be more flexible if software pattern fallback > was applied in case of pattern_set failure. Otherwise, it would > lead to the situation where LED class devices that support hardware > blinking couldn't be applied the same set of patterns as LED class > devices that don't implement pattern_set. The latter will always have to > resort to using software pattern engine which will accept far greater > amount of pattern combinations. >=20 > In this case we need to discuss on what basis the decision will be > made on whether hardware or software engine will be used. >=20 > Possible options coming to mind: > - an interface will be provided to determine max difference between > the settings supported by the hardware and the settings requested by > the user, that will result in aligning user's setting to the hardware > capabilities > - the above alignment rate will be predefined instead > - hardware engine will be used only if user requests supported settings > on the whole span of the requested pattern > - in each of the above cases it would be worth to think of the > interface to show the scope of the settings supported by hardware I'd recommend keeping it simple. We use hardware engine if driver author thinks pattern is "close enough". If human can not tell the difference, it probably is. We may want to do something more formal later. Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlt/2eEACgkQMOfwapXb+vKtBgCgp15fsv7FX679nW0h33YTmU70 KqwAoLsWGFNPvDCFIabrzTu9n1dvfmgM =KBsf -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb--