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=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham 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 D6887C43219 for ; Sun, 28 Apr 2019 21:21:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 92AD120652 for ; Sun, 28 Apr 2019 21:21:19 +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="NIdlGOCB" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726443AbfD1VVR (ORCPT ); Sun, 28 Apr 2019 17:21:17 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:47814 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726393AbfD1VVR (ORCPT ); Sun, 28 Apr 2019 17:21:17 -0400 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=0HSyafLjhakES8/olu0MhbLzbp4wm39701bfCEtPOKA=; b=NIdlGOCBb4dMORDqGfn/HlYQwr BTcrsHnjbPsd17ZuAu2C6WNzzFdxtL95hkHRPoUugZy4dWzUiT7MRv8HWw+uYuBsku/Vy34kpl1bS YHUBySpojQr+W9sJzLVVLWKILLD6tb/oHQQBbVLPiJIfn2/wdrJrfL06V3mX6bn/l/xo=; Received: from andrew by vps0.lunn.ch with local (Exim 4.89) (envelope-from ) id 1hKrEX-0002vd-2g; Sun, 28 Apr 2019 23:21:13 +0200 Date: Sun, 28 Apr 2019 23:21:13 +0200 From: Andrew Lunn To: Heiner Kallweit Cc: Florian Fainelli , David Miller , "netdev@vger.kernel.org" Subject: Re: [PATCH net-next] net: phy: improve setting advertised modes in phy_probe Message-ID: <20190428212113.GA10772@lunn.ch> References: <13d4d69b-86a8-6c0d-a5a3-354f79a82170@gmail.com> <20190428170456.GL23059@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sun, Apr 28, 2019 at 08:10:43PM +0200, Heiner Kallweit wrote: > On 28.04.2019 19:04, Andrew Lunn wrote: > > On Sun, Apr 28, 2019 at 03:03:37PM +0200, Heiner Kallweit wrote: > >> So far we set the advertising bitmap before setting the pause flags > >> in the supported bitmap. This may cause pause not being advertised. > > > > Hi Heiner > > > > Pause requires that the PHY can advertise the pause bits, and that the > > MAC supports pause. So by default, we don't advertise pause. The MAC > > needs to say it supports pause, by calling one of > > > > void phy_support_sym_pause(struct phy_device *phydev); > > void phy_support_asym_pause(struct phy_device *phydev); > > > > These two then copy supported into advertising. > > > Right, missed that. After checking the code a little bit more I think > we still may have few issues with pause settings. Hi Heiner I agree the current state could be improved. We just have to be careful how we do it. We don't want to introduce regressions. There are a lot of MAC drivers we have no idea if they support pause or not. We do get some clues from .set_pauseparam. > 1. > We have functions that copy supported -> advertising, e.g. > phy_set_max_speed(). If such a function is called pause gets advertised > even w/o the MAC calling one of the two functions. Yes. I'm not sure supported is the best place to keep this information about what the PHY can do about pause, because off issues like this. You also see such copies in a few MAC drivers. So we might want to move PHY pause capability it into new bits in phydev. > 2. > We have PHY's (e.g. KSZ9031) that support sym pause only due to a hw > erratum. If the MAC now calls phy_support_asym_pause() it sets the > asym pause flag in phydev->supported even though the PHY intentionally > disabled it. That's not nice .. Yes, some validation would be good. > Maybe we should do it differently: > Apply my patch, then both pause modes are initially advertised. > (This also avoids point 3 below) > - remove phy_support_asym_pause() > - phy_support_sym_pause() clears the asym pause bit and doesn't touch > sym pause bit. > - and we may need something like phy_support_no_pause(). I would prefer to keep with the assumption that the MAC does not support pause until it tells us it does. > 3. > What's with all the existing drivers where the MAC supports pause but > drivers call neither of the two functions? Apart from .set_pauseparams, we have no way to identify them. > 4. > Calling either of the two functions will be effective after an autoneg > restart only. Do we have to consider this? The code i've seen does this before calling phy_start(). So i don't think it is an issue. But we could add in code to see if the phy has been started, and if so, restart autoneg. Andrew