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 36039C433F5 for ; Fri, 7 Jan 2022 13:47:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238955AbiAGNra (ORCPT ); Fri, 7 Jan 2022 08:47:30 -0500 Received: from mga09.intel.com ([134.134.136.24]:41869 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238943AbiAGNrZ (ORCPT ); Fri, 7 Jan 2022 08:47:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1641563245; x=1673099245; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=S6EB7K/mWQGJ4edWsfLqzaPrJ4f9R1H4mn7kwvidIW0=; b=YRzwauuXxfhE4s/PeIHjLRCdqvRhZPGpNTPtRQV2gqJS4ddVcNRNHyTL yOkGiM9lhOVdd8uzaE9ppf/W07Ba5b3HjYEDyNYEth6BDTS3E6XBN40uC xioOiRXqFjz/nuARWme4TSo8RPtASY4AtO6JozIgCfZUwqXZSYMm4PnDJ T53fdBTuEhD9vHgOvqEgVvTH0p/ezw6D7zAzcRa8N9uBN3kdfsRBkxZ23 qzL0pWcyfiqk6sKp77cMAsg2jCto9I4JWsY17EqufxcknqktYIaw+2ylZ BJO2JBue73pZKS3LQA04BBDbfFibgNEE/LWQ5MXDtUNMk1w5uEuz2NR7O Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10219"; a="242665027" X-IronPort-AV: E=Sophos;i="5.88,270,1635231600"; d="scan'208";a="242665027" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jan 2022 05:47:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,270,1635231600"; d="scan'208";a="513800161" Received: from linux.intel.com ([10.54.29.200]) by orsmga007.jf.intel.com with ESMTP; 07 Jan 2022 05:47:23 -0800 Received: from linux.intel.com (vwong3-iLBPG3.png.intel.com [10.88.229.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by linux.intel.com (Postfix) with ESMTPS id D5238580806; Fri, 7 Jan 2022 05:47:20 -0800 (PST) Date: Fri, 7 Jan 2022 21:47:17 +0800 From: Wong Vee Khee To: "Russell King (Oracle)" Cc: Alexandre Torgue , Giuseppe Cavallaro , Jose Abreu , Maxime Coquelin , Andrew Lunn , "David S. Miller" , Heiner Kallweit , Jakub Kicinski , Jose Abreu , linux-arm-kernel@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, netdev@vger.kernel.org Subject: Re: [PATCH CFT net-next 0/6] net: stmmac/xpcs: modernise PCS support Message-ID: <20220107134717.GA10144@linux.intel.com> References: <20211217055729.GA14835@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Jan 07, 2022 at 01:40:06PM +0000, Russell King (Oracle) wrote: > On Fri, Dec 17, 2021 at 01:57:29PM +0800, Wong Vee Khee wrote: > > On Thu, Dec 16, 2021 at 01:11:40PM +0000, Russell King (Oracle) wrote: > > > Hi, > > > > > > This series updates xpcs and stmmac for the recent changes to phylink > > > to better support split PCS and to get rid of private MAC validation > > > functions. > > > > > > This series is slightly more involved than other conversions as stmmac > > > has already had optional proper split PCS support. > > > > > > The patches: > > > > > > 1) Provide a function to query the xpcs for the interface modes that > > > are supported. > > > > > > 2) Populates the MAC capabilities and switches stmmac_validate() to use > > > phylink_get_linkmodes(). We do not use phylink_generic_validate() yet > > > as (a) we do not always have the supported interfaces populated, and > > > (b) the existing code does not restrict based on interface. There > > > should be no functional effect from this patch. > > > > > > 3) Populates phylink's supported interfaces from the xpcs when the xpcs > > > is configured by firmware and also the firmware configured interface > > > mode. Note: this will restrict stmmac to only supporting these > > > interfaces modes - stmmac maintainers need to verify that this > > > behaviour is acceptable. > > > > > > 4) stmmac_validate() tail-calls xpcs_validate(), but we don't need it to > > > now that PCS have their own validation method. Convert stmmac and > > > xpcs to use this method instead. > > > > > > 5) xpcs sets the poll field of phylink_pcs to true, meaning xpcs > > > requires its status to be polled. There is no need to also set the > > > phylink_config.pcs_poll. Remove this. > > > > > > 6) Switch to phylink_generic_validate(). This is probably the most > > > contravertial change in this patch set as this will cause the MAC to > > > restrict link modes based on the interface mode. From an inspection > > > of the xpcs driver, this should be safe, as XPCS only further > > > restricts the link modes to a subset of these (whether that is > > > correct or not is not an issue I am addressing here.) For > > > implementations that do not use xpcs, this is a more open question > > > and needs feedback from stmmac maintainers. > > > > > > Please review and test this series. Thanks! > > > > > > > Tested this patch series on my Intel Elkhart Lake setup with Marvell > > 88E1510 PHY. > > > > Everything works perfectly! > > Can I take that as a tested-by please? > Sure. Tested-by: Wong Vee Khee # Intel EHL > It would be good to get some feedback from other stmmac users, since I > believe stmmac is used in multiple different configurations. > > Thanks! > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! 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 9E2E1C433F5 for ; Fri, 7 Jan 2022 13:48:48 +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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=7Ff7rJdD4ArfGr40b5NrDd2NjENuWk5qOdzN216Fpr4=; b=y09nBnvEY4mh/u sP/PXulUvRDdOAy2UsRcu0LXpBD1VcGLSEN2fCTFyXuAL6dBj37XMMCTX1yLai77Nve2WfnjaGcWH pyE/J/1YWefH4UuMmlqXBYKJ/ZW9bv+P5nlWraNRHJxTZ32euo+srcZPWuJNDMXJTycUyJ1lYIYX1 ltN1Y6q7GUI/vksBRinxiYGTzQaIz0FugUNuDwLDi481xoAV2ZwU+H5JfDaJ4p5DwkAU2Z0dj2v+u hHnveQa7y9ugtzsLqqPdUpMDdlh0uP43Ve2uLYPKusE1wflajAG7wZdgvz/z5KPBhTwgrbZgu9qJK HQGmQ4oQ68EeOTCC5UDA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n5pad-0042J3-69; Fri, 07 Jan 2022 13:47:31 +0000 Received: from mga03.intel.com ([134.134.136.65]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n5paZ-0042I9-KM for linux-arm-kernel@lists.infradead.org; Fri, 07 Jan 2022 13:47:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1641563247; x=1673099247; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=S6EB7K/mWQGJ4edWsfLqzaPrJ4f9R1H4mn7kwvidIW0=; b=JSG3nbi94tHsbKVt4fif1zlY/5GKye/VPrRRW53u0HGwdTbNlCoQily9 dIvUPjmdqhcH3MFg+NkZUpl91vjrNvtbg1OYnPCU80tm2qFExiLXz8sxX QKy7Oc4P5BScYAIILD8X2mDWsnZe2D49hxxzGZolA9S+l/o5uLNmP4+63 mLmwctlmwX2vvLGDKO0IwPSGaWC/lcMvb+3AaEXcBE2ggrfh2+Vlwd63i 10LDqvMC3OBpT8C136gb52kmUzFgvh2XJSOkmHp8OezDJ2o2VVW8ZjLf2 6E4+DtjTL1wocc3u5V/11RlnHe5+4RvTTHuzUuOHpX+/I3hW7jSn7bMRS A==; X-IronPort-AV: E=McAfee;i="6200,9189,10219"; a="242820363" X-IronPort-AV: E=Sophos;i="5.88,270,1635231600"; d="scan'208";a="242820363" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jan 2022 05:47:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,270,1635231600"; d="scan'208";a="513800161" Received: from linux.intel.com ([10.54.29.200]) by orsmga007.jf.intel.com with ESMTP; 07 Jan 2022 05:47:23 -0800 Received: from linux.intel.com (vwong3-iLBPG3.png.intel.com [10.88.229.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by linux.intel.com (Postfix) with ESMTPS id D5238580806; Fri, 7 Jan 2022 05:47:20 -0800 (PST) Date: Fri, 7 Jan 2022 21:47:17 +0800 From: Wong Vee Khee To: "Russell King (Oracle)" Cc: Alexandre Torgue , Giuseppe Cavallaro , Jose Abreu , Maxime Coquelin , Andrew Lunn , "David S. Miller" , Heiner Kallweit , Jakub Kicinski , Jose Abreu , linux-arm-kernel@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, netdev@vger.kernel.org Subject: Re: [PATCH CFT net-next 0/6] net: stmmac/xpcs: modernise PCS support Message-ID: <20220107134717.GA10144@linux.intel.com> References: <20211217055729.GA14835@linux.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220107_054727_763090_DB999F58 X-CRM114-Status: GOOD ( 38.86 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jan 07, 2022 at 01:40:06PM +0000, Russell King (Oracle) wrote: > On Fri, Dec 17, 2021 at 01:57:29PM +0800, Wong Vee Khee wrote: > > On Thu, Dec 16, 2021 at 01:11:40PM +0000, Russell King (Oracle) wrote: > > > Hi, > > > > > > This series updates xpcs and stmmac for the recent changes to phylink > > > to better support split PCS and to get rid of private MAC validation > > > functions. > > > > > > This series is slightly more involved than other conversions as stmmac > > > has already had optional proper split PCS support. > > > > > > The patches: > > > > > > 1) Provide a function to query the xpcs for the interface modes that > > > are supported. > > > > > > 2) Populates the MAC capabilities and switches stmmac_validate() to use > > > phylink_get_linkmodes(). We do not use phylink_generic_validate() yet > > > as (a) we do not always have the supported interfaces populated, and > > > (b) the existing code does not restrict based on interface. There > > > should be no functional effect from this patch. > > > > > > 3) Populates phylink's supported interfaces from the xpcs when the xpcs > > > is configured by firmware and also the firmware configured interface > > > mode. Note: this will restrict stmmac to only supporting these > > > interfaces modes - stmmac maintainers need to verify that this > > > behaviour is acceptable. > > > > > > 4) stmmac_validate() tail-calls xpcs_validate(), but we don't need it to > > > now that PCS have their own validation method. Convert stmmac and > > > xpcs to use this method instead. > > > > > > 5) xpcs sets the poll field of phylink_pcs to true, meaning xpcs > > > requires its status to be polled. There is no need to also set the > > > phylink_config.pcs_poll. Remove this. > > > > > > 6) Switch to phylink_generic_validate(). This is probably the most > > > contravertial change in this patch set as this will cause the MAC to > > > restrict link modes based on the interface mode. From an inspection > > > of the xpcs driver, this should be safe, as XPCS only further > > > restricts the link modes to a subset of these (whether that is > > > correct or not is not an issue I am addressing here.) For > > > implementations that do not use xpcs, this is a more open question > > > and needs feedback from stmmac maintainers. > > > > > > Please review and test this series. Thanks! > > > > > > > Tested this patch series on my Intel Elkhart Lake setup with Marvell > > 88E1510 PHY. > > > > Everything works perfectly! > > Can I take that as a tested-by please? > Sure. Tested-by: Wong Vee Khee # Intel EHL > It would be good to get some feedback from other stmmac users, since I > believe stmmac is used in multiple different configurations. > > Thanks! > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel