Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp4693730pxb; Tue, 5 Oct 2021 08:24:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw+FEzUgFRsalJnDD2wVhtzy5l/71D+RuTWv9Xo5r7gsAnXB8WfCUIG0+CsXXjJ394pXPT4 X-Received: by 2002:a63:ec06:: with SMTP id j6mr16252877pgh.259.1633447487807; Tue, 05 Oct 2021 08:24:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633447487; cv=none; d=google.com; s=arc-20160816; b=iQ+Nmr1Zb1mmHvHSwZT7mhfvDSx1pHEKLeOydikdmvXIW2x15GCzZ071S7zWAX1Pzz VwBEJ4tQkHqQ6o2XoWh2pWph1bh9JEq1gciWNyaBsUfhNPhBGB+2Sdi2gnyLMMxHPB5N cTT8sl2vSJXGZvGYejsbsYu495XgWcQo5RzxED3nJBDXaPb2fTDwpmUsSAONUvQWeU5i JVanJdikxchTykNU43mz7q9g3qMa9HxcCCl0pxpu3A8GTnqbIjW0XPTCxjGZXwiuflYp l7qxS9GC0QOM2nxTjpex53Zt2qO2BZdQp8nW/mkUJjlWo9u/uepAzHRepUTF3wcBlcZk J9hA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:mail-followup-to:message-id:subject:cc:to:from:date; bh=fVJl3Hoq4paFxcJKagDTCRqX6tB/C6mY4Vj72vfhcx4=; b=LlfF9N+7iCjDVg7LTqHgXdTHvgqnaT6hwcvJ1hLePW/6a/zDhLdpbWQIXtmFzZPvGx BufPOprZEq3rDDzU4e4OY4+UBmX1QoBVgcp7SPUgLlLulvOgmA51q+5HIlX+WIbulmwU ET90qOIpyCAsPDI3RtFzvlogMXRNticp2SNlmDOXYbsEwmG7Itm6dfbE4umPmQAAu/Gn Q4G506zVVJJ4WEtHHeqOHOA4mOVJDyPQ4FXKSSe3+MDJMHAjfG98QnqYNjifiQ1R+hpU fuUUejeVacaCX3ARhv2cYJ8f5hHHOyWZmoc2h/N69X3bAAaVcIENhygBqIhsr2X5HaiF ieNA== 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 x5si22585218pga.241.2021.10.05.08.24.34; Tue, 05 Oct 2021 08:24:47 -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 S235968AbhJEPZU (ORCPT + 99 others); Tue, 5 Oct 2021 11:25:20 -0400 Received: from m-r2.th.seeweb.it ([5.144.164.171]:35717 "EHLO m-r2.th.seeweb.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235951AbhJEPZT (ORCPT ); Tue, 5 Oct 2021 11:25:19 -0400 Received: from SoMainline.org (94-209-165-62.cable.dynamic.v4.ziggo.nl [94.209.165.62]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by m-r2.th.seeweb.it (Postfix) with ESMTPSA id 5D90B3E8D8; Tue, 5 Oct 2021 17:23:27 +0200 (CEST) Date: Tue, 5 Oct 2021 17:23:26 +0200 From: Marijn Suijten To: Daniel Thompson Cc: phone-devel@vger.kernel.org, Andy Gross , Bjorn Andersson , Lee Jones , Jingoo Han , ~postmarketos/upstreaming@lists.sr.ht, AngeloGioacchino Del Regno , Konrad Dybcio , Martin Botka , Jami Kettunen , Pavel Dubrova , Kiran Gunda , Courtney Cavin , Bryan Wu , linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 05/10] backlight: qcom-wled: Fix off-by-one maximum with default num_strings Message-ID: <20211005152326.5k5cb53ajqnactrg@SoMainline.org> Mail-Followup-To: Marijn Suijten , Daniel Thompson , phone-devel@vger.kernel.org, Andy Gross , Bjorn Andersson , Lee Jones , Jingoo Han , ~postmarketos/upstreaming@lists.sr.ht, AngeloGioacchino Del Regno , Konrad Dybcio , Martin Botka , Jami Kettunen , Pavel Dubrova , Kiran Gunda , Courtney Cavin , Bryan Wu , linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20211004192741.621870-1-marijn.suijten@somainline.org> <20211004192741.621870-6-marijn.suijten@somainline.org> <20211005091947.7msztp5l554c7cy4@maple.lan> <20211005100606.faxra73mzkvjd4f6@SoMainline.org> <20211005103843.heufyonycnudxnzd@maple.lan> <20211005105312.kqiyzoqtzzjxayhg@maple.lan> <20211005114435.phyq2jsbdyroa6kn@SoMainline.org> <20211005140349.kefi26yev3gy3zhv@maple.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211005140349.kefi26yev3gy3zhv@maple.lan> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-10-05 15:03:49, Daniel Thompson wrote: [..] > > I much prefer doing that instead of trying to wrangle enumeration > > parsing around integer values that are supposed to be used as-is. After > > all this variable is already named to set the `+ 1` override currently, > > and `qcom,enabled_strings` has "custom" handling as well. I'll extend > > the validation to ensure num_strings>=1 too. > > Great. > > > > In addition, and this needs some investigation on the dt-bindings side > > too, it might be beneficial to make both properties mutually exclusive. > > When specifying qcom,enabled_strings it makes little sense to also > > provide qcom,num_strings and we want the former to take precedence. > > If we are designing a "fix" for that then my view is that if both are > passed then num-strings should take precedence because it is an > explicit statement about the number of strings where enabled_strings > is implicit. In other words, if num-strings <= len(enabled_strings) then > we should do what we are told, otherwise report error. IMO both should be identical (num-strings == len(enabled-strings)) to avoid ambiguity, but do read on. > > At that point one might ask why qcom,num_strings remains at all when > > DT can use qcom,enabled_strings instead. We will supposedly have to > > keep backwards compatibility with DTs in mind so none of this can be > > removed or made mutually exclusive from a driver standpoint, that all > > has to be done in dt-bindings yaml to be enforced on checked-in DTs. > > So... perhaps I made a make offering a Reviewed-by: to a patch > that allows len(enabled-strings) to have precedence. If anything > currently uses enabled-strings then it *will* be 4 cells long and > is relying on num-strings to ensure the right things happens ;-) . Unfortunately Konrad (one of my team members) landed such a patch at the beginning of this year because I failed to submit this patchset in time while it has been sitting in my queue since 2019 after being used in a downstream project. This is in pmi8994 which doesn't have anything widely used / production ready yet, so I'd prefer to fix the DT instead and remove / fix his comment: /* Yes, all four strings *have to* be defined or things won't work. */ But this is mostly because, prior to this patchset, no default was set for WLED4 so the 0'th string would get enabled num-strings (3 in pmi8994's case) times. Aside that there's only one more PMIC (also being worked on by SoMainline) that sets qcom,enabled-strings: this is pm660l, pulled from our local tree, and it actually has enabled-strings of length 2 which is broken in its current form, exactly because of relying on this patchset. Finally, we already discussed this inside SoMainline and the number/enabled leds should most likely be moved out of the PMIC dtsi's as they're probably panel, hence board or even device dependent. > We'd like that case to keep working so we must allow num-strings to have > precedence. In other words, when you add the new code, please put it at > the end of the function! Since there don't seem to be any substantial platforms/PMICs using this functionality in a working manner, can I talk you into agreeing with fixing the DT instead? PS. In -next pmi8994_wled is only enabled for sony-xperia-tone, and pm660l_wled has yet to be enabled by anything. - Marijn