Received: by 2002:a05:6a10:83d0:0:0:0:0 with SMTP id o16csp34393pxh; Thu, 7 Apr 2022 13:09:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy13a1oXHl5HFEJja9a2zEPlIEe2kXKi5qQKIZwraVYNfYkEFO5rBxFYufuk/8WOWKH982k X-Received: by 2002:a05:6a00:999:b0:4fa:964f:9021 with SMTP id u25-20020a056a00099900b004fa964f9021mr15966532pfg.34.1649362165662; Thu, 07 Apr 2022 13:09:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649362165; cv=none; d=google.com; s=arc-20160816; b=nwBfIX9AsJLQbrx3LDDN12jaQXJTVeD88gjvwdcnaD221zNt2NOENxHnRxRTLQG5gx 8n/K1Xx1XhhTgwTu4bbQz3oCCx63B0TpjK5cfv2egz+5upcC+Txn4GFrNFEMt5iucjmP 5Rhpyc+YhWTRAfpt3lIhtxCQDbp3df34G4LTqVOop8tRjyP5mNlA2UMlUOAvbk2QTAkp 8PDHoAJo3BrCsyFyqgzfTaL/sdkaPYkQhnWqp1axwcNwCLPE9OPMqZjWDQh2LpfLajmh j86COOEs7HneDMxVIgeguir/qFstMayDuXbITRUGl0yI2rb+8LHV3EsiBA/BclY8L5n5 hNmA== 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:dkim-signature; bh=dYlUZ7HEM9Q8UXLO+RramSh0ZaxW+tJRr+1uBmDx/CA=; b=fVlnKhkndZBIWilyuPfVAA6JcqkgNNOtq3VPwsZUOnthAQ9uk7vrfACAt7modEGpi9 XoZLArP68BW7ppuHAdosjL2JGA9qiy9mWt39UfwUFs2rpnh7jcMiWMUd1k1AaMS6Hdsn YvP7WmWBj+wvVNojdOTvT0omGa/flAjb9Xv7CyOduY2CEa1QghKx/V3WB6BJFD1ewCEN TaYBXvhYjnJlTeERyUrD9WQoct9b5l+nAbzEUq17P1YRYZ8yw7ZEW0g295pkUjJgttxT EhcE4QhgmMO4Mw3mvivUHJxZnL2j2wTdV4vuTp6WkqxPZ/JWu9MnvzXnfY7L3Yjw98Fs tJyQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=0piKrbmh; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id q16-20020a056a00089000b004fe0ecc07acsi12844152pfj.106.2022.04.07.13.09.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Apr 2022 13:09:25 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=0piKrbmh; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6E9332B5AFB; Thu, 7 Apr 2022 12:32:28 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240598AbiDGOrQ (ORCPT + 99 others); Thu, 7 Apr 2022 10:47:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229758AbiDGOrP (ORCPT ); Thu, 7 Apr 2022 10:47:15 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [185.16.172.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DD0684C40B; Thu, 7 Apr 2022 07:45:10 -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=dYlUZ7HEM9Q8UXLO+RramSh0ZaxW+tJRr+1uBmDx/CA=; b=0piKrbmhFW7hUKXrkZkNchk2tg eEuOXgL43A35J6T4dB1XfIg5vVxVAYDF8nwD9oSOioIPA1XtTPyzcwSNR8dfXZv/CJT8Sgs9iZ7cf UbvI1VufV7xLk3WfTgFqcPuF6WLIJkY0zQckaBtEGiuKaIumSR4CBYTg+/a2BISfxi5Q=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1ncTNf-00Ef6h-NE; Thu, 07 Apr 2022 16:45:03 +0200 Date: Thu, 7 Apr 2022 16:45:03 +0200 From: Andrew Lunn To: "huangguangbin (A)" Cc: Oleksij Rempel , davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, lipeng321@huawei.com, chenhao288@hisilicon.com Subject: Re: [PATCH] net: phy: genphy_loopback: fix loopback failed when speed is unknown Message-ID: References: <20220331114819.14929-1-huangguangbin2@huawei.com> <130bb780-0dc1-3819-8f6d-f2daf4d9ece9@huawei.com> <20220401064006.GB4449@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Hi Andrew, > The PHY we test is RTL8211F, it supports 10 half. This problem actually is, > our board has MAC connected with PHY, when loopback test, packet flow is > MAC->PHY->MAC, it needs speed of MAC and PHY should be same when they work. > > If PHY speed is unknown when PHY goes down, we will not set MAC speed in > adjust_link interface. In this case, we hope that PHY speed should not be > changed, as the old code of function genphy_loopback() before patch > "net: phy: genphy_loopback: add link speed configuration". > > If PHY has never link, MAC speed has never be set in adjust_link interface, > yeah, in this case, MAC and PHY may has different speed, and they can not work. > I think we can accept this situation. > > I think it is general problem if there is MAC connected with PHY. Thanks for investigating. Looks like we are getting close the real solution. And it is a generic problem, that the MAC and PHY might not be using the same configuration. So it looks like if the link is down, or speed is UNKNOWN, we need to set phydev->link true, speed 10, duplex half, the PHY into 10/Half and call the adjust_link callback. That should get the MAC and PHY to talk to each other. The open question is what to do when we disable loopback. Maybe we need to always set link false, speed unknown and call phy_start_aneg() to restart the link? Andrew