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: <trinity-eb5bbb4a-b96f-4436-ae9f-8ee5f4b8fe9b-1678639848562@3c-app-gmx-bap51>
Date:   Sun, 12 Mar 2023 17:50:48 +0100
From:   Frank Wunderlich <frank-w@...lic-files.de>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Daniel Golle <daniel@...rotopia.org>,
        Vladimir Oltean <vladimir.oltean@....com>,
        netdev@...r.kernel.org, linux-mediatek@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Heiner Kallweit <hkallweit1@...il.com>,
        Lorenzo Bianconi <lorenzo@...nel.org>,
        Mark Lee <Mark-MC.Lee@...iatek.com>,
        John Crispin <john@...ozen.org>, Felix Fietkau <nbd@....name>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        DENG Qingfang <dqfext@...il.com>,
        Landen Chao <Landen.Chao@...iatek.com>,
        Sean Wang <sean.wang@...iatek.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Vladimir Oltean <olteanv@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Jianhui Zhao <zhaojh329@...il.com>,
        Bjørn Mork <bjorn@...k.no>,
        Alexander Couzens <lynxis@...0.eu>,
        Frank Wunderlich <frank-w@...lic-files.de>
Subject: Aw: Re: Re: [PATCH net-next v12 08/18] net: ethernet: mtk_eth_soc:
 fix 1000Base-X and 2500Base-X modes

Just to make it clear...the issue with the copper-sfps is no regression of this series it exists before.
i only had none of them to test for until this weekend....my 1g fibre-sfp were working fine with the inband-flag.

this patch tries to fix it in mtk driver, this was rejected (as far as i understand it should be handled in phylink core instead of pcs driver).
and no more in the v13, so we try to fix it another way.

whatever i do in phylink_parse_mode the link is always inband...i tried to add a new state to have the configuration not FIXED or PHY or INBAND

drivers/net/phy/phylink.c
@@ -151,6 +151,7 @@ static const char *phylink_an_mode_str(unsigned int mode)
                [MLO_AN_PHY] = "phy",
                [MLO_AN_FIXED] = "fixed",
                [MLO_AN_INBAND] = "inband",
+               [MLO_AN_INBAND_DISABLED] = "inband disabled",
        };

include/linux/phylink.h
@@ -20,6 +20,7 @@ enum {
        MLO_AN_PHY = 0, /* Conventional PHY */
        MLO_AN_FIXED,   /* Fixed-link mode */
        MLO_AN_INBAND,  /* In-band protocol */
+       MLO_AN_INBAND_DISABLED

is my start the right way?

i noticed that sfp-handling is always calling phylink_sfp_config_optical and this calls phylink_sfp_set_config with fixed MLO_AN_INBAND.

https://elixir.bootlin.com/linux/v6.3-rc1/source/drivers/net/phy/phylink.c#L3038

This looks wrong for me...
First not all sfp are optical (ethtool shows FIBRE for copper-sfps too) and not all use inband mode...
after changing this to my new state i see it in the configuration message.

@@ -3044,7 +3049,7 @@ static int phylink_sfp_config_optical(struct phylink *pl)

        pl->link_port = pl->sfp_port;

-       phylink_sfp_set_config(pl, MLO_AN_INBAND, pl->sfp_support, &config);
+       phylink_sfp_set_config(pl, MLO_AN_INBAND_DISABLED, pl->sfp_support, &config);

        return 0;
 }

root@...-r3:~# ip link set eth1 up
[   30.186811] mtk_soc_eth 15100000.ethernet eth1: configuring for inband disabled/2500base-x link mode

changing the mode itself is not enough for getting the link up...
have not found spacial handling of MLO_AN_INBAND except in phylink_mac_initial_config where i added my mode to the
MLO_AN_INBAND as fallthrough (there is not autoneg set/done). also disabled link_config.an_enabled whereever i've found,
but this does not bring up the link on the copper sfps...it looks like there must be a state-change...

but here i'm stuck with my limited knowledge ;(

regards Frank

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ