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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 00149C47422 for ; Mon, 29 Jan 2024 13:12:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=oPBu2CZmyNG6wn+6QlTDyQlZywZxoy7gEiH0qOoO/ZA=; b=wMQSUrwfj8vpGh us8Ax3sPLPaxL04L8nzi8s/ZoLGlvdQ9rc+lGPdgegTDQaKLTk/bxxVLdnRo0soxZ4SjFfEO9H1Tf RL1lJSG8exn7DVRZI+ipQdqs1KK6brxsxQvMngpnQpcwNj/27CAkqtn6S+Lj/zP/ueI0R2Q/N8CGo UmcZ277NTCjoaBvEz/MQbD7YznOTpMznTHovCwjHxdz0ODVZDsvp95JUqurqeBVcMnHiCibu6/5QY couBYbNne5PRGCdml7mWEKg/+AdsK8T3J1Sxjx2tMjq1/cdU8eB9KXcLrKJH7379oJU+Dq5eCByvb ExIgdnNULmD5d8GQkTOg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rURQs-0000000Cnne-3ZCT; Mon, 29 Jan 2024 13:12:14 +0000 Received: from mgamail.intel.com ([198.175.65.12]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rURQp-0000000CnlY-3WGx for linux-arm-kernel@lists.infradead.org; Mon, 29 Jan 2024 13:12:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1706533932; x=1738069932; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=+Ew5LUI3g/pPiKdhhQ2t8V+CzBXr7IlkIiYR6xaMc2Q=; b=FoKgNuxXiadScDOvUIei8mUbe13xyXwGthVQOvzulh9ES//yI4GEPN7i KdHB05e4QsvoIhOHZ1VbzW2N3zLpBl6ffgME/9fSjmPuuPp+JYPrPhLL6 hQj87ebFck50oyP51zv7GbTpR8M3YtzviEh4Zr04N1ZUBZ+t55SUcmVAT GhUH5NOBEmszJiC0U5V3cseOExklGIk9fGziuaFnR6sFTko/9X2LgkuZI NfP/5mNJbt5+/ZoR5zv5zvPVgSFR3n/tagh80NBzsp9/8gp/LYqlkEIGJ CacpXxqo3lWAA6J3dX29zVXZxFSFhB346xqHx1txAdPxaf9oob34DIYhW g==; X-IronPort-AV: E=McAfee;i="6600,9927,10967"; a="10328239" X-IronPort-AV: E=Sophos;i="6.05,227,1701158400"; d="scan'208";a="10328239" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jan 2024 05:12:10 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10967"; a="878068136" X-IronPort-AV: E=Sophos;i="6.05,227,1701158400"; d="scan'208";a="878068136" Received: from choongyo-mobl.gar.corp.intel.com (HELO [10.247.122.111]) ([10.247.122.111]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jan 2024 05:11:56 -0800 Message-ID: Date: Mon, 29 Jan 2024 21:11:53 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v2 0/5] TSN auto negotiation between 1G and 2.5G Content-Language: en-US To: "Russell King (Oracle)" , Andrew Lunn Cc: Rajneesh Bhardwaj , David E Box , Hans de Goede , Mark Gross , Jose Abreu , Heiner Kallweit , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , =?UTF-8?Q?Marek_Beh=C3=BAn?= , Jean Delvare , Guenter Roeck , Giuseppe Cavallaro , Alexandre Torgue , Jose Abreu , Maxime Coquelin , Richard Cochran , Philipp Zabel , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Wong Vee Khee , Jon Hunter , Jesse Brandeburg , Revanth Kumar Uppala , Shenwei Wang , Andrey Konovalov , Jochen Henneberg , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, platform-driver-x86@vger.kernel.org, linux-hwmon@vger.kernel.org, bpf@vger.kernel.org, Voon Wei Feng , Tan Tee Min , Michael Sit Wei Hong , Lai Peter Jun Ann References: <20230804084527.2082302-1-yong.liang.choong@linux.intel.com> <5bd05ba2-fd88-4e5c-baed-9971ff917484@lunn.ch> <37fe9352-ec84-47b8-bb49-9441987ca1b9@lunn.ch> <0098eaf3-717a-4b50-b2a0-4b28b75b0735@lunn.ch> From: Choong Yong Liang In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240129_051211_991362_BD93F0CF X-CRM114-Status: GOOD ( 23.05 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 21/9/2023 10:55 pm, Russell King (Oracle) wrote: > On Thu, Sep 21, 2023 at 04:41:20PM +0200, Andrew Lunn wrote: >> On Thu, Sep 21, 2023 at 03:12:19PM +0100, Russell King (Oracle) wrote: >>> On Thu, Sep 21, 2023 at 03:21:00PM +0200, Andrew Lunn wrote: >>>>> Hi Andrew, >>>>> >>>>> After conducting a comprehensive study, it seems that implementing >>>>> out-of-band for all link modes might not be feasible. I may have missed some >>>>> key aspects during my analysis. >>>>> >>>>> Would you be open to sharing a high-level idea of how we could potentially >>>>> make this feasible? Your insights would be greatly appreciated. >>>> >>>> stmmac_mac_link_up() gets passed interface, speed and duplex. That >>>> tells you what the PHY has negotiated. Is there anything else you need >>>> to know? >>> >>> The problem is... the stmmac driver is utter bollocks - that information >>> is *not* passed to the BSP. Instead, stmmac parse and store information >>> such as the PHY interface mode at initialisation time. BSPs also re- >>> parse and store e.g. the PHY interface mode at initialisation time. >>> The driver ignores what it gets from phylink. >>> >>> The driver is basically utter crap. That's an area I _had_ patches to >>> clean up. I no longer do. stmmac is crap crap crap and will stay crap >>> until they become more receptive to patches to fix it, even if the >>> patches are not 100% to their liking but are in fact correct. Maybe >>> if I ever decide to touch that driver in the future. Which I doubt >>> given my recent experience. >> >> Hi Russell >> >> You pointed out the current proposal will break stuff. Do you see a >> way forward for this patchset which does not first involve actually >> cleaning up of this driver? > > As I said in one of my replies, it would really help if the author can > provide a table showing what is attempting to be achieved here. With > that, we should be able to work out exactly what is required, what > needs to change in stmmac, etc. > Thank you, Russell and Andrew for the comments. What I'm trying to achieve here is to enable interface mode switching between 2500basex and SGMII interfaces for Intel platforms. I did based on the DM7052 SFP module and BCM84881 PHY to make the necessary changes in the new version of my patch series. In the new patch series, the 'allow_switch_interface' flag was introduced, based on the 'allow_switch_interface' flag, the interface mode is configured to PHY_INTERFACE_MODE_NA within the 'phylink_validate_phy' function. This setting allows all ethtool link modes that are supported and advertised will be published. Then interface mode switching occurs based on the selection of different link modes. During the interface mode switching, the code will go through the `phylink_major_config` function and based on the interface mode to select PCS and PCS negotiation mode to configure PCS. Then, the MAC driver will perform SerDes configuration according to the interface mode. I did rewrite the description for the new patch series, hoping that it is clear to describe the whole intention of the changes. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel