Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp1793033imb; Sun, 3 Mar 2019 06:54:31 -0800 (PST) X-Google-Smtp-Source: AHgI3Ib/nUpYcqD9TEINi5Gf3tRSlRdnggxSwTaYlBtIEl/Ot+ttPsIbSdE11WsrOsb0Qq/HRjNW X-Received: by 2002:a62:18d8:: with SMTP id 207mr15545522pfy.57.1551624871178; Sun, 03 Mar 2019 06:54:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551624871; cv=none; d=google.com; s=arc-20160816; b=Ez7u4rPq6W3pOy+M8VlBZ9c1OL9kf4pMNogp8/5ve40Y8mNwsPBENBbmzY77pkQQhw 2QAYC0JIL72JarDmWboJ1ckrGOQuCbwZJpusDT+ZCrBUDEMOi4YPEecWqaeQYEtpwKW5 vQx1h+Roca4hpdnxt/Mj2cY2mmJf0n2OnVGtjLRZIffJ0rSAIPXSLA1RhoQ+oW7U/zko 8xieQr1QB6P4+XJrZpZr+MnAnnkGtMGuTrEnbush4A4m0h9PvPvqbMILRpe6PIHZpizn Vvt0f4fikyUV+Rpki2O7LfgIPW2k8BQbf6z3M+P8huH757iicjVpMQ2mjypoqO9xqCA1 lD2Q== 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:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=jYPAQJ785nQw/OAOj3KDFsUqz7LBYAA+Lzt+EzA/Fgc=; b=SFpDWj4RLmHpxosxh7U4lKTgh6O3bQImPB9Uui++uZX8juZB3/X4YaBhgte+FJyLxz GQ7DMPsntNDKaHHVwxRK9y9ne2d3uWhF3WdoY3Byv810nvwbMEOZRMt8t9ugP9aDP3DH RoVzvq5Q4QV0Rbo9vxWgVR1L+JElOYhuYrvd8Jzbjiqh03piBbiiYsfzJOY8nyXqE2hy gUS+qYzRk1P9R5LCATggvQ/08rrj2dCQ84PVW7m9IAjHbda19B0XZJxE6/EJLjAjJIUA ssspv6OLQQ5VonH9kTdi5hS6qzES6bHAn85Ku8r128fbXzWMk3B+2yFyO1Hq9GRX6F6w 7Rug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="rzTOSD/K"; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g188si2985700pgc.88.2019.03.03.06.54.15; Sun, 03 Mar 2019 06:54:31 -0800 (PST) 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=pass header.i=@kernel.org header.s=default header.b="rzTOSD/K"; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726341AbfCCOx4 (ORCPT + 99 others); Sun, 3 Mar 2019 09:53:56 -0500 Received: from mail.kernel.org ([198.145.29.99]:52154 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726252AbfCCOx4 (ORCPT ); Sun, 3 Mar 2019 09:53:56 -0500 Received: from archlinux (cpc91196-cmbg18-2-0-cust659.5-4.cable.virginm.net [81.96.234.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C127C20835; Sun, 3 Mar 2019 14:53:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1551624835; bh=Mvo+X3wRoMGON/YmscCJuQvZhEiGKLrVtGJpcZX9Oz8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=rzTOSD/K/72B+LUjlQccxXfeCMneZxAjw7OeSnPSzPOpV2Pkngfx0jVrU5JqDKtBB K6y3dxnzU3CPc7/pEGq1FqHZdZfAVdogHdBSy6OVU/lJRw2O9UmUcwS00Eh0Lfe+6m ol9GnRog1L2RQyZb0oiqjiOeRwf5JtKeFTHFfD94= Date: Sun, 3 Mar 2019 14:53:47 +0000 From: Jonathan Cameron To: Renato Lui Geh Cc: "Ardelean, Alexandru" , "lars@metafoo.de" , "robh+dt@kernel.org" , "Popa, Stefan Serban" , "knaack.h@gmx.de" , "Hennerich, Michael" , "mark.rutland@arm.com" , "giuliano.belinassi@usp.br" , "pmeerw@pmeerw.net" , "gregkh@linuxfoundation.org" , "linux-kernel@vger.kernel.org" , "linux-iio@vger.kernel.org" , "devel@driverdev.osuosl.org" , "kernel-usp@googlegroups.com" , "devicetree@vger.kernel.org" Subject: Re: [PATCH v4 4/9] staging:iio:ad7780: add chip ID values and mask Message-ID: <20190303145347.41d49646@archlinux> In-Reply-To: <20190303140107.ljjo3flatwmd44ya@renatolg> References: <90c573cd53bb54d49de6ac270bcff66880ccfeb5.1551358569.git.renatogeh@gmail.com> <190e26b19b8ed6559b92d3a000d852bbb0099a52.camel@analog.com> <20190303140107.ljjo3flatwmd44ya@renatolg> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 3 Mar 2019 11:01:09 -0300 Renato Lui Geh wrote: > On 03/01, Ardelean, Alexandru wrote: > >On Thu, 2019-02-28 at 11:24 -0300, Renato Lui Geh wrote: > >> > >> > >> The ad7780 supports both the ad778x and ad717x families. Each chip has > >> a corresponding ID. This patch provides a mask for extracting ID values > >> from the status bits and also macros for the correct values for the > >> ad7170, ad7171, ad7780 and ad7781. > >> > >> Signed-off-by: Renato Lui Geh > >> --- > >> drivers/staging/iio/adc/ad7780.c | 8 ++++++-- > >> 1 file changed, 6 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/staging/iio/adc/ad7780.c > >> b/drivers/staging/iio/adc/ad7780.c > >> index 56c49e28f432..ad7617a3a141 100644 > >> --- a/drivers/staging/iio/adc/ad7780.c > >> +++ b/drivers/staging/iio/adc/ad7780.c > >> @@ -26,10 +26,14 @@ > >> #define AD7780_RDY BIT(7) > >> #define AD7780_FILTER BIT(6) > >> #define AD7780_ERR BIT(5) > >> -#define AD7780_ID1 BIT(4) > >> -#define AD7780_ID0 BIT(3) > >> #define AD7780_GAIN BIT(2) > >> > >> +#define AD7170_ID 0 > >> +#define AD7171_ID 1 > >> +#define AD7780_ID 1 > >> +#define AD7781_ID 0 > >> + > >> +#define AD7780_ID_MASK (BIT(3) | BIT(4)) > > > >This also doesn't have any functionality change. > >The AD7170_ID, AD7171_ID, AD7780_ID & AD7781_ID IDs are also unused (maybe > >in a later patch they are ?). > > They aren't. I added them following a previous review suggestion. Should > I remove them? Can we check them? It's always useful to confirm that the device is the one you think it is. Then we can either use what is there with a suitable warning, or if that is tricky just fault out as the dt is giving us the wrong part number. J > > > >I would also leave the AD7780_ID1 & AD7780_ID0 definitions in place, since > >they're easier matched with the datasheet. > > > >> > >> #define AD7780_PATTERN_GOOD 1 > >> #define AD7780_PATTERN_MASK GENMASK(1, 0) > >> -- > >> 2.21.0 > >>