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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AC92EC433FE for ; Tue, 29 Mar 2022 15:27:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238117AbiC2P2u (ORCPT ); Tue, 29 Mar 2022 11:28:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50488 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233601AbiC2P2u (ORCPT ); Tue, 29 Mar 2022 11:28:50 -0400 Received: from ms.lwn.net (ms.lwn.net [IPv6:2600:3c01:e000:3a1::42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F317E1271; Tue, 29 Mar 2022 08:27:07 -0700 (PDT) Received: from localhost (unknown [IPv6:2601:281:8300:35::5f6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id EDBAC732; Tue, 29 Mar 2022 15:27:06 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 ms.lwn.net EDBAC732 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lwn.net; s=20201203; t=1648567627; bh=J4BwUFEnERHD+GXWZTxjovQvtNqH+5sYie0SgwCqXpk=; h=From:To:Subject:In-Reply-To:References:Date:From; b=W1k6RhGshgO420otQc6BSAwtuJAMUaHZ616+tM0WyzUJd5CAQvaLB2JaBTXbDIs8K Dhz1TobDSQhos4+TFz2cD4rhdW2VE27WkDEqq/FBCIhPjqWGPoZQ9w3lGy+V/9nyeN sTlSxFxfSLzYskogQfuYd5vTyn3bSFAN7EXKxBb4jRFq2G5IuZ2UlqLBGcZ7+kns0c DMVzd+8p6fYQLKe24gjotWXGSvAXgWhWvQXXtsWWgUB0B+oReA0jURqFnr8jFUwTzm cK+BeIcUBVPe2OWlnWNXOyaxRK3kUXjbSr/3Y6DhWUuygMO0iec1mwCwKaNvldCc6F JPdfv1ZApDjsQ== From: Jonathan Corbet To: Bagas Sanjaya , Dipen Patel , thierry.reding@gmail.com, jonathanh@nvidia.com, smangipudi@nvidia.com, linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org, linux-gpio@vger.kernel.org, linus.walleij@linaro.org, bgolaszewski@baylibre.com, warthog618@gmail.com, devicetree@vger.kernel.org, linux-doc@vger.kernel.org, robh+dt@kernel.org Subject: Re: [PATCH v5 01/11] Documentation: Add HTE subsystem guide In-Reply-To: References: <20220329054521.14420-1-dipenp@nvidia.com> <20220329054521.14420-2-dipenp@nvidia.com> Date: Tue, 29 Mar 2022 09:27:06 -0600 Message-ID: <875ynw7p9x.fsf@meer.lwn.net> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org Bagas Sanjaya writes: > On 29/03/22 12.45, Dipen Patel wrote: >> +============================================ >> +The Linux Hardware Timestamping Engine (HTE) >> +============================================ >> + >> +:Author: Dipen Patel >> + > > Please learn how to convey semantics with rst format, see further comments > below. That is the Sphinx "field list" syntax; it's pretty heavily used throughout the kernel documentation and doesn't seem to merit that sort of response...? [...] >> +The struct hte_ts_data is used to pass timestamp details between the consumers >> +and the providers. It expresses timestamp data in nanoseconds in u64 data >> +type. For now all the HTE APIs using struct hte_ts_data require tsc to be in >> +nanoseconds. An example of the typical hte_ts_data data life cycle, for the >> +GPIO line is as follows:: >> + > > When we talk about name terms found in actual code (like keywords or variable > names), it is customary to enclose them inside inline code (for example, > ``struct what`` or ``u64 what``). It's also customary to minimize markup. In the case of "struct whatever" the markup is actively harmful since it interferes with the automatic recognition and cross-referencing of the type. jon