Received: by 2002:ac0:b08d:0:0:0:0:0 with SMTP id l13csp2501286imc; Sat, 23 Feb 2019 04:56:07 -0800 (PST) X-Google-Smtp-Source: AHgI3Ib8sSZBAgsLjr7P4l3aHyTlPN7RWblZ6RYJ3hAktDIDZi+y3GikepUO6ZYLq+bkLNbQHW/e X-Received: by 2002:a17:902:4225:: with SMTP id g34mr9527083pld.152.1550926567172; Sat, 23 Feb 2019 04:56:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550926567; cv=none; d=google.com; s=arc-20160816; b=F/Vbl4JZhJWkDp/rUr4RB73fQf2Vw8J9LKKjwqmJKR0FpSIXdSsTrGbqI6shCnEFLy EDT9suELfCkgWWzPTqLucDZaKccZKbd42k6Lw7nQislqmN5wpcVRa6Yalij/1iMwM8VD uawB0hwg/vGKiDwxR5YqhvXgC2SkourHV2/Hd741NKPbOYKrz9oGt1NSrbNZmiFaIjR2 cEsahYo/5nS6mrfHkMgaGa95gfPft7bQ741C2sMJ5tsON/S+lBDFta2D5BvXt8Tlom9P eNPj54AkfmWdSBScDF+R1n9Aju4SiKpZGW1TB3Icss44vI4o1ss7bxMy/KPeInhs4mSz Dw2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=If1EW02IMyYRK8Qqq7I2S3/zZAH0ob5WSW7je21GfAs=; b=a2MU3XrSnF5QcAZDucvUflTLl8UgmVDsZK8Mz7349TnaMbRopAUajY7jysDBPIeePY r+CnZlN25iJPiksLcp6LkzR0mm6v38fA0bS3PId5cWdUwB/82lEKcY0Veo0BeNRFVafM deoIMtjwVSEBS3ds6Yolz9q1DM9rF6kPHJeqgEZj42ErZmCmTnT7XACnND7rpblPkZls LD6FwDBL6ornEQU1F8QLwZRu6p5J6cw68amLMa23wa+1H+KLun5A2Vn7r0l6htN1wVAp 8bbGwomrwIdVJTx6S2WgS5Xd3S+TRDwQr7+XQH4kAk68KO3QeYMtZqHnwFjrozyMTGd+ 0rvw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ingics-com.20150623.gappssmtp.com header.s=20150623 header.b=kD8F70P4; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b4si3681010pgq.43.2019.02.23.04.55.51; Sat, 23 Feb 2019 04:56:07 -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=@ingics-com.20150623.gappssmtp.com header.s=20150623 header.b=kD8F70P4; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726271AbfBWMzI (ORCPT + 99 others); Sat, 23 Feb 2019 07:55:08 -0500 Received: from mail-wr1-f67.google.com ([209.85.221.67]:41735 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725859AbfBWMzH (ORCPT ); Sat, 23 Feb 2019 07:55:07 -0500 Received: by mail-wr1-f67.google.com with SMTP id n2so5155687wrw.8 for ; Sat, 23 Feb 2019 04:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ingics-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=If1EW02IMyYRK8Qqq7I2S3/zZAH0ob5WSW7je21GfAs=; b=kD8F70P4rBiVCZ8IwysPtKXNJ2l5LpggetxtPP3YsgHgHbEuZjQ6QOnVVEPeh+K8lc lmMqjHsfPiOUQ5985T5npSAnTJqvPI+92oZMQAdcxz1+ngodcfv5UVRYAQFu+AyUlO+c QFNoVwxAa655ifdNh6ys08GkycDv6NhO1bJUyM1NH4m2jiKNMZ83yz8RpO4eMngR9KuN aulolYnCAXsUKR/cZjkNU8eN1lhTEb7UJQHJWYOe9NXYHNTfdVU8MAn1DJpRDHR2ZzR+ jyTkdk14V1oAaRucac9Iard5uSiRMcvXxfn+6Be+wF4P5AkB3+E3OpRB7H2tTGyEOJ08 g7/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=If1EW02IMyYRK8Qqq7I2S3/zZAH0ob5WSW7je21GfAs=; b=Oes33myziP2/f1or1yN25PcQZ5SoPGN6soN8ZjolFNJ6D5uOLV9LgYHbn33FCrr1CR ZmNdkqR5K26rcNUpSV2FLbagscDqYzBzpcESmVQE8dZuphSjjpIZGgwD2dK5HGtaJk+O p/JdYLOO/Mu49GCE8phAueerZt39dDYJx/1+yAXeSuyGM915/i4XBB4LwPFutDDw9B79 VFlD/TPA7/w47Ip3uGe/LCYPEQuvB9dUQp6pFEv+2NJPmPRfp3qZiiGCKO69IawYGaGN 68P1JYLiB+sEuATzZPWBAQmt006EQDQ4kvZzyibDgktYXKNz4AnYvNW3umjhMoD2TXBu unDA== X-Gm-Message-State: AHQUAuYcoxJAYQeYC0HKxO56d6XjLg+lgeDQsdmWlq3wBvxMPEwmHAa5 w7bRe2H3z6nJeDxNnmI6W37JFvYkZswNjujqOVyPuw== X-Received: by 2002:adf:eac2:: with SMTP id o2mr6388092wrn.0.1550926505583; Sat, 23 Feb 2019 04:55:05 -0800 (PST) MIME-Version: 1.0 References: <20190220165013.12774-1-axel.lin@ingics.com> <24E35288-677D-4223-B94A-52A4F37792A8@schinagl.nl> <20190221094237.GA5970@sirena.org.uk> In-Reply-To: From: Axel Lin Date: Sat, 23 Feb 2019 20:54:54 +0800 Message-ID: Subject: Re: [PATCH] regulator: axp20x: Get rid of AXP20X_xxx_START/END/STEPS defines To: Olliver Schinagl Cc: Mark Brown , Chen-Yu Tsai , Priit Laes , Liam Girdwood , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > I will not disagree that it may be extra work to look up the define > (especially if there is no tool tip or split view in the editor) but > reading the whole lot of code, with only the magic values, you still > have to look up the meaning of each magic value, have to guess which one > has the same meaning etc. > > Further more, I do believe far more people reading will find an define > to be more descriptive to read. Whoever needs to actually go in and > fix/change things. I disagree. The reason I sent this patch is because these defines reduce readability. I do care about readability, but in this case these defines make readability worsen. At the context of REGULATOR_LINEAR_RANGE, each fields has well known meaning. When I look at the table with values (I don't care if it's hex or decimal), it tells everything I need to know. I can easily check if any linear ranger cover other ranges. I can easily check if any gap between linar ranges, (probably due to reserved bits). I can easily count the number of entries in each range. I can easily calculate the min/max voltage of each range and double check with datasheet. i.e. If there are something wrong, it's eash to detect it. When you change the values to DEFINES, I have to check the value of each define *one-by-one*. There is no benefit in this case. I don't mean adding DEFINES is wrong. Just in this case it does not help and actually has downside. I only remove AXP20X_xxx_START/END/STEPS defines, not all defines. BTW, just show you an example (from drivers/regulator/88pm8607.c) I don't think change all below values to DEFINES help in readability. static const unsigned int BUCK1_table[] = { 725000, 750000, 775000, 800000, 825000, 850000, 875000, 900000, 925000, 950000, 975000, 1000000, 1025000, 1050000, 1075000, 1100000, 1125000, 1150000, 1175000, 1200000, 1225000, 1250000, 1275000, 1300000, 1325000, 1350000, 1375000, 1400000, 1425000, 1450000, 1475000, 1500000, 0, 25000, 50000, 75000, 100000, 125000, 150000, 175000, 200000, 225000, 250000, 275000, 300000, 325000, 350000, 375000, 400000, 425000, 450000, 475000, 500000, 525000, 550000, 575000, 600000, 625000, 650000, 675000, 700000, 725000, 750000, 775000, }; Regards, Axel