linux-rng/include/linux/mod_devicetable.h, branch linus/master

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

2025-06-06T19:45:35Z

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:43Z

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:30Z

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:03Z

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:49Z

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

x86/cpu: Fix x86_match_cpu() to match just X86_VENDOR_INTEL

2024-05-22T09:31:10Z

Code in v6.9 arch/x86/kernel/smpboot.c was changed by commit 4db64279bc2b ("x86/cpu: Switch to new Intel CPU model defines") from: static const struct x86_cpu_id intel_cod_cpu[] = { X86_MATCH_INTEL_FAM6_MODEL(HASWELL_X, 0), /* COD */ X86_MATCH_INTEL_FAM6_MODEL(BROADWELL_X, 0), /* COD */ X86_MATCH_INTEL_FAM6_MODEL(ANY, 1), /* SNC */ <--- 443 {} }; static bool match_llc(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o) { const struct x86_cpu_id *id = x86_match_cpu(intel_cod_cpu); to: static const struct x86_cpu_id intel_cod_cpu[] = { X86_MATCH_VFM(INTEL_HASWELL_X, 0), /* COD */ X86_MATCH_VFM(INTEL_BROADWELL_X, 0), /* COD */ X86_MATCH_VFM(INTEL_ANY, 1), /* SNC */ {} }; static bool match_llc(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o) { const struct x86_cpu_id *id = x86_match_cpu(intel_cod_cpu); On an Intel CPU with SNC enabled this code previously matched the rule on line 443 to avoid printing messages about insane cache configuration. The new code did not match any rules. Expanding the macros for the intel_cod_cpu[] array shows that the old is equivalent to: static const struct x86_cpu_id intel_cod_cpu[] = { [0] = { .vendor = 0, .family = 6, .model = 0x3F, .steppings = 0, .feature = 0, .driver_data = 0 }, [1] = { .vendor = 0, .family = 6, .model = 0x4F, .steppings = 0, .feature = 0, .driver_data = 0 }, [2] = { .vendor = 0, .family = 6, .model = 0x00, .steppings = 0, .feature = 0, .driver_data = 1 }, [3] = { .vendor = 0, .family = 0, .model = 0x00, .steppings = 0, .feature = 0, .driver_data = 0 } } while the new code expands to: static const struct x86_cpu_id intel_cod_cpu[] = { [0] = { .vendor = 0, .family = 6, .model = 0x3F, .steppings = 0, .feature = 0, .driver_data = 0 }, [1] = { .vendor = 0, .family = 6, .model = 0x4F, .steppings = 0, .feature = 0, .driver_data = 0 }, [2] = { .vendor = 0, .family = 0, .model = 0x00, .steppings = 0, .feature = 0, .driver_data = 1 }, [3] = { .vendor = 0, .family = 0, .model = 0x00, .steppings = 0, .feature = 0, .driver_data = 0 } } Looking at the code for x86_match_cpu(): const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match) { const struct x86_cpu_id *m; struct cpuinfo_x86 *c = &boot_cpu_data; for (m = match; m->vendor | m->family | m->model | m->steppings | m->feature; m++) { ... } return NULL; it is clear that there was no match because the ANY entry in the table (array index 2) is now the loop termination condition (all of vendor, family, model, steppings, and feature are zero). So this code was working before because the "ANY" check was looking for any Intel CPU in family 6. But fails now because the family is a wild card. So the root cause is that x86_match_cpu() has never been able to match on a rule with just X86_VENDOR_INTEL and all other fields set to wildcards. Add a new flags field to struct x86_cpu_id that has a bit set to indicate that this entry in the array is valid. Update X86_MATCH*() macros to set that bit. Change the end-marker check in x86_match_cpu() to just check the flags field for this bit. Backporter notes: The commit in Fixes is really the one that is broken: you can't have m->vendor as part of the loop termination conditional in x86_match_cpu() because it can happen - as it has happened above - that that whole conditional is 0 albeit vendor == 0 is a valid case - X86_VENDOR_INTEL is 0. However, the only case where the above happens is the SNC check added by 4db64279bc2b1 so you only need this fix if you have backported that other commit 4db64279bc2b ("x86/cpu: Switch to new Intel CPU model defines") Fixes: 644e9cbbe3fc ("Add driver auto probing for x86 features v4") Suggested-by: Thomas Gleixner Suggested-by: Borislav Petkov Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov (AMD) Cc: # see above Link: https://lore.kernel.org/r/20240517144312.GBZkdtAOuJZCvxhFbJ@fat_crate.local

firmware: coreboot: Generate aliases for coreboot modules

2024-02-17T00:53:05Z

Generate aliases for coreboot modules to allow automatic module probing. Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Brian Norris Signed-off-by: Nícolas F. R. A. Prado Acked-by: Masahiro Yamada Link: https://lore.kernel.org/r/20240212-coreboot-mod-defconfig-v4-2-d14172676f6d@collabora.com Signed-off-by: Tzung-Bi Shih

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

2023-11-04T01:31:04Z

Pull staging driver updates from Greg KH: "Here is the big set of staging driver updates for 6.7-rc1. A bit bigger than 6.6 this time around, as it coincided with the Outreachy and mentorship application process, so we got a bunch of new developers sending in their first changes, which is nice to see. Also in here is a removal of the qlge ethernet driver, and the rtl8192u wireless driver. Both of these were very old and no one was maintaining them, the wireless driver removal was due to no one using it anymore, and no hardware to be found, and is part of a larger effort to remove unused and old wifi drivers from the system. The qlge ethernet driver did have one user pop up after it was dropped, and we are working with the network mainainers to figure out what tree it will come back in from and who will be responsible for it, and if it really is being used or not. Odds are it will show up in a network subsystem pull request after -rc1 is out, but we aren't sure yet. Other smaller changes in here are: - Lots of vc04_services work by Umang to clean up the mess created by the rpi developers long ago, bringing it almost into good enough shape to get out of staging, hopefully next major release, it's getting close. - rtl8192e variable cleanups and removal of unused code and structures - vme_user coding style cleanups - other small coding style cleanups to lots of the staging drivers - octeon typedef removals, and then last-minute revert when it was found to break the build in some configurations (it's a hard driver to build properly, none of the normal automated testing catches it.) All of these have been in linux-next for a while with no reported issues" * tag 'staging-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (256 commits) Revert "staging: octeon: remove typedef in enum cvmx_spi_mode_t" Revert "staging: octeon: remove typedef in enum cvmx_helper_interface_mode_t" Revert "staging: octeon: remove typedef in enum cvmx_pow_wait_t" Revert "staging: octeon: remove typedef in struct cvmx_pko_lock_t" Revert "staging: octeon: remove typedef in enum cvmx_pko_status_t" Revert "staging: octeon: remove typedef in structs cvmx_pip_port_status_t and cvmx_pko_port_status_t" staging: vt6655: Type encoding info dropped from variable name "byRxRate" staging: vt6655: Type encoding info dropped from function name "CARDbUpdateTSF" staging: vt6655: Type encoding info dropped from function name "CARDvSetRSPINF" staging: vt6655: Type encoding info dropped from function name "CARDbyGetPktType" staging: vt6655: Type encoding info dropped from variable name "byPacketType" staging: vt6655: Type encoding info dropped from function name "CARDbSetPhyParameter" staging: vt6655: Type encoding info dropped from variable name "pbyRsvTime" staging: vt6655: Type encoding info dropped from variable name "pbyTxRate" staging: vt6655: Type encoding info dropped from function name "s_vCalculateOFDMRParameter" staging: vt6655: Type encoding info dropped from array name "cwRXBCNTSFOff" staging: fbtft: Convert to platform remove callback returning void staging: olpc_dcon: Remove I2C_CLASS_DDC support staging: vc04_services: use snprintf instead of sprintf staging: rtl8192e: Fix line break issue at priv->rx_buf[priv->rx_idx] ...

cdx: add sysfs for subsystem, class and revision

2023-10-27T11:23:24Z

CDX controller provides subsystem vendor, subsystem device, class and revision info of the device along with vendor and device ID in native endian format. CDX Bus system uses this information to bind the cdx device to the cdx device driver. Co-developed-by: Puneet Gupta Signed-off-by: Puneet Gupta Co-developed-by: Nipun Gupta Signed-off-by: Nipun Gupta Signed-off-by: Abhijit Gangurde Reviewed-by: Pieter Jansen van Vuuren Tested-by: Nikhil Agarwal Link: https://lore.kernel.org/r/20231017160505.10640-8-abhijit.gangurde@amd.com Signed-off-by: Greg Kroah-Hartman

staging: vc04_services: Support module autoloading using MODULE_DEVICE_TABLE

2023-10-21T09:56:26Z

VC04 has now a independent bus vchiq_bus to register its devices. However, the module auto-loading for bcm2835-audio and bcm2835-camera currently happens through MODULE_ALIAS() macro specified explicitly. The correct way to auto-load a module, is when the alias is picked out from MODULE_DEVICE_TABLE(). In order to get there, we need to introduce vchiq_device_id and add relevant entries in file2alias.c infrastructure so that aliases can be generated. This patch targets adding vchiq_device_id and do_vchiq_entry, in order to generate those alias using the /script/mod/file2alias.c. Going forward the MODULE_ALIAS() from bcm2835-camera and bcm2835-audio will be dropped, in favour of MODULE_DEVICE_TABLE being used there. The alias format for vchiq_bus devices will be "vchiq:". Adjust the vchiq_bus_uevent() to reflect that. Signed-off-by: Umang Jain Reviewed-by: Laurent Pinchart Reviewed-by: Kieran Bingham Link: https://lore.kernel.org/r/20231019090128.430297-2-umang.jain@ideasonboard.com Signed-off-by: Greg Kroah-Hartman