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=-5.8 required=3.0 tests=BAYES_00,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 57C41C49EA6 for ; Sun, 27 Jun 2021 11:49:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 220DE6023F for ; Sun, 27 Jun 2021 11:49:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229761AbhF0Lvq (ORCPT ); Sun, 27 Jun 2021 07:51:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53750 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229820AbhF0Lvp (ORCPT ); Sun, 27 Jun 2021 07:51:45 -0400 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 992B7C061787 for ; Sun, 27 Jun 2021 04:49:21 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id k10so26113199lfv.13 for ; Sun, 27 Jun 2021 04:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tpoElu9HhDNMGczYWroxZynDrE3+UL8THrpTkrlrgBE=; b=SeMq4I4fzXXSXZW+ZTJ4cnYUEmcGafFSMeE7zSJzNqKsEB54rze3vvRxqcbaxeFqbt UjmCQ1gN+BMf1s2+0oeI1XU6ZKLo/cisq0n4u0rgL+JJErn6sXBtdXgZyMCYmFeTKIQW mp1vRjWQSOO4NoVUJ2WrGNXnvKqhmp7uVDyXmWm3bhxP2oWTdAzD6tSC8JUz2ufrlsyA 6IgvBRUnYwmBpq+Iie0X2AuqlJOs0WqkZv3pixeIozAFt8FbK/4DYNDXlWYS/olf1uZK xfCg5zj49WCyoCCYH/IbxQCifxirtTFJALHF3uun6ZmVLct6Av2uFUoJkDy7WsrLGIjz HDXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tpoElu9HhDNMGczYWroxZynDrE3+UL8THrpTkrlrgBE=; b=Wwu5RC3jrcn8SI0TRMww+ABDi8YhmbBP/OhATbxHaV5sV/oZPuTO2q6hFEXtRbi0LG oQ+0NuvqluVUBjcZ/6v4szc9N7goYC3BYh5Wc9rhLWIE98IxGX3vDvMsNlfwTytgTzeB einuv4t5nbpInXfUv+IFsMP/nxfi+xb905cm0I6j7wrV0n/HY8Gmdgwm7lxRBDRJO2Ib T3PJyDwgLrQ9OE+P9rTBWeF5UTlBDI22pYuqLMHqE+y0qp0WEzuwBtx0yoEQwbURnboi vA7KkMFCNaMXnOaCiM0EpWGP0ojMbn0Wray7cId8Hz9YqdzWkPMWmTGnPCjaXIFk7wd5 VgJA== X-Gm-Message-State: AOAM532KYeSpT+Tojw3PMWd7Xti916IZwPPAbHiSiambWCZEr9ozH+2u 8sadcrh6IgCFtT7gtbhDFIIM1g5Kqzy81rZ2BlARyQ== X-Google-Smtp-Source: ABdhPJzsY3TPEADWEnLuc1HU6Lu+XDBmazMUEMM7MH6onGvPBHXknFq0Gn3MrsAqwkzfG8hkFw55hjaWWDobzdrUXaI= X-Received: by 2002:a05:6512:1508:: with SMTP id bq8mr15388692lfb.529.1624794559770; Sun, 27 Jun 2021 04:49:19 -0700 (PDT) MIME-Version: 1.0 References: <20210625235532.19575-1-dipenp@nvidia.com> <20210625235532.19575-9-dipenp@nvidia.com> In-Reply-To: <20210625235532.19575-9-dipenp@nvidia.com> From: Linus Walleij Date: Sun, 27 Jun 2021 13:49:08 +0200 Message-ID: Subject: Re: [RFC 08/11] gpiolib: cdev: Add hardware timestamp clock type To: Dipen Patel Cc: "thierry.reding@gmail.com" , Jon Hunter , linux-kernel , linux-tegra , "open list:GPIO SUBSYSTEM" , Bartosz Golaszewski , Kent Gibson , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux Doc Mailing List , Rob Herring Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Sat, Jun 26, 2021 at 1:48 AM Dipen Patel wrote: Just a quick question about this: > + GPIO_V2_LINE_FLAG_EVENT_CLOCK_HARDWARE | \ Is the usage intended to be such that since hardware timestamp can not be guaranteed we need to ask for it and fail and if that fails maybe the software wants to fall back to the realtime or common timestamp? I'm thinking from the view of libgpiod or similar apps that abstract this and they will be "I want to use hardware timestamps if and only if it is available, otherwise I want to use this other timestamp" or is that use case uncommon, such that either you know exactly what you want or you should not be messing with hardware timestamps? Yours, Linus Walleij