* Re: [PATCH] docs: netlink: Correct buffer sizing info
From: patchwork-bot+netdevbpf @ 2026-05-15 23:10 UTC (permalink / raw)
To: Konstantin Shabanov
Cc: linux-doc, davem, edumazet, kuba, pabeni, horms, corbet, skhan,
netdev, linux-kernel
In-Reply-To: <20260512103101.1076173-1-mail@etehtsea.me>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 12 May 2026 17:30:53 +0700 you wrote:
> Update the docs to match the code (include/linux/netlink.h):
>
> /*
> * skb should fit one page. This choice is good for headerless malloc.
> * But we should limit to 8K so that userspace does not have to
> * use enormous buffer sizes on recvmsg() calls just to avoid
> * MSG_TRUNC when PAGE_SIZE is very large.
> */
> #if PAGE_SIZE < 8192UL
> #define NLMSG_GOODSIZE SKB_WITH_OVERHEAD(PAGE_SIZE)
> #else
> #define NLMSG_GOODSIZE SKB_WITH_OVERHEAD(8192UL)
> #endif
>
> [...]
Here is the summary with links:
- docs: netlink: Correct buffer sizing info
https://git.kernel.org/netdev/net-next/c/55834f0d7421
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v16 01/38] tpm: Initial step to reorganize TPM public headers
From: Dave Hansen @ 2026-05-15 23:10 UTC (permalink / raw)
To: Jason Gunthorpe, Jarkko Sakkinen
Cc: Ross Philipson, linux-kernel, x86, linux-integrity, linux-doc,
linux-crypto, kexec, linux-efi, iommu, dpsmith, tglx, mingo, bp,
hpa, dave.hansen, ardb, mjg59, James.Bottomley, peterhuewe, luto,
nivedita, herbert, davem, corbet, ebiederm, dwmw2, baolu.lu,
kanth.ghatraju, daniel.kiper, andrew.cooper3, trenchboot-devel
In-Reply-To: <20260515230553.GO7702@ziepe.ca>
On 5/15/26 16:05, Jason Gunthorpe wrote:
> Can we please split out and progress the TPM reorg mini-series at the
> front?
Yes, please.
Any way to break this down and merge in more bite-size pieces would be
better for everyone involved.
^ permalink raw reply
* Re: [PATCH v16 02/38] tpm: Move TPM1 specific definitions to the command header
From: Jarkko Sakkinen @ 2026-05-15 23:14 UTC (permalink / raw)
To: Ross Philipson
Cc: linux-kernel, x86, linux-integrity, linux-doc, linux-crypto,
kexec, linux-efi, iommu, dpsmith, tglx, mingo, bp, hpa,
dave.hansen, ardb, mjg59, James.Bottomley, peterhuewe, jgg, luto,
nivedita, herbert, davem, corbet, ebiederm, dwmw2, baolu.lu,
kanth.ghatraju, daniel.kiper, andrew.cooper3, trenchboot-devel
In-Reply-To: <20260515211410.31440-3-ross.philipson@gmail.com>
On Fri, May 15, 2026 at 02:13:34PM -0700, Ross Philipson wrote:
> Gather all the TPM1 definitions and structures in the internal header
> file drivers/char/tpm/tpm.h into the command header. In addition, bring
> in the single RNG structure from tpm-interface.c.
>
> The definitions moved to these files correspond to the TCG specification
> for TPM 1 family:
>
> TPM 1.2 Main Specification
> - https://trustedcomputinggroup.org/resource/tpm-main-specification/
>
> Co-developed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> Co-developed-by: Alec Brown <alec.r.brown@oracle.com>
> Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
> Signed-off-by: Ross Philipson <ross.philipson@gmail.com>
> ---
> drivers/char/tpm/tpm.h | 102 --------------------------------
> drivers/char/tpm/tpm1-cmd.c | 5 --
> include/linux/tpm_command.h | 115 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 115 insertions(+), 107 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index 87d68ddf270a..043d78a9617a 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -52,105 +52,9 @@ enum tpm_addr {
> TPM_ADDR = 0x4E,
> };
>
> -#define TPM_WARN_RETRY 0x800
> -#define TPM_WARN_DOING_SELFTEST 0x802
> -#define TPM_ERR_DEACTIVATED 0x6
> -#define TPM_ERR_DISABLED 0x7
> -#define TPM_ERR_FAILEDSELFTEST 0x1C
> -#define TPM_ERR_INVALID_POSTINIT 38
> -
> -#define TPM_TAG_RQU_COMMAND 193
> -
> /* TPM2 specific constants. */
> #define TPM2_SPACE_BUFFER_SIZE 16384 /* 16 kB */
>
> -struct stclear_flags_t {
> - __be16 tag;
> - u8 deactivated;
> - u8 disableForceClear;
> - u8 physicalPresence;
> - u8 physicalPresenceLock;
> - u8 bGlobalLock;
> -} __packed;
> -
> -struct tpm1_version {
> - u8 major;
> - u8 minor;
> - u8 rev_major;
> - u8 rev_minor;
> -} __packed;
> -
> -struct tpm1_version2 {
> - __be16 tag;
> - struct tpm1_version version;
> -} __packed;
> -
> -struct timeout_t {
> - __be32 a;
> - __be32 b;
> - __be32 c;
> - __be32 d;
> -} __packed;
> -
> -struct duration_t {
> - __be32 tpm_short;
> - __be32 tpm_medium;
> - __be32 tpm_long;
> -} __packed;
> -
> -struct permanent_flags_t {
> - __be16 tag;
> - u8 disable;
> - u8 ownership;
> - u8 deactivated;
> - u8 readPubek;
> - u8 disableOwnerClear;
> - u8 allowMaintenance;
> - u8 physicalPresenceLifetimeLock;
> - u8 physicalPresenceHWEnable;
> - u8 physicalPresenceCMDEnable;
> - u8 CEKPUsed;
> - u8 TPMpost;
> - u8 TPMpostLock;
> - u8 FIPS;
> - u8 operator;
> - u8 enableRevokeEK;
> - u8 nvLocked;
> - u8 readSRKPub;
> - u8 tpmEstablished;
> - u8 maintenanceDone;
> - u8 disableFullDALogicInfo;
> -} __packed;
> -
> -typedef union {
> - struct permanent_flags_t perm_flags;
> - struct stclear_flags_t stclear_flags;
> - __u8 owned;
> - __be32 num_pcrs;
> - struct tpm1_version version1;
> - struct tpm1_version2 version2;
> - __be32 manufacturer_id;
> - struct timeout_t timeout;
> - struct duration_t duration;
> -} cap_t;
> -
> -enum tpm_capabilities {
> - TPM_CAP_FLAG = 4,
> - TPM_CAP_PROP = 5,
> - TPM_CAP_VERSION_1_1 = 0x06,
> - TPM_CAP_VERSION_1_2 = 0x1A,
> -};
> -
> -enum tpm_sub_capabilities {
> - TPM_CAP_PROP_PCR = 0x101,
> - TPM_CAP_PROP_MANUFACTURER = 0x103,
> - TPM_CAP_FLAG_PERM = 0x108,
> - TPM_CAP_FLAG_VOL = 0x109,
> - TPM_CAP_PROP_OWNER = 0x111,
> - TPM_CAP_PROP_TIS_TIMEOUT = 0x115,
> - TPM_CAP_PROP_TIS_DURATION = 0x120,
> -};
> -
> enum tpm2_pt_props {
> TPM2_PT_NONE = 0x00000000,
> TPM2_PT_GROUP = 0x00000100,
> @@ -225,12 +129,6 @@ enum tpm2_pt_props {
> TPM2_PT_AUDIT_COUNTER_1 = TPM2_PT_VAR + 20,
> };
>
> -/* 128 bytes is an arbitrary cap. This could be as large as TPM_BUFSIZE - 18
> - * bytes, but 128 is still a relatively large number of random bytes and
> - * anything much bigger causes users of struct tpm_cmd_t to start getting
> - * compiler warnings about stack frame size. */
> -#define TPM_MAX_RNG_DATA 128
> -
> extern const struct class tpm_class;
> extern const struct class tpmrm_class;
> extern dev_t tpm_devt;
> diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
> index 664ca1fff2e8..96f189b5fd6f 100644
> --- a/drivers/char/tpm/tpm1-cmd.c
> +++ b/drivers/char/tpm/tpm1-cmd.c
> @@ -504,11 +504,6 @@ ssize_t tpm1_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
> }
> EXPORT_SYMBOL_GPL(tpm1_getcap);
>
> -struct tpm1_get_random_out {
> - __be32 rng_data_len;
> - u8 rng_data[TPM_MAX_RNG_DATA];
> -} __packed;
> -
> /**
> * tpm1_get_random() - get random bytes from the TPM's RNG
> * @chip: a &struct tpm_chip instance
> diff --git a/include/linux/tpm_command.h b/include/linux/tpm_command.h
> index 174b043d8bbc..30d01953a6f8 100644
> --- a/include/linux/tpm_command.h
> +++ b/include/linux/tpm_command.h
> @@ -36,6 +36,121 @@ enum tpm_command_ordinals {
> TPM_ORD_UNSEAL = 24,
> };
>
> +enum tpm_capabilities {
> + TPM_CAP_FLAG = 4,
> + TPM_CAP_PROP = 5,
> + TPM_CAP_VERSION_1_1 = 0x06,
> + TPM_CAP_VERSION_1_2 = 0x1A,
> +};
> +
> +enum tpm_sub_capabilities {
> + TPM_CAP_PROP_PCR = 0x101,
> + TPM_CAP_PROP_MANUFACTURER = 0x103,
> + TPM_CAP_FLAG_PERM = 0x108,
> + TPM_CAP_FLAG_VOL = 0x109,
> + TPM_CAP_PROP_OWNER = 0x111,
> + TPM_CAP_PROP_TIS_TIMEOUT = 0x115,
> + TPM_CAP_PROP_TIS_DURATION = 0x120,
> +};
> +
> +/* Return Codes */
> +enum tpm_return_codes {
> + TPM_BASE_MASK = 0,
> + TPM_NON_FATAL_MASK = 0x00000800,
> + TPM_SUCCESS = TPM_BASE_MASK + 0,
> + TPM_ERR_DEACTIVATED = TPM_BASE_MASK + 6,
> + TPM_ERR_DISABLED = TPM_BASE_MASK + 7,
> + TPM_ERR_FAIL = TPM_BASE_MASK + 9,
> + TPM_ERR_FAILEDSELFTEST = TPM_BASE_MASK + 28,
> + TPM_ERR_INVALID_POSTINIT = TPM_BASE_MASK + 38,
> + TPM_ERR_INVALID_FAMILY = TPM_BASE_MASK + 55,
> + TPM_WARN_RETRY = TPM_BASE_MASK + TPM_NON_FATAL_MASK + 0,
> + TPM_WARN_DOING_SELFTEST = TPM_BASE_MASK + TPM_NON_FATAL_MASK + 2,
> +};
> +
> +struct stclear_flags_t {
> + __be16 tag;
> + u8 deactivated;
> + u8 disableForceClear;
> + u8 physicalPresence;
> + u8 physicalPresenceLock;
> + u8 bGlobalLock;
> +} __packed;
> +
> +struct tpm1_version {
> + u8 major;
> + u8 minor;
> + u8 rev_major;
> + u8 rev_minor;
> +} __packed;
> +
> +struct tpm1_version2 {
> + __be16 tag;
> + struct tpm1_version version;
> +} __packed;
> +
> +struct timeout_t {
> + __be32 a;
> + __be32 b;
> + __be32 c;
> + __be32 d;
> +} __packed;
> +
> +struct duration_t {
> + __be32 tpm_short;
> + __be32 tpm_medium;
> + __be32 tpm_long;
> +} __packed;
> +
> +struct permanent_flags_t {
> + __be16 tag;
> + u8 disable;
> + u8 ownership;
> + u8 deactivated;
> + u8 readPubek;
> + u8 disableOwnerClear;
> + u8 allowMaintenance;
> + u8 physicalPresenceLifetimeLock;
> + u8 physicalPresenceHWEnable;
> + u8 physicalPresenceCMDEnable;
> + u8 CEKPUsed;
> + u8 TPMpost;
> + u8 TPMpostLock;
> + u8 FIPS;
> + u8 operator;
> + u8 enableRevokeEK;
> + u8 nvLocked;
> + u8 readSRKPub;
> + u8 tpmEstablished;
> + u8 maintenanceDone;
> + u8 disableFullDALogicInfo;
> +} __packed;
> +
> +typedef union {
> + struct permanent_flags_t perm_flags;
> + struct stclear_flags_t stclear_flags;
> + __u8 owned;
> + __be32 num_pcrs;
> + struct tpm1_version version1;
> + struct tpm1_version2 version2;
> + __be32 manufacturer_id;
> + struct timeout_t timeout;
> + struct duration_t duration;
> +} cap_t;
> +
> +/*
> + * 128 bytes is an arbitrary cap. This could be as large as TPM_BUFSIZE - 18
> + * bytes, but 128 is still a relatively large number of random bytes and
> + * anything much bigger causes users of struct tpm_cmd_t to start getting
> + * compiler warnings about stack frame size.
> + */
> +#define TPM_MAX_RNG_DATA 128
> +
> +struct tpm1_get_random_out {
> + __be32 rng_data_len;
> + u8 rng_data[TPM_MAX_RNG_DATA];
> +} __packed;
> +
> /* Other constants */
> #define SRKHANDLE 0x40000000
> #define TPM_NONCE_SIZE 20
> --
> 2.47.3
>
LGTM
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v16 03/38] tpm: Move TPM2 specific definitions to the command header
From: Jarkko Sakkinen @ 2026-05-15 23:15 UTC (permalink / raw)
To: Ross Philipson
Cc: linux-kernel, x86, linux-integrity, linux-doc, linux-crypto,
kexec, linux-efi, iommu, dpsmith, tglx, mingo, bp, hpa,
dave.hansen, ardb, mjg59, James.Bottomley, peterhuewe, jgg, luto,
nivedita, herbert, davem, corbet, ebiederm, dwmw2, baolu.lu,
kanth.ghatraju, daniel.kiper, andrew.cooper3, trenchboot-devel
In-Reply-To: <20260515211410.31440-4-ross.philipson@gmail.com>
On Fri, May 15, 2026 at 02:13:35PM -0700, Ross Philipson wrote:
> Gather all the TPM2 definitions and structures in the internal header
> file drivers/char/tpm/tpm.h into the command header, including:
> - Command codes, return codes and definitions from the public and
> internal tpm.h files.
> - Structures defined in numerous TPM driver C modules.
>
> The definitions moved to these files correspond to the TCG specification
> for TPM 2 family:
>
> TPM 2.0 Library
> - https://trustedcomputinggroup.org/resource/tpm-library-specification/
>
> Co-developed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> Co-developed-by: Alec Brown <alec.r.brown@oracle.com>
> Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
> Signed-off-by: Ross Philipson <ross.philipson@gmail.com>
> ---
> drivers/char/tpm/tpm.h | 77 ----------
> drivers/char/tpm/tpm2-cmd.c | 30 ----
> drivers/char/tpm/tpm2-space.c | 13 --
> include/linux/tpm.h | 145 ------------------
> include/linux/tpm_command.h | 271 ++++++++++++++++++++++++++++++++++
> 5 files changed, 271 insertions(+), 265 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index 043d78a9617a..680f89d9c9f9 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -52,83 +52,6 @@ enum tpm_addr {
> TPM_ADDR = 0x4E,
> };
>
> -/* TPM2 specific constants. */
> -#define TPM2_SPACE_BUFFER_SIZE 16384 /* 16 kB */
> -
> -enum tpm2_pt_props {
> - TPM2_PT_NONE = 0x00000000,
> - TPM2_PT_GROUP = 0x00000100,
> - TPM2_PT_FIXED = TPM2_PT_GROUP * 1,
> - TPM2_PT_FAMILY_INDICATOR = TPM2_PT_FIXED + 0,
> - TPM2_PT_LEVEL = TPM2_PT_FIXED + 1,
> - TPM2_PT_REVISION = TPM2_PT_FIXED + 2,
> - TPM2_PT_DAY_OF_YEAR = TPM2_PT_FIXED + 3,
> - TPM2_PT_YEAR = TPM2_PT_FIXED + 4,
> - TPM2_PT_MANUFACTURER = TPM2_PT_FIXED + 5,
> - TPM2_PT_VENDOR_STRING_1 = TPM2_PT_FIXED + 6,
> - TPM2_PT_VENDOR_STRING_2 = TPM2_PT_FIXED + 7,
> - TPM2_PT_VENDOR_STRING_3 = TPM2_PT_FIXED + 8,
> - TPM2_PT_VENDOR_STRING_4 = TPM2_PT_FIXED + 9,
> - TPM2_PT_VENDOR_TPM_TYPE = TPM2_PT_FIXED + 10,
> - TPM2_PT_FIRMWARE_VERSION_1 = TPM2_PT_FIXED + 11,
> - TPM2_PT_FIRMWARE_VERSION_2 = TPM2_PT_FIXED + 12,
> - TPM2_PT_INPUT_BUFFER = TPM2_PT_FIXED + 13,
> - TPM2_PT_HR_TRANSIENT_MIN = TPM2_PT_FIXED + 14,
> - TPM2_PT_HR_PERSISTENT_MIN = TPM2_PT_FIXED + 15,
> - TPM2_PT_HR_LOADED_MIN = TPM2_PT_FIXED + 16,
> - TPM2_PT_ACTIVE_SESSIONS_MAX = TPM2_PT_FIXED + 17,
> - TPM2_PT_PCR_COUNT = TPM2_PT_FIXED + 18,
> - TPM2_PT_PCR_SELECT_MIN = TPM2_PT_FIXED + 19,
> - TPM2_PT_CONTEXT_GAP_MAX = TPM2_PT_FIXED + 20,
> - TPM2_PT_NV_COUNTERS_MAX = TPM2_PT_FIXED + 22,
> - TPM2_PT_NV_INDEX_MAX = TPM2_PT_FIXED + 23,
> - TPM2_PT_MEMORY = TPM2_PT_FIXED + 24,
> - TPM2_PT_CLOCK_UPDATE = TPM2_PT_FIXED + 25,
> - TPM2_PT_CONTEXT_HASH = TPM2_PT_FIXED + 26,
> - TPM2_PT_CONTEXT_SYM = TPM2_PT_FIXED + 27,
> - TPM2_PT_CONTEXT_SYM_SIZE = TPM2_PT_FIXED + 28,
> - TPM2_PT_ORDERLY_COUNT = TPM2_PT_FIXED + 29,
> - TPM2_PT_MAX_COMMAND_SIZE = TPM2_PT_FIXED + 30,
> - TPM2_PT_MAX_RESPONSE_SIZE = TPM2_PT_FIXED + 31,
> - TPM2_PT_MAX_DIGEST = TPM2_PT_FIXED + 32,
> - TPM2_PT_MAX_OBJECT_CONTEXT = TPM2_PT_FIXED + 33,
> - TPM2_PT_MAX_SESSION_CONTEXT = TPM2_PT_FIXED + 34,
> - TPM2_PT_PS_FAMILY_INDICATOR = TPM2_PT_FIXED + 35,
> - TPM2_PT_PS_LEVEL = TPM2_PT_FIXED + 36,
> - TPM2_PT_PS_REVISION = TPM2_PT_FIXED + 37,
> - TPM2_PT_PS_DAY_OF_YEAR = TPM2_PT_FIXED + 38,
> - TPM2_PT_PS_YEAR = TPM2_PT_FIXED + 39,
> - TPM2_PT_SPLIT_MAX = TPM2_PT_FIXED + 40,
> - TPM2_PT_TOTAL_COMMANDS = TPM2_PT_FIXED + 41,
> - TPM2_PT_LIBRARY_COMMANDS = TPM2_PT_FIXED + 42,
> - TPM2_PT_VENDOR_COMMANDS = TPM2_PT_FIXED + 43,
> - TPM2_PT_NV_BUFFER_MAX = TPM2_PT_FIXED + 44,
> - TPM2_PT_MODES = TPM2_PT_FIXED + 45,
> - TPM2_PT_MAX_CAP_BUFFER = TPM2_PT_FIXED + 46,
> - TPM2_PT_VAR = TPM2_PT_GROUP * 2,
> - TPM2_PT_PERMANENT = TPM2_PT_VAR + 0,
> - TPM2_PT_STARTUP_CLEAR = TPM2_PT_VAR + 1,
> - TPM2_PT_HR_NV_INDEX = TPM2_PT_VAR + 2,
> - TPM2_PT_HR_LOADED = TPM2_PT_VAR + 3,
> - TPM2_PT_HR_LOADED_AVAIL = TPM2_PT_VAR + 4,
> - TPM2_PT_HR_ACTIVE = TPM2_PT_VAR + 5,
> - TPM2_PT_HR_ACTIVE_AVAIL = TPM2_PT_VAR + 6,
> - TPM2_PT_HR_TRANSIENT_AVAIL = TPM2_PT_VAR + 7,
> - TPM2_PT_HR_PERSISTENT = TPM2_PT_VAR + 8,
> - TPM2_PT_HR_PERSISTENT_AVAIL = TPM2_PT_VAR + 9,
> - TPM2_PT_NV_COUNTERS = TPM2_PT_VAR + 10,
> - TPM2_PT_NV_COUNTERS_AVAIL = TPM2_PT_VAR + 11,
> - TPM2_PT_ALGORITHM_SET = TPM2_PT_VAR + 12,
> - TPM2_PT_LOADED_CURVES = TPM2_PT_VAR + 13,
> - TPM2_PT_LOCKOUT_COUNTER = TPM2_PT_VAR + 14,
> - TPM2_PT_MAX_AUTH_FAIL = TPM2_PT_VAR + 15,
> - TPM2_PT_LOCKOUT_INTERVAL = TPM2_PT_VAR + 16,
> - TPM2_PT_LOCKOUT_RECOVERY = TPM2_PT_VAR + 17,
> - TPM2_PT_NV_WRITE_RECOVERY = TPM2_PT_VAR + 18,
> - TPM2_PT_AUDIT_COUNTER_0 = TPM2_PT_VAR + 19,
> - TPM2_PT_AUDIT_COUNTER_1 = TPM2_PT_VAR + 20,
> -};
> -
> extern const struct class tpm_class;
> extern const struct class tpmrm_class;
> extern dev_t tpm_devt;
> diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
> index 3a77be7ebf4a..1fa3e8a43c79 100644
> --- a/drivers/char/tpm/tpm2-cmd.c
> +++ b/drivers/char/tpm/tpm2-cmd.c
> @@ -94,17 +94,6 @@ unsigned long tpm2_calc_ordinal_duration(u32 ordinal)
> return msecs_to_jiffies(TPM2_DURATION_DEFAULT);
> }
>
> -struct tpm2_pcr_read_out {
> - __be32 update_cnt;
> - __be32 pcr_selects_cnt;
> - __be16 hash_alg;
> - u8 pcr_select_size;
> - u8 pcr_select[TPM2_PCR_SELECT_MIN];
> - __be32 digests_cnt;
> - __be16 digest_size;
> - u8 digest[];
> -} __packed;
> -
> /**
> * tpm2_pcr_read() - read a PCR value
> * @chip: TPM chip to use.
> @@ -238,11 +227,6 @@ int tpm2_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
> return rc;
> }
>
> -struct tpm2_get_random_out {
> - __be16 size;
> - u8 buffer[TPM_MAX_RNG_DATA];
> -} __packed;
> -
> /**
> * tpm2_get_random() - get random bytes from the TPM RNG
> *
> @@ -366,14 +350,6 @@ void tpm2_flush_context(struct tpm_chip *chip, u32 handle)
> }
> EXPORT_SYMBOL_GPL(tpm2_flush_context);
>
> -struct tpm2_get_cap_out {
> - u8 more_data;
> - __be32 subcap_id;
> - __be32 property_cnt;
> - __be32 property_id;
> - __be32 value;
> -} __packed;
> -
> /**
> * tpm2_get_tpm_pt() - get value of a TPM_CAP_TPM_PROPERTIES type property
> * @chip: a &tpm_chip instance
> @@ -541,12 +517,6 @@ static int tpm2_init_bank_info(struct tpm_chip *chip, u32 bank_index)
> return tpm2_pcr_read(chip, 0, &digest, &bank->digest_size);
> }
>
> -struct tpm2_pcr_selection {
> - __be16 hash_alg;
> - u8 size_of_select;
> - u8 pcr_select[3];
> -} __packed;
> -
> ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip)
> {
> struct tpm2_pcr_selection pcr_selection;
> diff --git a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2-space.c
> index 60354cd53b5c..7c1c0a174a2b 100644
> --- a/drivers/char/tpm/tpm2-space.c
> +++ b/drivers/char/tpm/tpm2-space.c
> @@ -15,19 +15,6 @@
> #include <linux/unaligned.h>
> #include "tpm.h"
>
> -enum tpm2_handle_types {
> - TPM2_HT_HMAC_SESSION = 0x02000000,
> - TPM2_HT_POLICY_SESSION = 0x03000000,
> - TPM2_HT_TRANSIENT = 0x80000000,
> -};
> -
> -struct tpm2_context {
> - __be64 sequence;
> - __be32 saved_handle;
> - __be32 hierarchy;
> - __be16 blob_size;
> -} __packed;
> -
> static void tpm2_flush_sessions(struct tpm_chip *chip, struct tpm_space *space)
> {
> int i;
> diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> index 1846d5485a2c..8551b24c2bff 100644
> --- a/include/linux/tpm.h
> +++ b/include/linux/tpm.h
> @@ -38,12 +38,6 @@ struct trusted_key_options;
> /* opaque structure, holds auth session parameters like the session key */
> struct tpm2_auth;
>
> -enum tpm2_session_types {
> - TPM2_SE_HMAC = 0x00,
> - TPM2_SE_POLICY = 0x01,
> - TPM2_SE_TRIAL = 0x02,
> -};
> -
> /* if you add a new hash to this, increment TPM_MAX_HASHES below */
> enum tpm_algorithms {
> TPM_ALG_ERROR = 0x0000,
> @@ -65,11 +59,6 @@ enum tpm_algorithms {
> */
> #define TPM_MAX_HASHES 5
>
> -enum tpm2_curves {
> - TPM2_ECC_NONE = 0x0000,
> - TPM2_ECC_NIST_P256 = 0x0003,
> -};
> -
> struct tpm_digest {
> u16 alg_id;
> u8 digest[TPM2_MAX_DIGEST_SIZE];
> @@ -222,122 +211,11 @@ struct tpm_chip {
>
> #define TPM_HEADER_SIZE 10
>
> -enum tpm2_const {
> - TPM2_PLATFORM_PCR = 24,
> - TPM2_PCR_SELECT_MIN = ((TPM2_PLATFORM_PCR + 7) / 8),
> -};
> -
> -enum tpm2_timeouts {
> - TPM2_TIMEOUT_A = 750,
> - TPM2_TIMEOUT_B = 4000,
> - TPM2_TIMEOUT_C = 200,
> - TPM2_TIMEOUT_D = 30,
> -};
> -
> -enum tpm2_durations {
> - TPM2_DURATION_SHORT = 20,
> - TPM2_DURATION_LONG = 2000,
> - TPM2_DURATION_DEFAULT = 120000,
> -};
> -
> -enum tpm2_structures {
> - TPM2_ST_NO_SESSIONS = 0x8001,
> - TPM2_ST_SESSIONS = 0x8002,
> - TPM2_ST_CREATION = 0x8021,
> -};
> -
> -/* Indicates from what layer of the software stack the error comes from */
> -#define TSS2_RC_LAYER_SHIFT 16
> -#define TSS2_RESMGR_TPM_RC_LAYER (11 << TSS2_RC_LAYER_SHIFT)
> -
> -enum tpm2_return_codes {
> - TPM2_RC_SUCCESS = 0x0000,
> - TPM2_RC_HASH = 0x0083, /* RC_FMT1 */
> - TPM2_RC_HANDLE = 0x008B,
> - TPM2_RC_INTEGRITY = 0x009F,
> - TPM2_RC_INITIALIZE = 0x0100, /* RC_VER1 */
> - TPM2_RC_FAILURE = 0x0101,
> - TPM2_RC_DISABLED = 0x0120,
> - TPM2_RC_UPGRADE = 0x012D,
> - TPM2_RC_COMMAND_CODE = 0x0143,
> - TPM2_RC_TESTING = 0x090A, /* RC_WARN */
> - TPM2_RC_REFERENCE_H0 = 0x0910,
> - TPM2_RC_RETRY = 0x0922,
> - TPM2_RC_SESSION_MEMORY = 0x0903,
> -};
> -
> -enum tpm2_command_codes {
> - TPM2_CC_FIRST = 0x011F,
> - TPM2_CC_HIERARCHY_CONTROL = 0x0121,
> - TPM2_CC_HIERARCHY_CHANGE_AUTH = 0x0129,
> - TPM2_CC_CREATE_PRIMARY = 0x0131,
> - TPM2_CC_SEQUENCE_COMPLETE = 0x013E,
> - TPM2_CC_SELF_TEST = 0x0143,
> - TPM2_CC_STARTUP = 0x0144,
> - TPM2_CC_SHUTDOWN = 0x0145,
> - TPM2_CC_NV_READ = 0x014E,
> - TPM2_CC_CREATE = 0x0153,
> - TPM2_CC_LOAD = 0x0157,
> - TPM2_CC_SEQUENCE_UPDATE = 0x015C,
> - TPM2_CC_UNSEAL = 0x015E,
> - TPM2_CC_CONTEXT_LOAD = 0x0161,
> - TPM2_CC_CONTEXT_SAVE = 0x0162,
> - TPM2_CC_FLUSH_CONTEXT = 0x0165,
> - TPM2_CC_READ_PUBLIC = 0x0173,
> - TPM2_CC_START_AUTH_SESS = 0x0176,
> - TPM2_CC_VERIFY_SIGNATURE = 0x0177,
> - TPM2_CC_GET_CAPABILITY = 0x017A,
> - TPM2_CC_GET_RANDOM = 0x017B,
> - TPM2_CC_PCR_READ = 0x017E,
> - TPM2_CC_PCR_EXTEND = 0x0182,
> - TPM2_CC_EVENT_SEQUENCE_COMPLETE = 0x0185,
> - TPM2_CC_HASH_SEQUENCE_START = 0x0186,
> - TPM2_CC_CREATE_LOADED = 0x0191,
> - TPM2_CC_LAST = 0x0193, /* Spec 1.36 */
> -};
> -
> -enum tpm2_permanent_handles {
> - TPM2_RH_NULL = 0x40000007,
> - TPM2_RS_PW = 0x40000009,
> -};
> -
> -/* Most Significant Octet for key types */
> -enum tpm2_mso_type {
> - TPM2_MSO_NVRAM = 0x01,
> - TPM2_MSO_SESSION = 0x02,
> - TPM2_MSO_POLICY = 0x03,
> - TPM2_MSO_PERMANENT = 0x40,
> - TPM2_MSO_VOLATILE = 0x80,
> - TPM2_MSO_PERSISTENT = 0x81,
> -};
> -
> static inline enum tpm2_mso_type tpm2_handle_mso(u32 handle)
> {
> return handle >> 24;
> }
>
> -enum tpm2_capabilities {
> - TPM2_CAP_HANDLES = 1,
> - TPM2_CAP_COMMANDS = 2,
> - TPM2_CAP_PCRS = 5,
> - TPM2_CAP_TPM_PROPERTIES = 6,
> -};
> -
> -enum tpm2_properties {
> - TPM_PT_TOTAL_COMMANDS = 0x0129,
> -};
> -
> -enum tpm2_startup_types {
> - TPM2_SU_CLEAR = 0x0000,
> - TPM2_SU_STATE = 0x0001,
> -};
> -
> -enum tpm2_cc_attrs {
> - TPM2_CC_ATTR_CHANDLES = 25,
> - TPM2_CC_ATTR_RHANDLE = 28,
> - TPM2_CC_ATTR_VENDOR = 29,
> -};
> -
> #define TPM_VID_INTEL 0x8086
> #define TPM_VID_WINBOND 0x1050
> #define TPM_VID_STM 0x104A
> @@ -389,29 +267,6 @@ struct tpm_buf {
> u8 handles;
> };
>
> -enum tpm2_object_attributes {
> - TPM2_OA_FIXED_TPM = BIT(1),
> - TPM2_OA_ST_CLEAR = BIT(2),
> - TPM2_OA_FIXED_PARENT = BIT(4),
> - TPM2_OA_SENSITIVE_DATA_ORIGIN = BIT(5),
> - TPM2_OA_USER_WITH_AUTH = BIT(6),
> - TPM2_OA_ADMIN_WITH_POLICY = BIT(7),
> - TPM2_OA_NO_DA = BIT(10),
> - TPM2_OA_ENCRYPTED_DUPLICATION = BIT(11),
> - TPM2_OA_RESTRICTED = BIT(16),
> - TPM2_OA_DECRYPT = BIT(17),
> - TPM2_OA_SIGN = BIT(18),
> -};
> -
> -enum tpm2_session_attributes {
> - TPM2_SA_CONTINUE_SESSION = BIT(0),
> - TPM2_SA_AUDIT_EXCLUSIVE = BIT(1),
> - TPM2_SA_AUDIT_RESET = BIT(3),
> - TPM2_SA_DECRYPT = BIT(5),
> - TPM2_SA_ENCRYPT = BIT(6),
> - TPM2_SA_AUDIT = BIT(7),
> -};
> -
> struct tpm2_hash {
> unsigned int crypto_id;
> unsigned int tpm_id;
> diff --git a/include/linux/tpm_command.h b/include/linux/tpm_command.h
> index 30d01953a6f8..9dd903dd6b5c 100644
> --- a/include/linux/tpm_command.h
> +++ b/include/linux/tpm_command.h
> @@ -156,4 +156,275 @@ struct tpm1_get_random_out {
> #define TPM_NONCE_SIZE 20
> #define TPM_ST_CLEAR 1
>
> +/*
> + * == TPM 2 Family Chips ==
> + *
> + * TPM 2.0 Library
> + * https://trustedcomputinggroup.org/resource/tpm-library-specification/
> + */
> +
> +/* TPM2 specific constants. */
> +#define TPM2_SPACE_BUFFER_SIZE 16384 /* 16 kB */
> +
> +enum tpm2_session_types {
> + TPM2_SE_HMAC = 0x00,
> + TPM2_SE_POLICY = 0x01,
> + TPM2_SE_TRIAL = 0x02,
> +};
> +
> +enum tpm2_timeouts {
> + TPM2_TIMEOUT_A = 750,
> + TPM2_TIMEOUT_B = 4000,
> + TPM2_TIMEOUT_C = 200,
> + TPM2_TIMEOUT_D = 30,
> + TPM2_DURATION_SHORT = 20,
> + TPM2_DURATION_MEDIUM = 750,
> + TPM2_DURATION_LONG = 2000,
> + TPM2_DURATION_LONG_LONG = 300000,
> + TPM2_DURATION_DEFAULT = 120000,
> +};
> +
> +enum tpm2_structures {
> + TPM2_ST_NO_SESSIONS = 0x8001,
> + TPM2_ST_SESSIONS = 0x8002,
> + TPM2_ST_CREATION = 0x8021,
> +};
> +
> +/* Indicates from what layer of the software stack the error comes from */
> +#define TSS2_RC_LAYER_SHIFT 16
> +#define TSS2_RESMGR_TPM_RC_LAYER (11 << TSS2_RC_LAYER_SHIFT)
> +
> +enum tpm2_return_codes {
> + TPM2_RC_SUCCESS = 0x0000,
> + TPM2_RC_HASH = 0x0083, /* RC_FMT1 */
> + TPM2_RC_HANDLE = 0x008B,
> + TPM2_RC_INTEGRITY = 0x009F,
> + TPM2_RC_INITIALIZE = 0x0100, /* RC_VER1 */
> + TPM2_RC_FAILURE = 0x0101,
> + TPM2_RC_DISABLED = 0x0120,
> + TPM2_RC_UPGRADE = 0x012D,
> + TPM2_RC_COMMAND_CODE = 0x0143,
> + TPM2_RC_TESTING = 0x090A, /* RC_WARN */
> + TPM2_RC_REFERENCE_H0 = 0x0910,
> + TPM2_RC_RETRY = 0x0922,
> + TPM2_RC_SESSION_MEMORY = 0x0903,
> +};
> +
> +enum tpm2_command_codes {
> + TPM2_CC_FIRST = 0x011F,
> + TPM2_CC_HIERARCHY_CONTROL = 0x0121,
> + TPM2_CC_HIERARCHY_CHANGE_AUTH = 0x0129,
> + TPM2_CC_CREATE_PRIMARY = 0x0131,
> + TPM2_CC_SEQUENCE_COMPLETE = 0x013E,
> + TPM2_CC_SELF_TEST = 0x0143,
> + TPM2_CC_STARTUP = 0x0144,
> + TPM2_CC_SHUTDOWN = 0x0145,
> + TPM2_CC_NV_READ = 0x014E,
> + TPM2_CC_CREATE = 0x0153,
> + TPM2_CC_LOAD = 0x0157,
> + TPM2_CC_SEQUENCE_UPDATE = 0x015C,
> + TPM2_CC_UNSEAL = 0x015E,
> + TPM2_CC_CONTEXT_LOAD = 0x0161,
> + TPM2_CC_CONTEXT_SAVE = 0x0162,
> + TPM2_CC_FLUSH_CONTEXT = 0x0165,
> + TPM2_CC_READ_PUBLIC = 0x0173,
> + TPM2_CC_START_AUTH_SESS = 0x0176,
> + TPM2_CC_VERIFY_SIGNATURE = 0x0177,
> + TPM2_CC_GET_CAPABILITY = 0x017A,
> + TPM2_CC_GET_RANDOM = 0x017B,
> + TPM2_CC_PCR_READ = 0x017E,
> + TPM2_CC_PCR_EXTEND = 0x0182,
> + TPM2_CC_EVENT_SEQUENCE_COMPLETE = 0x0185,
> + TPM2_CC_HASH_SEQUENCE_START = 0x0186,
> + TPM2_CC_CREATE_LOADED = 0x0191,
> + TPM2_CC_LAST = 0x0193, /* Spec 1.36 */
> +};
> +
> +enum tpm2_capabilities {
> + TPM2_CAP_HANDLES = 1,
> + TPM2_CAP_COMMANDS = 2,
> + TPM2_CAP_PCRS = 5,
> + TPM2_CAP_TPM_PROPERTIES = 6,
> +};
> +
> +enum tpm2_properties {
> + TPM_PT_TOTAL_COMMANDS = 0x0129,
> +};
> +
> +enum tpm2_startup_types {
> + TPM2_SU_CLEAR = 0x0000,
> + TPM2_SU_STATE = 0x0001,
> +};
> +
> +enum tpm2_cc_attrs {
> + TPM2_CC_ATTR_CHANDLES = 25,
> + TPM2_CC_ATTR_RHANDLE = 28,
> + TPM2_CC_ATTR_VENDOR = 29,
> +};
> +
> +enum tpm2_permanent_handles {
> + TPM2_RH_NULL = 0x40000007,
> + TPM2_RS_PW = 0x40000009,
> +};
> +
> +/* Most Significant Octet for key types */
> +enum tpm2_mso_type {
> + TPM2_MSO_NVRAM = 0x01,
> + TPM2_MSO_SESSION = 0x02,
> + TPM2_MSO_POLICY = 0x03,
> + TPM2_MSO_PERMANENT = 0x40,
> + TPM2_MSO_VOLATILE = 0x80,
> + TPM2_MSO_PERSISTENT = 0x81,
> +};
> +
> +enum tpm2_curves {
> + TPM2_ECC_NONE = 0x0000,
> + TPM2_ECC_NIST_P256 = 0x0003,
> +};
> +
> +enum tpm2_object_attributes {
> + TPM2_OA_FIXED_TPM = BIT(1),
> + TPM2_OA_ST_CLEAR = BIT(2),
> + TPM2_OA_FIXED_PARENT = BIT(4),
> + TPM2_OA_SENSITIVE_DATA_ORIGIN = BIT(5),
> + TPM2_OA_USER_WITH_AUTH = BIT(6),
> + TPM2_OA_ADMIN_WITH_POLICY = BIT(7),
> + TPM2_OA_NO_DA = BIT(10),
> + TPM2_OA_ENCRYPTED_DUPLICATION = BIT(11),
> + TPM2_OA_RESTRICTED = BIT(16),
> + TPM2_OA_DECRYPT = BIT(17),
> + TPM2_OA_SIGN = BIT(18),
> +};
> +
> +enum tpm2_session_attributes {
> + TPM2_SA_CONTINUE_SESSION = BIT(0),
> + TPM2_SA_AUDIT_EXCLUSIVE = BIT(1),
> + TPM2_SA_AUDIT_RESET = BIT(3),
> + TPM2_SA_DECRYPT = BIT(5),
> + TPM2_SA_ENCRYPT = BIT(6),
> + TPM2_SA_AUDIT = BIT(7),
> +};
> +
> +enum tpm2_pcr_select {
> + TPM2_PLATFORM_PCR = 24,
> + TPM2_PCR_SELECT_MIN = ((TPM2_PLATFORM_PCR + 7) / 8),
> +};
> +
> +enum tpm2_handle_types {
> + TPM2_HT_HMAC_SESSION = 0x02000000,
> + TPM2_HT_POLICY_SESSION = 0x03000000,
> + TPM2_HT_TRANSIENT = 0x80000000,
> +};
> +
> +enum tpm2_pt_props {
> + TPM2_PT_NONE = 0x00000000,
> + TPM2_PT_GROUP = 0x00000100,
> + TPM2_PT_FIXED = TPM2_PT_GROUP * 1,
> + TPM2_PT_FAMILY_INDICATOR = TPM2_PT_FIXED + 0,
> + TPM2_PT_LEVEL = TPM2_PT_FIXED + 1,
> + TPM2_PT_REVISION = TPM2_PT_FIXED + 2,
> + TPM2_PT_DAY_OF_YEAR = TPM2_PT_FIXED + 3,
> + TPM2_PT_YEAR = TPM2_PT_FIXED + 4,
> + TPM2_PT_MANUFACTURER = TPM2_PT_FIXED + 5,
> + TPM2_PT_VENDOR_STRING_1 = TPM2_PT_FIXED + 6,
> + TPM2_PT_VENDOR_STRING_2 = TPM2_PT_FIXED + 7,
> + TPM2_PT_VENDOR_STRING_3 = TPM2_PT_FIXED + 8,
> + TPM2_PT_VENDOR_STRING_4 = TPM2_PT_FIXED + 9,
> + TPM2_PT_VENDOR_TPM_TYPE = TPM2_PT_FIXED + 10,
> + TPM2_PT_FIRMWARE_VERSION_1 = TPM2_PT_FIXED + 11,
> + TPM2_PT_FIRMWARE_VERSION_2 = TPM2_PT_FIXED + 12,
> + TPM2_PT_INPUT_BUFFER = TPM2_PT_FIXED + 13,
> + TPM2_PT_HR_TRANSIENT_MIN = TPM2_PT_FIXED + 14,
> + TPM2_PT_HR_PERSISTENT_MIN = TPM2_PT_FIXED + 15,
> + TPM2_PT_HR_LOADED_MIN = TPM2_PT_FIXED + 16,
> + TPM2_PT_ACTIVE_SESSIONS_MAX = TPM2_PT_FIXED + 17,
> + TPM2_PT_PCR_COUNT = TPM2_PT_FIXED + 18,
> + TPM2_PT_PCR_SELECT_MIN = TPM2_PT_FIXED + 19,
> + TPM2_PT_CONTEXT_GAP_MAX = TPM2_PT_FIXED + 20,
> + TPM2_PT_NV_COUNTERS_MAX = TPM2_PT_FIXED + 22,
> + TPM2_PT_NV_INDEX_MAX = TPM2_PT_FIXED + 23,
> + TPM2_PT_MEMORY = TPM2_PT_FIXED + 24,
> + TPM2_PT_CLOCK_UPDATE = TPM2_PT_FIXED + 25,
> + TPM2_PT_CONTEXT_HASH = TPM2_PT_FIXED + 26,
> + TPM2_PT_CONTEXT_SYM = TPM2_PT_FIXED + 27,
> + TPM2_PT_CONTEXT_SYM_SIZE = TPM2_PT_FIXED + 28,
> + TPM2_PT_ORDERLY_COUNT = TPM2_PT_FIXED + 29,
> + TPM2_PT_MAX_COMMAND_SIZE = TPM2_PT_FIXED + 30,
> + TPM2_PT_MAX_RESPONSE_SIZE = TPM2_PT_FIXED + 31,
> + TPM2_PT_MAX_DIGEST = TPM2_PT_FIXED + 32,
> + TPM2_PT_MAX_OBJECT_CONTEXT = TPM2_PT_FIXED + 33,
> + TPM2_PT_MAX_SESSION_CONTEXT = TPM2_PT_FIXED + 34,
> + TPM2_PT_PS_FAMILY_INDICATOR = TPM2_PT_FIXED + 35,
> + TPM2_PT_PS_LEVEL = TPM2_PT_FIXED + 36,
> + TPM2_PT_PS_REVISION = TPM2_PT_FIXED + 37,
> + TPM2_PT_PS_DAY_OF_YEAR = TPM2_PT_FIXED + 38,
> + TPM2_PT_PS_YEAR = TPM2_PT_FIXED + 39,
> + TPM2_PT_SPLIT_MAX = TPM2_PT_FIXED + 40,
> + TPM2_PT_TOTAL_COMMANDS = TPM2_PT_FIXED + 41,
> + TPM2_PT_LIBRARY_COMMANDS = TPM2_PT_FIXED + 42,
> + TPM2_PT_VENDOR_COMMANDS = TPM2_PT_FIXED + 43,
> + TPM2_PT_NV_BUFFER_MAX = TPM2_PT_FIXED + 44,
> + TPM2_PT_MODES = TPM2_PT_FIXED + 45,
> + TPM2_PT_MAX_CAP_BUFFER = TPM2_PT_FIXED + 46,
> + TPM2_PT_VAR = TPM2_PT_GROUP * 2,
> + TPM2_PT_PERMANENT = TPM2_PT_VAR + 0,
> + TPM2_PT_STARTUP_CLEAR = TPM2_PT_VAR + 1,
> + TPM2_PT_HR_NV_INDEX = TPM2_PT_VAR + 2,
> + TPM2_PT_HR_LOADED = TPM2_PT_VAR + 3,
> + TPM2_PT_HR_LOADED_AVAIL = TPM2_PT_VAR + 4,
> + TPM2_PT_HR_ACTIVE = TPM2_PT_VAR + 5,
> + TPM2_PT_HR_ACTIVE_AVAIL = TPM2_PT_VAR + 6,
> + TPM2_PT_HR_TRANSIENT_AVAIL = TPM2_PT_VAR + 7,
> + TPM2_PT_HR_PERSISTENT = TPM2_PT_VAR + 8,
> + TPM2_PT_HR_PERSISTENT_AVAIL = TPM2_PT_VAR + 9,
> + TPM2_PT_NV_COUNTERS = TPM2_PT_VAR + 10,
> + TPM2_PT_NV_COUNTERS_AVAIL = TPM2_PT_VAR + 11,
> + TPM2_PT_ALGORITHM_SET = TPM2_PT_VAR + 12,
> + TPM2_PT_LOADED_CURVES = TPM2_PT_VAR + 13,
> + TPM2_PT_LOCKOUT_COUNTER = TPM2_PT_VAR + 14,
> + TPM2_PT_MAX_AUTH_FAIL = TPM2_PT_VAR + 15,
> + TPM2_PT_LOCKOUT_INTERVAL = TPM2_PT_VAR + 16,
> + TPM2_PT_LOCKOUT_RECOVERY = TPM2_PT_VAR + 17,
> + TPM2_PT_NV_WRITE_RECOVERY = TPM2_PT_VAR + 18,
> + TPM2_PT_AUDIT_COUNTER_0 = TPM2_PT_VAR + 19,
> + TPM2_PT_AUDIT_COUNTER_1 = TPM2_PT_VAR + 20,
> +};
> +
> +struct tpm2_pcr_read_out {
> + __be32 update_cnt;
> + __be32 pcr_selects_cnt;
> + __be16 hash_alg;
> + u8 pcr_select_size;
> + u8 pcr_select[TPM2_PCR_SELECT_MIN];
> + __be32 digests_cnt;
> + __be16 digest_size;
> + u8 digest[];
> +} __packed;
> +
> +struct tpm2_get_random_out {
> + __be16 size;
> + u8 buffer[TPM_MAX_RNG_DATA];
> +} __packed;
> +
> +struct tpm2_get_cap_out {
> + u8 more_data;
> + __be32 subcap_id;
> + __be32 property_cnt;
> + __be32 property_id;
> + __be32 value;
> +} __packed;
> +
> +struct tpm2_pcr_selection {
> + __be16 hash_alg;
> + u8 size_of_select;
> + u8 pcr_select[3];
> +} __packed;
> +
> +struct tpm2_context {
> + __be64 sequence;
> + __be32 saved_handle;
> + __be32 hierarchy;
> + __be16 blob_size;
> +} __packed;
> +
> #endif
> --
> 2.47.3
>
LGTM
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v16 04/38] tpm: Move TPM common base definitions to the command header
From: Jarkko Sakkinen @ 2026-05-15 23:22 UTC (permalink / raw)
To: Ross Philipson
Cc: linux-kernel, x86, linux-integrity, linux-doc, linux-crypto,
kexec, linux-efi, iommu, dpsmith, tglx, mingo, bp, hpa,
dave.hansen, ardb, mjg59, James.Bottomley, peterhuewe, jgg, luto,
nivedita, herbert, davem, corbet, ebiederm, dwmw2, baolu.lu,
kanth.ghatraju, daniel.kiper, andrew.cooper3, trenchboot-devel
In-Reply-To: <20260515211410.31440-5-ross.philipson@gmail.com>
On Fri, May 15, 2026 at 02:13:36PM -0700, Ross Philipson wrote:
> These are top level definitions shared by both TPM 1 and 2
> family chips. This includes core definitions like TPM localities,
> common crypto algorithm IDs, and the base TPM command header.
>
> Co-developed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> Co-developed-by: Alec Brown <alec.r.brown@oracle.com>
> Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
> Signed-off-by: Ross Philipson <ross.philipson@gmail.com>
> ---
> include/linux/tpm.h | 50 +--------------------
> include/linux/tpm_command.h | 89 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 90 insertions(+), 49 deletions(-)
>
> diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> index 8551b24c2bff..3630b2ea6aef 100644
> --- a/include/linux/tpm.h
> +++ b/include/linux/tpm.h
> @@ -27,49 +27,12 @@
>
> #include <linux/tpm_command.h>
>
> -#define TPM_DIGEST_SIZE 20 /* Max TPM v1.2 PCR size */
> -
> -#define TPM2_MAX_DIGEST_SIZE SHA512_DIGEST_SIZE
> -#define TPM2_MAX_PCR_BANKS 8
> -
> struct tpm_chip;
> struct trusted_key_payload;
> struct trusted_key_options;
> /* opaque structure, holds auth session parameters like the session key */
> struct tpm2_auth;
>
> -/* if you add a new hash to this, increment TPM_MAX_HASHES below */
> -enum tpm_algorithms {
> - TPM_ALG_ERROR = 0x0000,
> - TPM_ALG_SHA1 = 0x0004,
> - TPM_ALG_AES = 0x0006,
> - TPM_ALG_KEYEDHASH = 0x0008,
> - TPM_ALG_SHA256 = 0x000B,
> - TPM_ALG_SHA384 = 0x000C,
> - TPM_ALG_SHA512 = 0x000D,
> - TPM_ALG_NULL = 0x0010,
> - TPM_ALG_SM3_256 = 0x0012,
> - TPM_ALG_ECC = 0x0023,
> - TPM_ALG_CFB = 0x0043,
> -};
> -
> -/*
> - * maximum number of hashing algorithms a TPM can have. This is
> - * basically a count of every hash in tpm_algorithms above
> - */
> -#define TPM_MAX_HASHES 5
> -
> -struct tpm_digest {
> - u16 alg_id;
> - u8 digest[TPM2_MAX_DIGEST_SIZE];
> -} __packed;
> -
> -struct tpm_bank_info {
> - u16 alg_id;
> - u16 digest_size;
> - u16 crypto_id;
> -};
> -
> enum TPM_OPS_FLAGS {
> TPM_OPS_AUTO_STARTUP = BIT(0),
> };
> @@ -127,7 +90,7 @@ struct tpm_chip_seqops {
> const struct seq_operations *seqops;
> };
>
> -/* fixed define for the curve we use which is NIST_P256 */
> +/* Fixed define for the curve we use which is NIST_P256 */
> #define EC_PT_SZ 32
>
> /*
> @@ -209,8 +172,6 @@ struct tpm_chip {
> #endif
> };
>
> -#define TPM_HEADER_SIZE 10
> -
> static inline enum tpm2_mso_type tpm2_handle_mso(u32 handle)
> {
> return handle >> 24;
> @@ -239,15 +200,6 @@ enum tpm_chip_flags {
>
> #define to_tpm_chip(d) container_of(d, struct tpm_chip, dev)
>
> -struct tpm_header {
> - __be16 tag;
> - __be32 length;
> - union {
> - __be32 ordinal;
> - __be32 return_code;
> - };
> -} __packed;
> -
> enum tpm_buf_flags {
> /* the capacity exceeded: */
> TPM_BUF_OVERFLOW = BIT(0),
> diff --git a/include/linux/tpm_command.h b/include/linux/tpm_command.h
> index 9dd903dd6b5c..96edebd9610f 100644
> --- a/include/linux/tpm_command.h
> +++ b/include/linux/tpm_command.h
> @@ -427,4 +427,93 @@ struct tpm2_context {
> __be16 blob_size;
> } __packed;
>
> +/*
> + * == TPM Common Defs ==
> + */
> +
> +#define TPM_DIGEST_SIZE 20 /* Max TPM v1.2 PCR size */
> +#define TPM_BUFSIZE 4096
> +
> +/*
> + * SHA-512 is, as of today, the largest digest in the TCG algorithm repository.
> + */
> +#define TPM2_MAX_DIGEST_SIZE SHA512_DIGEST_SIZE
> +
> +/*
> + * A TPM name digest i.e., TPMT_HA, is a concatenation of TPM_ALG_ID of the
> + * name algorithm and hash of TPMT_PUBLIC.
> + */
> +#define TPM2_MAX_NAME_SIZE (TPM2_MAX_DIGEST_SIZE + 2)
> +
> +/*
> + * Fixed define for the size of a name. This is actually HASHALG size
> + * plus 2, so 32 for SHA256
> + */
> +#define TPM2_NULL_NAME_SIZE 34
> +
> +/*
> + * The maximum number of PCR banks.
> + */
> +#define TPM2_MAX_PCR_BANKS 8
> +
> +/* If you add a new hash to this, increment TPM_MAX_HASHES below */
> +enum tpm_algorithms {
> + TPM_ALG_ERROR = 0x0000,
> + TPM_ALG_SHA1 = 0x0004,
> + TPM_ALG_AES = 0x0006,
> + TPM_ALG_KEYEDHASH = 0x0008,
> + TPM_ALG_SHA256 = 0x000B,
> + TPM_ALG_SHA384 = 0x000C,
> + TPM_ALG_SHA512 = 0x000D,
> + TPM_ALG_NULL = 0x0010,
> + TPM_ALG_SM3_256 = 0x0012,
> + TPM_ALG_ECC = 0x0023,
> + TPM_ALG_CFB = 0x0043,
> +};
> +
> +/*
> + * The locality (0 - 4) for a TPM, as defined in section 3.2 of the
> + * Client Platform Profile Specification.
> + */
> +enum tpm_localities {
> + TPM_LOCALITY_0 = 0, /* Static RTM */
> + TPM_LOCALITY_1 = 1, /* Dynamic OS */
> + TPM_LOCALITY_2 = 2, /* DRTM Environment */
> + TPM_LOCALITY_3 = 3, /* Aux Components */
> + TPM_LOCALITY_4 = 4, /* CPU DRTM Establishment */
> + TPM_MAX_LOCALITY = TPM_LOCALITY_4
> +};
> +
> +/*
> + * Structure to represent active PCR algorithm banks usable by the
> + * TPM chip.
> + */
> +struct tpm_bank_info {
> + u16 alg_id;
> + u16 digest_size;
> + u16 crypto_id;
> +};
> +
> +/*
> + * Maximum number of hashing algorithms a TPM can have. This is
> + * basically a count of every hash in tpm_algorithms above
> + */
> +#define TPM_MAX_HASHES 5
> +
> +struct tpm_digest {
> + u16 alg_id;
> + u8 digest[TPM2_MAX_DIGEST_SIZE];
> +} __packed;
> +
> +#define TPM_HEADER_SIZE 10
> +
> +struct tpm_header {
> + __be16 tag;
> + __be32 length;
> + union {
> + __be32 ordinal;
> + __be32 return_code;
> + };
> +} __packed;
> +
> #endif
> --
> 2.47.3
>
LGTM
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v16 01/38] tpm: Initial step to reorganize TPM public headers
From: Jarkko Sakkinen @ 2026-05-15 23:51 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Ross Philipson, linux-kernel, x86, linux-integrity, linux-doc,
linux-crypto, kexec, linux-efi, iommu, dpsmith, tglx, mingo, bp,
hpa, dave.hansen, ardb, mjg59, James.Bottomley, peterhuewe, luto,
nivedita, herbert, davem, corbet, ebiederm, dwmw2, baolu.lu,
kanth.ghatraju, daniel.kiper, andrew.cooper3, trenchboot-devel
In-Reply-To: <20260515230553.GO7702@ziepe.ca>
On Fri, May 15, 2026 at 08:05:53PM -0300, Jason Gunthorpe wrote:
> On Sat, May 16, 2026 at 02:03:59AM +0300, Jarkko Sakkinen wrote:
>
> > LGTM
> >
> > I'll hold on from actual tags up until there is some consensus with the
> > patch set.
>
> This patch set is huge, and I know there is alot of interest now in
> DRTM.
>
> Can we please split out and progress the TPM reorg mini-series at the
> front?
I'm not usually for "non-functional" series but in the case of D-RTM
that could stil bel a good idea.
I.e. let's iterate it through faster than the main series and get it to
the mainline before next merge window, and then switch gears back to
the "main series".
>
> Jason
BR, Jarkko
^ permalink raw reply
* [linux-next:master 3552/4394] htmldocs: Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst:1: WARNING: Title overline too short.
From: kernel test robot @ 2026-05-16 0:44 UTC (permalink / raw)
To: Linlin Zhang; +Cc: oe-kbuild-all, Mikulas Patocka, linux-doc
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: e98d21c170b01ddef366f023bbfcf6b31509fa83
commit: b4a0774bd7fd859c1d243be0919c8df39eac20c0 [3552/4394] dm: add documentation for dm-inlinecrypt target
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260516/202605160214.wOV5aa0q-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605160214.wOV5aa0q-lkp@intel.com/
All warnings (new ones prefixed by >>):
WARNING: Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:36: abi_sys_class_reboot_mode_driver_reboot_modes doesn't have a description
WARNING: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/os_mode is defined 2 times: Documentation/ABI/testing/sysfs-driver-hid-lenovo-go:364; Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s:234
WARNING: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/os_mode_index is defined 2 times: Documentation/ABI/testing/sysfs-driver-hid-lenovo-go:373; Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s:243
WARNING: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/enabled is defined 2 times: Documentation/ABI/testing/sysfs-driver-hid-lenovo-go:636; Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s:252
WARNING: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/enabled_index is defined 2 times: Documentation/ABI/testing/sysfs-driver-hid-lenovo-go:645; Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s:261
>> Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst:1: WARNING: Title overline too short.
--
Documentation/userspace-api/landlock:550: ./include/uapi/linux/landlock.h:45: ERROR: Unknown target name: "network flags". [docutils]
Documentation/userspace-api/landlock:550: ./include/uapi/linux/landlock.h:50: ERROR: Unknown target name: "scope flags". [docutils]
Documentation/userspace-api/landlock:550: ./include/uapi/linux/landlock.h:24: ERROR: Unknown target name: "filesystem flags". [docutils]
Documentation/userspace-api/landlock:559: ./include/uapi/linux/landlock.h:168: ERROR: Unknown target name: "filesystem flags". [docutils]
Documentation/userspace-api/landlock:559: ./include/uapi/linux/landlock.h:191: ERROR: Unknown target name: "network flags". [docutils]
>> Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst: WARNING: document isn't included in any toctree [toc.not_included]
Documentation/networking/skbuff:36: ./include/linux/skbuff.h:181: WARNING: Failed to create a cross reference. A title or caption not found: 'crc' [ref.ref]
vim +1 Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst
> 1 ========
2 dm-inlinecrypt
3 ========
4
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v14 net-next 02/11] net/nebula-matrix: add our driver architecture
From: Jakub Kicinski @ 2026-05-16 1:17 UTC (permalink / raw)
To: illusion.wang
Cc: Jakub Kicinski, dimon.zhao, alvin.wang, sam.chen, netdev,
andrew+netdev, corbet, horms, linux-doc, pabeni, vadim.fedorenko,
lukas.bulwahn, edumazet, enelsonmoore, skhan, hkallweit1,
linux-kernel
In-Reply-To: <20260513011649.4404-3-illusion.wang@nebula-matrix.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net/nebula-matrix: add our driver architecture
This commit introduces the baseline driver architecture for the
nebula-matrix networking device. It establishes the Hardware, Channel,
Resource, Dispatch, and Device layers for device management.
> diff --git a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.c b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.c
> index 0000000000000..1d673b7757655
> --- /dev/null
> +++ b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.c
[ ... ]
> @@ -46,104 +46,149 @@
> +int nbl_hw_init_leonis(struct nbl_adapter *adapter)
> +{
[ ... ]
> + if (common->has_ctrl) {
> + bar_len = pci_resource_len(pdev, NBL_MEMORY_BAR);
> + bar_start = pci_resource_start(pdev, NBL_MEMORY_BAR);
> + if (!(pci_resource_flags(pdev, NBL_MEMORY_BAR) &
> + IORESOURCE_MEM) ||
> + bar_len < NBL_RDMA_NOTIFY_OFF) {
If bar_len is exactly equal to NBL_RDMA_NOTIFY_OFF (8192 bytes), this check
evaluates to false and passes.
> + dev_err(&pdev->dev, "Invalid BAR: unassigned or length too small\n");
> + ret = -EINVAL;
> + goto ioremap_err;
> + }
> + hw_mgt->hw_addr =
> + ioremap(bar_start,
> + bar_len - NBL_RDMA_NOTIFY_OFF);
Which then leads to ioremap(bar_start, 0) here. Is mapping 0 bytes valid, or
could it lead to out-of-bounds accesses? Should the condition above be
bar_len <= NBL_RDMA_NOTIFY_OFF?
> + if (!hw_mgt->hw_addr) {
> + dev_err(&pdev->dev, "Memory bar ioremap failed\n");
> + ret = -EIO;
> + goto ioremap_err;
> + }
> + hw_mgt->hw_size = bar_len - NBL_RDMA_NOTIFY_OFF;
> + } else {
> + hw_mgt->hw_addr =
> + ioremap(pci_resource_start(pdev, NBL_MEMORY_BAR),
> + NBL_RDMA_NOTIFY_OFF);
Are we missing a validation check here? Unlike the has_ctrl branch, this
unconditionally maps NBL_MEMORY_BAR without checking if the BAR has the
IORESOURCE_MEM flag or if its length is at least NBL_RDMA_NOTIFY_OFF. Could
this cause issues if the device presents an unassigned or I/O port BAR?
> diff --git a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_reg.h b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_reg.h
> index 0000000000000..2921f70890722
> --- /dev/null
> +++ b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_reg.h
[ ... ]
> +
> +#define NBL_MEMORY_BAR 0
> +#define NBL_MAILBOX_BAR 2
> +#define NBL_RDMA_NOTIFY_OFF 8192
> +#define NBL_HW_DUMMY_REG 0x1300904
[ ... ]
> +static inline void nbl_flush_writes(struct nbl_hw_mgt *hw_mgt)
> +{
> + nbl_hw_rd32(hw_mgt, NBL_HW_DUMMY_REG);
> +}
Can this perform an out-of-bounds memory read? NBL_HW_DUMMY_REG is defined as
0x1300904 (~19MB), but when has_ctrl is false, the driver explicitly maps only
NBL_RDMA_NOTIFY_OFF (8192 bytes) for hw_mgt->hw_addr. Should the driver ensure
the offset is bounded by hw_mgt->hw_size?
> diff --git a/drivers/net/ethernet/nebula-matrix/nbl/nbl_main.c b/drivers/net/ethernet/nebula-matrix/nbl/nbl_main.c
> index 10c3536b327b2..56131a50d59bd 100644
> --- a/drivers/net/ethernet/nebula-matrix/nbl/nbl_main.c
> +++ b/drivers/net/ethernet/nebula-matrix/nbl/nbl_main.c
[ ... ]
> +struct nbl_adapter *nbl_core_init(struct pci_dev *pdev,
> + struct nbl_init_param *param)
> +{
[ ... ]
> + ret = product_base_ops->hw_init(adapter);
> + if (ret)
> + goto hw_init_fail;
> +
> + ret = product_base_ops->chan_init(adapter);
> + if (ret)
> + goto chan_init_fail;
> +
> + ret = product_base_ops->res_init(adapter);
> + if (ret)
> + goto res_init_fail;
> +
> + ret = nbl_disp_init(adapter);
> + if (ret)
> + goto disp_init_fail;
> +
> + ret = nbl_dev_init(adapter);
> + if (ret)
> + goto dev_init_fail;
> + return adapter;
> +
> +dev_init_fail:
> + nbl_disp_remove(adapter);
> +disp_init_fail:
> + product_base_ops->res_remove(adapter);
> +res_init_fail:
> + product_base_ops->chan_remove(adapter);
> +chan_init_fail:
> + product_base_ops->hw_remove(adapter);
> +hw_init_fail:
> + return NULL;
> +}
Does this silently discard specific initialization error codes? When
sub-initialization routines fail, they return informative error codes like
-ENOMEM or -EINVAL, but this function catches them and simply returns NULL.
[ ... ]
> +static void nbl_get_func_param(struct pci_dev *pdev, kernel_ulong_t driver_data,
> + struct nbl_init_param *param)
> +{
[ ... ]
> + /*
> + * Leonis only PF0 has ctrl capability, but PF0's pcie device_id
> + * is same with other PF.So handle it special.
> + */
> + if (param->product_type == NBL_LEONIS_TYPE &&
> + (PCI_FUNC(pdev->devfn) == 0))
> + param->caps.has_ctrl = 1;
> +}
Could this incorrectly grant VFs management privileges? In SR-IOV environments
where VFs are assigned to new virtual buses (such as with Alternative Routing-ID
Interpretation), VFs can also have a function number of 0. Should the driver
verify that the device is actually a Physical Function by checking
!pdev->is_virtfn?
[ ... ]
> +static int nbl_probe(struct pci_dev *pdev,
> + const struct pci_device_id *id)
> +{
[ ... ]
> + adapter = nbl_core_init(pdev, ¶m);
> + if (!adapter) {
> + dev_err(dev, "Nbl adapter init fail\n");
> + err = -ENODEV;
> + goto adapter_init_err;
> + }
If nbl_core_init() returned an ERR_PTR(ret) instead of NULL, we wouldn't have
to unconditionally override the true root cause of probe failures with -ENODEV,
which could make driver debugging easier.
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH v14 net-next 03/11] net/nebula-matrix: add chip related definitions
From: Jakub Kicinski @ 2026-05-16 1:17 UTC (permalink / raw)
To: illusion.wang
Cc: Jakub Kicinski, dimon.zhao, alvin.wang, sam.chen, netdev,
andrew+netdev, corbet, horms, linux-doc, pabeni, vadim.fedorenko,
lukas.bulwahn, edumazet, enelsonmoore, skhan, hkallweit1,
linux-kernel
In-Reply-To: <20260513011649.4404-4-illusion.wang@nebula-matrix.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net/nebula-matrix: add chip related definitions
This patch adds chip-related register definitions for the Leonis
hardware and introduces nbl_write_all_regs(), which programs a large
set of P4 configuration tables at chip initialization time.
> They also should not be moved into firmware files,
> as the software functionality is tightly coupled with these
> configurations.If they were moved to firmware,users could easily end up
> with mismatched versions of the firmware and the kernel driver module,
> leading to functional inconsistencies or system malfunctions.
Is it acceptable to bypass the standard request_firmware() API by embedding
these large configuration blobs directly in the C source?
Embedding large configuration blobs bloats the kernel image. Versioning
compatibility is typically handled through embedded firmware headers and
versioned file requests rather than static inclusion.
diff --git a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.h b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.h
--- a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.h
+++ b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.h
[ ... ]
> union nbl_mailbox_qinfo_map_table_u {
> struct nbl_mailbox_qinfo_map_table {
> u32 function:3;
> u32 devid:5;
> u32 bus:8;
> u32 msix_idx:13;
> u32 msix_idx_valid:1;
> u32 rsv:2;
> } __packed info;
> u32 data;
> };
Can the use of C bitfields for hardware register formats cause endianness
portability regressions?
The memory layout and bit-packing direction of C bitfields are
compiler-defined and vary by CPU architecture endianness. On big-endian
systems, writing the 32-bit data representation to an MMIO register might
transmit the bits in reverse block order compared to a little-endian system.
[ ... ]
> #define NBL_FUNC_MSIX_MAP_DWLEN 3
> union nbl_function_msix_map_u {
> struct nbl_function_msix_map {
> u64 msix_map_base_addr;
> u32 function:3;
> u32 devid:5;
> u32 bus:8;
> u32 valid:1;
> u32 rsv0:15;
> u32 rsv1;
> } info;
> u32 data[NBL_FUNC_MSIX_MAP_DWLEN];
> };
Could this size mismatch lead to incorrect hardware register array strides?
The struct contains an 8-byte u64, 4 bytes of bitfields, and a 4-byte u32,
making the unpacked struct 16 bytes. However, NBL_FUNC_MSIX_MAP_DWLEN is 3,
making the u32 array 12 bytes long.
Because a union's size is determined by its largest member, the sizeof
evaluates to 16 bytes. The macro NBL_PCOMPLETER_FUNCTION_MSIX_MAP_REG_ARR(i)
uses this sizeof to calculate hardware offsets, which might lead to writing
MSI-X configuration to the wrong PCIe offsets.
diff --git a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis_regs.c b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis_regs.c
--- a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis_regs.c
+++ b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis_regs.c
[ ... ]
> #define NBL_SEC021_SIZE 1
> #define NBL_SEC021_ADDR 0x8c1f8
> #define NBL_SEC022_SIZE 256
> #define NBL_SEC022_ADDR 0x85f000
> #define NBL_SEC022_REGI(i) (0x85f000 + NBL_BYTES_IN_REG * (i))
> #define NBL_SEC023_SIZE 128
> #define NBL_SEC023_ADDR 0x85f800
Could this NBL_SEC022_SIZE macro introduce a regression by truncating the
hardware initialization data?
The macro is defined as 256, which means only the first 256 elements of the
NBL_SEC022 block are written. However, the corresponding data array
nbl_sec022_data contains 512 elements, and the address gap between
NBL_SEC022_ADDR (0x85f000) and NBL_SEC023_ADDR (0x85f800) is exactly 0x800
bytes, which fits exactly 512 u32 registers.
^ permalink raw reply
* Re: [PATCH v14 net-next 05/11] net/nebula-matrix: add channel layer
From: Jakub Kicinski @ 2026-05-16 1:17 UTC (permalink / raw)
To: illusion.wang
Cc: Jakub Kicinski, dimon.zhao, alvin.wang, sam.chen, netdev,
andrew+netdev, corbet, horms, linux-doc, pabeni, vadim.fedorenko,
lukas.bulwahn, edumazet, enelsonmoore, skhan, hkallweit1,
linux-kernel
In-Reply-To: <20260513011649.4404-6-illusion.wang@nebula-matrix.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net/nebula-matrix: add channel layer
A channel management layer provides a structured approach to handle
communication between different components and drivers. It handles message
registration, message sending/acknowledgment, and queue management using
mailbox channels.
> diff --git a/drivers/net/ethernet/nebula-matrix/nbl/nbl_channel/nbl_channel.c b/drivers/net/ethernet/nebula-matrix/nbl/nbl_channel/nbl_channel.c
> index c1b724a8b92dd..8b178b8f6de3f 100644
> --- a/drivers/net/ethernet/nebula-matrix/nbl/nbl_channel/nbl_channel.c
> +++ b/drivers/net/ethernet/nebula-matrix/nbl/nbl_channel/nbl_channel.c
[ ... ]
> +static int nbl_chan_teardown_queue(struct nbl_channel_mgt *chan_mgt,
> + u8 chan_type)
> +{
> + struct nbl_chan_info *chan_info = chan_mgt->chan_info[chan_type];
> +
> + cancel_work_sync(chan_info->clean_task);
Could this pointer be uninitialized? If nbl_chan_setup_queue() fails
early (for example, during buffer allocation), it calls this teardown
function, but the clean_task appears to only be registered externally later.
Would this pass a NULL pointer to cancel_work_sync() and cause a panic?
[ ... ]
> +static int nbl_chan_update_txqueue(struct nbl_channel_mgt *chan_mgt,
> + struct nbl_chan_info *chan_info,
> + struct nbl_chan_tx_param *param)
> +{
[ ... ]
> + if (param->arg_len > NBL_CHAN_TX_DESC_EMBEDDED_DATA_LEN) {
> + memcpy(tx_buf->va, param->arg, param->arg_len);
> + tx_desc->buf_addr = cpu_to_le64(tx_buf->pa);
> + tx_desc->buf_len = cpu_to_le16(param->arg_len);
> + tx_desc->data_len = 0;
> + } else {
> + memcpy(tx_desc->data, param->arg, param->arg_len);
> + tx_desc->buf_len = 0;
> + tx_desc->data_len = cpu_to_le16(param->arg_len);
> + }
> + tx_desc->flags = cpu_to_le16(BIT(NBL_CHAN_TX_DESC_AVAIL));
Should there be a dma_wmb() before setting the AVAIL flag? Without a memory
barrier here, the CPU might reorder the flag write before the payload data
is fully committed, causing the hardware DMA engine to fetch an incomplete
descriptor.
[ ... ]
> +static int nbl_chan_kick_tx_ring(struct nbl_channel_mgt *chan_mgt,
> + struct nbl_chan_info *chan_info)
> +{
[ ... ]
> + while (retry_count < max_retries) {
> + if (le16_to_cpu(READ_ONCE(tx_desc->flags)) &
> + BIT(NBL_CHAN_TX_DESC_USED)) {
> + dma_rmb();
> + break;
> + }
> +
> + if (!(retry_count % NBL_CHAN_TX_REKICK_WAIT_TIMES))
> + NBL_UPDATE_QUEUE_TAIL_PTR(chan_info, hw_ops, chan_mgt,
> + txq->tail_ptr, NBL_MB_TX_QID);
> + retry_count++;
> +
> + usleep_range(NBL_CHAN_TX_WAIT_US, NBL_CHAN_TX_WAIT_US_MAX);
> + }
> + if (retry_count >= max_retries) {
> + dev_err(dev, "chan send message type: %d timeout\n",
> + le16_to_cpu(READ_ONCE(tx_desc->msg_type)));
> + return -ETIMEDOUT;
> + }
> + txq->next_to_clean = txq->next_to_use;
If a timeout happens, this returns -ETIMEDOUT without advancing
txq->next_to_clean. Won't this permanently wedge the TX queue, because the
next send operation will start polling the exact same stuck descriptor and
timeout again?
[ ... ]
> +static void nbl_chan_recv_ack_msg(void *priv, u16 srcid, u16 msgid, void *data,
> + u32 data_len)
> +{
[ ... ]
> + if (ack_datalen > MAX_ACK_DATA_SIZE) {
> + dev_err(dev, "Invalid loc=%d\n", ack_msgid.info.loc);
> + return;
> + }
> + ack_msgid.id = *(u16 *)(payload + NBL_CHAN_MSG_ID_POS);
Doesn't the error log above print an uninitialized value? The ack_msgid
union is populated on the line right after it is logged, so it will always
print the zero-initialized default value.
Also, is it safe to read the msgid by casting the payload pointer like this?
Since the sender stores a 16-bit msgid into a 32-bit array natively, casting
to a u16 pointer will read the upper 16 bits of the 32-bit word on big-endian
architectures. That would result in a message ID of 0 and break the ACK
mechanism.
[ ... ]
> + wait_head->ack_err = *(payload + NBL_CHAN_ACK_RET_POS);
> +
> + copy_len = min_t(u32, wait_head->ack_data_len, ack_datalen);
> + if (wait_head->ack_err >= 0 && copy_len > 0) {
> + if (NBL_CHAN_ACK_HEAD_LEN * sizeof(u32) + copy_len > data_len) {
> + dev_err(dev, "ACK payload overflow\n");
> + return;
> + }
> + memcpy((char *)wait_head->ack_data,
> + payload + NBL_CHAN_ACK_HEAD_LEN, copy_len);
> + wait_head->ack_data_len = (u16)copy_len;
> + } else {
> + wait_head->ack_data_len = 0;
> + }
Can this memcpy() race with the timeout path in nbl_chan_send_msg()? The
receiver checks wait_head->status earlier without holding locks. If
nbl_chan_send_msg() times out immediately after that check, it sets
wait_head->ack_data to NULL and returns, freeing its local buffer. The
receiver might then resume and execute this memcpy into a NULL pointer or a
freed stack frame.
[ ... ]
> +static void nbl_chan_recv_msg(struct nbl_channel_mgt *chan_mgt, void *data)
> +{
[ ... ]
> + if (tx_desc->data_len) {
> + payload_len = le16_to_cpu(tx_desc->data_len);
> + if (payload_len > NBL_CHAN_TX_DESC_DATA_LEN) {
> + dev_err(dev, "data_len=%u exceeds embedded buffer size=%u\n",
> + payload_len,
> + NBL_CHAN_TX_DESC_DATA_LEN);
> + return;
> + }
> + payload = tx_desc->data;
> + } else {
> + payload_len = le16_to_cpu(tx_desc->buf_len);
> + if (payload_len > NBL_CHAN_BUF_LEN) {
> + dev_err(dev, "buf_len=%u exceeds external buffer size=%u\n",
> + payload_len,
> + NBL_CHAN_BUF_LEN);
> + return;
> + }
> + payload = tx_desc + 1;
> + }
Could this result in an out-of-bounds access? The external buffer payload
pointer starts at tx_desc + 1 (an offset of sizeof(struct nbl_chan_tx_desc),
which is 64 bytes). If payload_len is between 4033 and 4096,
payload + payload_len will exceed the total NBL_CHAN_BUF_LEN of 4096 bytes,
overflowing the buffer boundary.
[ ... ]
> +static int nbl_chan_send_msg(struct nbl_channel_mgt *chan_mgt,
> + struct nbl_chan_send_info *chan_send)
> +{
[ ... ]
> + /*polling wait mailbox ack*/
> + mutex_lock(&chan_info->txq_lock);
> + while (i--) {
> + nbl_chan_clean_queue(chan_mgt, chan_info);
> +
> + if (wait_head->acked) {
> + chan_send->ack_len = wait_head->ack_data_len;
> + atomic_set(&wait_head->status, NBL_MBX_STATUS_IDLE);
> + ret = READ_ONCE(wait_head->ack_err);
> + mutex_unlock(&chan_info->txq_lock);
> + return ret;
> + }
Are we missing a read memory barrier here? The receiver uses a wmb() before
setting wait_head->acked = 1, but the polling loop lacks a corresponding rmb()
after observing the flag. The CPU could reorder the reads, causing this code
to read stale values for ack_data_len or ack_err.
Also, is it possible for this polling loop to self-deadlock? The loop holds
txq_lock while calling nbl_chan_clean_queue(), which processes incoming
messages. If an incoming message requires an ACK, its handler will call
nbl_chan_send_ack(), which eventually calls nbl_chan_send_msg() again and
will attempt to reacquire the non-recursive txq_lock.
[ ... ]
> +static int nbl_chan_send_ack(struct nbl_channel_mgt *chan_mgt,
> + struct nbl_chan_ack_info *chan_ack)
> +{
> + u32 len = NBL_CHAN_ACK_HEAD_LEN * sizeof(u32) + chan_ack->data_len;
Does this calculation have an integer overflow issue? A sufficiently large
chan_ack->data_len could cause len to wrap around, leading to a tiny heap
allocation. The subsequent memcpy() would then write past the end of the buffer.
[ ... ]
> +int nbl_chan_init_common(struct nbl_adapter *adap)
> +{
[ ... ]
> + chan_ops_tbl = nbl_chan_setup_ops(dev, chan_mgt);
> + if (IS_ERR(chan_ops_tbl)) {
> + ret = PTR_ERR(chan_ops_tbl);
> + goto exit;
> + }
> + adap->intf.channel_ops_tbl = chan_ops_tbl;
> +
> + return 0;
> +
> +exit:
> + if (chan_mgt) {
> + nbl_chan_remove_msg_handler(chan_mgt);
> + adap->core.chan_mgt = NULL;
> + }
Will this cause a panic if nbl_chan_setup_chan_mgt() returns an ERR_PTR?
The condition if (chan_mgt) will evaluate to true for an error pointer, and
nbl_chan_remove_msg_handler() will dereference it. A check like
!IS_ERR_OR_NULL(chan_mgt) might be safer here.
> diff --git a/drivers/net/ethernet/nebula-matrix/nbl/nbl_common/nbl_common.c b/drivers/net/ethernet/nebula-matrix/nbl/nbl_common/nbl_common.c
> new file mode 100644
> index 0000000000000..79c1d5f5aacf9
> --- /dev/null
> +++ b/drivers/net/ethernet/nebula-matrix/nbl/nbl_common/nbl_common.c
[ ... ]
> +void nbl_common_destroy_wq(void)
> +{
> + destroy_workqueue(wq_mgt->ctrl_dev_wq);
> + kfree(wq_mgt);
> + wq_mgt = NULL;
> +}
Is it possible that wq_mgt is NULL here? If nbl_common_create_wq() fails to
allocate the workqueue, it frees wq_mgt and sets it to NULL. A subsequent
cleanup call to nbl_common_destroy_wq() would unconditionally dereference it.
[ ... ]
> +int nbl_common_alloc_hash_node(struct nbl_hash_tbl_mgt *tbl_mgt, void *key,
> + void *data, void **out_data)
> +{
[ ... ]
> + hash_val = nbl_common_calc_hash_key(key, key_size,
> + tbl_mgt->tbl_key.bucket_size);
> +
> + hlist_add_head(&hash_node->node, tbl_mgt->hash + hash_val);
> + tbl_mgt->node_num++;
> + if (out_data)
> + *out_data = hash_node->data;
> +
> + return 0;
[ ... ]
> +void *nbl_common_get_hash_node(struct nbl_hash_tbl_mgt *tbl_mgt, void *key)
> +{
[ ... ]
> + hlist_for_each_entry(hash_node, head, node)
> + if (!memcmp(hash_node->key, key, key_size)) {
> + data = hash_node->data;
> + break;
> + }
> +
> + return data;
> +}
Is there a synchronization issue with this hash table implementation? The
code modifies and traverses the hlist without any locking or RCU protection.
Concurrent message registration and reception could corrupt the linked list.
^ permalink raw reply
* Re: [PATCH v14 net-next 06/11] net/nebula-matrix: add common resource implementation
From: Jakub Kicinski @ 2026-05-16 1:17 UTC (permalink / raw)
To: illusion.wang
Cc: Jakub Kicinski, dimon.zhao, alvin.wang, sam.chen, netdev,
andrew+netdev, corbet, horms, linux-doc, pabeni, vadim.fedorenko,
lukas.bulwahn, edumazet, enelsonmoore, skhan, hkallweit1,
linux-kernel
In-Reply-To: <20260513011649.4404-7-illusion.wang@nebula-matrix.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net/nebula-matrix: add common resource implementation
The Resource layer processes the entries/data of various modules within
the processing chip to accomplish specific entry management operations,
this describes the module business capabilities of the chip and the data
it manages.
This patch provides the common part, including the conversion
relationships among vsi_id, func_id, eth_id, and pf_id.
> diff --git a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.c b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.c
> index b63c91e559af4..55d6ed70a9e60 100644
> --- a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.c
> +++ b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.c
[ ... ]
> @@ -148,6 +169,36 @@ static void nbl_hw_cfg_mailbox_qinfo(struct nbl_hw_mgt *hw_mgt, u16 func_id,
> +static void nbl_hw_cfg_mailbox_qinfo(struct nbl_hw_mgt *hw_mgt, u16 func_id,
> + u16 bus, u16 devid, u16 function)
> +{
> + union nbl_mailbox_qinfo_map_table_u mb_qinfo_map;
> +
> + memset(&mb_qinfo_map, 0, sizeof(mb_qinfo_map));
> + mb_qinfo_map.info.function = function;
> + mb_qinfo_map.info.devid = devid;
> + mb_qinfo_map.info.bus = bus;
Since the memory layout of C bitfields within an integer is compiler-defined
and depends on the CPU's endianness, will assigning to bitfields in
mb_qinfo_map.info result in incorrect bits being written to the hardware
register on big-endian architectures?
Also, if the caller passes a function value that exceeds the width of the
function bitfield (which appears to be 3 bits based on standard PCIe), will
the value be silently truncated, causing multiple distinct PFs to map to the
same PCIe function?
> + mb_qinfo_map.info.msix_idx_valid = 0;
> + nbl_hw_wr_regs(hw_mgt, NBL_MAILBOX_QINFO_MAP_REG_ARR(func_id),
> + &mb_qinfo_map.data, sizeof(mb_qinfo_map));
> +}
> +
> +static void nbl_hw_get_board_info(struct nbl_hw_mgt *hw_mgt,
> + struct nbl_board_port_info *board_info)
> +{
> + union nbl_fw_board_cfg_dw3 dw3 = { .info = { 0 } };
> +
> + nbl_hw_read_mbx_regs(hw_mgt, NBL_FW_BOARD_DW3_OFFSET, &dw3.data,
> + sizeof(dw3));
> + board_info->eth_num = dw3.info.port_num;
Similarly, does reading from the dw3.info bitfields cause incorrect values
to be extracted on big-endian architectures?
[ ... ]
> diff --git a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_resource_leonis.c b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_resource_leonis.c
> index 6885195c96ca8..7c366a1d5e489 100644
> --- a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_resource_leonis.c
> +++ b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_resource_leonis.c
[ ... ]
> @@ -45,8 +48,164 @@ nbl_res_setup_ops(struct device *dev, struct nbl_resource_mgt *res_mgt)
> +static int nbl_res_ctrl_dev_setup_eth_info(struct nbl_resource_mgt *res_mgt)
> +{
[ ... ]
> + eth_info->eth_num =
> + (u8)hw_ops->get_fw_eth_num(res_mgt->hw_ops_tbl->priv);
> + if (eth_info->eth_num > NBL_MAX_ETHERNET) {
> + dev_warn(dev, "FW reports %u Ethernet ports, but only %u are supported\n",
> + eth_info->eth_num, NBL_MAX_ETHERNET);
> + eth_info->eth_num = NBL_MAX_ETHERNET;
> + }
> + eth_bitmap = hw_ops->get_fw_eth_map(res_mgt->hw_ops_tbl->priv);
> + /* for 2 eth port board, the eth_id is 0, 2 */
> + for (i = 0; i < NBL_MAX_ETHERNET; i++) {
> + if ((1 << i) & eth_bitmap) {
> + set_bit(i, eth_info->eth_bitmap);
> + eth_info->eth_id[eth_num] = i;
> + eth_info->logic_eth_id[i] = eth_num;
> + eth_num++;
> + }
> + }
If the firmware returns an eth_info->eth_num that is greater than the
number of set bits in eth_bitmap, could this lead to uninitialized elements
in the eth_id array being accessed later?
> +
> + for (i = 0; i < res_mgt->resource_info->max_pf; i++) {
> + /* Map PF index i to eth_id from eth_info->eth_id[i]
> + * if i < eth_num, otherwise map to eth_id 0
> + */
> + if (i < eth_num) {
> + eth_id = eth_info->eth_id[i];
> + eth_info->pf_bitmap[eth_id] |= BIT(i);
> + } else {
> + eth_info->pf_bitmap[0] |= BIT(i);
> + }
> + }
If the eth_bitmap from the firmware does not have bit 0 set (meaning
physical port 0 is inactive), will excess PFs be mapped to a dead port here
instead of the first active physical port?
> +
> + return 0;
> +}
> +
> +static int nbl_res_ctrl_dev_sriov_info_init(struct nbl_resource_mgt *res_mgt)
> +{
[ ... ]
> + common->hw_bus = hw_ops->get_real_bus(p);
> + for (func_id = 0; func_id < res_mgt->resource_info->max_pf; func_id++) {
> + sriov_info = res_mgt->resource_info->sriov_info + func_id;
> + sriov_info->bdf = PCI_DEVID(common->hw_bus,
> + PCI_DEVFN(common->devid, func_id));
> + }
> +
> + return 0;
> +}
Is there a potential mismatch in BDF tracking here if the base device function
(common->function) is not 0?
If the mailbox configuration layer expects the function to include
common->function, could this lead to inconsistent state between the
software and the hardware?
^ permalink raw reply
* Re: [PATCH v14 net-next 07/11] net/nebula-matrix: add intr resource implementation
From: Jakub Kicinski @ 2026-05-16 1:17 UTC (permalink / raw)
To: illusion.wang
Cc: Jakub Kicinski, dimon.zhao, alvin.wang, sam.chen, netdev,
andrew+netdev, corbet, horms, linux-doc, pabeni, vadim.fedorenko,
lukas.bulwahn, edumazet, enelsonmoore, skhan, hkallweit1,
linux-kernel
In-Reply-To: <20260513011649.4404-8-illusion.wang@nebula-matrix.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net/nebula-matrix: add intr resource implementation
Implement dynamic allocation and management of MSI-X interrupt vectors,
including network interrupts and other interrupt types. Maintain the
MSI-X mapping table (msix_map_table) to establish interrupt associations
between hardware and software. Support enabling/disabling specific
interrupts through hardware operations.
> diff --git a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.c b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.c
> index 55d6ed70a9e60..612d6c9812b01 100644
> --- a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.c
> +++ b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.c
> @@ -64,6 +64,76 @@ static void nbl_hw_wr_regs(struct nbl_hw_mgt *hw_mgt, u64 reg, const u32 *data,
[ ... ]
> +static void nbl_hw_configure_msix_map(struct nbl_hw_mgt *hw_mgt, u16 func_id,
> + bool valid, dma_addr_t dma_addr, u8 bus,
> + u8 devid, u8 function)
> +{
> + union nbl_function_msix_map_u function_msix_map;
> +
> + memset(&function_msix_map, 0, sizeof(function_msix_map));
> + if (valid) {
> + function_msix_map.info.msix_map_base_addr = dma_addr;
> + /* use af's bdf, because dma memmory is alloc by af */
> + function_msix_map.info.function = function;
> + function_msix_map.info.devid = devid;
> + function_msix_map.info.bus = bus;
> + function_msix_map.info.valid = 1;
> + }
> +
> + nbl_hw_wr_regs(hw_mgt,
> + NBL_PCOMPLETER_FUNCTION_MSIX_MAP_REG_ARR(func_id),
> + function_msix_map.data, sizeof(function_msix_map));
Is there an out-of-bounds array access here when passing
function_msix_map.data?
union nbl_function_msix_map_u contains struct info which is 16 bytes long,
but its data array is defined as u32 data[NBL_FUNC_MSIX_MAP_DWLEN], where
NBL_FUNC_MSIX_MAP_DWLEN is 3 (12 bytes).
When nbl_hw_wr_regs() receives sizeof(function_msix_map) (16 bytes), it will
iterate 4 times and access data[3]. Since data is an array of size 3, this
triggers an out-of-bounds memory violation under CONFIG_UBSAN_BOUNDS.
Should NBL_FUNC_MSIX_MAP_DWLEN be updated to 4?
> +}
[ ... ]
> diff --git a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_resource.h b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_resource.h
> index 15dc7f78afc0b..b1f5724e727a9 100644
> --- a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_resource.h
> +++ b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_resource.h
> @@ -18,6 +18,35 @@
>
> struct nbl_resource_mgt;
>
> +/* --------- INTERRUPT ---------- */
> +#define NBL_MAX_OTHER_INTERRUPT 1024
> +#define NBL_MAX_NET_INTERRUPT 4096
> +
> +struct nbl_msix_map {
> + u16 valid:1;
> + u16 global_msix_index:13;
> + u16 rsv:2;
> +};
Does this code use C bitfields for hardware-shared structures?
This structure is used for DMA-coherent memory in
nbl_res_intr_configure_msix_map():
drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_interrupt.c:nbl_res_intr_configure_msix_map() {
...
msix_map_table->size =
sizeof(struct nbl_msix_map) * NBL_MSIX_MAP_TABLE_MAX_ENTRIES;
msix_map_table->base_addr = dma_alloc_coherent(dev,
msix_map_table->size,
...
}
Bitfield packing order is implementation-defined in C. On Big Endian
architectures, compilers pack bitfields in the opposite direction from Little
Endian, which will cause the hardware to read misaligned or reversed bit
positions. Standard kernel practice mandates using explicitly sized types
like __le16 and bitwise operations (FIELD_PREP, etc.) for hardware-facing
memory.
The same applies to MMIO registers written using unions containing bitfields,
such as union nbl_function_msix_map_u and union nbl_mailbox_qinfo_map_table_u.
Could these be converted to standard bitwise operations as well?
^ permalink raw reply
* Re: [PATCH v14 net-next 08/11] net/nebula-matrix: add vsi resource implementation
From: Jakub Kicinski @ 2026-05-16 1:17 UTC (permalink / raw)
To: illusion.wang
Cc: Jakub Kicinski, dimon.zhao, alvin.wang, sam.chen, netdev,
andrew+netdev, corbet, horms, linux-doc, pabeni, vadim.fedorenko,
lukas.bulwahn, edumazet, enelsonmoore, skhan, hkallweit1,
linux-kernel
In-Reply-To: <20260513011649.4404-9-illusion.wang@nebula-matrix.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net/nebula-matrix: add vsi resource implementation
This commit introduces the hardware initialization sequence for the DP module,
the intf module, and P4 registers. It sets up various submodules including
dped, uped, shaping, ustore, and dstore.
> diff --git a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.c b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.c
> index 612d6c9812b01..feb8d1f6fc239 100644
> --- a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.c
> +++ b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.c
[ ... ]
> @@ -64,6 +65,409 @@ static void nbl_hw_wr_regs(struct nbl_hw_mgt *hw_mgt, u64 reg, const u32 *data,
[ ... ]
> +static void nbl_uped_init(struct nbl_hw_mgt *hw_mgt)
> +{
> + union ped_hw_edit_profile_u hw_edit;
> +
> + nbl_hw_rd_regs(hw_mgt, NBL_UPED_HW_EDT_PROF_TABLE(NBL_DPED_V4_TCP_IDX),
> + &hw_edit.data, sizeof(hw_edit));
This isn't a bug, but since data is an array (u32 data[8]), does taking its
address yield a pointer to an array (u32 (*)[8]) rather than a u32 * as
expected by nbl_hw_rd_regs()? Should the address-of operator be omitted?
> + hw_edit.info.l3_len = 0;
> + nbl_hw_wr_regs(hw_mgt, NBL_UPED_HW_EDT_PROF_TABLE(NBL_DPED_V4_TCP_IDX),
> + &hw_edit.data, sizeof(hw_edit));
[ ... ]
> +static void nbl_shaping_eth_init(struct nbl_hw_mgt *hw_mgt, u8 eth_id, u8 speed)
> +{
> + union nbl_shaping_dvn_dport_u dvn_dport = { 0 };
> + union nbl_shaping_dport_u dport = { 0 };
> + u32 rate, half_rate;
> + u32 depth;
> +
> + switch (speed) {
> + case NBL_FW_PORT_SPEED_100G:
> + rate = 100000;
> + break;
> + case NBL_FW_PORT_SPEED_50G:
> + rate = 50000;
> + break;
> + case NBL_FW_PORT_SPEED_25G:
> + rate = 25000;
> + break;
> + case NBL_FW_PORT_SPEED_10G:
> + rate = 10000;
> + break;
> + default:
> + dev_err(hw_mgt->common->dev, "Unsupported port speed %u for eth%u\n",
> + speed, eth_id);
> + break;
> + }
> +
> + half_rate = rate / 2;
If the default case is hit, rate remains uninitialized. Could this result in
writing uninitialized stack memory to hardware registers via half_rate?
> + depth = max(rate * 2, NBL_LR_LEONIS_NET_BUCKET_DEPTH);
> + dport.info.low |= FIELD_PREP(DPORT_CIR_MASK, rate);
[ ... ]
> diff --git a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.h b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.h
> index 7eef749eeb69f..75bb8b715f35a 100644
> --- a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.h
> +++ b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_hw_leonis/nbl_hw_leonis.h
[ ... ]
> @@ -258,6 +259,15 @@ union dsch_vn_quanta_u {
>
> #define DEFAULT_DVN_DESC_WR_MERGE_TIMEOUT_MAX 0x3FF
>
> +#define PACKET_RING_MIN 8U
> +#define PACKET_RING_MAX 32U
> +#define SPLIT_RING_MIN 8U
> +#define SPLIT_RING_MAX 16U
> +#define PACKET_RING_BASE 8U
> +#define PACKET_RING_DIV 4U
> +#define SPLIT_RING_CFG_8 0U
> +#define SPLIT_RING_CFG_16 1U
> +
> union nbl_dvn_descreq_num_cfg_u {
> struct nbl_dvn_descreq_num_cfg {
> u32 avring_cfg_num:1; /* spilit ring descreq_num 0:8,1:16 */
Is it safe to use C bitfields for hardware register layouts here? The memory
layout of bitfields is compiler-dependent and varies with architecture
endianness, which could result in incorrect bits being written to the device on
big-endian systems.
^ permalink raw reply
* Re: [PATCH v14 net-next 09/11] net/nebula-matrix: add Dispatch layer implementation
From: Jakub Kicinski @ 2026-05-16 1:17 UTC (permalink / raw)
To: illusion.wang
Cc: Jakub Kicinski, dimon.zhao, alvin.wang, sam.chen, netdev,
andrew+netdev, corbet, horms, linux-doc, pabeni, vadim.fedorenko,
lukas.bulwahn, edumazet, enelsonmoore, skhan, hkallweit1,
linux-kernel
In-Reply-To: <20260513011649.4404-10-illusion.wang@nebula-matrix.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net/nebula-matrix: add Dispatch layer implementation
This patch introduces a control-level routing mechanism for the Dispatch layer.
Routing is controlled by interface-declared levels and upper-layer configured
control levels.
> Current state:
> - Regular PF: configures NET_LVL at Dispatch layer.
> Since NBL_DISP_CTRL_LVL_NET is not yet wired in nbl_disp_init(),
> all operations currently fall through to the CTRL_LVL_MGT branch
> and use the channel path. The direct path for NET_LVL is a
> framework extension point reserved for future use.
>
> - Management PF: configures both NET_LVL and CTRL_LVL.
> Same as above — currently all ops use channel path.
>
> Future work:
> Implement the has_net / NBL_DISP_CTRL_LVL_NET branch in nbl_disp_init()
> to enable direct path routing for network operations.
The commit message states that NBL_DISP_CTRL_LVL_NET is not yet wired in
nbl_disp_init(), and lists implementing the has_net branch as future work.
However, the patch includes this exact logic in nbl_disp_init() below.
Could the commit message be updated to match the implemented code?
[ ... ]
> --- a/drivers/net/ethernet/nebula-matrix/nbl/nbl_core/nbl_dispatch.c
> +++ b/drivers/net/ethernet/nebula-matrix/nbl/nbl_core/nbl_dispatch.c
[ ... ]
> +static void nbl_disp_chan_get_vsi_id_resp(void *priv, u16 src_id, u16 msg_id,
> + void *data, u32 data_len)
> +{
[ ... ]
> + NBL_CHAN_ACK(chan_ack, src_id, NBL_CHAN_MSG_GET_VSI_ID, msg_id, err,
> + &result, sizeof(result));
> + ret = chan_ops->send_ack(disp_mgt->chan_ops_tbl->priv, &chan_ack);
Could this lead to a self-deadlock on txq_lock during mailbox polling?
If a message is sent while polling, nbl_chan_send_msg() acquires txq_lock
and processes incoming messages in its polling loop:
nbl_chan_send_msg() [acquires txq_lock]
-> nbl_chan_clean_queue()
-> nbl_chan_recv_msg()
-> nbl_disp_chan_get_vsi_id_resp()
If nbl_disp_chan_get_vsi_id_resp() processes a request and calls
chan_ops->send_ack(), this will eventually call back into nbl_chan_send_msg():
nbl_disp_chan_get_vsi_id_resp()
-> chan_ops->send_ack()
-> nbl_chan_send_ack()
-> nbl_chan_send_msg() [attempts to acquire txq_lock again]
Will this cause an immediate deadlock since the non-recursive txq_lock is
already held by the outer nbl_chan_send_msg() call?
[ ... ]
> @@ -71,9 +477,24 @@ int nbl_disp_init(struct nbl_adapter *adapter)
[ ... ]
> + if (common->has_ctrl)
> + nbl_disp_setup_ctrl_lvl(disp_mgt, NBL_DISP_CTRL_LVL_MGT);
> +
> + if (common->has_net)
> + nbl_disp_setup_ctrl_lvl(disp_mgt, NBL_DISP_CTRL_LVL_NET);
This appears to wire up the NBL_DISP_CTRL_LVL_NET branch, which contradicts the
commit message stating it is not yet wired.
> +
> + nbl_disp_setup_ctrl_lvl(disp_mgt, NBL_DISP_CTRL_LVL_ALWAYS);
> +
> + return ret;
> }
^ permalink raw reply
* Re: [PATCH v14 net-next 10/11] net/nebula-matrix: add common/ctrl dev init/reinit operation
From: Jakub Kicinski @ 2026-05-16 1:17 UTC (permalink / raw)
To: illusion.wang
Cc: Jakub Kicinski, dimon.zhao, alvin.wang, sam.chen, netdev,
andrew+netdev, corbet, horms, linux-doc, pabeni, vadim.fedorenko,
lukas.bulwahn, edumazet, enelsonmoore, skhan, hkallweit1,
linux-kernel
In-Reply-To: <20260513011649.4404-11-illusion.wang@nebula-matrix.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net/nebula-matrix: add common/ctrl dev init/reinit operation
This commit introduces common and control device setup and teardown routines
for the nebula-matrix network driver. It configures mailbox channels, queue
tasks, and MSI-X initialization.
> diff --git a/drivers/net/ethernet/nebula-matrix/nbl/nbl_core/nbl_dev.c b/drivers/net/ethernet/nebula-matrix/nbl/nbl_core/nbl_dev.c
> --- a/drivers/net/ethernet/nebula-matrix/nbl/nbl_core/nbl_dev.c
> +++ b/drivers/net/ethernet/nebula-matrix/nbl/nbl_core/nbl_dev.c
[ ... ]
> @@ -6,6 +6,159 @@
> #include <linux/pci.h>
> #include "nbl_dev.h"
[ ... ]
> +static int nbl_dev_setup_common_dev(struct nbl_adapter *adapter)
> +{
> + struct nbl_dev_mgt *dev_mgt = adapter->core.dev_mgt;
> + struct nbl_dispatch_ops *disp_ops = dev_mgt->disp_ops_tbl->ops;
> + struct nbl_dispatch_mgt *priv = dev_mgt->disp_ops_tbl->priv;
> + struct nbl_common_info *common = dev_mgt->common;
> + struct nbl_dev_common *common_dev;
> + int ret;
> +
> + common_dev = devm_kzalloc(&adapter->pdev->dev, sizeof(*common_dev),
> + GFP_KERNEL);
> + if (!common_dev)
> + return -ENOMEM;
> + common_dev->dev_mgt = dev_mgt;
> +
> + ret = nbl_dev_setup_chan_queue(dev_mgt, NBL_CHAN_TYPE_MAILBOX);
> + if (ret)
> + return ret;
> +
> + INIT_WORK(&common_dev->clean_mbx_task, nbl_dev_clean_mailbox_task);
> + common->vsi_id = disp_ops->get_vsi_id(priv, NBL_VSI_DATA);
> + if (common->vsi_id == U32_MAX)
> + return -ENOENT;
If disp_ops->get_vsi_id() or disp_ops->get_eth_id() fail below, does this
leak the mailbox channel queue?
Because dev_mgt->common_dev is not assigned until the very end of this
function, the standard cleanup routine nbl_dev_remove_common_dev() will
return early due to its NULL check. It seems the queue will not be destroyed
in these error paths.
> + ret = disp_ops->get_eth_id(priv, common->vsi_id, &common->eth_num,
> + &common->eth_id, &common->logic_eth_id);
> + if (ret)
> + return ret;
> + nbl_dev_register_chan_task(dev_mgt, NBL_CHAN_TYPE_MAILBOX,
> + &common_dev->clean_mbx_task);
> +
> + dev_mgt->common_dev = common_dev;
> + nbl_dev_init_msix_cnt(dev_mgt);
> +
> + return 0;
> +}
> +
> +static void nbl_dev_remove_common_dev(struct nbl_adapter *adapter)
> +{
> + struct nbl_dev_mgt *dev_mgt = adapter->core.dev_mgt;
> + struct nbl_dev_common *common_dev = dev_mgt->common_dev;
> +
> + if (!common_dev)
> + return;
> +
> + nbl_dev_remove_chan_queue(dev_mgt, NBL_CHAN_TYPE_MAILBOX);
Can this lead to a race condition and a potential use-after-free?
By tearing down the channel queue before unregistering the task, a pending
or running clean_mbx_task could execute on the destroyed queue.
Additionally, is a call to cancel_work_sync() needed here for the
clean_mbx_task? Since common_dev is allocated via devm_kzalloc, it will be
freed when the device detaches. If the work is still pending or running, it
might try to access the freed memory.
> + nbl_dev_register_chan_task(dev_mgt, NBL_CHAN_TYPE_MAILBOX, NULL);
> +}
[ ... ]
^ permalink raw reply
* Re: [PATCH v14 net-next 11/11] net/nebula-matrix: add common dev start/stop operation
From: Jakub Kicinski @ 2026-05-16 1:17 UTC (permalink / raw)
To: illusion.wang
Cc: Jakub Kicinski, dimon.zhao, alvin.wang, sam.chen, netdev,
andrew+netdev, corbet, horms, linux-doc, pabeni, vadim.fedorenko,
lukas.bulwahn, edumazet, enelsonmoore, skhan, hkallweit1,
linux-kernel
In-Reply-To: <20260513011649.4404-12-illusion.wang@nebula-matrix.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net/nebula-matrix: add common dev start/stop operation
This patch sets up common device start and stop operations. It configures the
MSI-X map table, allocates and enables MSI-X vectors, and registers the
mailbox ISR.
> diff --git a/drivers/net/ethernet/nebula-matrix/nbl/nbl_core/nbl_dev.c b/drivers/net/ethernet/nebula-matrix/nbl/nbl_core/nbl_dev.c
> index 9b7f4598fccc3..c7e632a16b40c 100644
> --- a/drivers/net/ethernet/nebula-matrix/nbl/nbl_core/nbl_dev.c
> +++ b/drivers/net/ethernet/nebula-matrix/nbl/nbl_core/nbl_dev.c
[ ... ]
> @@ -79,6 +259,14 @@ static void nbl_dev_clean_mailbox_task(struct work_struct *work)
> NBL_CHAN_TYPE_MAILBOX);
> }
>
> +static int nbl_dev_clean_mailbox_schedule(struct nbl_dev_mgt *dev_mgt)
> +{
> + struct nbl_dev_common *common_dev = dev_mgt->common_dev;
> +
> + nbl_common_queue_work(&common_dev->clean_mbx_task);
> + return 0;
> +}
> +
> /* ---------- Dev init process ---------- */
> static int nbl_dev_setup_common_dev(struct nbl_adapter *adapter)
> {
Looking at nbl_dev_setup_common_dev() in the same file:
nbl_dev_setup_common_dev() {
...
ret = nbl_dev_setup_chan_queue(dev_mgt, NBL_CHAN_TYPE_MAILBOX);
if (ret)
return ret;
INIT_WORK(&common_dev->clean_mbx_task, nbl_dev_clean_mailbox_task);
common->vsi_id = disp_ops->get_vsi_id(priv, NBL_VSI_DATA);
if (common->vsi_id == U32_MAX)
return -ENOENT;
...
}
If operations like disp_ops->get_vsi_id() or disp_ops->get_eth_id() fail,
the function returns the error directly. Could this leak the mailbox queue
resources allocated by nbl_dev_setup_chan_queue() on these initialization
error paths?
Since dev_mgt->common_dev is only assigned at the end of the setup function,
it appears the caller nbl_dev_init() cannot clean this up either.
[ ... ]
> @@ -220,9 +408,41 @@ void nbl_dev_remove(struct nbl_adapter *adapter)
> /* ---------- Dev start process ---------- */
> int nbl_dev_start(struct nbl_adapter *adapter)
> {
> + struct nbl_dev_mgt *dev_mgt = adapter->core.dev_mgt;
> + int ret;
> +
> + ret = nbl_dev_configure_msix_map(dev_mgt);
> + if (ret)
> + goto config_msix_map_err;
> +
> + ret = nbl_dev_init_interrupt_scheme(dev_mgt);
> + if (ret)
> + goto init_interrupt_scheme_err;
> + ret = nbl_dev_request_mailbox_irq(dev_mgt);
> + if (ret)
> + goto mailbox_request_irq_err;
> + ret = nbl_dev_enable_mailbox_irq(dev_mgt);
> + if (ret)
> + goto enable_mailbox_irq_err;
> +
> return 0;
> +enable_mailbox_irq_err:
> + nbl_dev_disable_mailbox_irq(dev_mgt);
> + nbl_dev_free_mailbox_irq(dev_mgt);
> +mailbox_request_irq_err:
> + nbl_dev_clear_interrupt_scheme(dev_mgt);
> +init_interrupt_scheme_err:
> + nbl_dev_destroy_msix_map(dev_mgt);
> +config_msix_map_err:
> + return ret;
> }
>
> void nbl_dev_stop(struct nbl_adapter *adapter)
> {
> + struct nbl_dev_mgt *dev_mgt = adapter->core.dev_mgt;
> +
> + nbl_dev_disable_mailbox_irq(dev_mgt);
> + nbl_dev_free_mailbox_irq(dev_mgt);
> + nbl_dev_clear_interrupt_scheme(dev_mgt);
> + nbl_dev_destroy_msix_map(dev_mgt);
> }
When nbl_dev_stop() is called, or when nbl_dev_start() takes the error path
after enabling the mailbox IRQ, the driver disables and frees the interrupt,
but does not cancel clean_mbx_task.
If an interrupt fires just before the IRQ is disabled, the work remains
queued on wq_mgt->ctrl_dev_wq and will execute asynchronously.
Could this lead to a memory access issue if devres frees the common_dev
memory when the device unbinds? Is it necessary to call cancel_work_sync()
here to ensure any pending work is flushed or cancelled before the structure
is destroyed?
^ permalink raw reply
* Re: [linux-next:master 3552/4394] htmldocs: Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst:1: WARNING: Title overline too short.
From: Randy Dunlap @ 2026-05-16 1:46 UTC (permalink / raw)
To: kernel test robot, Linlin Zhang; +Cc: oe-kbuild-all, Mikulas Patocka, linux-doc
In-Reply-To: <202605160214.wOV5aa0q-lkp@intel.com>
On 5/15/26 5:44 PM, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head: e98d21c170b01ddef366f023bbfcf6b31509fa83
> commit: b4a0774bd7fd859c1d243be0919c8df39eac20c0 [3552/4394] dm: add documentation for dm-inlinecrypt target
> compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
> docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
> reproduce: (https://download.01.org/0day-ci/archive/20260516/202605160214.wOV5aa0q-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202605160214.wOV5aa0q-lkp@intel.com/
>
> All warnings (new ones prefixed by >>):
>
>>> Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst:1: WARNING: Title overline too short.
> --
>>> Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst: WARNING: document isn't included in any toctree [toc.not_included]
>
>
> vim +1 Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst
>
> > 1 ========
> 2 dm-inlinecrypt
> 3 ========
Patch already available:
https://lore.kernel.org/linux-doc/20260512180409.1193504-1-rdunlap@infradead.org/
--
~Randy
^ permalink raw reply
* Documentation: fix typo in title for max31730
From: Hassan Maazu @ 2026-05-16 2:41 UTC (permalink / raw)
To: corbet@lwn.net; +Cc: linux-doc@vger.kernel.org, khan@linuxfoundation.org
Wrong device name used in title.
Signed-off-by: Hassan Maazu <maazudev@proton.me>
--- Documentation/hwmon/max31730.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/hwmon/max31730.rst b/Documentation/hwmon/max31730.rst
index 1c5a32b64187..0936ba2eac24 100644
--- a/Documentation/hwmon/max31730.rst
+++ b/Documentation/hwmon/max31730.rst
@@ -1,4 +1,4 @@
-Kernel driver max31790
+Kernel driver max31730
======================
Supported chips:
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v4 1/2] spi: add new_device/delete_device sysfs interface
From: Mark Brown @ 2026-05-16 2:44 UTC (permalink / raw)
To: Vishwaroop A
Cc: linux-spi, smangipudi, jonathanh, thierry.reding, corbet,
linux-doc
In-Reply-To: <20260511104002.976269-2-va@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]
On Mon, May 11, 2026 at 10:40:01AM +0000, Vishwaroop A wrote:
> +static ssize_t
> +new_device_store(struct device *dev, struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + /* Controller is dying; clean up if __unregister hasn't already */
> + if (device_is_registered(&spi->dev))
> + spi_unregister_device(spi);
This runs outside of userspace_clients_lock so there's a possibility
that if the controller is in the middle of unregistering (which is
likely since that's the case we're handling!) it might be running
device_for_each_child(&ctlr->dev, NULL, __unregister);
which would result in a double free.
> @@ -3633,8 +3813,35 @@ void spi_unregister_controller(struct spi_controller *ctlr)
> if (IS_ENABLED(CONFIG_SPI_DYNAMIC))
> mutex_lock(&ctlr->add_lock);
>
> + /*
> + * Mark dead and drain userspace_clients before __unregister,
> + * since spi_unregister_device() doesn't do list_del() itself.
> + */
> +#if IS_ENABLED(CONFIG_SPI_DYNAMIC)
> + mutex_lock(&ctlr->userspace_clients_lock);
> + ctlr->dead = true;
> + while (!list_empty(&ctlr->userspace_clients)) {
> + struct spi_device *spi;
> +
> + spi = list_first_entry(&ctlr->userspace_clients,
> + struct spi_device,
> + userspace_node);
> + list_del(&spi->userspace_node);
> + spi_unregister_device(spi);
> + }
> + mutex_unlock(&ctlr->userspace_clients_lock);
The spi_unregister_controller() side does things with the lock.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Documentation: fix typo in title for max31730
From: Randy Dunlap @ 2026-05-16 2:56 UTC (permalink / raw)
To: Hassan Maazu, corbet@lwn.net
Cc: linux-doc@vger.kernel.org, khan@linuxfoundation.org,
Guenter Roeck
In-Reply-To: <lC2hDaF-g523KA69MW_DVSRix9HHjA5drjH62zaO9eFNuOboR1cxxrTbqNJ8lmvuZ0u35qD4Ds8x0SeARtp5Hi-qIVpOi2zjYoV_vzCJjEM=@proton.me>
[adding Guenter]
On 5/15/26 7:41 PM, Hassan Maazu wrote:
> Wrong device name used in title.
>
> Signed-off-by: Hassan Maazu <maazudev@proton.me>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
>
> --- Documentation/hwmon/max31730.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/hwmon/max31730.rst b/Documentation/hwmon/max31730.rst
> index 1c5a32b64187..0936ba2eac24 100644
> --- a/Documentation/hwmon/max31730.rst
> +++ b/Documentation/hwmon/max31730.rst
> @@ -1,4 +1,4 @@
> -Kernel driver max31790
> +Kernel driver max31730
> ======================
>
> Supported chips:
> --
> 2.54.0
>
--
~Randy
^ permalink raw reply
* Re: [PATCH 1/2] module: add CONFIG_MODULE_RESTRICT_AUTOLOAD
From: Randy Dunlap @ 2026-05-16 3:03 UTC (permalink / raw)
To: Michal Gorlas, Jonathan Corbet, Shuah Khan, Luis Chamberlain,
Petr Pavlu, Daniel Gomez, Sami Tolvanen, Aaron Tomlin
Cc: linux-doc, linux-kernel, linux-modules
In-Reply-To: <20260515-autoload_restrict-v1-1-40b7c03ddd04@9elements.com>
On 5/15/26 10:20 AM, Michal Gorlas wrote:
> diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
> index 43b1bb01fd27..c9e01bb848c0 100644
> --- a/kernel/module/Kconfig
> +++ b/kernel/module/Kconfig
> @@ -337,6 +337,21 @@ config MODULE_SIG_HASH
>
> endif # MODULE_SIG || IMA_APPRAISE_MODSIG
>
> +config MODULE_RESTRICT_AUTOLOAD
> + bool "Restrict module auto-loading to privileged users"
> + default n
> + help
> + Restrict module auto-loading in response to use of some feature
> + implemented by an unloaded module to CAP_SYS_ADMIN. Enabling this
> + option helps reducing the attack surface where unprivileged users
helps reduce
or
helps to reduce
> + can abuse auto-loading to cause a vulnerable module to load that is
> + then exploited.
> +
> + Note that this option also prevents a benign use of auto-loading for
> + a non-root users. Thus if enabled, the root user should execute
> + modprobe manually if needed, or add the module to the list of modules
> + loaded at the boot by modifying init scripts.
--
~Randy
^ permalink raw reply
* htmldocs: Documentation/mm/page_owner.rst:70: WARNING: Literal block expected; none found. [docutils]
From: kernel test robot @ 2026-05-16 3:08 UTC (permalink / raw)
To: Zhen Ni; +Cc: oe-kbuild-all, 0day robot, linux-doc
tree: https://github.com/intel-lab-lkp/linux/commits/Zhen-Ni/mm-page_owner-add-print_mode-filter/20260515-225525
head: a6ca3c15fa7e6f6f22139da9699ecc02375c6942
commit: a6ca3c15fa7e6f6f22139da9699ecc02375c6942 mm/page_owner: document page_owner filter
date: 12 hours ago
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260516/202605160501.NQmx0x3R-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605160501.NQmx0x3R-lkp@intel.com/
All warnings (new ones prefixed by >>):
Non-Preserved Properties
======================== [docutils]
>> Documentation/mm/page_owner.rst:70: WARNING: Literal block expected; none found. [docutils]
Documentation/networking/skbuff:36: ./include/linux/skbuff.h:48: ERROR: Unexpected section title.
vim +70 Documentation/mm/page_owner.rst
69
> 70 To filter page_owner output::
71
72 cd tools/mm
73 make page_owner_filter
74
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] Documentation: hwmon: adt7411: document supported sysfs attributes
From: Chen-Shi-Hong @ 2026-05-16 3:52 UTC (permalink / raw)
To: linux; +Cc: corbet, skhan, linux-hwmon, linux-doc, linux-kernel,
Chen-Shi-Hong
The adt7411 driver exposes additional standard hwmon attributes beyond
the ones currently listed in Documentation/hwmon/adt7411.rst.
Document voltage min/max/alarm attributes, temperature min/max and
min_alarm/max_alarm attributes, and the temp2_fault attribute for the
external temperature channel.
Also update the documentation to clarify that analog inputs in1 and in2
are not available when the external temperature sensor is enabled, and
remove the outdated statement claiming that external temperature support
and limit registers are unsupported.
Signed-off-by: Chen-Shi-Hong <eric039eric@gmail.com>
---
Documentation/hwmon/adt7411.rst | 37 +++++++++++++++++++++++++++------
1 file changed, 31 insertions(+), 6 deletions(-)
diff --git a/Documentation/hwmon/adt7411.rst b/Documentation/hwmon/adt7411.rst
index 57ad16fb216a..28b6f3cb6b86 100644
--- a/Documentation/hwmon/adt7411.rst
+++ b/Documentation/hwmon/adt7411.rst
@@ -30,11 +30,36 @@ Check the datasheet for details.
sysfs-Interface
---------------
-================ =================
-in0_input vdd voltage input
-in[1-8]_input analog 1-8 input
-temp1_input temperature input
-================ =================
+================ =================================
+in0_input vdd voltage input
+in0_min vdd low limit
+in0_max vdd high limit
+in0_alarm vdd alarm
+in[1-8]_input analog 1-8 input
+in[1-8]_min analog input low limit
+in[1-8]_max analog input high limit
+in[1-8]_alarm analog input alarm
+temp1_input internal temperature input
+temp1_min internal temperature low limit
+temp1_max internal temperature high limit
+temp1_min_alarm internal temperature low alarm
+temp1_max_alarm internal temperature high alarm
+================ =================================
+
+If the external temperature sensor is enabled, the following attributes are
+also available:
+
+================ ================================================
+temp2_input external temperature input
+temp2_min external temperature low limit
+temp2_max external temperature high limit
+temp2_min_alarm external temperature low alarm
+temp2_max_alarm external temperature high alarm
+temp2_fault external temperature sensor fault
+================ ================================================
+
+If the external temperature sensor is enabled, analog inputs in1 and in2 are
+not available.
Besides standard interfaces, this driver adds (0 = off, 1 = on):
@@ -47,4 +72,4 @@ Besides standard interfaces, this driver adds (0 = off, 1 = on):
Notes
-----
-SPI, external temperature sensor and limit registers are not supported yet.
+SPI is not supported yet.
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v7 2/6] mm/memory-failure: surface unhandlable kernel pages as -ENOTRECOVERABLE
From: Lance Yang @ 2026-05-16 4:06 UTC (permalink / raw)
To: Breno Leitao
Cc: linmiaohe, akpm, david, ljs, vbabka, rppt, surenb, mhocko, shuah,
nao.horiguchi, rostedt, mhiramat, mathieu.desnoyers, corbet,
skhan, liam, linux-mm, linux-kernel, linux-doc, linux-kselftest,
linux-trace-kernel, kernel-team
In-Reply-To: <agcbfLHT5ZWnNeN0@gmail.com>
On 2026/5/15 21:13, Breno Leitao wrote:
[...]
>>
>> Wonder if it would be simpler to just do a positive check near the top
>> of get_any_page() instead. Something like:
>>
>> static bool hwpoison_unrecoverable_kernel_page(struct page *page,
>> unsigned long flags)
>
> Ack. We probably want to call it something like HWPoisonKernelOwned() to
> follow the same naming sematics of these helpers, such as HWPoisonHandlable()
>
> By the way, I will re-include the self test back to this patch series,
> In case they are not useful, we do not merge it.
>
Sounds good :)
Can you also test the relevant page types if possible, especially
the ones the new helper is supposed to classify?
Cheers, Lance
^ permalink raw reply
* [PATCH v4 0/4] Add MSI Claw HID Configuration Driver
From: Derek J. Clark @ 2026-05-16 4:28 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Pierre-Loup A . Griffais, Denis Benato, Zhouwang Huang,
Derek J . Clark, linux-input, linux-doc, linux-kernel
This series adds an HID Configuration driver for the MSI Claw line of
Handheld Gaming PC's. The MSI Claw HID interface provides multiple
features, such as the ability to switch between xinput, dinput, and a
desktop mode, RGB control, rumble intensity, and mapping of the rear "M"
keys. There are additional gamepad modes that are not included in this
driver as they appear to be used in assembly line testing or are
incomplete in the firmware. During my testing I found them to be unstable.
The initial version of this driver was written by Denis Benato, which
contained the initial reverse-engineering and implementation for the
gamepad mode switching. This work was later expanded by Zhouwang Huang
to include more gamepad modes and additional features. Finally, I
refactored the entire driver, fixed multiple bugs, and refined the overall
format to conform to kernel driver best practices and style guide.
Claude was used initially by Zhouwang Huang to quickly parse HID captures
during the reverse-engineering of some of the features. Since Claude had
already been used, as a test of its capabilities I had it implement the
rumble intensity attribute after I had already rewritten most of the
driver, which I then manually edited to fix some mistakes. I also used
Claude to review the driver and these patches for any mistakes and bugs.
Assisted-by: Claude:claude-sonnet-4-6
Co-developed-by: Denis Benato <denis.benato@linux.dev>
Signed-off-by: Denis Benato <denis.benato@linux.dev>
Co-developed-by: Zhouwang Huang <honjow311@gmail.com>
Signed-off-by: Zhouwang Huang <honjow311@gmail.com>
Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
---
v4:
- Add msi_suspend/claw_suspend.
- Reorder claw_remove to cancel all work before removing sysfs.
- Add mutex lock for removing sysfs attributes.
- Add mutex lock for MODE command data read/write.
- Change dev_warn to dev_dbg in claw_profile_event.
- use __free with DEFINE_FREE macro for argv instead of manually
running argv_free, cleaining up scoped_guard goto.
- Fix frame_calc validity check to use >=.
- Use spinlock instead of mutex in raw_event and related attribute
_store function.
- Ensure delayed work is canceled in suspend & canceled before sysfs
attribute removal.
v3: https://lore.kernel.org/linux-input/20260515033622.2095277-1-derekjohn.clark@gmail.com/
- Add mutex for read/write if rgb frame data.
- Ensure claw_hw_output_report is properly guarded.
- Remove setting rgb_frame_count when reading rgb profiles as it always
returns garbage data.
- Ensure rgb_speed is getting drvdata from a valid lookup (not hdev).
- Use scoped_guard where necessary.
- Reoder claw_probe to ensure all mutex, completion, and variable
assignments are in place prior to setting drvdata.
- Ensure gamepad_mode is set to a valid enum value in claw_probe.
v2: https://lore.kernel.org/linux-input/20260513231445.3213501-1-derekjohn.clark@gmail.com/
- Use mutexes to guard SYNC_TO_ROM calls and pending_profile calls.
- Rename driver to hid-msi and add generic entrypoints for
probe/resume/remove that call claw specific functions in order to
future proof the driver for other MSI HID interfaces.
- Fix various bugs and formatting issues.
v1: https://lore.kernel.org/linux-input/20260510043510.442807-1-derekjohn.clark@gmail.com/
Derek J. Clark (4):
HID: hid-msi: Add MSI Claw configuration driver
HID: hid-msi: Add M-key mapping attributes
HID: hid-msi: Add RGB control interface
HID: hid-msi: Add Rumble Intensity Attributes
MAINTAINERS | 6 +
drivers/hid/Kconfig | 12 +
drivers/hid/Makefile | 1 +
drivers/hid/hid-ids.h | 6 +
drivers/hid/hid-msi.c | 1708 +++++++++++++++++++++++++++++++++++++++++
5 files changed, 1733 insertions(+)
create mode 100644 drivers/hid/hid-msi.c
--
2.53.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox