Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp5426732pxu; Thu, 22 Oct 2020 01:50:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxjlWRWAbXrlu4yNdpTxB7T9xaDz+BCL7odHk3wDJV67IO3YVZhdv8ODSSQW4KsVmIugpsZ X-Received: by 2002:a17:906:d0d4:: with SMTP id bq20mr1277494ejb.257.1603356639064; Thu, 22 Oct 2020 01:50:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603356639; cv=none; d=google.com; s=arc-20160816; b=EeDjK2eDAIWJ0Pro2C9ZOpghqNe/9c77tSmt2D2/5bdtoAgH5/TzBV2zrPJFjAKype DCSVWzLMUHzjZstwCapIWv+h0vSPOvu/rgclDmsy3kn0rXkjm0FjSshmuBfS6n7hmGn5 eZi1wIvsb8AoCe+0GINnEq0QRLGdQSpgBsnSwdIrAOFgONCtNtPx9fBdfDMr1JbZOn5f uXa0HaQ4juSvJEuPTgOm4ByJwKDBXw0sahDAw8qvfSev9iIKts8zufzvAAffzAe6b+OR Y2ZyvqvkkYMewbBtj7rJ64OOO9DX/9/D1ilHPbasZIRAanHcYcM0SCmmxSsdjNd2OOId e0Xw== 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=MjxL3DYJGQVIzNRVJORDKUlQeyxx6j/Q57E5GhjykYY=; b=xko8K5bvAx1a7mTG8uBax7y0JpkMK4ygz/XHfecHwuckeJVQ3jqgOHD2TKD54gZuoZ D4Kiwk33kz+mADNW32I3jx9PMNW35hvzSxH4+1RTVyM8KNGQ4iRdhrocVf/lLrsFoBT6 jXyjERBaB86EbXNW5TvR0xGaRwS/npMbP0bnr8NvitNXyMJRDCzphQBCnPU4pPAiNW2p UNojSIbdCNnSB51PG+r0YWQGvS8TySVinjtKR7eu1CJQwpkgwwG5TcGVlCvRBjb5Fa6G d/3PKkt/PgwLoOJUQWoJWV8197VaBu1uOevhcon4Qm4DsNfyjgiFRG7Mk1yegfrquSzL kCWg== 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 p16si446241ejw.561.2020.10.22.01.50.16; Thu, 22 Oct 2020 01:50:39 -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 S2508566AbgJVHcR (ORCPT + 99 others); Thu, 22 Oct 2020 03:32:17 -0400 Received: from mailout08.rmx.de ([94.199.90.85]:34111 "EHLO mailout08.rmx.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2508538AbgJVHcR (ORCPT ); Thu, 22 Oct 2020 03:32:17 -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 mailout08.rmx.de (Postfix) with ESMTPS id 4CGzb05T30zMtN6; Thu, 22 Oct 2020 09:32:12 +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 4CGzZm0HM5z2xKF; Thu, 22 Oct 2020 09:32:00 +0200 (CEST) Received: from n95hx1g2.localnet (192.168.54.141) by mta.arri.de (192.168.100.104) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 22 Oct 2020 09:30:58 +0200 From: Christian Eggers To: Richard Cochran CC: Vladimir Oltean , 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 09:30:57 +0200 Message-ID: <2975985.V79r5fVmzq@n95hx1g2> Organization: Arnold & Richter Cine Technik GmbH & Co. Betriebs KG In-Reply-To: <20201022023233.GA904@hoboy.vegasvil.org> References: <20201019172435.4416-1-ceggers@arri.de> <20201021233935.ocj5dnbdz7t7hleu@skbuf> <20201022023233.GA904@hoboy.vegasvil.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [192.168.54.141] X-RMX-ID: 20201022-093200-4CGzZm0HM5z2xKF-0@kdin01 X-RMX-SOURCE: 217.111.95.66 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Richard, On Thursday, 22 October 2020, 04:42:01 CEST, Richard Cochran wrote: > I'm just catching up with this. > > Really. Truly. Please -- Include the maintainer on CC for such patches! sorry for missing you on the recipients list. I blindly trusted the output of get_maintainer.pl. I recently sent two other patches which may also be of interest for you. They related to handling of SO_TIMESTAMPING on 32 bit platforms with newer C libraries: https://patchwork.ozlabs.org/project/netdev/patch/20201012093542.15504-1-ceggers@arri.de/ https://patchwork.ozlabs.org/project/netdev/patch/20201012093542.15504-2-ceggers@arri.de/ > On Thu, Oct 22, 2020 at 02:39:35AM +0300, Vladimir Oltean wrote: > > On Mon, Oct 19, 2020 at 07:24:33PM +0200, Christian Eggers wrote: > > > The PTP hardware performs internal detection of PTP frames (likely > > > similar as ptp_classify_raw() and ptp_parse_header()). As these filters > > > cannot be disabled, the current delay mode (E2E/P2P) and the clock mode > > > (master/slave) must be configured via sysfs attributes. > > This is a complete no-go. NAK. I didn't design the hardware nor do I have access to adequate documentation. I will try to figure out what functionality is concretely affected by these two settings. If I am correct, the KSZ hardware consists of two main building blocks: 1. A TC on the switch path. 2. An OC on the DSA host port. From the data sheet, page 109, chapter 5.1.6.11 ("Global PTP Message Config 1 Register"), bit 2: > *Selection of P2P or E2E* > 1 = Peer-to-peer (P2P) transparent clock mode > 0 = End-to-end (E2E) transparent clock mode So this "tcmode" sysfs entry controls the behavior of the switch' transparent clock. Is this related in any way to the PTP API? For the master/slave setting, the data sheet writes the following: *Selection of Master or Slave* 1 = Host port is PTP master ordinary clock 0 = Host port is PTP slave ordinary clock So this is really related to the OC and so to the PTP API. Setting this manually would interfere with the BMCA. I'll check whether delay measurement and clock synchronization can also work for all conditions (E2E/P2P, master/slave) without altering this value. Otherwise we might consider the KSZ as a "Slave Only Clock (SO)". Christian