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=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, 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 90710C433EF for ; Thu, 16 Sep 2021 15:39:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 719DC6120E for ; Thu, 16 Sep 2021 15:39:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239059AbhIPPlM (ORCPT ); Thu, 16 Sep 2021 11:41:12 -0400 Received: from mail.kernel.org ([198.145.29.99]:49488 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229523AbhIPPlK (ORCPT ); Thu, 16 Sep 2021 11:41:10 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id BDA9E61212; Thu, 16 Sep 2021 15:39:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1631806790; bh=3vn7YL+5sPCmEXebrf4gKwhwgVs86WlquEukFERKLso=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=r/vyyKO45JfHuuabM34iB46x0O9VKg9Z6ypahOTEL8LyIUkcHSaY7/24NLWYXKdRP CSvP03zCdgtSOgXC8UusFtPoxIe4dgTE8uQUGfLg6ym6mzZClYrw6kLCr1rpCYgPYb 4jQHgTAP54tTeVqRIudc4Of5PClhH0Cch+0o7yWI= Date: Thu, 16 Sep 2021 17:39:47 +0200 From: Greg KH To: Min Li Cc: "arnd@arndb.de" , "derek.kiernan@xilinx.com" , "dragan.cvetic@xilinx.com" , "linux-kernel@vger.kernel.org" , "lee.jones@linaro.or" Subject: Re: [PATCH misc v2 2/2] misc: Add Renesas Synchronization Management Unit (SMU) support Message-ID: References: <1631731629-20862-1-git-send-email-min.li.xe@renesas.com> <1631731629-20862-2-git-send-email-min.li.xe@renesas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 16, 2021 at 03:33:06PM +0000, Min Li wrote: > > > > -----Original Message----- > > From: Greg KH > > Sent: September 16, 2021 1:26 AM > > To: Min Li > > Cc: arnd@arndb.de; derek.kiernan@xilinx.com; dragan.cvetic@xilinx.com; > > linux-kernel@vger.kernel.org; lee.jones@linaro.or > > Subject: Re: [PATCH misc v2 2/2] misc: Add Renesas Synchronization > > Management Unit (SMU) support > > > > On Wed, Sep 15, 2021 at 02:47:09PM -0400, min.li.xe@renesas.com wrote: > > > From: Min Li > > > > > > This driver is developed for the IDT ClockMatrix(TM) and 82P33xxx > > > families of timing and synchronization devices.It will be used by > > > Renesas PTP Clock Manager for Linux (pcm4l) software to provide > > > support to GNSS assisted partial timing support (APTS) and other > > networking timing functions. > > > > Where is that software? > > https://www.renesas.com/us/en/software-tool/ptp-clock-manager-linux Please put that link in the changelog comment and in the .c code as well so that people know where to find it. > > > > Why is this new api not a standard one? > > > > There is no actual standard for the GNSS assisted partial timing support (APTS) > In terms of Linux kernel API Then make one! :) > > What is the standard here? > > > > What do other devices do and why is this a new api? > > > > There is really no standard for APTS and different company has its own hw/sw solutions But userspace has to all deal with this in a standard way somehow, right? What libraries and apis do they interact with there? > > > Current version provides kernel API's to support the following > > > functions -set combomode to enable SYNCE clock support -read dpll's > > > state to determine if the dpll is locked to the GNSS channel -read > > > dpll's ffo (fractional frequency offset) in ppqt > > > > Why do all of these have to be in the kernel at all? > > > > Because all these API's need spi/i2c accesses to the RSMU card and spi/i2c accesses have been > abstracted to the MFD driver in kernel Why not just do this all from userspace then? You can have spi/i2c userspace code, right? Why does this have to be a kernel driver? thanks, greg k-h