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=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 09D14C55189 for ; Wed, 22 Apr 2020 11:16:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D17A920787 for ; Wed, 22 Apr 2020 11:16:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="J5SbB60Y" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726535AbgDVLQW (ORCPT ); Wed, 22 Apr 2020 07:16:22 -0400 Received: from lelv0142.ext.ti.com ([198.47.23.249]:43544 "EHLO lelv0142.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725787AbgDVLQV (ORCPT ); Wed, 22 Apr 2020 07:16:21 -0400 Received: from fllv0034.itg.ti.com ([10.64.40.246]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 03MBGFrS062002; Wed, 22 Apr 2020 06:16:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1587554175; bh=89X1lvMjHBm10I+ntaGK72ShPuo8BykYYefZWM91YCc=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=J5SbB60YTkOjlSOgIX0gfiAq4s0ehSiu250MPHxgbPDIPr2/6RZRcKDGqqorUJYcB EIJA/xYNx+txh80hrtYzGl3PoYcflFeIvsIieYo3BrGACPBP3+QqVj+JRh+Gmkdi6H x8pl2vStWE/BCvde8i/jUO/BsqFlTytiPR785Qns= Received: from DLEE111.ent.ti.com (dlee111.ent.ti.com [157.170.170.22]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 03MBGFGY039190 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 22 Apr 2020 06:16:15 -0500 Received: from DLEE103.ent.ti.com (157.170.170.33) by DLEE111.ent.ti.com (157.170.170.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3; Wed, 22 Apr 2020 06:16:14 -0500 Received: from lelv0326.itg.ti.com (10.180.67.84) by DLEE103.ent.ti.com (157.170.170.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3 via Frontend Transport; Wed, 22 Apr 2020 06:16:14 -0500 Received: from [10.250.100.73] (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0326.itg.ti.com (8.15.2/8.15.2) with ESMTP id 03MBGAIg117679; Wed, 22 Apr 2020 06:16:12 -0500 Subject: Re: [PATCH] net: cpts: Condition WARN_ON on PTP_1588_CLOCK To: Arnd Bergmann , Richard Cochran CC: Clay McClure , "David S. Miller" , Sekhar Nori , Networking , "linux-kernel@vger.kernel.org" References: <20200416085627.1882-1-clay@daemons.net> <6fef3a00-6c18-b775-d1b4-dfd692261bd3@ti.com> <20200420093610.GA28162@arctic-shiba-lx> <20200420170051.GB11862@localhost> <20200420211819.GA16930@localhost> <20200420213406.GB20996@localhost> From: Grygorii Strashko Message-ID: Date: Wed, 22 Apr 2020 14:16:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi On 21/04/2020 00:42, Arnd Bergmann wrote: > On Mon, Apr 20, 2020 at 11:34 PM Richard Cochran > wrote: >> >> On Mon, Apr 20, 2020 at 11:21:20PM +0200, Arnd Bergmann wrote: >>> It's not great, but we have other interfaces like this that can return NULL for >>> success when the subsystem is disabled. The problem is when there is >>> a mismatch between the caller treating NULL as failure when it is meant to >>> be "successful lack of object returned". >> >> Yeah, that should be fixed. >> >> To be clear, do you all see a need to change the stubbed version of >> ptp_clock_register() or not? > > No, if the NULL return is only meant to mean "nothing wrong, keep going > wihtout an object", that's fine with me. It does occasionally confuse driver > writers (as seen here), so it's not a great interface, but there is no general > solution to make it better. As per commit commit d1cbfd771ce8297fa11e89f315392de6056a2181 Author: Nicolas Pitre Date: Fri Nov 11 00:10:07 2016 -0500 ptp_clock: Allow for it to be optional In order to break the hard dependency between the PTP clock subsystem and ethernet drivers capable of being clock providers, this patch provides simple PTP stub functions to allow linkage of those drivers into the kernel even when the PTP subsystem is configured out. Drivers must be ready to accept NULL from ptp_clock_register() in that case. And to make it possible for PTP to be configured out, the select statement in those driver's Kconfig menu entries is converted to the new "imply" statement. This way the PTP subsystem may have Kconfig dependencies of its own, such as POSIX_TIMERS, without having to make those ethernet drivers unavailable if POSIX timers are cconfigured out. And when support for POSIX timers is selected again then the default config option for PTP clock support will automatically be adjusted accordingly. the idea of using "imply" is to keep networking enabled even if PTP is configured out and this exactly what happens with cpts driver. Another question is that CPTS completely nonfunctional in this case and it was never expected that somebody will even try to use/run such configuration (except for random build purposes). -- Best regards, grygorii