Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp1338117pxt; Sat, 7 Aug 2021 07:47:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzN5EVFldHHUxy4ODY9M1yZ3zIb2b3gO5fKUc8cw01/3IKmXyQ+gciTahUqErG3E6yEfNWo X-Received: by 2002:a17:906:1e42:: with SMTP id i2mr14910900ejj.76.1628347660784; Sat, 07 Aug 2021 07:47:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628347660; cv=none; d=google.com; s=arc-20160816; b=lKSt4ePji8Nvz0TtuDNXB54j9oIKkRy+HbbbzIQ8BU2vRnLq5KV4mGU+HPFx3Plm5i 43CO0IriRsrNCSXFQbGOPq6ttUt6rkn12x7H+grTVCchT9Sv3A0a9SLmXn1oY/tkoXoM 2yyG8aIEdvauKkVdGxWY6bPg1sGh/4HE8XtWJFavW8Yq5aaUUNYnmWFP3i8J4s/S28TT RX7QBe8BFUYfIkkpIeMVONLRc+Yg2pgcaUldX2r683avuk20nJNjyguNOu4kUqUIxPfG fTkYK6bpOeDAy5oRkFQxWMCzkpyUSE8HJ296/bjEIYvzGWSQ+X7Wy41RYgchVgM1+tcT 0TZg== 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=KCNLnCUiZ+ov8onPR3PzcmV7yH057fWxJ3U1+LFsGFg=; b=WIpYIBpIAgru3Gi3F9zMpwtwh7xPusWnPnfOrz/AIVAPjwOYFKcbAvZswtQfaCKIjV LjbrGNB84u4GKf8xTf0yR49HR3FPvYayKhp8aLVPtlXyXhzHeLgEYka5i1rygT/Jlxhl ENB3w1eVYpq9Bx1EhB7ovp41+ze/GBhAhAXKsU9qjz2+chwZmeLXXv7Gzc6DKm6BlsFD FWB4wdZpqRIW41AzdH4uNyEc7EAyCTIMkgO2eEyhF2f+jVdQenwkurt12Dk3zaq5Okmr AaDrwys1g44YeO5Aw8k/iYPtaFo5x4yyapB6SyrTCrAkw8y03Zo5nIDcw6hVM0JIm6NY XPPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QsEp3Lso; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hz15si11453713ejc.333.2021.08.07.07.47.03; Sat, 07 Aug 2021 07:47:40 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QsEp3Lso; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229869AbhHGOnz (ORCPT + 99 others); Sat, 7 Aug 2021 10:43:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229503AbhHGOnx (ORCPT ); Sat, 7 Aug 2021 10:43:53 -0400 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 28F29C0613CF; Sat, 7 Aug 2021 07:43:36 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id d6so17536825edt.7; Sat, 07 Aug 2021 07:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=KCNLnCUiZ+ov8onPR3PzcmV7yH057fWxJ3U1+LFsGFg=; b=QsEp3LsokWXgTBYa573FAuouSLXfRxMfWZmnKLl8UhRbZgh+Uo92IcVfwKVWPEbC3w u818UjNdH9gMLW/ea+WncjsGTRBbR9+gYQFUsVRbjwR2J8MQLLusyJJSIjU1IjvTeCkM NOTbwx2BVDTXSIQPyhlua3mkjm6DlEhS+wboajYVOZyzjJnUvrs2fk9XsyzZmzgFut9T XZJR5eg7f7MR0KvFwv5M/LQBOr7EPsC7WNNkc7BbRozHCWXA/lsl+2dHBOoLskpMHX5V olt2DFuKJxPZ3QcDCdtRFXScux7ld7X4ZQLsf9wfvF1SRNskOr+asXwPJ1X5eZj8pfSA Me0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=KCNLnCUiZ+ov8onPR3PzcmV7yH057fWxJ3U1+LFsGFg=; b=nLmsxRJptfLPaiFghIFcBYL2sPkqPeP/9II6utLbCg5Hg4knQpHqrW2TfREm/Sm7M0 ysUTypJrE4N8BIvSpjCTM4HBOzXh1aBWQ325fS3NqFhOaQ4Biy/h3sJbaMPlkvCyDBD+ M6ji60TzoefB0EeZTktpGPTXMPS2aosLfjiG6+JJGK8DaXtTkcOilA2cyZg6H/w+Md3Z Agnirg2Hrgkue2r7OxT0m56A4SPMmnkbtiL4xe/f08bm4BTOX4+8WcGXA8cKG0MFv6Vw oLKmvxbOv2UN9cUtkF4AHFXdNkG/NZRhmM5hy9lDmxKDnVMELSNjs6u3ZxBkQ0aqCxAz VVMg== X-Gm-Message-State: AOAM533/xmQ/1vyZPxXV/MGremS1RJLC4HjPc/HwizEPerEHePkL2pId MYWasIQOl6SpppkGyWH+xlY= X-Received: by 2002:a05:6402:1719:: with SMTP id y25mr19430725edu.331.1628347414721; Sat, 07 Aug 2021 07:43:34 -0700 (PDT) Received: from skbuf ([188.25.144.60]) by smtp.gmail.com with ESMTPSA id k23sm3599454ejr.2.2021.08.07.07.43.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 07 Aug 2021 07:43:34 -0700 (PDT) Date: Sat, 7 Aug 2021 17:43:32 +0300 From: Vladimir Oltean To: Richard Cochran Cc: Vinicius Costa Gomes , Yangbo Lu , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, mptcp@lists.linux.dev, "David S . Miller" , Jakub Kicinski , Mat Martineau , Matthieu Baerts , Shuah Khan , Michal Kubecek , Florian Fainelli , Andrew Lunn , Rui Sousa , Sebastien Laveze Subject: Re: [net-next, v5, 02/11] ptp: support ptp physical/virtual clocks conversion Message-ID: <20210807144332.szyazdfl42abwzmd@skbuf> References: <20210630081202.4423-1-yangbo.lu@nxp.com> <20210630081202.4423-3-yangbo.lu@nxp.com> <87r1f6kqby.fsf@vcostago-mobl2.amr.corp.intel.com> <20210807142259.GB22362@hoboy.vegasvil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210807142259.GB22362@hoboy.vegasvil.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 07, 2021 at 07:22:59AM -0700, Richard Cochran wrote: > On Fri, Aug 06, 2021 at 06:15:29PM -0700, Vinicius Costa Gomes wrote: > > > > int ptp_clock_unregister(struct ptp_clock *ptp) > > > { > > > + if (ptp_vclock_in_use(ptp)) { > > > + pr_err("ptp: virtual clock in use\n"); > > > + return -EBUSY; > > > + } > > > + > > > > None of the drivers (that I looked) expect ptp_clock_unregister() to > > return an error. > > > > So, what should we do? > > 1. Fix all the drivers to return an error on module unloading (that's > > usually the path ptp_clock_unregister() is called)? > > 2. Remove all the PTP virtual clocks when the physical clock is > > unregistered? > > This: > > 3. Let the vclocks hold a reference to the underlying posix dynamic clock. So even if the vclock holds a reference to the underlying POSIX clock, that won't prevent the hardware driver from unbinding, and further gettime() calls on the vclock from faulting, will it? What about: 4. Create a device link with the vclock being a consumer and the parent clock being a supplier? This way, ptp_vclock_unregister() is automatically called whenever (and before) ptp_clock_unregister() is. https://www.kernel.org/doc/html/latest/driver-api/device_link.html