Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <BYAPR11MB3240F382BD180FF90C7DF0B9E1069@BYAPR11MB3240.namprd11.prod.outlook.com>
 <7de35859-97ab-8e88-f590-d5851b81773b@nvidia.com> <BYAPR11MB32405F4FA22BB47BD03C8F18E10C9@BYAPR11MB3240.namprd11.prod.outlook.com>
 <CACRpkdbY5aU3OTufA0q+N7Pwm0shGgnjScAGR_96oo9XdgBDhQ@mail.gmail.com>
 <34baa0b1-72c3-e4b3-3eaf-9b07fe86c3df@nvidia.com> <BYAPR11MB324034C53D14D8F7E332A3C5E1179@BYAPR11MB3240.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB324034C53D14D8F7E332A3C5E1179@BYAPR11MB3240.namprd11.prod.outlook.com>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Sat, 3 Dec 2022 10:49:50 +0100
Message-ID: <CACRpkdaTaDNB12vkmUVdmk0yBH-YW07RfcDO97q7d+ppLHj_iQ@mail.gmail.com>
Subject: Re: Intel timed i/o driver in HTE
To:     "N, Pandith" <pandith.n@intel.com>, Johan Hovold <johan@kernel.org>
Cc:     Dipen Patel <dipenp@nvidia.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Hall, Christopher S" <christopher.s.hall@intel.com>,
        "Gross, Mark" <mark.gross@intel.com>,
        "Sangannavar, Mallikarjunappa" 
        <mallikarjunappa.sangannavar@intel.com>,
        "D, Lakshmi Sowjanya" <lakshmi.sowjanya.d@intel.com>,
        "T R, Thejesh Reddy" <thejesh.reddy.t.r@intel.com>,
        "andriy.shevchenko@linux.intel.com" 
        <andriy.shevchenko@linux.intel.com>,
        "timestamp@lists.linux.dev" <timestamp@lists.linux.dev>,
        Arnd Bergmann <arnd@arndb.de>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Dec 2, 2022 at 4:00 AM N, Pandith <pandith.n@intel.com> wrote:

> > 1. Does timed io only meant for GPIO or other signals? if other signals, what
> > type of signals?
> This could be time sync signals or periodic/single pulse input for timestamp support
(...)
> b. char device creation for timestamping hardware. Something like /dev/hteX

No way this goes to userspace if the usecase is synchronizing GPS time.

It should be in the kernel, where the timebase of the system is.

We already created drivers/gnss because power, clock etc management
need to be close to the hardware, in the kernel. Don't try to push this
up to userspace, group it with the rest of the kernel GPS handling.

If your GPS vendor doesn't want the kernel to talk directly to the GPS,
bad luck, because the kernel definitely should in this case.  The kernel
has the best time source and the shortest access path to it, so there
you go.

The GPS vendors have already created enough of a mess by not having
open documentation for their hardware, if this is an incentive for them to
be more open if they want proper time sync that is *good*.

Yours,
Linus Walleij