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 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0F1E0D1A627 for ; Fri, 9 Jan 2026 13:33:46 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7F60710E8D1; Fri, 9 Jan 2026 13:33:45 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="q0JTTK0S"; dkim-atps=neutral Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by gabe.freedesktop.org (Postfix) with ESMTPS id ABB9F10E8CC for ; Fri, 9 Jan 2026 13:33:43 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 9AC4860053; Fri, 9 Jan 2026 13:33:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59E4DC4CEF1; Fri, 9 Jan 2026 13:33:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767965622; bh=LQUyd3vGywKl1tt4v7FTaee6X195SbdF/LwGioPgO0Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=q0JTTK0SuScg/iiVRITNJPgQhFo6wCicXuq1pTQJFV7I1QNAIOscrK/4nmMlMUjhv egOcy2OCsl9Y/M2qRjS4xH6T8+59mTV7cgy5gUporGVkhrmi5kVywyaz/vF+ez3oSx VmJRDxYVTEXJ5q9cnOQARgiEyc/kp0KWOfynaVrIKS94NZN4scnMO0uBRYQYhH0j0E QkO9qXdiSigxFXQVW79rdOsIWC/20vwe/uVE0FTofU99jIldVz7VMlwcJOmmPL8QjN EYfeE1cnHnuREL8qBFSW1zH0bqB0tJPQQ7HrkGiyQlXoR9eWeTgzBMrgENx917rHOZ 1F0akGT210qAQ== Date: Fri, 9 Jan 2026 13:33:35 +0000 From: Daniel Thompson To: Konrad Dybcio Cc: barnabas.czeman@mainlining.org, Lee Jones , Jingoo Han , Pavel Machek , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Bjorn Andersson , Kiran Gunda , Helge Deller , Luca Weiss , Konrad Dybcio , Eugene Lepshy , Gianluca Boiano , Alejandro Tafalla , dri-devel@lists.freedesktop.org, linux-leds@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-fbdev@vger.kernel.org Subject: Re: [PATCH v2 2/7] backlight: qcom-wled: Support ovp values for PMI8994 Message-ID: References: <20260108-pmi8950-wled-v2-0-8687f23147d7@mainlining.org> <20260108-pmi8950-wled-v2-2-8687f23147d7@mainlining.org> <67acbe8ff2496e18a99165d794a7bae8@mainlining.org> <0fe51f7f-9b77-4bff-ab1c-21c44a863a7a@oss.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0fe51f7f-9b77-4bff-ab1c-21c44a863a7a@oss.qualcomm.com> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Jan 09, 2026 at 12:09:11PM +0100, Konrad Dybcio wrote: > On 1/9/26 7:36 AM, barnabas.czeman@mainlining.org wrote: > > On 2026-01-08 12:28, Daniel Thompson wrote: > >> On Thu, Jan 08, 2026 at 04:43:20AM +0100, Barnabás Czémán wrote: > >>> WLED4 found in PMI8994 supports different ovp values. > >>> > >>> Fixes: 6fc632d3e3e0 ("video: backlight: qcom-wled: Add PMI8994 compatible") > >>> Reviewed-by: Konrad Dybcio > >>> Signed-off-by: Barnabás Czémán > >>> --- > >>>  drivers/video/backlight/qcom-wled.c | 41 +++++++++++++++++++++++++++++++++++-- > >>>  1 file changed, 39 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/drivers/video/backlight/qcom-wled.c b/drivers/video/backlight/qcom-wled.c > >>> index a63bb42c8f8b..5decbd39b789 100644 > >>> --- a/drivers/video/backlight/qcom-wled.c > >>> +++ b/drivers/video/backlight/qcom-wled.c > >>> @@ -1244,6 +1244,15 @@ static const struct wled_var_cfg wled4_ovp_cfg = { > >>>      .size = ARRAY_SIZE(wled4_ovp_values), > >>>  }; > >>> > >>> +static const u32 pmi8994_wled_ovp_values[] = { > >>> +    31000, 29500, 19400, 17800, > >>> +}; > >>> + > >>> +static const struct wled_var_cfg pmi8994_wled_ovp_cfg = { > >>> +    .values = pmi8994_wled_ovp_values, > >>> +    .size = ARRAY_SIZE(pmi8994_wled_ovp_values), > >>> +}; > >>> + > >> > >> Do these *have* to be named after one of the two PMICs that implement > >> this OVP range. > >> > >> Would something like wled4_alternative_ovp_values[] (and the same > >> throughout the patch) be more descriptive? > > I don't know. I don't like the PMIC naming either but at least it > > descriptive about wich PMIC is needing these values. It's the descriptive but wrong element I dislike (pmi8994_wled_ovp_cfg is used by pmi8550). I know these things crop up for "historical reasons" when is appears in the same patchset I have to question the naming. > > I think PMIC naming would be fine if compatibles what representing the > > same configurations would be deprecated and used as a fallback compatbile > > style. > > I mean we could kept the first added compatible for a configuration. > > Maybe they should be named diferently i don't know if WLEDs have subversion. > > Every PMIC peripheral is versioned. > > WLED has separate versioning for the digital and analog parts: > > PMIC ANA DIG > --------------------------- > PMI8937 2.0 1.0 (also needs the quirk) > PMI8950 2.0 1.0 > PMI8994 2.0 1.0 > PMI8996 2.1 1.0 > PMI8998 3.1 3.0 > PM660L 4.1 4.0 > > I don't know for sure if "PMIC4 with WLED ANA/DIG 3.x" a good > discriminant though.. Peronally I'd prefer that to making them all use pmi8994 structures. It's a much better link back to the docs (at least for those with the power to read them ;-) ). Daniel.