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 83DC8C43334 for ; Fri, 22 Jul 2022 21:54:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235591AbiGVVyY (ORCPT ); Fri, 22 Jul 2022 17:54:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52774 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229667AbiGVVyX (ORCPT ); Fri, 22 Jul 2022 17:54:23 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [185.16.172.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C33F2A43B; Fri, 22 Jul 2022 14:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=9ul5HRwjM7WDUxRSXRBNR66kxi05F3aeIEeMEbXyF3k=; b=PDN/3e30eHLs8BtaLZ0T8TMOyN N2HcfxKuYaTro4pIBdbot118lnyGcp4WCsIp6ajuJ6Re71SWmWgaYRfmrLC82jB15SXOQTPKLLYNs XsLQ0dEg5gllyf/TMUKfxhTKKM30CKfds4fGXZzIb8Jw2ZlT9Rxg6YRhqh0h3L/HVMKY=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1oF0ai-00BBNY-9v; Fri, 22 Jul 2022 23:53:48 +0200 Date: Fri, 22 Jul 2022 23:53:48 +0200 From: Andrew Lunn To: "Russell King (Oracle)" Cc: Vladimir Oltean , Marek =?iso-8859-1?Q?Beh=FAn?= , Heiner Kallweit , Alexandre Belloni , Alvin __ipraga , Andy Shevchenko , Claudiu Manoil , Daniel Scally , "David S. Miller" , DENG Qingfang , Eric Dumazet , Florian Fainelli , George McCollister , Greg Kroah-Hartman , Hauke Mehrtens , Heikki Krogerus , Jakub Kicinski , Kurt Kanzenbach , Landen Chao , Linus Walleij , linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Matthias Brugger , netdev@vger.kernel.org, Paolo Abeni , "Rafael J. Wysocki" , Sakari Ailus , Sean Wang , UNGLinuxDriver@microchip.com, Vivien Didelot , Woojung Huh Subject: Re: [PATCH net-next 3/6] net: dsa: add support for retrieving the interface mode Message-ID: References: <20220721182216.z4vdaj4zfb6w3emo@skbuf> <20220721213645.57ne2jf7f6try4ec@skbuf> <20220722105238.qhfq5myqa4ixkvy4@skbuf> <20220722124629.7y3p7nt6jmm5hecq@skbuf> <20220722165600.lldukpdflv7cjp4j@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > I still don't understand your point - because you seem to be conflating > two different things (at least as I understand it.) > > We have this: > > port@N { > reg = ; > label = "cpu"; > ethernet = <ðX>; > }; > > This specifies that the port operates at whatever interface mode and > settings gives the maximum speed. There is no mention of a "managed" > property, and therefore (Andrew, correct me if I'm wrong) in-band > negotiation is not expected to be used. I would actually say it is undefined if in-band is expected or not. Pretty much everything is undefined, expect 'maximum speed'. If you can choose between SGMII and 1000BaseX, GMII or RGMII, it is not defined which you should pick. However generally, *MII and a SERDES are mutually exclusive in hardware, except for the 6352 which have some ports with both. The switches do have strapping pins which can configure most ports into specific modes, which is probably want most boards do, and the "maximum speed" probably does not in fact adjust the port mode unless really required. It does however configure the MAC to fixed speed. There is a degree of separation between the MAC and the internal PHY/PCS. So the MAC could be fixed, and the PCS is probably using its power up defaults which could be to perform in-band signalling. And it is very likely the results from that in band signalling is ignored by the MAC. So this is all pretty fragile, but that is the way this has all evolved over time for the mv88e6xxx driver. And so far, boards continue to work, or at least, we are not going reports they are broken. That however does not mean it will not all implode sometime in the future, and we probably should be asking new submissions to always use a fixed-link and a phy-mode, even if it is not strictly needed. Andrew