lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20250928091818.4243-1-dpenkler@gmail.com>
Date: Sun, 28 Sep 2025 11:18:18 +0200
From: Dave Penkler <dpenkler@...il.com>
To: gregkh@...uxfoundation.org,
	linux-staging@...ts.linux.dev,
	linux-kernel@...r.kernel.org
Cc: Dave Penkler <dpenkler@...il.com>
Subject: [PATCH] staging: gpib: Fix no EOI on 1 and 2 byte writes

EOI (End Or Identify) is a hardware line on the GPIB bus that can be
asserted with the last byte of a message to indicate the end of the
transfer to the receiving device.

In this driver, a write with send_eoi true is done in 3 parts:
  Send first byte directly
  Send remaining but 1 bytes using the fifo
  Send the last byte directly with EOI asserted

The first byte in a write is always sent by writing to the tms9914
chip directly to setup for the subsequent fifo transfer.  We were not
checking for a 1 byte write with send_eoi true resulting in EOI not
being asserted. Since the fifo transfer was not executed
(fifotransfersize == 0) the retval in the test after the fifo transfer
code was still 1 from the preceding direct write. This caused it to
return without executing the final direct write which would have sent
an unsollicited extra byte.

For a 2 byte message the first byte was sent directly. But since the
fifo transfer was not executed (fifotransfersize == 1) and the retval
in the test after the fifo transfer code was still 1 from the
preceding first byte write it returned before the final direct byte
write with send_eoi true. The second byte was then sent as a separate
1 byte write to complete the 2 byte write count again without EOI
being asserted as above.

Only send the first byte directly if more than 1 byte is to be
transferred with send_eoi true.

Also check for retval < 0 for the error return in case the fifo code
is not used (1 or 2 byte message with send_eoi true).

Fixes: 09a4655ee1eb ("staging: gpib: Add HP/Agilent/Keysight 8235xx PCI GPIB driver")
Tested-by: Dave Penkler <dpenkler@...il.com>
Signed-off-by: Dave Penkler <dpenkler@...il.com>
---
 drivers/staging/gpib/agilent_82350b/agilent_82350b.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/gpib/agilent_82350b/agilent_82350b.c b/drivers/staging/gpib/agilent_82350b/agilent_82350b.c
index 94bbb3b6576d..01a5bb43cd2d 100644
--- a/drivers/staging/gpib/agilent_82350b/agilent_82350b.c
+++ b/drivers/staging/gpib/agilent_82350b/agilent_82350b.c
@@ -182,10 +182,12 @@ static int agilent_82350b_accel_write(struct gpib_board *board, u8 *buffer,
 		return retval;
 #endif
 
-	retval = agilent_82350b_write(board, buffer, 1, 0, &num_bytes);
-	*bytes_written += num_bytes;
-	if (retval < 0)
-		return retval;
+	if (fifotransferlength > 0) {
+		retval = agilent_82350b_write(board, buffer, 1, 0, &num_bytes);
+		*bytes_written += num_bytes;
+		if (retval < 0)
+			return retval;
+	}
 
 	write_byte(tms_priv, tms_priv->imr0_bits & ~HR_BOIE, IMR0);
 	for (i = 1; i < fifotransferlength;) {
@@ -217,7 +219,7 @@ static int agilent_82350b_accel_write(struct gpib_board *board, u8 *buffer,
 			break;
 	}
 	write_byte(tms_priv, tms_priv->imr0_bits, IMR0);
-	if (retval)
+	if (retval < 0)
 		return retval;
 
 	if (send_eoi) {
-- 
2.51.0


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ