Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp1605220pxb; Thu, 16 Sep 2021 10:55:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyLw0T8ssmYN2kY+8hD57/K00H9dOomnyEYFrTFKSubCM4NevGFE5kS075mry2PcAYi9FcJ X-Received: by 2002:a6b:8b4b:: with SMTP id n72mr5257057iod.18.1631814901547; Thu, 16 Sep 2021 10:55:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631814901; cv=none; d=google.com; s=arc-20160816; b=MKlUzfHEOBx21PLzFdH3ha55mT+veYP/yUwgSrtjkvTxgiSPqCR+Tt+hv88l25v+3c dnBZkQYS0jjHJAY1J3ORBNJ0a2fIJ0r1cyHqDqcjFD1NCx71T48EeT2KgpzVf5StAMuZ qFB0sIhZMWlSSUJCznM7/tKg1dnx/3FBlyh2AbKacJoYrX2k3V5ess1BhtBaruNy1/VU ho/cipEOoHWlO/sQDsnRyAFyd7rDz78OZszvRFOhRAqQQ7lm8C+pgmlbzbEB2EICQ2la 0JUTFybsv/J0XLt0fh8gwCjKbQbLJ1AryiROakdvAlFRAleATdXX7DAMSa4LKobN69N0 Dh6g== 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=5c/ecdXYtBKNaT4XUXBBjwKqQDAkBCfFl+45+deqxV8=; b=wIGY36SXRzwxr+sZdGDlK6ZGz8mWOzBabXBrZR9PqOwFrc/VNY1MDTaGBMxJy6M8KH RZ0Zc1HU1ydhCk4HAN+1abUcXghb+3ERR3+6j3VSaXk0CzGJJAgk9ni9xduRv3dzZ9xg dIzaPKFKYRbeLhWrYR/KYblXK3sEa266aAh4MS5Gf+jcrsZyvfQLB2DXUeOYpGjaZfuo nmovSOqW0LNPpDEyDxCfYsY04k1ljQQF5YhGILtDyCbByb/6FXy6gimc31kyXF54HoMm iyB3XHUyIq6wXpBNWfq+ZyWn3eZA2bJ+npPu4coUwKMVMqKAGuN4oLyx649VN5dXoJDX tdkg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=LOuIWXdW; 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=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m43si3268751jav.131.2021.09.16.10.54.50; Thu, 16 Sep 2021 10:55:01 -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=@linuxfoundation.org header.s=korg header.b=LOuIWXdW; 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=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357795AbhIPRwT (ORCPT + 99 others); Thu, 16 Sep 2021 13:52:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:57130 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355841AbhIPRmL (ORCPT ); Thu, 16 Sep 2021 13:42:11 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id D2EFA60F6D; Thu, 16 Sep 2021 17:22:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1631812966; bh=Q08H6DZ4BxEkJU51LQTF5dWsZstlotAhOnYpzocUYrE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LOuIWXdWIRQsT/0L1Ibt06eIM32VeSHQ2vmabx301G+E2x5v4EfaA9tlAUeNgtbqr z8xj/i3khu0VRr5cOZRqU0UGZlX++5vd26VWctRjU5WgbiETuFzpVsz701jYWGGi6t hpsf4rKeulnUCseI4Ryzdh7vj3Nd74A9y8IgAcnw= Date: Thu, 16 Sep 2021 19:22:43 +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 05:01:10PM +0000, Min Li wrote: > > > > -----Original Message----- > > From: Greg KH > > Sent: September 16, 2021 12:05 PM > > 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 Thu, Sep 16, 2021 at 03:54:52PM +0000, Min Li wrote: > > > > > > > > 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! :) > > > > > > Yes it is on our roadmap to do that for next release > > > > Please do it for this kernel api, otherwise you have to support this for the > > next 20+ years as-is :( > > > > In that case, I would have to get back to you in a few months. If you are rejecting this > change due to this reason. Please tell me explicitly so that I can copy paste to my manager > and that would be it. Thanks Please come up with a unified api that will work with all devices of this type, and not a one-off ioctl with random structures in it that are directly tied to the hardware. > > > > 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? > > > > > > > We used to do everything in userspace. But since PHC (ptp hardware > > > clock) came along, we decided to move the driver part to kernel. Please > > take a look at drivers/ptp/ptp_clockmatrix.c for reference. > > > Recently, we have some functions like APTS that doesn't belong to PTP > > > or anything else so we have to split those functions to RSMU misc driver > > and i2c/spi bus accesses to RSMU MFD driver. > > > > I still do not understand why this has to be a kernel driver, sorry. > > What exactly forces it to be that way? > > > That is our management decision since everyone is trying to move their driver to Linux kernel > to contribute so that we don't have to release the driver to each customer separately. The customer > can just grab the driver from linux Don't use the kernel as your distribution method for things that should not belong in the kernel. There is no need for creating and maintain kernel modules for drivers that do not need to be drivers at all. That feels like you would be doing extra work here. Writing a simple userspace library for this that works for all kernel versions would be much easier. thanks, greg k-h