On Thu, 17 Mar 2022 08:28:58 -0700 Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote: > > > On 3/17/22 08:25, kushagra765@xxxxxxxxxxx wrote: > > From ade08e81a63db0faf39791f9cd7c87e5787186f5 Mon Sep 17 00:00:00 2001 > > From: Kushagra Verma <kushagra765@xxxxxxxxxxx> > > Date: Thu, 17 Mar 2022 20:37:36 +0530 > > Subject: [PATCH] Documentation: fixed typos > > > > 1. Documentation/admin-guide/bootconfig.rst:207: fixed a typo in the word 'concatenated` > > 2. Documentation/atomic_t.txt:327: fixed a typo in the word `architecture` > > > > Signed-off-by: Kushagra Verma <kushagra765@xxxxxxxxxxx> > > Acked-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx> > > for the text changes. > But you should Cc one or more maintainers and the file's "owner". (done now) Thanks Randy, Acked-by: Masami Hiramatsu <mhiramat@xxxxxxxxxx> > > > --- > > Documentation/admin-guide/bootconfig.rst | 2 +- > > Documentation/atomic_t.txt | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/admin-guide/bootconfig.rst b/Documentation/admin-guide/bootconfig.rst > > index a1860fc0ca88..d4ea063aca0c 100644 > > --- a/Documentation/admin-guide/bootconfig.rst > > +++ b/Documentation/admin-guide/bootconfig.rst > > @@ -204,7 +204,7 @@ In addition to the kernel command line, the boot config can be used for > > passing the kernel parameters. All the key-value pairs under ``kernel`` > > key will be passed to kernel cmdline directly. Moreover, the key-value > > pairs under ``init`` will be passed to init process via the cmdline. > > -The parameters are concatinated with user-given kernel cmdline string > > +The parameters are concatenated with user-given kernel cmdline string > > as the following order, so that the command line parameter can override > > bootconfig parameters (this depends on how the subsystem handles parameters > > but in general, earlier parameter will be overwritten by later one.):: > > diff --git a/Documentation/atomic_t.txt b/Documentation/atomic_t.txt > > index 0f1ffa03db09..d7adc6d543db 100644 > > --- a/Documentation/atomic_t.txt > > +++ b/Documentation/atomic_t.txt > > @@ -324,7 +324,7 @@ atomic operations. > > > > Specifically 'simple' cmpxchg() loops are expected to not starve one another > > indefinitely. However, this is not evident on LL/SC architectures, because > > -while an LL/SC architecure 'can/should/must' provide forward progress > > +while an LL/SC architecture 'can/should/must' provide forward progress > > guarantees between competing LL/SC sections, such a guarantee does not > > transfer to cmpxchg() implemented using LL/SC. Consider: > > > > thanks. > -- > ~Randy -- Masami Hiramatsu <mhiramat@xxxxxxxxxx>
