Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp463924pxu; Tue, 6 Oct 2020 10:30:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz8dnmtkiVd+3uXOqekWLNjWBnu+uTcqcnGo4w+sn3iwMaHB03IOQHo6bphQHbRQdo/yxif X-Received: by 2002:a17:906:1152:: with SMTP id i18mr622649eja.101.1602005419488; Tue, 06 Oct 2020 10:30:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602005419; cv=none; d=google.com; s=arc-20160816; b=CeRPaScrvjcjCChI6UHL3dRYhyMggcghIygaCKzEL1UW7V7Hie0611y12GwfjAxwzm Nuk8+Bsbqu2Ke3XFL5LK7uRYNHf1cr7GBir5dT13GUHHswZjsRaU/gitqIAp+kriR2XA MczpnLQ1+Avx+vEf4HlcjWKF3ItP+dqWPeJABrPfCNqPEMsEQC/NlOMx49f4mqJrZHTx DH1qsOnDSi/n3nvKsAoH5I5QHP52I4jsKeQpwMmGJjQkgpDk4DzAio3hPyjADgfaxDhl 0EshE+LSThQlljEXCMcjlDley6XqRMM0td5IiPnOAl8gyVjYbyVVNbkRSPFO46KB3HdL DVyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=FrSCuHqKqJ2HzqbLpElyu4MYYzH67ZFFr8qWykOtqC4=; b=g0u3IRN7kO+7bzwUFUbDgr5egk8qoYzTHvAEncUWtaXtHjfYmntrVayATeH1dngmze GT1MSbmNS1f11NC+XNLaAETuoAmL8QecXWQywQ0ws+658sYK/L/Q/tpeU5rPHhOyau/P 6MNGx8sin3sUqxmgfXuCnlyz6llMS7AIO/+WigNd2VI9losv7DJkfwsFjx076lkavnvz 9qeNbkwCPfDXEfbKOC3qUKw3qScvipMlhe5ZSG9na5E5FY27v40avVQ9sjMc/A42pN47 j+cSOsPOSrjXdWMECX51XvlWcBQJSwVBWCJU/0B40zo998GTg7kKHGEndEn0juo20oEa jWGQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u20si2439419ejt.14.2020.10.06.10.29.54; Tue, 06 Oct 2020 10:30:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726100AbgJFR03 (ORCPT + 99 others); Tue, 6 Oct 2020 13:26:29 -0400 Received: from jabberwock.ucw.cz ([46.255.230.98]:55150 "EHLO jabberwock.ucw.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725902AbgJFR02 (ORCPT ); Tue, 6 Oct 2020 13:26:28 -0400 Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 08C401C0B8B; Tue, 6 Oct 2020 19:26:26 +0200 (CEST) Date: Tue, 6 Oct 2020 19:26:10 +0200 From: Pavel Machek To: Marek Behun Cc: Dan Murphy , ultracoolguy@tutanota.com, Linux Leds , Linux Kernel , Rob Herring , devicetree@vger.kernel.org Subject: Re: [PATCH] leds: lm3697: Fix out-of-bound access Message-ID: <20201006172610.GA1836@duo.ucw.cz> References: <966c3f39-1310-dd60-6f33-0d9464ed2ff1@ti.com> <20201005164808.slrtmsvmw4pvwppm@falbala.internal.home.lespocky.de> <20201005173227.GA6431@duo.ucw.cz> <20201006093356.6d25b280@blackhole.sk> <144aa75a-4369-cd81-d7dc-2354a9afd7c5@ti.com> <20201006164101.2c3fa0d7@blackhole.sk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <20201006164101.2c3fa0d7@blackhole.sk> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > > >> By the way I just realized that the DT binding in this driver seems > > >> incorrect to me. > > >> > > >> The controller logically supports 3 LED strings, each having > > >> configurable control bank. =20 > >=20 > > There are two control banks. You can connect the HVLED outputs to eithe= r=20 > > control bank A or B there is no individual control of the LED strings. > >=20 > >=20 > > >> But the DT binding supports 2 DT nodes, one for each control bank > > >> (identified by the `reg` property) and then `led-sources` says which > > >> string should be controlled by given bank. > > >> > > >> But taking in mind that DT should describe how devices are connected= to > > >> each other, I think the child nodes in the binding should instead > > >> describe the 3 supported LED strings... =20 > >=20 > > The outputs in this case are virtual outputs which are the banks (A and= B). > >=20 > > Since the device is bank controlled the actual current sinks are not=20 > > defined thus making the the banks the actual outputs. > >=20 > > This is why the 'reg' property defines the control bank either A or B= =20 > > and the led-sources indicates the strings associated with the control b= ank. > Dan, I looked at the datasheet, I understand this. >=20 > Nonetheless, device tree should describe how devices are connected to > each other. The chip has 3 pins for 3 LED strings. Well, device tree is not a device schematics... > If this controller should be able to support 3 LED strings via 3 > outputs, the device tree binding nodes should, in my opinion, describe > each pin connected string. The nodes should maybe even be called > 'led-string@N' where N is from [0, 1, 2]. >=20 > The fact that the device is bank controlled and there are only two > banks (and it is configurable by which bank each LED string is > controlled) is more relevant to the driver, not as much to device tree > binding. Seems to me like two independend LEDs, and I'd describe it as such. The fact that it goes over 3 wires is just a implementation detail. Lets keep it simple... Best regards, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCX3yosgAKCRAw5/Bqldv6 8sF6AJ9djAsB19pw03xFkkLaSd7uT/tGFQCgoXaT2KSu0s7VLgQyScGaV1t+698= =4/S2 -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO--