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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 20F4EC7EE23 for ; Sun, 28 May 2023 15:09:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4xpKUn41V5HxrJZZaw783nW1z8qyhL9iynKUz8aMKmI=; b=gklJexSBt693Xo TZ9C5aRbGs2R17haOSXJTDraeKPLxeT0pSddtuARW0GpicePWcn3r3pOU4yTVeSyhi8s61DKIbwm9 EbeeiqxxSBhf6SfV7FlXuJiMdrpK1PQs87T2gFUQXjDT55fQPkvqYZKUPFuxtRjU7MmK08uMuzDxL 7wh20yviPomVtxvDbl8w0CGaeahCm2l/sNoLuTIXFhWdWot8FIxPJIrW0EUoUkbRvpUyoMqOhw2j5 TKTd+Ndg+doMvkUzdoPIllEyaT73ctFJyVN6TKSQlK29CBLG7gUcx57FeCcsAWMv9eqUq6Q2A6S24 jagIS5PXgyUoMcEBxatA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q3I0u-007uk7-0M; Sun, 28 May 2023 15:08:56 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q3I0r-007uiv-1y; Sun, 28 May 2023 15:08:55 +0000 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 2755E60DFE; Sun, 28 May 2023 15:08:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D2F5BC433EF; Sun, 28 May 2023 15:08:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685286532; bh=yLY65D3lC0tV36WPq/3WNHSYiwt+E+smRjd0WJL9G7s=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Ihed7O23AluVfBTmTgPGc1bz8+pzAUzHrmq8mKzU+NAoLzS1YEJjtHEww4Dx2kzxO aC7VEGAOJQjD7HGpmg8jfS5iN4swC8zxDV4tBFuZuqfkIUtOFhCtdOuqVODhEoK9Sr 81NFtiqCuU51WPehREiC1h+N5R8vCJGlVA5N5yoAhbx5kPmeH7rcd38MWxruVwq1jD zveXAfq29XhbpOH74kz+RxcHcSEJw5DkYmFzXbcjIL881jCiNkHd5F4G8hXgEO7jf8 YoCX6/pEom+A4J0+Qa9/r4T1rd3Qh54Pu335ebcg99yhatftNJ2XZ9vz/hlWz/eAjs kuC4dB8UlQ0ZQ== Date: Sun, 28 May 2023 16:25:07 +0100 From: Jonathan Cameron To: Maxim Kiselev Cc: Andre Przywara , linux-iio@vger.kernel.org, Lars-Peter Clausen , Rob Herring , Krzysztof Kozlowski , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , Conor Dooley , Paul Walmsley , Palmer Dabbelt , Albert Ou , Philipp Zabel , Heiko Stuebner , Andy Shevchenko , Cosmin Tanislav , Mike Looijmans , Haibo Chen , ChiYuan Huang , Ramona Bolboaca , Ibrahim Tilki , Caleb Connolly , William Breathitt Gray , Arnd Bergmann , Leonard =?UTF-8?B?R8O2aHJz?= , AngeloGioacchino Del Regno , Hugo Villeneuve , ChiaEn Wu , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [RFC PATCH v1 0/4] Add support for Allwinner GPADC on D1/T113s/R329 SoCs Message-ID: <20230528162507.144cfdf2@jic23-huawei> In-Reply-To: <20230528162257.7e8932b9@jic23-huawei> References: <20230524082744.3215427-1-bigunclemax@gmail.com> <20230524103431.50c6a2fd@donnerap.cambridge.arm.com> <20230528162257.7e8932b9@jic23-huawei> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230528_080853_793137_180ECC0F X-CRM114-Status: GOOD ( 33.62 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sun, 28 May 2023 16:22:57 +0100 Jonathan Cameron wrote: > On Wed, 24 May 2023 14:36:28 +0300 > Maxim Kiselev wrote: > > > Hi Andre, > > > > thanks for you comments > > > > > This may sound kind of obvious, but wouldn't it be easier to model this > > > with one compatible string, and have the number of channels as a DT > > > property? > > > > Yes, I completely agree that using separate config for each SoCs is looks > > overcomplicated because the only difference is the number of channels. > > I thought about a DT property with channels number but I didn't find > > another ADC driver with the same approach (except i2c ADC's with child nodes). > If you are 100% sure that that devices are either > 1) Detectable at runtime > 2) Identical in functionality. > > So that in neither case will any changes on driver support expose differences > in the future then a single compatible is fine. > > The back up is that you use fallback compatibles - list more than one. > Whilst it doesn't matter (as no differences found) the driver can use > the first one. If differences become apparent later, others may be used. > > I'm not however keen on a simple channel count parameter. If you want > to go that way, it's better to provide the fine control of individual channel > child nodes (see Documentation/devicetree/bindings/iio/adc/adc.yaml) > > That way the control is on which channels are wired to something useful, rather > than whether the device can read them or not (which is pointless if no one > wired them up. Another thing to note is that with generic compatibles you loose the ability to have the dt-schmema validate that sets of parameters make sense. If it's just the channels available that may not matter however. > > > > > > > Or, alternatively, using iio/multiplexer/io-channel-mux.yaml, since it's > > > only one ADC anyway? > > I'm sorry, I didn't quite understand what you're suggesting. > > That's normally only used for a separate MUX where we need a separate driver > to handle it. If used on a device like this it would expose additional complexity > to userspace with no benefits in generality etc. > > > > > > And btw: it seems that the T507 (the H616 die with a different pinout) has > > > the same IP, with four channels: > > > http://dl.linux-sunxi.org/T507/ > > > > Oh, thanks for pointing that. I'll add it to the list in the next version. > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel