Changes in xor

cdd5b5a9761fd66d17586e4f4ba6588c70e640ea - Merge branch 'next' into for-linus

Tue, 07 Nov 2023 00:42:08 +0100

Merge branch 'next' into for-linusPrepare input updates for 6.7 merge window. List of files: /linux/scripts/atomic/kerneldoc/xor

34069d12e239ae8f36dd96c378e4622fb1c42a76 - Merge tag 'v6.5' into next

Tue, 05 Sep 2023 23:08:14 +0200

Merge tag 'v6.5' into nextSync up with mainline to bring in updates to the shared infrastructure. List of files: /linux/scripts/atomic/kerneldoc/xor

2612e3bbc0386368a850140a6c9b990cd496a5ec - Merge drm/drm-next into drm-intel-next

Mon, 07 Aug 2023 23:14:42 +0200

Merge drm/drm-next into drm-intel-nextCatching-up with drm-next and drm-intel-gt-next.It will unblock a code refactor around the platformdefinitions (names vs acronyms).Signed-off-by: Rodrigo Vivi List of files: /linux/scripts/atomic/kerneldoc/xor

9f771739a04919226081a107167596de75108fbb - Merge drm/drm-next into drm-intel-gt-next

Mon, 07 Aug 2023 12:29:40 +0200

Merge drm/drm-next into drm-intel-gt-nextNeed to pull in b3e4aae612ec ("drm/i915/hdcp: Modify hdcp_gsc_message msg sending mechanism") asa dependency for https://patchwork.freedesktop.org/series/121735/Signed-off-by: Joonas Lahtinen List of files: /linux/scripts/atomic/kerneldoc/xor

61b7369483efb5e0a9f3b48e75fac00d46d661e0 - Merge drm/drm-next into drm-misc-next

Mon, 24 Jul 2023 15:44:47 +0200

Merge drm/drm-next into drm-misc-nextBackmerging to get v6.5-rc2.Signed-off-by: Thomas Zimmermann List of files: /linux/scripts/atomic/kerneldoc/xor

0791faebfe750292a8a842b64795a390ca4a3b51 - ASoC: Merge v6.5-rc2

Mon, 17 Jul 2023 07:12:31 +0200

ASoC: Merge v6.5-rc2Get a similar baseline to my other branches, and fixes for people usingthe branch. List of files: /linux/scripts/atomic/kerneldoc/xor

2f98e686ef59b5d19af5847d755798e2031bee3a - Merge v6.5-rc1 into drm-misc-fixes

Tue, 11 Jul 2023 09:23:20 +0200

Merge v6.5-rc1 into drm-misc-fixesBoris needs 6.5-rc1 in drm-misc-fixes to prevent a conflict.Signed-off-by: Maxime Ripard List of files: /linux/scripts/atomic/kerneldoc/xor

44f10dbefd5e41b3385af91f855a57aa2afaf40e - Merge branch 'master' into mm-hotfixes-stable

Fri, 30 Jun 2023 17:41:39 +0200

Merge branch 'master' into mm-hotfixes-stable List of files: /linux/scripts/atomic/kerneldoc/xor

bc6cb4d5bc3a44197de30784eae71d8ba28483eb - Merge tag 'locking-core-2023-06-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Tue, 27 Jun 2023 23:14:30 +0200

Merge tag 'locking-core-2023-06-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipPull locking updates from Ingo Molnar: - Introduce cmpxchg128() -- aka. the demise of cmpxchg_double() The cmpxchg128() family of functions is basically & functionally the same as cmpxchg_double(), but with a saner interface. Instead of a 6-parameter horror that forced u128 - u64/u64-halves layout details on the interface and exposed users to complexity, fragility & bugs, use a natural 3-parameter interface with u128 types. - Restructure the generated atomic headers, and add kerneldoc comments for all of the generic atomic{,64,_long}_t operations. The generated definitions are much cleaner now, and come with documentation. - Implement lock_set_cmp_fn() on lockdep, for defining an ordering when taking multiple locks of the same type. This gets rid of one use of lockdep_set_novalidate_class() in the bcache code. - Fix raw_cpu_generic_try_cmpxchg() bug due to an unintended variable shadowing generating garbage code on Clang on certain ARM builds.* tag 'locking-core-2023-06-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (43 commits) locking/atomic: scripts: fix ${atomic}_dec_if_positive() kerneldoc percpu: Fix self-assignment of __old in raw_cpu_generic_try_cmpxchg() locking/atomic: treewide: delete arch_atomic_*() kerneldoc locking/atomic: docs: Add atomic operations to the driver basic API documentation locking/atomic: scripts: generate kerneldoc comments docs: scripts: kernel-doc: accept bitwise negation like ~@var locking/atomic: scripts: simplify raw_atomic*() definitions locking/atomic: scripts: simplify raw_atomic_long*() definitions locking/atomic: scripts: split pfx/name/sfx/order locking/atomic: scripts: restructure fallback ifdeffery locking/atomic: scripts: build raw_atomic_long*() directly locking/atomic: treewide: use raw_atomic*_() locking/atomic: scripts: add trivial raw_atomic*_() locking/atomic: scripts: factor out order template generation locking/atomic: scripts: remove leftover "${mult}" locking/atomic: scripts: remove bogus order parameter locking/atomic: xtensa: add preprocessor symbols locking/atomic: x86: add preprocessor symbols locking/atomic: sparc: add preprocessor symbols locking/atomic: sh: add preprocessor symbols ... List of files: /linux/scripts/atomic/kerneldoc/xor

ad8110706f381170c9f9975f1cb06010fd3ca381 - locking/atomic: scripts: generate kerneldoc comments

Mon, 05 Jun 2023 09:01:22 +0200

locking/atomic: scripts: generate kerneldoc commentsCurrently the atomics are documented in Documentation/atomic_t.txt, andhave no kerneldoc comments. There are a sufficient number of gotchas(e.g. semantics, noinstr-safety) that it would be nice to have commentsto call these out, and it would be nice to have kerneldoc comments suchthat these can be collated.While it's possible to derive the semantics from the code, this can bepainful given the amount of indirection we currently have (e.g. fallbackpaths), and it's easy to be mislead by naming, e.g.* The unconditional void-returning ops *only* have relaxed variants without a _relaxed suffix, and can easily be mistaken for being fully ordered. It would be nice to give these a _relaxed() suffix, but this would result in significant churn throughout the kernel.* Our naming of conditional and unconditional+test ops is rather inconsistent, and it can be difficult to derive the name of an operation, or to identify where an op is conditional or unconditional+test. Some ops are clearly conditional: - dec_if_positive - add_unless - dec_unless_positive - inc_unless_negative Some ops are clearly unconditional+test: - sub_and_test - dec_and_test - inc_and_test However, what exactly those test is not obvious. A _test_zero suffix might be clearer. Others could be read ambiguously: - inc_not_zero // conditional - add_negative // unconditional+test It would probably be worth renaming these, e.g. to inc_unless_zero and add_test_negative.As a step towards making this more consistent and easier to understand,this patch adds kerneldoc comments for all generated *atomic*_*()functions. These are generated from templates, with some common textshared, making it easy to extend these in future if necessary.I've tried to make these as consistent and clear as possible, and I'vedeliberately ensured:* All ops have their ordering explicitly mentioned in the short and long description.* All test ops have "test" in their short description.* All ops are described as an expression using their usual C operator. For example: andnot: "Atomically updates @v to (@v & ~@i)" inc: "Atomically updates @v to (@v + 1)" Which may be clearer to non-naative English speakers, and allows all the operations to be described in the same style.* All conditional ops have their condition described as an expression using the usual C operators. For example: add_unless: "If (@v != @u), atomically updates @v to (@v + @i)" cmpxchg: "If (@v == @old), atomically updates @v to @new" Which may be clearer to non-naative English speakers, and allows all the operations to be described in the same style.* All bitwise ops (and,andnot,or,xor) explicitly mention that they are bitwise in their short description, so that they are not mistaken for performing their logical equivalents.* The noinstr safety of each op is explicitly described, with a description of whether or not to use the raw_ form of the op.There should be no functional change as a result of this patch.Reported-by: Paul E. McKenney Signed-off-by: Mark Rutland Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20230605070124.3741859-26-mark.rutland@arm.com List of files: /linux/scripts/atomic/kerneldoc/xor