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 X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 94205C4363C for ; Wed, 7 Oct 2020 10:39:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3A824207EA for ; Wed, 7 Oct 2020 10:39:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="iPYPKOAq"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="ajgj4QkI" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728111AbgJGKjx (ORCPT ); Wed, 7 Oct 2020 06:39:53 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:42738 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727767AbgJGKjx (ORCPT ); Wed, 7 Oct 2020 06:39:53 -0400 From: Kurt Kanzenbach DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1602067191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=DyTO6nNH3VT0YkDiBwoY6iLnyasMfYs/rQZg2axs0do=; b=iPYPKOAqg3ZavBsrgasT9+vNkcqGOs9XW+mdvnpa0hLk/Vt2FtKmHQZCuAZ4OtHLcIFloa CYfNQ6hhCKc4ThAWDtrBFflmKMi+KdfuG1l2hwF47vUwGxmEL5i3z7STc3GvaM5Na85nEV 1SXnISWJf/lpt7Nf15ydpK0K+nbiCdoyUcg6zgJW6ju1QQcZ07xiXW8hrJa+3joLj2sxwz DE4r9loTtWm6PRMj37nTB10DL9hCuIvE07DP1kuqOmd/Knn8d4A3WSfmq0uU8KDCkbcwkE SvgOeaoMVOge6oztDs0YSF4IO5iRbmjyMxom2bQD53YXToalVVc+uNolzG5Zkg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1602067191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=DyTO6nNH3VT0YkDiBwoY6iLnyasMfYs/rQZg2axs0do=; b=ajgj4QkIIQpu2oCJw+9X5U6pVrjt0bdQtRXZ5FNcgXLpcTYpneJ7XTHP87ecKK6FoWeKX9 4GMPiFwz2/ZBihDw== To: Vladimir Oltean Cc: Andrew Lunn , Vivien Didelot , Florian Fainelli , "David S. Miller" , Jakub Kicinski , netdev@vger.kernel.org, Rob Herring , devicetree@vger.kernel.org, Sebastian Andrzej Siewior , Richard Cochran , Kamil Alkhouri , ilias.apalodimas@linaro.org Subject: Re: [PATCH net-next v6 4/7] net: dsa: hellcreek: Add support for hardware timestamping In-Reply-To: <20201006140102.6q7ep2w62jnilb22@skbuf> References: <20201004112911.25085-1-kurt@linutronix.de> <20201004112911.25085-5-kurt@linutronix.de> <20201004143000.blb3uxq3kwr6zp3z@skbuf> <87imbn98dd.fsf@kurt> <20201006072847.pjygwwtgq72ghsiq@skbuf> <87tuv77a83.fsf@kurt> <20201006133222.74w3r2jwwhq5uop5@skbuf> <87r1qb790w.fsf@kurt> <20201006140102.6q7ep2w62jnilb22@skbuf> Date: Wed, 07 Oct 2020 12:39:49 +0200 Message-ID: <87lfgiqpze.fsf@kurt> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue Oct 06 2020, Vladimir Oltean wrote: > On Tue, Oct 06, 2020 at 03:56:31PM +0200, Kurt Kanzenbach wrote: >> On Tue Oct 06 2020, Vladimir Oltean wrote: >> > On Tue, Oct 06, 2020 at 03:30:36PM +0200, Kurt Kanzenbach wrote: >> >> That's the point. The user (or anybody else) cannot disable hardware >> >> stamping, because it is always performed. So, why should it be allowed >> >> to disable it even when it cannot be disabled? >> > >> > Because your driver's user can attach a PTP PHY to your switch port, a= nd >> > the network stack doesn't support multiple TX timestamps attached to t= he >> > same skb. They'll want the TX timestamp from the PHY and not from your >> > switch. >>=20 >> Yeah, sure. That use case makes sense. What's the problem exactly? > > The SO_TIMESTAMPING / SO_TIMESTAMPNS cmsg socket API simply doesn't have > any sort of identification for a hardware TX timestamp (where it came > from). This is sounds like a problem. For instance the hellcreek switch has actually three ptp hardware clocks and the time stamping can be configured to use either one of them. How would the user space distinguish what time stamp is taken by which clock? This is not a problem at the moment, because currently only the synchronized clock is exported to user space. See change log of this patch. > So when you'll poll for TX timestamps, you'll receive a TX > timestamp from the PHY and another one from the switch, and those will > be in a race with one another, so you won't know which one is which. OK. So what happens if the driver will accept to disable hardware timestamping? Is there anything else that needs to be implemented? Are there (good) examples? Thanks, Kurt --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEooWgvezyxHPhdEojeSpbgcuY8KYFAl99mvUACgkQeSpbgcuY 8KYpYA/+NZ7x6UiwCygVWpIliPBWn1e5Z8sYKM2LClYibjm32fUKUbxj3JyPGg9F vmhcRp6eFX+AItyhzd6NG+whOa72HyxQDCi7JvW52NHavnOlpmeeKu+g9bc9rTxJ ihd7DR4lHt+wpDM/8khGX4yQMFkjbAAN62nDziVPhHAVQFKOvLmLj7ns0q4HpcVw Atq+idodnY0qWrm0byWDn1OrVbKHkw2hmYgmsBH//bdjA7fspsCgoWxU3A5aF70l u4dB5zj7bcTS/osxZeYocWBlbEuLdzzt+4eqPVdYUuwh69bBaCwPvDXXmF9ot6jp xrMaLmgnhil+zverXQNKMY8KNXfNtAAg10XM/av4Uqf/pSgAlEzQ3HHC9qUTd+m4 Tfv+bpVOu24PdnwMkvwhGYXn9s3GNCe1w9nMeftabqKIg322XE39azgTNLy/l27x +kiLOKkU1IaibGKNbSKErRB1PH3gQIMNfn3VCvYnpvRB4ezCH2T0v7ldpntIUBui mH/q850jNaV0ig9n/Ju9vuZUwKefU0745qa1KMTNqu2oH/AQ5WOpboQ4X9U0NBy1 W+Tbl0ub0v27SNkAiVzkfeGRH4b6l+OASCryEIOc+NU26zfXp/dczAYXCEXdRvRG unBwF5t6zEk2Nin/Hf/dQh/XH0w3BfreM4snHQ/t6kyYvsxQNcU= =r52S -----END PGP SIGNATURE----- --=-=-=--