From nobody Sun Apr 26 21:28:10 2026 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 58114CCA47D for ; Wed, 22 Jun 2022 08:48:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351709AbiFVIsD (ORCPT ); Wed, 22 Jun 2022 04:48:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45736 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234486AbiFVIsC (ORCPT ); Wed, 22 Jun 2022 04:48:02 -0400 Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5677125E1; Wed, 22 Jun 2022 01:48:00 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id h34-20020a17090a29a500b001eb01527d9eso15263123pjd.3; Wed, 22 Jun 2022 01:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=Hs9pVTpUBi42eMdaATCBVLHpAcP7Nw426zvueY8ZwZI=; b=Lw0reKp119fQgW191FyyK0jxb52gIGmRolrrEJan5fK67WbHe6KIeUNsg7pgDoqjtT RzO3qPtfgxrYlG/fRm0u8QBkiO/igrt4hSQwVNHETFmkLoMkwJwaTT7mpeooVbsiN9fL 8I2KrBsqduyUa+VSUxarzQxWslOLClxg5whYaXKY5ZXnOuK8gMQsLEa1DKU8/SxqlH8n JDIBbuDtZGUR1qz4pUDcY0uXn6Pnfk+jzwUo8vRF+Ni0gZrppyu5+G7IElQJbAJFbwn0 NqXSmHspY8OWIBFYtfgkweYjzXgs0aK/59uJPuDKoM/hHkfGSay0c1bnYIx4JIInMCOP 4hDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=Hs9pVTpUBi42eMdaATCBVLHpAcP7Nw426zvueY8ZwZI=; b=LpslrHezcQCyHm+VEVOTMSRLxERozF5drOOxNliCDm+PvFI48R5ewUZFZDvUfOlHXB CiS42FKzNGekZu4/SFcMTCZ8t6nV6h8VsPZIN1MmiyDZrS62RhnuhLnzfVftanH/w7Xb fD1/ELS69tDMN38UysZJc2BcHHv/TJLbdRvrN57nXuPka5xn6WTrgy0yD3yNvzea5bRH OYk+IQU5rn9TYIblw1yzOTq/mRXy9dlxW1kAASrx0egwfY3/IM14eIKIdq42sMUZcMce w0pw3vxeIHNbJ3DwglR1aticwaxd3dmd+OBEKZMQySuUm0/fLKuVounTlz1N4/esGpEy ALoA== X-Gm-Message-State: AJIora8D/KuQauig3+F3RJvHYeFYHw6u13wM0xxeVyn/WxwdhrC5/1Dx vLjTykhbpAh4TUfxsWKhek9+7vNE31s= X-Google-Smtp-Source: AGRyM1shJvjitaGBPWgz/pdx6BV2OQUPOBwCHk3mBN4tYOSIhFIxvffRnNlgoVtOp/xm7tZgDMdKLQ== X-Received: by 2002:a17:902:d509:b0:167:6ed8:afb5 with SMTP id b9-20020a170902d50900b001676ed8afb5mr33549819plg.137.1655887679517; Wed, 22 Jun 2022 01:47:59 -0700 (PDT) Received: from debian.me (subs02-180-214-232-91.three.co.id. [180.214.232.91]) by smtp.gmail.com with ESMTPSA id a9-20020a170902ecc900b001677fa34a4fsm8199930plh.72.2022.06.22.01.47.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Jun 2022 01:47:58 -0700 (PDT) From: Bagas Sanjaya To: linux-doc@vger.kernel.org Cc: Bagas Sanjaya , Andrew Morton , Ira Weiny , "Matthew Wilcox (Oracle)" , "Fabio M. De Francesco" , Sebastian Andrzej Siewior , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v4] Documentation: highmem: Use literal block for code example in highmem.h comment Date: Wed, 22 Jun 2022 15:45:46 +0700 Message-Id: <20220622084546.17745-1-bagasdotme@gmail.com> X-Mailer: git-send-email 2.36.0 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" When building htmldocs on Linus' tree, there are inline emphasis warnings on include/linux/highmem.h: Documentation/vm/highmem:166: ./include/linux/highmem.h:154: WARNING: Inlin= e emphasis start-string without end-string. Documentation/vm/highmem:166: ./include/linux/highmem.h:157: WARNING: Inlin= e emphasis start-string without end-string. These warnings above are due to comments in code example at the mentioned lines above are enclosed by double dash (--), which confuses Sphinx as inline markup delimiters instead. Fix these warnings by indenting the code example with literal block indentation and making the comments C comments. Fixes: 85a85e7601263f ("Documentation/vm: move "Using kmap-atomic" to highm= em.h") Cc: Andrew Morton Cc: Ira Weiny Cc: "Matthew Wilcox (Oracle)" Cc: "Fabio M. De Francesco" Cc: Sebastian Andrzej Siewior Cc: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Bagas Sanjaya Reviewed-by: Ira Weiny Tested-by: Ira Weiny --- Changes since v3 [1]: - Say "C comments" rephrase (suggested by Ira) [1]: https://lore.kernel.org/linux-doc/20220620083649.18172-1-bagasdotme@g= mail.com/ include/linux/highmem.h | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/include/linux/highmem.h b/include/linux/highmem.h index 3af34de54330cb..56d6a019653489 100644 --- a/include/linux/highmem.h +++ b/include/linux/highmem.h @@ -149,19 +149,19 @@ static inline void *kmap_local_folio(struct folio *fo= lio, size_t offset); * It is used in atomic context when code wants to access the contents of a * page that might be allocated from high memory (see __GFP_HIGHMEM), for * example a page in the pagecache. The API has two functions, and they - * can be used in a manner similar to the following: + * can be used in a manner similar to the following:: * - * -- Find the page of interest. -- - * struct page *page =3D find_get_page(mapping, offset); + * // Find the page of interest. + * struct page *page =3D find_get_page(mapping, offset); * - * -- Gain access to the contents of that page. -- - * void *vaddr =3D kmap_atomic(page); + * // Gain access to the contents of that page. + * void *vaddr =3D kmap_atomic(page); * - * -- Do something to the contents of that page. -- - * memset(vaddr, 0, PAGE_SIZE); + * // Do something to the contents of that page. + * memset(vaddr, 0, PAGE_SIZE); * - * -- Unmap that page. -- - * kunmap_atomic(vaddr); + * // Unmap that page. + * kunmap_atomic(vaddr); * * Note that the kunmap_atomic() call takes the result of the kmap_atomic() * call, not the argument. base-commit: a111daf0c53ae91e71fd2bfe7497862d14132e3e --=20 An old man doll... just what I always wanted! - Clara