Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp5721538pxu; Thu, 22 Oct 2020 09:24:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw1ZNkHOMehm76Y2PIazJ0SmZdcguL0t9KjD5PwsO1+fQOlOSf9xBkjA2M/H302Wi+ZfTuP X-Received: by 2002:a17:906:bc91:: with SMTP id lv17mr3145291ejb.249.1603383870264; Thu, 22 Oct 2020 09:24:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603383870; cv=none; d=google.com; s=arc-20160816; b=gicF5GPEt5RP4jKpE2TNNT8A/OJAJpKVBESiF5EYnfICfavH0bfVChNxfZiU1i1cC6 naFt0p3wI7RnW0HFX/lMXKMZ+T8hvaDq63an+k26hykCfGBaoEezRHZ4KKHOmXhSYjol LYoYpveBwK2HkMg8v78HBXNHKq3VA6zA68yAfcXJ//JVGqb00ImKjhWp3biyayavO1Xx 4WDGLxGEpxmLz73CPjUwxyZZ7e4Nu+MWHONI73zL3lfST7zEfIXKlMZtFKdFsw2oTFaH 2TfVYCsvf+GSAp1UCnfpNz3cPdYjw5AZHdkcO4vLui71DHQHwl83IublLJnDp8tNCsvR I/rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:organization:message-id:date:subject:cc:to :from; bh=wYupGaaHtLknS8EDBmWWycUc47meZBq41T7+1w8TCQA=; b=WfTpQWuYY7StAhHqKX7kW7YvmgI9zUp9aw5CPRu6olBOdjHQrN+lTkdxHWDLjdChZl T7k5ksShRDOJ/2LJOcl8bMuJRqmlnUowtGO9xR94BIRh0r99niEWr/usV4xQKqjLlOV1 bqskBkMaVtIQHx5S3RWkffwxUBRONBgPy7PEo2DUgcxcF9XjL+4a5TbZG/7Tp/is4j4A ZeYQcV7Ep8AfjaGas6OvIZGQfydYIUjDzQYwzyizwSNutQTmM2iK1S5ImGS0UACq6cjx VoQ4+hxRxFm1bVKygmyPtjsU426meIQ2N9UeKR65Fbj9z8k2ZoL8/9cR0BBXzEdBCSX5 YNog== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ga26si1110624ejc.292.2020.10.22.09.24.07; Thu, 22 Oct 2020 09:24:30 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2897071AbgJVLNA (ORCPT + 99 others); Thu, 22 Oct 2020 07:13:00 -0400 Received: from mailout04.rmx.de ([94.199.90.94]:34163 "EHLO mailout04.rmx.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2897062AbgJVLNA (ORCPT ); Thu, 22 Oct 2020 07:13:00 -0400 Received: from kdin01.retarus.com (kdin01.dmz1.retloc [172.19.17.48]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout04.rmx.de (Postfix) with ESMTPS id 4CH4Tg5b6Qz3r1qD; Thu, 22 Oct 2020 13:12:55 +0200 (CEST) Received: from mta.arri.de (unknown [217.111.95.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by kdin01.retarus.com (Postfix) with ESMTPS id 4CH4TR0tBFz2xqR; Thu, 22 Oct 2020 13:12:43 +0200 (CEST) Received: from n95hx1g2.localnet (192.168.54.94) by mta.arri.de (192.168.100.104) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 22 Oct 2020 13:11:41 +0200 From: Christian Eggers To: Vladimir Oltean CC: Richard Cochran , Florian Fainelli , Andrew Lunn , Vivien Didelot , Jakub Kicinski , Rob Herring , Helmut Grohne , Paul Barker , Codrin Ciubotariu , George McCollister , Marek Vasut , Tristram Ha , "David S . Miller" , Woojung Huh , "Microchip Linux Driver Support" , , , Subject: Re: [RFC PATCH net-next 7/9] net: dsa: microchip: ksz9477: add hardware time stamping support Date: Thu, 22 Oct 2020 13:11:40 +0200 Message-ID: <2541271.Km786uMvHt@n95hx1g2> Organization: Arnold & Richter Cine Technik GmbH & Co. Betriebs KG In-Reply-To: <20201022105014.gflswfpie4qvbw3h@skbuf> References: <20201019172435.4416-1-ceggers@arri.de> <20201022090126.h64hfnlajqelveku@skbuf> <20201022105014.gflswfpie4qvbw3h@skbuf> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [192.168.54.94] X-RMX-ID: 20201022-131243-4CH4TR0tBFz2xqR-0@kdin01 X-RMX-SOURCE: 217.111.95.66 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vladimir, On Thursday, 22 October 2020, 12:50:14 CEST, Vladimir Oltean wrote: > If the hardware supports p2p one-step, it subtracts the ingress time > stamp value from the Pdelay_Request correction field. The user space > software stack then simply copies the correction field into the > Pdelay_Response, and on transmission the hardware adds the egress time > stamp into the correction field. > > So we were correct about the behavior, just not about the target > hardware. > > So, that's just not how this hardware works. What do you recommend? > Keeping a FIFO of Pdelay_Req RX timestamps, and matching them to > Pdelay_Resp messages on TX, all of that contained within tag_ksz.c? after applying the RX timestamp correctly to the correction field (shifting the nanoseconds by 16), it seems that "moving" the timestamp back to the tail tag on TX is not required anymore. Keeping the RX timestamp simply in the correction field (negative value), works fine now. So this halves the effort in the tag_ksz driver. Best regards Christian