mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Oliver Neukum <oliver@neukum.org>
To: Greg KH <greg@kroah.com>
Cc: mchehab@infradead.org, v4l-dvb-maintainer@linuxtv.org,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	video4linux-list@redhat.com
Subject: Re: [PATCH] USB: add Sensoray 2255 v4l driver
Date: Thu, 15 May 2008 13:38:37 +0200	[thread overview]
Message-ID: <200805151338.38801.oliver@neukum.org> (raw)
In-Reply-To: <20080514205927.GA13134@kroah.com>

Hi,

1. how about a *.h file?

2. You can inline these.

+static int norm_maxw(struct video_device *vdev)
+{
+       return (vdev->current_norm != V4L2_STD_PAL_B) ?
+           LINE_SZ_4CIFS_NTSC : LINE_SZ_4CIFS_PAL;
+}

3. The firmware stuff. That's an interesting solution. However:

a - if you don't need that delay, use a work queue

b - that's mean, use interruptible sleep

+               /* give 1 second for firmware to load in case
+                  driver loaded and then device immediately opened */
+               msleep(1000);

particularly you'd stall khubd processing an early unplug

c - obviously loading the firmware might have failed after waiting

+               if (dev->fw_data->fw_state == FWSTATE_NOTLOADED) {
+                       err("2255 firmware loading stalled\n");
+                       mutex_unlock(&usb_s2255_open_mutex);
+                       return -EAGAIN;
+               }
+       }

you need a check for failure in an else branch

d - so you'll never release firmware in the error case unless you unplug

+       /* if first open after firmware loaded, release the firmware */
+       if (dev->fw_data->fw) {
+               release_firmware(dev->fw_data->fw);
+               dev->fw_data->fw = NULL;
+       }

e - you need to report errors

+static void s2255_timer(unsigned long user_data)
+{
+       struct complete_data *data = (struct complete_data *)user_data;
+       dprintk(100, "s2255 timer\n");
+       if (usb_submit_urb(data->fw_urb, GFP_ATOMIC) < 0) {
+               printk(KERN_ERR "s2255: can't submit urb\n");
+               if (data->fw) {
+                       release_firmware(data->fw);
+                       data->fw = NULL;
+               }
+               return;
+       }
+}

f - also here

+static void s2255_fwchunk_complete(struct urb *urb)
+{
+       struct complete_data *data = urb->context;
+       struct usb_device *udev = urb->dev;
+       int len;
+       dprintk(100, "udev %p urb %p", udev, urb);
+
+       if (urb->status) {
+               dev_err(&udev->dev, "URB failed with status %d", urb->status);
+               return;
+       }

4. as a rule, init all locks before you start a timer

+       mod_timer(&dev->timer, jiffies + HZ);
+       spin_lock_init(&dev->slock);

5. Unnecessary init

+static void s2255_disconnect(struct usb_interface *interface)
+{
+       struct s2255_dev *dev = NULL;

6. The initial firmware timer may still be ticking

+       if (dev->fw_data->fw_urb) {
+               dprintk(2, "kill URB\n");
+               usb_kill_urb(dev->fw_data->fw_urb);
+               usb_free_urb(dev->fw_data->fw_urb);

You need to delete that timer and kill the firmware urb after that.

7. That's not an error you want to return in that case. It may livelock

+       if (dev->users[cur_channel] > 1) {
+               dev->users[cur_channel]--;
+               dev_err(&dev->udev->dev, "one user at a time\n");
+               mutex_unlock(&usb_s2255_open_mutex);
+               return -EAGAIN;
+       }

8. Bogus check

+       if (data->fw_urb == NULL) {
+               dev_err(&udev->dev, "early disconncect\n");
+               return;
+       }

9. This can be computed directly

+       while (*size * *count > vid_limit * 1024 * 1024)
+               (*count)--;

10. This is fishy.

+static int res_locked(struct s2255_dev *dev, struct s2255_fh *fh)
+{
+       return (dev->resources[fh->channel]);
+}
+
+static void res_free(struct s2255_dev *dev, struct s2255_fh *fh)
+{
+       dev->resources[fh->channel] = 0;
+       dprintk(1, "res: put\n");
+}

In theory out of order memory access might return false positives.
Better use memory barriers or take the mutex.

11. Coding style

+       return (0);

12. This is close to obfuscated code

+       is_ntsc =
+           (dev->vdev[fh->channel]->current_norm != V4L2_STD_PAL_B) ? 1 : 0;

13. Coding style

+       if (ret < 0)
+               return (ret);

14. GFP_KERNEL in interrupt context

+
+       if (pipe_info->state != 0) {
+               if (usb_submit_urb(pipe_info->stream_urb, GFP_KERNEL)) {

15. Error handling in s2255_probe() is a gigantic resource leak

+       if (!dev->fw_data->fw_urb) {
+               dev_err(&interface->dev, "out of memory!\n");
+               goto error;
+       }

You must free what you allocate

	Regards
		Oliver

  parent reply	other threads:[~2008-05-15 11:38 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-14 20:59 Greg KH
2008-05-15  1:17 ` [v4l-dvb-maintainer] " Markus Rechberger
2008-05-15  2:41   ` Greg KH
2008-05-15  3:12     ` Trent Piepho
2008-05-15 15:34       ` Dean Anderson
2008-05-15 16:57         ` Markus Rechberger
2008-05-16  2:59         ` Mauro Carvalho Chehab
2008-05-15 11:38 ` Oliver Neukum [this message]
2008-05-15 12:03   ` Oliver Neukum
2008-05-15 18:44     ` Greg KH
2008-05-15 19:54       ` Oliver Neukum
2008-05-15 20:10         ` Greg KH
2008-05-15 20:13           ` Oliver Neukum
2008-05-16  2:51 ` Mauro Carvalho Chehab
2008-05-16  6:28   ` Oliver Neukum
2008-05-16 15:57     ` dean
2008-05-16 16:04       ` Oliver Neukum
2008-05-16 18:17       ` Mauro Carvalho Chehab
2008-05-16 14:53   ` dean
2008-05-16 15:34     ` Mauro Carvalho Chehab

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=200805151338.38801.oliver@neukum.org \
    --to=oliver@neukum.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mchehab@infradead.org \
    --cc=v4l-dvb-maintainer@linuxtv.org \
    --cc=video4linux-list@redhat.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

all inboxes | Powered by JetHome®