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 X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D9D4AC3F2CD for ; Sat, 29 Feb 2020 17:06:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A47902072A for ; Sat, 29 Feb 2020 17:06:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="Il+UOTDq" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727196AbgB2RGw (ORCPT ); Sat, 29 Feb 2020 12:06:52 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:39846 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727176AbgB2RGw (ORCPT ); Sat, 29 Feb 2020 12:06:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=kvDszULOHU2THHkE1gFvbsX46BUGU952QWYH97S/Pzg=; b=Il+UOTDqA5c1PQLZvj5CipCZ0q N2WADRXXFNz3ChvyHB1FfsTEGpQNebtYp4P7JE/7ZOHs8cGLsdkTdddtpk0UIIed747rI8xSzY7Mq kAt0hBZ42MGrfdJxceCOKomRxAaSvzRSuNDqSnS4ueBD4y9unuVK6949+zL/Z8wGolpw=; Received: from andrew by vps0.lunn.ch with local (Exim 4.93) (envelope-from ) id 1j85ZZ-000263-Su; Sat, 29 Feb 2020 18:06:41 +0100 Date: Sat, 29 Feb 2020 18:06:41 +0100 From: Andrew Lunn To: Russell King - ARM Linux admin Cc: Florian Fainelli , Vivien Didelot , "David S. Miller" , Jakub Kicinski , Ioana Ciornei , Vladimir Oltean , netdev@vger.kernel.org Subject: Re: [PATCH net] net: dsa: fix phylink_start()/phylink_stop() calls Message-ID: <20200229170641.GE6305@lunn.ch> References: <20200229154215.GD6305@lunn.ch> <20200229164538.GB25745@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200229164538.GB25745@shell.armlinux.org.uk> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi Russell > > The current code in dsa_slave_open() first enables the port, then > > calls phylink_start(). So maybe we should keep the ordering the same? > > However, dsa_port_setup() does it in the reverse order, so it was a > bit of guess work which is right. So, if the port needs to be enabled > first, then the dsa_port_setup() path for DSA and CPU ports is wrong. > > It's not clear what dsa_port_enable() actually does, and should a port > be enabled before its interface mode and link parameters have been > set? Agreed, it is not clearly defined. port_enable()/port_disable() are mostly used for power saving. If a port is not used, it can be turned off. Having phylink for DSA and CPU ports is a new thing. Slaves have always had phylib/phylink. So i think it would be safest to follow the order used for slave interfaces, enable the port first, then start phylink. We should probably also change the order for DSA and CPU ports so it is consistent. Andrew