All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Frédéric DALLEAU" <frederic.dalleau@linux.intel.com>
To: linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH v4 2/6] Bluetooth: Add SCO socket voice_setting option
Date: Mon, 08 Apr 2013 14:41:03 +0200	[thread overview]
Message-ID: <5162BADF.7010608@linux.intel.com> (raw)
In-Reply-To: <DE6F5576-C7C9-4EA9-B242-3489F0651FBC@holtmann.org>

Hi Marcel

Le 26/03/2013 21:22, Marcel Holtmann a écrit :
I find this parameter name a bit long. What about just "setting" or 
"settings" or "voice". I am open for suggestions.
>
> Also should this be part of options or the socket address structure.
>
> Another option would be to introduce a SCO_SETTINGS or SCO_VOICE socket option. With just this one parameter.
>
> Since the default value of voice setting is not 0x0000, it might make actually more sense to introduce a new socket option. Playing the memset handling would only work nicely if the default would be 0x0000, but it isn't.
>
> Regards
>
> Marcel
>

  I agree that having a separate socket option is better. IMHO, having 
it in the
sockaddr is not enough because you don't know in advance what stream is
flowing for incoming connections. It could improve the API for outgoing
connections.

My concern is how do we handle user values.
If the user do not set this option, hci_conn->settings contains 0x0000.
In this case, it is possible to start the sco connection as we have it 
today.
If the user set 0x0060 (cvsd 16 bits) or 0x0003 (transparent data), then 
it is
possible to start S3, S2, S1 or T2, T1 sequences.

For other values, IMHO, returning an error would be the way to go.

If the above is fine for you, we can discuss the naming. What about the
following ?

#define SCO_SETTINGS  0x03
struct sco_settings {
         __u16           settings;
};

Regards,
Frédéric

  parent reply	other threads:[~2013-04-08 12:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-19 18:04 [PATCH v4 0/6] sco: SCO socket option for voice_setting Frédéric Dalleau
2013-03-19 18:04 ` [PATCH v4 1/6] Bluetooth: Move and rename hci_conn_accept Frédéric Dalleau
2013-03-26 20:18   ` Marcel Holtmann
2013-03-19 18:04 ` [PATCH v4 2/6] Bluetooth: Add SCO socket voice_setting option Frédéric Dalleau
2013-03-26 20:22   ` Marcel Holtmann
2013-04-08  8:55     ` Dalleau, Frederic
2013-04-08 12:41     ` Frédéric DALLEAU [this message]
2013-04-08 17:50       ` Marcel Holtmann
2013-04-09  8:32         ` Frédéric DALLEAU
2013-04-09 15:30           ` Marcel Holtmann
2013-04-09 16:38             ` Frédéric DALLEAU
2013-03-19 18:04 ` [PATCH v4 3/6] Bluetooth: Use hci_connect_sco directly Frédéric Dalleau
2013-03-19 18:04 ` [PATCH v4 4/6] Bluetooth: Use voice_setting in incoming SCO connection Frédéric Dalleau
2013-03-19 18:04 ` [PATCH v4 5/6] Bluetooth: Parameters for outgoing SCO connections Frédéric Dalleau
2013-03-19 18:04 ` [PATCH v4 6/6] Bluetooth: Fallback transparent SCO from T2 to T1 Frédéric Dalleau

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=5162BADF.7010608@linux.intel.com \
    --to=frederic.dalleau@linux.intel.com \
    --cc=linux-bluetooth@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.