linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Gustavo F. Padovan" <padovan@profusion.mobi>
To: Mat Martineau <mathewm@codeaurora.org>
Cc: haijun liu <liuhaijun.er@gmail.com>,
	"haijun.liu" <haijun.liu@atheros.com>,
	linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH 16/22] Store new configuration values in l2cap_pinfo
Date: Fri, 3 Sep 2010 18:04:32 -0300	[thread overview]
Message-ID: <20100903210432.GA16973@vigoh> (raw)
In-Reply-To: <alpine.DEB.2.00.1009031337410.26179@linux-sea-02>

Hi Mat,

* Mat Martineau <mathewm@codeaurora.org> [2010-09-03 13:58:46 -0700]:

> 
> On Fri, 3 Sep 2010, haijun liu wrote:
> 
> > On Fri, Sep 3, 2010 at 7:02 AM, Mat Martineau <mathewm@codeaurora.org> wrote:
> >>
> >> On Thu, 26 Aug 2010, haijun liu wrote:
> >>
> >>> From d093975dde6d85c824a5aaac943d676100810010 Mon Sep 17 00:00:00 2001
> >>> From: haijun.liu <haijun.liu@atheros.com>
> >>> Date: Mon, 23 Aug 2010 00:09:56 +0800
> >>> Subject: [PATCH 16/22] Store new configuration values in l2cap_pinfo.
> >>>
> >>> ---
> >>> include/net/bluetooth/l2cap.h |    9 +++++++++
> >>> 1 files changed, 9 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> >>> index 2d864d4..f2dd65d 100644
> >>> --- a/include/net/bluetooth/l2cap.h
> >>> +++ b/include/net/bluetooth/l2cap.h
> >>> @@ -406,6 +406,15 @@ struct l2cap_pinfo {
> >>>        __u16           remote_mps;
> >>>        __u16           mps;
> >>>
> >>> +       __u8            ext_flowspec_enable;
> >>> +       struct ext_flow_spec    loc_efs;
> >>> +       struct ext_flow_spec    rem_efs;
> >>> +
> >>> +       __u8            extwin_enable;
> >>> +       __u16           extwin_size;
> >>> +       __u8            rem_extwin_enable;
> >>> +       __u16           rem_extwin_size;
> >>> +
> >>>        __le16          sport;
> >>>
> >>>        struct timer_list       retrans_timer;
> >>
> >> Regarding the new "extwin" structure members, have you considered changing
> >> the existing tx_win and remote_tx_win members to __u16 and using them with
> >> both standard and extended window sizes?
> >>
> >> The spec also requires that both directions of the link use the same type of
> >> control field (standard or extended).  After L2CAP configuration is done,
> >> all the information required for the transmit window is the control field
> >> type, tx_win, and remote_tx_win.  The control field would be set to
> >> 'extended' if a successful configuration response is sent or received for
> >> the extended window size option.
> >
> > Yes, we do, please look into the patch, we use __u16 for extwin_size &
> > rem_extwin_size
> > +       __u8            extwin_enable;
> > +       __u16           extwin_size;
> > +       __u8            rem_extwin_enable;
> > +       __u16           rem_extwin_size;
> >
> > You are exactly right, in our implementation, choosing standard or 
> > extended window, it depends whether successful configuration 
> > response contain the extended window size option.
> 
> Haijin -
> 
> Thank you for your explanation.  I was trying to suggest something 
> different - sorry I did not explain myself well.
> 
> I think that extwin_enable, extwin_size, rem_extwin_enable, and 
> rem_extwin_size are not needed in l2cap_pinfo.  Instead, I suggest 
> this:
> 
> @@ -349,15 +349,17 @@ struct l2cap_pinfo {
> 
>          __u8            ident;
> 
> -       __u8            tx_win;
> +       __u16           tx_win;
>          __u8            max_tx;
> -       __u8            remote_tx_win;
> +       __u16           remote_tx_win;
>          __u8            remote_max_tx;
>          __u16           retrans_timeout;
>          __u16           monitor_timeout;
>          __u16           remote_mps;
>          __u16           mps;
> 
> +       __u8            extended_control;
> +
>          __le16          sport;
> 
>          struct timer_list       retrans_timer;
> 
> Here, tx_win and remote_tx_win are always used to record the window 
> size, whether extended or standard.  extended_control is used to 
> specify standard or extended control fields.

Then you don't need extended_control here, a bit in the conf_state field
should be enough.

-- 
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi

  reply	other threads:[~2010-09-03 21:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-25 22:37 [PATCH 16/22] Store new configuration values in l2cap_pinfo haijun liu
2010-08-26  1:21 ` Gustavo F. Padovan
2010-09-02 23:02 ` Mat Martineau
2010-09-03  1:30   ` haijun liu
2010-09-03 20:58     ` Mat Martineau
2010-09-03 21:04       ` Gustavo F. Padovan [this message]
2010-09-03 21:46         ` Mat Martineau
2010-09-03 21:49           ` Gustavo F. Padovan

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=20100903210432.GA16973@vigoh \
    --to=padovan@profusion.mobi \
    --cc=haijun.liu@atheros.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=liuhaijun.er@gmail.com \
    --cc=mathewm@codeaurora.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 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).