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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 B49ADC19759 for ; Sun, 4 Aug 2019 19:22:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8133020844 for ; Sun, 4 Aug 2019 19:22:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="gPsfzmbW" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726717AbfHDTWO (ORCPT ); Sun, 4 Aug 2019 15:22:14 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:38433 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726392AbfHDTWO (ORCPT ); Sun, 4 Aug 2019 15:22:14 -0400 Received: by mail-ed1-f67.google.com with SMTP id r12so41966962edo.5; Sun, 04 Aug 2019 12:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pj0ikRyiM2M9/CD5d5FXd58Pei1+6t41sEsA8s09Pcw=; b=gPsfzmbWFNebo/r/tjyKdRsMpRqU7/GEJfVm12iwmr3CNve3wsyxGbCCPz/l4auW7j JPHC/iGCWCazjhXUo/D9KqaSGNBR1FDgiuaMKXJ7csIm6LSP9oPszFw2+rn5MwDyTxes 8RkOp2C3q/x1XIognnm732OGX1WYSZVsDKzM0Ct+yCeSh5C79g8D/sS5rphnKHMvFmkx LTZkHNeAr3L62qSi4W6sgffugyxMDLgSu1QnB4jR6VZsLDcA4i1j82xcpWm8Yswl5T6P khPBEn4QQNyuy+ZXFDUDoarTya3UGTurgdSA6k/salgjZ7FMA22rOKhSfc1U8YbQ90ib GvKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pj0ikRyiM2M9/CD5d5FXd58Pei1+6t41sEsA8s09Pcw=; b=QUXMb9W0Av9gKH/ASswsfJglmGG/vTWZPWuhsSg+Km5vyz/bj6F1e/kLC9c+JjvkBo 95aiAT8D5wqv0WpjY7M/nmoFL1x5lkfRkUvMQ77mMw6TvQ38EI5y2ZoqFB8acTakTUUp 7DHDlwJgUEBR9KmiX/7j3u+6K3YYKQDfC8c075DfHd7MgSxTh62MqcfdcLQAxKZlaHfv E3+6t+0PDBNfeDcvnE/H4u5Yv4K8W2vygiaeIDMHNU/unUzHnPSYObjtk9THbdirvVNB 6id684Gk3l7+kATYxUVzeZIfJzrla78J9G+KjDzBfQ5leOy/d2X+KNggQrjFXV23GB9m qPQQ== X-Gm-Message-State: APjAAAUSCJRZ5FG50CzcEDTUQFE2pO8ArFOUB9TMiREJmUzstxbdgjnk s8qnCMOzE/kkLEo6GvdKJw5OEKj63ZleecvQHSM= X-Google-Smtp-Source: APXvYqySJFhDQZLNHXF8JQtrbX7ltOk9v6vkJxguWkKjYjXZq6sNO150ER/Wv1dGCfkPRz29WtcXiXs6SnoLaT60K5s= X-Received: by 2002:a17:906:19d3:: with SMTP id h19mr13839881ejd.300.1564946532348; Sun, 04 Aug 2019 12:22:12 -0700 (PDT) MIME-Version: 1.0 References: <20190802215419.313512-1-taoren@fb.com> <53e18a01-3d08-3023-374f-2c712c4ee9ea@fb.com> <20190804145152.GA6800@lunn.ch> In-Reply-To: From: Vladimir Oltean Date: Sun, 4 Aug 2019 22:22:01 +0300 Message-ID: Subject: Re: [PATCH net-next v3] net: phy: broadcom: add 1000Base-X support for BCM54616S To: Heiner Kallweit Cc: Andrew Lunn , Tao Ren , Florian Fainelli , "David S . Miller" , Arun Parameswaran , Justin Chen , netdev , lkml , "openbmc@lists.ozlabs.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 4 Aug 2019 at 19:07, Heiner Kallweit wrote: > > On 04.08.2019 17:59, Vladimir Oltean wrote: > > On Sun, 4 Aug 2019 at 17:52, Andrew Lunn wrote: > >> > >>>> The patchset looks better now. But is it ok, I wonder, to keep > >>>> PHY_BCM_FLAGS_MODE_1000BX in phydev->dev_flags, considering that > >>>> phy_attach_direct is overwriting it? > >>> > >> > >>> I checked ftgmac100 driver (used on my machine) and it calls > >>> phy_connect_direct which passes phydev->dev_flags when calling > >>> phy_attach_direct: that explains why the flag is not cleared in my > >>> case. > >> > >> Yes, that is the way it is intended to be used. The MAC driver can > >> pass flags to the PHY. It is a fragile API, since the MAC needs to > >> know what PHY is being used, since the flags are driver specific. > >> > >> One option would be to modify the assignment in phy_attach_direct() to > >> OR in the flags passed to it with flags which are already in > >> phydev->dev_flags. > >> > >> Andrew > > > > Even if that were the case (patching phy_attach_direct to apply a > > logical-or to dev_flags), it sounds fishy to me that the genphy code > > is unable to determine that this PHY is running in 1000Base-X mode. > > > > In my opinion it all boils down to this warning: > > > > "PHY advertising (0,00000200,000062c0) more modes than genphy > > supports, some modes not advertised". > > > The genphy code deals with Clause 22 + Gigabit BaseT only. > Question is whether you want aneg at all in 1000Base-X mode and > what you want the config_aneg callback to do. > There may be some inspiration in the Marvel PHY drivers. > AN for 1000Base-X still gives you duplex and pause frame settings. I thought the base page format for exchanging that info is standardized in clause 37. Does genphy cover only copper media by design, or is it desirable to augment genphy_read_status? > > You see, the 0x200 in the above advertising mask corresponds exactly > > to this definition from ethtool.h: > > ETHTOOL_LINK_MODE_1000baseX_Full_BIT = 41, > > > > But it gets truncated and hence lost. > > > > Regards, > > -Vladimir > > > Heiner