public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: 敬锐 <micky_ching@realsil.com.cn>
Cc: "sameo@linux.intel.com" <sameo@linux.intel.com>,
	"devel@linuxdriverproject.org" <devel@linuxdriverproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"rogerable@realtek.com" <rogerable@realtek.com>,
	王炜 <wei_wang@realsil.com.cn>
Subject: Re: [PATCH 06/10] mfd: rtsx: update phy register
Date: Tue, 20 Jan 2015 09:45:57 +0000	[thread overview]
Message-ID: <20150120094557.GL5767@x1> (raw)
In-Reply-To: <54BDB860.9080704@realsil.com.cn>

On Tue, 20 Jan 2015, 敬锐 wrote:
> On 01/19/2015 03:47 PM, Lee Jones wrote:
> > On Mon, 19 Jan 2015, 敬锐 wrote:
> >> >On 01/18/2015 08:29 PM, Lee Jones wrote:
> >>> > >On Thu, 15 Jan 2015,micky_ching@realsil.com.cn  wrote:
> >>> > >
> >>>> > >>From: Micky Ching<micky_ching@realsil.com.cn>
> >>>> > >>
> >>>> > >>update phy register value and using direct value instead of macros.
> >>>> > >>It is much easier to debug using constant value than a lot of macros.
> >>>> > >>We usually need compare the value directly to check the configure.
> >>> > >NACK.  This is the opposite of what I would like to see.
> >>> > >
> >> >When we debug, we usually need to compare the value provided from hardware,
> >> >of course we can compare by print them to kernel log. but I think it more
> >> >convenient from source code. And we only set phy register when
> >> >initialize chip,
> >> >so the value will not scattered everywhere, we will not benefit from macros.
> >> >
> >> >if we want to know the meaning of setting, we can look at the register
> >> >define.
> > This is not acceptable and is the complete opposite of what we're
> > trying to achieve.  I promote readability (by humans) as one of the
> > highest priorities when writing code.  0xFE6C is far from readable.
> >
> Because the truly thing we concerned is the address and value, not
> a lot of macros. 0xFE6C is a magic number, but a lot of macros
> even hide the magic number we curious. To verify if the source
> code is right, we only need to compare the value, if too much macros
> joined together, the work is boring and easy to inject errors.

I completely disagree and think the converse to be true.  It's _much_
easier to get the magic number incorrect.

> I hate magic number too, but in this case using magic number
> is deserved for correctness.
> 
> Two method can help enhance readability.
> (1). define register address and values
> If we want to know what the bit field means, we can jump to the register
> define. This is very easy by tag system.
> eg.
> rtsx_pci_write_phy_register(pcr, PHY_BPCR, 0x05C0);
> we can jump to PHY_BPCR to see bit-field define.
>
> (2). add comment for magic number.
> I don't like comment.
> 
> If you still like macro list, I will update the register next patch.

Defining register values and bit fields is the _correct_ way to do
this.  Using magic numbers is the _wrong_ way.

I'm sorry Micky, but I am not moving on this.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2015-01-20  9:46 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-15 11:18 [PATCH 00/10] mfd: rtsx: add support for new rts524A and rts525A micky_ching
2015-01-15 11:18 ` [PATCH 01/10] mfd: rtsx: replace TAB by SPC after #define micky_ching
2015-01-18 12:39   ` Lee Jones
2015-01-19  1:23     ` 敬锐
2015-01-19  7:49       ` Lee Jones
2015-01-15 11:18 ` [PATCH 02/10] mfd: rtsx: place register address and values togather micky_ching
2015-01-18 12:35   ` Lee Jones
2015-01-15 11:19 ` [PATCH 03/10] mfd: rtsx: add debug info when access register failed micky_ching
2015-01-18 12:35   ` Lee Jones
2015-01-15 11:19 ` [PATCH 04/10] mfd: rtsx: update PETXCFG address micky_ching
2015-01-18 12:31   ` Lee Jones
2015-01-15 11:19 ` [PATCH 05/10] mfd: rtsx: update driving settings micky_ching
2015-01-18 12:32   ` Lee Jones
2015-01-15 11:19 ` [PATCH 06/10] mfd: rtsx: update phy register micky_ching
2015-01-18 12:29   ` Lee Jones
2015-01-19  1:55     ` 敬锐
2015-01-19  7:47       ` Lee Jones
2015-01-20  2:07         ` 敬锐
2015-01-20  9:45           ` Lee Jones [this message]
2015-01-15 11:19 ` [PATCH 07/10] mfd: rtsx: remove LCTLR defination micky_ching
2015-01-18 12:28   ` Lee Jones
2015-01-19  1:12     ` 敬锐
2015-01-19  8:06       ` Lee Jones
2015-01-15 11:19 ` [PATCH 08/10] mfd: rtsx: add support for rts524A micky_ching
2015-01-18 12:20   ` Lee Jones
2015-01-19  2:32     ` 敬锐
2015-01-19  2:36     ` 敬锐
2015-01-19  7:40       ` Lee Jones
2015-01-19  3:09     ` 敬锐
2015-01-19  7:38       ` Lee Jones
2015-01-15 11:19 ` [PATCH 09/10] mfd: rtsx: add support for rts525A micky_ching
2015-01-18 11:13   ` Lee Jones
2015-01-19  2:53     ` 敬锐
2015-01-19  7:41       ` Lee Jones
2015-01-15 11:19 ` [PATCH 10/10] mfd: rtsx: using pcr_dbg replace dev_dbg micky_ching
2015-01-18 10:43   ` Lee Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150120094557.GL5767@x1 \
    --to=lee.jones@linaro.org \
    --cc=devel@linuxdriverproject.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=micky_ching@realsil.com.cn \
    --cc=rogerable@realtek.com \
    --cc=sameo@linux.intel.com \
    --cc=wei_wang@realsil.com.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox