From patchwork Tue May 30 12:26:21 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lukasz Majewski X-Patchwork-Id: 100827 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp2152163vqr; Tue, 30 May 2023 05:46:06 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6cPFQNZ97PtnFp726fqESwDxYDeQVbk8UgXhSKJeJaCKMkDGoEIdM/e5pFeg2LkL4mciey X-Received: by 2002:a05:6a20:938d:b0:106:9266:4448 with SMTP id x13-20020a056a20938d00b0010692664448mr2538271pzh.16.1685450765806; Tue, 30 May 2023 05:46:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685450765; cv=none; d=google.com; s=arc-20160816; b=ZbH3HjRu1y1lN3PQXGJK5gbEuN1zlRAUOyFPAtRUelN4PHI324MCl+s2Di+mijdWO4 6LldCgod+1myUR2tOy83jidTaG3pfpI7Rg3UK9xMYFPnlQxDYv+bV36rbpqxRYMUPFvY BnYg1BPl3j+f2xEH+LxPcDLqHtO2IbpRUeGJ72xZwSjUwSDenn0+32GnF3o4geg04w7/ SbNFVGEc2qYyo4HPG4USWRoOpf4yohBShWA90IO1tCLjIEz63tS/XjuuRQk7q4CsYRrf kwfzodPa+Mxtxa9pB/yHFj+sQCrrVJFFi1A1ncShZ0EBnz6MBU+TL8zdVuSC2fRQnoR/ aqDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=HCxUDLptga1ZY26RbeXABUOOkjpCerVJLwimbWQwyU8=; b=y90HXTDk/YH5AdVbnYbuMJLWo5JkortdoMqqEEcPyuHx/sDJMZx6bgKQjzt/zxPEd7 CvLmeQV3IQaqpZtah1qdTmW2ZOSqeGkwiRe6KKpT8SCrfW4cIZus82LIhPDlfNaLKUh6 hBUnwFmunO9WH/mpXo9EBmvzgQg/BC3V5sVxNBnPga9Fvb5mBUYJpwJS/MB4Vf2dPpFN sCWCheo/8YgSD3RS3ze7CmBiDcTxy3Kumq1Q0NClUgtTrN4ylGhJPTBdw7O3bV7ETmOj 4B6GqZtbvvxgdfh92Km/A9wVSrl3YO6ryTx/9dc/pY43Cc5o7rPT3/7W93q7PmQFGilN gzjA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@denx.de header.s=phobos-20191101 header.b=JpfxQZ2G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=denx.de Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h12-20020a63384c000000b00528c6c2ea96si10907554pgn.306.2023.05.30.05.45.51; Tue, 30 May 2023 05:46:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@denx.de header.s=phobos-20191101 header.b=JpfxQZ2G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=denx.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230303AbjE3M1B (ORCPT + 99 others); Tue, 30 May 2023 08:27:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53708 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229806AbjE3M06 (ORCPT ); Tue, 30 May 2023 08:26:58 -0400 Received: from phobos.denx.de (phobos.denx.de [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37054E42; Tue, 30 May 2023 05:26:38 -0700 (PDT) Received: from localhost.localdomain (85-222-111-42.dynamic.chello.pl [85.222.111.42]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: lukma@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id 2D0D985F52; Tue, 30 May 2023 14:26:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1685449595; bh=HCxUDLptga1ZY26RbeXABUOOkjpCerVJLwimbWQwyU8=; h=From:To:Cc:Subject:Date:From; b=JpfxQZ2G7jg0wSVBi2cOntG4yyCH1s2egcZzvVd5FjNL+SKgIAGoDMt0Q/redNUL9 +/Fc42ob9MGrQzAU71wrEuICXBHNgX0Yt7jAPXV2I99x5rJ1ZM5emKP2qmXiZIf/Jb 6rtL8sTbCheZglPY3ImO/bQ87hAfGA2vHG5SB7SagMAbykeTxGyGU/Gn74AW7gfc5E 0lMlC0S9GwXsAL5o+pj0WRXh/ocBstfHhKxjDJ/t2Mqyh0iqXsR3i2/C7nwD1mHRwx nFdGwh65F37hd/qaysI15AaY9mZpW2KBCWsy8uM56uz0SbqtoI8zLVUY4myA4/mDlj 2ho0LTsD2R9SQ== From: Lukasz Majewski To: Andrew Lunn , Russell King Cc: Vivien Didelot , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Jakub Kicinski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Lukasz Majewski Subject: [RFC] net: dsa: slave: Advertise correct EEE capabilities at slave PHY setup Date: Tue, 30 May 2023 14:26:21 +0200 Message-Id: <20230530122621.2142192-1-lukma@denx.de> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1767323221809792193?= X-GMAIL-MSGID: =?utf-8?q?1767323221809792193?= One can disable in device tree advertising of EEE capabilities of PHY when 'eee-broken-100tx' property is present in DTS. With DSA switch it also may happen that one would need to disable EEE due to some network issues. Corresponding switch DTS description: switch@0 { ports { port@0 { reg = <0>; label = "lan1"; phy-handle = <&switchphy0>; }; } mdio { switchphy0: switchphy@0 { reg = <0>; eee-broken-100tx; }; }; This patch adjusts the content of MDIO_AN_EEE_ADV in MDIO_MMD_AN "device" so the phydev->eee_broken_modes are taken into account from the start of the slave PHYs. As a result the 'ethtool --show-eee lan1' shows that EEE is not supported from the outset. Questions: - Is the genphy_config_eee_advert() appropriate to be used here? As I found this issue on 5.15 kernel, it looks like mainline now uses PHY features for handle EEE (but the aforementioned function is still present in newest mainline - v6.4-rc1). - I've also observed strange behaviour for EEE capability register: Why the value in MDIO_MMD_PCS device; reg MDIO_PCS_EEE_ABLE is somewhat "volatile" - in a sense that when I use: ethtool --set-eee lan2 eee off It is cleared by PHY itself to 0x0 (from 0x2) and turning it on again is not working. Is this expected? Or am I missing something? Signed-off-by: Lukasz Majewski --- net/dsa/slave.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/dsa/slave.c b/net/dsa/slave.c index 353d8fff3166..712923c7d4e2 100644 --- a/net/dsa/slave.c +++ b/net/dsa/slave.c @@ -2247,6 +2247,7 @@ static int dsa_slave_phy_setup(struct net_device *slave_dev) phylink_destroy(dp->pl); } + genphy_config_eee_advert(slave_dev->phydev); return ret; }