linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: guido@kiener-muenchen.de
To: George McCollister <george.mccollister@gmail.com>
Cc: linux-usb@vger.kernel.org, guido.kiener@rohde-schwarz.com,
	dpenkler@gmail.com, steve_bayless@keysight.com
Subject: Re: usbtmc: stb race condition introduced by 4f3c8d6eddc272b386464524235440a418ed2029
Date: Tue, 22 Sep 2020 15:33:17 +0000	[thread overview]
Message-ID: <20200922153317.Horde.kYfFgpOej2x7e8K3swKnHnz@webmail.kiener-muenchen.de> (raw)
In-Reply-To: <20200903165401.Horde.0plv-8-wrkSbaoSekydKWEy@webmail.kiener-muenchen.de>


Hi George,

We discussed some solutions to solve the race you found.

Since we want to avoid future requests and compatibility problems
regarding the SRQ and Status Byte, we will fix the current ioctl.
Furthermore we add two ioctls which return the original status
message and avoid assumptions about the USB488 subclass definition.

We will have the 3 STB ioctls:

1) USBTMC488_IOCTL_READ_STB always reads the STB from the device and
if the associated file descriptor has the srq_asserted bit set it ors
in the RQS bit to the returned STB and clears the srq_asserted bit.

Comment: This ioctl will return the latest status byte again, but will
not loose the RQS bit sent by intermediate SRQ messages. This ioctl
should be conform with 488.2 devices.

2) USBTMC_IOCTL_GET_STB always reads the STB from the device and returns
the STB unmodified to the application. The srq_asserted bit is not changed.

3) USBTMC_IOCTL_GET_SRQ_STB if the associated file descriptor has the
srq_asserted bit set it returns the STB originally sent in the device
SRQ message and clears the srq_asserted bit otherwise it returns error
code ENOMSG.

Please let us know your feedback and comments.

Regards,

Guido



  reply	other threads:[~2020-09-22 15:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-31 14:31 usbtmc: stb race condition introduced by 4f3c8d6eddc272b386464524235440a418ed2029 George McCollister
2020-09-01 18:59 ` guido
2020-09-01 22:21   ` George McCollister
2020-09-02 15:25     ` guido
2020-09-03 14:42       ` George McCollister
2020-09-03 16:54         ` guido
2020-09-22 15:33           ` guido [this message]
2020-09-28 13:58             ` George McCollister

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=20200922153317.Horde.kYfFgpOej2x7e8K3swKnHnz@webmail.kiener-muenchen.de \
    --to=guido@kiener-muenchen.de \
    --cc=dpenkler@gmail.com \
    --cc=george.mccollister@gmail.com \
    --cc=guido.kiener@rohde-schwarz.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=steve_bayless@keysight.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).