linux-next.git/include/linux/mod_devicetable.h, branch master

mod_devicetable.h: Split into per subsystem headers

2026-07-03T05:37:43+00:00

is included transitively in nearly every driver in an x86_64 allmodconfig build of v7.1: $ find drivers -name \*.o -not -name \*.mod.o | wc -l 21330 $ find drivers -name \*.o.cmd -not -name \*.mod.o.cmd | xargs grep -l mod_devicetable.h | wc -l 17038 The result is that even when touching an obscure device id struct most of the kernel needs to be recompiled. Given that each driver typically only needs one or two of these structures, splitting into per subsystem headers and only including what is really needed reduces the amount of needed recompilation. Implement the first step and define each device id struct in a separate header (together with its associated #defines). is modified to include all the new headers to continue to provide the same symbols. Several headers currently include , those that are most lukrative to include only their subsystem headers only are: $ git -C source grep -l mod_devicetable.h include/linux | while read h; do echo -n "$h:"; find drivers -name \*.o.cmd -not -name \*.mod.o.cmd | xargs grep -l $h | wc -l; done | sort -t: -k2 -n -r | head include/linux/of.h:10897 include/linux/pci.h:7920 include/linux/acpi.h:7097 include/linux/i2c.h:5402 include/linux/spi/spi.h:1897 include/linux/dmi.h:1643 include/linux/usb.h:1222 include/linux/input.h:1205 include/linux/mdio.h:835 include/linux/phy.h:733 struct cpu_feature isn't really a device_id struct. That is kept in for now. Acked-by: Danilo Krummrich Acked-by: Takashi Sakamoto Acked-by: Geert Uytterhoeven # zorro Link: https://patch.msgid.link/41400e323be8640702b906d04327e833c5bdaf4a.1782808461.git.u.kleine-koenig@baylibre.com [Drop "MOD" from the header guards] Signed-off-by: Uwe Kleine-König (The Capable Hub)

firewire: Simplify storing pointers in device id struct

2026-05-11T10:45:02+00:00

Technically it is fine (on all current Linux architectures) to store a pointer in an unsigned long variable. However this needs explicit casting which is an easy source for type mismatches. By replacing the plain unsigned long .driver_data in struct ieee1394_device_id by an anonymous union, most of the casting can be dropped. There is still some implicit casting involved (between a void * and a driver specific pointer type), but that's better than the approach to store a pointer in an unsigned long variable as this doesn't lose the information that the data being pointed to is const. All users of struct ieee1394_device_id are initialized in a way that is compatible with the new definition, so no adaptions are needed there. (The comments addressing to CHERI extension are dropped by the maintainer.) Signed-off-by: Uwe Kleine-König (The Capable Hub) Link: https://lore.kernel.org/r/e5ba45a7e386461c0b1a5001635aa008b01c2164.1778494204.git.u.kleine-koenig@baylibre.com Signed-off-by: Takashi Sakamoto

x86/cpu: Add platform ID to CPU matching structure

2026-03-05T20:25:38+00:00

The existing x86_match_cpu() infrastructure can be used to match a bunch of attributes of a CPU: vendor, family, model, steppings and CPU features. But, there's one more attribute that's missing and unable to be matched against: the platform ID, enumerated on Intel CPUs in MSR_IA32_PLATFORM_ID. It is a little more obscure and is only queried during microcode loading. This is because Intel sometimes has CPUs with identical family/model/stepping but which need different microcode. These CPUs are differentiated with the platform ID. Add a field in 'struct x86_cpu_id' for the platform ID. Similar to the stepping field, make the new field a mask of platform IDs. Some examples: 0x01: matches only platform ID 0x0 0x02: matches only platform ID 0x1 0x03: matches platform IDs 0x0 or 0x1 0x80: matches only platform ID 0x7 0xff: matches all 8 possible platform IDs Since the mask is only a byte wide, it nestles in next to another u8 and does not even increase the size of 'struct x86_cpu_id'. Reserve the all 0's value as the wildcard (X86_PLATFORM_ANY). This avoids forcing changes to existing 'struct x86_cpu_id' users. They can just continue to fill the field with 0's and their matching will work exactly as before. Note: If someone is ever looking for space in 'struct x86_cpu_id', this new field could probably get stuck over in ->driver_data for the one user that there is. Signed-off-by: Dave Hansen Reviewed-by: Sohil Mehta Link: https://patch.msgid.link/20260304181022.058DF07C@davehans-spike.ostc.intel.com

net: phy: remove modalias-based mdio bus matching

2026-02-03T11:46:55+00:00

Last user dsa_loop has been migrated away from modalias-based matching, so we can remove this feature now. It was the only user of MDIO_NAME_SIZE, so remove also this constant. Signed-off-by: Heiner Kallweit Link: https://patch.msgid.link/ce1c6df0-4785-4b28-8322-32dc6bceea18@gmail.com Signed-off-by: Paolo Abeni

mod_devicetable: Bump auxiliary_device_id name size

2025-11-26T14:17:37+00:00

We have an upcoming driver named "intel_ehl_pse_io". This creates an auxiliary child device for it's GPIO sub-functionality, which matches against "intel_ehl_pse_io.gpio-elkhartlake" and overshoots the current maximum limit of 32 bytes for auxiliary device id string. Bump the size to 40 bytes to satisfy such cases. Suggested-by: Andy Shevchenko Signed-off-by: Raag Jadav Link: https://patch.msgid.link/20251106052838.433673-1-raag.jadav@intel.com Signed-off-by: Greg Kroah-Hartman

Merge tag 'usb-6.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

2025-06-06T19:45:35+00:00

Pull USB / Thunderbolt updates from Greg KH: "Here is the big set of USB and Thunderbolt changes for 6.16-rc1. Included in here are the following: - USB offload support for audio devices. I think this takes the record for the most number of patch series (30+) over the longest period of time (2+ years) to get merged properly. Many props go to Wesley Cheng for seeing this effort through, they took a major out-of-tree hacked-up-monstrosity that was created by multiple vendors for their specific devices, got it all merged into a semi-coherent set of changes, and got all of the different major subsystems to agree on how this should be implemented both with changes to their code as well as userspace apis, AND wrangled the hardware companies into agreeing to go forward with this, despite making them all redo work they had already done in their private device trees. This feature offers major power savings on embedded devices where a USB audio stream can continue to flow while the rest of the system is sleeping, something that devices running on battery power really care about. There are still some more small tweaks left to be done here, and those patches are still out for review and arguing among the different hardware companies, but this is a major step forward and a great example of how to do upstream development well. - small number of thunderbolt fixes and updates, things seem to be slowing down here (famous last words...) - xhci refactors and reworking to try to handle some rough corner cases in some hardware implementations where things don't always work properly - typec driver updates - USB3 power management reworking and updates - Removal of some old and orphaned UDC gadget drivers that had not been used in a very long time, dropping over 11 thousand lines from the tree, always a nice thing, making up for the 12k lines added for the USB offload feature. - lots of little updates and fixes in different drivers All of these have been in linux-next for over 2 weeks, the USB offload logic has been in there for 8 weeks now, with no reported issues" * tag 'usb-6.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (172 commits) ALSA: usb-audio: qcom: fix USB_XHCI dependency ASoC: qdsp6: fix compile-testing without CONFIG_OF usb: misc: onboard_usb_dev: fix build warning for CONFIG_USB_ONBOARD_DEV_USB5744=n usb: typec: tipd: fix typo in TPS_STATUS_HIGH_VOLAGE_WARNING macro USB: typec: fix const issue in typec_match() USB: gadget: udc: fix const issue in gadget_match_driver() USB: gadget: fix up const issue with struct usb_function_instance USB: serial: pl2303: add new chip PL2303GC-Q20 and PL2303GT-2AB USB: serial: bus: fix const issue in usb_serial_device_match() usb: usbtmc: Fix timeout value in get_stb usb: usbtmc: Fix read_stb function and get_stb ioctl ALSA: qc_audio_offload: try to reduce address space confusion ALSA: qc_audio_offload: avoid leaking xfer_buf allocation ALSA: qc_audio_offload: rename dma/iova/va/cpu/phys variables ALSA: usb-audio: qcom: Fix an error handling path in qc_usb_audio_probe() usb: misc: onboard_usb_dev: Fix usb5744 initialization sequence dt-bindings: usb: ti,usb8041: Add binding for TI USB8044 hub controller usb: misc: onboard_usb_dev: Add support for TI TUSB8044 hub usb: gadget: lpc32xx_udc: Use USB API functions rather than constants usb: gadget: epautoconf: Use USB API functions rather than constants ...

mod_devicetable: Enlarge the maximum platform_device_id name length

2025-04-28T17:32:43+00:00

The 20 byte length of struct platform_device_id::name is not long enough for many devices (especially regulators), where the string initialization is getting truncated and missing the trailing NUL byte. This is seen with GCC 15's -Wunterminated-string-initialization option: drivers/regulator/hi6421v530-regulator.c:189:19: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (21 chars into 20 available) [-Wunterminated-string-initialization] 189 | { .name = "hi6421v530-regulator" }, | ^~~~~~~~~~~~~~~~~~~~~~ drivers/regulator/hi6421v600-regulator.c:278:19: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (21 chars into 20 available) [-Wunterminated-string-initialization] 278 | { .name = "hi6421v600-regulator" }, | ^~~~~~~~~~~~~~~~~~~~~~ drivers/regulator/lp87565-regulator.c:233:11: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (21 chars into 20 available) [-Wunterminated-string-initialization] 233 | { "lp87565-q1-regulator", }, | ^~~~~~~~~~~~~~~~~~~~~~ sound/soc/fsl/imx-pcm-rpmsg.c:818:19: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (21 chars into 20 available) [-Wunterminated-string-initialization] 818 | { .name = "rpmsg-micfil-channel" }, | ^~~~~~~~~~~~~~~~~~~~~~ drivers/iio/light/hid-sensor-als.c:457:25: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (21 chars into 20 available) [-Wunterminated-string-initialization] 457 | .name = "HID-SENSOR-LISS-0041", | ^~~~~~~~~~~~~~~~~~~~~~ drivers/iio/light/hid-sensor-prox.c:366:25: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (21 chars into 20 available) [-Wunterminated-string-initialization] 366 | .name = "HID-SENSOR-LISS-0226", | ^~~~~~~~~~~~~~~~~~~~~~ Increase the length to 24, slightly more than is currently being used by the affected drivers. The string is used in '%s' format strings and via the module code, which appears to do its own length encoding. This size was chosen because there was already a 4 byte hole in the structure: struct platform_device_id { char name[20]; /* 0 20 */ /* XXX 4 bytes hole, try to pack */ kernel_ulong_t driver_data; /* 24 8 */ /* size: 32, cachelines: 1, members: 2 */ /* sum members: 28, holes: 1, sum holes: 4 */ /* last cacheline: 32 bytes */ }; Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20250415231420.work.066-kees@kernel.org Signed-off-by: Kees Cook

ALSA: Add USB audio device jack type

2025-04-11T11:02:30+00:00

Add an USB jack type, in order to support notifying of a valid USB audio device. Since USB audio devices can have a slew of different configurations that reach beyond the basic headset and headphone use cases, classify these devices differently. Reviewed-by: Pierre-Louis Bossart Signed-off-by: Wesley Cheng Acked-by: Mark Brown Link: https://lore.kernel.org/r/20250409194804.3773260-8-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman

x86/cpu: Add cpu_type to struct x86_cpu_id

2025-03-19T10:17:03+00:00

In addition to matching vendor/family/model/feature, for hybrid variants it is required to also match cpu-type. For example, some CPU vulnerabilities like RFDS only affect a specific cpu-type. To be able to also match CPUs based on their type, add a new field "type" to struct x86_cpu_id which is used by the CPU-matching tables. Introduce X86_CPU_TYPE_ANY for the cases that don't care about the cpu-type. [ bp: Massage commit message. ] Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Ingo Molnar Acked-by: Dave Hansen Link: https://lore.kernel.org/r/20250311-add-cpu-type-v8-3-e8514dcaaff2@linux.intel.com

x86/cpu: Expose only stepping min/max interface

2024-12-18T00:14:49+00:00

The x86_match_cpu() infrastructure can match CPU steppings. Since there are only 16 possible steppings, the matching infrastructure goes all out and stores the stepping match as a bitmap. That means it can match any possible steppings in a single list entry. Fun. But it exposes this bitmap to each of the X86_MATCH_*() helpers when none of them really need a bitmap. It makes up for this by exporting a helper (X86_STEPPINGS()) which converts a contiguous stepping range into the bitmap which every single user leverages. Instead of a bitmap, have the main helper for this sort of thing (X86_MATCH_VFM_STEPS()) just take a stepping range. This ends up actually being even more compact than before. Leave the helper in place (renamed to __X86_STEPPINGS()) to make it more clear what is going on instead of just having a random GENMASK() in the middle of an already complicated macro. One oddity that I hit was this macro: X86_MATCH_VFM_STEPS(vfm, X86_STEPPING_MIN, max_stepping, issues) It *could* have been converted over to take a min/max stepping value for each entry. But that would have been a bit too verbose and would prevent the one oddball in the list (INTEL_COMETLAKE_L stepping 0) from sticking out. Instead, just have it take a *maximum* stepping and imply that the match is from 0=>max_stepping. This is functional for all the cases now and also retains the nice property of having INTEL_COMETLAKE_L stepping 0 stick out like a sore thumb. skx_cpuids[] is goofy. It uses the stepping match but encodes all possible steppings. Just use a normal, non-stepping match helper. Suggested-by: Ingo Molnar Signed-off-by: Dave Hansen Link: https://lore.kernel.org/all/20241213185129.65527B2A%40davehans-spike.ostc.intel.com