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: <20201020125001.GX456889@lunn.ch>
Date:   Tue, 20 Oct 2020 14:50:01 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     netdev@...r.kernel.org, Jassi Brar <jaswinder.singh@...aro.org>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Willy Liu <willy.liu@...ltek.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Masahisa Kojima <masahisa.kojima@...aro.org>,
        Serge Semin <fancer.lancer@...il.com>
Subject: Re: [PATCH net] netsec: ignore 'phy-mode' device property on ACPI
 systems

On Sun, Oct 18, 2020 at 06:36:25PM +0200, Ard Biesheuvel wrote:
> Since commit bbc4d71d63549bc ("net: phy: realtek: fix rtl8211e rx/tx
> delay config"), the Realtek PHY driver will override any TX/RX delay
> set by hardware straps if the phy-mode device property does not match.
> 
> This is causing problems on SynQuacer based platforms (the only SoC
> that incorporates the netsec hardware), since many were built with
> this Realtek PHY, and shipped with firmware that defines the phy-mode
> as 'rgmii', even though the PHY is configured for TX and RX delay using
> pull-ups.
> 
> >From the driver's perspective, we should not make any assumptions in
> the general case that the PHY hardware does not require any initial
> configuration. However, the situation is slightly different for ACPI
> boot, since it implies rich firmware with AML abstractions to handle
> hardware details that are not exposed to the OS. So in the ACPI case,
> it is reasonable to assume that the PHY comes up in the right mode,
> regardless of whether the mode is set by straps, by boot time firmware
> or by AML executed by the ACPI interpreter.
> 
> So let's ignore the 'phy-mode' device property when probing the netsec
> driver in ACPI mode, and hardcode the mode to PHY_INTERFACE_MODE_NA,
> which should work with any PHY provided that it is configured by the
> time the driver attaches to it. While at it, document that omitting
> the mode is permitted for DT probing as well, by setting the phy-mode
> DT property to the empty string.
> 
> Cc: Jassi Brar <jaswinder.singh@...aro.org>
> Cc: Ilias Apalodimas <ilias.apalodimas@...aro.org>
> Cc: Masami Hiramatsu <mhiramat@...nel.org>
> Cc: Andrew Lunn <andrew@...n.ch>
> Cc: Willy Liu <willy.liu@...ltek.com>
> Cc: "David S. Miller" <davem@...emloft.net>
> Cc: Jakub Kicinski <kuba@...nel.org>
> Cc: Masahisa Kojima <masahisa.kojima@...aro.org>
> Cc: Serge Semin <fancer.lancer@...il.com>
> Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver")
> Signed-off-by: Ard Biesheuvel <ardb@...nel.org>

Reviewed-by: Andrew Lunn <andrew@...n.ch>

    Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ