Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1424235ybt; Sat, 11 Jul 2020 09:38:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwoD11GK1fNXqP/rLmOjmHxJMqqRebO/pRhlckq/2pSbwpkh6khj/15cdZwNj1HqtqXGyaw X-Received: by 2002:a17:906:50a:: with SMTP id j10mr52842059eja.113.1594485526875; Sat, 11 Jul 2020 09:38:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594485526; cv=none; d=google.com; s=arc-20160816; b=rbVjvKb68REUaVpu7sLxKcIdfqDHjptSgAzg4gE2x1OjLyAht5gLwYx9GsVAVCPE+C Bwz7rL+IgjCCWXZgGp1QRcWIYEacoyIo0Ir/WRLUW+W3ugVCKW0yc2WCHlhvu5u2d+0v AekwQMBOkUjMwP0QaNpB1X3FfKz7D02OazT2AiT0towZqk6rQEdIonagUxvdi0sDuv1r w7weYO/MFnPRe52Otk6xrfUlhp9HPWzwIjN3n15BU8jpawplWkjdsbSKcpE5lge+qBaR 6eAdqQdmChYndupWF64wvBKG40oreDfmvFAj/bRQVmkYQYOenL2NRBl0zMzSZ4gSsn5u yFkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=/jvffiaZQjZVgE9QFLUyonYkQMoccPl0x5jOAHo8Vak=; b=AWPHonFOyHlR5WpmgbZ7ikJg+Pey3zJzDbZK0pQsNeWpRm5fY85sxKph9Mbp6urC7l /AZqewldgClkhm7kUc/rStimEFtU83QT089bk3MyRvx5yvZWtj9ZOevS+2xfMpu7PO7i Di9ic2vyb73qsmfMZFjRqqDvy7wfmLWnDgkK+T+kQVwisclEqoS0vSuO93/hb63xBR02 /8tj7JwuajdyQvLKtQYA7NF/0nX777a77rU4R7OjMfhFDRvUnnSqiWu900d8wBWhWePI YDz5XU/kPRcWEJtq9MRsAx8YyhWFs4thGnzbFK9k3NBJX4w7uIlFa4YN1co0RnX59a56 CKAg== 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 t19si5744682ejx.443.2020.07.11.09.38.24; Sat, 11 Jul 2020 09:38:46 -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 S1728652AbgGKQiM (ORCPT + 99 others); Sat, 11 Jul 2020 12:38:12 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:58620 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728412AbgGKQiM (ORCPT ); Sat, 11 Jul 2020 12:38:12 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1juIVq-004dfe-Si; Sat, 11 Jul 2020 18:38:06 +0200 Date: Sat, 11 Jul 2020 18:38:06 +0200 From: Andrew Lunn To: Richard Cochran Cc: Jakub Kicinski , min.li.xe@renesas.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next] ptp: add debugfs support for IDT family of timing devices Message-ID: <20200711163806.GM1014141@lunn.ch> References: <1594395685-25199-1-git-send-email-min.li.xe@renesas.com> <20200710135844.58d76d44@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20200711134601.GD20443@hoboy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200711134601.GD20443@hoboy> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jul 11, 2020 at 06:46:01AM -0700, Richard Cochran wrote: > On Fri, Jul 10, 2020 at 01:58:44PM -0700, Jakub Kicinski wrote: > > On Fri, 10 Jul 2020 11:41:25 -0400 min.li.xe@renesas.com wrote: > > > From: Min Li > > > > > > This patch is to add debugfs support for ptp_clockmatrix and ptp_idt82p33. > > > It will create a debugfs directory called idtptp{x} and x is the ptp index. > > > Three inerfaces are present, which are cmd, help and regs. help is read > > > only and will display a brief help message. regs is read only amd will show > > > all register values. cmd is write only and will accept certain commands. > > > Currently, the accepted commands are combomode to set comobo mode and write > > > to write up to 4 registers. > > > > > > Signed-off-by: Min Li > > > > No private configuration interfaces in debugfs, please. > > I suggested to Min to use debugfs for device-specific configuration > that would be out of place in the generic PTP Hardware Clock > interface. > > > If what you're exposing is a useful feature it deserves a proper > > uAPI interface. > > Can you expand on what you mean by "proper uAPI interface" please? Hi Richard Well, one obvious issues is that debugfs it totally optional, and often not built. You would not want the correct operation of a device to depend something which is optional. debugfs is also unstable. There are no ABI rules. So user space cannot rely on the API being the same from version to version. Again, not something you want for the correct operation of a device. Allowing registers to be read, is a typical debug operation. So that part seems reasonable. A kernel developer/debugger has the skills to deal with unstable APIs, and rebuilding the kernel to actually have debugfs in the image. But configuration does not belong in debugfs. It would be good to explain what is being configured by these parameters, then we can maybe make a suggestion about the correct API to use. Andrew