public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Oliver Neukum <oliver@neukum.org>
Cc: linux-bluetooth@vger.kernel.org, linux-usb@vger.kernel.org,
	Sarah Sharp <sarah.a.sharp@linux.intel.com>,
	Arjan Van De Ven <arjan@linux.intel.com>,
	saharabeara@gmail.com
Subject: Re: btusb autosuspend and circular lock dep
Date: Mon, 24 Aug 2009 09:56:54 -0700	[thread overview]
Message-ID: <1251133014.2950.45.camel@localhost.localdomain> (raw)
In-Reply-To: <200908241429.49498.oliver@neukum.org>

Hi Oliver,

> > > +skip_waking:
> > >       usb_anchor_urb(urb, &data->tx_anchor);
> > >  
> > >       err = usb_submit_urb(urb, GFP_ATOMIC);
> > > @@ -646,10 +723,13 @@ static int btusb_send_frame(struct sk_buff *skb)
> > >               BT_ERR("%s urb %p submission failed", hdev->name, urb);
> > >               kfree(urb->setup_packet);
> > >               usb_unanchor_urb(urb);
> > > +     } else {
> > > +             usb_mark_last_busy(data->udev);
> > >       }
> > >  
> > >       usb_free_urb(urb);
> > >  
> > > +out:
> > >       return err;
> > >  }
> >
> > Please call the labels simply skip and done.
> 
> In this particular case skip_waking seems to be clearer because it
> tells you right away what is skipped.

agree, keep it then.

> > > @@ -721,8 +801,19 @@ static void btusb_work(struct work_struct *work)
> > >  {
> > >       struct btusb_data *data = container_of(work, struct btusb_data,
> > > work); struct hci_dev *hdev = data->hdev;
> > > +     int err;
> > >  
> > >       if (hdev->conn_hash.sco_num > 0) {
> > > +             if (!data->did_iso_resume) {
> > > +                     err = usb_autopm_get_interface(data->isoc);
> > > +                     if (!err) {
> > > +                             data->did_iso_resume = 1;
> > > +                     } else {
> > > +                             clear_bit(BTUSB_ISOC_RUNNING,
> > > &data->flags);
> > > +                             usb_kill_anchored_urbs(&data->isoc_anchor);
> > > +                             return;
> > > +                     }
> >
> > Having this as like this is simpler to read:
> >
> >                 if (err < 0) {
> >                         clear_bit(BTUSB_ISOC_RUNNING, &data->flags);
> >                         usb_kill_anchored_urbs(&data->isoc_anchor);
> >                         return;
> >                 }
> >
> >                 data->did_iso_resume = 1;
> 
> Do you generally prefer the "else" branch implicit?

I prefer: if error, cleanup and leave function. It is easier to read and
understand by people that are not familiar enough with the code.

If we have a lot of else branches you have to think too much which one
gets executed in case of success. If the command and the follow command
in case of success are on the same indentation, I find it a lot simpler
to follow. My take on these :)

Regards

Marcel



  reply	other threads:[~2009-08-24 16:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20090615175435.GA4772@gamba.jf.intel.com>
     [not found] ` <200906210034.42481.oliver@neukum.org>
     [not found]   ` <1251102046.2950.28.camel@localhost.localdomain>
2009-08-24  9:49     ` btusb autosuspend and circular lock dep Oliver Neukum
2009-08-24 10:16       ` Marcel Holtmann
2009-08-24 12:29         ` Oliver Neukum
2009-08-24 16:56           ` Marcel Holtmann [this message]
2009-08-24 13:59     ` Oliver Neukum
2009-08-24 17:03       ` Marcel Holtmann
2009-08-24 19:49         ` Oliver Neukum
2009-08-24 19:59           ` Marcel Holtmann
2009-08-24 21:26             ` Oliver Neukum
2009-08-24 21:36               ` Marcel Holtmann
2009-08-24 21:44                 ` Oliver Neukum
2009-08-24 21:58                   ` Sarah Sharp
2009-08-24 22:49                     ` Sarah Sharp
2009-08-24 23:07                       ` Marcel Holtmann
2009-08-24 23:30                   ` Marcel Holtmann

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=1251133014.2950.45.camel@localhost.localdomain \
    --to=marcel@holtmann.org \
    --cc=arjan@linux.intel.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=oliver@neukum.org \
    --cc=saharabeara@gmail.com \
    --cc=sarah.a.sharp@linux.intel.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