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
next prev parent 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