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=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 52D6FC43603 for ; Sun, 15 Dec 2019 11:10:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 22CB9206D3 for ; Sun, 15 Dec 2019 11:10:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726146AbfLOLKW (ORCPT ); Sun, 15 Dec 2019 06:10:22 -0500 Received: from guitar.tcltek.co.il ([192.115.133.116]:36487 "EHLO mx.tkos.co.il" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726089AbfLOLKW (ORCPT ); Sun, 15 Dec 2019 06:10:22 -0500 Received: from tarshish (unknown [10.0.8.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.tkos.co.il (Postfix) with ESMTPS id 29014440808; Sun, 15 Dec 2019 13:10:20 +0200 (IST) References: <20191211131111.GK16369@lunn.ch> <87fthqu6y6.fsf@tarshish> <20191211174938.GB30053@lunn.ch> <20191212085045.nqhfldkbebqzzamv@sapphire.tkos.co.il> <20191212131448.GA9959@lunn.ch> <20191212150810.zx6o26jnk5croh4r@sapphire.tkos.co.il> <20191212151355.GE30053@lunn.ch> <20191212152355.iiepmi4cjriddeon@sapphire.tkos.co.il> <20191212193611.63111051@nic.cz> <20191212190640.6vki2pjfacdnxihh@sapphire.tkos.co.il> <20191212193129.GF30053@lunn.ch> <20191212204141.16a406cd@nic.cz> <8736dlucai.fsf@tarshish> User-agent: mu4e 1.2.0; emacs 26.1 From: Baruch Siach To: Marek Behun Cc: Andrew Lunn , Vivien Didelot , netdev@vger.kernel.org, Denis Odintsov , Hubert Feurstein Subject: Re: [BUG] mv88e6xxx: tx regression in v5.3 In-reply-to: <8736dlucai.fsf@tarshish> Date: Sun, 15 Dec 2019 13:10:19 +0200 Message-ID: <871rt5u9no.fsf@tarshish> MIME-Version: 1.0 Content-Type: text/plain Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi Marek, On Sun, Dec 15 2019, Baruch Siach wrote: > The call to mv88e6341_port_set_cmode() introduced in commit 7a3007d22e8 > ("net: dsa: mv88e6xxx: fully support SERDES on Topaz family") still > breaks port 5 (cpu) configuration. When called, its mode parameter is > set to PHY_INTERFACE_MODE_2500BASEX (19). > > Any idea? I dug a little further here. It turns out that mv88e6xxx_port_set_cmode() does not do any register write, because it exits early here with cmode == 0xb: /* cmode doesn't change, nothing to do for us */ if (cmode == chip->ports[port].cmode) return 0; mv88e6341_port_set_cmode_writable() breaks the port configuration with its call to mv88e6xxx_port_hidden_write(). Before this call mv88e6352_port_get_cmode() sets cmode to 0xb. After this call cmode is 6. This breaks the assumption that the equality test above relies on. This fixes cpu port configuration for me: diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c index 7fe256c5739d..a6c320978bcf 100644 --- a/drivers/net/dsa/mv88e6xxx/port.c +++ b/drivers/net/dsa/mv88e6xxx/port.c @@ -427,10 +427,6 @@ static int mv88e6xxx_port_set_cmode(struct mv88e6xxx_chip *chip, int port, cmode = 0; } - /* cmode doesn't change, nothing to do for us */ - if (cmode == chip->ports[port].cmode) - return 0; - lane = mv88e6xxx_serdes_get_lane(chip, port); if (lane) { if (chip->ports[port].serdes_irq) { Does that make sense? Thanks, baruch -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -