summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-08-06soundwire: get mipi-sdw-bra-mode-max-data-per-frame propertyBard Liao1-0/+3
Get the mipi-sdw-bra-mode-max-data-per-frame property which indicates the maximum data payload size (in bytes per frame excluding header, CRC, and footer) for the BRA Mode. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20260728124639.1484973-5-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-06soundwire: intel: handle Peripheral bra_block_alignmentBard Liao3-0/+14
The data pre frame size should be a multiple of bra_block_alignment. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20260728124639.1484973-4-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-06soundwire: Add bra_block_alignment property supportRichard Fitzgerald1-0/+3
Add a property to struct sdw_slave_prop equivalent to the Disco property "mipi-sdw-bra-mode-block-alignment". The SoundWire Disco specification defines this as: "The data payload size for this BRA Mode shall be an integer multiple of the value of this Property." Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Co-developed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20260728124639.1484973-3-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-06soundwire: cadence_master: add BRA_NumBytes[8] supportBard Liao1-6/+18
The header[0] bit definitions are: Header[0] bits 7 – 6: BRA_HeaderType Header[0] bits 5 – 2: BRA_DeviceAddress[3:0] Header[0] bit 1 BRA_Opcode 1 => Write, 0 => Read Header[0] bit 0 BRA_NumBytes[8] And the header[1] indicates the BRA_NumBytes[7:0]. The existing code doesn't handle BRA_NumBytes[8] therefore the maximum BRA number of a frame is limited to 255. Fixes: fe8a9cf75c1e ("soundwire: pass sdw_bpt_section to cdns BPT helpers") Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20260728124639.1484973-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-08-06clk: renesas: Add R-Car X5H CPG driverGeert Uytterhoeven3-0/+171
Add a minimal Clock Pulse Generator driver for the R-Car X5H (R8A78000) SoC. For now this supports just the few fixed-rate clocks that are needed by the current minimal DTS. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://patch.msgid.link/3f981753722de1ba871667be63460e89d299d635.1785941595.git.geert+renesas@glider.be
2026-08-06drm/panthor: Check VMA boundaries for PMD mappingsChristian A. Ehrhardt1-1/+5
When checking a different patch[1] sashiko AI pointed out that panthor needs the same fix[2]: In the ->huge_fault handler do not install a PMD huge page mapping if the huge page exceeds the boundaries of the VMA. [1] https://lore.kernel.org/lkml/20260622215718.1532689-1-lk@c--e.de/ [2] https://sashiko.dev/#/patchset/20260622215718.1532689-1-lk%40c--e.de Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Steven Price <steven.price@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Fixes: 68cbf96b1e9b ("drm/panthor: Part ways with drm_gem_shmem_object") Signed-off-by: Christian A. Ehrhardt <lk@c--e.de> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/lkml/20260622215718.1532689-1-lk@c--e.de/ Link: https://patch.msgid.link/20260623181942.1536598-1-lk@c--e.de Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2026-08-06cpufreq: imx6q: fix out-of-bounds write when probed more than onceKarl Mehltretter1-1/+1
imx6_soc_volt is allocated fresh on every probe, sized to the number of ARM OPPs: imx6_soc_volt = devm_kcalloc(cpu_dev, num, sizeof(*imx6_soc_volt), GFP_KERNEL); but it is filled through soc_opp_count, which has static storage and is never reset. A second bind after an unbind keeps indexing from where the first one stopped, and writes past the end of the new array. Unbinding and rebinding the driver on qemu's mcimx6ul-evk, under KASAN: BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe+0x3b0/0xa34 Write of size 4 at addr c5e90480 by task binder/73 imx6q_cpufreq_probe from platform_probe+0x88/0xe4 platform_probe from really_probe+0x108/0x384 bind_store from kernfs_fop_write_iter+0x1b4/0x28c The write lands one u32 past the end of the allocation. soc_opp_count is only read a few lines below the loop that fills it, so it never needed static storage. Make it a local. Fixes: b4573d1d657a ("cpufreq: imx6q: correct VDDSOC/PU voltage scaling when cpufreq is changed") Assisted-by: Claude:claude-opus-5 Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-08-06cpufreq: imx6q: fix devres accumulation across driver rebindKarl Mehltretter1-1/+3
imx6_soc_volt is allocated with devm_kcalloc(cpu_dev, ...), where cpu_dev is the CPU device from get_cpu_device(0). That device is never unbound, so its devres list is never released, and imx6q_cpufreq_remove() does not free the array either. Every probe therefore adds an allocation that stays for the lifetime of the system. Allocate against the platform device instead. Its devres is released when the driver is unbound, which is exactly the lifetime the array wants: imx6q_set_target() reads it, and nothing may reach that after cpufreq_unregister_driver(). That makes the array actually go away on unbind, so also clear the file-scope pointer in remove and on the failed-probe path, rather than leave it pointing at memory devres is about to release. Tested by rebinding the driver on qemu's mcimx6ul-evk. Fixes: b4573d1d657a ("cpufreq: imx6q: correct VDDSOC/PU voltage scaling when cpufreq is changed") Assisted-by: Claude:claude-opus-5 Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-08-06opp: Use clk_get_optional() to avoid leaving opp_table->clk as an error pointerPraveen Talari1-30/+24
_update_opp_table_clk() uses clk_get(dev, NULL) to acquire the device's clock. On platforms where the perf domain device has no Linux clock and is instead managed entirely by firmware via devm_pm_opp_of_add_table() (through of_genpd_add_provider_simple()/onecell()), clk_get() returns -ENOENT. That case is treated as valid (the OPP table can still have entries sourced from firmware), but opp_table->clk is left holding ERR_PTR(-ENOENT) rather than being reset to NULL: opp_table->clk = clk_get(dev, NULL); ret = PTR_ERR_OR_ZERO(opp_table->clk); ... if (ret == -ENOENT) { opp_table->clk_count = 1; return opp_table; /* opp_table->clk is still ERR_PTR(-ENOENT) */ } Consumers that only check IS_ERR(opp_table->clk) treat this as a valid clk and pass it straight into the clk consumer API. In particular, dev_pm_opp_set_rate() calls clk_round_rate(opp_table->clk, target_freq), and clk_round_rate() only guards against a NULL clk, so it dereferences the error pointer to read clk->exclusive_count and crashes: Unable to handle kernel NULL pointer dereference at virtual address 000000000000002e ... pc : clk_round_rate+0x3c/0x188 ... Call trace: clk_round_rate+0x3c/0x188 (P) dev_pm_opp_set_rate+0x114/0x33c Rather than teaching every clk consumer API to special-case ERR_PTR(-ENOENT), fix it at the source: use clk_get_optional() instead of clk_get() in _update_opp_table_clk(), which already translates -ENOENT into a NULL clk. This documents that the clock is genuinely optional for such devices, and keeps opp_table->clk holding either a valid clk or NULL, never a lingering -ENOENT error pointer. _opp_config_clk_single() is only wired up via opp_table->config_clks when a clk was actually found, and every other opp_table->clk consumer already tolerates NULL through the standard clk API (which treats a NULL clk as a no-op), so no other call site needs to change. Suggested-by: Sebastian Reichel <sre@kernel.org> Reviewed-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-08-06drm/sun4i: hdmi-phy: Fix H6 8-bit MPLL config at 594 MHzJernej Skrabec1-1/+1
The 8-bit entry of the last MPLL row (594 MHz) doesn't lock reliably on H6. 4K@60 RGB/YUV444, which is the mode that reaches this entry, doesn't come up. Align the value with the vendor driver. Other entries are left alone, they are used by lower pixel clocks which work fine. Tested with 4K@60 on a LG TV. Fixes: 0fb4b858b102 ("drm/sun4i: Add support for H6 HDMI PHY") Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Chen-Yu Tsai <wens@kernel.org> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Link: https://patch.msgid.link/aec9060209473b8176eb43bc7c63c20b21306adf.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-08-06drm/sun4i: Drop node references while building component listJernej Skrabec1-0/+3
Two references are leaked every time the display pipeline is walked: the output port node in sun4i_drv_traverse_endpoints(), which was never released since the driver was introduced, and each node taken out of the endpoint fifo in sun4i_drv_probe(), which stopped being released when the fifo was introduced. The latter is still safe to drop right after processing, since drm_of_component_match_add() takes its own reference. Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support") Fixes: 8b11aaface2b ("drm/sun4i: Implement endpoint parsing using kfifo") Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Chen-Yu Tsai <wens@kernel.org> Link: https://patch.msgid.link/759c74e3a22b97ca066ef7910ca4b91b852011e6.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-08-06drm/sun4i: dw-hdmi: Drop TCON TOP port referenceJernej Skrabec1-0/+2
When the HDMI controller is fed by TCON TOP, the port node used to enumerate the possible CRTCs is never released. Fixes: 57e23de02f48 ("drm/sun4i: DW HDMI: Expand algorithm for possible crtcs") Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Chen-Yu Tsai <wens@kernel.org> Link: https://patch.msgid.link/43ffcc17f7c3f94c1d7bd1ee89134c766e84df35.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-08-06drm/sun4i: tcon: Drop remote endpoint referenceJernej Skrabec1-0/+1
sun4i_tcon_of_get_id_from_port() never drops the reference taken by of_graph_get_remote_endpoint(). The function is not only called during bind, but also on every mode set through sun8i_r40_tcon_tv_set_mux(), so the leak accumulates. Fixes: e8d5bbf7f4c4 ("drm/sun4i: tcon: get TCON ID and matching engine with remote endpoint ID") Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Chen-Yu Tsai <wens@kernel.org> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/3f5ec952ad80cb51efebf2fe230df50259041a23.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-08-06drm/sun4i: crtc: Propagate layer initialization errorJernej Skrabec1-1/+1
sun4i_crtc_init() returns plain NULL when layer initialization fails, while all its other error paths return an error pointer. The only caller, sun4i_tcon_bind(), checks the result with IS_ERR() and happily continues with tcon->crtc set to NULL. sun4i_rgb_init() and sun4i_lvds_init() then dereference it in drm_crtc_mask(), which oopses. Return the error pointer instead. Fixes: dcd215801b02 ("drm/sun4i: Drop primary layer pointer from sun4i_drv") Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Chen-Yu Tsai <wens@kernel.org> Link: https://patch.msgid.link/b26a0d427d9dfae9c82e3ca90a67d24d8ece5a28.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-08-06drm/sun4i: hdmi: Don't leak sync polarity bits into packet controlJernej Skrabec1-1/+1
sun4i_hdmi_enable() keeps using the same variable after it programmed the video timing polarity register with it. The leftover TX_CLK, HSYNC and VSYNC bits are then ORed into the packet control register, where each nibble selects the packet type sent in one slot. As a result, slot 0 selects packet type 3 instead of the AVI infoframe whenever the mode has positive HSYNC polarity, and the TX_CLK bits set nibbles which the driver never programs. Assign the packet types instead of ORing them into the stale value. Fixes: 9ca6bc246035 ("drm/sun4i: hdmi: Move mode_set into enable") Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Chen-Yu Tsai <wens@kernel.org> Link: https://patch.msgid.link/51ba0918ce016a4b45313d5df1b6ce31b8c8731e.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-08-06drm/sun4i: tcon: Drop TCON TOP device referenceJernej Skrabec1-10/+9
of_find_device_by_node() takes a device reference. Drop it after mux configuration succeeds. Fixes: 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON") Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Chen-Yu Tsai <wens@kernel.org> Link: https://patch.msgid.link/871a3108086c15a483eef23301984c8d2254dfa7.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-08-06drm/sun4i: tcon: Set output mux for DSI and LVDSJernej Skrabec1-0/+2
DSI and LVDS skip output mux setup, so TCON TOP cannot route the selected mixer. Configure them like other channel 0 outputs. In practice this matters for D1, where channel 0 TCONs are fed through TCON TOP. The remaining set_mux implementations only handle TMDS and return an error for other encoder types, as before. Fixes: b9b52d2f4aaf ("drm/sun4i: Add support for D1 TCONs") Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Chen-Yu Tsai <wens@kernel.org> Link: https://patch.msgid.link/7e9dad9eed2e91a79c4e1202caa8fed7c2427531.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-08-06drm/sun4i: tcon-top: Keep mixer routes distinctJernej Skrabec2-12/+65
Both mixer selectors reset to TCON 0. Selecting the same TCON for both mixers causes black or corrupted output. When a route would collide, park the other mixer on another described TCON, or an unused selector if none exists. Since the TCON index is now used as a shift, also reject negative values. Tested on Orange Pi 3 with TCON_LCD0 and TCON_TV0. Link: https://lore.kernel.org/linux-sunxi/Zn8GVkpwXwhaUFno@titan/ Link: https://lore.kernel.org/linux-sunxi/20241108-tcon_fix-v1-1-616218cc0d5f@jookia.org/ Fixes: 05db311a792d ("drm/sun4i: tcon-top: Add helpers for mux switching") Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Link: https://patch.msgid.link/52eb247169b268054302afa71e598add0b04748d.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-08-06drm/sun4i: vi scaler: Restore opaque alpha in video modesJernej Skrabec2-0/+3
The DE3 mixer initialization clears the entire mixer register space. This also clears VSU_GLOBAL_ALPHA, despite its hardware reset value being 0xff. The VI scaler uses Video Normal mode for subsampled YUV formats. In this mode, VSU_GLOBAL_ALPHA provides the scaler output alpha. Leaving the register at zero causes the scaler to produce fully transparent output. Set VSU_GLOBAL_ALPHA to 0xff whenever configuring a DE3 or newer VI scaler. The register is ignored in UI scaling mode. Fixes: c50519e6db4d ("drm/sun4i: Add basic support for DE3") Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Chen-Yu Tsai <wens@kernel.org> Link: https://patch.msgid.link/c48ba85b9e4478d51afde4f36839fd1c1d363b23.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-08-06drm/sun4i: vi scaler: Fix coefficient selectionJernej Skrabec1-6/+12
Currently, vertical coefficients are selected based on horizontal scaling, which is wrong. Additionally, chroma coefficients should be selected based on format subsampling. Fix all that. Fixes: b862a648de3b ("drm/sun4i: Add support for HW scaling to DE2") Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Link: https://patch.msgid.link/263a4a41442a3c8b072b170256b72658f1b90802.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-08-06drm/sun4i: Fix V3s YUV scanline sizeJernej Skrabec1-1/+1
The VI scaler line buffer on V3s can hold 1024 pixels for subsampled formats, not 2048 as currently claimed. Since coarse horizontal scaling is engaged only once the source width exceeds that limit, YUV layers wider than 1024 pixels are passed to the scaler unchanged and the output is corrupted. Use the value from the vendor driver. Fixes: 2586de70c15c ("drm/sun4i: Add VI scaler line size quirk for DE2/DE3") Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Chen-Yu Tsai <wens@kernel.org> Link: https://patch.msgid.link/75ad4947981f2dc33fd42c05ae0b0cedda7647bd.1785772659.git.jernej.skrabec@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-08-05Input: evdev - sanitize event type index when fetching event masksDmitry Torokhov1-1/+4
The user-supplied event type index passed to EVIOCGMASK / EVIOCSMASK ioctls is used to index the static counts array in evdev_get_mask_cnt() and client evmasks array in evdev_get_mask(). While the event type is architecturally bounded by EV_CNT, speculative execution may mispredict bounds checks and perform out-of-bounds loads. Sanitize the event type index in evdev_get_mask_cnt() branchlessly using array_index_mask_nospec(). This clamps the index to 0 for safe array access and forces the returned count to 0 speculatively when the index is out of bounds. We do not need additional array_index_nospec() calls in evdev_get_mask() because evdev_get_mask_cnt() speculatively forces the count (and resulting xfer_size) to 0 for out-of-bounds types, preventing any speculative memory access to client evmasks array. Reported-by: "Wagenaar, C.C.J. (Chris)" <c.c.j.wagenaar@vu.nl> Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.6-flash Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/anFCAfvxwXB5eJF1@google.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-08-05Input: reject inhibit and uninhibit requests on unregistering devicesDmitry Torokhov1-0/+6
When an input device is being unregistered via input_unregister_device(), input_disconnect_device() sets dev->going_away = true under dev->mutex and releases the mutex. If a concurrent sysfs write to the inhibited attribute executes input_inhibit_device() or input_uninhibit_device(), it acquires dev->mutex. Because neither function checks dev->going_away (unlike input_open_device()), input_uninhibit_device() proceeds to call dev->open() and start polling on a device that is in the middle of being unregistered and torn down. Fix this by checking dev->going_away in input_inhibit_device() and input_uninhibit_device() under dev->mutex and returning -ENODEV if the device is going away. Fixes: a181616487db ("Input: Add "inhibited" property") Reported-by: sashiko-bot@kernel.org Assisted-by: Antigravity:gemini-3.6-flash Link: https://patch.msgid.link/anEolqA35rGei9ql@google.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-08-05Input: defer handler's start() until device is openedDmitry Torokhov1-24/+31
When registering an input handle, handler->start() is currently called immediately. However, the input device might not be fully opened or ready to process events at this stage, meaning any state synchronization events (like setting LED states) injected by the handler's start method might be dropped. Move the handler->start() invocation to input_open_device(). If it is the first handle opening the device, start() is called after the driver's open() method has successfully completed and the device is fully prepared. To facilitate this, factor out the device startup logic (calling driver's open and starting polling) into input_start_device(). For passive observer handlers, their start() method is also deferred until the handle is opened. Since opening a passive observer handle does not start the underlying hardware device, their start() method is called immediately upon opening, regardless of whether the device is active. Fixes: c7e8dc6ee6d5 ("Input: add start() method to input handlers") Link: https://patch.msgid.link/20260803005210.1251102-4-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-08-05Input: call handler->start() when uninhibiting deviceDmitry Torokhov1-0/+6
When an input device is inhibited via input_inhibit_device(), the driver is closed and physical feedback (like LEDs and sounds) is toggled off. However, from the input core's perspective, the handles remain open. When the device is later uninhibited, the driver is re-opened. While the core restores simple LED states via input_dev_toggle(), complex handlers (such as vt/keyboard) may need to re-synchronize their broader logical state with the hardware. Fixes: a181616487db ("Input: Add "inhibited" property") Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260803005210.1251102-3-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-08-05Input: clear inhibited flag before re-opening device on uninhibitDmitry Torokhov1-6/+8
When uninhibiting a device, we previously called dev->open() and started the poller before clearing dev->inhibited. Since drivers (like gpio_keys) often report initial state during open(), and pollers report events immediately upon starting, these initial events were dropped by input_get_disposition() because dev->inhibited was still true. Fix this by clearing dev->inhibited before calling dev->open(), ensuring initial events are delivered to handlers, and restoring dev->inhibited = true if dev->open() fails. Fixes: a181616487db ("Input: Add "inhibited" property") Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260803005210.1251102-2-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-08-05Input: ensure device is ready before delivering eventsDmitry Torokhov1-37/+66
When a device is opened via input_open_device(), the driver's open() callback is invoked. Some drivers, like cm109, submit URBs or perform other hardware initialization in their open() callbacks. However, the input core does not prevent dev->event() from being called concurrently during the driver's open() execution. For instance, if a console beep occurs, the kbd handler might inject an EV_SND event. This can lead to double list_add BUGs if the driver submits the same URB in both open() and event() paths without adequate synchronization. To fix this, introduce a ready flag in the input_dev structure. For complex devices (where dev->open is defined), this flag is set to true only after the driver's open() method successfully completes. The core now checks ready in input_event_dispose() and input_dev_toggle() to prevent events from reaching the hardware before it is fully prepared. For simple devices (no open callback), events are delivered immediately. We also replay the logical state in input_open_device() by calling input_dev_toggle() right after marking the device ready, ensuring no events are permanently lost. In the inhibit path, we ensure that physical feedback (LEDs/sounds) is turned off before the device is closed, and we synchronize the inhibited state transition under the event lock to prevent races with incoming events. Assisted-by: Antigravity:gemini-3.5-flash Link: https://patch.msgid.link/20260803005210.1251102-1-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-08-06drm/sun4i: framebuffer: Set mode_config.normalize_zposChen-Yu Tsai1-17/+2
Back when support for zpos was added in commit 47a05f4a68f9 ("drm/sun4i: backend: Add support for zpos"), a custom atomic_check callback was also added in commit b8f1230dd3bf ("drm/sun4i: framebuffer: Add a custom atomic_check") to have a place to call drm_atomic_normalize_zpos(). Commit 49efffc7fbd4 ("drm: Add drm_mode_config->normalize_zpos boolean") added drm_atomic_normalize_zpos() to the standard atomic_check function. Set mode_config.normalize_zpos and drop the custom atomic_check implementation, which at this point is just a simplified copy of the standard one. The standard one also checks whether async updates are valid and updates the self refresh state, but neither feature is supported by this driver. Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20260803111319.2836240-1-wenst@chromium.org Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2026-08-05Input: gscps2 - supply PA-RISC keyboard keymap via device propertyDmitry Torokhov5-166/+172
Instead of hardcoding PA-RISC specific keycode tables into atkbd via compile-time inclusion, have the gscps2 PS/2 port driver attach a linux,keymap software node device property to the serio device when a keyboard port is registered. This allows atkbd to dynamically fetch and apply the custom keymap when probing the port using generic firmware property helpers, removing architecture-specific hacks from generic keyboard driver code. Co-locate the keymap definitions with the serio port driver by moving hpps2atkbd.h from drivers/input/keyboard/ to drivers/input/serio/. To handle the five conflicting keys on RDI PrecisionBook laptops without runtime model string checks or duplicate keymap tables in memory, add CONFIG_SERIO_GSCPS2_RDI_KEYCODES to drivers/input/serio/Kconfig and resolve the conflicting keycodes at compile time via preprocessor macros. Link: https://patch.msgid.link/am_9BvmZu9g4RlUM@google.com Acked-by: Helge Deller <deller@gmx.de> Tested-by: Helge Deller <deller@gmx.de> Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-08-06Merge tag 'exynos-drm-next-for-v7.3' of ↵Dave Airlie5-13/+59
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next Cleanup and modernization for Exynos encoders - Remove dependency on deprecated DRM simple KMS helpers . Replaces drm_simple_encoder_init() with drm_encoder_init() across dp, dpi, dsi, vidi and hdmi. . Adds per-driver drm_encoder_funcs with .destroy = drm_encoder_cleanup, removing the intermediate layer between the drivers and atomic modesetting. - Add error handling to drm_encoder_init() . Checks the return code at every call site instead of ignoring it. . Prevents silent encoder creation failures and drm_encoder_cleanup() on an uninitialized encoder. Bug fix for Exynos HDMI DDC adapter refcounting - Take an i2c adapter module reference . Switches to of_get_i2c_adapter_by_node() / i2c_put_adapter() so the adapter module reference is held while the DDC bus is in use. . Makes an unload attempt fail gracefully with -EBUSY instead of blocking uninterruptibly in i2c_del_adapter(). Signed-off-by: Dave Airlie <airlied@redhat.com> From: Inki Dae <inki.dae@samsung.com> Link: https://patch.msgid.link/20260802061039.73544-1-inki.dae@samsung.com
2026-08-06Merge tag 'amd-drm-next-7.3-2026-07-31' of ↵Dave Airlie17-388/+370
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-7.3-2026-07-31: amdgpu: - PM sysfs fix for APUs - DC pageflip timeout fixes - New GFX7 soft reset implementation - Misc code cleanup amdkfd: - Remove svm_bo eviction fence Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260731153253.1393962-1-alexander.deucher@amd.com
2026-08-05net: stmmac: raise TX completion interrupt at the end of an xmit burstJohan Alvarado1-0/+4
The TX mitigation logic only sets the Interrupt on Completion bit once every tx_coal_frames descriptors (STMMAC_TX_FRAMES = 25), with the tx_coal_timer hrtimer (STMMAC_COAL_TX_TIMER = 5000 us) as the only fallback. TX skbs are freed exclusively from the TX completion path, so any flow that keeps fewer than 25 frames in flight has all of its skbs held for up to 5 ms after transmission. Paced flows never queue enough frames to reach the frame threshold: TCP Small Queues caps the amount of unfreed data at roughly two pacing intervals worth, which at moderate pacing rates is only a couple of packets. Every small burst then stalls until the coalesce timer fires, and throughput collapses to approximately tsq_limit / tx_coal_timer regardless of link capacity. This is easily reproducible with BBR, which paces its output and thus keeps only a few frames in flight at a time. On a YT6801 (dwmac-motorcomm) equipped Orange Pi 5 Pro, a BBR upload over a ~23 ms RTT path is capped at 5.24 Mbit/s, while CUBIC reaches 207 Mbit/s on the same path. BBR measures the stalled send rate as the path bandwidth and locks its estimate near the floor, so the connection never recovers. Lowering the coalesce settings with ethtool -C (tx-usecs 100 tx-frames 1) lifts the same transfer to 447 Mbit/s, confirming the mechanism. Fix this by setting the IC bit on the last descriptor of every xmit burst, i.e. whenever netdev_xmit_more() reports that no further frames are pending in the current dequeue batch. Frame-based coalescing still applies within a burst, bulk traffic keeps batching through qdisc bulk dequeue and NAPI polling, and the coalesce timer becomes a pure fallback instead of the primary completion mechanism for lightly queued flows. tx-frames 0 keeps its meaning of timer-based mitigation only. Signed-off-by: Johan Alvarado <contact@c127.dev> Link: https://patch.msgid.link/20260731194522.55069-1-contact@c127.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05net/mlx5: add debugfs stats for doorbell dma poolsNimrod Oren1-0/+27
Add a debugfs file exposing per-node DMA pool usage for doorbell allocations. # cat /sys/kernel/debug/mlx5/<dev>/db_dma_pools node block_size used_blocks allocated_blocks 0 64 0 0 1 64 0 0 Signed-off-by: Nimrod Oren <noren@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260803132520.2891860-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05net/mlx5: allocate doorbells from dma poolsNimrod Oren2-98/+17
Allocate doorbells from dma pools instead of the pgdir allocator. Doorbell records remain cache-line sized coherent DMA allocations, but their sub-allocation is now handled by the common mlx5 DMA pool infrastructure. This also makes doorbell allocation honor the requested NUMA node when reusing existing backing pages. The old pgdir allocator used the requested node only when allocating a new pgdir page; later allocations scanned one global pgdir list and could take any pgdir with a free entry, even if that page had been allocated for a different NUMA node. Selecting the per-node DMA pool before sub-allocation keeps reused doorbell records on pages allocated for the requested node. Signed-off-by: Nimrod Oren <noren@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260803132520.2891860-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05net/mlx5: initialize doorbell dma poolsNimrod Oren3-0/+46
Add per-node doorbell dma pool creation and cleanup to mdev lifecycle. Signed-off-by: Nimrod Oren <noren@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260803132520.2891860-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05dpll: zl3073x: recognize the ZL30643 chip ID (0x0E3B)Vincent Jardin1-0/+1
The Microchip ZL30643 is a 3-channel ZL3064x line-card part that is register compatible with the ZL30733. Only the runtime chip-ID table needs the 0x0E3B entry so the probe resolves the channel count (3) and flags. The ZL3073X_FLAG_REF_PHASE_COMP_32 flag applies unchanged: the ref_phase path dpll_meas_ctrl::en -> ref_phase_0P/0N -> ref_phase_offset_compensation -> ref_phase_err_read_rqst is identical between ZL3064x and ZL3073x. No new device flag is needed. Test: once register, for instance, we get: devlink dev param set spi/spi0.0 name clock_id value 3733 cmode driverinit devlink dev reload spi/spi0.0 devlink dev param set spi/spi2.1 name clock_id value 3643 cmode driverinit devlink dev reload spi/spi2.1 dpll device show | grep clock-id clock-id: 3733 clock-id: 3733 clock-id: 3733 clock-id: 3643 clock-id: 3643 clock-id: 3643 Signed-off-by: Vincent Jardin <vjardin@free.fr> Link: https://patch.msgid.link/20260730-for-upstream-zl30643-v2-2-0ea0bbd03755@free.fr Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05pppoe: remove redundant xmit wrapperQingfang Deng1-16/+4
Merge __pppoe_xmit() into pppoe_xmit(), its only caller. Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev> Link: https://patch.msgid.link/20260804094336.109364-1-qingfang.deng@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05net: tulip: remove xircom_cb driverPablo Vallespín Aranguren3-1187/+2
A possible bug was found in investigate_read_descriptor() and a fix was proposed. Since this is an orphan driver for hardware that is old, removing the driver was suggested instead. This patch removes the driver. Jakub: clean up the Kconfig and platform configs Link: https://lore.kernel.org/netdev/2026080158-next-diligent-b4ce@gregkh Signed-off-by: Pablo Vallespín Aranguren <pablopva014@gmail.com> Link: https://patch.msgid.link/am48DR5FC-xTY3-D@ThinkPad-P15 Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05dinghai: add hardware register access and PCI capability scanningJunyang Han3-0/+377
Implement PCI configuration space access, BAR mapping, capability scanning (common/notify/device), and hardware queue register definitions for DingHai PF device. Signed-off-by: Junyang Han <han.junyang@zte.com.cn> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05dinghai: add ZTE network driver supportJunyang Han8-0/+272
Add basic framework for ZTE DingHai ethernet PF driver, including Kconfig/Makefile build support and PCIe device probe/remove skeleton. Signed-off-by: Junyang Han <han.junyang@zte.com.cn> Link: https://patch.msgid.link/202608021621043761zZMwCny1e6y0TRFLQHxx@zte.com.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05ptp: reject frequency adjustments that overflow scaled_ppm_to_ppb()Deep Shah1-1/+13
ptp_clock_adjtime() validates an ADJ_FREQUENCY request by converting the requested scaled ppm to ppb and comparing it against ops->max_adj: long ppb = scaled_ppm_to_ppb(tx->freq); if (ppb > ops->max_adj || ppb < -ops->max_adj) return -ERANGE; scaled_ppm_to_ppb() computes (1 + ppm) * 125 >> 13 in s64. For a sufficiently large tx->freq the multiplication overflows s64 and wraps, so the resulting ppb can fall back within [-max_adj, max_adj] and pass the check. The unclamped tx->freq is then handed to ->adjfine(), where drivers scale it again (e.g. scaled_ppm * 762939453125 in ptp_idt82p33) and program a bogus frequency word. For example tx->freq = 147573952589676412 makes (1 + ppm) * 125 equal 2^64 + 9, which wraps to ppb == 0 and is accepted. The caller already has write access to the PHC, so this hardens the max_adj sanity check rather than crossing a privilege boundary, and well-behaved user space (e.g. ptp4l) never requests such values. It is a follow-up to commit 475b92f93216 ("ptp: improve max_adj check against unreasonable values"), which handled the analogous s32 narrowing but not this multiplication overflow. Detect the overflow with check_*_overflow() and reject the request in ptp_clock_adjtime() instead of acting on the wrapped value. Signed-off-by: Deep Shah <deepshah146@gmail.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Acked-by: Richard Cochran <richardcochran@gmail.com> Link: https://patch.msgid.link/20260801222923.39017-2-deepshah146@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05net: usb: cdc_ether: add quirk for AMI BMC stale link eventsJinhui Guo1-0/+16
On AMD Genoa/Turin platforms the BMC-provided USB-Ethernet gadget (American Megatrends, VID 0x046b PID 0xffb0) intermittently fails to respond to ARP after AC cold boot. usbmon captures a stale NETWORK_CONNECTION(off) immediately followed by NETWORK_CONNECTION(on) on the interrupt endpoint (~130us apart) after enumeration. Because alloc_netdev() leaves __LINK_STATE_NOCARRIER cleared, netif_carrier_ok() returns true when the spurious OFF arrives, so usbnet_cdc_status() cannot recognise it as redundant and schedules EVENT_LINK_CHANGE. __handle_link_change() then calls unlink_urbs(), killing ~60 rx URBs whose payload has already been DMA'd into memory — xHCI trace confirms them completing as -ECONNRESET with non-zero residual length. rx_complete() drops these unconditionally. The following ON restores the carrier and re-submits URBs, but the ARP reply is already lost; the interface looks "up but silent" until ifdown/ifup. Fix this by adding a device-specific quirk with FLAG_LINK_INTR set, which makes usbnet_probe() call netif_carrier_off() after bind. With initial carrier == OFF, usbnet_cdc_status() recognises the spurious OFF as matching the current state and drops it; the subsequent ON is the first real event and brings the link up cleanly without ever tearing down the rx queue. The scheduled link-change kevent is harmless because EVENT_DEV_OPEN is not yet set at probe time. This is applied as a device-specific quirk rather than a change to the shared cdc_info driver_info because some CDC devices never send NETWORK_CONNECTION notifications; forcing carrier off for them would leave the link permanently DOWN. Restricting the change to this VID/PID keeps that class of device untouched. Tested on Genoa and Turin across 100+ AC cold boot cycles; ping first-packet success rate went from intermittent to 100%. Signed-off-by: Jinhui Guo <guojinhui.liam@bytedance.com> Link: https://patch.msgid.link/20260730051341.24930-1-guojinhui.liam@bytedance.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05pds_core: add debugfs support for host backed memoryNikhil P. Rao3-0/+48
Add debugfs entry to dump host backed memory allocations for debug purposes. Signed-off-by: Vamsi Atluri <Vamsi.Atluri@amd.com> Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com> Link: https://patch.msgid.link/20260730-upstream_v8-v12-6-136cd174ee85@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05pds_core: add host backed memory support for firmwareNikhil P. Rao3-0/+184
Some newer AMD/Pensando cards have minimal memory and there are cases where components, specifically in the control plane, need more memory. This series adds support for host backed DMA memory that can be used by the firmware for the previously mentioned cases. Host memory allocation is best-effort: if some allocations fail, the driver continues with whatever succeeded. Firmware gracefully degrades when less memory is available than requested. Signed-off-by: Vamsi Atluri <Vamsi.Atluri@amd.com> Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com> Link: https://patch.msgid.link/20260730-upstream_v8-v12-5-136cd174ee85@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05pds_core: add PLDM component info displayBrett Creeley2-5/+142
Add detailed component information display via devlink info. This allows users to see individual firmware components and their versions. Components are reported as fixed, running, or stored based on their firmware-provided flags. Example output: $ devlink dev info pci/0000:00:05.0 versions: fixed: asic.id 0x0 asic.rev 0x0 running: fw.bootloader 1.2.3 fw.uboot 1.60.0-73 fw 1.60.0-73 fw.cpld 3.18 stored: fw.bootloader 1.2.3 fw.uboot 1.60.0-73 fw.uboot.gold 1.50.0-22 fw.gold 1.50.0-22 fw 1.60.0-73 fw.cpld 3.18 Signed-off-by: Brett Creeley <brett.creeley@amd.com> Link: https://patch.msgid.link/20260730-upstream_v8-v12-4-136cd174ee85@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05pds_core: add PLDM firmware update support via devlink flashBrett Creeley7-11/+921
Implement PLDM FW Update in the pds_core driver using the upstream pldmfw API. This allows updating an entire PLDM FW package at once or updating specific firmware components by name. Flash the entire image: devlink dev flash pci/0000:b5:00.0 file firmware.pldmfw Flash a specific component from the PLDM FW package: devlink dev flash pci/0000:b5:00.0 \ file firmware.pldmfw component fw.cpld Per-component update uses driver-defined component names (fw, fw.cpld, etc.). Not all components support per-component update - devlink will reject the request if the specified component cannot be updated. Signed-off-by: Brett Creeley <brett.creeley@amd.com> Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com> Link: https://patch.msgid.link/20260730-upstream_v8-v12-3-136cd174ee85@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05pds_core: add support for identity version 2Brett Creeley1-9/+35
Add a new capabilities field in struct pds_core_dev_identity, which requires bumping the identity version to 2, i.e. PDS_CORE_IDENTITY_VERSION_2. If version 2 negotiation fails, then quietly fall back to version 1. If version 1 negotiation fails, then driver load will fail. Another patch in the series will make use of the capabilities field. Signed-off-by: Brett Creeley <brett.creeley@amd.com> Link: https://patch.msgid.link/20260730-upstream_v8-v12-2-136cd174ee85@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05pds_core: add support for quiet devcmd failuresBrett Creeley1-5/+13
Currently there aren't any use-cases that require special handling on whether or not to print devcmd failures. Specifically non-generic failures, i.e. not supported failures. Add support to allow these messages to be suppressed. This will be used when adding support to negotiate PDS_CORE_IDENTITY_VERSION_2. Signed-off-by: Brett Creeley <brett.creeley@amd.com> Link: https://patch.msgid.link/20260730-upstream_v8-v12-1-136cd174ee85@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05net: phy: nxp-tja11xx: cancel registration work on removeHongyan Xu1-0/+9
tja1102_p0_probe() schedules work to register the second port. That work uses the Port 0 private data and phydev. The private data is devm-allocated, but the driver does not wait for the pending work on remove. Store the Port 0 private data in phydev->priv and add a remove callback. The callback cancels the registration work before devres teardown frees the state. This issue was found by a static analysis tool. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Hongyan Xu <getshell@seu.edu.cn> Link: https://patch.msgid.link/20260801140643.1871-1-getshell@seu.edu.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-05pfcp: Support per-netns netdev unregistration.Kuniyuki Iwashima1-5/+7
pfcp_net_exit_rtnl() iterates pfcp devices whose sockets are in the dying netns and queues them for destruction. So the devices may reside in different netns. Let's use unregister_netdevice_queue_net() to support per-netns device unregistration. list_del() is changed to list_del_init() to avoid queueing the same device twice. Even after pfcp_net_exit_rtnl() queues a cross-netns pfcp device, pfcp_dellink() could be called concurrently for it (once RTNL is removed). In such a case, __rtnl_net_unlock() will perform the unregistration. We can see pfcp0 below is unregistered by the per-netns work instead of cleanup_net(). # bpftrace -e '#include <linux/netdevice.h> kprobe:pfcp_dev_uninit { $dev = (struct net_device *)arg0; printf("PID: %d | DEV: %s%s\n", pid, $dev->name, kstack()); } kprobe:pfcp_net_exit_rtnl { printf("PID: %d%s\n", pid, kstack()); }' & # ip netns add ns1 # ip netns add ns2 # ip -n ns1 link add pfcp0 link-netns ns2 type pfcp # ip netns del ns2 PID: 12 pfcp_net_exit_rtnl+5 ops_undo_list+702 cleanup_net+1122 process_scheduled_works+2538 ... PID: 462 | DEV: pfcp0 pfcp_dev_uninit+5 unregister_netdevice_many_notify+7129 unregister_netdevice_many_net+1050 rtnl_net_work_func+136 process_scheduled_works+2538 Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260731224406.2444121-3-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>