From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 15AADC433E1 for ; Sat, 11 Jul 2020 15:59:22 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D815020786 for ; Sat, 11 Jul 2020 15:59:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Ktwgo8Kv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D815020786 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ucw.cz Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=sGDEYhbG87MG4g5q4KD0MKoEqR2Q8RVfWWf7QB74p/w=; b=Ktwgo8KvhdqREMCq1Xy8AtU7i PZg+bEGLv5QjUd7Ic8Z9BIN9ByYYtjqdKWLMAywSwCV0p/NObPAz+KY8WUADWzqToVNuDsWpmakhS AqAEphtB9wjLQasHgwbgQHySvUBMCO8FT8qu/bBtVw9Uh50t5lmMYpbNRT8IWMgj/RY/+SkWC27e8 qXY93vy4wJ2uyaexcm1ydGE1BmXmwEd46UbnIr3MZwtJ9LYfWH2otCjQYmmnzZq94Rz+ux1w+dlI3 OZqhwTyLJDuSWPf/2cvFrQvzpvkG7f0rT1IkTW7p+mTQHQfNldCQZB+bVIt8QMK4+jk+/m+OYS/2J lgZa83WQQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1juHsk-0000xo-V7; Sat, 11 Jul 2020 15:57:42 +0000 Received: from jabberwock.ucw.cz ([46.255.230.98]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1juHsi-0000xJ-ET for linux-arm-kernel@lists.infradead.org; Sat, 11 Jul 2020 15:57:41 +0000 Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 1F7CE1C0BD2; Sat, 11 Jul 2020 17:57:35 +0200 (CEST) Date: Sat, 11 Jul 2020 17:57:34 +0200 From: Pavel Machek To: Dan Murphy Subject: Re: [PATCH v29 03/16] leds: multicolor: Introduce a multicolor class definition Message-ID: <20200711155734.GA21726@amd> References: <20200622185919.2131-1-dmurphy@ti.com> <20200622185919.2131-4-dmurphy@ti.com> MIME-Version: 1.0 In-Reply-To: <20200622185919.2131-4-dmurphy@ti.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200711_115740_623955_4B329D1F X-CRM114-Status: GOOD ( 19.25 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: robh@kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, jacek.anaszewski@gmail.com, linux-leds@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: multipart/mixed; boundary="===============6481316255904425175==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============6481316255904425175== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > Introduce a multicolor class that groups colored LEDs > within a LED node. > +What: /sys/class/leds//multi_intensity > +Date: March 2020 > +KernelVersion: 5.8 > +Contact: Dan Murphy > +Description: read/write > + Intensity level for the LED color within an array of integers. ? "This file contains array of integers". > + The intensities for each color must be entered based on the > + multi_index array. This does not make sense to me. "Order of components is described by the multi_index array"? > The max_intensity should not exceed "max_intensity" -> "maximum intensity"? > + /sys/class/leds//max_brightness. > +Multicolor Class Brightness Control > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > +The multicolor class framework will calculate each monochrome LEDs inten= sity. ? > +static ssize_t multi_intensity_store(struct device *dev, > + struct device_attribute *intensity_attr, > + const char *buf, size_t size) > +{ > + struct led_classdev *led_cdev =3D dev_get_drvdata(dev); > + struct led_classdev_mc *mcled_cdev =3D lcdev_to_mccdev(led_cdev); > + int nrchars, offset =3D 0; > + int intensity_value[LED_COLOR_ID_MAX]; > + int i; > + ssize_t ret; > + > + mutex_lock(&led_cdev->led_access); > + > + for (i =3D 0; i < mcled_cdev->num_colors; i++) { > + ret =3D sscanf(buf + offset, "%i%n", > + &intensity_value[i], &nrchars); > + if (ret !=3D 1) { > + dev_dbg(led_cdev->dev, > + "Incorrect number of LEDs expected %i values intensity was not appli= ed\n", > + mcled_cdev->num_colors); > + ret =3D -EINVAL; > + goto err_out; > + } > + offset +=3D nrchars; > + } > + > + /* account for the space at the end of the buffer */ > + offset++; space? I'd expect \n there. And it would be good to verify it is indeed \n, so that for example "0 0 0b" is not accepted. Please remove the dev_dbg()s that can be triggered by userspace. We don't want users spamming the logs. > +static ssize_t multi_intensity_show(struct device *dev, > + struct device_attribute *intensity_attr, > + char *buf) > +{ > + struct led_classdev *led_cdev =3D dev_get_drvdata(dev); > + struct led_classdev_mc *mcled_cdev =3D lcdev_to_mccdev(led_cdev); > + int len =3D 0; > + int i; > + > + for (i =3D 0; i < mcled_cdev->num_colors; i++) { > + len +=3D sprintf(buf + len, "%d", > + mcled_cdev->subled_info[i].intensity); > + len +=3D sprintf(buf + len, " "); We should not really put " " before newline. > +static ssize_t multi_index_show(struct device *dev, > + struct device_attribute *multi_index_attr, > + char *buf) > +{ > + for (i =3D 0; i < mcled_cdev->num_colors; i++) { > + index =3D mcled_cdev->subled_info[i].color_index; > + len +=3D sprintf(buf + len, "%s", led_colors[index]); > + len +=3D sprintf(buf + len, " "); > + } We should not really put " " before newline. > +{ > + struct led_classdev *led_cdev; > + > + if (!mcled_cdev) > + return -EINVAL; > + > + if (!mcled_cdev->num_colors) > + return -EINVAL; It is plain int, so you may want to check for <=3D 0? Or maybe make it unsigned? > +MODULE_LICENSE("GPL v2"); If your legal department allows that, GPL v2+ would be preffered (globally). > +struct mc_subled { > + int color_index; > + int brightness; > + int intensity; > + int channel; > +}; > + > +struct led_classdev_mc { > + /* led class device */ > + struct led_classdev led_cdev; > + int num_colors; > + > + struct mc_subled *subled_info; > +}; Would some "unsigned"s make sense here to cut number of corner cases? Best regards, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --huq684BweRXVnRxX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAl8J4W4ACgkQMOfwapXb+vKH+QCeKT1Udif6m7xNGEBzvGZd+FuN MBoAoIoLjg2c6JgcTC4sA+OJgOAaBnuQ =lZ/X -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- --===============6481316255904425175== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============6481316255904425175==--