From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 62AE12115 for ; Tue, 5 Sep 2023 08:22:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BEC4EC433C7; Tue, 5 Sep 2023 08:22:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1693902165; bh=o+ZGlAMObEDJBIPsyoWsE0YE8FuZ4lKzyNTKvi6BMhY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KiSwNP5L91KskXMYDz3YRi1JHcGLqINOPP0MoeZW2Ditw67Og9uAxojKUEGP2v0kR ILHhtv5oU/ERoIO8Ix4RY2bxpfNhEPq1ub08HBXfBP4cnAWSfToHK/glteix06dbZk m34yk8I9QEphfPGJjFUqkAktXyImdVdq7RCc2O10SC8m5xqwMO2aQzLQ+asam2TSm5 1desbj3jzAQTgPoQZWwaCg2IUvi3bmtViwi3KCe8RA48qp+Pe3Tma8TzLEPGJ0yqul v2j2PN00SB5kdRVNFORgg330GvyvOcnEzbZ91RdrZu8xvgxfjIYg4iaScwjoLT+Usb CmTrZzaGjtmhQ== Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Tue, 05 Sep 2023 10:22:40 +0200 From: Michael Walle To: "Russell King (Oracle)" Cc: Andrew Lunn , Heiner Kallweit , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Yisen Zhuang , Salil Mehta , Florian Fainelli , Broadcom internal kernel review list , =?UTF-8?Q?Marek_B?= =?UTF-8?Q?eh=C3=BAn?= , Xu Liang , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Simon Horman Subject: Re: [PATCH net-next v3 02/11] net: phy: introduce phy_has_c45_registers() In-Reply-To: References: <7be8b305-f287-4e99-bddd-55646285c427@lunn.ch> <867ae3cc05439599d63e4712bca79e27@kernel.org> <7c29bfa7-b4a6-49c9-9369-d98bae98f135@lunn.ch> Message-ID: X-Sender: mwalle@kernel.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi, > Hence why I disagree with your suggestion. So how can we make progress here? I tried Russells suggestion using phy_supports_c45_transfers() and phy_has_c22_registers(). You can find a possible v4 of this series on my github [1]. Some uses of .is_c45 seem to be to test whether the c45_ids are valid. E.g. from the phy.h: * @c45_ids: 802.3-c45 Device Identifiers if is_c45. But if you test if a bit is set, you can skip that. For the opposite test you'd need to have some kind of indication whether c45_ids was populated in the first place. If you convert all these uses of is_c45, there will only be a handful of uses left. And replacing these by phy_supports_c45_transfers() sounds sane to me except for for these two: (1) drivers/net/ethernet/hisilicon/hns/hns_ethtool.c (2) drivers/net/phy/mxl-gpy.c (2) will eventually replaced by my phy_promote_to_c45(). I might reorder the patches, so I'll get rid of the .is_c45 use there before the conversion to phy_supports_c45_transfers(). But honestly, for (1) I don't have any idea whats going on. If I look at the very first commit, it seems that the is_c45 property is used to distinguish loopback handling between a gigabit and a 10g PHY (?). Btw, Russell, I've noticed that phy_restart_aneg() and phy_config_aneg() will test for c22 registers, but phy_aneg_done() tests just for .is_c45. Is that correct? -michael [1] https://github.com/mwalle/linux/tree/feature-c45-over-c22-v4 [2] https://git.kernel.org/torvalds/c/b5996f11ea5496d0445078f47d22c987888ed467