Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp3756843rwd; Mon, 29 May 2023 16:37:52 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5OpATaq2fHI0PUNzZ8hV/yWnEUKlb0ZCZCXlWPOYkA88V4pbHhT0hwHdqSZZXWoTGoiRzD X-Received: by 2002:a17:90a:4504:b0:250:1905:ae78 with SMTP id u4-20020a17090a450400b002501905ae78mr656527pjg.15.1685403471877; Mon, 29 May 2023 16:37:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685403471; cv=none; d=google.com; s=arc-20160816; b=AI2JnETcz4DXMlQk3oU2YkS2XotopPSZJIg7iz4tzr97fBE7XrSSeNapUB7QyQnRlZ n+A9/SiAYJeTQB6r5iWWgOrEaP/Qew+IKwUT4l1HwjWFOLZpYWh2a0Wpbr39qMJS8B8/ KW+hMpLLRX4XCWMenXV0fC7mrJOeZoYGX4qmLmxySz2/1lnDcuT3rpXl8nP9Uo+45Yw3 aE93LzUV3jX8jplw1DHmc4WTBkNh6EW58/5L6bBvTXQQQJkjQZUkeUGyfEl7xIOEMJ0Y 9FMdik/V74fH1z8nWGlrlubbv4/tjzWGBRNqWHSk7n3FVQ9ISeA1lM1u1QiSCMldXLK1 DMdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:date:from; bh=6UPHdGfk6C3UHf+MCte9uAx63GwGR4xDhoY0ZGNFqv8=; b=CXaIeHwxSTyK3yUIj3NYXEQNII6YHlKNGtYW1SzAdL+TaZQyP4QWeJLGsMo54zasli yT1F2Ihv6DuYwZySOk5uxDMC/3qdfUyTzWic5Q5Y9ceD2L9EbPCQLTXHYrnVzAlzQtMu +bDXdtBlqEPCfCQR2sAm4IzkIOCp1u97GetjRcIZSV1LwZ44+HqsYcCbDtViCLVKRdDL sYTmGXL2OUq5BXUsbZpRB4llUKP3cDqEA0qidUxVHC04Jl9bEyATbZKrjMZ2LVZyhoaW FdPguHZSmODNItbi6ZLDTp6onpCWI5M6cRejtaJ6SPfjQUfX5qV4zdfQFhyubl1gXcvG 8IMQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id oc17-20020a17090b1c1100b0025355f85165si6909890pjb.139.2023.05.29.16.37.39; Mon, 29 May 2023 16:37:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229461AbjE2XdG (ORCPT + 99 others); Mon, 29 May 2023 19:33:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38426 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229498AbjE2XdF (ORCPT ); Mon, 29 May 2023 19:33:05 -0400 Received: from fgw23-7.mail.saunalahti.fi (fgw23-7.mail.saunalahti.fi [62.142.5.84]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D9171BE for ; Mon, 29 May 2023 16:33:03 -0700 (PDT) Received: from localhost (88-113-26-95.elisa-laajakaista.fi [88.113.26.95]) by fgw23.mail.saunalahti.fi (Halon) with ESMTP id 2552c16e-fe79-11ed-b972-005056bdfda7; Tue, 30 May 2023 02:33:00 +0300 (EEST) From: andy.shevchenko@gmail.com Date: Tue, 30 May 2023 02:32:58 +0300 To: George Stark Cc: Andy Shevchenko , "jic23@kernel.org" , "lars@metafoo.de" , "neil.armstrong@linaro.org" , "khilman@baylibre.com" , "jbrunet@baylibre.com" , "martin.blumenstingl@googlemail.com" , "nuno.sa@analog.com" , "linux-iio@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-amlogic@lists.infradead.org" , kernel Subject: Re: [PATCH v2] meson saradc: add iio device attrib to switch channel 7 mux Message-ID: References: <20230527214854.126517-1-gnstark@sberdevices.ru> <9df82b13-7594-a8f0-f27e-87bce5a38b74@sberdevices.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9df82b13-7594-a8f0-f27e-87bce5a38b74@sberdevices.ru> X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FORGED_GMAIL_RCVD,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,SPF_HELO_NONE, SPF_SOFTFAIL,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mon, May 29, 2023 at 01:31:40AM +0300, George Stark kirjoitti: > On 5/28/23 13:46, Andy Shevchenko wrote: > > On Sun, May 28, 2023 at 12:48:54AM +0300, George Stark wrote: ... > > > + if (index >= ARRAY_SIZE(chan7_vol)) > > > + index = ARRAY_SIZE(chan7_vol) - 1; > > I think this is incorrect and prone to error in the future in case this array > > will be extended. What I would expect is to return something like "unknown". > > I agree this part is unclean. Actually the register's last 3 (out of 8) > possible values are stand for the same mux input "ch7_input". So > theoretically we can read from register a value out of array bounds. There > should be a comment at least. You can add there in the array to extend it up to 8 entries, so it will be clear. And for the rest you will return unknown / unsupported / etc. ... > > > +static const char * const chan7_vol[] = { > > > + "gnd", > > > + "vdd/4", > > > + "vdd/2", > > > + "vdd*3/4", > > > + "vdd", > > > + "ch7_input", > > > +}; > About the question of naming mux inputs from the other letter (vdd/2 vs > 0.5Vdd etc). > While I fully agree with you that point is better than slash but mixing > letter cases... should we? What's wrong with that? > e.g. this is how iio_info output looks like now: > ... > ?? ???? ??? voltage7:? (input) > ?? ???? ??? 3 channel-specific attributes found: > ?? ???? ??? ??? attr? 0: mean_raw value: 0 > ?? ???? ??? ??? attr? 1: raw value: 1 > ?? ???? ??? ??? attr? 2: scale value: 0.439453125 > ?? ???? 4 device-specific attributes found: > ?? ???? ??? ??? attr? 0: chan7_mux value: gnd > ?? ???? ??? ??? attr? 1: chan7_mux_available value: gnd vdd/4 vdd/2 vdd*3/4 > vdd ch7_input > ?? ???? ??? ??? attr? 2: current_timestamp_clock value: realtime > > ?? ???? ??? ??? attr? 3: waiting_for_supplier value: 0 > > or naming with Jonathan's approach > /sys/devices/platform/soc/fe000000.bus/fe002c00.adc/iio:device0/in_voltage_0.5vdd_raw See the alternative I proposed is to have _ delimiter. But that might make parsing a bit harder in user space. -- With Best Regards, Andy Shevchenko