From: Dave Penkler <dpenkler@gmail.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
peter.chen@freescale.com, teuniz@gmail.com,
USB <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 1/5] Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation.
Date: Sun, 22 Nov 2015 10:19:52 +0100 [thread overview]
Message-ID: <20151122091952.GB4581@slacky> (raw)
In-Reply-To: <CAHp75Vfp+GmeGQvmh8reqS=dUw108GBfAvr60d8wQUdPC=gDJg@mail.gmail.com>
On Wed, Nov 18, 2015 at 11:55:27AM +0200, Andy Shevchenko wrote:
> On Wed, Nov 18, 2015 at 10:37 AM, Dave Penkler <dpenkler@gmail.com> wrote:
> > Background:
> > When performing a read on an instrument that is executing a function
> > that runs longer than the USB timeout the instrument may hang and
> > require a device reset to recover. The READ_STATUS_BYTE operation
> > always returns even when the instrument is busy permitting to poll
> > for the appropriate condition. This capability is referred to in
> > instrument application notes on synchronizing acquisitions for other
> > platforms.
> >
>
> First of all, please be patient and do not send patches immediately
> when you answered to someone's review. It increases redundant noise
> and burden on reviewer. Wait at least for 24h especially if there are
> topics still to discuss.
>
OK, apologies.
snip
> > +
> > + switch (status) {
> > + case 0: /* SUCCESS */
> > + if (data->iin_buffer[0] & 0x80) {
> > + /* check for valid STB notification */
> > + if ((data->iin_buffer[0] & 0x7f) > 1) {
>
> Despite your answer to my comment code is quite understandable even with & 0x7e.
> You already put comment line about this, you may add that you validate
> the value to be 127 >= value >= 2.
>
Yes it is quite understandable but it is less clear. I repeat my comment here:
When reading the spec and the code it is more obvious that here
we are testing for the value in bits D6..D0 to be a valid iin_bTag return.
(See Table 7 in the USBTMC-USB488 spec.)
What is your motivation for
if (data->iin_buffer[0] & 0x7e)
?
> > + data->bNotify1 = data->iin_buffer[0];
> > + data->bNotify2 = data->iin_buffer[1];
> > + atomic_set(&data->iin_data_valid, 1);
> > + wake_up_interruptible(&data->waitq);
> > + goto exit;
> > + }
> > + }
snip
> > + /* urb terminated, clean up */
> > + dev_dbg(&data->intf->dev,
> > + "%s - urb terminated, status: %d\n",
> > + __func__, status);
>
> No need to print function here explicitly. Check Dynamic Debug framework.
I am not using dynamic debug but when I enable static debug I get:
[ 1438.562458] usbtmc 1-1:1.0: Enter ioctl_read_stb iin_ep_present: 1
on the console log for
dev_dbg(dev, "Enter ioctl_read_stb iin_ep_present: %d\n",
data->iin_ep_present);
So if I don't print the function it does not appear on the log.
>
> > + return;
> > + default:
> > + dev_err(&data->intf->dev,
> > + "%s - unknown status received: %d\n",
> > + __func__, status);
> > + }
> > +exit:
> > + rv = usb_submit_urb(urb, GFP_ATOMIC);
> > + if (rv) {
> > + dev_err(&data->intf->dev, "%s - usb_submit_urb failed: %d\n",
> > + __func__, rv);
> > + }
> > +}
snip
> > +
> > + /* fill interrupt urb */
> > + usb_fill_int_urb(data->iin_urb, data->usb_dev,
> > + usb_rcvintpipe(data->usb_dev, data->iin_ep),
> > + data->iin_buffer, data->iin_wMaxPacketSize,
> > + usbtmc_interrupt,
> > + data, data->iin_interval);
> > +
> > + if (usb_submit_urb(data->iin_urb, GFP_KERNEL)) {
>
> Does it return a proper error code?
>
Yes, will propagate it.
> > + retcode = -EIO;
> > + dev_err(&intf->dev, "Failed to submit iin_urb\n");
> > + goto error_register;
> > + }
> > + }
> > +
>
> > retcode = sysfs_create_group(&intf->dev.kobj, &data_attr_grp);
> >
> > retcode = usb_register_dev(intf, &usbtmc_class);
>
> Hmm??? Unrelated to this patch, but notice that retcode is overridden here.
>
>
> > @@ -1185,6 +1395,7 @@ static int usbtmc_probe(struct usb_interface *intf,
> > error_register:
> > sysfs_remove_group(&intf->dev.kobj, &capability_attr_grp);
> > sysfs_remove_group(&intf->dev.kobj, &data_attr_grp);
> > + usbtmc_free_int(data);
> > kref_put(&data->kref, usbtmc_delete);
> > return retcode;
> > }
>
>
> --
> With Best Regards,
> Andy Shevchenko
cheers,
-Dave
next prev parent reply other threads:[~2015-11-22 9:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-18 8:32 [PATCH v5 0/5] usb: usbtmc: Add support for missing functions in USBTMC-USB488 spec Dave Penkler
2015-11-18 8:37 ` [PATCH v5 1/5] Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation Dave Penkler
2015-11-18 9:55 ` Andy Shevchenko
2015-11-22 9:19 ` Dave Penkler [this message]
2015-11-22 10:32 ` Andy Shevchenko
2015-11-25 9:18 ` Dave Penkler
2015-11-25 20:38 ` Andy Shevchenko
2015-11-28 11:55 ` Dave Penkler
2015-11-28 14:57 ` Andy Shevchenko
2015-11-28 17:41 ` Dave Penkler
2015-11-28 19:18 ` Andy Shevchenko
2015-11-18 8:38 ` [PATCH v5 2/5] Add support for USBTMC USB488 SRQ notification with fasync Dave Penkler
2015-11-18 8:38 ` [PATCH v5 3/5] Add support for receiving USBTMC USB488 SRQ notifications via poll/select Dave Penkler
2015-11-18 8:38 ` [PATCH v5 4/5] Add ioctl to retrieve USBTMC-USB488 capabilities Dave Penkler
2015-11-18 8:38 ` [PATCH v5 5/5] Add ioctls to enable and disable local controls on an instrument Dave Penkler
2015-11-18 9:41 ` Andy Shevchenko
2015-11-22 8:51 ` Dave Penkler
2015-11-22 10:36 ` Andy Shevchenko
2015-11-25 9:12 ` Dave Penkler
2015-11-25 20:46 ` Andy Shevchenko
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=20151122091952.GB4581@slacky \
--to=dpenkler@gmail.com \
--cc=andy.shevchenko@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=peter.chen@freescale.com \
--cc=teuniz@gmail.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