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 5351CC76196 for ; Tue, 11 Apr 2023 13:33:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229596AbjDKNdH (ORCPT ); Tue, 11 Apr 2023 09:33:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42156 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229559AbjDKNdG (ORCPT ); Tue, 11 Apr 2023 09:33:06 -0400 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4F6E335B3 for ; Tue, 11 Apr 2023 06:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: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=1IgoBJ4vDO/ax/MPew7OVysBajZgiajTs+DJ60W5huM=; b=lS15DPzsm0mV70oW+P7CSGyjdd yEPiOGeibDJj/Oh3luerS17jnUWEqz3/orWIIOc9E/gOjKXSqYM9leom7IUr6JMzCjyyq4iuyJjhA EfgyMCeNWeKsUn2QbgswZBKQnGMRtG8zlj/xt4x/iNq57acsrnkCRR3I8Ycn1yGPZIJEPp9j0Bli3 UMl81xmH8UAdUJBqnj69q2eI4quJuZqrnO6cIQ3yLVHbE1VJ2TcluOFo97vy9iRzwhFR3a8jWqS2P NgoQDX8jwbLk0DB2mFzIWUoUSXX/XPwt8zCobDONJByY7wUAEl/uc3uWThPgS9HPlN+xNezxAlYXV X2T76Tuw==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:45694) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pmE7J-0005xK-6m; Tue, 11 Apr 2023 14:33:01 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1pmE7I-00049C-2W; Tue, 11 Apr 2023 14:33:00 +0100 Date: Tue, 11 Apr 2023 14:33:00 +0100 From: "Russell King (Oracle)" To: Vladimir Oltean Cc: Oleksij Rempel , Andrew Lunn , Woojung Huh , Arun Ramadoss , Florian Fainelli , netdev@vger.kernel.org, UNGLinuxDriver@microchip.com, Eric Dumazet , kernel@pengutronix.de, Jakub Kicinski , Paolo Abeni , "David S. Miller" Subject: Re: FWD: Re: [PATCH net-next v1 1/1] net: dsa: microchip: ksz8: Make flow control, speed, and duplex on CPU port configurable Message-ID: References: <7055f8c2-3dba-49cd-b639-b4b507bc1249@lunn.ch> <20230411085626.GA19711@pengutronix.de> <20230411111609.jhfcvvxbxbkl47ju@skbuf> <20230411113516.ez5cm4262ttec2z7@skbuf> <20230411132617.nonvvtll7xxvadhr@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230411132617.nonvvtll7xxvadhr@skbuf> Sender: Russell King (Oracle) Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Apr 11, 2023 at 04:26:17PM +0300, Vladimir Oltean wrote: > On Tue, Apr 11, 2023 at 01:00:43PM +0100, Russell King (Oracle) wrote: > > ethtool --pause ... autoneg on > > ethtool --pause ... autoneg off rx off tx off > > ethtool --pause ... autoneg off rx on tx on > > > > Anything else wouldn't give the result the user wants, because there's > > no way to independently force rx and tx flow control per port. > > Right. > > > That said, phylink doesn't give enough information to make the above > > possible since the force bit depends on (tx && rx &&!permit_pause_to_mac) > > So, since the "permit_pause_to_mac" information is missing here, I guess > the next logical step based on what you're saying is that it's a matter > of not using the pcs_config() API, or am I misunderstanding again? :) pcs_config() doesn't get the "tx" and "rx" above. mac_link_up() does, but doesn't get the "permit_pause_to_mac" (since that's supposed to be a "configuration" thing.) Anyway, I think this is now moot since I think we've agreed on a way forward for this hardware. > > So, because this hardware is that crazy, I suggest that it *doesn't* > > even attempt to support ethtool --pause, and either is programmed > > at setup time to use autonegotiated pause (with the negotiation state > > programmed via ethtool -s) or it's programmed to have pause globally > > disabled. Essentially, I'm saying the hardware is too broken in its > > design to be worth bothering trying to work around its weirdness. > > Ok. How can this driver reject changes made through ethtool --pause? We would need either something in DSA (dsa_slave_set_pauseparam()) to prevent success, or something in phylink_ethtool_set_pauseparam() to do the same. At the phylink level, that could be a boolean in struct phylink_config. Something like "disable_ethtool_set_pauseparam" (I'd prefer something a tad shorter) which if set would make phylink_ethtool_set_pauseparam() return -EOPNOTSUPP. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!