netdev - Re: [PATCH v2 1/4] net: phy: at803x: Document RGMII RX and TX clock delay issues

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: <1c35e791-c181-2855-8463-b3b0ef5367a2@codeaurora.org>
Date:   Fri, 21 Jul 2017 09:06:44 -0500
From:   Timur Tabi <timur@...eaurora.org>
To:     Marc Gonzalez <marc_gonzalez@...madesigns.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>, Mans Rullgard <mans@...sr.com>,
        Martin Blumenstingl <martin.blumenstingl@...il.com>,
        Grygorii Strashko <grygorii.strashko@...com>,
        Fabio Estevam <fabio.estevam@....com>,
        Zefir Kurtisi <zefir.kurtisi@...atec.com>,
        Daniel Mack <zonque@...il.com>
Cc:     netdev <netdev@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "David S. Miller" <davem@...emloft.net>,
        Thibaud Cornic <thibaud_cornic@...madesigns.com>,
        Mason <slash.tmp@...e.fr>
Subject: Re: [PATCH v2 1/4] net: phy: at803x: Document RGMII RX and TX clock
 delay issues

On 7/21/17 8:29 AM, Marc Gonzalez wrote:
> I don't understand what you're saying.
> 
> It is a correct observation that the code enabling
> RGMII RX clock delay is a NOP, since that bit will
> always be set at that point.
> 
> The spec for the 8035 (I haven't checked for 8030 and 8031,
> is that what you meant by "other systems"?) states that
> Sel_clk125m_dsp, which is described as:
> "Control bit for rgmii interface rx clock delay"
> is 1 after HW reset, 1 after SW reset.
> 
> So my statement "RX clock delay is enabled at reset"
> is universally true. It's not just on some systems.

Ok, taken out of context, the comment doesn't really explain why the 
code is the way it is.  I'm not really happy about the word "assumes". 
Maybe you should add a sentence explaining when the code is NOT a no-op.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.