Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3722728pxu; Mon, 30 Nov 2020 09:01:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJzpfK5AEHV7UzIDdQEkb8c6/e+uA29nFogMcUCsmhlmfZp4pfftI+bCdqU8Enyq/pO5upRF X-Received: by 2002:aa7:cb4a:: with SMTP id w10mr22741985edt.343.1606755674464; Mon, 30 Nov 2020 09:01:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606755674; cv=none; d=google.com; s=arc-20160816; b=h12NQApzuf/CK6c4iLhvH4eGtHAAQPY7aQDnfqpqjhhXk2S10HLE7voxEWr+rj6FGe fk1BdXhP/n99eg5Z4RPiDRntrIXFq7jcU7RtHgFWSYCqc88K24qUBUhPnkBT07g8M3QO XlKjQYaipRRKoCVNrg61oGM+bfPLjvncq7QsvXyXbEDg98J2g80HY/oqWc7FqmRqRiun qGTVKxvPJoodMzc/oMWMKvVDaCrEwdxQdznWgbJRtmsFEgvW3DU8qHvU8UiftO7IAL8l d6C/GA4KbGNJSiRT6D89y+uFbG8AjWIhdKHQCM3IiJiQ6Idzlh7HNPrM51EGcMuHwWz4 e+Xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=gNrJH9LatK/TB9QXpNOyePdcdm5KvLQAOw2GWVuZR7k=; b=t+1Z/Yk8Ng9TQZ7868bmksa7/TsY5RO0p3ZrMOdNXuAsbiV3NYhjQsxsM1RvnqkJZ7 nUdod6a51uhqF2h8Cb/YYaEmVodeqLvnrp+RjG04jb5ScQQWWM5IkxCkiiRGT5vwxd3Y IWm7bMsSqwV3ljok5IzxlFdYKhpucWUS1pK6D0LCHUU5XYUibu+IrBJIpehYLARY8feU Smq5uaO5SpWURshsa+aQQ/ZylxK7ABWeGLj1g9YSYjPkMp8LIkYO2IEvx/SKVxo6x+Yj hZa2YbHJP95FG2AaDAWQGo3yG80DngQeg0Ol1qfoNPG+LeHa99g0Qca4CNGdrAunAggi xFFg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=vMzBA7E7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t17si11321362edq.418.2020.11.30.09.00.49; Mon, 30 Nov 2020 09:01:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=vMzBA7E7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729083AbgK3Q6k (ORCPT + 99 others); Mon, 30 Nov 2020 11:58:40 -0500 Received: from fllv0015.ext.ti.com ([198.47.19.141]:40350 "EHLO fllv0015.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728053AbgK3Q6j (ORCPT ); Mon, 30 Nov 2020 11:58:39 -0500 Received: from fllv0035.itg.ti.com ([10.64.41.0]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 0AUGvfe1047924; Mon, 30 Nov 2020 10:57:41 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1606755461; bh=gNrJH9LatK/TB9QXpNOyePdcdm5KvLQAOw2GWVuZR7k=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=vMzBA7E7D8WiTNE2j9XJD8Qnw+Nl0PpmalzczB8uss8R4HzHbCw0QwYyO0877j59M R++stf+HjFugyp9GrtNkt8xsN19V9oyxYSwP8hi7EkPT2a4anwVM89dR79QIwrnJx6 iZM0dSi6ZOQUzW6BoRIY2j5IOxBQr1DyopcmEUBY= Received: from DLEE105.ent.ti.com (dlee105.ent.ti.com [157.170.170.35]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 0AUGvggS046975 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 30 Nov 2020 10:57:42 -0600 Received: from DLEE107.ent.ti.com (157.170.170.37) by DLEE105.ent.ti.com (157.170.170.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Mon, 30 Nov 2020 10:57:41 -0600 Received: from lelv0326.itg.ti.com (10.180.67.84) by DLEE107.ent.ti.com (157.170.170.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3 via Frontend Transport; Mon, 30 Nov 2020 10:57:41 -0600 Received: from [10.250.40.192] (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0326.itg.ti.com (8.15.2/8.15.2) with ESMTP id 0AUGvf1a004085; Mon, 30 Nov 2020 10:57:41 -0600 Subject: Re: [PATCH net-next v4 4/4] net: phy: dp83td510: Add support for the DP83TD510 Ethernet PHY To: Andrew Lunn CC: , , , , , , , References: <20201117201555.26723-1-dmurphy@ti.com> <20201117201555.26723-5-dmurphy@ti.com> <20201120014919.GB1804098@lunn.ch> From: Dan Murphy Message-ID: Date: Mon, 30 Nov 2020 10:57:36 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201120014919.GB1804098@lunn.ch> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andrew On 11/19/20 7:49 PM, Andrew Lunn wrote: >> +static int dp83td510_config_init(struct phy_device *phydev) >> +{ >> + struct dp83td510_private *dp83td510 = phydev->priv; >> + int ret = 0; >> + >> + if (phy_interface_is_rgmii(phydev)) { >> + if (dp83td510->rgmii_delay) { >> + ret = phy_set_bits_mmd(phydev, DP83TD510_DEVADDR, >> + DP83TD510_MAC_CFG_1, >> + dp83td510->rgmii_delay); > Just to be safe, you should always write rgmii_delay, even if it is > zero. We have had too many bugs with RGMII delays which cause bad > backwards compatibility problems, so i would prefer to do a write > which might be unneeded, that find a bug here in a few years time. OK. > >> + if (ret) >> + return ret; >> + } >> + } >> + >> + if (phydev->interface == PHY_INTERFACE_MODE_RMII) { >> + ret = phy_modify(phydev, DP83TD510_GEN_CFG, >> + DP83TD510_FIFO_DEPTH_MASK, >> + dp83td510->tx_fifo_depth); > So there is no need to set the FIFO depth for the other three RGMII > modes? Or should this also be phy_interface_is_rgmii(phydev)? According to the data sheet the FIFO depth is for RMII. "Fifo depth for RMII Tx fifo" But I will ask the HW team for clarification. > >> +#if IS_ENABLED(CONFIG_OF_MDIO) >> +static int dp83td510_of_init(struct phy_device *phydev) >> +{ >> + struct dp83td510_private *dp83td510 = phydev->priv; >> + struct device *dev = &phydev->mdio.dev; >> + struct device_node *of_node = dev->of_node; > You need to move this assignment to later in order to keep with > reverse christmas tree. Well this is only used once so I will just remove the of_node declaration > >> +#else >> +static int dp83869_of_init(struct phy_device *phydev) >> +{ >> + dp83td510->hi_diff_output = DP83TD510_2_4V_P2P >> + dp83td510->tx_fifo_depth = DP83TD510_FIFO_DEPTH_5_B_NIB > You don't have DT, so there is no fine control, but you still need to > do the basic 2ns delay as indicated by the phydev->interface value. So > i think you still need to set dp83td510->rgmii_delay depending on > which RGMII mode is requested. The RGMII delay is fixed in the PHY.  The user can either turn it on or off. The default is 'off' which is 0. I can explicitly set the rgmii_delay to 0 in non-OF cases. Dan