From: Mika Westerberg <mika.westerberg(a)linux.intel.com>
[ Upstream commit f7e37affbc9085f2b77ccb6596521a44eabf7505 ]
Add Intel Wildcat Lake SPI serial flash PCI ID to the list of supported
devices.
Signed-off-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Link: https://patch.msgid.link/20251020145415.3377022-4-mika.westerberg@linux.int…
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
LLM Generated explanations, may be completely bogus:
## BACKPORT ANALYSIS COMPLETE
**Backport Status: YES**
---
## DETAILED ANALYSIS
### 1. COMMIT CHARACTERIZATION
**Type**: Hardware enablement (PCI device ID addition)
**Code Changes**:
- Single line addition to `drivers/spi/spi-intel-pci.c`
- Adds PCI device ID `0x4d23` (Intel Wildcat Lake SPI serial flash)
- Maps to existing `cnl_info` configuration structure
- No behavioral changes to existing code paths
### 2. SEMANTIC CODE ANALYSIS FINDINGS
#### Tools Used:
- **Read**: Examined the complete file structure (drivers/spi/spi-intel-
pci.c:68-99)
- **Grep**: Located PCI device table usage and MODULE_DEVICE_TABLE macro
- **Git analysis**: Reviewed commit history and backport precedents
#### Impact Scope Analysis:
- **Direct impact**: Only affects systems with PCI ID 0x4d23 (Wildcat
Lake hardware)
- **Caller analysis**: The PCI device table is used by the kernel's PCI
subsystem for automatic device-driver matching
- **Dependency analysis**: Uses `cnl_info` structure (drivers/spi/spi-
intel-pci.c:38-41), which has existed since 2022
- **Risk assessment**: Zero risk to existing hardware - new entry only
triggers on matching PCI ID
### 3. BACKPORT PRECEDENT (Strong Evidence)
I found multiple similar commits that **WERE backported** to stable
trees:
**Example 1 - Lunar Lake-M** (commit ec33549be99fe):
```
commit ec33549be99fe25c6927c8b3d6ed13918b27656e
Author: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Commit: Sasha Levin <sashal(a)kernel.org> [STABLE MAINTAINER]
spi: intel-pci: Add support for Lunar Lake-M SPI serial flash
[ Upstream commit 8f44e3808200c1434c26ef459722f88f48b306df ]
```
**Example 2 - Granite Rapids** (commit 60446b5e74865):
```
commit 60446b5e74865acff1af5f2d89d99551c8e6e2c1
Author: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Commit: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> [STABLE
MAINTAINER]
spi: intel-pci: Add support for Granite Rapids SPI serial flash
[ Upstream commit 9855d60cfc720ff32355484c119acafd3c4dc806 ]
```
**Key Finding**: Both commits were backported to stable trees by stable
maintainers (Sasha Levin, Greg Kroah-Hartman) **despite having NO
explicit stable tags** in the original commits.
### 4. STABLE TREE COMPLIANCE
**Positive Factors**:
- ✅ Fixes a real user problem (Wildcat Lake users cannot access SPI
flash on stable kernels)
- ✅ Extremely low risk (single line, static table entry)
- ✅ No architectural changes
- ✅ No dependencies on unreleased features
- ✅ Follows established backporting pattern for PCI ID additions
- ✅ "Obviously correct" - uses tested configuration from 20+ other Intel
platforms
**Considerations**:
- ⚠️ Technically a "new feature" (new hardware support)
- ✅ However, PCI ID additions are a **special exception** routinely
accepted by stable maintainers
- ✅ Hardware enablement is considered "fixing" missing support for
existing hardware
### 5. DEPENDENCY VERIFICATION
- **cnl_info structure**: Present since 2022, exists in all stable
kernels that would receive this backport
- **PCI_VDEVICE macro**: Standard kernel infrastructure
- **intel_spi_probe()**: Core function, no recent changes that would
conflict
- **Clean backport**: No conflicts expected with any stable kernel
version
### 6. RISK ANALYSIS
**Regression Risk**: **MINIMAL**
- Only triggered when PCI ID 0x4d23 is detected
- No effect on systems without Wildcat Lake hardware
- Uses well-tested code path (cnl_info shared with 20+ other platforms)
- No user-space API changes
**Testing Coverage**:
- Same code path used by numerous Intel platforms (Ice Lake, Tiger Lake,
Alder Lake, etc.)
- Configuration structure (cnl_info) battle-tested across multiple
generations
### 7. COMMIT MESSAGE ANALYSIS
The commit message is:
- ✅ Clear and descriptive
- ✅ Identifies specific hardware (Intel Wildcat Lake)
- ✅ Consistent with previous similar commits
- ❌ No "Fixes:" tag (not applicable - this is new hardware support)
- ❌ No "Cc: stable(a)vger.kernel.org" tag (but precedent shows this
doesn't prevent backporting)
---
## RECOMMENDATION
**YES - This commit SHOULD be backported to stable kernel trees**
### Rationale:
1. **Strong precedent**: Multiple similar PCI ID additions for Intel
platforms (Lunar Lake, Granite Rapids, Arrow Lake) have been
backported to stable trees by stable maintainers
2. **User benefit**: Enables critical SPI flash functionality for
Wildcat Lake hardware owners running stable kernels
3. **Minimal risk**: Single-line change to static table with no impact
on existing hardware
4. **Well-established pattern**: PCI ID additions for hardware
enablement are routinely accepted for stable backports as they "fix"
missing hardware support
5. **Clean backport**: No dependencies or conflicts expected
### Target Stable Trees:
- All currently maintained stable kernels (6.17.x, 6.16.x, 6.15.x, etc.)
- The commit is from v6.18-rc3, so it would benefit users on any stable
kernel before 6.18
drivers/spi/spi-intel-pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-intel-pci.c b/drivers/spi/spi-intel-pci.c
index 4b63cb98df9cc..4bb158a23349e 100644
--- a/drivers/spi/spi-intel-pci.c
+++ b/drivers/spi/spi-intel-pci.c
@@ -75,6 +75,7 @@ static const struct pci_device_id intel_spi_pci_ids[] = {
{ PCI_VDEVICE(INTEL, 0x38a4), (unsigned long)&bxt_info },
{ PCI_VDEVICE(INTEL, 0x43a4), (unsigned long)&cnl_info },
{ PCI_VDEVICE(INTEL, 0x4b24), (unsigned long)&bxt_info },
+ { PCI_VDEVICE(INTEL, 0x4d23), (unsigned long)&cnl_info },
{ PCI_VDEVICE(INTEL, 0x4da4), (unsigned long)&bxt_info },
{ PCI_VDEVICE(INTEL, 0x51a4), (unsigned long)&cnl_info },
{ PCI_VDEVICE(INTEL, 0x54a4), (unsigned long)&cnl_info },
--
2.51.0
In thermal_of_cm_lookup(), of_parse_phandle() returns a device node with
its reference count incremented. The caller is responsible for releasing
this reference when the node is no longer needed.
Add of_node_put(tr_np) to fix the reference leaks.
Found via static analysis.
Fixes: 3fd6d6e2b4e8 ("thermal/of: Rework the thermal device tree initialization")
Cc: stable(a)vger.kernel.org
Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com>
---
drivers/thermal/thermal_of.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/thermal_of.c b/drivers/thermal/thermal_of.c
index 1a51a4d240ff..2bb1b8e471cf 100644
--- a/drivers/thermal/thermal_of.c
+++ b/drivers/thermal/thermal_of.c
@@ -284,8 +284,11 @@ static bool thermal_of_cm_lookup(struct device_node *cm_np,
int count, i;
tr_np = of_parse_phandle(child, "trip", 0);
- if (tr_np != trip->priv)
+ if (tr_np != trip->priv) {
+ of_node_put(tr_np);
continue;
+ }
+ of_node_put(tr_np);
/* The trip has been found, look up the cdev. */
count = of_count_phandle_with_args(child, "cooling-device",
--
2.39.5 (Apple Git-154)
The 2 argument version of v4l2_subdev_state_get_format() takes the pad
as second argument, not the stream.
Fixes: bc0e8d91feec ("media: v4l: subdev: Switch to stream-aware state functions")
Cc: stable(a)vger.kernel.org
Signed-off-by: Hans de Goede <hansg(a)kernel.org>
---
Note the problem pre-exists the Fixes: commit but backporting further
will require manual backports and seems unnecessary.
---
drivers/media/i2c/ov01a10.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ov01a10.c b/drivers/media/i2c/ov01a10.c
index f92867f542f0..0405ec7c75fd 100644
--- a/drivers/media/i2c/ov01a10.c
+++ b/drivers/media/i2c/ov01a10.c
@@ -731,7 +731,7 @@ static int ov01a10_set_format(struct v4l2_subdev *sd,
h_blank);
}
- format = v4l2_subdev_state_get_format(sd_state, fmt->stream);
+ format = v4l2_subdev_state_get_format(sd_state, fmt->pad);
*format = fmt->format;
return 0;
--
2.51.0
From: Benjamin Berg <benjamin.berg(a)intel.com>
The normal timer mechanism assume that timeout further in the future
need a lower accuracy. As an example, the granularity for a timer
scheduled 4096 ms in the future on a 1000 Hz system is already 512 ms.
This granularity is perfectly sufficient for e.g. timeouts, but there
are other types of events that will happen at a future point in time and
require a higher accuracy.
Add a new wiphy_hrtimer_work type that uses an hrtimer internally. The
API is almost identical to the existing wiphy_delayed_work and it can be
used as a drop-in replacement after minor adjustments. The work will be
scheduled relative to the current time with a slack of 1 millisecond.
CC: stable(a)vger.kernel.org # 6.4+
Signed-off-by: Benjamin Berg <benjamin.berg(a)intel.com>
Reviewed-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit(a)intel.com>
---
include/net/cfg80211.h | 78 ++++++++++++++++++++++++++++++++++++++++++
net/wireless/core.c | 56 ++++++++++++++++++++++++++++++
net/wireless/trace.h | 21 ++++++++++++
3 files changed, 155 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 781624f5913a..820e299f06b5 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -6435,6 +6435,11 @@ static inline void wiphy_delayed_work_init(struct wiphy_delayed_work *dwork,
* after wiphy_lock() was called. Therefore, wiphy_cancel_work() can
* use just cancel_work() instead of cancel_work_sync(), it requires
* being in a section protected by wiphy_lock().
+ *
+ * Note that these are scheduled with a timer where the accuracy
+ * becomes less the longer in the future the scheduled timer is. Use
+ * wiphy_hrtimer_work_queue() if the timer must be not be late by more
+ * than approximately 10 percent.
*/
void wiphy_delayed_work_queue(struct wiphy *wiphy,
struct wiphy_delayed_work *dwork,
@@ -6506,6 +6511,79 @@ void wiphy_delayed_work_flush(struct wiphy *wiphy,
bool wiphy_delayed_work_pending(struct wiphy *wiphy,
struct wiphy_delayed_work *dwork);
+struct wiphy_hrtimer_work {
+ struct wiphy_work work;
+ struct wiphy *wiphy;
+ struct hrtimer timer;
+};
+
+enum hrtimer_restart wiphy_hrtimer_work_timer(struct hrtimer *t);
+
+static inline void wiphy_hrtimer_work_init(struct wiphy_hrtimer_work *hrwork,
+ wiphy_work_func_t func)
+{
+ hrtimer_setup(&hrwork->timer, wiphy_hrtimer_work_timer,
+ CLOCK_BOOTTIME, HRTIMER_MODE_REL);
+ wiphy_work_init(&hrwork->work, func);
+}
+
+/**
+ * wiphy_hrtimer_work_queue - queue hrtimer work for the wiphy
+ * @wiphy: the wiphy to queue for
+ * @hrwork: the high resolution timer worker
+ * @delay: the delay given as a ktime_t
+ *
+ * Please refer to wiphy_delayed_work_queue(). The difference is that
+ * the hrtimer work uses a high resolution timer for scheduling. This
+ * may be needed if timeouts might be scheduled further in the future
+ * and the accuracy of the normal timer is not sufficient.
+ *
+ * Expect a delay of a few milliseconds as the timer is scheduled
+ * with some slack and some more time may pass between queueing the
+ * work and its start.
+ */
+void wiphy_hrtimer_work_queue(struct wiphy *wiphy,
+ struct wiphy_hrtimer_work *hrwork,
+ ktime_t delay);
+
+/**
+ * wiphy_hrtimer_work_cancel - cancel previously queued hrtimer work
+ * @wiphy: the wiphy, for debug purposes
+ * @hrtimer: the hrtimer work to cancel
+ *
+ * Cancel the work *without* waiting for it, this assumes being
+ * called under the wiphy mutex acquired by wiphy_lock().
+ */
+void wiphy_hrtimer_work_cancel(struct wiphy *wiphy,
+ struct wiphy_hrtimer_work *hrtimer);
+
+/**
+ * wiphy_hrtimer_work_flush - flush previously queued hrtimer work
+ * @wiphy: the wiphy, for debug purposes
+ * @hrwork: the hrtimer work to flush
+ *
+ * Flush the work (i.e. run it if pending). This must be called
+ * under the wiphy mutex acquired by wiphy_lock().
+ */
+void wiphy_hrtimer_work_flush(struct wiphy *wiphy,
+ struct wiphy_hrtimer_work *hrwork);
+
+/**
+ * wiphy_hrtimer_work_pending - Find out whether a wiphy hrtimer
+ * work item is currently pending.
+ *
+ * @wiphy: the wiphy, for debug purposes
+ * @hrwork: the hrtimer work in question
+ *
+ * Return: true if timer is pending, false otherwise
+ *
+ * Please refer to the wiphy_delayed_work_pending() documentation as
+ * this is the equivalent function for hrtimer based delayed work
+ * items.
+ */
+bool wiphy_hrtimer_work_pending(struct wiphy *wiphy,
+ struct wiphy_hrtimer_work *hrwork);
+
/**
* enum ieee80211_ap_reg_power - regulatory power for an Access Point
*
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 797f9f2004a6..54a34d8d356e 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -1787,6 +1787,62 @@ bool wiphy_delayed_work_pending(struct wiphy *wiphy,
}
EXPORT_SYMBOL_GPL(wiphy_delayed_work_pending);
+enum hrtimer_restart wiphy_hrtimer_work_timer(struct hrtimer *t)
+{
+ struct wiphy_hrtimer_work *hrwork =
+ container_of(t, struct wiphy_hrtimer_work, timer);
+
+ wiphy_work_queue(hrwork->wiphy, &hrwork->work);
+
+ return HRTIMER_NORESTART;
+}
+EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_timer);
+
+void wiphy_hrtimer_work_queue(struct wiphy *wiphy,
+ struct wiphy_hrtimer_work *hrwork,
+ ktime_t delay)
+{
+ trace_wiphy_hrtimer_work_queue(wiphy, &hrwork->work, delay);
+
+ if (!delay) {
+ hrtimer_cancel(&hrwork->timer);
+ wiphy_work_queue(wiphy, &hrwork->work);
+ return;
+ }
+
+ hrwork->wiphy = wiphy;
+ hrtimer_start_range_ns(&hrwork->timer, delay,
+ 1000 * NSEC_PER_USEC, HRTIMER_MODE_REL);
+}
+EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_queue);
+
+void wiphy_hrtimer_work_cancel(struct wiphy *wiphy,
+ struct wiphy_hrtimer_work *hrwork)
+{
+ lockdep_assert_held(&wiphy->mtx);
+
+ hrtimer_cancel(&hrwork->timer);
+ wiphy_work_cancel(wiphy, &hrwork->work);
+}
+EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_cancel);
+
+void wiphy_hrtimer_work_flush(struct wiphy *wiphy,
+ struct wiphy_hrtimer_work *hrwork)
+{
+ lockdep_assert_held(&wiphy->mtx);
+
+ hrtimer_cancel(&hrwork->timer);
+ wiphy_work_flush(wiphy, &hrwork->work);
+}
+EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_flush);
+
+bool wiphy_hrtimer_work_pending(struct wiphy *wiphy,
+ struct wiphy_hrtimer_work *hrwork)
+{
+ return hrtimer_is_queued(&hrwork->timer);
+}
+EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_pending);
+
static int __init cfg80211_init(void)
{
int err;
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index 8a4c34112eb5..2b71f1d867a0 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -304,6 +304,27 @@ TRACE_EVENT(wiphy_delayed_work_queue,
__entry->delay)
);
+TRACE_EVENT(wiphy_hrtimer_work_queue,
+ TP_PROTO(struct wiphy *wiphy, struct wiphy_work *work,
+ ktime_t delay),
+ TP_ARGS(wiphy, work, delay),
+ TP_STRUCT__entry(
+ WIPHY_ENTRY
+ __field(void *, instance)
+ __field(void *, func)
+ __field(ktime_t, delay)
+ ),
+ TP_fast_assign(
+ WIPHY_ASSIGN;
+ __entry->instance = work;
+ __entry->func = work->func;
+ __entry->delay = delay;
+ ),
+ TP_printk(WIPHY_PR_FMT " instance=%p func=%pS delay=%llu",
+ WIPHY_PR_ARG, __entry->instance, __entry->func,
+ __entry->delay)
+);
+
TRACE_EVENT(wiphy_work_worker_start,
TP_PROTO(struct wiphy *wiphy),
TP_ARGS(wiphy),
--
2.34.1
In omap_usb2_probe(), of_parse_phandle() returns a device node with its
reference count incremented. The caller is responsible for releasing this
reference when the node is no longer needed.
Add of_node_put(control_node) after usage to fix the
reference leak.
Found via static analysis.
Fixes: 478b6c7436c2 ("usb: phy: omap-usb2: Don't use omap_get_control_dev()")
Cc: stable(a)vger.kernel.org
Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com>
---
drivers/phy/ti/phy-omap-usb2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/ti/phy-omap-usb2.c b/drivers/phy/ti/phy-omap-usb2.c
index 1eb252604441..660df3181e4f 100644
--- a/drivers/phy/ti/phy-omap-usb2.c
+++ b/drivers/phy/ti/phy-omap-usb2.c
@@ -426,6 +426,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
}
control_pdev = of_find_device_by_node(control_node);
+ of_node_put(control_node);
if (!control_pdev) {
dev_err(&pdev->dev, "Failed to get control device\n");
return -EINVAL;
--
2.39.5 (Apple Git-154)