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] [day] [month] [year] [list]
Date:	Wed, 3 Mar 2010 09:38:46 -0500
From:	Greg Freemyer <greg.freemyer@...il.com>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Sergei Shtylyov <sshtylyov@...sta.com>,
	Anton Vorontsov <avorontsov@...mvista.com>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 09/12] ahci: Introduce ahci_set_em_messages()

On Wed, Mar 3, 2010 at 6:41 AM, Jeff Garzik <jeff@...zik.org> wrote:
> On 03/03/2010 05:40 AM, Sergei Shtylyov wrote:
>>
>> Hello.
>>
>> Jeff Garzik wrote:
>>
>>>>> Factor out some ahci_em_messages handling code from ahci_init_one().
>>>>> We would like to reuse it for non-PCI devices.
>>>>>
>>>>> Signed-off-by: Anton Vorontsov <avorontsov@...mvista.com>
>>>>> ---
>>>>> drivers/ata/ahci.c | 41 ++++++++++++++++++++++++-----------------
>>>>> 1 files changed, 24 insertions(+), 17 deletions(-)
>>>>>
>>>>> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
>>>>> index 18443e9..6694b17 100644
>>>>> --- a/drivers/ata/ahci.c
>>>>> +++ b/drivers/ata/ahci.c
>>>>> @@ -3040,6 +3040,29 @@ static inline void
>>>>> ahci_gtf_filter_workaround(struct ata_host *host)
>>>>> {}
>>>>> #endif
>>>>>
>>>>> +static void ahci_set_em_messages(struct ahci_host_priv *hpriv,
>>>>> + struct ata_port_info *pi)
>>>>> +{
>>>>> + u8 messages;
>>>>> + void __iomem *mmio = hpriv->mmio;
>>>>> + u32 em_loc = readl(mmio + HOST_EM_LOC);
>>>>> + u32 em_ctl = readl(mmio + HOST_EM_CTL);
>>>>> +
>>>>> + if (!ahci_em_messages || !(hpriv->cap & HOST_CAP_EMS))
>>>>> + return;
>>>>> +
>>>>> + messages = (em_ctl & EM_CTRL_MSG_TYPE) >> 16;
>>>>> +
>>>>> + /* we only support LED message type right now */
>>>>> + if ((messages & 0x01) && (ahci_em_messages == 1)) {
>>>>> + /* store em_loc */
>>>>> + hpriv->em_loc = ((em_loc >> 16) * 4);
>>>>
>>>> Could drop unneeded parens, while at it...
>>>
>>> While not strictly necessary, parens often help with readability. I
>>> think the above code looks fine as-is. If the reader has to waste a
>>> few seconds recalling C's operator precedence, that detracts from the
>>> easy reading of the code. Not everyone is like me and has worked on a
>>> C compiler, you know ;-)
>>
>> Come on, parens around the right arg of = are pretty counter-intuitive
>> and so don't add to the readability. :-)
>
> <shrug>  I respectfully disagree.  It is wasteful but does not detract from
> readability at all, IMO.
>
>        Jeff


Re:      hpriv->em_loc = ((em_loc >> 16) * 4);

I think the way it is leaves the reader wondering what used to be
there.  ie. It makes me think there used to be a function call that
was removed, but the parens left in place.

I agree with Sergei that it is a readability issue because it sends
the readers brain off into tangents.

Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ