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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 58667C43381 for ; Wed, 27 Feb 2019 21:26:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 207AF20842 for ; Wed, 27 Feb 2019 21:26:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="kWj36slZ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730440AbfB0V0I (ORCPT ); Wed, 27 Feb 2019 16:26:08 -0500 Received: from mail-wm1-f41.google.com ([209.85.128.41]:38666 "EHLO mail-wm1-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729412AbfB0V0H (ORCPT ); Wed, 27 Feb 2019 16:26:07 -0500 Received: by mail-wm1-f41.google.com with SMTP id v26so6971014wmh.3 for ; Wed, 27 Feb 2019 13:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=NIDo/ouMRGurapVXku4DwB9bkHr6ujIweNo3lz7tjFo=; b=kWj36slZQsuyzLobBrXgdm8MlPuZghoJHaaDX9rjrCIMqf9JfPTXHbZFx8tI7odkcG yIuMXqt3poM0FEAWv04ouMDqJsfmc87/5N0O4uD4LWzMNvuG2ZXhvSBISha5ftN8WjG+ 8gtPfMPMnbexKAzBMEj3F0UwuXyPEwlTiSuWLbr9ZRfuAcZzm9eyjXsgwNhOyL5Nbai8 JjVwJ0zotlgLLKYDNLfDes+hTPsqUE7Dofl4KUG9glHLC6351lejHuA8562Yoo3OvrAb d0vgQkxyElLuWNsqSiCIIMH+crajaWbDKIf73bPZWg4t7+EMrEORwAhi5CaKbQRhQv7E rH/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=NIDo/ouMRGurapVXku4DwB9bkHr6ujIweNo3lz7tjFo=; b=f0mPpzwRVnJE7bJ2eMWZtPxWWMnW5aR5wQQ1/QFjWJJBgqmh4eTETrjfy4RuwKrzVH 96yJX/fxV2Cuo1RZ2OJMwmhGMVMbpDrR7XMvFIh+64oB/yO5PNLrneWje+3G0yUGjyKi v8L80aZhO/Vw5C4DSFpT6drj5dZH+KmCL+s2E3W3Cqjdmtk8xXu7bpEzzawNIm4snNY4 KJGSJawlSpKBp66uBPCQnDSgysU5lUQ2kjJM/JUoWc3QInD90C9dffvK/KxcFbHlCOjw MlObhPjTX96CbRIc/KhbyW0z6ddvXsp6iRNQdmggO3oihuy7cSU3Dw8m5IsRhIDq/r5E 9ybg== X-Gm-Message-State: APjAAAUudR9MJXyHxMuTNx5Pbjx+hI7umIVUNxabYMSI+NCl+8Ew/eLU aZ8HsBQrpbmWOuWH3KbPZT8FKeWY X-Google-Smtp-Source: AHgI3IZXXdrY1Sp/rH1sqE5CLj0N/dCG7ZMwmblezDX0cRHhNOTN6wJJhqLgpaqlErA660TbvEzrJA== X-Received: by 2002:a1c:f502:: with SMTP id t2mr754996wmh.124.1551302765001; Wed, 27 Feb 2019 13:26:05 -0800 (PST) Received: from ?IPv6:2003:ea:8bf1:e200:7597:929b:df9d:5281? (p200300EA8BF1E2007597929BDF9D5281.dip0.t-ipconnect.de. [2003:ea:8bf1:e200:7597:929b:df9d:5281]) by smtp.googlemail.com with ESMTPSA id n9sm1808176wmi.33.2019.02.27.13.26.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Feb 2019 13:26:04 -0800 (PST) To: Russell King - ARM Linux , Andrew Lunn , Florian Fainelli Cc: "netdev@vger.kernel.org" From: Heiner Kallweit Subject: phylink / mv8e6xxx and SGMII aneg not working, link doesn't come up Message-ID: Date: Wed, 27 Feb 2019 22:25:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org For the ones who don't know my story yet: I have a Marvell 88E6390 switch with a Clause 45 PHY connected via SGMII to port 9. For other reasons I limit the PHY to 100Mbps currently. DT says: managed = "in-band-status" Driver is mv8e6xxx + phylink. Problem is that the link doesn't come up. Debugging resulted in: PHY establishes link to link partner (100Mbps, FD) and fires the "link up" interrupt. The "link up" is also properly transmitted via SGMII in-band signalling and fires the SERDES interrupt in mv8e6xxx. Problem is that the in-band transmitted values for speed and duplex don't show up anywhere. And phylink_resolve() doesn't even print the link-up message. First question: Both, PHY and SERDES interrupt, try to do the same thing: they eventually call phylink_run_resolve(). Is this correct? I have some problems with understanding the code for MLO_AN_INBAND in phylink_resolve(). Maybe also something is missing there for proper in-band aneg support. First we get the mac state (which is link down, 10Mbps, HD in my case). Then the link state is calculated as "mac link up" && "phy link up". This results in "link down", because mac link is down and phy link is up. This logic isn't clear to me. How is the "link up" info supposed to ever reach the mac? We're reading the port status, but IMO we want to set it based on the auto-negotiated settings we get from the PHY. Later pause settings and possibly changed interface mode are propagated to the mac. But no word about speed and duplex. Via "some callback" "some code" should read the in-band-transmitted speed and duplex values from the SGMII port and use them to configure the mac. Is this simply missing or do I miss something? Heiner