Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v7.0-rc7 2026-02-22T04:03:00+00:00 2026-02-22T04:03:00+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-02-22T04:03:00+00:00 urn:sha1:32a92f8c89326985e05dce8b22d3f0aa07a3e1bd This converts some of the visually simpler cases that have been split over multiple lines. I only did the ones that are easy to verify the resulting diff by having just that final GFP_KERNEL argument on the next line. Somebody should probably do a proper coccinelle script for this, but for me the trivial script actually resulted in an assertion failure in the middle of the script. I probably had made it a bit _too_ trivial. So after fighting that far a while I decided to just do some of the syntactically simpler cases with variations of the previous 'sed' scripts. The more syntactically complex multi-line cases would mostly really want whitespace cleanup anyway. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2026-02-22T01:09:51+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-02-22T01:06:51+00:00 urn:sha1:323bbfcf1ef8836d0d2ad9e2c1f1c684f0e3b5b3 This is the exact same thing as the 'alloc_obj()' version, only much smaller because there are a lot fewer users of the *alloc_flex() interface. As with alloc_obj() version, this was done entirely with mindless brute force, using the same script, except using 'flex' in the pattern rather than 'objs*'. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2026-02-22T01:09:51+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-02-22T00:37:42+00:00 urn:sha1:bf4afc53b77aeaa48b5409da5c8da6bb4eff7f43 This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2026-02-21T09:02:28+00:00 Kees Cook kees@kernel.org 2026-02-21T07:49:23+00:00 urn:sha1:69050f8d6d075dc01af7a5f2f550a8067510366f This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook <kees@kernel.org> 2026-02-17T17:36:43+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-02-17T17:36:43+00:00 urn:sha1:17f8d2009367c3da82882f70ccbdca9f8c7b5f20 Pull USB / Thunderbolt updates from Greg KH: "Here is the "big" set of USB and Thunderbolt driver updates for 7.0-rc1. Overall more lines were removed than added, thanks to dropping the obsolete isp1362 USB host controller driver, always a nice change. Other than that, nothing major happening here, highlights are: - lots of dwc3 driver updates and new hardware support added - usb gadget function driver updates - usb phy driver updates - typec driver updates and additions - USB rust binding updates for syntax and formatting changes - more usb serial device ids added - other smaller USB core and driver updates and additions All of these have been in linux-next for a long time, with no reported problems" * tag 'usb-7.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (77 commits) usb: typec: ucsi: Add Thunderbolt alternate mode support usb: typec: hd3ss3220: Check if regulator needs to be switched usb: phy: tegra: parametrize PORTSC1 register offset usb: phy: tegra: parametrize HSIC PTS value usb: phy: tegra: return error value from utmi_wait_register usb: phy: tegra: cosmetic fixes dt-bindings: usb: renesas,usbhs: Add RZ/G3E SoC support usb: dwc2: fix resume failure if dr_mode is host usb: cdns3: fix role switching during resume usb: dwc3: gadget: Move vbus draw to workqueue context USB: serial: option: add Telit FN920C04 RNDIS compositions usb: dwc3: Log dwc3 address in traces usb: gadget: tegra-xudc: Add handling for BLCG_COREPLL_PWRDN usb: phy: tegra: add HSIC support usb: phy: tegra: use phy type directly usb: typec: ucsi: Enforce mode selection for cros_ec_ucsi usb: typec: ucsi: Support mode selection to activate altmodes usb: typec: Introduce mode_selection bit usb: typec: Implement mode selection usb: typec: Expose alternate mode priority via sysfs ... 2026-02-11T17:19:47+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-02-11T17:19:47+00:00 urn:sha1:be653d2d1f435218cf4b7abad96b42a20ce28451 Pull chrome platform updates from Tzung-Bi Shih: "New cros_ec_lightbar features: - Report the number of exposed LED segments via sysfs - Support large sequence of program to be transmitted Fixes: - Don't touch fwnode_handle::dev which is a private field - Fix wrong assignment for response size in cros_ec_lightbar Cleanups: - Use acpi_get_local_u64_address() helper" * tag 'chrome-platform-v7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: platform/chrome: lightbar: Use flexible array member platform/chrome: lightbar: Fix lightbar_program_ex alignment platform/chrome: lightbar: Add support for large sequence platform/chrome: lightbar: Report number of segments platform/chrome: cros_ec_lightbar: Fix response size initialization platform/chrome: cros_typec_switch: Use acpi_get_local_u64_address() platform/chrome: cros_typec_switch: Don't touch struct fwnode_handle::dev 2026-01-30T08:30:01+00:00 Gwendal Grignou gwendal@chromium.org 2026-01-30T08:13:51+00:00 urn:sha1:9600b8bdbfe48bb51865be743450160577d2bae2 Current sequences are limited to 192 bytes. Increase support to whatever the EC support. If the sequence is too long, the EC will return an OVERFLOW error. Test: Check sending a large sequence is received by the EC. Signed-off-by: Gwendal Grignou <gwendal@google.com> Link: https://lore.kernel.org/r/20260130081351.487517-2-gwendal@google.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> 2026-01-30T08:29:52+00:00 Gwendal Grignou gwendal@chromium.org 2026-01-30T08:13:50+00:00 urn:sha1:2d8251d98ce0be96d79aec708aa70cab2b4f6f17 Add attribue `num_segments` to return the number of exposed LED segments in the lightbar. It can be smaller than the number of physical leds in the lightbar. Test: Check the attribute is present and returns a value when read. Signed-off-by: Gwendal Grignou <gwendal@google.com> Link: https://lore.kernel.org/r/20260130081351.487517-1-gwendal@google.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> 2026-01-30T07:56:08+00:00 Tzung-Bi Shih tzungbi@kernel.org 2026-01-30T04:03:35+00:00 urn:sha1:ec0dd36dbf8b0b209e63d0cd795451fa2203c736 Commit 1e7913ff5f9f ("platform/chrome: cros_ec_lightbar: Reduce ligthbar get version command") meant to set smaller values for both request and response sizes. However, it incorrectly assigned the response size to the `result` field instead of `insize`. Fix it. Reported-by: Gwendal Grignou <gwendal@google.com> Closes: https://lore.kernel.org/chrome-platform/CAMHSBOVrrYaB=1nEqZk09VkczCrj=6B-P8Fe29TpPdSDgT2CCQ@mail.gmail.com Fixes: 1e7913ff5f9f ("platform/chrome: cros_ec_lightbar: Reduce ligthbar get version command") Link: https://lore.kernel.org/r/20260130040335.361997-1-tzungbi@kernel.org Reviewed-by: Gwendal Grignou <gwendal@google.com> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> 2026-01-23T16:18:01+00:00 Andrei Kuchynski akuchynski@chromium.org 2026-01-19T13:18:19+00:00 urn:sha1:4ec128733f68f77af452b0d97d8688cd33cd963e This flag specifies that the Embedded Controller (EC) must receive explicit approval from the Application Processor (AP) before initiating Type-C alternate modes or USB4 mode. Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Benson Leung <bleung@chromium.org> Link: https://patch.msgid.link/20260119131824.2529334-3-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>