| Message ID | 20230129235701.2393241-1-conor@kernel.org (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 2a5303b499b18de7179ee1b4ab759880fb02ec9c |
| Delegated to: | Palmer Dabbelt |
| Headers | show |
| Series | Documentation: riscv: fix insufficient list item indent | expand |
| Context | Check | Description |
|---|---|---|
| conchuod/cover_letter | success | Single patches do not need cover letters |
| conchuod/tree_selection | success | Guessed tree name to be for-next |
| conchuod/fixes_present | success | Fixes tag not required for -next series |
| conchuod/maintainers_pattern | success | MAINTAINERS pattern errors before the patch: 13 and now 13 |
| conchuod/verify_signedoff | success | Signed-off-by tag matches author and committer |
| conchuod/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| conchuod/module_param | success | Was 0 now: 0 |
| conchuod/build_rv64_gcc_allmodconfig | success | Errors and warnings before: 0 this patch: 0 |
| conchuod/alphanumeric_selects | success | Out of order selects before the patch: 57 and now 57 |
| conchuod/build_rv32_defconfig | success | Build OK |
| conchuod/dtb_warn_rv64 | success | Errors and warnings before: 2 this patch: 2 |
| conchuod/header_inline | success | No static functions without inline keyword in header files |
| conchuod/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 14 lines checked |
| conchuod/source_inline | success | Was 0 now: 0 |
| conchuod/build_rv64_nommu_k210_defconfig | success | Build OK |
| conchuod/verify_fixes | success | Fixes tag looks correct |
| conchuod/build_rv64_nommu_virt_defconfig | success | Build OK |
On Sun, Jan 29, 2023 at 11:57:01PM +0000, Conor Dooley wrote: > From: Conor Dooley <conor.dooley@microchip.com> > > When adding the ISA string ordering rules, I didn't sufficiently indent > one of the list items. > > Reported-by: kernel test robot <lkp@intel.com> > Fixes: f07b2b3f9d47 ("Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo") > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Seems like you forget to add link to the report: Link: https://lore.kernel.org/linux-doc/202301300743.bp7Dpazv-lkp@intel.com/ > --- > Documentation/riscv/uabi.rst | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/Documentation/riscv/uabi.rst b/Documentation/riscv/uabi.rst > index 2ebec4c52230..8960fac42c40 100644 > --- a/Documentation/riscv/uabi.rst > +++ b/Documentation/riscv/uabi.rst > @@ -21,10 +21,10 @@ so for our purposes the following rules apply: > single-letter extensions and before any higher-privileged extensions. > > #. For additional standard extensions, the first letter following the 'Z' > - conventionally indicates the most closely related alphabetical > - extension category. If multiple 'Z' extensions are named, they will be ordered > - first by category, in canonical order, as listed above, then alphabetically > - within a category. > + conventionally indicates the most closely related alphabetical > + extension category. If multiple 'Z' extensions are named, they will be > + ordered first by category, in canonical order, as listed above, then > + alphabetically within a category. > > #. Standard supervisor-level extensions (starting with 'S') will be listed > after standard unprivileged extensions. If multiple supervisor-level The warning is fixed, thanks! Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
On Mon, Jan 30, 2023 at 10:05:53AM +0700, Bagas Sanjaya wrote: > On Sun, Jan 29, 2023 at 11:57:01PM +0000, Conor Dooley wrote: > > From: Conor Dooley <conor.dooley@microchip.com> > > > > When adding the ISA string ordering rules, I didn't sufficiently indent > > one of the list items. > > > > Reported-by: kernel test robot <lkp@intel.com> > > Fixes: f07b2b3f9d47 ("Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo") > > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > > Seems like you forget to add link to the report: > > Link: https://lore.kernel.org/linux-doc/202301300743.bp7Dpazv-lkp@intel.com/ No, I didn't forget actually. I just didn't think it added any useful information. No harm having it though I suppose, but I'll not resend to add it. Thanks, Conor.
Hey Palmer, If you do end up having WiFi could you pick this up so that the regressions report thingy stops whining at me? Thanks! On Sun, Jan 29, 2023 at 11:57:01PM +0000, Conor Dooley wrote: > From: Conor Dooley <conor.dooley@microchip.com> > > When adding the ISA string ordering rules, I didn't sufficiently indent > one of the list items. > > Reported-by: kernel test robot <lkp@intel.com> > Fixes: f07b2b3f9d47 ("Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo") > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > --- > Documentation/riscv/uabi.rst | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/Documentation/riscv/uabi.rst b/Documentation/riscv/uabi.rst > index 2ebec4c52230..8960fac42c40 100644 > --- a/Documentation/riscv/uabi.rst > +++ b/Documentation/riscv/uabi.rst > @@ -21,10 +21,10 @@ so for our purposes the following rules apply: > single-letter extensions and before any higher-privileged extensions. > > #. For additional standard extensions, the first letter following the 'Z' > - conventionally indicates the most closely related alphabetical > - extension category. If multiple 'Z' extensions are named, they will be ordered > - first by category, in canonical order, as listed above, then alphabetically > - within a category. > + conventionally indicates the most closely related alphabetical > + extension category. If multiple 'Z' extensions are named, they will be > + ordered first by category, in canonical order, as listed above, then > + alphabetically within a category. > > #. Standard supervisor-level extensions (starting with 'S') will be listed > after standard unprivileged extensions. If multiple supervisor-level > -- > 2.39.1 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv >
On Sun, 29 Jan 2023 23:57:01 +0000, Conor Dooley wrote: > When adding the ISA string ordering rules, I didn't sufficiently indent > one of the list items. > > Applied, thanks! [1/1] Documentation: riscv: fix insufficient list item indent https://git.kernel.org/palmer/c/377804b13d8b Best regards,
On Tue, 07 Feb 2023 06:58:54 PST (-0800), Conor Dooley wrote: > Hey Palmer, > > If you do end up having WiFi could you pick this up so that the > regressions report thingy stops whining at me? Sorry I forgot about this one, it's on for-next. > > Thanks! > > On Sun, Jan 29, 2023 at 11:57:01PM +0000, Conor Dooley wrote: >> From: Conor Dooley <conor.dooley@microchip.com> >> >> When adding the ISA string ordering rules, I didn't sufficiently indent >> one of the list items. >> >> Reported-by: kernel test robot <lkp@intel.com> >> Fixes: f07b2b3f9d47 ("Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo") >> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> >> --- >> Documentation/riscv/uabi.rst | 8 ++++---- >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/Documentation/riscv/uabi.rst b/Documentation/riscv/uabi.rst >> index 2ebec4c52230..8960fac42c40 100644 >> --- a/Documentation/riscv/uabi.rst >> +++ b/Documentation/riscv/uabi.rst >> @@ -21,10 +21,10 @@ so for our purposes the following rules apply: >> single-letter extensions and before any higher-privileged extensions. >> >> #. For additional standard extensions, the first letter following the 'Z' >> - conventionally indicates the most closely related alphabetical >> - extension category. If multiple 'Z' extensions are named, they will be ordered >> - first by category, in canonical order, as listed above, then alphabetically >> - within a category. >> + conventionally indicates the most closely related alphabetical >> + extension category. If multiple 'Z' extensions are named, they will be >> + ordered first by category, in canonical order, as listed above, then >> + alphabetically within a category. >> >> #. Standard supervisor-level extensions (starting with 'S') will be listed >> after standard unprivileged extensions. If multiple supervisor-level >> -- >> 2.39.1 >> >> >> _______________________________________________ >> linux-riscv mailing list >> linux-riscv@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-riscv >>
On Sun, 29 Jan 2023 19:05:53 PST (-0800), bagasdotme@gmail.com wrote: > On Sun, Jan 29, 2023 at 11:57:01PM +0000, Conor Dooley wrote: >> From: Conor Dooley <conor.dooley@microchip.com> >> >> When adding the ISA string ordering rules, I didn't sufficiently indent >> one of the list items. >> >> Reported-by: kernel test robot <lkp@intel.com> >> Fixes: f07b2b3f9d47 ("Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo") >> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > > Seems like you forget to add link to the report: > > Link: https://lore.kernel.org/linux-doc/202301300743.bp7Dpazv-lkp@intel.com/ Is that the normal way to do it? I've only been adding the Reported-by like the bot suggests, but I guess it's kind of nice information to have the bug report as well. From looking at git history it's kind of a mix. Maybe the bot should suggest this in the bug report, right next to the other tag? >> --- >> Documentation/riscv/uabi.rst | 8 ++++---- >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/Documentation/riscv/uabi.rst b/Documentation/riscv/uabi.rst >> index 2ebec4c52230..8960fac42c40 100644 >> --- a/Documentation/riscv/uabi.rst >> +++ b/Documentation/riscv/uabi.rst >> @@ -21,10 +21,10 @@ so for our purposes the following rules apply: >> single-letter extensions and before any higher-privileged extensions. >> >> #. For additional standard extensions, the first letter following the 'Z' >> - conventionally indicates the most closely related alphabetical >> - extension category. If multiple 'Z' extensions are named, they will be ordered >> - first by category, in canonical order, as listed above, then alphabetically >> - within a category. >> + conventionally indicates the most closely related alphabetical >> + extension category. If multiple 'Z' extensions are named, they will be >> + ordered first by category, in canonical order, as listed above, then >> + alphabetically within a category. >> >> #. Standard supervisor-level extensions (starting with 'S') will be listed >> after standard unprivileged extensions. If multiple supervisor-level > > The warning is fixed, thanks! > > Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com> > > -- > An old man doll... just what I always wanted! - Clara
On Thu, Feb 09, 2023 at 10:48:58AM -0800, Palmer Dabbelt wrote: > On Sun, 29 Jan 2023 19:05:53 PST (-0800), bagasdotme@gmail.com wrote: > > On Sun, Jan 29, 2023 at 11:57:01PM +0000, Conor Dooley wrote: > > > From: Conor Dooley <conor.dooley@microchip.com> > > > > > > When adding the ISA string ordering rules, I didn't sufficiently indent > > > one of the list items. > > > > > > Reported-by: kernel test robot <lkp@intel.com> > > > Fixes: f07b2b3f9d47 ("Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo") > > > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > > > > Seems like you forget to add link to the report: > > > > Link: https://lore.kernel.org/linux-doc/202301300743.bp7Dpazv-lkp@intel.com/ > > Is that the normal way to do it? I've only been adding the Reported-by like > the bot suggests, but I guess it's kind of nice information to have the bug > report as well. From looking at git history it's kind of a mix. IMO it totally depends on whether there is something useful in the thread on lore. I see no point adding the links if they're just a regurgitation of something conveyed in a commit message. But then again, I don't bother adding a lore link to patchsets I apply either. I'm in the Torvald's camp of only using those tags to link to things containing "actual new information". There was a discussion of that a while back, see [1] & [2] if you care, although it was largely born out of frustration at links added by maintainers to original submissions, not subjectively redundant bot emails. Following that logic, I didn't bother adding one here, just as I wouldn't for a compilation error if I included it in the commit log. We've probably spent more time typing emails about it than the issue warrants, but that's par for the course I suppose! 1 - https://lore.kernel.org/all/CAHk-=wj9zKJGA_6SJOMPiQEoYke6cKX-FV3X_5zNXOcFJX1kOQ@mail.gmail.com/ 2 - https://lore.kernel.org/all/CAHk-=wgzRUT1fBpuz3xcN+YdsX0SxqOzHWRtj0ReHpUBb5TKbA@mail.gmail.com/ > Maybe the bot should suggest this in the bug report, right next to the other > tag? Iff the bot knows its own message-id before sending, I think that could be nice to have. Does Intel's mail system may support that?
Hello: This patch was applied to riscv/linux.git (for-next) by Palmer Dabbelt <palmer@rivosinc.com>: On Sun, 29 Jan 2023 23:57:01 +0000 you wrote: > From: Conor Dooley <conor.dooley@microchip.com> > > When adding the ISA string ordering rules, I didn't sufficiently indent > one of the list items. > > Reported-by: kernel test robot <lkp@intel.com> > Fixes: f07b2b3f9d47 ("Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo") > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > > [...] Here is the summary with links: - Documentation: riscv: fix insufficient list item indent https://git.kernel.org/riscv/c/2a5303b499b1 You are awesome, thank you!
diff --git a/Documentation/riscv/uabi.rst b/Documentation/riscv/uabi.rst index 2ebec4c52230..8960fac42c40 100644 --- a/Documentation/riscv/uabi.rst +++ b/Documentation/riscv/uabi.rst @@ -21,10 +21,10 @@ so for our purposes the following rules apply: single-letter extensions and before any higher-privileged extensions. #. For additional standard extensions, the first letter following the 'Z' - conventionally indicates the most closely related alphabetical - extension category. If multiple 'Z' extensions are named, they will be ordered - first by category, in canonical order, as listed above, then alphabetically - within a category. + conventionally indicates the most closely related alphabetical + extension category. If multiple 'Z' extensions are named, they will be + ordered first by category, in canonical order, as listed above, then + alphabetically within a category. #. Standard supervisor-level extensions (starting with 'S') will be listed after standard unprivileged extensions. If multiple supervisor-level