Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp5627886rwb; Wed, 21 Sep 2022 10:10:12 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6dFPR50R9wAiSPqHWUbzNCS8yzYeysmKxYb5Mlx1+WaLOve8yLwoxZVoH4l9xz/EUXGcEJ X-Received: by 2002:a17:907:6e1e:b0:782:161b:3403 with SMTP id sd30-20020a1709076e1e00b00782161b3403mr3076310ejc.519.1663780211916; Wed, 21 Sep 2022 10:10:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663780211; cv=none; d=google.com; s=arc-20160816; b=fiDkkiZPY+YJNoaC9h8gKwSqn9CUerv2disoWkeU6a8g3LHy6YhodpwS4fNyWB3+ND cg1ppGIz0QpZ+Sa+tH3L00yuVYRVW8oW08SVFlBV7XyB8+sdX7aiKBBl4bDrGkywh6ts OTUsqhReoABKnU0UW6pJhRFHRfAo5AofCBaBJqQAZz2Kh+a6QHUwDexd5eGD/UFGPkvD kB6oyc/jRt3tZdNmKocLZ1nreeaND2JvzX9/e6ZCxh6dCuG77KKNv20iq+IpInBq9HHW qOwdw9t1R9jtTRjnmYJ5wYF1Zyyjw44Nyd9WfcTZAeHq9A1cN6I0xxHCwPSxIEKDz1SN 8CLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=FHfwgDXmPpcQJLzWOVWHkoKnzQTyRHKuE+9UFfOn5bs=; b=pcTtajOSBWxgqPectoMBEhlqzqiW465s7b8Ylm4/E+HjD4fimUycVRMBeE7coFDwJd kDK35k7Yxxl5rI0B/O3263nuhYQ0kvAHL+QLNxQVPKvGBQvphdukvi+9oLNTpoJqyhbb y5HqVXRjbs1N4z0J0mbRemQmwbr77kHfSqFPGOGMUHoULcpXSnEuWBbjfs+Y2tsqGKVr QqPF+0wg1KyKNuBKly3XcXkTaVIxLMkEDbUO3RXw6wxn8E3klibMDp8VER79UABIrqJs fCTOteNnFPcPKnLjrzj/Tle0IlTUnO+gxLRgcRZe2MlrDJKYpObVghpl5MTRUWw2iNTz fHHw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=13fYbqbT; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gn21-20020a1709070d1500b007330c08fe49si3350259ejc.206.2022.09.21.10.09.44; Wed, 21 Sep 2022 10:10:11 -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=@linuxfoundation.org header.s=korg header.b=13fYbqbT; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231744AbiIUP4z (ORCPT + 99 others); Wed, 21 Sep 2022 11:56:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39960 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231696AbiIUP4S (ORCPT ); Wed, 21 Sep 2022 11:56:18 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5CB629F8FF; Wed, 21 Sep 2022 08:50:51 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B557DB827D4; Wed, 21 Sep 2022 15:50:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1115EC433C1; Wed, 21 Sep 2022 15:50:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1663775449; bh=ienKP1MV/qqUYIaRNSoy9Pszc3E/nPCebcPJi5veVjU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=13fYbqbT/QNXEh4FYdJsSMjJH317bP5CviRr300VxFt7mXYAWwPTzDg9pfhMNjS0E nJl+j0zujSxAIVAQ+UOLnTgDgk9ZXKbS8VdZWtpvbNwNZ91tCNk55dhSLMBQjtgqcU 5W1DO1pkSBKQthaTMDkqtEDQy1/hoE3GGDzgybjI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Martyn Welch , "Russell King (Oracle)" , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.10 11/39] net: dsa: mv88e6xxx: allow use of PHYs on CPU and DSA ports Date: Wed, 21 Sep 2022 17:46:16 +0200 Message-Id: <20220921153646.121763439@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220921153645.663680057@linuxfoundation.org> References: <20220921153645.663680057@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS 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 From: Russell King (Oracle) [ Upstream commit 04ec4e6250e5f58b525b08f3dca45c7d7427620e ] Martyn Welch reports that his CPU port is unable to link where it has been necessary to use one of the switch ports with an internal PHY for the CPU port. The reason behind this is the port control register is left forcing the link down, preventing traffic flow. This occurs because during initialisation, phylink expects the link to be down, and DSA forces the link down by synthesising a call to the DSA drivers phylink_mac_link_down() method, but we don't touch the forced-link state when we later reconfigure the port. Resolve this by also unforcing the link state when we are operating in PHY mode and the PPU is set to poll the PHY to retrieve link status information. Reported-by: Martyn Welch Tested-by: Martyn Welch Fixes: 3be98b2d5fbc ("net: dsa: Down cpu/dsa ports phylink will control") Cc: # 5.7: 2b29cb9e3f7f: net: dsa: mv88e6xxx: fix "don't use PHY_DETECT on internal PHY's" Signed-off-by: Russell King (Oracle) Link: https://lore.kernel.org/r/E1mvFhP-00F8Zb-Ul@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- drivers/net/dsa/mv88e6xxx/chip.c | 64 +++++++++++++++++--------------- 1 file changed, 34 insertions(+), 30 deletions(-) diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c index 7b7a8a74405d..371b345635e6 100644 --- a/drivers/net/dsa/mv88e6xxx/chip.c +++ b/drivers/net/dsa/mv88e6xxx/chip.c @@ -666,44 +666,48 @@ static void mv88e6xxx_mac_config(struct dsa_switch *ds, int port, { struct mv88e6xxx_chip *chip = ds->priv; struct mv88e6xxx_port *p; - int err; + int err = 0; p = &chip->ports[port]; - /* FIXME: is this the correct test? If we're in fixed mode on an - * internal port, why should we process this any different from - * PHY mode? On the other hand, the port may be automedia between - * an internal PHY and the serdes... - */ - if ((mode == MLO_AN_PHY) && mv88e6xxx_phy_is_internal(ds, port)) - return; - mv88e6xxx_reg_lock(chip); - /* In inband mode, the link may come up at any time while the link - * is not forced down. Force the link down while we reconfigure the - * interface mode. - */ - if (mode == MLO_AN_INBAND && p->interface != state->interface && - chip->info->ops->port_set_link) - chip->info->ops->port_set_link(chip, port, LINK_FORCED_DOWN); - - err = mv88e6xxx_port_config_interface(chip, port, state->interface); - if (err && err != -EOPNOTSUPP) - goto err_unlock; - err = mv88e6xxx_serdes_pcs_config(chip, port, mode, state->interface, - state->advertising); - /* FIXME: we should restart negotiation if something changed - which - * is something we get if we convert to using phylinks PCS operations. - */ - if (err > 0) - err = 0; + if (mode != MLO_AN_PHY || !mv88e6xxx_phy_is_internal(ds, port)) { + /* In inband mode, the link may come up at any time while the + * link is not forced down. Force the link down while we + * reconfigure the interface mode. + */ + if (mode == MLO_AN_INBAND && + p->interface != state->interface && + chip->info->ops->port_set_link) + chip->info->ops->port_set_link(chip, port, + LINK_FORCED_DOWN); + + err = mv88e6xxx_port_config_interface(chip, port, + state->interface); + if (err && err != -EOPNOTSUPP) + goto err_unlock; + + err = mv88e6xxx_serdes_pcs_config(chip, port, mode, + state->interface, + state->advertising); + /* FIXME: we should restart negotiation if something changed - + * which is something we get if we convert to using phylinks + * PCS operations. + */ + if (err > 0) + err = 0; + } /* Undo the forced down state above after completing configuration - * irrespective of its state on entry, which allows the link to come up. + * irrespective of its state on entry, which allows the link to come + * up in the in-band case where there is no separate SERDES. Also + * ensure that the link can come up if the PPU is in use and we are + * in PHY mode (we treat the PPU as an effective in-band mechanism.) */ - if (mode == MLO_AN_INBAND && p->interface != state->interface && - chip->info->ops->port_set_link) + if (chip->info->ops->port_set_link && + ((mode == MLO_AN_INBAND && p->interface != state->interface) || + (mode == MLO_AN_PHY && mv88e6xxx_port_ppu_updates(chip, port)))) chip->info->ops->port_set_link(chip, port, LINK_UNFORCED); p->interface = state->interface; -- 2.35.1