There’s no issue with abstracting code into a helper function. If we want to optimize for cognitive load, the intent should be as clear as possible, starting with the name.
In some languages (with named arguments) you could write this as:
make_u32(msw: 0xABCD, lsw: 0xEFEF)
That similarly reduces the ambiguity and enhances readability.
But I think the other thing not discussed here was the principle of "telling one story" with a given patch set. Introducing a new way to combine 16-bit words is "one story", and it belongs in a patch set that continues the story by applying this new abstraction across the code base. Then you can read it in context and judge whether it makes the code easier to read, more fool proof, etc.
"Bug fixes for the RISC-V platform" is an entirely different "story" and shouldn't be commingled in one patch set. It might *depend* on the earlier patch, but its not the same story.
Would you send this new less ambiguous abstraction to Mr. Torvalds? If no, then the problem is not the ambiguity ;)
In some languages (with named arguments) you could write this as:
make_u32(msw: 0xABCD, lsw: 0xEFEF)
That similarly reduces the ambiguity and enhances readability.
But I think the other thing not discussed here was the principle of "telling one story" with a given patch set. Introducing a new way to combine 16-bit words is "one story", and it belongs in a patch set that continues the story by applying this new abstraction across the code base. Then you can read it in context and judge whether it makes the code easier to read, more fool proof, etc.
"Bug fixes for the RISC-V platform" is an entirely different "story" and shouldn't be commingled in one patch set. It might *depend* on the earlier patch, but its not the same story.