From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Sasha Levin <sashal@kernel.org>,
Paul Menzel <pmenzel@molgen.mpg.de>,
Rinitha S <sx.rinitha@intel.com>,
przemyslaw.kitszel@intel.com,
Aleksandr Loktionov <aleksandr.loktionov@intel.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Simon Horman <horms@kernel.org>,
intel-wired-lan@lists.osuosl.org
Subject: [Intel-wired-lan] [PATCH AUTOSEL 6.18-6.12] ice: Allow 100M speed for E825C SGMII device
Date: Mon, 8 Dec 2025 19:15:37 -0500 [thread overview]
Message-ID: <20251209001610.611575-45-sashal@kernel.org> (raw)
In-Reply-To: <20251209001610.611575-1-sashal@kernel.org>
From: Grzegorz Nitka <grzegorz.nitka@intel.com>
[ Upstream commit ba2807b869a16d36b8bc76efa774fe433b3c45de ]
Add E825C 10GbE SGMII device to the list of devices supporting 100Mbit
link mode. Without that change, 100Mbit link mode is ignored in ethtool
interface. This change was missed while adding the support for E825C
devices family.
Testing hints (please note, for previous version, 100baseT/Full entry
was missing):
[root@localhost]# ethtool eth3
Settings for eth3:
Supported ports: [ TP ]
Supported link modes: 100baseT/Full
1000baseT/Full
10000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: None
Advertised link modes: 100baseT/Full
1000baseT/Full
10000baseT/Full
...
Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have a complete understanding. Let me summarize my analysis:
## DETAILED ANALYSIS
### 1. COMMIT MESSAGE ANALYSIS
**Subject:** `ice: Allow 100M speed for E825C SGMII device`
**Key phrases in commit message:**
- "This change was missed while adding the support for E825C devices
family" - This explicitly acknowledges this is a bug fix for a missed
case when E825C was introduced
- "Without that change, 100Mbit link mode is ignored in ethtool
interface" - Describes the user-visible symptom
**Missing tags:**
- No `Fixes:` tag (should logically point to `f64e189442332` - "ice:
introduce new E825C devices family")
- No `Cc: stable@vger.kernel.org` tag
**Tags present:**
- Multiple `Reviewed-by:` tags (3 reviewers including Simon Horman)
- `Tested-by:` tag from Intel QA
### 2. CODE CHANGE ANALYSIS
The change is extremely minimal - adding a single line to a switch
statement:
```c
bool ice_is_100m_speed_supported(struct ice_hw *hw)
{
switch (hw->device_id) {
case ICE_DEV_ID_E822C_SGMII:
case ICE_DEV_ID_E822L_SGMII:
case ICE_DEV_ID_E823L_1GBE:
case ICE_DEV_ID_E823C_SGMII:
+ case ICE_DEV_ID_E825C_SGMII: // <-- NEW LINE ADDED
return true;
default:
return false;
}
}
```
**Technical mechanism:**
- The `ice_is_100m_speed_supported()` function is called by
`ice_mask_min_supported_speeds()` in `ice_ethtool.c`
- This function is used to determine which link speeds to report to
ethtool as supported
- When `ice_is_100m_speed_supported()` returns `false`, the code masks
off 100Mbit phy types (`ICE_PHY_TYPE_LOW_100BASE_TX` and
`ICE_PHY_TYPE_LOW_100M_SGMII`)
- Without this fix, E825C SGMII devices (PCI ID 0x579F) cannot advertise
or use 100Mbit mode via ethtool, even though the hardware supports it
**Root cause:** When E825C support was added in commit `f64e189442332`,
the developer forgot to also add `ICE_DEV_ID_E825C_SGMII` to the
`ice_is_100m_speed_supported()` function. All other E8xx SGMII devices
were already included.
### 3. CLASSIFICATION
**Type:** Bug fix - Missing device ID in a capability function
**Category analysis:**
- ✅ **Device ID addition to existing driver** - This is adding a device
ID to an existing whitelist function
- ❌ Not a new feature - The 100M speed support exists, just missing one
device
- ❌ Not a security fix
- ✅ Hardware capability fix - Enables correct hardware capability
reporting
### 4. SCOPE AND RISK ASSESSMENT
**Size:** 1 line added to 1 file
**Risk level:** EXTREMELY LOW
- The change adds a single `case` label to a switch statement
- The function returns a boolean indicating device capability
- No logic changes, no side effects, no behavior changes for any other
device
- The E825C_SGMII device ID (0x579F) already exists and is used in other
places in the driver
- Multiple reviewers including Simon Horman
**Subsystem:** Intel ice network driver (mature, widely used, well-
tested)
### 5. USER IMPACT
**Who is affected:**
- Users with Intel E825-C SGMII network devices (PCI ID 0x579F)
- These are specific embedded/enterprise networking devices
**Symptom without fix:**
- `ethtool` shows 100Mbit as NOT supported when it should be
- Users cannot force 100Mbit link mode even if needed
- Misleading capability reporting in network management tools
**Severity:** Medium-Low
- Not a crash, security issue, or data corruption
- Affects device functionality/usability
- Users with this specific hardware are affected
### 6. STABILITY INDICATORS
**Positive signals:**
- `Reviewed-by: Simon Horman <horms@kernel.org>` (well-known networking
reviewer)
- `Reviewed-by: Aleksandr Loktionov` (Intel)
- `Reviewed-by: Paul Menzel`
- `Tested-by: Rinitha S` (Intel QA)
- Commit signed off by Intel maintainer Tony Nguyen
### 7. DEPENDENCY CHECK
**Dependencies:**
- Requires E825C device support (introduced in v6.9-rc1 via
`f64e189442332`)
- Requires `ice_is_100m_speed_supported()` function (introduced in
v6.1-rc1 via `39ed02a4ba527`)
**Stable tree applicability:**
- v6.6.y: ❌ No E825C support, commit NOT applicable
- v6.10.y: ✅ Has E825C support and `ice_is_100m_speed_supported()`,
commit APPLICABLE
- v6.11.y: ✅ APPLICABLE
- v6.12.y: ✅ APPLICABLE
### 8. STABLE KERNEL RULES ASSESSMENT
| Rule | Assessment |
|------|------------|
| Obviously correct and tested | ✅ Yes - trivial addition, well-
reviewed, tested |
| Fixes real bug that affects users | ✅ Yes - 100Mbit mode not available
on E825C SGMII |
| Important issue | ⚠️ Moderate - not critical but affects device
usability |
| Small and contained | ✅ Yes - 1 line change |
| No new features | ✅ Yes - enables existing functionality |
| No new APIs | ✅ Yes |
| Applies cleanly | ✅ Should apply cleanly to v6.10+ |
### CONCERNS
1. **No explicit stable markers:** The commit lacks `Cc:
stable@vger.kernel.org` and `Fixes:` tags, suggesting the
developer/maintainer didn't explicitly request backport
2. **Only applies to kernels with E825C support:** This fix is ONLY
meaningful for kernels v6.10+ that have E825C device support.
Backporting to v6.6.y would be pointless since those kernels don't
have E825C at all.
3. **Not a critical fix:** While it's a real bug, it's not a crash,
security issue, or data corruption - it's a feature parity/usability
issue.
### RECOMMENDATION
This commit **SHOULD be backported** to stable kernels that have E825C
support (v6.10+, v6.11+, v6.12+) for the following reasons:
1. **Clearly a bug fix:** The commit message explicitly states "This
change was missed while adding the support for E825C devices family"
2. **Trivial and safe:** Single line addition to a capability whitelist
- minimal risk
3. **Well-reviewed and tested:** Multiple reviewers and explicit testing
4. **Follows the device ID exception:** Adding device IDs to existing
functions is a well-accepted stable practice
5. **Fixes real user issue:** Users with E825C SGMII hardware cannot
configure 100Mbit mode
The lack of explicit stable tags appears to be an oversight rather than
a deliberate decision to not backport. The change is clearly in the
category of "hardware quirks/device ID additions that enable proper
hardware support."
**YES**
drivers/net/ethernet/intel/ice/ice_common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c
index 2532b6f82e971..449418cf06c20 100644
--- a/drivers/net/ethernet/intel/ice/ice_common.c
+++ b/drivers/net/ethernet/intel/ice/ice_common.c
@@ -3389,6 +3389,7 @@ bool ice_is_100m_speed_supported(struct ice_hw *hw)
case ICE_DEV_ID_E822L_SGMII:
case ICE_DEV_ID_E823L_1GBE:
case ICE_DEV_ID_E823C_SGMII:
+ case ICE_DEV_ID_E825C_SGMII:
return true;
default:
return false;
--
2.51.0
WARNING: multiple messages have this Message-ID (diff)
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Grzegorz Nitka <grzegorz.nitka@intel.com>,
Aleksandr Loktionov <aleksandr.loktionov@intel.com>,
Paul Menzel <pmenzel@molgen.mpg.de>,
Simon Horman <horms@kernel.org>, Rinitha S <sx.rinitha@intel.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Sasha Levin <sashal@kernel.org>,
przemyslaw.kitszel@intel.com, intel-wired-lan@lists.osuosl.org
Subject: [PATCH AUTOSEL 6.18-6.12] ice: Allow 100M speed for E825C SGMII device
Date: Mon, 8 Dec 2025 19:15:37 -0500 [thread overview]
Message-ID: <20251209001610.611575-45-sashal@kernel.org> (raw)
In-Reply-To: <20251209001610.611575-1-sashal@kernel.org>
From: Grzegorz Nitka <grzegorz.nitka@intel.com>
[ Upstream commit ba2807b869a16d36b8bc76efa774fe433b3c45de ]
Add E825C 10GbE SGMII device to the list of devices supporting 100Mbit
link mode. Without that change, 100Mbit link mode is ignored in ethtool
interface. This change was missed while adding the support for E825C
devices family.
Testing hints (please note, for previous version, 100baseT/Full entry
was missing):
[root@localhost]# ethtool eth3
Settings for eth3:
Supported ports: [ TP ]
Supported link modes: 100baseT/Full
1000baseT/Full
10000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: None
Advertised link modes: 100baseT/Full
1000baseT/Full
10000baseT/Full
...
Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have a complete understanding. Let me summarize my analysis:
## DETAILED ANALYSIS
### 1. COMMIT MESSAGE ANALYSIS
**Subject:** `ice: Allow 100M speed for E825C SGMII device`
**Key phrases in commit message:**
- "This change was missed while adding the support for E825C devices
family" - This explicitly acknowledges this is a bug fix for a missed
case when E825C was introduced
- "Without that change, 100Mbit link mode is ignored in ethtool
interface" - Describes the user-visible symptom
**Missing tags:**
- No `Fixes:` tag (should logically point to `f64e189442332` - "ice:
introduce new E825C devices family")
- No `Cc: stable@vger.kernel.org` tag
**Tags present:**
- Multiple `Reviewed-by:` tags (3 reviewers including Simon Horman)
- `Tested-by:` tag from Intel QA
### 2. CODE CHANGE ANALYSIS
The change is extremely minimal - adding a single line to a switch
statement:
```c
bool ice_is_100m_speed_supported(struct ice_hw *hw)
{
switch (hw->device_id) {
case ICE_DEV_ID_E822C_SGMII:
case ICE_DEV_ID_E822L_SGMII:
case ICE_DEV_ID_E823L_1GBE:
case ICE_DEV_ID_E823C_SGMII:
+ case ICE_DEV_ID_E825C_SGMII: // <-- NEW LINE ADDED
return true;
default:
return false;
}
}
```
**Technical mechanism:**
- The `ice_is_100m_speed_supported()` function is called by
`ice_mask_min_supported_speeds()` in `ice_ethtool.c`
- This function is used to determine which link speeds to report to
ethtool as supported
- When `ice_is_100m_speed_supported()` returns `false`, the code masks
off 100Mbit phy types (`ICE_PHY_TYPE_LOW_100BASE_TX` and
`ICE_PHY_TYPE_LOW_100M_SGMII`)
- Without this fix, E825C SGMII devices (PCI ID 0x579F) cannot advertise
or use 100Mbit mode via ethtool, even though the hardware supports it
**Root cause:** When E825C support was added in commit `f64e189442332`,
the developer forgot to also add `ICE_DEV_ID_E825C_SGMII` to the
`ice_is_100m_speed_supported()` function. All other E8xx SGMII devices
were already included.
### 3. CLASSIFICATION
**Type:** Bug fix - Missing device ID in a capability function
**Category analysis:**
- ✅ **Device ID addition to existing driver** - This is adding a device
ID to an existing whitelist function
- ❌ Not a new feature - The 100M speed support exists, just missing one
device
- ❌ Not a security fix
- ✅ Hardware capability fix - Enables correct hardware capability
reporting
### 4. SCOPE AND RISK ASSESSMENT
**Size:** 1 line added to 1 file
**Risk level:** EXTREMELY LOW
- The change adds a single `case` label to a switch statement
- The function returns a boolean indicating device capability
- No logic changes, no side effects, no behavior changes for any other
device
- The E825C_SGMII device ID (0x579F) already exists and is used in other
places in the driver
- Multiple reviewers including Simon Horman
**Subsystem:** Intel ice network driver (mature, widely used, well-
tested)
### 5. USER IMPACT
**Who is affected:**
- Users with Intel E825-C SGMII network devices (PCI ID 0x579F)
- These are specific embedded/enterprise networking devices
**Symptom without fix:**
- `ethtool` shows 100Mbit as NOT supported when it should be
- Users cannot force 100Mbit link mode even if needed
- Misleading capability reporting in network management tools
**Severity:** Medium-Low
- Not a crash, security issue, or data corruption
- Affects device functionality/usability
- Users with this specific hardware are affected
### 6. STABILITY INDICATORS
**Positive signals:**
- `Reviewed-by: Simon Horman <horms@kernel.org>` (well-known networking
reviewer)
- `Reviewed-by: Aleksandr Loktionov` (Intel)
- `Reviewed-by: Paul Menzel`
- `Tested-by: Rinitha S` (Intel QA)
- Commit signed off by Intel maintainer Tony Nguyen
### 7. DEPENDENCY CHECK
**Dependencies:**
- Requires E825C device support (introduced in v6.9-rc1 via
`f64e189442332`)
- Requires `ice_is_100m_speed_supported()` function (introduced in
v6.1-rc1 via `39ed02a4ba527`)
**Stable tree applicability:**
- v6.6.y: ❌ No E825C support, commit NOT applicable
- v6.10.y: ✅ Has E825C support and `ice_is_100m_speed_supported()`,
commit APPLICABLE
- v6.11.y: ✅ APPLICABLE
- v6.12.y: ✅ APPLICABLE
### 8. STABLE KERNEL RULES ASSESSMENT
| Rule | Assessment |
|------|------------|
| Obviously correct and tested | ✅ Yes - trivial addition, well-
reviewed, tested |
| Fixes real bug that affects users | ✅ Yes - 100Mbit mode not available
on E825C SGMII |
| Important issue | ⚠️ Moderate - not critical but affects device
usability |
| Small and contained | ✅ Yes - 1 line change |
| No new features | ✅ Yes - enables existing functionality |
| No new APIs | ✅ Yes |
| Applies cleanly | ✅ Should apply cleanly to v6.10+ |
### CONCERNS
1. **No explicit stable markers:** The commit lacks `Cc:
stable@vger.kernel.org` and `Fixes:` tags, suggesting the
developer/maintainer didn't explicitly request backport
2. **Only applies to kernels with E825C support:** This fix is ONLY
meaningful for kernels v6.10+ that have E825C device support.
Backporting to v6.6.y would be pointless since those kernels don't
have E825C at all.
3. **Not a critical fix:** While it's a real bug, it's not a crash,
security issue, or data corruption - it's a feature parity/usability
issue.
### RECOMMENDATION
This commit **SHOULD be backported** to stable kernels that have E825C
support (v6.10+, v6.11+, v6.12+) for the following reasons:
1. **Clearly a bug fix:** The commit message explicitly states "This
change was missed while adding the support for E825C devices family"
2. **Trivial and safe:** Single line addition to a capability whitelist
- minimal risk
3. **Well-reviewed and tested:** Multiple reviewers and explicit testing
4. **Follows the device ID exception:** Adding device IDs to existing
functions is a well-accepted stable practice
5. **Fixes real user issue:** Users with E825C SGMII hardware cannot
configure 100Mbit mode
The lack of explicit stable tags appears to be an oversight rather than
a deliberate decision to not backport. The change is clearly in the
category of "hardware quirks/device ID additions that enable proper
hardware support."
**YES**
drivers/net/ethernet/intel/ice/ice_common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c
index 2532b6f82e971..449418cf06c20 100644
--- a/drivers/net/ethernet/intel/ice/ice_common.c
+++ b/drivers/net/ethernet/intel/ice/ice_common.c
@@ -3389,6 +3389,7 @@ bool ice_is_100m_speed_supported(struct ice_hw *hw)
case ICE_DEV_ID_E822L_SGMII:
case ICE_DEV_ID_E823L_1GBE:
case ICE_DEV_ID_E823C_SGMII:
+ case ICE_DEV_ID_E825C_SGMII:
return true;
default:
return false;
--
2.51.0
next prev parent reply other threads:[~2025-12-09 0:18 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-09 0:14 [PATCH AUTOSEL 6.18-6.1] ksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrency Sasha Levin
2025-12-09 0:14 ` [PATCH AUTOSEL 6.18-6.17] wifi: rtw89: use skb_dequeue() for queued ROC packets to prevent racing Sasha Levin
2025-12-09 0:14 ` [PATCH AUTOSEL 6.18-6.6] ipv6: clean up routes when manually removing address with a lifetime Sasha Levin
2025-12-09 0:14 ` [PATCH AUTOSEL 6.18-5.10] ext4: remove page offset calculation in ext4_block_zero_page_range() Sasha Levin
2025-12-09 0:14 ` [PATCH AUTOSEL 6.18-6.6] fs/ntfs3: fix KMSAN uninit-value in ni_create_attr_list Sasha Levin
2025-12-09 0:14 ` [PATCH AUTOSEL 6.18-6.6] btrfs: abort transaction on item count overflow in __push_leaf_left() Sasha Levin
2025-12-09 0:14 ` [PATCH AUTOSEL 6.18-6.1] smb/server: fix return value of smb2_ioctl() Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.1] gfs2: Fix use of bio_chain Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-5.10] Bluetooth: btusb: Add new VID/PID 13d3/3533 for RTL8821CE Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.12] wifi: mac80211: reset CRC valid after CSA Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.12] Bluetooth: btusb: Add new VID/PID 0x0489/0xE12F for RTL8852BE-VT Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-5.10] wifi: mt76: mmio_*_copy fix byte order and alignment Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-5.10] btrfs: scrub: always update btrfs_scrub_progress::last_physical Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.12] bpf: Skip bounds adjustment for conditional jumps on same scalar register Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.12] wifi: rtl8xxxu: Fix HT40 channel config for RTL8192CU, RTL8723AU Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.12] Bluetooth: btusb: MT7920: Add VID/PID 0489/e135 Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.12] Bluetooth: btusb: MT7922: Add VID/PID 0489/e170 Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.12] virtio_blk: NULL out vqs to avoid double free on failed resume Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.1] kbuild: Use objtree for module signing key path Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.17] btrfs: use kvcalloc for btrfs_bio::csum allocation Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.12] net: sched: Don't use WARN_ON_ONCE() for -ENOMEM in tcf_classify() Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-5.10] hfsplus: Verify inode mode when loading from disk Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.6] gfs2: fix remote evict for read-only filesystems Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-5.10] net: amd-xgbe: use EOPNOTSUPP instead of ENOTSUPP in xgbe_phy_mii_read_c45 Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-5.10] net: init shinfo->gso_segs from qdisc_pkt_len_init() Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.17] Bluetooth: btusb: add new custom firmwares Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-5.10] hfsplus: fix missing hfs_bnode_get() in __hfs_bnode_create Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.12] cxgb4: Rename sched_class to avoid type clash Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.12] net: mana: Drop TX skb on post_work_request failure and unmap resources Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-5.10] hfsplus: fix volume corruption issue for generic/070 Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.17] wifi: rtw89: rtw8852bu: Added dev id for ASUS AX57 NANO USB Wifi dongle Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-5.10] net: restore napi_consume_skb()'s NULL-handling Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-5.15] fs/ntfs3: Support timestamps prior to epoch Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.1] smb/server: fix return value of smb2_query_dir() Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.17] wifi: rtw88: Add BUFFALO WI-U3-866DHP to the USB ID list Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.6] Bluetooth: btusb: Add new VID/PID 2b89/6275 for RTL8761BUV Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.12] bpf: Disable file_alloc_security hook Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.1] wifi: rtw89: phy: fix out-of-bounds access in rtw89_phy_read_txpwr_limit() Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.6] ntfs: set dummy blocksize to read boot_block when mounting Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-5.10] hfsplus: fix volume corruption issue for generic/073 Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.12] wifi: mt76: mt792x: fix wifi init fail by setting MCU_RUNNING after CLC load Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.12] gfs2: Fix "gfs2: Switch to wait_event in gfs2_quotad" Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.6] ksmbd: vfs: fix race on m_flags in vfs_cache Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.1] wifi: rtw89: flush TX queue before deleting key Sasha Levin
2025-12-09 0:15 ` Sasha Levin [this message]
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.12] ice: Allow 100M speed for E825C SGMII device Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251209001610.611575-45-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=aleksandr.loktionov@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=patches@lists.linux.dev \
--cc=pmenzel@molgen.mpg.de \
--cc=przemyslaw.kitszel@intel.com \
--cc=stable@vger.kernel.org \
--cc=sx.rinitha@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.