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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A8E3C433EF for ; Wed, 6 Oct 2021 14:44:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 06E23610C8 for ; Wed, 6 Oct 2021 14:44:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238226AbhJFOqn (ORCPT ); Wed, 6 Oct 2021 10:46:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231776AbhJFOql (ORCPT ); Wed, 6 Oct 2021 10:46:41 -0400 Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4A840C061755 for ; Wed, 6 Oct 2021 07:44:49 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id m22so9687545wrb.0 for ; Wed, 06 Oct 2021 07:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=D8IjD/aX+SAqkEjm7xgEe5lxocD/PXw4l5YWyLqfbtc=; b=sjymcv1htUJfHr/ek8Mjj/Jzt/jL4wvmG/taOYRNvKcZWk9BkgQtJjHgO7wbXBFrHy meZmY5A0tTIXo7CrDb1wtV1kVUe0zpcretTP/oJR1dUYtCogFfD4itlw7SlETG69n6Xi cRM1/7X/fYoubACDyBPEiCkkKuAUi0hY2aAzKxEFA/nDteTiuhRMStnHbhpfANKS6SOo aZ2uU5GuqODutpS9OMjadts9W8OOjuOAgFSiKeYSCLDwsbW9Cov/zeNYAJFIXp8iKB4R qB3jLqqhLJY0SdzrfSgr+y6OWem7CqBIbjFWChJaTT0M0IN9Rp0D7UjF4OBKnk8d1pUl rGUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=D8IjD/aX+SAqkEjm7xgEe5lxocD/PXw4l5YWyLqfbtc=; b=qOvwOLUV94L3iLG7JmAjyA2Urx1eQ89ZivkSawR2uSPrWw66KFAlcr1M286p33nLoI Uy1P+N1NbRJo/VzhZSTVG3l64FjPticckbTJpWDSsg5a0vyN5fQbnolXR0VfIzbKO2eX 1E7XPQSC/pKhD+ixyIQ7TsSezQ2PvemjEA7CUypneo8PswJNEiTvpGZQA4L7nE1aV/ES Xo79Hlt50mi2EEYcPRC6xGTmXUZWh69MUx713Ey4dwUQJnmtiPD6K7Ez3x7l/4ZYq8bW QQMrrkb3aUEOdsalnST8a9Mp4c2AqJB6ixmNWRXfHFxtNVzXdtL4fT418CM5ZJpwrzgP jhVg== X-Gm-Message-State: AOAM532aayHCsKy3zNRE6V2BjZ9cVAIbcp2U9G7a3afay3sZRuUpErX1 GjZWNH8gKxCoVCqZk9a5ep1+4w== X-Google-Smtp-Source: ABdhPJzOIM/pk9tWOTUWl5e+TDTH0xpNOQTnfj4KEfoU6EtOZONtFMHK6lwbDtQM4rXB6YpRldnDdg== X-Received: by 2002:a1c:5413:: with SMTP id i19mr10372676wmb.31.1633531487682; Wed, 06 Oct 2021 07:44:47 -0700 (PDT) Received: from maple.lan (cpc141216-aztw34-2-0-cust174.18-1.cable.virginm.net. [80.7.220.175]) by smtp.gmail.com with ESMTPSA id f7sm3104178wmj.20.2021.10.06.07.44.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Oct 2021 07:44:46 -0700 (PDT) Date: Wed, 6 Oct 2021 15:44:44 +0100 From: Daniel Thompson To: Marijn Suijten 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: <20211006144444.6q3qm3bzfrhzwa46@maple.lan> References: <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> <20211005152326.5k5cb53ajqnactrg@SoMainline.org> <20211005162453.ozckxhm47jcarsza@maple.lan> <20211005173400.lyu3gabbalv2l3uq@SoMainline.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211005173400.lyu3gabbalv2l3uq@SoMainline.org> Precedence: bulk List-ID: X-Mailing-List: phone-devel@vger.kernel.org On Tue, Oct 05, 2021 at 07:34:00PM +0200, Marijn Suijten wrote: > On 2021-10-05 17:24:53, Daniel Thompson wrote: > > On Tue, Oct 05, 2021 at 05:23:26PM +0200, Marijn Suijten wrote: > > > 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? > > > > I've no objections to seeing the DT updated. However I don't really see > > what benefit we get from breaking existing DTs in order to do so. > > > > "Cleaning up annoying legacy" is seldom a good reason to break existing > > DTs since, if we could break DTs whenever we choose, there would never > > be any annoying legacy to worry about. When conflicting properties > > result in uninterpretable DTs then a break may be justified but that is > > not the case here. > > As mentioned in my message and repeated by Konrad, the only "existing > DT" that could possibly be broken is a platform that's brought up by us > (SoMainline) and we're more than happy to improve the driver and leave > legacy DT behind us, unless there's more DT in circulation that hasn't > landed in Linux mainline but should be taken into account? Devicetrees are supposed to be the domain of firmware (e.g. not part of the kernel). I'm therefore reluctant to adopt an "it only exists if it is upstream" approach for documented DT bindings. Doubly so when it is our bugs that causes DTs to be written in a manner which we then retrospectively declare to be wrong. > Anyway the plan is to leave qcom,num-strings in place so that the > default enabled_strings list in this driver actually serves a purpose. > Then, if num-strings and enabled-strings is provided the former has > precedence (assuming it doesn't exceed the size of the latter) but > we'll print a warning about this (now unnecessary) ambiguity, and if > possible at all - haven't found an example yet - make the properties > mutually exclusive in dt-bindings. > > Disallowing both cases would only simplify the code in the end but we > can spend a few lines to support the desired legacy. Yes, warning is OK for me. Daniel.