netdev - Re: [PATCH] net: macb: Correct usage of MACB_CAPS_CLK_HW

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]

Message-ID: <20201223194158.GG9673@ediswmail.ad.cirrus.com>
Date:   Wed, 23 Dec 2020 19:41:58 +0000
From:   Charles Keepax <ckeepax@...nsource.cirrus.com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     <nicolas.ferre@...rochip.com>, <claudiu.beznea@...rochip.com>,
        <davem@...emloft.net>, <kuba@...nel.org>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] net: macb: Correct usage of MACB_CAPS_CLK_HW_CHG flag on
 Zynq

On Wed, Dec 23, 2020 at 08:24:41PM +0100, Andrew Lunn wrote:
> On Wed, Dec 23, 2020 at 06:41:44PM +0000, Charles Keepax wrote:
> > A new flag MACB_CAPS_CLK_HW_CHG was added and all callers of
> > macb_set_tx_clk were gated on the presence of this flag.
> > 
> > if (!bp->tx_clk || !(bp->caps & MACB_CAPS_CLK_HW_CHG))
> > 
> > However the flag was not added to anything other than the new
> > sama7g5_gem, turning that function call into a no op for all other
> > systems. This breaks the networking on Zynq.
> 
> I'm not sure this is the correct fix. I think the original patch might
> be broken. Look at the commit message wording:
> 
>                                                       The patch adds a new
>     capability so that macb_set_tx_clock() to not be called for IPs having
>     this capability
> 
> So MACB_CAPS_CLK_HW_CHG disables something, not enables it. So i
> suspect this if statement is wrong and needs fixing.

Hmm... good spot, hopefully the original author can comment. The
flag name reads to me as clock rate can change, the commit message
definitely implies the opposite.

So it really depends if this function was intended to be skipped
for the sama7g5 gem or emac.

Thanks,
Charles