--- /dev/null
+From 2692c614f8f05929d692b3dbfd3faef1f00fbaf0 Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Date: Tue, 10 Feb 2026 14:58:22 +0100
+Subject: device property: Allow secondary lookup in fwnode_get_next_child_node()
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+commit 2692c614f8f05929d692b3dbfd3faef1f00fbaf0 upstream.
+
+When device_get_child_node_count() got split to the fwnode and device
+respective APIs, the fwnode didn't inherit the ability to traverse over
+the secondary fwnode. Hence any user, that switches from device to fwnode
+API misses this feature. In particular, this was revealed by the commit
+1490cbb9dbfd ("device property: Split fwnode_get_child_node_count()")
+that effectively broke the GPIO enumeration on Intel Galileo boards.
+Fix this by moving the secondary lookup from device to fwnode API.
+
+Note, in general no device_*() API should go into the depth of the fwnode
+implementation.
+
+Fixes: 114dbb4fa7c4 ("drivers property: When no children in primary, try secondary")
+Cc: stable@vger.kernel.org
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
+Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Link: https://patch.msgid.link/20260210135822.47335-1-andriy.shevchenko@linux.intel.com
+Signed-off-by: Danilo Krummrich <dakr@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/base/property.c | 27 +++++++++++++--------------
+ 1 file changed, 13 insertions(+), 14 deletions(-)
+
+--- a/drivers/base/property.c
++++ b/drivers/base/property.c
+@@ -749,7 +749,18 @@ struct fwnode_handle *
+ fwnode_get_next_child_node(const struct fwnode_handle *fwnode,
+ struct fwnode_handle *child)
+ {
+- return fwnode_call_ptr_op(fwnode, get_next_child_node, child);
++ struct fwnode_handle *next;
++
++ if (IS_ERR_OR_NULL(fwnode))
++ return NULL;
++
++ /* Try to find a child in primary fwnode */
++ next = fwnode_call_ptr_op(fwnode, get_next_child_node, child);
++ if (next)
++ return next;
++
++ /* When no more children in primary, continue with secondary */
++ return fwnode_call_ptr_op(fwnode->secondary, get_next_child_node, child);
+ }
+ EXPORT_SYMBOL_GPL(fwnode_get_next_child_node);
+
+@@ -793,19 +804,7 @@ EXPORT_SYMBOL_GPL(fwnode_get_next_availa
+ struct fwnode_handle *device_get_next_child_node(const struct device *dev,
+ struct fwnode_handle *child)
+ {
+- const struct fwnode_handle *fwnode = dev_fwnode(dev);
+- struct fwnode_handle *next;
+-
+- if (IS_ERR_OR_NULL(fwnode))
+- return NULL;
+-
+- /* Try to find a child in primary fwnode */
+- next = fwnode_get_next_child_node(fwnode, child);
+- if (next)
+- return next;
+-
+- /* When no more children in primary, continue with secondary */
+- return fwnode_get_next_child_node(fwnode->secondary, child);
++ return fwnode_get_next_child_node(dev_fwnode(dev), child);
+ }
+ EXPORT_SYMBOL_GPL(device_get_next_child_node);
+
--- /dev/null
+From 0b87d51690dd5131cbe9fbd23746b037aab89815 Mon Sep 17 00:00:00 2001
+From: Franz Schnyder <franz.schnyder@toradex.com>
+Date: Fri, 6 Feb 2026 13:37:36 +0100
+Subject: drm/bridge: ti-sn65dsi86: Enable HPD polling if IRQ is not used
+
+From: Franz Schnyder <franz.schnyder@toradex.com>
+
+commit 0b87d51690dd5131cbe9fbd23746b037aab89815 upstream.
+
+Fallback to polling to detect hotplug events on systems without
+interrupts.
+
+On systems where the interrupt line of the bridge is not connected,
+the bridge cannot notify hotplug events. Only add the
+DRM_BRIDGE_OP_HPD flag if an interrupt has been registered
+otherwise remain in polling mode.
+
+Fixes: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type")
+Cc: stable@vger.kernel.org # 6.16: 9133bc3f0564: drm/bridge: ti-sn65dsi86: Add
+Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
+Reviewed-by: Douglas Anderson <dianders@chromium.org>
+[dianders: Adjusted Fixes/stable line based on discussion]
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Link: https://patch.msgid.link/20260206123758.374555-1-fra.schnyder@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/bridge/ti-sn65dsi86.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
++++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+@@ -1307,6 +1307,7 @@ static int ti_sn_bridge_probe(struct aux
+ {
+ struct ti_sn65dsi86 *pdata = dev_get_drvdata(adev->dev.parent);
+ struct device_node *np = pdata->dev->of_node;
++ const struct i2c_client *client = to_i2c_client(pdata->dev);
+ int ret;
+
+ pdata->next_bridge = devm_drm_of_get_bridge(&adev->dev, np, 1, 0);
+@@ -1326,8 +1327,9 @@ static int ti_sn_bridge_probe(struct aux
+ ? DRM_MODE_CONNECTOR_DisplayPort : DRM_MODE_CONNECTOR_eDP;
+
+ if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) {
+- pdata->bridge.ops = DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_DETECT |
+- DRM_BRIDGE_OP_HPD;
++ pdata->bridge.ops = DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_DETECT;
++ if (client->irq)
++ pdata->bridge.ops |= DRM_BRIDGE_OP_HPD;
+ /*
+ * If comms were already enabled they would have been enabled
+ * with the wrong value of HPD_DISABLE. Update it now. Comms
--- /dev/null
+From ce9e40a9a5e5cff0b1b0d2fa582b3d71a8ce68e8 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Fri, 6 Feb 2026 15:48:16 +0000
+Subject: irqchip/gic-v3-its: Limit number of per-device MSIs to the range the ITS supports
+
+From: Marc Zyngier <maz@kernel.org>
+
+commit ce9e40a9a5e5cff0b1b0d2fa582b3d71a8ce68e8 upstream.
+
+The ITS driver blindly assumes that EventIDs are in abundant supply, to the
+point where it never checks how many the hardware actually supports.
+
+It turns out that some pretty esoteric integrations make it so that only a
+few bits are available, all the way down to a single bit.
+
+Enforce the advertised limitation at the point of allocating the device
+structure, and hope that the endpoint driver can deal with such limitation.
+
+Fixes: 84a6a2e7fc18d ("irqchip: GICv3: ITS: device allocation and configuration")
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Signed-off-by: Thomas Gleixner <tglx@kernel.org>
+Reviewed-by: Robin Murphy <robin.murphy@arm.com>
+Reviewed-by: Zenghui Yu <zenghui.yu@linux.dev>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260206154816.3582887-1-maz@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-gic-v3-its.c | 4 ++++
+ include/linux/irqchip/arm-gic-v3.h | 1 +
+ 2 files changed, 5 insertions(+)
+
+--- a/drivers/irqchip/irq-gic-v3-its.c
++++ b/drivers/irqchip/irq-gic-v3-its.c
+@@ -3382,6 +3382,7 @@ static struct its_device *its_create_dev
+ int lpi_base;
+ int nr_lpis;
+ int nr_ites;
++ int id_bits;
+ int sz;
+
+ if (!its_alloc_device_table(its, dev_id))
+@@ -3394,7 +3395,10 @@ static struct its_device *its_create_dev
+ /*
+ * Even if the device wants a single LPI, the ITT must be
+ * sized as a power of two (and you need at least one bit...).
++ * Also honor the ITS's own EID limit.
+ */
++ id_bits = FIELD_GET(GITS_TYPER_IDBITS, its->typer) + 1;
++ nvecs = min_t(unsigned int, nvecs, BIT(id_bits));
+ nr_ites = max(2, nvecs);
+ sz = nr_ites * (FIELD_GET(GITS_TYPER_ITT_ENTRY_SIZE, its->typer) + 1);
+ sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1;
+--- a/include/linux/irqchip/arm-gic-v3.h
++++ b/include/linux/irqchip/arm-gic-v3.h
+@@ -394,6 +394,7 @@
+ #define GITS_TYPER_VLPIS (1UL << 1)
+ #define GITS_TYPER_ITT_ENTRY_SIZE_SHIFT 4
+ #define GITS_TYPER_ITT_ENTRY_SIZE GENMASK_ULL(7, 4)
++#define GITS_TYPER_IDBITS GENMASK_ULL(12, 8)
+ #define GITS_TYPER_IDBITS_SHIFT 8
+ #define GITS_TYPER_DEVBITS_SHIFT 13
+ #define GITS_TYPER_DEVBITS GENMASK_ULL(17, 13)
--- /dev/null
+From feae40a6a178bb525a15f19288016e5778102a99 Mon Sep 17 00:00:00 2001
+From: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
+Date: Wed, 10 Dec 2025 12:26:51 +0100
+Subject: ixgbevf: fix link setup issue
+
+From: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
+
+commit feae40a6a178bb525a15f19288016e5778102a99 upstream.
+
+It may happen that VF spawned for E610 adapter has problem with setting
+link up. This happens when ixgbevf supporting mailbox API 1.6 cooperates
+with PF driver which doesn't support this version of API, and hence
+doesn't support new approach for getting PF link data.
+
+In that case VF asks PF to provide link data but as PF doesn't support
+it, returns -EOPNOTSUPP what leads to early bail from link configuration
+sequence.
+
+Avoid such situation by using legacy VFLINKS approach whenever negotiated
+API version is less than 1.6.
+
+To reproduce the issue just create VF and set its link up - adapter must
+be any from the E610 family, ixgbevf must support API 1.6 or higher while
+ixgbevf must not.
+
+Fixes: 53f0eb62b4d2 ("ixgbevf: fix getting link speed data for E610 devices")
+Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
+Reviewed-by: Piotr Kwapulinski <piotr.kwapulinski@intel.com>
+Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
+Cc: stable@vger.kernel.org
+Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
+Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/intel/ixgbevf/vf.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c b/drivers/net/ethernet/intel/ixgbevf/vf.c
+index 74d320879513..b67b580f7f1c 100644
+--- a/drivers/net/ethernet/intel/ixgbevf/vf.c
++++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
+@@ -852,7 +852,8 @@ static s32 ixgbevf_check_mac_link_vf(struct ixgbe_hw *hw,
+ if (!mac->get_link_status)
+ goto out;
+
+- if (hw->mac.type == ixgbe_mac_e610_vf) {
++ if (hw->mac.type == ixgbe_mac_e610_vf &&
++ hw->api_version >= ixgbe_mbox_api_16) {
+ ret_val = ixgbevf_get_pf_link_state(hw, speed, link_up);
+ if (ret_val)
+ goto out;
+--
+2.53.0
+
ceph-fix-i_nlink-underrun-during-async-unlink.patch
time-add-kernel-doc-in-time.c.patch
time-jiffies-mark-jiffies_64_to_clock_t-notrace.patch
+drm-bridge-ti-sn65dsi86-enable-hpd-polling-if-irq-is-not-used.patch
+device-property-allow-secondary-lookup-in-fwnode_get_next_child_node.patch
+irqchip-gic-v3-its-limit-number-of-per-device-msis-to-the-range-the-its-supports.patch
+ixgbevf-fix-link-setup-issue.patch
+staging-rtl8723bs-properly-validate-the-data-in-rtw_get_ie_ex.patch
+staging-rtl8723bs-fix-potential-out-of-bounds-read-in-rtw_restruct_wmm_ie.patch
--- /dev/null
+From a75281626fc8fa6dc6c9cc314ee423e8bc45203b Mon Sep 17 00:00:00 2001
+From: Luka Gejak <luka.gejak@linux.dev>
+Date: Tue, 24 Feb 2026 14:26:47 +0100
+Subject: staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie
+
+From: Luka Gejak <luka.gejak@linux.dev>
+
+commit a75281626fc8fa6dc6c9cc314ee423e8bc45203b upstream.
+
+The current code checks 'i + 5 < in_len' at the end of the if statement.
+However, it accesses 'in_ie[i + 5]' before that check, which can lead
+to an out-of-bounds read. Move the length check to the beginning of the
+conditional to ensure the index is within bounds before accessing the
+array.
+
+Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
+Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
+Link: https://patch.msgid.link/20260224132647.11642-2-luka.gejak@linux.dev
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/rtl8723bs/core/rtw_mlme.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
++++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
+@@ -2010,7 +2010,10 @@ int rtw_restruct_wmm_ie(struct adapter *
+ while (i < in_len) {
+ ielength = initial_out_len;
+
+- if (in_ie[i] == 0xDD && in_ie[i+2] == 0x00 && in_ie[i+3] == 0x50 && in_ie[i+4] == 0xF2 && in_ie[i+5] == 0x02 && i+5 < in_len) { /* WMM element ID and OUI */
++ if (i + 5 < in_len &&
++ in_ie[i] == 0xDD && in_ie[i + 2] == 0x00 &&
++ in_ie[i + 3] == 0x50 && in_ie[i + 4] == 0xF2 &&
++ in_ie[i + 5] == 0x02) {
+ for (j = i; j < i + 9; j++) {
+ out_ie[ielength] = in_ie[j];
+ ielength++;
--- /dev/null
+From f0109b9d3e1e455429279d602f6276e34689750a Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Date: Mon, 23 Feb 2026 14:31:35 +0100
+Subject: staging: rtl8723bs: properly validate the data in rtw_get_ie_ex()
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+commit f0109b9d3e1e455429279d602f6276e34689750a upstream.
+
+Just like in commit 154828bf9559 ("staging: rtl8723bs: fix out-of-bounds
+read in rtw_get_ie() parser"), we don't trust the data in the frame so
+we should check the length better before acting on it
+
+Cc: stable <stable@kernel.org>
+Assisted-by: gkh_clanker_2000
+Tested-by: Navaneeth K <knavaneeth786@gmail.com>
+Reviewed-by: Navaneeth K <knavaneeth786@gmail.com>
+Link: https://patch.msgid.link/2026022336-arrange-footwork-6e54@gregkh
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/rtl8723bs/core/rtw_ieee80211.c | 15 ++++++++++-----
+ 1 file changed, 10 insertions(+), 5 deletions(-)
+
+--- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
++++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
+@@ -186,20 +186,25 @@ u8 *rtw_get_ie_ex(u8 *in_ie, uint in_len
+
+ cnt = 0;
+
+- while (cnt < in_len) {
++ while (cnt + 2 <= in_len) {
++ u8 ie_len = in_ie[cnt + 1];
++
++ if (cnt + 2 + ie_len > in_len)
++ break;
++
+ if (eid == in_ie[cnt]
+- && (!oui || !memcmp(&in_ie[cnt+2], oui, oui_len))) {
++ && (!oui || (ie_len >= oui_len && !memcmp(&in_ie[cnt + 2], oui, oui_len)))) {
+ target_ie = &in_ie[cnt];
+
+ if (ie)
+- memcpy(ie, &in_ie[cnt], in_ie[cnt+1]+2);
++ memcpy(ie, &in_ie[cnt], ie_len + 2);
+
+ if (ielen)
+- *ielen = in_ie[cnt+1]+2;
++ *ielen = ie_len + 2;
+
+ break;
+ }
+- cnt += in_ie[cnt+1]+2; /* goto next */
++ cnt += ie_len + 2; /* goto next */
+ }
+
+ return target_ie;
projects / thirdparty / kernel / stable-queue.git / commitdiff
