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) > --- > 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
