summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-09-14net: stmmac: move timestamping/ptp init to stmmac_hw_setup() callerRussell King (Oracle)
Move the call to stmmac_init_timestamping() or stmmac_setup_ptp() out of stmmac_hw_setup() to its caller after stmmac_hw_setup() has successfully completed. This slightly changes the ordering during setup, but should be safe to do. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: stmmac: move PTP support check into stmmac_init_timestamping()Russell King (Oracle)
Move the PTP support check from stmmac_init_tstamp_counter() into stmmac_init_timestamping() as it makes more sense to be there. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: stmmac: add stmmac_setup_ptp()Russell King (Oracle)
Add a function to setup PTP, which will enable the clock, initialise the timestamping, and register with the PTP clock subsystem. Call this when we want to register the PTP clock in stmmac_hw_setup(), otherwise just call the Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: stmmac: rename stmmac_init_ptp()Russell King (Oracle)
Changes to the stmmac driver to fix various issues with PTP have made stmmac_init_ptp() less about initialising the entire PTP block, and now primarily deals with the packet timestamping support. The exception to this is ptp_clk_freq_config(), which is an odditiy. It remains as stmmac_init_ptp() is used both at .ndo_open() time and in the resume paths. However, restructuring this code to make it more easily readable makes the continued use of "init_ptp" confusing. In preparation to cleaning up the (re-)initialisation of timestamping, rename the existing stmmac_init_ptp() to stmmac_init_timestamping() which better reflects its functionality. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: stmmac: move stmmac_init_ptp() messages into functionRussell King (Oracle)
Move the stmmac_init_ptp() messages from stmmac_hw_setup() to stmmac_init_ptp(), which will allow further cleanups. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: stmmac: add __stmmac_release() to complement __stmmac_open()Russell King (Oracle)
Rename stmmac_release() to __stmmac_release(), providing a new stmmac_release() method. Update stmmac_change_mtu() to use __stmmac_release(). Move the runtime PM handling into stmmac_open() and stmmac_release(). This avoids stmmac_change_mtu() needlessly fiddling with the runtime PM state, and will allow future changes to remove code from __stmmac_open() and __stmmac_release() that should only happen when the net device is administratively brought up or down. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: stmmac: unexport stmmac_init_tstamp_counter()Russell King (Oracle)
Nothing outside of stmmac_main.c makes use of stmmac_init_tstamp_counter(), so there's no point exporting it for modules, or even having it non-static. Remove the export and make it static. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: stmmac: fix stmmac_xdp_open() clk_ptp_ref error cleanupRussell King (Oracle)
Neither stmmac_xdp_release() nor the normal paths of stmmac_xdp_open() touch clk_ptp_ref, so stmmac_xdp_open() should not be doing anything with this clock. However, in its error path, it calls stmmac_hw_teardown() which disables and unprepares this clock, which can lead to the clock state becoming unbalanced when the netdev is taken administratively down. Remove this call to stmmac_hw_teardown(), and as this is the last user of this function, remove the function as well. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: stmmac: fix PTP error cleanup in __stmmac_open()Russell King (Oracle)
The cleanup function for stmmac_setup_ptp() is stmmac_release_ptp() which entirely undoes the effects of stmmac_setup_ptp() by unregistering the PTP device and then stopping the PTP clock, whereas stmmac_hw_teardown() will only stop the PTP clock while leaving the PTP device registered. This can lead to a kernel oops - if __stmmac_open() fails after registering the PTP clock, the PTP device will remain registered, and if the module is removed, subsequent PTP device accesses will lead to a kernel oops. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: stmmac: disable PTP clock after unregistering PTPRussell King (Oracle)
Follow the principle of unpublish from userspace and then teardown resources. Disable the PTP clock only after unregistering with the PTP subsystem, which ensures that we only stop the clock that ticks the timesource after we have removed the PTP device. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: stmmac: ptp: improve handling of aux_ts_lock lifetimeRussell King (Oracle)
The aux_ts_lock mutex is only required while the PTP clock has been successfully registered. stmmac_ptp_register() does not return any errors (as we don't wish to prevent the netdev being opened if PTP fails), stmmac_ptp_unregister() was coded to allow it to be called irrespective of whether PTP was successfully registered or not. Arrange for the aux_ts_lock mutex to be destroyed if the PTP clock is not functional during stmmac_ptp_register(), and only destroy it in stmmac_ptp_unregister() if we had a PTP clock registered. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: dsa: mv88e6xxx: remove unused support for PPS event captureRussell King (Oracle)
mv88e6352_config_eventcap() is documented as handling both EXTTS and PPS capture modes, but nothing ever calls it for PPS capture. Remove the unused PPS capture mode support, and the now unused MV88E6XXX_TAI_EVENT_STATUS_CAP_TRIG definition. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uwep9-00000004ikJ-2FeF@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: dsa: mv88e6xxx: remove chip->evcap_configRussell King (Oracle)
evcap_config is only read and written in mv88e6352_config_eventcap(), so it makes little sense to store it in the global chip struct. Make it a local variable instead. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uwep4-00000004ikD-1ZEh@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: dsa: mv88e6xxx: remove chip->trig_configRussell King (Oracle)
chip->trig_config is never written, and thus takes the value zero. Remove this struct member and its single reader. Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uweoz-00000004ik7-13Fl@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: dsa: mv88e6xxx: remove mv88e6250_ptp_opsRussell King (Oracle)
mv88e6250_ptp_ops and mv88e6352_ptp_ops are identical since commit 7e3c18097a70 ("net: dsa: mv88e6xxx: read cycle counter period from hardware"). Remove the unnecessary duplication. Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uweou-00000004ik1-0aiX@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: mana: Reduce waiting time if HWC not respondingHaiyang Zhang
If HW Channel (HWC) is not responding, reduce the waiting time, so further steps will fail quickly. This will prevent getting stuck for a long time (30 minutes or more), for example, during unloading while HWC is not responding. Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Link: https://patch.msgid.link/1757537841-5063-1-git-send-email-haiyangz@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: stmmac: dwmac-renesas-gbeth: Add support for RZ/T2H SoCLad Prabhakar
Extend the Renesas GBETH stmmac glue driver to support the RZ/T2H SoC, where the GMAC is connected through a MIIC PCS. Introduce a new `has_pcs` flag in `struct renesas_gbeth_of_data` to indicate when PCS handling is required. When enabled, the driver parses the `pcs-handle` phandle, creates a PCS instance with `miic_create()`, and wires it into phylink. Proper cleanup is done with `miic_destroy()`. New init/exit/select hooks are added to `plat_stmmacenet_data` for PCS integration. Update Kconfig to select `PCS_RZN1_MIIC` when building the Renesas GBETH driver so the PCS support is always available. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://patch.msgid.link/20250908105901.3198975-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14net: stmmac: dwmac-renesas-gbeth: Use OF data for configurationLad Prabhakar
Prepare for adding RZ/T2H SoC support by making the driver configuration selectable via OF match data. While the RZ/V2H(P) and RZ/T2H use the same version of the Synopsys DesignWare MAC (version 5.20), the hardware is synthesized with different options. To accommodate these differences, introduce a struct holding per-SoC configuration such as clock list, number of clocks, TX clock rate control, and STMMAC flags, and retrieve it from the device tree match entry during probe. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://patch.msgid.link/20250908105901.3198975-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-14Merge tag 'tty-6.17-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial fixes from Greg KH: "Here are some small tty and serial driver fixes for 6.17-rc6 that resolve some reported problems. Included in here are: - 8250 driver dt bindings fixes - broadcom serial driver binding fixes - hvc_console bugfix - xilinx serial driver bugfix - sc16is7xx serial driver bugfix All of these have been in linux-next for the past week with no reported issues" * tag 'tty-6.17-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: serial: xilinx_uartps: read reg size from DTS tty: hvc_console: Call hvc_kick in hvc_write unconditionally dt-bindings: serial: 8250: allow "main" and "uart" as clock names dt-bindings: serial: 8250: move a constraint dt-bindings: serial: brcm,bcm7271-uart: Constrain clocks serial: sc16is7xx: fix bug in flow control levels init
2025-09-14Merge tag 'usb-6.17-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB fixes from Greg KH: "Here are some small USB driver fixes and new device ids for 6.17-rc6. Included in here are: - new usb-serial driver device ids - dummy-hcd locking bugfix for rt-enabled systems (which is crazy, but people have odd testing requirements at times...) - xhci driver bugfixes for reported issues - typec driver bugfix - midi2 gadget driver bugfixes - usb core sysfs file regression fix from -rc1 All of these, except for the last usb sysfs file fix, have been in linux-next with no reported issues. The sysfs fix was added to the tree on Friday, and is "obviously correct" and should not have any problems either, it just didn't have any time for linux-next to pick up (0-day had no problems with it)" * tag 'usb-6.17-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: USB: core: remove the move buf action usb: gadget: midi2: Fix MIDI2 IN EP max packet size usb: gadget: midi2: Fix missing UMP group attributes initialization usb: typec: tcpm: properly deliver cable vdms to altmode drivers USB: gadget: dummy-hcd: Fix locking bug in RT-enabled kernels xhci: fix memory leak regression when freeing xhci vdev devices depth first xhci: dbc: Fix full DbC transfer ring after several reconnects xhci: dbc: decouple endpoint allocation from initialization USB: serial: option: add Telit Cinterion LE910C4-WWX new compositions USB: serial: option: add Telit Cinterion FN990A w/audio compositions
2025-09-14Merge tag 'input-for-v6.17-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input fixes from Dmitry Torokhov: - a quirk to i8042 for yet another TUXEDO laptop - a fix to mtk-pmic-keys driver to properly handle MT6359 - a fix to iqs7222 driver to only enable proximity interrupt if it is mapped to a key or a switch event - an update to xpad controller driver to recognize Flydigi Apex 5 controller - an update to maintainers file to drop bounding entry for Melfas touch controller * tag 'input-for-v6.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: MAINTAINERS: Input: Drop melfas-mip4 section Input: mtk-pmic-keys - MT6359 has a specific release irq Input: i8042 - add TUXEDO InfinityBook Pro Gen10 AMD to i8042 quirk table Input: iqs7222 - avoid enabling unused interrupts Input: xpad - add support for Flydigi Apex 5
2025-09-14staging: sm750fb: rename camel case variableAhmet Sezgin Duran
Rename regValue to reg_value to follow kernel coding style. Signed-off-by: Ahmet Sezgin Duran <ahmet@sezginduran.net> Link: https://lore.kernel.org/r/20250912162627.95010-1-ahmet@sezginduran.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14staging: rtl8723bs: hal: put return type and function name on one lineAkiyoshi Kurita
Make the function definition of phy_StoreTxPowerByRateBase() follow the kernel coding style by placing the return type and function name on a single line. No functional change. Signed-off-by: Akiyoshi Kurita <weibu@redadmin.org> Link: https://lore.kernel.org/r/20250912162613.776769-1-weibu@redadmin.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Handle mode transitions for CD321xHector Martin
On Apple Silicon machines there is no control over which alt mode is chosen. The CD321x' firmware negotiates the target mode on its own and only lets the main CPU know after the mode has already been chosen. Especially after plugging a new cable in this can result to quick mode changes from e.g. power only -> USB3 only -> USB3+DisplayPort in a short time. It is not possile to influence this in any way and we also do not get direct access to the PDOs or VDOs exchanged via USB PD. Additionally, mode changes must be tightly synchronized between DWC3 and the Type C PHY and most mode changes require a full reset of DWC3 to make the port work correctly. This is all done synchronously from the role switch handler inside the DWC3 glue driver on these machines to avoid tripping any failsafes or watchdogs inside the Type-C PHY that may, in the worst case, reset the entire SoC. To be able to control all this we trigger the entire process in the correct order directly from the TIPD driver and de-bounce any mode changes to avoid tearing down and re-setting DWC3 back up multiple times any time a new connection is made. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Co-developed-by: Sven Peter <sven@kernel.org> Signed-off-by: Sven Peter <sven@kernel.org> Reviewed-by: Janne Grunau <j@jannau.net> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-11-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Read data status in probe and cache its valueHector Martin
Just like for power status we also need to keep track of data status to be able to detect mode changes once we introduce de-bouncing for CD321x. Read it during probe and keep a cached copy of its value. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-10-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Use read_power_status function in probeHector Martin
We need the initial power status to be able to reliably detect connector changes once we introduce de-bouncing for CD321x next. read_power_status takes care of this and also forwards the status to the trace subsystem so let's use that instead of open-coding it inside probe. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-9-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Update partner identity when power status was updatedHector Martin
Whenever the power status is changed make sure to also update the partner identity to be able to detect changes once de-bouncing and mode changes are added for CD321x. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-8-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Register DisplayPort and Thunderbolt altmodes for cd321xSven Peter
Ports equipped with a CD321x are only found on Apple Silicon machines and always support DisplayPort, Thunderbolt and USB4. Register these port modes unconditionally. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-7-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Read USB4, Thunderbolt and DisplayPort status for cd321xSven Peter
CD321x supports various alternate modes and stores information once these are entered into separate status registers. Read those when they are active when reading TPS_DATA_STATUS to prepare supporting these. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-6-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Add cd321x struct with separate sizeSven Peter
We're about to add more fields to struct tps6598x which are only relevant for Apple's CD321x and to ensure that we don't waste memory everywhere for those add a separate struct for cd321x and prepare to allocate more space inside probe. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-5-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Trace data status for CD321x correctlySven Peter
Some bits inside the CD321x TPS_DATA_STATUS register have a different function compared to the original tipd chip. Add these and introduce a separate trace function to show them correctly. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-4-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Move switch_power_state to tipd_dataSven Peter
When support for CD321x was originally added no other hardware variant was supported and there was no need for struct tipd_data. Now that it exists move the special case in there so that we can drop the of_device_is_compatible_check entirely. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-3-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Move initial irq mask to tipd_dataSven Peter
Since the irq mask was originally added more tipd variants have been introduced and there's now struct tipd_data. Move the initial mask in there. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-2-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14usb: typec: tipd: Clear interrupts firstSven Peter
Right now the interrupt handler first reads all updated status registers and only then clears the interrupts. It's possible that a duplicate interrupt for a changed register or plug state comes in after the interrupts have been processed but before they have been cleared: * plug is inserted, TPS_REG_INT_PLUG_EVENT is set * TPS_REG_INT_EVENT1 is read * tps6598x_handle_plug_event() has run and registered the plug * plug is removed again, TPS_REG_INT_PLUG_EVENT is set (again) * TPS_REG_INT_CLEAR1 is written, TPS_REG_INT_PLUG_EVENT is cleared We then have no plug connected and no pending interrupt but the tipd core still thinks there is a plug. It's possible to trigger this with e.g. a slightly broken Type-C to USB A converter. Fix this by first clearing the interrupts and only then reading the updated registers. Fixes: 45188f27b3d0 ("usb: typec: tipd: Add support for Apple CD321X") Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers") Cc: stable@kernel.org Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-1-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-14clk: tegra: dfll: Add CVB tables for Tegra114Svyatoslav Ryhel
Extend the Tegra124 DFLL driver to include configuration settings required for Tegra114 compatibility. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com> [treding@nvidia.com: Use TEGRA210 instead of T210] Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-09-14Input: cros_ec_keyb - Defer probe until parent EC device is registeredTzung-Bi Shih
The `cros_ec_keyb` driver can be probed before the cros_ec_device has completed the registration. This creates a race condition where `cros_ec_keyb` might access uninitialized data. Fix this by calling `cros_ec_device_registered()` to check the parent's status. If the device is not yet ready, return -EPROBE_DEFER to ensure the probe is retried later. Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20250828083601.856083-6-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2025-09-14platform/chrome: cros_ec: Add a flag to track registration stateTzung-Bi Shih
Introduce a `registered` flag to the `struct cros_ec_device` to allow callers to determine if the device has been fully registered and is ready for use. This is a preparatory step to prevent race conditions where other drivers might try to access the device before it is fully registered or after it has been unregistered. Link: https://lore.kernel.org/r/20250828083601.856083-5-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2025-09-14platform/chrome: cros_ec: Separate initialization from cros_ec_register()Tzung-Bi Shih
Move the initialization of the `struct cros_ec_device` from cros_ec_register() into cros_ec_device_alloc(). This decouples device initialization from registration. By doing so, the per-device lock is now available immediately after allocation, allowing it to be used safely even before the device is fully registered. Link: https://lore.kernel.org/r/20250828083601.856083-4-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2025-09-14platform/chrome: Centralize common cros_ec_device initializationTzung-Bi Shih
Move the common initialization from protocol device drivers into central cros_ec_device_alloc(). This removes duplicated code from each driver's probe function. The buffer sizes are now calculated once, using the maximum possible overhead required by any of the transport protocols, ensuring the allocated buffers are sufficient for all cases. Link: https://lore.kernel.org/r/20250828083601.856083-3-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2025-09-14platform/chrome: Centralize cros_ec_device allocationTzung-Bi Shih
Introduce a helper function, cros_ec_device_alloc(), to centralize the allocation of the struct cros_ec_device. Convert all protocol device drivers to use this new function. This is a preparatory step for separating common initialization logic out of device drivers' probe() and cros_ec_register(). Link: https://lore.kernel.org/r/20250828083601.856083-2-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2025-09-13efi: support booting with kexec handover (KHO)Evangelos Petrongonas
When KHO (Kexec HandOver) is enabled, it sets up scratch memory regions early during device tree scanning. After kexec, the new kernel exclusively uses this region for memory allocations during boot up to the initialization of the page allocator However, when booting with EFI, EFI's reserve_regions() uses memblock_remove(0, PHYS_ADDR_MAX) to clear all memory regions before rebuilding them from EFI data. This destroys KHO scratch regions and their flags, thus causing a kernel panic, as there are no scratch memory regions. Instead of wholesale removal, iterate through memory regions and only remove non-KHO ones. This preserves KHO scratch regions, which are good known memory, while still allowing EFI to rebuild its memory map. Link: https://lkml.kernel.org/r/b34da9fd50c89644cd4204136cfa6f5533445c56.1755721529.git.epetron@amazon.de Signed-off-by: Evangelos Petrongonas <epetron@amazon.de> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Acked-by: Pratyush Yadav <pratyush@kernel.org> Cc: Alexander Graf <graf@amazon.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Baoquan He <bhe@redhat.com> Cc: Changyuan Lyu <changyuanl@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-09-13fbdev: use panic_in_progress() helperJinchao Wang
Update the fbcon_skip_panic() function to use the panic_in_progress() helper. The previous direct access to panic_cpu is less readable and is being replaced by a dedicated function that more clearly expresses the intent. This change is part of a series to refactor the kernel's panic handling logic for better clarity and robustness. Link: https://lkml.kernel.org/r/20250825022947.1596226-3-wangjinchao600@gmail.com Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com> Acked-by Qianqiang Liu <qianqiang.liu@163.com> Cc: Anna Schumaker <anna.schumaker@oracle.com> Cc: Baoquan He <bhe@redhat.com> Cc: "Darrick J. Wong" <djwong@kernel.org> Cc: Dave Young <dyoung@redhat.com> Cc: Doug Anderson <dianders@chromium.org> Cc: "Guilherme G. Piccoli" <gpiccoli@igalia.com> Cc: Helge Deller <deller@gmx.de> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Joanthan Cameron <Jonathan.Cameron@huawei.com> Cc: Joel Granados <joel.granados@kernel.org> Cc: John Ogness <john.ogness@linutronix.de> Cc: Kees Cook <kees@kernel.org> Cc: Li Huafei <lihuafei1@huawei.com> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Luo Gengkun <luogengkun@huaweicloud.com> Cc: Max Kellermann <max.kellermann@ionos.com> Cc: Nam Cao <namcao@linutronix.de> Cc: oushixiong <oushixiong@kylinos.cn> Cc: Petr Mladek <pmladek@suse.com> Cc: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: Sohil Mehta <sohil.mehta@intel.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Tejun Heo <tj@kernel.org> Cc: Thomas Gleinxer <tglx@linutronix.de> Cc: Thomas Zimemrmann <tzimmermann@suse.de> Cc: Thorsten Blum <thorsten.blum@linux.dev> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Yicong Yang <yangyicong@hisilicon.com> Cc: Yunhui Cui <cuiyunhui@bytedance.com> Cc: Yury Norov (NVIDIA) <yury.norov@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-09-13drivers/base/node: handle error properly in register_one_node()Donet Tom
If register_node() returns an error, it is not handled correctly. The function will proceed further and try to register CPUs under the node, which is not correct. So, in this patch, if register_node() returns an error, we return immediately from the function. Link: https://lkml.kernel.org/r/20250822084845.19219-1-donettom@linux.ibm.com Fixes: 76b67ed9dce6 ("[PATCH] node hotplug: register cpu: remove node struct") Signed-off-by: Donet Tom <donettom@linux.ibm.com> Acked-by: David Hildenbrand <david@redhat.com> Cc: Alison Schofield <alison.schofield@intel.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Dave Jiang <dave.jiang@intel.com> Cc: Donet Tom <donettom@linux.ibm.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Hiroyouki Kamezawa <kamezawa.hiroyu@jp.fujitsu.com> Cc: Joanthan Cameron <Jonathan.Cameron@huawei.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com> Cc: Yury Norov (NVIDIA) <yury.norov@gmail.com> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-09-13mm: rename vm_ops->find_special_page() to vm_ops->find_normal_page()David Hildenbrand
... and hide it behind a kconfig option. There is really no need for any !xen code to perform this check. The naming is a bit off: we want to find the "normal" page when a PTE was marked "special". So it's really not "finding a special" page. Improve the documentation, and add a comment in the code where XEN ends up performing the pte_mkspecial() through a hypercall. More details can be found in commit 923b2919e2c3 ("xen/gntdev: mark userspace PTEs as special on x86 PV guests"). Link: https://lkml.kernel.org/r/20250811112631.759341-12-david@redhat.com Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Oscar Salvador <osalvador@suse.de> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Reviewed-by: Wei Yang <richard.weiyang@gmail.com> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Alistair Popple <apopple@nvidia.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dev Jain <dev.jain@arm.com> Cc: Hugh Dickins <hughd@google.com> Cc: Jan Kara <jack@suse.cz> Cc: Jann Horn <jannh@google.com> Cc: Juegren Gross <jgross@suse.com> Cc: Lance Yang <lance.yang@linux.dev> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Mariano Pache <npache@redhat.com> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-09-13treewide: remove MIGRATEPAGE_SUCCESSDavid Hildenbrand
At this point MIGRATEPAGE_SUCCESS is misnamed for all folio users, and now that we remove MIGRATEPAGE_UNMAP, it's really the only "success" return value that the code uses and expects. Let's just get rid of MIGRATEPAGE_SUCCESS completely and just use "0" for success. Link: https://lkml.kernel.org/r/20250811143949.1117439-3-david@redhat.com Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Zi Yan <ziy@nvidia.com> [mm] Acked-by: Dave Kleikamp <dave.kleikamp@oracle.com> [jfs] Acked-by: David Sterba <dsterba@suse.com> [btrfs] Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Byungchul Park <byungchul@sk.com> Cc: Alistair Popple <apopple@nvidia.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Benjamin LaHaise <bcrl@kvack.org> Cc: Chris Mason <clm@fb.com> Cc: Christian Brauner <brauner@kernel.org> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Dave Kleikamp <shaggy@kernel.org> Cc: Eugenio Pé rez <eperezma@redhat.com> Cc: Gregory Price <gourry@gourry.net> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Jan Kara <jack@suse.cz> Cc: Jason Wang <jasowang@redhat.com> Cc: Jerrin Shaji George <jerrin.shaji-george@broadcom.com> Cc: Josef Bacik <josef@toxicpanda.com> Cc: Joshua Hahn <joshua.hahnjy@gmail.com> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Mathew Brost <matthew.brost@intel.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Rakie Kim <rakie.kim@sk.com> Cc: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Cc: Lance Yang <lance.yang@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-09-13zram: protect recomp_algorithm_show() with ->init_lockSergey Senozhatsky
sysfs handlers should be called under ->init_lock and are not supposed to unlock it until return, otherwise e.g. a concurrent reset() can occur. There is one handler that breaks that rule: recomp_algorithm_show(). Move ->init_lock handling outside of __comp_algorithm_show() (also drop it and call zcomp_available_show() directly) so that the entire recomp_algorithm_show() loop is protected by the lock, as opposed to protecting individual iterations. The patch does not need to go to -stable, as it does not fix any runtime errors (at least I can't think of any). It makes recomp_algorithm_show() "atomic" w.r.t. zram reset() (just like the rest of zram sysfs show() handlers), that's a pretty minor change. Link: https://lkml.kernel.org/r/20250805101946.1774112-1-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org> Reported-by: Seyediman Seyedarab <imandevel@gmail.com> Suggested-by: Seyediman Seyedarab <imandevel@gmail.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: Minchan Kim <minchan@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-09-13/dev/zero: try to align PMD_SIZE for private mappingZhang Qilong
Attempt to map aligned to huge page size for private mapping which could achieve performance gains, the mprot_tw4m in libMicro average execution time on arm64: - Test case: mprot_tw4m - Before the patch: 22 us - After the patch: 17 us If THP config is not set, we fall back to system page size mappings. Link: https://lkml.kernel.org/r/20250731122305.2669090-1-zhangqilong3@huawei.com Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Tested-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Acked-by: David Hildenbrand <david@redhat.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Kefeng Wang <wangkefeng.wang@huawei.com> Cc: Nanyong Sun <sunnanyong@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-09-13Merge tag 'regulator-fix-v6.17-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fix from Mark Brown: "One fix for sy7636a which got confused about which device to use to manage the lifecycle of the power good GPIO because it's looked up from the parent device due to the way DT bindings work" * tag 'regulator-fix-v6.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: sy7636a: fix lifecycle of power good gpio
2025-09-13can: rcar_canfd: Simplify data bit rate configBiju Das
Introduce rcar_canfd_compute_data_bit_rate_cfg() for simplifying data bit rate configuration by replacing function-like macros. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/20250908120940.147196-5-biju.das.jz@bp.renesas.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-13can: rcar_canfd: Simplify nominal bit rate configBiju Das
Introduce rcar_canfd_compute_nominal_bit_rate_cfg() for simplifying nominal bit rate configuration by replacing function-like macros. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/20250908120940.147196-4-biju.das.jz@bp.renesas.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>