Forum | Documentation | Website | Blog

Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Mar 29, 2024
  3. Mar 27, 2024
  5. Mar 26, 2024
  7. Mar 24, 2024
  9. Mar 21, 2024
  11. Mar 20, 2024
  13. Mar 17, 2024
  15. Mar 15, 2024
  17. Mar 13, 2024
  19. Mar 11, 2024
  21. Mar 10, 2024
  23. Mar 08, 2024
  25. Mar 07, 2024
  27. Mar 05, 2024
    • Arnd Bergmann's avatar
      ARM: s32c: update MAINTAINERS entry · 98dcb872
      Arnd Bergmann authored 
      
As discussed on the mailing list, Chester is stepping down from being
the primary maintainer for the s32c platform, and Ghennadi becomes an
additional reviewer.

For the moment, there is no full maintainer for s32c, but Shawn is already
listed as the overall maintainer for 32-bit freescale/nxp platforms
(except layerscape and qoriq) and agreed to merge s32c patches as they
come in and are reviewed by the remaining reviewers.

Adapt the entries in the maintainers file based on the discussion.

Reviewed-by: default avatarMatthias Brugger <mbrugger@suse.com>
Reviewed-by: default avatarGhennadi Procopciuc <ghennadi.procopciuc@oss.nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Chester Lin <chester62515@gmail.com>
Cc: Matthias Brugger <mbrugger@suse.com>
Cc: Ghennadi Procopciuc <ghennadi.procopciuc@oss.nxp.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: NXP S32 Linux Team <s32@nxp.com>
Link: https://lore.kernel.org/all/20240221120123.1118552-1-ghennadi.procopciuc@oss.nxp.com/
Link: https://lore.kernel.org/r/20240304204249.936140-1-arnd@kernel.org


Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      98dcb872
    • Kees Cook's avatar
      string: Convert helpers selftest to KUnit · fb57550f
      Kees Cook authored 
      Convert test-string_helpers.c to KUnit so it can be easily run with
everything else.

Failure reporting doesn't need to be open-coded in most places, for
example, forcing a failure in the expected output for upper/lower
testing looks like this:

[12:18:43] # test_upper_lower: EXPECTATION FAILED at lib/string_helpers_kunit.c:579
[12:18:43] Expected dst == strings_upper[i].out, but
[12:18:43]     dst == "ABCDEFGH1234567890TEST"
[12:18:43]     strings_upper[i].out == "ABCDEFGH1234567890TeST"
[12:18:43] [FAILED] test_upper_lower

Currently passes without problems:

$ ./tools/testing/kunit/kunit.py run string_helpers
...
[12:23:55] Starting KUnit Kernel (1/1)...
[12:23:55] ============================================================
[12:23:55] =============== string_helpers (3 subtests) ================
[12:23:55] [PASSED] test_get_size
[12:23:55] [PASSED] test_upper_lower
[12:23:55] [PASSED] test_unescape
[12:23:55] ================= [PASSED] string_helpers ==================
[12:23:55] ============================================================
[12:23:55] Testing complete. Ran 3 tests: passed: 3
[12:23:55] Elapsed time: 6.709s total, 0.001s configuring, 6.591s building, 0.066s running

Link: https://lore.kernel.org/r/20240301202732.2688342-2-keescook@chromium.org


Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      fb57550f
    • Kees Cook's avatar
      string: Convert selftest to KUnit · 29d85688
      Kees Cook authored 
      Convert test_string.c to KUnit so it can be easily run with everything
else.

Additional text context is retained for failure reporting. For example,
when forcing a bad match, we can see the loop counters reported for the
memset() tests:

[09:21:52]     # test_memset64: ASSERTION FAILED at lib/string_kunit.c:93
[09:21:52]     Expected v == 0xa2a1a1a1a1a1a1a1ULL, but
[09:21:52]         v == -6799976246779207263 (0xa1a1a1a1a1a1a1a1)
[09:21:52]         0xa2a1a1a1a1a1a1a1ULL == -6727918652741279327 (0xa2a1a1a1a1a1a1a1)
[09:21:52] i:0 j:0 k:0
[09:21:52] [FAILED] test_memset64

Currently passes without problems:

$ ./tools/testing/kunit/kunit.py run string
...
[09:37:40] Starting KUnit Kernel (1/1)...
[09:37:40] ============================================================
[09:37:40] =================== string (6 subtests) ====================
[09:37:40] [PASSED] test_memset16
[09:37:40] [PASSED] test_memset32
[09:37:40] [PASSED] test_memset64
[09:37:40] [PASSED] test_strchr
[09:37:40] [PASSED] test_strnchr
[09:37:40] [PASSED] test_strspn
[09:37:40] ===================== [PASSED] string ======================
[09:37:40] ============================================================
[09:37:40] Testing complete. Ran 6 tests: passed: 6
[09:37:40] Elapsed time: 6.730s total, 0.001s configuring, 6.562s building, 0.131s running

Link: https://lore.kernel.org/r/20240301202732.2688342-1-keescook@chromium.org


Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      29d85688
    • Tvrtko Ursulin's avatar
      MAINTAINERS: Update email address for Tvrtko Ursulin · 9b467b42
      Tvrtko Ursulin authored 
      
I will lose access to my @.*intel.com e-mail addresses soon so let me
adjust the maintainers entry and update the mailmap too.

While at it consolidate a few other of my old emails to point to the
main one.

Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: default avatarJani Nikula <jani.nikula@intel.com>
Acked-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20240228142240.2539358-1-tvrtko.ursulin@linux.intel.com
      9b467b42
  29. Mar 04, 2024
  31. Mar 03, 2024
    • Thorsten Leemhuis's avatar
      docs: new text on bisecting which also covers bug validation · 78129672
      Thorsten Leemhuis authored 
      
Add a second document on bisecting regressions explaining the whole
process from beginning to end -- while also describing how to validate
if a problem is still present in mainline.  This "two in one" approach
is possible, as checking whenever a bug is in mainline is one of the
first steps before performing a bisection anyway and thus needs to be
described. Due to this approach the text also works quite nicely in
conjunction with Documentation/admin-guide/reporting-issues.rst, as it
covers all typical cases where users will need to build a kernel in
exactly the same order.

The text targets users that normally run kernels from their Linux
distributor who might never have compiled their own kernel.

This aim is why the first kernel built while following this guide is
generated from the latest mainline codebase. This will rule out that the
regression (a) was fixed already and (b) is caused by config change a
vendor distributor performed; checking mainline will furthermore (c)
determine if the issue is something that needs to be reported to the
regular developers or the stable team (this is needed even when readers
bisect within a stable series).

Only then are readers instructed to build their own variant of the
'good' kernel to validate the trimmed .config file created during early
in the guide, as performing a bisection with a broken one would be a
waste of time. There is a small downside of this order: readers might
have to go back to testing mainline, if it turns out there is a problem
with their .config. But that should be rare -- and if the regression was
already fixed readers might not get to this point anyway. Hence in the
end this order should mean that readers built less kernels overall.

This sequence allows the text to easily cover the "check if a bug is
present in the upstream kernel" case while only making things a tiny bit
more complicated.

The text tries to prevent readers from running into many mistakes users
are known to frequently make. The steps required for this might look
superfluous for people that are already familiar with bisections -- but
anyone with that knowledge should be able to adapt the instructions to
their use-case or will not need this text at all.

Style and structure of the text match the one
Documentation/admin-guide/quickly-build-trimmed-linux.rst uses. Quite a
few paragraphs are even copied from there and not changed at all or only
slightly. This will complicate maintenance, as some future changes to
one of these documents will have to be replicated in the other. But this
is the lesser evil: solutions like "sending readers from one document
over to the other" or "extracting the common parts into a separate
document" might work in other cases, but would be too confusing here
given the topic and the target audience.

Signed-off-by: default avatarThorsten Leemhuis <linux@leemhuis.info>
[jc: Undo spurious removal of subsection header line]
Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
Message-ID: <02b084a06de4ad61ac4ecd92b9265d4df4d03d71.1709282441.git.linux@leemhuis.info>
      78129672
  33. Mar 01, 2024
  35. Feb 29, 2024
  37. Feb 28, 2024

Open hardware computers for makers, educators and professionals