Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp4557760pxu; Tue, 20 Oct 2020 22:25:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzcz6GgwJOSVaBOvh0tSCCSOXlWKaC+74DTZ0L0TagDXGzhYBqZjmaK8Gma1RHqyaWZTaJ4 X-Received: by 2002:a05:6402:1004:: with SMTP id c4mr1327682edu.149.1603257928820; Tue, 20 Oct 2020 22:25:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603257928; cv=none; d=google.com; s=arc-20160816; b=Gb663V0DfU/lc1/I/HiWccdtxQy2ZZJ1lkfqg5E5fmcJ6+WfkryedqW06s9HZrecA4 +FKEHCHCgSBp+VfJc1cgj04WwUq/PvQT7uog+Ms2xONjBwgK02JrKaopoQaKvrCYFNV2 ggiqyiS5IWaD4HjRx4AKVWZbNAf+GAina7RzoWfLPWKeuHe4r7YuA1rFBFz2j+26jQvf Utxc1g4Y+LzpxPn3ihiFL4e3643JJaaGy8q/a10in0yenRc3q5cDBQvYLEnNn5yKOx86 26WShdjlvkwkmR4ihFo3mofClMN/HxLsZFKJINBninfDhiYaQu/fW0xlGgnvX5Unq4I8 eTOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=clX8o/R+KHVD4HdvcVIn6slrzOWZhMrH731A1pTde+E=; b=sqxnJyWr3q5NwVWdaTSfwWjGP3yhqhCSo6ApvwwXavTTx79rUagJ4zMpPXVYhwrnhy jLMCYMWc5qXXWRte4Tu1cyewK1dSI4wJqm7MIDm3RBic1Ff4nRFUfRkYJi3ANy+ZeTMr Rvqk4zPGlXxx8wWokot+0oQtvXKAn9rB5dtxXjPdJppziRNuBZnN6H/slgzU6R/1eWzE HVyKNPODT4116/KCYj8GSDU8ept+MO1J8Rag9ueSTfDHPhcE4DjfIXVDMCQ6Bc0CBlTO PrUH0GT4OMTuDSKp+Or+sQYUUac4nbv/lqGUAXVhQv7z5cAYaJkJQLucqrAwLq1/m8Rj DWTw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n9si578258ejx.364.2020.10.20.22.25.06; Tue, 20 Oct 2020 22:25:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407826AbgJTOFx (ORCPT + 99 others); Tue, 20 Oct 2020 10:05:53 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:36698 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2407816AbgJTOFx (ORCPT ); Tue, 20 Oct 2020 10:05:53 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1kUsGd-002ftA-OS; Tue, 20 Oct 2020 16:05:35 +0200 Date: Tue, 20 Oct 2020 16:05:35 +0200 From: Andrew Lunn To: Marek Behun Cc: Russell King - ARM Linux admin , Chris Packham , vivien.didelot@gmail.com, f.fainelli@gmail.com, olteanv@gmail.com, davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/3] net: dsa: mv88e6xxx: Don't force link when using in-band-status Message-ID: <20201020140535.GE139700@lunn.ch> References: <20201020034558.19438-1-chris.packham@alliedtelesis.co.nz> <20201020034558.19438-2-chris.packham@alliedtelesis.co.nz> <20201020101552.GB1551@shell.armlinux.org.uk> <20201020154940.60357b6c@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201020154940.60357b6c@nic.cz> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 20, 2020 at 03:49:40PM +0200, Marek Behun wrote: > On Tue, 20 Oct 2020 11:15:52 +0100 > Russell King - ARM Linux admin wrote: > > > On Tue, Oct 20, 2020 at 04:45:56PM +1300, Chris Packham wrote: > > > When a port is configured with 'managed = "in-band-status"' don't force > > > the link up, the switch MAC will detect the link status correctly. > > > > > > Signed-off-by: Chris Packham > > > Reviewed-by: Andrew Lunn > > > > I thought we had issues with the 88E6390 where the PCS does not > > update the MAC with its results. Isn't this going to break the > > 6390? Andrew? > > > > Russell, I tested this patch on Turris MOX with 6390 on port 9 (cpu > port) which is configured in devicetree as 2500base-x, in-band-status, > and it works... > > Or will this break on user ports? User ports is what needs testing, ideally with an SFP. There used to be explicit code which when the SERDES reported link up, the MAC was configured in software with the correct speed etc. With the move to pcs APIs, it is less obvious how this works now, does it still software configure the MAC, or do we have the right magic so that the hardware updates itself. Andrew