From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Hiroaki Yamamoto <hrak1529@gmail.com>,
Ping-Ke Shih <pkshih@realtek.com>,
Sasha Levin <sashal@kernel.org>,
linux-wireless@vger.kernel.org
Subject: [PATCH AUTOSEL 6.18-6.17] wifi: rtw88: Add BUFFALO WI-U3-866DHP to the USB ID list
Date: Mon, 8 Dec 2025 19:15:27 -0500 [thread overview]
Message-ID: <20251209001610.611575-35-sashal@kernel.org> (raw)
In-Reply-To: <20251209001610.611575-1-sashal@kernel.org>
From: Hiroaki Yamamoto <hrak1529@gmail.com>
[ Upstream commit 8adb609f645b42148c14989066a971bbb5f3587e ]
BUFFALO WI-U3-866DHP (0411:03d0) is based on rtl8812bu. I locally tested
this patch with a retail sample and it worked fine.
Signed-off-by: Hiroaki Yamamoto <hrak1529@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20251031111641.33653-1-hrak1529@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have a complete picture. Let me provide my thorough analysis:
---
## Comprehensive Analysis
### 1. COMMIT MESSAGE ANALYSIS
**Subject:** `wifi: rtw88: Add BUFFALO WI-U3-866DHP to the USB ID list`
**Body:**
- States the device USB VID/PID: `0411:03d0` (BUFFALO is vendor 0x0411)
- Claims the device is "based on rtl8812bu" (RTL8822B chipset)
- Author tested with a retail sample and confirms it works
**Tags:**
- `Signed-off-by: Hiroaki Yamamoto` (author/contributor)
- `Acked-by: Ping-Ke Shih` (Realtek driver maintainer)
- `Signed-off-by: Ping-Ke Shih` (committed by maintainer)
- **NO `Cc: stable@vger.kernel.org` tag**
- **NO `Fixes:` tag**
### 2. CODE CHANGE ANALYSIS
The commit is **extremely simple and surgical**:
```c
+ { USB_DEVICE_AND_INTERFACE_INFO(0x0411, 0x03d0, 0xff, 0xff,
0xff),
+ .driver_info = (kernel_ulong_t)&(rtw8822b_hw_spec) }, /*
BUFFALO WI-U3-866DHP */
```
**What it does:**
- Adds a single USB device ID entry to the `rtw_8822bu_id_table[]` array
- Uses `USB_DEVICE_AND_INTERFACE_INFO()` macro with:
- VID: `0x0411` (BUFFALO Inc.)
- PID: `0x03d0` (WI-U3-866DHP specific)
- Interface class/subclass/protocol: `0xff, 0xff, 0xff` (vendor-
specific)
- Associates with `rtw8822b_hw_spec` - the existing chip specification
structure
**Why it's correct:**
- The pattern is identical to 34 other devices already in this table
- The `rtw8822b_hw_spec` structure already supports this chipset
- All device-specific handling is already implemented in the driver
- No new code paths are introduced - only the USB subsystem can now
recognize and bind this device
### 3. CLASSIFICATION
**Category: NEW DEVICE ID ADDITION**
This falls squarely into the "NEW DEVICE IDs" exception category that IS
allowed in stable:
- Adding USB VID/PID to an existing, working driver
- One-line addition that enables hardware support
- Device uses identical chip (RTL8822B) as many other supported devices
- No new functionality, APIs, or driver changes
This is NOT:
- A new driver (driver already exists since v6.2)
- A new feature
- A bug fix (though users without support might consider it a bug)
- A security fix
- A quirk/workaround
### 4. SCOPE AND RISK ASSESSMENT
**Lines changed:** 2 lines (one USB_DEVICE entry + comment)
**Files touched:** 1 file (`rtw8822bu.c`)
**Complexity:** Trivial - just data table addition
**Subsystem:** WiFi/Realtek rtw88 driver
- The rtw88 driver is mature (mainline since v5.2 for PCIe, v6.2 for
USB)
- USB support is well-tested with 34+ devices in the table
**Risk of regression:** **EXTREMELY LOW**
- The change only affects users who plug in this specific BUFFALO device
- No existing functionality is modified
- No code paths change for other devices
- If the device ID is somehow wrong, worst case is the device doesn't
work
- Cannot break any existing hardware
### 5. USER IMPACT
**Who is affected:**
- Users with BUFFALO WI-U3-866DHP USB WiFi adapter
- This appears to be a retail device from BUFFALO (Japanese networking
company)
- Without this patch, users would need to manually bind the device using
sysfs or build custom kernels
**Severity:**
- Not a crash/security/data corruption issue
- This is a hardware enablement issue - device simply won't be
recognized
- Users who buy this device expect it to work with Linux
**Market context:**
- BUFFALO is a major Japanese networking brand
- The WI-U3-866DHP is a USB 3.0 802.11ac adapter
- Similar to WI-U2-866DM (0411:03d1) which was added in b7f0cc647e522
### 6. STABILITY INDICATORS
**Positive signals:**
- Acked by Ping-Ke Shih (Realtek maintainer)
- Author claims personal testing with retail hardware
- Follows exact same pattern as 34 other working device entries
**Negative signals:**
- No `Cc: stable@vger.kernel.org` tag
- No external testing reports (Tested-by)
- No Reviewed-by from other developers
### 7. DEPENDENCY CHECK
**Dependencies:** None
- This change only adds data to an array
- No other commits required
- No API changes needed
**Stable tree compatibility:**
- The rtw8822bu driver exists in stable kernels from v6.2 onwards
- The file structure is compatible (USB ID table is at same location)
- May require minor adjustment if backporting to older stable trees
where some context lines differ due to fewer USB IDs in the table
### 8. COMPARISON WITH SIMILAR COMMITS
Looking at recent USB ID additions to rtw88:
| Commit | Description | Stable Tag? | Backported? |
|--------|-------------|-------------|-------------|
| `b8a62478f3b14` | Add missing VID/PIDs for 8811CU/8821CU | **YES**
(`Cc: stable`) | YES (6.10+) |
| `7b5ce65d90187` | 8821au additional devices | NO | NO |
| `d4c4903508f9e` | Additional USB IDs for RTL8812BU | NO | NO |
| `80c4668d024ff` | Mercusys MA30N, D-Link DWA-T185 | NO | NO |
| `b7f0cc647e522` | BUFFALO WI-U2-866DM | NO | NO |
| **This commit** | BUFFALO WI-U3-866DHP | NO | ? |
The pattern shows that USB ID additions WITHOUT explicit stable tags are
typically NOT backported, while those WITH the tag ARE backported.
---
## FINAL ASSESSMENT
### Arguments FOR backporting:
1. **Falls under "NEW DEVICE IDs" exception** - USB ID additions to
existing drivers are explicitly allowed in stable
2. **Trivial change** - 2 lines of data, zero code changes
3. **Zero regression risk** - Only affects this specific device
4. **Enables real hardware** - Users with this device can use their
hardware
5. **Well-tested pattern** - Identical to 34 other entries in the same
driver
6. **Driver is mature** - rtw8822bu has been in mainline since v6.2
### Arguments AGAINST backporting:
1. **No explicit stable tag** - The maintainer did NOT add `Cc:
stable@vger.kernel.org`
2. **Not fixing a bug** - This is enablement, not a fix
3. **No Fixes: tag** - Not tied to any bug
4. **Precedent** - Similar commits without stable tags were not
backported
5. **Maintainer choice** - If Ping-Ke Shih wanted it in stable, they
would have added the tag
### Risk vs Benefit:
- **Risk:** Essentially zero - worst case is the device doesn't work on
one specific hardware configuration
- **Benefit:** Moderate - enables hardware support for users with this
specific BUFFALO adapter
### Decision Reasoning:
While this commit is technically safe to backport (it's a trivial USB ID
addition with no risk), the kernel's stable tree process respects
maintainer intent. The absence of a `Cc: stable@vger.kernel.org` tag
indicates the maintainer did not consider this critical enough for
stable trees. Looking at the pattern of similar commits, those without
stable tags are consistently not backported.
Additionally, USB device ID additions for "new" hardware (devices that
weren't recognized before) are generally seen as enablement rather than
bug fixes. The stable kernel rules emphasize fixing bugs that affect
users, not adding hardware support.
The conservative approach for stable trees is to follow maintainer
intent. If the maintainer wanted this in stable, they would have tagged
it.
**YES**
drivers/net/wireless/realtek/rtw88/rtw8822bu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw88/rtw8822bu.c b/drivers/net/wireless/realtek/rtw88/rtw8822bu.c
index 44e28e583964c..2769b86ce1b2a 100644
--- a/drivers/net/wireless/realtek/rtw88/rtw8822bu.c
+++ b/drivers/net/wireless/realtek/rtw88/rtw8822bu.c
@@ -79,6 +79,8 @@ static const struct usb_device_id rtw_8822bu_id_table[] = {
.driver_info = (kernel_ulong_t)&(rtw8822b_hw_spec) }, /* D-Link DWA-T185 rev. A1 */
{ USB_DEVICE_AND_INTERFACE_INFO(0x0411, 0x03d1, 0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t)&(rtw8822b_hw_spec) }, /* BUFFALO WI-U2-866DM */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x0411, 0x03d0, 0xff, 0xff, 0xff),
+ .driver_info = (kernel_ulong_t)&(rtw8822b_hw_spec) }, /* BUFFALO WI-U3-866DHP */
{},
};
MODULE_DEVICE_TABLE(usb, rtw_8822bu_id_table);
--
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 ` Sasha Levin [this message]
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 ` [Intel-wired-lan] [PATCH AUTOSEL 6.18-6.12] ice: Allow 100M speed for E825C SGMII device Sasha Levin
2025-12-09 0:15 ` 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-35-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=hrak1529@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=patches@lists.linux.dev \
--cc=pkshih@realtek.com \
--cc=stable@vger.kernel.org \
/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.