From patchwork Wed Aug 31 16:49:13 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Robert P. J. Day" X-Patchwork-Id: 664620 X-Patchwork-Delegate: trini@ti.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from theia.denx.de (theia.denx.de [85.214.87.163]) by ozlabs.org (Postfix) with ESMTP id 3sPWZg2TMmz9sCY for ; Thu, 1 Sep 2016 02:49:46 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id F11C34B9AD; Wed, 31 Aug 2016 18:49:41 +0200 (CEST) Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULRDuv6b02oR; Wed, 31 Aug 2016 18:49:41 +0200 (CEST) Received: from theia.denx.de (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 334B44B93F; Wed, 31 Aug 2016 18:49:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id B483E4B93F for ; Wed, 31 Aug 2016 18:49:34 +0200 (CEST) Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2CWCdMvCqcs for ; Wed, 31 Aug 2016 18:49:34 +0200 (CEST) X-policyd-weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 (only DNSBL check requested) Received: from smtp685.redcondor.net (smtp685.redcondor.net [208.80.206.85]) by theia.denx.de (Postfix) with ESMTPS id 3ABE34B698 for ; Wed, 31 Aug 2016 18:49:30 +0200 (CEST) Received: from astoria.ccjclearline.com ([64.235.106.9]) by smtp685.redcondor.net ({20c8e40f-6b6c-4c9e-abff-1640ea7bf404}) via TCP (outbound) with ESMTPS id 20160831164927964_0685 for ; Wed, 31 Aug 2016 09:49:27 -0700 X-RC-FROM: X-RC-RCPT: Received: from [216.191.234.70] (port=37833 helo=crashcourse.ca) by astoria.ccjclearline.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1bf8jV-0000YM-NJ for u-boot@lists.denx.de; Wed, 31 Aug 2016 12:51:25 -0400 Date: Wed, 31 Aug 2016 12:49:13 -0400 (EDT) From: "Robert P. J. Day" X-X-Sender: rpjday@localhost.localdomain To: U-Boot list Message-ID: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 X-MAG-OUTBOUND: ccj.redcondor.net@64.235.106.9/32 Subject: [U-Boot] [PATCH] common/Kconfig: Fix various innocuous typos. X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.15 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" Correct a small number of spelling mistakes. Signed-off-by: Robert P. J. Day --- noticed one typo in this file so figured i might as well just do the whole thing. diff --git a/common/Kconfig b/common/Kconfig index 46e7173..4494112 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -9,13 +9,13 @@ config BOOTSTAGE give the entry a name with bootstage_mark_name(). You can also record elapsed time in a particular stage using bootstage_start() before starting and bootstage_accum() when finished. Bootstage will - add up all the accumated time and report it. + add up all the accumulated time and report it. Normally, IDs are defined in bootstage.h but a small number of - additional 'user' IDs can be used but passing BOOTSTAGE_ID_ALLOC + additional 'user' IDs can be used by passing BOOTSTAGE_ID_ALLOC as the ID. - Calls to show_boot_progress() wil also result in log entries but + Calls to show_boot_progress() will also result in log entries but these will not have names. config BOOTSTAGE_REPORT @@ -53,7 +53,7 @@ config BOOTSTAGE_FDT Stash the bootstage information in the FDT. A root 'bootstage' node is created with each bootstage id as a child. Each child has a 'name' property and either 'mark' containing the - mark time in microsecond, or 'accum' containing the + mark time in microseconds, or 'accum' containing the accumulated time for that bootstage id in microseconds. For example: @@ -114,7 +114,7 @@ config NAND_BOOT help Enabling this will make a U-Boot binary that is capable of being booted via NAND flash. This is not a must, some SoCs need this, - somes not. + some not. config ONENAND_BOOT bool "Support for booting from ONENAND" @@ -122,7 +122,7 @@ config ONENAND_BOOT help Enabling this will make a U-Boot binary that is capable of being booted via ONENAND. This is not a must, some SoCs need this, - somes not. + some not. config QSPI_BOOT bool "Support for booting from QSPI flash" @@ -130,7 +130,7 @@ config QSPI_BOOT help Enabling this will make a U-Boot binary that is capable of being booted via QSPI flash. This is not a must, some SoCs need this, - somes not. + some not. config SATA_BOOT bool "Support for booting from SATA" @@ -138,7 +138,7 @@ config SATA_BOOT help Enabling this will make a U-Boot binary that is capable of being booted via SATA. This is not a must, some SoCs need this, - somes not. + some not. config SD_BOOT bool "Support for booting from SD/EMMC" @@ -146,7 +146,7 @@ config SD_BOOT help Enabling this will make a U-Boot binary that is capable of being booted via SD/EMMC. This is not a must, some SoCs need this, - somes not. + some not. config SPI_BOOT bool "Support for booting from SPI flash" @@ -154,7 +154,7 @@ config SPI_BOOT help Enabling this will make a U-Boot binary that is capable of being booted via SPI flash. This is not a must, some SoCs need this, - somes not. + some not. endmenu @@ -174,7 +174,7 @@ config CONSOLE_RECORD bool "Console recording" help This provides a way to record console output (and provide console - input) through cirular buffers. This is mostly useful for testing. + input) through circular buffers. This is mostly useful for testing. Console output is recorded even when the console is silent. To enable console recording, call console_record_reset_enable() from your code.