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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D4EB4C77B73 for ; Sat, 15 Apr 2023 16:49:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229630AbjDOQtq (ORCPT ); Sat, 15 Apr 2023 12:49:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56350 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229468AbjDOQtq (ORCPT ); Sat, 15 Apr 2023 12:49:46 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 52245E1; Sat, 15 Apr 2023 09:49:45 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E14D86118B; Sat, 15 Apr 2023 16:49:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22A85C433EF; Sat, 15 Apr 2023 16:49:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681577384; bh=HzfT7C9pxZUKfBOzD0bn0wIBd5ovSSU49etyxQMRn4s=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=aBYgLqucsTTarCKTBL3wdnwg6i8sqBa804UW2EET+CKcXHntwF3129XIKFpOEhB74 5bj5xri8We8v9A+D08305ckbNN91Rtfm/Gr4W4awR6XD0C8iqS7/HvhON+nfc80uYB Y9ykEn/YDDdsiwALjAy4XMLfafRnUV6reZ8hliEb1BeCr7M+sHsS4C2R6Yf+jpOGVX 1AcI3IbBksAxbLurcRqzVEeLm0z9G7JHmwE5q536S1/xasJpntZaTWZKzEnDRR4EVC YjIrBDvqauhSg5VPr2ahuQM9ByvNSG34ccFZMG+Ts6vgDM34WH4eXx29T5ZTT9jOVk XRmheW/YpuW5A== Date: Sat, 15 Apr 2023 17:49:43 +0100 From: Jonathan Cameron To: Marijn Suijten Cc: phone-devel@vger.kernel.org, ~postmarketos/upstreaming@lists.sr.ht, AngeloGioacchino Del Regno , Konrad Dybcio , Martin Botka , Jami Kettunen , Lars-Peter Clausen , Rob Herring , Krzysztof Kozlowski , Andy Gross , Bjorn Andersson , Manivannan Sadhasivam , linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH v4 5/5] dt-bindings: iio: adc: Require generic `channel` name for channel nodes Message-ID: <20230415174943.2b731203@jic23-huawei> In-Reply-To: References: <20230410202917.247666-1-marijn.suijten@somainline.org> <20230410202917.247666-6-marijn.suijten@somainline.org> <20230412212756.0b4b69f3@jic23-huawei> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.37; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Wed, 12 Apr 2023 22:31:46 +0200 Marijn Suijten wrote: > On 2023-04-12 21:27:56, Jonathan Cameron wrote: > > On Mon, 10 Apr 2023 22:29:17 +0200 > > Marijn Suijten wrote: > > > > > As discussed in [1] it is more convenient to use a generic `channel` > > > node name for ADC channels while storing a friendly - board-specific > > > instead of PMIC-specific - name in the label, if/when desired to > > > overwrite the channel description already contained (but previously > > > unused) in the driver [2]. > > > > > > The same `channel` node name pattern has also been set in > > > iio/adc/adc.yaml, but this generic binding is not inherited as base for > > > qcom,spmi-vadc bindings due to not having any other generic elements in > > > common, besides the node name rule and reg property. > > > > > > Replace the .* name pattern with the `channel` literal, but leave the > > > label property optional for bindings to choose to fall back a channel > > > label hardcoded in the driver [2] instead. > > > > > > [1]: https://lore.kernel.org/linux-arm-msm/20221106193018.270106-1-marijn.suijten@somainline.org/T/#u > > > [2]: https://lore.kernel.org/linux-arm-msm/20230116220909.196926-4-marijn.suijten@somainline.org/ > > > > > > Signed-off-by: Marijn Suijten > > > > There are various ways we could pick up this patch set... > > a) Binding changes via individual subsystem trees, > > b) All in on go. > > > > I think it's late to guarantee to land the changes from (a) in the coming merge window > > so if someone else is willing to do (b) then > > > > Acked-by: Jonathan Cameron > > > > Otherwise we can do (a) early in next cycle. Feel free to poke me if we are doing (b) > > and I seem to have forgotten to pick up this patch! > > Thanks! I hope we don't get many conflicts (+ new bindings adhering to > the old(er) formats) otherwise I'll resend if we do (a). Around what > time would be good, rc2? Sure. If rebase is needed send a v5 with that done. If not, a simple reminder reply to this thread will probably work. Thanks, Jonathan > > [..] > > - Marijn