All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.