lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54BDB860.9080704@realsil.com.cn>
Date:	Tue, 20 Jan 2015 02:07:26 +0000
From:	敬锐 <micky_ching@...lsil.com.cn>
To:	Lee Jones <lee.jones@...aro.org>
CC:	"sameo@...ux.intel.com" <sameo@...ux.intel.com>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"rogerable@...ltek.com" <rogerable@...ltek.com>,
	王炜 <wei_wang@...lsil.com.cn>
Subject: Re: [PATCH 06/10] mfd: rtsx: update phy register


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@...lsil.com.cn  wrote:
>>> > >
>>>> > >>From: Micky Ching<micky_ching@...lsil.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 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.

regards.
micky.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ