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 7DED6C7EE29 for ; Sun, 28 May 2023 15:08:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229573AbjE1PI4 (ORCPT ); Sun, 28 May 2023 11:08:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43676 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229478AbjE1PIy (ORCPT ); Sun, 28 May 2023 11:08:54 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8BAB8B1; Sun, 28 May 2023 08:08:53 -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 22A7360BA0; 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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. >