All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Max Krasnyansky <maxk@qualcomm.com>
Cc: BlueZ Mailing List <bluez-devel@lists.sourceforge.net>
Subject: [Bluez-devel] Re: Bluetooth update for 2.4.23-pre2
Date: 09 Oct 2003 18:13:54 +0200	[thread overview]
Message-ID: <1065716040.14513.52.camel@pegasus> (raw)
In-Reply-To: <5.1.0.14.2.20031008180324.059f6750@unixmail.qualcomm.com>

Hi Max,

> >I want to keep the the third parameter to be save in future if we need
> >to send other notifications down to the HCI driver for which we can use
> >it eventually. Bluetooth 1.2 and 2.0 will come with new stuff that may
> >need it.
> Unlikely. In any case we can add it later of needed.
> 
> >For the CONN_ADD and CONN_DEL I think we should also send the "conn"
> >down to the driver so it can read from it if needed.
> But the only thing useful for the driver is the connection type. We might as 
> well just pass that instead of a pointer to the whole struct. Anyway core should
> count connections not the driver.
> 
> >If not, it has to go by itself through the hash and I don't see any way that the 
> >driver can find out the current added connection. Am I wrong?
> conn_hash has 'num' field which is total number of connections. So we just need to
> keep two separate counters for ACL and SCO.
> I'll try to find some time this week to implement that.

I see the notify() interface and the seperate counting of ACL and SCO as
two different problems and I don't wanna mix them.

However I think it is nice to send the "conn" down to the driver, if you
thing it is two much, I drop it.

> >Yes, you told me that. And I put a note on my TODO list that this needs
> >further attention. But your suggestions was to change the credits value
> >from uint to int and don't find the time to check if a type change may
> >not causes other problems. And as I also said a new flag may be a better
> >solution.
> >Anyway I took the patch in, because it fixes the problem and whithout we
> >have a bug with incoming 1.0b connections. The double negotiation only
> >takes place on the second outgoing connections to the same 1.0b device.
> >And how much 1.0b devices do you have or do you know of? My only 1.0b
> >device is a Ericsson T39m and even my old Nokia 6210 already supports
> >CFC. And my HBH-10 don't count, because it support only one RFCOMM
> >connection ;)
> What I'm saying is that we should fix the write way not just some hack that 
> fixes first negotiation. It will pass certification with Ceticomm (or whatever 
> the name of that company) but will fail if tester code does proper checking ie second 
> connection, etc.
> It should be a trivial fix. I take a look at it tonight.

I looked at your fix and it looks fine to me. Can you please rebuild my
marcel-2.4 tree on the base of your current work? I will re-push my
other patches so we can sync up with Marcelo until the end of this week.
I want to finish this as soon as possible, because I am away for the
complete next week.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

  reply	other threads:[~2003-10-09 16:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1062432872.13729.185.camel@pegasus>
2003-09-12 17:44 ` Bluetooth update for 2.4.23-pre2 Max Krasnyansky
2003-09-12 22:48   ` [Bluez-devel] " Marcel Holtmann
2003-10-09  1:12     ` Max Krasnyansky
2003-10-09 16:13       ` Marcel Holtmann [this message]
2003-10-09 17:45         ` [Bluez-devel] " Max Krasnyansky
2003-10-09 18:24           ` Marcel Holtmann
2003-10-12 12:25             ` Jonathan Paisley
2003-10-13  9:28               ` 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=1065716040.14513.52.camel@pegasus \
    --to=marcel@holtmann.org \
    --cc=bluez-devel@lists.sourceforge.net \
    --cc=maxk@qualcomm.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 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.