Received: by 2002:a5d:925a:0:0:0:0:0 with SMTP id e26csp493980iol; Sat, 11 Jun 2022 09:17:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxzHPn7cSy03Dizqddfc/D3k0pvK3ouIrKtplsH2nLY7mMgLS1vKJSYzXdAOdBzT8q1f97d X-Received: by 2002:a17:902:c951:b0:163:efad:406d with SMTP id i17-20020a170902c95100b00163efad406dmr50319402pla.55.1654964242698; Sat, 11 Jun 2022 09:17:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654964242; cv=none; d=google.com; s=arc-20160816; b=NJ7DMitGNjFnpxSBqymhnNwiZH9U83TUOpHTYduXIc4lhu42lP1mNP4F4vZumePRYF rKpdqSvUDDqdF2FsxnnjH8+EQZanhUKgfLb+IACSQyyRJFfBDynylUsWhu4QIaVVDOKy B6EPGqqEM+XwPhUdd2vJjP3o7EIl+aYe1vSs2i7RZYTetr87vzeCZ9rz8zVH0OBGhjqF gW1CH9lRjOeATP3vfrlxWNpApi8hl+J+IYmnG11twlIM/EpwyqT2TZi6p0M1zpPZ6wRX vtX7UbjrXMU5CrSwIvrwkk0efJrNno8tY3829OMoSUfxKqFDan0HjofSR3b5J3XiFCnJ clFw== 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=bxg6oME6P+/xKVdg0UH1OZTEHoeeXwl7w9rgm0xrILk=; b=SUoHyL+8rnZCgtfWX23oOgE56Q/KtXl3LX2CzjkY202YlOMhNZDoqM8ERjgK69oFeE fMPcHgxP00HeA7G03eH810oJGcgEmi2ZGOVfEOzSoccUeNGjXbBopR6om/UhF00Amzur Z+O+ONSbK5VeyQsm5gePTzeN6Nimkp0sQmLqAIBNVrMSfvKvY+lmWgnmm2kAS9GpP/uo KG7n/SN4YqOQ04m7X83PBv+RruXMZ9pf3Z5J/enhyTw2/E1lIeS5iM9qzxF9xjoE9s9M 2VyGkqHOm3jqTwgmhF6e6Js3o9hHp3knqnQsIFS8vwVQTS1mmTBkU9pvHy6mMb/6Knnf eCJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=GpkQkm0I; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d16-20020a170902ced000b00163539c5a64si3451328plg.525.2022.06.11.09.17.07; Sat, 11 Jun 2022 09:17:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=GpkQkm0I; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233796AbiFKQMQ (ORCPT + 99 others); Sat, 11 Jun 2022 12:12:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36380 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231174AbiFKQMO (ORCPT ); Sat, 11 Jun 2022 12:12:14 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [185.16.172.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9117ABE; Sat, 11 Jun 2022 09:12: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=bxg6oME6P+/xKVdg0UH1OZTEHoeeXwl7w9rgm0xrILk=; b=GpkQkm0IOqePVzg/8SbLkwyoki GUZMbFBct50MYFqT7VyTM5qR5gy3PZi8+n0X92CjYA49aDgQBck6gQniTm0Yj6ymanKOofWwJHfRj /T/mTvxaJo7X2vmQYlYt4WcmhaE2U3i1sYfClDA9r6KPooci80mOUSMJyKtCy5YUh5J4=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1o03iP-006WjH-FD; Sat, 11 Jun 2022 18:11:57 +0200 Date: Sat, 11 Jun 2022 18:11:57 +0200 From: Andrew Lunn To: Oleksij Rempel Cc: Heiner Kallweit , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Jonathan Corbet , Michal Kubecek , kernel@pengutronix.de, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH net-next v1 1/1] net: phy: add remote fault support Message-ID: References: <20220608093403.3999446-1-o.rempel@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220608093403.3999446-1-o.rempel@pengutronix.de> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham 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 > diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c > index c67bf3060173..6c55c7f9b680 100644 > --- a/drivers/net/phy/phy-c45.c > +++ b/drivers/net/phy/phy-c45.c > @@ -205,7 +205,7 @@ static int genphy_c45_baset1_an_config_aneg(struct phy_device *phydev) > break; > case MASTER_SLAVE_CFG_UNKNOWN: > case MASTER_SLAVE_CFG_UNSUPPORTED: > - return 0; > + break; > default: > phydev_warn(phydev, "Unsupported Master/Slave mode\n"); > return -EOPNOTSUPP; > @@ -223,11 +223,16 @@ static int genphy_c45_baset1_an_config_aneg(struct phy_device *phydev) > break; > } > > + if (phydev->remote_fault_set >= REMOTE_FAULT_CFG_ERROR) > + adv_l |= MDIO_AN_T1_ADV_L_REMOTE_FAULT; > + > adv_l |= linkmode_adv_to_mii_t1_adv_l_t(phydev->advertising); > > ret = phy_modify_mmd_changed(phydev, MDIO_MMD_AN, MDIO_AN_T1_ADV_L, > - (MDIO_AN_T1_ADV_L_FORCE_MS | MDIO_AN_T1_ADV_L_PAUSE_CAP > - | MDIO_AN_T1_ADV_L_PAUSE_ASYM), adv_l); > + (MDIO_AN_T1_ADV_L_FORCE_MS | > + MDIO_AN_T1_ADV_L_PAUSE_CAP | > + MDIO_AN_T1_ADV_L_PAUSE_ASYM | > + MDIO_AN_T1_ADV_L_REMOTE_FAULT), adv_l); Since this is part of config_aneg, i assume you have to trigger an renegotiation, which will put the link down for a while. Is that actually required? Can the fault indicator be set at runtime without a full auto-neg? I suppose for a fault indicator, it probably does not matter, there is a fault... But i'm wondering about future extensions which might want to send values when the link is up. I've seen some PHYs indicate their make/model, etc. What sort of API would be needed for that? It might also be useful if we could send an event to userspace when the receive state changes, so there is no need to poll. I thought something link a linkstate message was broadcast under some conditions? That again my suggest ksetting is maybe not the best place for this? I see no problem in exposing this information, but i would like to be sure we get the API correct. Andrew