kernel/git/next/linux-next.git/Documentation/netlink, branch master

Merge branch 'drm-next' of https://gitlab.freedesktop.org/drm/kernel.git

2026-09-11T12:53:57+00:00

# Conflicts: # drivers/gpu/drm/xe/xe_pagefault.c

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2026-09-10T22:14:05+00:00

Cross-merge networking fixes after downstream PR (net-7.3-rc3). Conflicts: drivers/net/dsa/mt7530.c 3c18e3c9a54e ("net: dsa: mt7530: populate lpi_interfaces to fix EEE support") 10d9d8328e8a ("net: dsa: mt7530: replace mt7530_read with regmap_read") Adjacent changes: drivers/net/bonding/bond_alb.c 1746ef2e2df2 ("bonding: use skb_cow_head() in bond_do_alb_xmit() and rlb_arp_xmit()") 4cef95f72bbd ("bonding: fix u32 overflow in compute_gap()") Signed-off-by: Jakub Kicinski

netlink: specs: dpll: pin-get has no dump filter

2026-09-09T20:52:51+00:00

The op doc promises "dump request with target dpll - list all the pins registered with a given dpll device" and "do request with target dpll and target pin". Neither exists. pin-get uses attribute-set: pin, so the id in both requests is DPLL_A_PIN_ID, not a device id; there is no reachable "target dpll" attribute at all (DPLL_A_PIN_PARENT_ID is in neither list). dpll_nl_pin_get_dumpit() does not look at the request, it walks dpll_pin_xa from ctx->idx and emits every registered, available pin, and there is no dump start callback to consume an id either. So the generated dpll_pin_get_dump() sends an id, gets the full list back and reports no error. Drop the id from the dump request and the two targeting claims from the doc. Present since commit 3badff3a25d8 ("dpll: spec: Add Netlink spec in YAML"). Same caveat as for pin-set: sending DPLL_A_PIN_ID in a pin-get dump now fails validation instead of being ignored. Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260904191023.3869690-4-kuba@kernel.org Signed-off-by: Jakub Kicinski

netlink: specs: dpll: drop the pin-set attributes nothing implements

2026-09-09T20:52:51+00:00

pin-set advertises top level direction, prio and state, so the generated policy accepts them and the generated user space API grows setters for them. dpll_pin_set_from_nlattr() has cases only for FREQUENCY, PHASE_ADJUST, PARENT_DEVICE, PARENT_PIN, ESYNC_FREQUENCY and REFERENCE_SYNC - the request succeeds, does nothing and produces no extack. The three values are only actionable inside the parent-device nest, where dpll_pin_parent_device_set() handles them next to DPLL_A_PIN_PARENT_ID, which is what makes them meaningful: a pin can be registered with more than one device. Never implemented - "git log -S 'case DPLL_A_PIN_PRIO'" on dpll_netlink.c comes up empty - the spec has advertised them since commit 3badff3a25d8 ("dpll: spec: Add Netlink spec in YAML"). Note that this does change what the kernel accepts: sending one of the three now fails validation instead of being ignored. Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260904191023.3869690-3-kuba@kernel.org Signed-off-by: Jakub Kicinski

netlink: specs: dpll: add clock-quality-level to the device-get reply

2026-09-09T20:52:51+00:00

dpll_device_get_one() calls dpll_msg_add_clock_quality_level(), which puts DPLL_A_CLOCK_QUALITY_LEVEL into every device-get reply, dump entry and device-*-ntf of a device whose driver implements clock_quality_level_get() - mlx5 does. The &dev-attrs anchor lists 12 attributes and not this one, so struct dpll_device_get_rsp has no field for it, dpll_device_get_rsp_parse() drops it and dpll.rst does not document it. The attribute itself is correctly declared in the dpll attribute set, only the reply list was missing an entry. Missing since commit a1afb959add1 ("dpll: add clock quality level attribute and op"). Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260904191023.3869690-2-kuba@kernel.org Signed-off-by: Jakub Kicinski

netlink: specs: handshake: do not accept the handler-class sentinel

2026-09-09T20:52:47+00:00

"max" is the exclusive upper bound of enum handshake_handler_class, not a class a handler can ask for, but the spec lists it as a plain entry. _init_checks() derives the policy limit from the highest entry, so the generated policy came out as NLA_POLICY_MAX(NLA_U32, 2) and handshake_nl_accept_doit() takes class 2 all the way into handshake_req_next(), which walks hn_requests under hn_lock before returning -EAGAIN instead of the -EINVAL a bad class deserves. render-max is how YNL spells this, and unlike a hand written limit it stays correct when a second handler class is added. It does change what HANDSHAKE_HANDLER_CLASS_MAX means - the highest valid class rather than one past it, as in every other Netlink/YNL family - with the count left as __HANDSHAKE_HANDLER_CLASS_MAX. The constant is uAPI, but I could not find any user space user, this constant seems to have been added for kernel's benefit. I think the risk of changing this is worth taking, having MAX with different semantics than the rest of Netlink is very confusing. Acked-by: Chuck Lever Reviewed-by: Asbjørn Sloth Tønnesen Link: https://patch.msgid.link/20260904190410.3864660-2-kuba@kernel.org Signed-off-by: Jakub Kicinski

netlink: specs: handshake: type the remaining key serials s32

2026-09-09T20:52:44+00:00

include/linux/key.h has "typedef int32_t key_serial_t" and commit 160f404495aa ("handshake: Fix sign of key_serial_t fields") converted x509.cert and x509.privkey to s32, but accept.peer-identity, accept.keyring and done.remote-auth were left as u32 - the same quantity typed both ways inside one family, and a generated user space struct with __s32 cert next to __u32 keyring. All three come from key_serial_t storage in net/handshake/tlshd.c (treq->th_peerid[], treq->th_keyring), and special keyrings are legitimately negative (KEY_SPEC_PROCESS_KEYRING is -2). NLA_U32 and NLA_S32 have the same length and no range check here, so the only wire effect is how the value is printed. Acked-by: Chuck Lever Reviewed-by: Asbjørn Sloth Tønnesen Link: https://patch.msgid.link/20260904190410.3864660-1-kuba@kernel.org Signed-off-by: Jakub Kicinski

netlink: specs: fou: link the type attribute to the encap-type enum

2026-09-08T10:56:34+00:00

The spec defines encap-type (unspec / direct / gue), but no attribute references it, so the definition exists only to emit FOU_ENCAP_* into the uAPI header - while FOU_ATTR_TYPE is exactly that value space: fou_create() switches on FOU_ENCAP_DIRECT / FOU_ENCAP_GUE and returns -EINVAL for anything else. Python YNL could not accept or display the names and the generated C exposed a raw __u8 setter. The global policy entry becomes NLA_POLICY_MAX(NLA_U8, 2). For add that only moves the existing fou_create() rejection earlier; del and get ignore FOU_ATTR_TYPE altogether, so a bogus type there now fails validation instead of being dropped on the floor. Signed-off-by: Jakub Kicinski Reviewed-by: Nicolas Dichtel Link: https://patch.msgid.link/20260904191412.3872344-4-kuba@kernel.org Signed-off-by: Paolo Abeni

netlink: specs: fou: local-v4 and peer-v4 are big endian

2026-09-08T10:56:34+00:00

fou_core.c uses nla_get_in_addr() / nla_put_in_addr() on both, i.e. they are __be32, and port / peer-port in the same spec are already annotated. Without byte-order YNL swaps them on little endian hosts. The generated policy goes from NLA_U32 to NLA_BE32, which changes nothing: lib/nlattr.c gives the two the same length in nla_attr_len[] and the same range handling, and neither attribute has a range check. Signed-off-by: Jakub Kicinski Reviewed-by: Nicolas Dichtel Link: https://patch.msgid.link/20260904191412.3872344-3-kuba@kernel.org Signed-off-by: Paolo Abeni

netlink: specs: fou: add af to the shared attribute list

2026-09-08T10:56:34+00:00

parse_nl_config() is the only place the address family is chosen: it defaults cfg->udp_config.family to AF_INET and only switches to AF_INET6 when FOU_ATTR_AF is present. The &all_attrs anchor - the add request, and the get do and dump reply - does not list af, so a ynl generated client has no fou_add_req_set_af() and can never create an IPv6 FOU port; the local-v6 / peer-v6 attributes it does list are read by nothing. On the reply side fou_fill_info() puts FOU_ATTR_AF unconditionally, and struct fou_get_rsp has no member for it. kernel-policy is global, so fou_nl_ops[] carries no per-op attribute list and af is already in fou_nl_policy through &select_attrs - only the user space codegen and the rendered docs change, ynl-regen.sh produces no diff. Signed-off-by: Jakub Kicinski Reviewed-by: Nicolas Dichtel Link: https://patch.msgid.link/20260904191412.3872344-2-kuba@kernel.org Signed-off-by: Paolo Abeni