Received: by 2002:a25:d783:0:0:0:0:0 with SMTP id o125csp396369ybg; Thu, 19 Mar 2020 01:40:04 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuefgIW7Kj9Rx/QzXJHc6fJRAmNbOLQ3WZezX20qVwWjuHTs3xQjFTp69buQnngEUCrd0H/ X-Received: by 2002:a05:6830:4025:: with SMTP id i5mr1426482ots.203.1584607204159; Thu, 19 Mar 2020 01:40:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584607204; cv=none; d=google.com; s=arc-20160816; b=SqLx4EvRGthkaWC1/Yt29bPQ7pUXDaJOvTLlci88ehNxTRhb3N2A/slZMzkzxaJCs/ qnZ+uXv7dPyb8X6wOf7v44/fn5PV1a/ajl1+jj5zZ4QbzmS3MRW/lQ+YanTcRSWVP9mt W0uw/HynDAvhd1C6gsj+NO9qaOkLXcHaihwG3NAHEhO42R+hiycvYGRXbhAHxxo9IG5L 8fcnD3Ai9+l/WkM79bFX/zxjjPkGNRvodNFtonNHFEbv7CQ/KVUdcgLU7iYnvFfvsrAo eXGstuB+i7A82855ceOKDGspujaW+oNgJNb2zVbqbOJYtPHnlpT6I7FR4k1D6vxMAg2w BIFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=hKAEd+CZG7zQHnD4IiKme34IoCaYfigdFzSOMMibNAA=; b=jTml5g9m23OV+NmtBHxsoTMsfP7RO8QyCYa8QCADPJQErNBKJ88g5bLB2re//x+/ap btZqzMfMJSDdLZkfN3xBIOUshqEfFGqfoUei50HnG/aTKMJPyduwaZueXKxSZ1slrpas ljg2PofEE6aBsG4uQCyFTCGDYG7CpQAq9QsfXwXr0wKdeGycWX3eDou29hreoqdxK2Y7 bC6uw1fr/6Hv4N/LIVIL94YTh+sdRrMqVsZFUswjg7VAs0YEL7e0+VAUZQObRzWkoDEa M7WQc6TJryrB6IXTXrRmnehsuEdm2S3hfdCVq1hJjY6mZGXQXj/61FSZ7h0j5WLrg8Pi HeDA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@metafoo.de header.s=default2002 header.b=CPhk2aQy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=metafoo.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f5si850590otq.73.2020.03.19.01.39.50; Thu, 19 Mar 2020 01:40:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@metafoo.de header.s=default2002 header.b=CPhk2aQy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=metafoo.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726796AbgCSIi7 (ORCPT + 99 others); Thu, 19 Mar 2020 04:38:59 -0400 Received: from www381.your-server.de ([78.46.137.84]:50264 "EHLO www381.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725601AbgCSIi6 (ORCPT ); Thu, 19 Mar 2020 04:38:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=metafoo.de; s=default2002; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=hKAEd+CZG7zQHnD4IiKme34IoCaYfigdFzSOMMibNAA=; b=CPhk2aQyZbF0pNeM9BrP2x6HLF pULBTC7yBJqNu5sfAp9p+xwS1+L8McuoZUeBo5f+sDK2MAJKVnt7zdemGwaXjjForCkVJWUtFt0oZ stnaz2t92cxh3NWE8lx6Y0ecZ923C5o8VusltxFwbbqXiIV9yy4nVnft24DZZEoprb403gyhCCUYB xTPcZwwY/KnEPgt+ZQsCtEN/qChxqkBxEmQYzvWcEMbDvLLqbpD5UezzobSnXlcMK46xEYlxy7Qs7 cNT6rkKtY6r4Mvi2DAoaPWL/bj7DFrXA132IsaTU8SzK0lov4nhGV1NDS5F5rjE4IO2/HDZw2Db0w 1EZYJgzg==; Received: from sslproxy03.your-server.de ([88.198.220.132]) by www381.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1jEqhZ-0000Mk-9I; Thu, 19 Mar 2020 09:38:53 +0100 Received: from [93.104.102.217] (helo=[192.168.178.20]) by sslproxy03.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jEqhY-000Unr-VN; Thu, 19 Mar 2020 09:38:53 +0100 Subject: Re: [PATCH 5/5] iio: adc: ad7793: use read_avail iio hook for scale available To: "Ardelean, Alexandru" , "ardeleanalex@gmail.com" , "linux-iio@vger.kernel.org" , "linux-kernel@vger.kernel.org" Cc: "renatogeh@gmail.com" , "Hennerich, Michael" , "jic23@kernel.org" , "Caprioru, Mircea" References: <20200318134042.30133-1-alexandru.ardelean@analog.com> <20200318134042.30133-6-alexandru.ardelean@analog.com> From: Lars-Peter Clausen Message-ID: <4f00fe26-cb42-fc82-c97a-4c2191c0a243@metafoo.de> Date: Thu, 19 Mar 2020 09:38:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: lars@metafoo.de X-Virus-Scanned: Clear (ClamAV 0.102.2/25755/Wed Mar 18 14:14:00 2020) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/19/20 8:58 AM, Ardelean, Alexandru wrote: > On Wed, 2020-03-18 at 16:10 +0100, Lars-Peter Clausen wrote: >> On 3/18/20 2:40 PM, Alexandru Ardelean wrote: >>> This change uses the read_avail and '.info_mask_shared_by_type_available' >>> modifier to set the available scale. >>> Essentially, nothing changes to the driver's ABI. >>> >>> The main idea for this patch is to remove the AD7793 driver from >>> checkpatch's radar. There have been about ~3 attempts to fix/break the >>> 'in_voltage-voltage_scale_available' attribute, because checkpatch assumed >>> it to be an arithmetic operation and people were trying to change that. >> >> Yeah, probably a good idea! >> >>> Signed-off-by: Alexandru Ardelean >>> --- >>> drivers/iio/adc/ad7793.c | 53 +++++++++++++++++++++++++++------------- >>> 1 file changed, 36 insertions(+), 17 deletions(-) >>> >>> diff --git a/drivers/iio/adc/ad7793.c b/drivers/iio/adc/ad7793.c >>> index 5592ae573e6b..fad98f1801db 100644 >>> --- a/drivers/iio/adc/ad7793.c >>> +++ b/drivers/iio/adc/ad7793.c >>> @@ -354,29 +354,28 @@ static IIO_CONST_ATTR_SAMP_FREQ_AVAIL( >>> static IIO_CONST_ATTR_NAMED(sampling_frequency_available_ad7797, >>> sampling_frequency_available, "123 62 50 33 17 16 12 10 8 6 4"); >>> >>> -static ssize_t ad7793_show_scale_available(struct device *dev, >>> - struct device_attribute *attr, char *buf) >>> +static int ad7793_read_avail(struct iio_dev *indio_dev, >>> + struct iio_chan_spec const *chan, >>> + const int **vals, int *type, int *length, >>> + long mask) >>> { >>> - struct iio_dev *indio_dev = dev_to_iio_dev(dev); >>> struct ad7793_state *st = iio_priv(indio_dev); >>> - int i, len = 0; >>> >>> - for (i = 0; i < ARRAY_SIZE(st->scale_avail); i++) >>> - len += sprintf(buf + len, "%d.%09u ", st->scale_avail[i][0], >>> - st->scale_avail[i][1]); >>> + switch (mask) { >>> + case IIO_CHAN_INFO_SCALE: >>> + *vals = (int *)st->scale_avail; >> >> Can you change the type of scale_avail to int so we don't need the cast? >> > > So, I don't want to come-up as looking lazy. > [I mean, I am lazy, but I don't want to look lazy.] > > I took a look at what it means to change this to a simple array. > The rework feels to me like a bit more noise than is probably worth it. > I mean, if the purpose of the rework is to just get rid of this cast, then it > feels noisy [to me]. > > That being said, if you insist, I can take a look and do a patch [before this > one] to convert it to a simple array. Hm, ok, looks like is more complicated to get rid of the cast than I though. So keep it.