From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6AC25C05027 for ; Wed, 1 Feb 2023 17:12:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231917AbjBARMp (ORCPT ); Wed, 1 Feb 2023 12:12:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39284 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229576AbjBARMm (ORCPT ); Wed, 1 Feb 2023 12:12:42 -0500 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2D0B69EED; Wed, 1 Feb 2023 09:12:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=hGzG/sA63e+whllyzMxtyCU4dN4cHFGosz/XbA42Rbo=; b=QpRVxHzm/Z+iz1HHu18q5ar0Vg bytU7wJkj+A/7MJ2hijJHqPaSPHS8yMZBVyppjYl22azUXzXNZeJixr0tr8sdt0YhqH4FFtxqN/lG gX427TufG1zr5RTVRMP1Gusrm23fPQkN56hivbi1QA044K/AZ2laTtcN0WO9FbwuUFSo=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1pNGet-003ooW-4K; Wed, 01 Feb 2023 18:12:31 +0100 Date: Wed, 1 Feb 2023 18:12:31 +0100 From: Andrew Lunn To: Oleksij Rempel Cc: Woojung Huh , UNGLinuxDriver@microchip.com, Vivien Didelot , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Wei Fang , Heiner Kallweit , kernel@pengutronix.de, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Arun.Ramadoss@microchip.com, intel-wired-lan@lists.osuosl.org Subject: Re: [PATCH net-next v4 02/23] net: phy: add genphy_c45_read_eee_abilities() function Message-ID: References: <20230201145845.2312060-1-o.rempel@pengutronix.de> <20230201145845.2312060-3-o.rempel@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230201145845.2312060-3-o.rempel@pengutronix.de> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 01, 2023 at 03:58:24PM +0100, Oleksij Rempel wrote: > Add generic function for EEE abilities defined by IEEE 802.3 > specification. For now following registers are supported: > - IEEE 802.3-2018 45.2.3.10 EEE control and capability 1 (Register 3.20) > - IEEE 802.3cg-2019 45.2.1.186b 10BASE-T1L PMA status register > (Register 1.2295) > > Since I was not able to find any flag signaling support of this > registers, we should detect link mode abilities first and then based on > this abilities doing EEE link modes detection. Hi Oleksij There was a discussion along these lines with Chris Healy recently. The meson-gxl PHYs don't have these registers, and reads return 0xffff. The 802.3 2018 standard says the top 2 bits are reserved and should read as 0. Also, it seems unlikely anybody will build a PHY which supports 100GBASE-R deep sleep all the way down to 100BASE-TX EEE. So i would suggest adding a check when reading MDIO_PCS_EEE_ABLE and if it is 0xffff assume EEE is not supported. > + val = phy_read_mmd(phydev, MDIO_MMD_PCS, MDIO_PCS_EEE_ABLE); > + if (val < 0) > + return val; > + > + mii_eee_100_10000_adv_mod_linkmode_t(phydev->supported_eee, val); > + > + /* Some buggy devices claim not supported EEE link modes */ > + linkmode_and(phydev->supported_eee, phydev->supported_eee, > + phydev->supported); That comment could be improved. What i think you mean is /* Some buggy devices indicate EEE link modes in MDIO_PCS_EEE_ABLE which they don't support as indicated by BMSR, ESTATUS etc. */ Andrew