From patchwork Tue May 16 10:38:49 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 762886 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3wRv8q4fMsz9s03 for ; Tue, 16 May 2017 20:39:55 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Hom4lHfU"; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=XmI80yR0yWXYWM/XkXsTNYlMFgtqlpRf6OtbUnOrLkA=; b=Hom4lHfUbw1MGT RZ5pnHrkWl8yR8JPC3jCQ51+rfL5uG2qfOlFqkUA+pKDE0l8i5QLX+yeSybJmKXJyb0k4SoWYeMFM aEhMwbBqJq8HNykWDCVWAzk/r/YrCGLaTDbYBmpY1u8kueE5ph79T1uHQ7m39LURiaV8qYLzy5ITc S/FiQL/OXiPwMGzUgfxiEqv6AjAavGSIM066S2YKr1PRR3D5la508wsrsZ035uv/t7fHJpM8c0Ti9 FV3e3hRJLWv791leYggk7WZlgsTYRKGss1FNnLLlOtFYq2LJEygY32puo0U1nq3lzxY+GvlVzl7UI fAQ+hFa+DoLSi2+5AcsA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1dAZtP-0001G1-DV; Tue, 16 May 2017 10:39:51 +0000 Received: from ec2-52-27-115-49.us-west-2.compute.amazonaws.com ([52.27.115.49] helo=osg.samsung.com) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1dAZsx-0000z6-Ou for linux-mtd@lists.infradead.org; Tue, 16 May 2017 10:39:30 +0000 Received: from localhost (localhost [127.0.0.1]) by osg.samsung.com (Postfix) with ESMTP id A3FA5A05F1; Tue, 16 May 2017 10:39:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at osg.samsung.com Received: from osg.samsung.com ([127.0.0.1]) by localhost (s-opensource.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl2_1I8tfpsc; Tue, 16 May 2017 10:39:25 +0000 (UTC) Received: from vento.lan (unknown [189.61.98.202]) by osg.samsung.com (Postfix) with ESMTPSA id 71EB3A05EE; Tue, 16 May 2017 10:39:20 +0000 (UTC) Date: Tue, 16 May 2017 07:38:49 -0300 From: Mauro Carvalho Chehab To: Boris Brezillon Subject: Re: [PATCH 0/5] Convert more books to ReST Message-ID: <20170516073849.787750d4@vento.lan> In-Reply-To: <20170515140912.100c9cac@bbrezillon> References: <20170515140912.100c9cac@bbrezillon> Organization: Samsung X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20170516_033924_418822_6B7C11B7 X-CRM114-Status: GOOD ( 29.61 ) X-Spam-Score: -0.9 (/) X-Spam-Report: SpamAssassin version 3.4.1 on bombadil.infradead.org summary: Content analysis details: (-0.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 1.0 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rich Felker , linux-sh@vger.kernel.org, Takashi Iwai , Sebastian Andrzej Siewior , "Herton R. Krzesinski" , linux-mtd@lists.infradead.org, Cyrille Pitchen , Markus Heiser , Yoshinori Sato , Jonathan Corbet , Richard Weinberger , Linux Doc Mailing List , Marek Vasut , sayli karnik , Jani Nikula , Mauro Carvalho Chehab , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, Silvio Fricke , Brian Norris , David Woodhouse Sender: "linux-mtd" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org Em Mon, 15 May 2017 14:09:12 +0200 Boris Brezillon escreveu: > On Sat, 13 May 2017 08:10:53 -0300 > Mauro Carvalho Chehab wrote: > > > This patch series convert the following books to ReST: > > - librs > > - mtdnand > > - sh > > > > And it is based on my previous series of conversion patches. > > > > After this series, there will be just one DocBook pending conversion: > > - lsm (Linux Security Modules) > > > > This book is very outdated: no changes since the Kernel moved > > to git, in 2005 (except for a minor editorial fix in 2008). > > > > I took a look on the described API: it doesn't seem to be describing > > the current security implementation. > > > > The best here is if someone that works with LSM to convert it to > > ReST with: > > $ Documentation/sphinx/tmplcvt Documentation/DocBook/lsm.tmpl lsm.rst > > > > And fix the document to produce something that reflects the current > > implementation. If nobody is interested, then maybe we could just > > drop it. > > > > - > > > > This patch series is based on my past 00/36 patch series, applied on > > the top of docs tree (next branch). > > > > The full patch series is on this tree is at: > > > > https://git.linuxtv.org//mchehab/experimental.git/log/?h=docbook > > > > And the HTML output at: > > > > http://www.infradead.org/~mchehab/kernel_docs/ > > https://mchehab.fedorapeople.org/kernel_docs/ > > > > Mauro Carvalho Chehab (5): > > docs-rst: convert librs book to ReST > > docs-rst: convert mtdnand book to ReST > > mtdnand.rst: Fix some typos and group the "::" with previous line > > MTD maintainers did not receive the above patch. Can you Cc us the > whole series next time. Sorry. I'll add you on the whole series. It will be a big one, though, as it will contain the other docbook conversions on it (~50+ patches). > BTW, I had a look at your branch and it seems the typo you're fixing is > actually not a type. Flags are *OR-ed* (with the | operator) to form a > valid combination of flags. Ah! Ok, I updated the patch (see enclosed). Would that be OK for you? > > mtd: adjust kernel-docs to avoid Sphinx/kerneldoc warnings > > Not sure how you plan to merge these changes, but if it goes through > a single tree I'll probably need an immutable topic branch, because I > plan to change a few things in nand_base.c nand.h for the next release. At least the patches that touch at Documentation/* should go, IMHO, via a single tree: git://git.lwn.net/linux.git docs-next As Jon mentioned, he doesn't rebase it, so you should be able to get an immutable branch from it. Thanks, Mauro --- [PATCH] mtdnand.rst: group the "::" with previous line Group the :: with the previous paragraph, in order to make it visually better when reading as a text file. While here, replace: ored (with means "Covered or adorned with ore or metal") by: OR-ed To reflect its true meaning. Signed-off-by: Mauro Carvalho Chehab diff --git a/Documentation/driver-api/mtdnand.rst b/Documentation/driver-api/mtdnand.rst index 8723175f955e..7c19795ebb4a 100644 --- a/Documentation/driver-api/mtdnand.rst +++ b/Documentation/driver-api/mtdnand.rst @@ -843,10 +843,8 @@ Chip option constants Constants for chip id table ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -These constants are defined in nand.h. They are ored together to -describe the chip functionality. - -:: +These constants are defined in nand.h. They are OR-ed together to +describe the chip functionality:: /* Buswitdh is 16 bit */ #define NAND_BUSWIDTH_16 0x00000002 @@ -867,10 +865,8 @@ describe the chip functionality. Constants for runtime options ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -These constants are defined in nand.h. They are ored together to -describe the functionality. - -:: +These constants are defined in nand.h. They are OR-ed together to +describe the functionality:: /* The hw ecc generator provides a syndrome instead a ecc value on read * This can only work if we have the ecc bytes directly behind the @@ -881,9 +877,7 @@ describe the functionality. ECC selection constants ----------------------- -Use these constants to select the ECC algorithm. - -:: +Use these constants to select the ECC algorithm:: /* No ECC. Usage is not recommended ! */ #define NAND_ECC_NONE 0 @@ -903,9 +897,7 @@ Hardware control related constants ---------------------------------- These constants describe the requested hardware access function when the -boardspecific hardware control function is called - -:: +boardspecific hardware control function is called:: /* Select the chip by setting nCE to low */ #define NAND_CTL_SETNCE 1 @@ -929,9 +921,7 @@ Bad block table related constants --------------------------------- These constants describe the options used for bad block table -descriptors. - -:: +descriptors:: /* Options for the bad block table descriptors */