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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5E445C433F5 for ; Mon, 7 Mar 2022 13:09:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242796AbiCGNKA (ORCPT ); Mon, 7 Mar 2022 08:10:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40448 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242773AbiCGNJt (ORCPT ); Mon, 7 Mar 2022 08:09:49 -0500 Received: from vps0.lunn.ch (vps0.lunn.ch [185.16.172.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9F7D08A6DD; Mon, 7 Mar 2022 05:08:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=Y1pAQAT+a0HARiqstgx7zeKOv3dhoPYqsfR15bdIcSk=; b=EOb3iEff71UakXpSibnedHS2r+ BBoxGl/z1wtbVZrpT1EiRiLHrj525TcG5QXS6cwyna497wK3Dxhzu3x1E11SwlY3z2kdocmjAmFzW bJA0yFUCpyVSs9Yq5vlaz2X8i5k4c4h916s7+eKMT+fIfRP1ftDp2qmPqYAxupLPWvdI=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1nRD6Q-009cFX-HD; Mon, 07 Mar 2022 14:08:42 +0100 Date: Mon, 7 Mar 2022 14:08:42 +0100 From: Andrew Lunn To: Divya.Koppera@microchip.com Cc: netdev@vger.kernel.org, hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net, kuba@kernel.org, robh+dt@kernel.org, devicetree@vger.kernel.org, richardcochran@gmail.com, linux-kernel@vger.kernel.org, UNGLinuxDriver@microchip.com, Madhuri.Sripada@microchip.com, Manohar.Puri@microchip.com Subject: Re: [PATCH net-next 2/3] dt-bindings: net: micrel: Configure latency values and timestamping check for LAN8814 phy Message-ID: References: <20220304093418.31645-1-Divya.Koppera@microchip.com> <20220304093418.31645-3-Divya.Koppera@microchip.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > > + > > > + - lan8814,ignore-ts: If present the PHY will not support timestamping. > > > + > > > + This option acts as check whether Timestamping is supported by > > > + hardware or not. LAN8814 phy support hardware tmestamping. > > > > Does this mean the hardware itself cannot tell you it is missing the needed > > hardware? What happens when you forget to add this flag? Does the driver > > timeout waiting for hardware which does not exists? > > > > If forgot to add this flag, driver will try to register ptp_clock that needs > access to clock related registers, which in turn fails if those registers doesn't exists. Thanks for the reply, but you did not answer my question: Does this mean the hardware itself cannot tell you it is missing the needed hardware? Don't you have different IDs in register 2 and 3 for those devices with clock register and those without? > > > + - lan8814,latency_rx_10: Configures Latency value of phy in ingress at 10 > > Mbps. > > > + > > > + - lan8814,latency_tx_10: Configures Latency value of phy in egress at 10 > > Mbps. > > > + > > > + - lan8814,latency_rx_100: Configures Latency value of phy in ingress at 100 > > Mbps. > > > + > > > + - lan8814,latency_tx_100: Configures Latency value of phy in egress at 100 > > Mbps. > > > + > > > + - lan8814,latency_rx_1000: Configures Latency value of phy in ingress at > > 1000 Mbps. > > > + > > > + - lan8814,latency_tx_1000: Configures Latency value of phy in egress at > > 1000 Mbps. > > > > Why does this need to be configured, rather than hard coded? Why would the > > latency for a given speed change? I would of thought though you would take > > the average length of a PTP packet and divide is by the link speed. > > > > This latency values could be different for different phy's. So hardcoding will not work here. But you do actually have hard coded defaults. Those odd hex values i pointed out. By different PHYs do you mean different PHY versions? So you can look at register 2 and 3, determine what PHY it is, and so from that what defaults should be used? Or do you mean different boards with the same PHY? In general, the less tunables you have, the better. If the driver can figure it out, it is better to not have DT properties. The PHY will then also work with ACPI and USB etc, where there is no DT. Implementing the user space API Richard pointed out will also allow your PHY to work with none DP systems. > Yes in our case latency values depends on port speed. It is delay between network medium and > PTP timestamp point. What are the units. You generally have the units in the property name. So e.g. lan8814,latency_tx_1000_ns. If need be, the driver then converts to whatever value you place into the register. If you do keep them, please make it clear that these values are optional, and state what value will be used when the property is not present. Andrew