Received: by 10.223.185.116 with SMTP id b49csp2261228wrg; Mon, 12 Feb 2018 07:01:50 -0800 (PST) X-Google-Smtp-Source: AH8x225dY3SaVNC79LMKMqZjtdZbm/qwVY3CVabvUcPQVEfpEKb9oZGok8bs2QbJ/8Lk5jR6mgXI X-Received: by 10.98.8.86 with SMTP id c83mr11960699pfd.84.1518447710731; Mon, 12 Feb 2018 07:01:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518447710; cv=none; d=google.com; s=arc-20160816; b=aEewvLEp3EoH8ZoEmtPRUZHVBlMqVphhWH9Rb5gi+F9SLmaalDAxa09fqIQ+YBNhs1 MeTHQ2aUq7ii8hD11Z4mnjylpqYx6SL0xS8oVJBuJwuiCJVQZVwJcn0By8XR6F05hTtx Ar7/ArwlQ1g9S+bg8eiQ2VL1yGVGMJQrAKFu6EXm2bbuuciBFcSIPL9GJzlFGOVGLpji gPPyoSWjN5aPHSYJF74woUK1vdtOLb/fAmn1HbweyjwJyIavjloDvFrHAdKvNjgZdp2H gBbBNOs1FEv+haGgmIpkuEdoso2GtyMHi8djnq/lpIqfpNr2iEZujB1DoJNuFa+/CWga HzCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=0Bv0QeeylMQ6Zmli48IAQxXgT0H52HtKLWif30K8/yc=; b=usqb1HzCQdEF6bg+zL4/j8sV4+C/bq2qK4cB7X4Ltp4nq3Sc6hhhEKOnURGtA3zQjC YPusJhuOeMQq0XC7aacPmDQwVDUdQd82mclzbxoSIS1OCk0eT5c/63LATftaSiH3/Vau V/4rGfs65Nxxmxk8/7kegMbVP6X2SCqUXnKYf0cM0UrVP2rzLVYPkhUNrcKAY21ZQtR7 ScETHco4LxM/qrKsDHEumzzoUCDgLSRrhS+m7LgVfw79ijSzyIb89uM4xnKtLNY0PTR/ PagP/CNzXJl8ZSftb/mGW2w6gFdrcbzusJOHZuwyXhHP4oJbD103FH1362V6HaX2Gmhp me4A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=rMrxUeFp; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z61-v6si5968884plb.669.2018.02.12.07.01.32; Mon, 12 Feb 2018 07:01:50 -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=@gmail.com header.s=20161025 header.b=rMrxUeFp; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935928AbeBLOfe (ORCPT + 99 others); Mon, 12 Feb 2018 09:35:34 -0500 Received: from mail-pl0-f66.google.com ([209.85.160.66]:34711 "EHLO mail-pl0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933097AbeBLOfc (ORCPT ); Mon, 12 Feb 2018 09:35:32 -0500 Received: by mail-pl0-f66.google.com with SMTP id bd10so242441plb.1; Mon, 12 Feb 2018 06:35:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=0Bv0QeeylMQ6Zmli48IAQxXgT0H52HtKLWif30K8/yc=; b=rMrxUeFpd9ZzWfsAGh9x2sRH5JMso9IGqSspeyOMSvWzj/2NTj8pGVq+7r93UT4cHJ U1I9n8w1zKgRCDhnzKYP8q/tUmAyVgBoOoGN4p12JlYqkx2K+t/20vfP7hzfvAlLM7lk OrnTEuunpq4F+1THRQAzmeEFpanykf1S7gY7TwDIx0i5EBrXxaYvGTzDbmucK7cEBbN0 987wap6/IJmcz97imMtjSihl35AQ5mQ+SXeotFhRTpsvI9B1xTczs6kj3uxjIFbr6VVz Ley71/wKAX6HYFMrxcmb4XHQMmZGTNt9T5I0j6aCmBksiytQpyxCknMLz3+PbDdPktku 5IvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=0Bv0QeeylMQ6Zmli48IAQxXgT0H52HtKLWif30K8/yc=; b=sJzwWESFkioB89ER4D6Vld/pH0ov3c9BoZOUlfotrFF19gbT7SBG36rSJwwPwKrYRR pwlGtr+JXF6hTsSq9VFQZsZ998Ik68iHWzkLAugr4t68anOG6wTStGq/14uRJ7Hj9M5u U1tQwLtUlkY+oAFKG/xBLta80tS0p+8zkGEKHpzoMBA2fwq+CUnmBS5LTgCTjgG+JfKE v0xI1e3TBICIZElfROVy4CAm21YeDS1H5AUUq4sczMcw9PoXFp2g/QHTeIcjSRgM4xwt 1vVcK7CEmkb8YthD0aN6cP53BRcvffd2elqp0GjXZf5a+r2zxOJuBDBMpQIJwaUAF4q/ UxRw== X-Gm-Message-State: APf1xPDNjcvWha7OSwH3f+faIYrX2xk45KezrXHR05G5NLYyfDB9qk0E ntQrl015Id+p9D8/d8mbkKs= X-Received: by 2002:a17:902:6b05:: with SMTP id o5-v6mr10730767plk.179.1518446131518; Mon, 12 Feb 2018 06:35:31 -0800 (PST) Received: from himanshu-Vostro-3559 ([103.46.193.14]) by smtp.gmail.com with ESMTPSA id l84sm28280859pfb.153.2018.02.12.06.35.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Feb 2018 06:35:30 -0800 (PST) Date: Mon, 12 Feb 2018 20:05:22 +0530 From: Himanshu Jha To: Dan Carpenter Cc: 21cnbao@gmail.com, jic23@kernel.org, devel@driverdev.osuosl.org, lars@metafoo.de, Michael.Hennerich@analog.com, linux-iio@vger.kernel.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, pmeerw@pmeerw.net, knaack.h@gmx.de Subject: Re: [PATCH 2/4] staging: iio: accel: Remove unnecessary comments and add suitable suffix Message-ID: <20180212143522.GA12142@himanshu-Vostro-3559> References: <1518436499-8584-1-git-send-email-himanshujha199640@gmail.com> <1518436499-8584-3-git-send-email-himanshujha199640@gmail.com> <20180212125312.cjo76spuu6agjawc@mwanda> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180212125312.cjo76spuu6agjawc@mwanda> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Dan, On Mon, Feb 12, 2018 at 03:53:12PM +0300, Dan Carpenter wrote: > On Mon, Feb 12, 2018 at 05:24:57PM +0530, Himanshu Jha wrote: > > Remove some unnecessary comments by giving appropriate name to macros. > > Therefore, add _REG suffix for control registers. Also, align function > > arguments to match open parentheses using tabs. > > Group the control register and register field macros together. > > > > Blank line before some returns improves code readability. > > > > Signed-off-by: Himanshu Jha > > The most obvious response is that this needs to be broken up into > multiple patches. > > I think I liked almost all the comments... Please note that all the changes are suggested by Joanathan in his TODO https://marc.info/?l=linux-iio&m=151775804702998&w=2 I think it far more commenting as compared to other drivers in the mainline IIO drivers. I grouped all the relevant control registers together at one place with suitable comment. For eg: +/* Data Output Register Definitions */ The macro names are identical to the names in the datasheet if you can look and one could easily refer to the datasheet easily. Also, I grouped the control registers and their fields together make it more readable. For eg: +#define ADIS16201_MSC_CTRL_REG 0x34 +#define ADIS16201_MSC_CTRL_SELF_TEST_EN BIT(8) +#define ADIS16201_MSC_CTRL_DATA_RDY_EN BIT(2) > > -/* Output, power supply */ > > -#define ADIS16201_SUPPLY_OUT 0x02 > > +#define ADIS16201_SUPPLY_OUT_REG 0x02 > > To me it seems useful to know that we're talking about the power supply. For that purpose I already grouped data output register definitions. > Adding _REG to the name seems not terribly useful and it makes the name > longer so we're going to run into the 80 character limit. I just > checked and this patch does add some checkpatch warnings. _REG prefix is used to differentiate between registers addresses and the fields in the register as pointed in the above MSC_CTRL_REG and MSC_CTRL_SELF_TEST_EN. Yes by doing this it triggered 2 I think 80 character warning. For eg: ADIS_SUPPLY_CHAN(ADIS16201_SUPPLY_OUT_REG, ADIS16201_SCAN_SUPPLY, 0, 12), But you know with 81 characters so I neglected it because it looked more readable without breaking into lines IMHO. > But aligning the arguments is fine, deleting unused macros is fine, > adding blank lines is fine. > > > static int adis16201_probe(struct spi_device *spi) > > { > > - int ret; > > - struct adis *st; > > struct iio_dev *indio_dev; > > + struct adis *st; > > + int ret; > > Making this reverse Christmas tree is fine. But these things should all > be done in separate patches. I am sometimes confused in dividing the patches. As per your advice I should make separate patch for : 1. remove unnecessary comments. 2. add suitable suffix. 3. add tabs instead of space. 4. reverse christmas tree. But these should be done when we have *more* instances. For eg: I added a tab space in function static int adis16201_read_raw() argument to match open parentheses in this patch. But I also added tabs while removing and adding suitable suffix to the macros. So, should it also be done in a separate patch ? Since there was only one instance of adding tabs therefore I did it here without framing another patch for that purpose while saving my time to plan 'what to include/exclude in the patch ?' Also, given the above queries I was clueless as what to do first! Since sometimes it happens that the patch series doesn't apply cleanly because of incorrect ordering for framing the patches. Thanks for taking your time to review the patch series. -- Thanks Himanshu Jha