Linux bluetooth development
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Hemant Gupta <hemantgupta.ste@gmail.com>
Cc: Johan Hedberg <johan.hedberg@gmail.com>,
	linux-bluetooth@vger.kernel.org,
	Hemant Gupta <hemant.gupta@stericsson.com>
Subject: Re: [PATCH v3] Bluetooth: Fix packet type for ESCO Link
Date: Thu, 05 Apr 2012 10:46:32 -0700	[thread overview]
Message-ID: <1333647992.16897.13.camel@aeonflux> (raw)
In-Reply-To: <CACj007m7_3B=MiFZHGr9UHu2Fuq0_KOvgM1mhRXStp+se=nvvg@mail.gmail.com>

Hi Hemant,

> >> > This patch uses the corect packet type for ESCO Link.
> >> > Without this patch esco packet types were anded with ~EDR_ESCO_MASK
> >> > resulting in setting bits that are not supported by controller
> >> > to 0 which means that corresponding EDR ESCO packet type is
> >> > supported(EDR Packet types are inverted as per BT Spec) which might
> >> > not be the case.
> >> >
> >> Any comments on this patch ?
> >
> > as I said before, I like to see a hcidump in the commit messages that
> > shows the failure.
> >
> I am not sure the hcidump would indicate the exact problem, because the problem
> is of selecting wrong eSCO edr pkt type of local device and moreover
> my code base is bit different from upstream code.
> 
> For eg:
> Local Controller supports only 3-EV5, 2-EV5 and 3-EV3 of the EDR eSCO packet
> types and does not support 2-EV3 packet type.
> 
> This would mean that while creating the esco_type in function
> hci_cc_read_local_features()
> the ESCO_2EV3 bit would not be set and all other EDR eSCO bits would be set.
> Resulting hdev->esco_type = 0x0380
> 
> Now in hci_conn_add() when the pkt_type is being calculated for eSCO
> Link, wrong calculation
> would take place as below:
> 
> conn->pkt_type = hdev->esco_type & ~EDR_ESCO_MASK;
>                       = 0x0380 & ~0x03C0 = 0x0380 & 0xFC3F = 0x0000
> Since the EDR eSCO bits are invertedThis indicates that ultimately all
> EDR eSCO packet types are supported, which is not correct as local
> controller is not supporting the 2-EV3 packet type.
> 
> As per calculations of the patch
> conn->pkt_type = hdev->esco_type & ~EDR_ESCO_MASK;
>                       = 0x0380 ^ 0x03C0 = 0x0040
> which correctly indicates that packet type used excludes the 2-EV3
> packet type not supported by local controller.
> 
> Please let me know your views on this.

this sounds like a really good explanation that should go into the
commit message. Don't you agree?

Regards

Marcel



  reply	other threads:[~2012-04-05 17:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-05  3:46 [PATCH v3] Bluetooth: Fix packet type for ESCO Link Hemant Gupta
2012-04-05 16:01 ` Hemant Gupta
2012-04-05 16:14   ` Marcel Holtmann
2012-04-05 16:47     ` Hemant Gupta
2012-04-05 17:46       ` Marcel Holtmann [this message]
2012-04-05 18:01         ` Hemant Gupta

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=1333647992.16897.13.camel@aeonflux \
    --to=marcel@holtmann.org \
    --cc=hemant.gupta@stericsson.com \
    --cc=hemantgupta.ste@gmail.com \
    --cc=johan.hedberg@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox