Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp3449909pxb; Mon, 4 Apr 2022 17:21:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyS7LagteoU4+KWKnNv+M+gWZJbYvGCIebuyOR3GEqSk9D86/2cQeBMaBCfQqC8OkBWTVq0 X-Received: by 2002:a17:90b:17c7:b0:1c7:c616:6eb0 with SMTP id me7-20020a17090b17c700b001c7c6166eb0mr1021424pjb.144.1649118071304; Mon, 04 Apr 2022 17:21:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649118071; cv=none; d=google.com; s=arc-20160816; b=DGlm19mTCktz0tAvMh/MxRqr7G6khuvK574qChOClDrylNA1KbSRmTMIXd7R30hIgi H7Wz5ZLcdGcT0pKHgG6I2fL4yklAml+661wdCVC/6/zXgPZ3Z+qWx13mcoCrL8Y8Y/mc UNSdSsSV00hpHs30bdGOK7IpX6Kfsm4CxwlOiXP8Pyb6AkIWGN8rMV9RVPHFyqyfCMml qiJUftWB05RJiwoltjH3GuH2RP8+Lj5IbTJya4fzmccu+xs5ICzslQnzF9VoUnDXw5VI UCvXta6blvPFQj1XPsSxrF6u8o1NcZiH2QcJaoW26p/AnJfO2z7vQwRdGZXbHqN/v0oG 6c4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=eRnVwLqxvaZkK5inK6QPhoSx1abWW++tjzz4e/jN0cE=; b=RIdxt68vNshIe9BxzswnbBgVTnuo9C1RuB2/sthFMzlttjEAN2jKnFOgEu4pimBkRB hOJC0a8p1nA7BrUI1P7L7jTMpOdFSLLeXTpjPZ+v0sGGKdgMlIe9O9w342wK6uDps9K/ FtzdkDROJooU+zMWfdMraTIFsJ1ZW9P+Vrs3+HodWnIkZGCkR2A9HB2/lw39FjhTO3r+ gqvqqHy+BAw0CSCx0kRcWBUDRxTq9K8O/M3uPxZ27pzSKbkalylQaX18q/TnakyAvcKo yTiIcQSb2lf33W7R49PdCHq7OG1jQPJ6lc36P4B/WJNuxzB1CxoMDhwvhHuETyTfL+RC E0bw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b="N/SwS967"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id o14-20020a655bce000000b0039834489e06si12194335pgr.428.2022.04.04.17.21.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 17:21:11 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b="N/SwS967"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 68D7374614; Mon, 4 Apr 2022 16:46:48 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378506AbiDDPWv (ORCPT + 99 others); Mon, 4 Apr 2022 11:22:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35628 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344613AbiDDPWu (ORCPT ); Mon, 4 Apr 2022 11:22:50 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [185.16.172.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 00BDA3CA67; Mon, 4 Apr 2022 08:20:53 -0700 (PDT) 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=eRnVwLqxvaZkK5inK6QPhoSx1abWW++tjzz4e/jN0cE=; b=N/SwS967cwXIhNIsdZEPKbcl50 NlGBxBsYqBz63vqSTe9mXa0WoNV0H7lRX7/D3hloi5zAWd+s3g7s6qTesZfoGdq5esU9xpPpNXPAJ q52nGl5oyYJh7yT0bLAtL+4RRKDo2RbSOumUM/GJWZUBXtsKqAxFBlLih495I6Hi8vmY=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1nbOVI-00E6md-Fl; Mon, 04 Apr 2022 17:20:28 +0200 Date: Mon, 4 Apr 2022 17:20:28 +0200 From: Andrew Lunn To: Michael Walle Cc: richardcochran@gmail.com, davem@davemloft.net, grygorii.strashko@ti.com, kuba@kernel.org, kurt@linutronix.de, linux-kernel@vger.kernel.org, linux@armlinux.org.uk, mlichvar@redhat.com, netdev@vger.kernel.org, qiangqing.zhang@nxp.com, vladimir.oltean@nxp.com Subject: Re: [PATCH RFC V1 net-next 3/4] net: Let the active time stamping layer be selectable. Message-ID: References: <20220104014215.GA20062@hoboy.vegasvil.org> <20220404150508.3945833-1-michael@walle.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220404150508.3945833-1-michael@walle.cc> X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 04, 2022 at 05:05:08PM +0200, Michael Walle wrote: > Sorry for digging out this older thread, but it seems to be discussed > in [1]. > > > IMO, the default should be PHY because up until now the PHY layer was > > prefered. > > > > Or would you say the MAC layer should take default priority? > > > > (that may well break some existing systems) > > Correct me if I'm wrong, but for systems with multiple interfaces, > in particular switches, you'd need external circuits to synchronize > the PHCs within in the PHYs. If the PHYs are external. There are switches with internal PHYs, so they might already have the needed synchronisation. > (And if you use a time aware scheduler > you'd need to synchronize the MAC, too). Whereas for switches there > is usually just one PHC in the MAC which just works. And there could be switches with the MACs being totally independent. In theory. > On these systems, pushing the timestamping to the PHY would mean > that this external circuitry must exist and have to be in use/ > supported. MAC timestamping will work in all cases without any > external dependencies. And if the MAC are independent, you need the external dependency. > I'm working on a board with the LAN9668 switch which has one LAN8814 > PHY and two GPY215 PHYs and two internal PHYs. The LAN9668 driver > will forward all timestamping ioctls to the PHY if it supports > timestamping (unconditionally). As soon as the patches to add ptp > support to the LAN8814 will be accepted, I guess it will break the > PTP/TAS support because there is no synchronization between all the > PHCs on that board. Thus, IMHO MAC timestamping should be the default. There are arguments for MAC being the defaults. But we must have the option to do different, see above. But the real problem here is history. It is very hard to change a default without breaking systems which depend on that default. I believe Russell has a system which will break if the default is changed. So i suspect the default cannot be changed, but maybe we need a mechanism where an interface or a board can express a preference it would prefer be used when there are multiple choices, in addition to the user space API to make the selection. Andrew