KEYS: keys-next-7.1-rc1

The following changes since commit faeab166167f5787719eb8683661fd41a3bb1514:

Merge tag 'pinctrl-v7.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl (2026-04-18 16:59:09 -0700)

are available in the Git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git tags/keys-next-7.1-rc1

for you to fetch changes up to 4fb4ce024d06a0b31ab6cdd17ab8cb6aff851067:

KEYS: trusted: Debugging as a feature (2026-04-19 15:17:03 +0300)

----------------------------------------------------------------
Hi

This pull request mainly sanitizes debug traces in trusted keys to proper kconfig flags, and makes the whole feature overall a bit safer by putting it under kernel command-line parameter and setting up a convention to only use debug level traces.

BR, Jarkko

----------------------------------------------------------------
Eric Biggers (1):
KEYS: encrypted: Remove unnecessary selection of CRYPTO_RNG

Jarkko Sakkinen (1):
KEYS: trusted: Debugging as a feature

 Documentation/admin-guide/kernel-parameters.txt | 16 +++++++++
 include/keys/trusted-type.h                     | 21 +++++++-----
 security/keys/Kconfig                           |  1 -
 security/keys/trusted-keys/Kconfig              | 23 +++++++++++++
 security/keys/trusted-keys/trusted_caam.c       |  7 ++--
 security/keys/trusted-keys/trusted_core.c       |  6 ++++
 security/keys/trusted-keys/trusted_tpm1.c       | 44 ++++++++++++++-----------
 7 files changed, 87 insertions(+), 31 deletions(-)

This too appears to have been rebased just minutes before sending the email

No.

That counts as "zero testing" when you don't even explain why it happened.

Linus

I tested both PRs for the same baseline with two separate buildroot builds of

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd-test.git

The only last minute changes after testing I can recall were updating stable cc tags for TPM patches.

For the last minute patches I applied from Jacqueline I've tested their earlier version, and the patches I applied were just addressing checkpatch.pl --strict issues.

Granted not very explained so I get where you're coming from. So how to move forward?

BR, Jarkko

You threw away any and all testing that had been done by anybody else in linux-next.

And you rebased things on top of a random commit-of-the-day during the merge window, when things are possibly unstable due to all the *other* churn going on.

In other words, you did *EVERYTHING* that you shouldn't be doing, and that the documentation tells you not to do.

The WHOLE POINT of being in linux-next and being ready when the merge window opens is gone. All for apparently nothing.

Those stable cc tags do not add *any* value, since you could just have cc'd stable later instead.

I'm not pulling this. You need to stop doing this pointless churn, and read the docs on rebasing. See

Documentation/maintainer/rebasing-and-merging.rst

about how you are *not* supposed to randomly just rebase, and _particularly_ not rebase on top of some random state during the merge window.

Linus

"A frequent cause of merge-window trouble is when Linus is presented with a patch series that has clearly been reparented, often to a random commit, shortly before the pull request was sent. The chances of such a series having been adequately tested are relatively low - as are the chances of the pull request being acted upon."

OK, point digested.

I can update 'next' to contain only fixes from these PRs, and hold on up til doing PR for -rc2 (as corrective step).

BR, Jarkko