Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp3170999rwi; Fri, 21 Oct 2022 12:31:37 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7vAAldkYbUtA795l22umjiHEkL3X6uUBThDX5IteTgte9GVygjOLhyp1+p2gTZQsJDWDIN X-Received: by 2002:a17:90b:3ecc:b0:20d:9da6:56cd with SMTP id rm12-20020a17090b3ecc00b0020d9da656cdmr23270020pjb.246.1666380696932; Fri, 21 Oct 2022 12:31:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666380696; cv=none; d=google.com; s=arc-20160816; b=ROyr3anOd9AO+n4k3zX7BPzz5n7FT7N233vMneRCmWMTgGKqDH/A3e/xinv93Z3sIN YD3a24Ds5sCW1MJ5HcAhhb+J2tHqXSz1sS+YqKKZdFgqK6bULf1v8AdX1yeG9tOE4Gj3 XBbjHzmbK7BUQPfKTwx4Numi8Al5lkxAlDWcC2uVTFXMZlV2AR2dlq84zCNogxFk2cMm baq9pj8nCw8EXGRufJ+gAJXc+6M+bPWnnZDdgeUH3k9dROX8VOCF7tchz99whc2FKioX CXvsEreIGL2c0oFV7VO/hIJWk04fH0W1NUGz6xloU2JboNxoZfG3M8oo8CaT6/L+vmgt MhrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=bv4YI8sSgHvwniEnSXvaz0DDBkZlp+9CNcDod+TFfKw=; b=R0FUN69BABx2zeKJxEv45qVZQfPzEj7XFgkVoV06C2uXNnZkksuc4qc/N1pdWn6Cua cAN9RAL6bIN59JZ0bqDIbA/Li2YX0tReb6tFzyPHqyerg2KBxGsWeFkyaiCVwbow+CXP hgPjscgMf7P1yevIvXt6vGnx0MKtbKYwAi41KD1Q/SmJpU0shOQlyxwpway20CyEAl50 vfQV7rcb01B0kcxRuw/3jg+XF+Vty78dg3bLBbBXhuA6eDfpiLjkrfNf/HsJDSPsLmUY o9uCeOEmE+77aRnD234zsB84yTHW7HcbgVEwRbx2BlJAmyq8yiT/iUfZdY+WhrqNAkI3 2c5Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=12I3Ud5k; 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=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l17-20020a170903245100b0017811e3927bsi29214061pls.622.2022.10.21.12.31.22; Fri, 21 Oct 2022 12:31:36 -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=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=12I3Ud5k; 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=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230091AbiJUScV (ORCPT + 99 others); Fri, 21 Oct 2022 14:32:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52742 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229441AbiJUScT (ORCPT ); Fri, 21 Oct 2022 14:32:19 -0400 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B75D3272106; Fri, 21 Oct 2022 11:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: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=bv4YI8sSgHvwniEnSXvaz0DDBkZlp+9CNcDod+TFfKw=; b=12I3Ud5kvQPhpdSlXRIqfJDNKS 6jKrzdwfEmBkdaJ/G/BHpwlAPxUHA/9AZUxKfcZ0+xuK5dA7IilLovhlR87MWqUS88sH8tUxwdvlk 8fPlmPgVUkLKBewzgswYL8LS4cXxaZkC3Y7e+KJb70THzJ1daIv152U40UbwrxV3+O6tDiMsTChuB phGR3u+mibTuXYkaYpFrL+H8f3qxfL0Kr1vmEqURr1/5ehkVQioqYvZbLSI9gNe/FmyXZme5uCZzl fOYU2B/MyAcj1iGKcofxWgvhwqp4fnu5BO3GnY4FAjyF6vw8iwFPprB2EEAgZ4tPhzdnrTeOJXXJT 8VH8T7kQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:34876) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1olwoM-0000aJ-UI; Fri, 21 Oct 2022 19:32:02 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1olwoG-0004Mo-Hd; Fri, 21 Oct 2022 19:31:56 +0100 Date: Fri, 21 Oct 2022 19:31:56 +0100 From: "Russell King (Oracle)" To: Frank Wunderlich Cc: Frank Wunderlich , linux-mediatek@lists.infradead.org, Alexander Couzens , Felix Fietkau , John Crispin , Sean Wang , Mark Lee , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Matthias Brugger , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: Re: [PATCH v2] net: mtk_sgmii: implement mtk_pcs_ops Message-ID: References: <20221020144431.126124-1-linux@fw-web.de> <02A54E45-2084-440A-A643-772C0CC9F988@public-files.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Russell King (Oracle) 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_NONE,SPF_NONE, URIBL_BLOCKED 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 On Fri, Oct 21, 2022 at 07:47:47PM +0200, Frank Wunderlich wrote: > > Gesendet: Freitag, 21. Oktober 2022 um 11:06 Uhr > > Von: "Russell King (Oracle)" > > An: "Frank Wunderlich" > > On Fri, Oct 21, 2022 at 08:04:51AM +0200, Frank Wunderlich wrote: > > > I have no register documentation to check if there is any way to read out pause/duplex setting. Maybe MTK can answer this or extend function later. > > > > I suspect we can probably guess. > > > > Looking at SGMSYS_PCS_CONTROL_1, this is actually the standard BMCR in > > the low 16 bits, and BMSR in the upper 16 bits, so: > > > > At address 4, I'd expect the PHYSID. > > At address 8, I'd expect the advertisement register in the low 16 bits > > and the link partner advertisement in the upper 16 bits. > > > > Can you try an experiment, and in mtk_sgmii_init() try accessing the > > regmap at address 0, 4, and 8 and print their contents please? > > is this what you want to see? > > int mtk_sgmii_init(struct mtk_sgmii *ss, struct device_node *r, u32 ana_rgc3) > { > struct device_node *np; > + unsigned int val; > int i; > > for (i = 0; i < MTK_MAX_DEVS; i++) { > @@ -158,6 +159,12 @@ int mtk_sgmii_init(struct mtk_sgmii *ss, struct device_node *r, u32 ana_rgc3) > if (IS_ERR(ss->pcs[i].regmap)) > return PTR_ERR(ss->pcs[i].regmap); > > + regmap_read(ss->pcs[i].regmap, SGMSYS_PCS_CONTROL_1, &val); > + printk(KERN_ALERT "dev: %d offset:0 0x%x",i,val); > + regmap_read(ss->pcs[i].regmap, SGMSYS_PCS_CONTROL_1+4, &val); > + printk(KERN_ALERT "dev: %d offset:4 0x%x",i,val); > + regmap_read(ss->pcs[i].regmap, SGMSYS_PCS_CONTROL_1+8, &val); > + printk(KERN_ALERT "dev: %d offset:8 0x%x",i,val); > ss->pcs[i].pcs.ops = &mtk_pcs_ops; > } > > > [ 1.083359] dev: 0 offset:0 0x840140 > [ 1.083376] dev: 0 offset:4 0x4d544950 > [ 1.086955] dev: 0 offset:8 0x1 > [ 1.090697] dev: 1 offset:0 0x81140 > [ 1.093866] dev: 1 offset:4 0x4d544950 > [ 1.097342] dev: 1 offset:8 0x1 Thanks. Decoding these... dev 0: BMCR: fixed, full duplex, 1000Mbps, !autoneg BMSR: link up Phy ID: 0x4d54 0x4950 Advertise: 0x0001 (which would correspond with the MAC side of SGMII) Link partner: 0x0000 (no advertisement received, but we're not using negotiation.) dev 1: BMCR: autoneg (full duplex, 1000Mbps - both would be ignored) BMSR: able to do autoneg, no link Phy ID: 0x4d54 0x4950 Advertise: 0x0001 (same as above) Link partner: 0x0000 (no advertisement received due to no link) Okay, what would now be interesting is to see how dev 1 behaves when it has link with a 1000base-X link partner that is advertising properly. If this changes to 0x01e0 or similar (in the high 16-bits of offset 8) then we definitely know that this is an IEEE PHY register set laid out in memory, and we can program the advertisement and read the link partner's abilities. At that point, we should try programming the low 16-bits of offset 8 to see whether that advertisement makes it to the far end of the link. It would be well worth trying to work this out, because it will then vastly improve the knowledge of this hardware, and improve the driver no end. Is this something you could investigate please? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!