From: Dave Penkler dpenkler@gmail.com
[ Upstream commit f50d5e0c1f80d004510bf77cb0e1759103585c00 ]
A new version of a bona fide genuine NI-USB-HS+ adaptor sends new response codes to the initialization sequence.
Add the checking for these response codes to suppress console warning messages.
Signed-off-by: Dave Penkler dpenkler@gmail.com Link: https://lore.kernel.org/r/20250722164810.2621-1-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
Based on my analysis, I'll now provide my assessment of whether this commit should be backported to stable kernel trees.
**Backport Status: YES**
This commit should be backported to stable kernel trees. Here's my extensive analysis:
## Commit Analysis
The commit adds support for new response codes from newer NI-USB-HS+ hardware adaptors. Looking at the specific code changes:
1. **Lines 2082-2086**: The comment is updated from "NI-USB-HS+ sends 0xf here" to "NI-USB-HS+ sends 0xf or 0x19 here", and the check is expanded to accept 0x19 as a valid response code.
2. **Lines 2113-2119**: The comment is updated to indicate that new HS+ hardware sends 0x59 at position [10], and the check is expanded to accept 0x59 as a valid response code.
## Rationale for Backporting
1. **Fixes a Real User Issue**: This fixes a bug where newer NI-USB-HS+ hardware generates console warning messages due to unrecognized response codes. Without this fix, users with newer hardware see error messages like "unexpected data: buffer[x]=0x19, expected..." when the hardware is actually functioning correctly.
2. **Minimal Risk**: The change is extremely contained - it only adds two additional valid response codes (0x19 and 0x59) to existing validation checks. No logic changes, no structural modifications, just expanding the set of accepted values.
3. **Hardware Compatibility**: This is a hardware enablement fix that allows Linux to properly support newer versions of existing hardware without generating spurious warnings.
4. **Staging Driver Context**: While this is in staging, the gpib subsystem appears to be actively maintained (based on recent commit history), and hardware compatibility fixes are important for users of this specialized equipment.
5. **Clear Bug Fix**: The commit message explicitly states it "suppress[es] console warning messages" - this is fixing incorrect error reporting, not adding new features.
6. **No Architectural Changes**: The patch doesn't change any APIs, data structures, or driver architecture. It's purely adding two constants to existing validation logic.
7. **Tested Hardware**: The commit message indicates this was tested with "a bona fide genuine NI-USB-HS+ adaptor", suggesting real hardware validation.
## Stable Tree Criteria Met
- ✓ Fixes a bug that affects users (spurious warnings with newer hardware) - ✓ Small and contained change (4 lines modified) - ✓ No side effects beyond the intended fix - ✓ No architectural changes - ✓ Hardware enablement for existing driver
The commit clearly meets the stable tree criteria as a minimal hardware compatibility fix that resolves user-visible warnings without any risk of regression.
drivers/staging/gpib/ni_usb/ni_usb_gpib.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/gpib/ni_usb/ni_usb_gpib.c b/drivers/staging/gpib/ni_usb/ni_usb_gpib.c index 9f1b9927f025..56d3b62249b8 100644 --- a/drivers/staging/gpib/ni_usb/ni_usb_gpib.c +++ b/drivers/staging/gpib/ni_usb/ni_usb_gpib.c @@ -2069,10 +2069,10 @@ static int ni_usb_hs_wait_for_ready(struct ni_usb_priv *ni_priv) } if (buffer[++j] != 0x0) { // [6] ready = 1; - // NI-USB-HS+ sends 0xf here + // NI-USB-HS+ sends 0xf or 0x19 here if (buffer[j] != 0x2 && buffer[j] != 0xe && buffer[j] != 0xf && - buffer[j] != 0x16) { - dev_err(&usb_dev->dev, "unexpected data: buffer[%i]=0x%x, expected 0x2, 0xe, 0xf or 0x16\n", + buffer[j] != 0x16 && buffer[j] != 0x19) { + dev_err(&usb_dev->dev, "unexpected data: buffer[%i]=0x%x, expected 0x2, 0xe, 0xf, 0x16 or 0x19\n", j, (int)buffer[j]); unexpected = 1; } @@ -2100,11 +2100,11 @@ static int ni_usb_hs_wait_for_ready(struct ni_usb_priv *ni_priv) j, (int)buffer[j]); unexpected = 1; } - if (buffer[++j] != 0x0) { + if (buffer[++j] != 0x0) { // [10] MC usb-488 sends 0x7 here, new HS+ sends 0x59 ready = 1; - if (buffer[j] != 0x96 && buffer[j] != 0x7 && buffer[j] != 0x6e) { -// [10] MC usb-488 sends 0x7 here - dev_err(&usb_dev->dev, "unexpected data: buffer[%i]=0x%x, expected 0x96, 0x07 or 0x6e\n", + if (buffer[j] != 0x96 && buffer[j] != 0x7 && buffer[j] != 0x6e && + buffer[j] != 0x59) { + dev_err(&usb_dev->dev, "unexpected data: buffer[%i]=0x%x, expected 0x96, 0x07, 0x6e or 0x59\n", j, (int)buffer[j]); unexpected = 1; }