* Re: [PATCH] Setting default Link Policy according to the chip supported features
From: Johan Hedberg @ 2010-12-13 14:27 UTC (permalink / raw)
To: Pawel Wieczorkiewicz; +Cc: linux-bluetooth
In-Reply-To: <1292249954-8544-1-git-send-email-pawel.wieczorkiewicz@tieto.com>
Hi Pawel,
On Mon, Dec 13, 2010, Pawel Wieczorkiewicz wrote:
> By default all features are enabled (RSWITCH, HOLD, PARK, SNIFF).
> When "read local supported features" complete event occurs, not supported
> features are disabled and then "Write default link policy" command with
> supported features is sent.
>
> On behalf of ST-Ericsson SA
> ---
> plugins/hciops.c | 35 +++++++++++++++--------------------
> 1 files changed, 15 insertions(+), 20 deletions(-)
Thanks! The patch has been pushed upstream.
Johan
^ permalink raw reply
* [PATCH] Setting default Link Policy according to the chip supported features
From: Pawel Wieczorkiewicz @ 2010-12-13 14:19 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Pawel Wieczorkiewicz
By default all features are enabled (RSWITCH, HOLD, PARK, SNIFF).
When "read local supported features" complete event occurs, not supported
features are disabled and then "Write default link policy" command with
supported features is sent.
On behalf of ST-Ericsson SA
---
plugins/hciops.c | 35 +++++++++++++++--------------------
1 files changed, 15 insertions(+), 20 deletions(-)
diff --git a/plugins/hciops.c b/plugins/hciops.c
index 4af137c..44039ba 100644
--- a/plugins/hciops.c
+++ b/plugins/hciops.c
@@ -297,6 +297,7 @@ static void start_adapter(int index)
{
uint8_t events[8] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0x1f, 0x00, 0x00 };
uint8_t inqmode;
+ uint16_t policy;
if (VER(index).lmp_ver > 1) {
if (FEATURES(index)[5] & LMP_SNIFF_SUBR)
@@ -345,6 +346,20 @@ static void start_adapter(int index)
hci_send_cmd(SK(index), OGF_HOST_CTL,
OCF_READ_INQ_RESPONSE_TX_POWER_LEVEL, 0, NULL);
+ /* Set default link policy */
+ if (!(FEATURES(index)[0] & LMP_RSWITCH))
+ main_opts.link_policy &= ~HCI_LP_RSWITCH;
+ if (!(FEATURES(index)[0] & LMP_HOLD))
+ main_opts.link_policy &= ~HCI_LP_HOLD;
+ if (!(FEATURES(index)[0] & LMP_SNIFF))
+ main_opts.link_policy &= ~HCI_LP_SNIFF;
+ if (!(FEATURES(index)[1] & LMP_PARK))
+ main_opts.link_policy &= ~HCI_LP_PARK;
+
+ policy = htobs(main_opts.link_policy);
+ hci_send_cmd(SK(index), OGF_LINK_POLICY,
+ OCF_WRITE_DEFAULT_LINK_POLICY, 2, &policy);
+
CURRENT_COD(index) = 0;
memset(EIR(index), 0, sizeof(EIR(index)));
@@ -1949,7 +1964,6 @@ static void at_child_exit(void)
static void device_devup_setup(int index)
{
struct hci_dev_info di;
- uint16_t policy;
read_stored_link_key_cp cp;
DBG("hci%d", index);
@@ -1972,11 +1986,6 @@ static void device_devup_setup(int index)
WRITE_PAGE_TIMEOUT_CP_SIZE, &cp);
}
- /* Set default link policy */
- policy = htobs(main_opts.link_policy);
- hci_send_cmd(SK(index), OGF_LINK_POLICY,
- OCF_WRITE_DEFAULT_LINK_POLICY, 2, &policy);
-
bacpy(&cp.bdaddr, BDADDR_ANY);
cp.read_all = 1;
hci_send_cmd(SK(index), OGF_HOST_CTL, OCF_READ_STORED_LINK_KEY,
@@ -1997,7 +2006,6 @@ static void init_pending(int index)
static void init_device(int index)
{
struct hci_dev_req dr;
- struct hci_dev_info di;
int dd;
pid_t pid;
@@ -2042,19 +2050,6 @@ static void init_device(int index)
error("Can't set link mode on hci%d: %s (%d)",
index, strerror(errno), errno);
- /* Set link policy for BR/EDR HCI devices */
- if (hci_devinfo(index, &di) < 0)
- goto fail;
-
- if (!ignore_device(&di)) {
- dr.dev_opt = main_opts.link_policy;
- if (ioctl(dd, HCISETLINKPOL, (unsigned long) &dr) < 0 &&
- errno != ENETDOWN) {
- error("Can't set link policy on hci%d: %s (%d)",
- index, strerror(errno), errno);
- }
- }
-
/* Start HCI device */
if (ioctl(dd, HCIDEVUP, index) < 0 && errno != EALREADY) {
error("Can't init device hci%d: %s (%d)",
--
1.7.0.4
^ permalink raw reply related
* Re: How to implement multiple instances of obexd service?
From: Slawomir Bochenski @ 2010-12-13 13:56 UTC (permalink / raw)
To: Slawomir Bochenski, linux-bluetooth
In-Reply-To: <20101213132145.GA13767@jh-x301>
On Mon, Dec 13, 2010 at 2:21 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Slawek,
>
> On Mon, Dec 13, 2010, Slawomir Bochenski wrote:
>> On Mon, Dec 13, 2010 at 1:00 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
>> >> And what about assigned bitmask values for services in src/obex.h?
>> >
>> > Do we need to change something there?
>>
>> In that case src/obex.h is the only place that will need simple
>> modification for now -- MAP service value for services bitmask. This
>> may be OBEX_MAP (or OBEX_MAS) and I supppose its value should be the
>> next one available -- (1 << 8).
>
> Right, we'll need that. I thought you were talking about something
> related to multiple MAS instances (which I don't think affect this
> bitmask in any way).
>
> Johan
>
Yes, if we were to implement multiple instances using multiple
obex_service_driver structures (which would be needed in order to
support additional sdp records and additional channels), then we would
again have to add one define for each planned instance as obexd allows
adding only one service driver per service.
--
Slawomir Bochenski
^ permalink raw reply
* Re: How to implement multiple instances of obexd service?
From: Johan Hedberg @ 2010-12-13 13:21 UTC (permalink / raw)
To: Slawomir Bochenski; +Cc: linux-bluetooth
In-Reply-To: <AANLkTim2Q9dgj0t+AAcww33O=pdOHJp=sfQ_F7s8N08i@mail.gmail.com>
Hi Slawek,
On Mon, Dec 13, 2010, Slawomir Bochenski wrote:
> On Mon, Dec 13, 2010 at 1:00 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> >> And what about assigned bitmask values for services in src/obex.h?
> >
> > Do we need to change something there?
>
> In that case src/obex.h is the only place that will need simple
> modification for now -- MAP service value for services bitmask. This
> may be OBEX_MAP (or OBEX_MAS) and I supppose its value should be the
> next one available -- (1 << 8).
Right, we'll need that. I thought you were talking about something
related to multiple MAS instances (which I don't think affect this
bitmask in any way).
Johan
^ permalink raw reply
* Re: [PATCH] Setting default Link Policy according to the chip supported features
From: Johan Hedberg @ 2010-12-13 13:04 UTC (permalink / raw)
To: Pawel Wieczorkiewicz; +Cc: linux-bluetooth
In-Reply-To: <1292243202-6821-1-git-send-email-pawel.wieczorkiewicz@tieto.com>
Hi Pawel,
On Mon, Dec 13, 2010, Pawel Wieczorkiewicz wrote:
> By default all features are enabled (RSWITCH, HOLD, PARK, SNIFF).
> When "read local supported features" complete event occurs, not supported
> features are disabled and then "Write default link policy" command with
> supported features is sent.
>
> On behalf of ST-Ericsson SA
> ---
> plugins/hciops.c | 31 ++++++++++++++++---------------
> 1 files changed, 16 insertions(+), 15 deletions(-)
In general the patch seems fine and is actually a big improvement to the
hard coded link policy. In the long run I think it'd make sense for the
kernel to do this intialization, and I think I'll do that for mgmtops.
However for this hciops change I do have a few comments:
> static void read_local_features_complete(int index,
> const read_local_features_rp *rp)
> {
> + uint16_t policy;
> +
> if (rp->status)
> return;
>
> + /* Set default link policy */
> + if (!(rp->features[0] & LMP_RSWITCH))
> + main_opts.link_policy &= ~HCI_LP_RSWITCH;
> + if (!(rp->features[0] & LMP_HOLD))
> + main_opts.link_policy &= ~HCI_LP_HOLD;
> + if (!(rp->features[0] & LMP_SNIFF))
> + main_opts.link_policy &= ~HCI_LP_SNIFF;
> + if (!(rp->features[1] & LMP_PARK))
> + main_opts.link_policy &= ~HCI_LP_PARK;
> +
> + policy = htobs(main_opts.link_policy);
> + hci_send_cmd(SK(index), OGF_LINK_POLICY,
> + OCF_WRITE_DEFAULT_LINK_POLICY, 2, &policy);
> +
> memcpy(FEATURES(index), rp->features, 8);
read_local_features is the first command that the kernel sends (after
HCI_Reset) when bringing up a device. Therefore, I think it's a bit
early for userspace to send its own commands at this point. So I'd do
this in through the start_adapter function instead.
> @@ -2046,15 +2056,6 @@ static void init_device(int index)
> if (hci_devinfo(index, &di) < 0)
> goto fail;
>
> - if (!ignore_device(&di)) {
> - dr.dev_opt = main_opts.link_policy;
> - if (ioctl(dd, HCISETLINKPOL, (unsigned long) &dr) < 0 &&
> - errno != ENETDOWN) {
> - error("Can't set link policy on hci%d: %s (%d)",
> - index, strerror(errno), errno);
> - }
> - }
> -
> /* Start HCI device */
> if (ioctl(dd, HCIDEVUP, index) < 0 && errno != EALREADY) {
> error("Can't init device hci%d: %s (%d)",
It looks like the hci_devinfo call above isn't needed anymore after you
remove the ignore_device call. So please remove that too (as well as the
di variable from the function).
Johan
^ permalink raw reply
* Re: How to implement multiple instances of obexd service?
From: Slawomir Bochenski @ 2010-12-13 12:31 UTC (permalink / raw)
To: Slawomir Bochenski, linux-bluetooth
In-Reply-To: <20101213120003.GA12104@jh-x301>
Hello Johan,
On Mon, Dec 13, 2010 at 1:00 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
>> And what about assigned bitmask values for services in src/obex.h?
>
> Do we need to change something there?
In that case src/obex.h is the only place that will need simple
modification for now -- MAP service value for services bitmask. This
may be OBEX_MAP (or OBEX_MAS) and I supppose its value should be the
next one available -- (1 << 8).
--
Slawomir Bochenski
^ permalink raw reply
* [PATCH] Setting default Link Policy according to the chip supported features
From: Pawel Wieczorkiewicz @ 2010-12-13 12:26 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Pawel Wieczorkiewicz
By default all features are enabled (RSWITCH, HOLD, PARK, SNIFF).
When "read local supported features" complete event occurs, not supported
features are disabled and then "Write default link policy" command with
supported features is sent.
On behalf of ST-Ericsson SA
---
plugins/hciops.c | 31 ++++++++++++++++---------------
1 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/plugins/hciops.c b/plugins/hciops.c
index 4af137c..404422e 100644
--- a/plugins/hciops.c
+++ b/plugins/hciops.c
@@ -896,9 +896,25 @@ static void read_local_version_complete(int index,
static void read_local_features_complete(int index,
const read_local_features_rp *rp)
{
+ uint16_t policy;
+
if (rp->status)
return;
+ /* Set default link policy */
+ if (!(rp->features[0] & LMP_RSWITCH))
+ main_opts.link_policy &= ~HCI_LP_RSWITCH;
+ if (!(rp->features[0] & LMP_HOLD))
+ main_opts.link_policy &= ~HCI_LP_HOLD;
+ if (!(rp->features[0] & LMP_SNIFF))
+ main_opts.link_policy &= ~HCI_LP_SNIFF;
+ if (!(rp->features[1] & LMP_PARK))
+ main_opts.link_policy &= ~HCI_LP_PARK;
+
+ policy = htobs(main_opts.link_policy);
+ hci_send_cmd(SK(index), OGF_LINK_POLICY,
+ OCF_WRITE_DEFAULT_LINK_POLICY, 2, &policy);
+
memcpy(FEATURES(index), rp->features, 8);
if (!PENDING(index))
@@ -1949,7 +1965,6 @@ static void at_child_exit(void)
static void device_devup_setup(int index)
{
struct hci_dev_info di;
- uint16_t policy;
read_stored_link_key_cp cp;
DBG("hci%d", index);
@@ -1972,11 +1987,6 @@ static void device_devup_setup(int index)
WRITE_PAGE_TIMEOUT_CP_SIZE, &cp);
}
- /* Set default link policy */
- policy = htobs(main_opts.link_policy);
- hci_send_cmd(SK(index), OGF_LINK_POLICY,
- OCF_WRITE_DEFAULT_LINK_POLICY, 2, &policy);
-
bacpy(&cp.bdaddr, BDADDR_ANY);
cp.read_all = 1;
hci_send_cmd(SK(index), OGF_HOST_CTL, OCF_READ_STORED_LINK_KEY,
@@ -2046,15 +2056,6 @@ static void init_device(int index)
if (hci_devinfo(index, &di) < 0)
goto fail;
- if (!ignore_device(&di)) {
- dr.dev_opt = main_opts.link_policy;
- if (ioctl(dd, HCISETLINKPOL, (unsigned long) &dr) < 0 &&
- errno != ENETDOWN) {
- error("Can't set link policy on hci%d: %s (%d)",
- index, strerror(errno), errno);
- }
- }
-
/* Start HCI device */
if (ioctl(dd, HCIDEVUP, index) < 0 && errno != EALREADY) {
error("Can't init device hci%d: %s (%d)",
--
1.7.0.4
^ permalink raw reply related
* Re: How to implement multiple instances of obexd service?
From: Johan Hedberg @ 2010-12-13 12:00 UTC (permalink / raw)
To: Slawomir Bochenski; +Cc: linux-bluetooth
In-Reply-To: <AANLkTin4xG5KUEpn6QaZA0V6y3cDvxpWhwRJhMrE_8QO@mail.gmail.com>
Hi Slawek,
On Mon, Dec 13, 2010, Slawomir Bochenski wrote:
> In order to fully implement Message Access Profile, support for more
> than one so-called instance is needed (MAP specification, chapter
> 3.1.8). According to specs, separate e-mail accounts on MSE should be
> represented by separate MAS instances. This requires one SDP record
> per instance and those differ by MASInstanceID and ServiceName.
>
> As I understand this also implies that each and every instance needs
> its own separate RFCOMM channel?
Yep, I think that's implied, since othewise we can't detect which MAS
instance the client is trying to connect to (if I read the spec
correctly).
> What would be the preffered way to deal with this ugliness in obexd
> code?
Since we're primarly conserned with supporting only SMS for now, I think
it's too early to start adding complexity to the code due to this
feature. I.e. let's get working MAP with SMS support integrated upstream
and only after that start looking into these more advanced features.
> If separate channels are needed how to keep this in compliance
> with bluez doc/assigned-numbers.txt?
We'll need to reserve some channels for additional MAS instances.
> And what about assigned bitmask values for services in src/obex.h?
Do we need to change something there?
Johan
^ permalink raw reply
* How to implement multiple instances of obexd service?
From: Slawomir Bochenski @ 2010-12-13 11:10 UTC (permalink / raw)
To: linux-bluetooth
In order to fully implement Message Access Profile, support for more
than one so-called instance is needed (MAP specification, chapter
3.1.8). According to specs, separate e-mail accounts on MSE should be
represented by separate MAS instances. This requires one SDP record
per instance and those differ by MASInstanceID and ServiceName.
As I understand this also implies that each and every instance needs
its own separate RFCOMM channel?
What would be the preffered way to deal with this ugliness in obexd
code? If separate channels are needed how to keep this in compliance
with bluez doc/assigned-numbers.txt? And what about assigned bitmask values for
services in src/obex.h?
--
Slawomir Bochenski
^ permalink raw reply
* Re: Start dropping PCMCIA from compat-wireless for 2.6.38+
From: Holger Schurig @ 2010-12-13 7:46 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, linux-kernel, linux-bluetooth
In-Reply-To: <AANLkTik4W+UxgyPjVyHDeEFTRCkXdDBQ9obgPkpnhzGW@mail.gmail.com>
Please, if the burden is not too much, keep it for the benefit of
embedded people.
If you have some embedded device (e.g. ARM based), it's usually not so
easy to hieve this device to newest 2.6.3[5-7] kernel. However, it's
easy to use your adapted kernel, and compile compat-wireless against it.
I'm in such a situation with libertas_cs.
Greetings,
Holger
--
Homepage: http://www.holgerschurig.de
^ permalink raw reply
* EDR support
From: Manuel Naranjo @ 2010-12-11 20:18 UTC (permalink / raw)
To: BlueZ
Hi guys,
I was checking the latest BlueZ source code and the kernel source code,
and I noticed that by default EDR is disabled, when a dongle is detected
net/bluetooth/hci_core.c initializes the packet types with DM1, DH1 and
HV1, and then net/bluetooth/hci_event.c does it for DM3-5 DH3-5 and
HV3-5, but it never initializes the 2DHx or 3DHx. Was it made on purpose
or is it a bug in the code?
I just figured out how to help and try fixing it, but kernel hacking
isn't an easy to do task, and would prefer to get professional advice first.
Manuel
^ permalink raw reply
* Re: [PATCH] Initial draft of Application registration API
From: Claudio Takahasi @ 2010-12-11 19:27 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <AANLkTik8pqd0uaV2kVaeenBOfTPrVeO0YuW2mfQzJy1J@mail.gmail.com>
Hi Luiz,
On Fri, Dec 10, 2010 at 8:31 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Fri, Dec 10, 2010 at 6:13 AM, Claudio Takahasi
> <claudio.takahasi@openbossa.org> wrote:
>> doc/attribute-api.txt | 44 +++++++++++++++++++++++++++++++++++++++++++-
>> 1 files changed, 43 insertions(+), 1 deletions(-)
>>
>> diff --git a/doc/attribute-api.txt b/doc/attribute-api.txt
>> index 23808e6..ab62313 100644
>> --- a/doc/attribute-api.txt
>> +++ b/doc/attribute-api.txt
>> @@ -23,7 +23,6 @@ fully transparent and a differentiation becomes unimportant in the future.
>> A service consists of some generic service information and a set of
>> characteristics. All characteristic are presented as object path as well.
>>
>> -
>> Local Service hierarchy
>> =======================
>>
>> @@ -37,6 +36,35 @@ Methods
>> Properties
>>
>>
>> +Adapter Application Attribute hierarchy
>> +=======================================
>> +
>> +Service org.bluez
>> +Interface org.bluez.Attrib
>> +Object path [variable prefix]/{hci0,hci1,...}
>> +
>> +Methods void RegisterApplication(array{string} uuids, dict settings)
>> +
>> + Method to allow applications to control automatic
>> + connections to known devices.
>> +
>> + "settings" dictionary defines the wanted application
>> + connection parameters. Defined values:
>> + - Latency: low, medium and high
>> + - BandWidth: TBD
>> + - AutoConnect: boolean
>> +
>> + Latency parameter controls the scan and connect
>> + interval. AutoConnect parameter controls automatic
>> + connections if a bonded device emits a connectable
>> + advertising report.
>> +
>> + void UnregisterApplication(array{string} uuids)
>> +
>> + Unregister a previously registered application.
>> + Remotes are automatically disconnected if no more
>> + applications are interested in the given services.
>> +
>> Device Service hierarchy
>> ========================
>>
>> @@ -154,3 +182,17 @@ Object path freely definable
>> Methods void ValueChanged(object characteristic, array{byte})
>>
>> New raw value of the Characteristic Value attribute.
>> +
>> +Adapter Application Agent hierarchy
>> +====================================
>> +
>> +Service unique name
>> +Interface org.bluez.Application
>> +Object path freely definable
>> +
>> +Methods void Connected(object device, array{object} services)
>> +
>> + Indication that a given remote device was found
>> + and the connection has been established. service
>> + object represents an instance of a primary service
>> + that the application is interested in.
>
> It seems it is missing the object path on RegisterAplication to be
> used to call Connected, also I could see some use of this Application
> Agent for regular (non-LE) profiles, but of course the settings would
> have a bit different purpose for those.
>
> --
> Luiz Augusto von Dentz
> Computer Engineer
>
I discussed this issue with Vinicius before send the initial proposal,
but it is unclear to me if we need to support multiple calls/registers
for the same application or change the parameters. Returning an object
path will be easier to manage the unregister procedure, but once we
export an object path we need to export some methods and properties
for this object. For instance, allow the caller/owner change the UUIDs
and connection parameters.
Is it necessary to pass the application object path in the Connected
method? In my opinion only the object path for the primary services
are enough.
Implement the support for non-LE profiles will be trick, I am not sure
at the moment if we will be able to support BR/EDR and LE profiles
using the same API, but this is something that we already discussed
previously.
Claudio.
^ permalink raw reply
* AVDTP_DELAY_REPORT
From: pl bossart @ 2010-12-10 21:58 UTC (permalink / raw)
To: linux-bluetooth
Hi,
Does anyone know of audio headsets supporting the new DELAY_REPORT
commands? This could be very useful to improve a/v sync and may
require some additions to PulseAudio.
Thanks,
-Pierre
^ permalink raw reply
* Re: [PATCH] Fix crash while reading from mapped file
From: Luiz Augusto von Dentz @ 2010-12-10 17:45 UTC (permalink / raw)
To: Rafal Michalski; +Cc: linux-bluetooth
In-Reply-To: <1291989348-3911-1-git-send-email-michalski.raf@gmail.com>
Hi,
On Fri, Dec 10, 2010 at 3:55 PM, Rafal Michalski
<michalski.raf@gmail.com> wrote:
> After opening file from /var/lib/bluetooth/<bt_addr>/ and mapping to
> memory as it is done in "textfile_foreach" function in textfile.c,
> it may crash when size of file is equal to page size
> (or it's multiplicity) since "strpbrk" function operates on string
> so it expects zero at the end of buffer ("mmap" function zeroes
> remaining memory when mapped only for a file which size is not a
> multiple of the page size, so in this case "strpbrk" function can't
> find null terminating character and goes out of bounds).
> This patch provide buffer which contains null terminating character to
> avoid crash.
> ---
> src/textfile.c | 10 +++++++++-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/src/textfile.c b/src/textfile.c
> index 2429cc7..393efb8 100644
> --- a/src/textfile.c
> +++ b/src/textfile.c
> @@ -376,7 +376,7 @@ char *textfile_caseget(const char *pathname, const char *key)
> int textfile_foreach(const char *pathname, textfile_cb func, void *data)
> {
> struct stat st;
> - char *map, *off, *end, *key, *value;
> + char *map, *off, *end, *key, *value, *buffer = NULL;
> off_t size; size_t len;
> int fd, err = 0;
>
> @@ -404,6 +404,13 @@ int textfile_foreach(const char *pathname, textfile_cb func, void *data)
>
> off = map;
>
> + if (!(size % getpagesize())) {
> + buffer = malloc(size + 1);
> + memset(buffer, 0, size + 1);
> + memcpy(buffer, map, size);
> + off = buffer;
> + }
Isn't this doing exact the same as strncpy or g_strndup does? Actually
it is really too bad there is no str(n)pbrk variant.
> while (1) {
> end = strpbrk(off, " ");
> if (!end) {
> @@ -458,6 +465,7 @@ unlock:
>
> close:
> close(fd);
> + free(buffer);
> errno = err;
>
> return 0;
I also wonder why we didn't use g_strsplit for this, it seems it would
actually do the same, there is a little performance impact since we
would have to iterate on the vector generated to call the callback
while the current code do it in-place.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* [PATCH] Fix crash while reading from mapped file
From: Rafal Michalski @ 2010-12-10 13:55 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafal Michalski
After opening file from /var/lib/bluetooth/<bt_addr>/ and mapping to
memory as it is done in "textfile_foreach" function in textfile.c,
it may crash when size of file is equal to page size
(or it's multiplicity) since "strpbrk" function operates on string
so it expects zero at the end of buffer ("mmap" function zeroes
remaining memory when mapped only for a file which size is not a
multiple of the page size, so in this case "strpbrk" function can't
find null terminating character and goes out of bounds).
This patch provide buffer which contains null terminating character to
avoid crash.
---
src/textfile.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/src/textfile.c b/src/textfile.c
index 2429cc7..393efb8 100644
--- a/src/textfile.c
+++ b/src/textfile.c
@@ -376,7 +376,7 @@ char *textfile_caseget(const char *pathname, const char *key)
int textfile_foreach(const char *pathname, textfile_cb func, void *data)
{
struct stat st;
- char *map, *off, *end, *key, *value;
+ char *map, *off, *end, *key, *value, *buffer = NULL;
off_t size; size_t len;
int fd, err = 0;
@@ -404,6 +404,13 @@ int textfile_foreach(const char *pathname, textfile_cb func, void *data)
off = map;
+ if (!(size % getpagesize())) {
+ buffer = malloc(size + 1);
+ memset(buffer, 0, size + 1);
+ memcpy(buffer, map, size);
+ off = buffer;
+ }
+
while (1) {
end = strpbrk(off, " ");
if (!end) {
@@ -458,6 +465,7 @@ unlock:
close:
close(fd);
+ free(buffer);
errno = err;
return 0;
--
1.6.3.3
^ permalink raw reply related
* Re: A2DP reconfigure with BMW Carkit (supporting multi streams) timeouts.
From: roystonr @ 2010-12-10 12:19 UTC (permalink / raw)
To: Luiz Augusto von Dentz, Johan Hedberg
Cc: linux-bluetooth, roystonr, skrovvid, rshaffer
In-Reply-To: <c2cb901974d908ed9f808324e4b4f6fb.squirrel@www.codeaurora.org>
Hi Johan/Luiz,
> On Fri, Dec 10, 2010, Luiz Augusto von Dentz wrote:
> I guess it would be better to have the call to
> avdtp_stream_get_remote_sep on close_cfm, it is probably safer to do
> there and less code too, but the fix is probably right.
Along with this as per my understanding, struct avdtp_remote_sep *rsep has
to be added as member to struct a2dp_setup and rsep should be overridden
as follows in a2dp_reconfigure after call to avdtp_get_seps which returns
the sep corresponding to the stream not in use. If the remote device
supports multi-stream then sep returned would be based on the order of
get_capabilities response. Hence the following override is needed to
ensure that closed stream is reconfigured. Correct me if mistaken.
if (setup->rsep) {
rsep = setup->rsep;
}
Have provided the patch to the tester to verify as we don't have the BMW
CK available locally. Would update the feedback received.
Regards,
Royston Rodrigues
^ permalink raw reply
* Re: A2DP reconfigure with BMW Carkit (supporting multi streams) timeouts.
From: Johan Hedberg @ 2010-12-10 10:32 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: roystonr, linux-bluetooth, skrovvid, rshaffer
In-Reply-To: <AANLkTik78DiC7TgWtR0q=xPs+ZZq470_md-gJWv8tB8f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 376 bytes --]
Hi Luiz,
On Fri, Dec 10, 2010, Luiz Augusto von Dentz wrote:
> I guess it would be better to have the call to
> avdtp_stream_get_remote_sep on close_cfm, it is probably safer to do
> there and less code too, but the fix is probably right.
Good point. Attach is a patch which does this. Could we now please get
some feedback from the reporter if this really helps? :)
Johan
[-- Attachment #2: acp_sep_selection.patch --]
[-- Type: text/x-diff, Size: 1420 bytes --]
diff --git a/audio/a2dp.c b/audio/a2dp.c
index b1e94d9..b46cef1 100644
--- a/audio/a2dp.c
+++ b/audio/a2dp.c
@@ -1097,6 +1097,9 @@ static void close_cfm(struct avdtp *session, struct avdtp_local_sep *sep,
return;
}
+ if (!setup->rsep)
+ setup->rsep = avdtp_stream_get_remote_sep(stream);
+
if (setup->reconfigure)
g_timeout_add(RECONFIGURE_TIMEOUT, a2dp_reconfigure, setup);
}
diff --git a/audio/avdtp.c b/audio/avdtp.c
index 1683e7c..33178c3 100644
--- a/audio/avdtp.c
+++ b/audio/avdtp.c
@@ -3133,6 +3133,12 @@ gboolean avdtp_stream_has_capabilities(struct avdtp_stream *stream,
return TRUE;
}
+struct avdtp_remote_sep *avdtp_stream_get_remote_sep(
+ struct avdtp_stream *stream)
+{
+ return avdtp_get_remote_sep(stream->session, stream->rseid);
+}
+
gboolean avdtp_stream_get_transport(struct avdtp_stream *stream, int *sock,
uint16_t *imtu, uint16_t *omtu,
GSList **caps)
diff --git a/audio/avdtp.h b/audio/avdtp.h
index 9406fa7..5f37dc3 100644
--- a/audio/avdtp.h
+++ b/audio/avdtp.h
@@ -257,6 +257,8 @@ gboolean avdtp_stream_has_capability(struct avdtp_stream *stream,
struct avdtp_service_capability *cap);
gboolean avdtp_stream_has_capabilities(struct avdtp_stream *stream,
GSList *caps);
+struct avdtp_remote_sep *avdtp_stream_get_remote_sep(
+ struct avdtp_stream *stream);
unsigned int avdtp_add_state_cb(avdtp_session_state_cb cb, void *user_data);
^ permalink raw reply related
* Re: [PATCH] Initial draft of Application registration API
From: Luiz Augusto von Dentz @ 2010-12-10 10:31 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1291954417-18138-1-git-send-email-claudio.takahasi@openbossa.org>
Hi,
On Fri, Dec 10, 2010 at 6:13 AM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> doc/attribute-api.txt | 44 +++++++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 43 insertions(+), 1 deletions(-)
>
> diff --git a/doc/attribute-api.txt b/doc/attribute-api.txt
> index 23808e6..ab62313 100644
> --- a/doc/attribute-api.txt
> +++ b/doc/attribute-api.txt
> @@ -23,7 +23,6 @@ fully transparent and a differentiation becomes unimportant in the future.
> A service consists of some generic service information and a set of
> characteristics. All characteristic are presented as object path as well.
>
> -
> Local Service hierarchy
> =======================
>
> @@ -37,6 +36,35 @@ Methods
> Properties
>
>
> +Adapter Application Attribute hierarchy
> +=======================================
> +
> +Service org.bluez
> +Interface org.bluez.Attrib
> +Object path [variable prefix]/{hci0,hci1,...}
> +
> +Methods void RegisterApplication(array{string} uuids, dict settings)
> +
> + Method to allow applications to control automatic
> + connections to known devices.
> +
> + "settings" dictionary defines the wanted application
> + connection parameters. Defined values:
> + - Latency: low, medium and high
> + - BandWidth: TBD
> + - AutoConnect: boolean
> +
> + Latency parameter controls the scan and connect
> + interval. AutoConnect parameter controls automatic
> + connections if a bonded device emits a connectable
> + advertising report.
> +
> + void UnregisterApplication(array{string} uuids)
> +
> + Unregister a previously registered application.
> + Remotes are automatically disconnected if no more
> + applications are interested in the given services.
> +
> Device Service hierarchy
> ========================
>
> @@ -154,3 +182,17 @@ Object path freely definable
> Methods void ValueChanged(object characteristic, array{byte})
>
> New raw value of the Characteristic Value attribute.
> +
> +Adapter Application Agent hierarchy
> +====================================
> +
> +Service unique name
> +Interface org.bluez.Application
> +Object path freely definable
> +
> +Methods void Connected(object device, array{object} services)
> +
> + Indication that a given remote device was found
> + and the connection has been established. service
> + object represents an instance of a primary service
> + that the application is interested in.
It seems it is missing the object path on RegisterAplication to be
used to call Connected, also I could see some use of this Application
Agent for regular (non-LE) profiles, but of course the settings would
have a bit different purpose for those.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: A2DP reconfigure with BMW Carkit (supporting multi streams) timeouts.
From: Luiz Augusto von Dentz @ 2010-12-10 9:51 UTC (permalink / raw)
To: roystonr, linux-bluetooth, skrovvid, rshaffer
In-Reply-To: <20101209144103.GA30557@jh-x301>
Hi,
On Thu, Dec 9, 2010 at 4:41 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Royston,
>
> On Thu, Dec 09, 2010, roystonr@codeaurora.org wrote:
>> Change expected:
>> avdtp_get_seps should be able to provide the SEP of the one used in the
>> AVDTP_CLOSE previously. But there weren't any previously closed streams
>> then provide the SEP which is not in use (as done currently).
>>
>> Kindly let us know whether our understanding is right and can this be a
>> suspected cause of the issue seen. Correct if mistaken.
>
> Sounds like that might be the cause. Have you experimented with patching
> the bluez code to reuse the same SEP as was used for the Close? If not
> I'd advice you to do that so we can be sure that a change to the ACP SEP
> selection logic makes sense.
>
> Right now the reconfiguration happens in audio/a2dp.c where there's a
> setup->reconfigure flag to track if a new stream should be configured
> after receiving close_ind. The a2dp_reconfigure function in a2dp.c is
> responsible for selecting the remote SEP. Could you try the attached
> (completely untested) patch to see if it helps? It stores the old remote
> SEP in the setup structure when starting the Close procedure in which
> case a2dp_reconfigure() shouldn't try to reselect a new remote SEP but
> use the stored one instead.
I guess it would be better to have the call to
avdtp_stream_get_remote_sep on close_cfm, it is probably safer to do
there and less code too, but the fix is probably right.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH 1/1] bluetooth: Fix NULL pointer dereference issue
From: Ville Tervo @ 2010-12-10 7:17 UTC (permalink / raw)
To: Yuri Ershov
Cc: ext Gustavo F. Padovan, andrei.emeltchenko,
linux-bluetooth@vger.kernel.org
In-Reply-To: <4CFF6359.7000305@nokia.com>
Hi Yuri,
On Wed, Dec 08, 2010 at 01:52:09PM +0300, Yuri Ershov wrote:
> >>>So in which situations (n == p), or (p == p->next)? That should happen only
> >>>when p is the only element in the list, then p == head, right?
> >>The (n == p) is in situation, when sk is unlinked by task
> >>responsible for handling connect/disconnect requests while the
> >>"bt_accept_dequeue". This condition is indirect checking of sk
> >>validity.
> >
> >Why not using a list lock here instead? Fits a way better.
> >
> Yes, it's better. I tried to use the locks in this function, but it
> slows down the task handling connect/disconnect/etc. events and the
> task skips some events from fast clients.
>
What kind of problems you exactly got with locks? Maybe they should be fixed
also.
--
Ville
^ permalink raw reply
* Re: [PATCH] Initial draft of Application registration API
From: Claudio Takahasi @ 2010-12-10 5:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1291954417-18138-1-git-send-email-claudio.takahasi@openbossa.org>
Hi,
It should be a RFC instead of PATCH in the subject prefix.
On Fri, Dec 10, 2010 at 1:13 AM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> Add new methods to allow automatic connection when a known remote device
> which supports the wanted services is found.
>
> Overview: RegisterApplication method allows a given application to
> controls the connection establishment procedure for bonded devices.
> StartDiscovery() implements an interleaved discovery, switching between
> inquiry and LE active scanning. For single mode devices found, an
> application can call CreateDevice or CreatePairedDevice, these methods
> will trigger the Discover All Primary Services and SSP(if applied).
Please read SMP instead of SSP for CreatePairedDevice. GATT/ATT
implements a per attribute permission, for BlueZ we are planning to
use CreatePairedDevice to trigger the SMP/key distribution. SMP
negotiation is being implemented completely in the kernel, but at the
moment there isn't key storage and management interface between the
kernel and the userspace to notify the keys. SMP just works method
will be triggered when the client access the first attribute which
requires encryption or when a encrypted link is created.
IMHO, automatic connections needs to be restricted to bonded devices.
If necessary, we can also use the Trusted property.
Claudio
^ permalink raw reply
* Re: RFC: Allow Bluez to select flushable or non-flushable ACL packets with L2CAP_LM_RELIABLE
From: Suraj Sumangala @ 2010-12-10 4:25 UTC (permalink / raw)
To: Nick Pelly
Cc: Andrei Emeltchenko, Luiz Augusto von Dentz, Marcel Holtmann,
linux-bluetooth@vger.kernel.org
In-Reply-To: <AANLkTinbaqh_vXsNUHR4-XKfP-50dbmvNxM3QkZvnFjv@mail.gmail.com>
Hi,
On 12/9/2010 10:25 PM, Nick Pelly wrote:
> On Thu, Dec 9, 2010 at 2:37 AM, Andrei Emeltchenko
> <andrei.emeltchenko.news@gmail.com> wrote:
>>
>> Hi All,
>>
>> On Wed, Jun 16, 2010 at 5:15 PM, Nick Pelly<npelly@google.com> wrote:
>>> On Wed, Jun 16, 2010 at 4:40 AM, Luiz Augusto von Dentz
>>> <luiz.dentz@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> On Tue, Mar 9, 2010 at 11:45 PM, Marcel Holtmann<marcel@holtmann.org> wrote:
>>>>> Hi Nick,
>>>>>
>>>>>>>>>>> Right now Bluez always requests flushable ACL packets (but does not
>>>>>>>>>>> set a flush timeout, so effectively they are non-flushable):
>>>>>>>>>>>
>>>>>>>>>>> However it is desirable to use an ACL flush timeout on A2DP packets so
>>>>>>>>>>> that if the ACL packets block for some reason then the LM can flush
>>>>>>>>>>> them to make room for newer packets.
>>>>>>>>>>>
>>>>>>>>>>> Is it reasonable for Bluez to use the 0x00 ACL packet boundary flag by
>>>>>>>>>>> default (non-flushable packet), and let userspace request flushable
>>>>>>>>>>> packets on A2DP L2CAP sockets with the socket option
>>>>>>>>>>> L2CAP_LM_RELIABLE.
>>>>>>>>>>
>>>>>>>>>> the reliable option has a different meaning. It comes back from the old
>>>>>>>>>> Bluetooth 1.1 qualification days where we had to tests on L2CAP that had
>>>>>>>>>> to confirm that we can detect malformed packets and report them. These
>>>>>>>>>> days it is just fine to drop them.
>>>>>>>>>
>>>>>>>>> Got it, how about introducing
>>>>>>>>>
>>>>>>>>> #define L2CAP_LM_FLUSHABLE 0x0040
>>>>>>>>
>>>>>>>> that l2cap_sock_setsockopt_old() sets this didn't give you a hint that
>>>>>>>> we might wanna deprecate this socket options ;)
>>>>>>>>
>>>>>>>> I need to read up on the flushable stuff, but in the end it deserves its
>>>>>>>> own socket option. Also an ioctl() to actually trigger Enhanced flush
>>>>>>>> might be needed.
>>>>>>>>
>>>>>>>>> struct l2cap_pinfo {
>>>>>>>>> ...
>>>>>>>>> __u8 flushable;
>>>>>>>>> }
>>>>>>>>
>>>>>>>> Sure. In the long run we need to turn this into a bitmask. We are just
>>>>>>>> wasting memory here.
>>>>>>>
>>>>>>> Attached is an updated patch, that checks the LMP features bitmask
>>>>>>> before using the new non-flushable packet type.
>>>>>>>
>>>>>>> I am still using L2CAP_LM_FLUSHABLE socket option in
>>>>>>> l2cap_sock_setsockopt_old(), which I don't think you are happy with.
>>>>>>> So how about a new option:
>>>>>>>
>>>>>>> SOL_L2CAP, L2CAP_ACL_FLUSH
>>>>>>> which has a default value of 0, and can be set to 1 to make the ACL
>>>>>>> data sent by this L2CAP socket flushable.
>>>>>>>
>>>>>>> In a later commit we would then add
>>>>>>> SOL_ACL, ACL_FLUSH_TIMEOUT
>>>>>>> That is used to set an automatic flush timeout for the ACL link on a
>>>>>>> L2CAP socket. Note that SOL_ACL is new.
>>>>>>>
>>>>>>> But maybe this is not what you had in mind, so I'm looking for your
>>>>>>> advice before I implement this.
>>>>>>
>>>>>> Attached an updated patch for 2.6.32 kernel. We've been using this
>>>>>> patch successfully on production devices.
>>>>>
>>>>> can see anything wrong with that patch. However we need to use
>>>>> SOL_BLUETOOTH for it of course. So we need to come up with something to
>>>>> make this simple.
>>
>> Nick are you going to take Marcel comments? Otherwise I could take
>> care about the patch as it seems that it might help in some
>> situations.
>
> I'm not actively working on this patch.
>
>>>>> An additional change I like to see is to use flags for booleans like
>>>>> flushable in the structures. Can you work on changing that.
>>>>>
>>>>> Also do we have decoding support for this in hcidump. It might be nice
>>>>> to include some really simple examples in the commit message.
>>
>> At least wireshark which I use understands those packets.
>>
>>>> I would like to play a little bit with this, so is there any missing updates?
>>>
>>> Nope, that is our most recent version.
>>
>> Nick, do you know headset which could help to hear the real
>> difference? I was trying to use Sony DR-BT22 headset which has some
>> issues with A2DP but the solution did not help much.
>
> It becomes essential in non-ideal radio bandwidth conditions such as
> single antenna wifi co-existence. We also had some headsets that
> exacerbated the problem (presumably they had less logic to 'catch-up'
> through late packets) but I can't remember off hand.
I think you should be able to reproduce the same issue using any A2DP
headset.
Use a CSR dongle as local controller and start streaming A2DP data.
Parallel to that initiate an FTP connection to another device.
Take the headset out of range, or keep it in a shield box.
You should be able to see that the FTP link also stalls as the A2DP
packets are stalled in controller without getting flushed.
>
> Nick
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Regards
Suraj
^ permalink raw reply
* [PATCH] Initial draft of Application registration API
From: Claudio Takahasi @ 2010-12-10 4:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
Add new methods to allow automatic connection when a known remote device
which supports the wanted services is found.
Overview: RegisterApplication method allows a given application to
controls the connection establishment procedure for bonded devices.
StartDiscovery() implements an interleaved discovery, switching between
inquiry and LE active scanning. For single mode devices found, an
application can call CreateDevice or CreatePairedDevice, these methods
will trigger the Discover All Primary Services and SSP(if applied).
Characteristics will be fetched on demand to avoid unnecessary data
transfers.
The Generic attribute API exposes methods to applications to read and
write characteristics. Implement profile specific API will be avoided.
For example, Proximity Monitor may need a BlueZ plugin to monitor the
path loss however additional method specific to this profile doesn't
need to be exposed. The Generic API can expose all the characteristic
necessary to a Proximity client application.
Characteristic Watchers allow the applications to monitor(passively)
characteristics changes for a given primary service. It doesn't control
or trigger any connection establishment.
Register application will act as an advertising monitor, allowing
external applications to control passive scanning and automatic
connections(for bonded devices).
Open: Define the necessary parameters for RegisterApplication, support
for GAP Broadcaster/Observer, define if RegisterApplication needs to
support BR/EDR connections, maybe merge Watchers and Application
interfaces.
---
doc/attribute-api.txt | 44 +++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/doc/attribute-api.txt b/doc/attribute-api.txt
index 23808e6..ab62313 100644
--- a/doc/attribute-api.txt
+++ b/doc/attribute-api.txt
@@ -23,7 +23,6 @@ fully transparent and a differentiation becomes unimportant in the future.
A service consists of some generic service information and a set of
characteristics. All characteristic are presented as object path as well.
-
Local Service hierarchy
=======================
@@ -37,6 +36,35 @@ Methods
Properties
+Adapter Application Attribute hierarchy
+=======================================
+
+Service org.bluez
+Interface org.bluez.Attrib
+Object path [variable prefix]/{hci0,hci1,...}
+
+Methods void RegisterApplication(array{string} uuids, dict settings)
+
+ Method to allow applications to control automatic
+ connections to known devices.
+
+ "settings" dictionary defines the wanted application
+ connection parameters. Defined values:
+ - Latency: low, medium and high
+ - BandWidth: TBD
+ - AutoConnect: boolean
+
+ Latency parameter controls the scan and connect
+ interval. AutoConnect parameter controls automatic
+ connections if a bonded device emits a connectable
+ advertising report.
+
+ void UnregisterApplication(array{string} uuids)
+
+ Unregister a previously registered application.
+ Remotes are automatically disconnected if no more
+ applications are interested in the given services.
+
Device Service hierarchy
========================
@@ -154,3 +182,17 @@ Object path freely definable
Methods void ValueChanged(object characteristic, array{byte})
New raw value of the Characteristic Value attribute.
+
+Adapter Application Agent hierarchy
+====================================
+
+Service unique name
+Interface org.bluez.Application
+Object path freely definable
+
+Methods void Connected(object device, array{object} services)
+
+ Indication that a given remote device was found
+ and the connection has been established. service
+ object represents an instance of a primary service
+ that the application is interested in.
--
1.7.3.3
^ permalink raw reply related
* Re: compat-wireless-2.6.37-rc5 released
From: Luis R. Rodriguez @ 2010-12-10 1:08 UTC (permalink / raw)
To: linux-wireless; +Cc: linux-kernel, linux-bluetooth
In-Reply-To: <AANLkTim5HQGNL-vSapeQw_-dJue89pYz7zc8eiShma8j@mail.gmail.com>
On Wed, Dec 8, 2010 at 4:15 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> In later releases we will have to consider if we want to cherry pick
> anything extra or leave them as is. These few patches seem tempting to
> suck in:
>
> 01-ath9k-OTP.patch
> 03-ath9k-no-aggr-VO.patch
> 04-mac80211-no-aggr-VO.patch
> 05-ath9k-Reintroduce-modparam-to-enable-btcoex.patch
> 06-ath9k_hw-fix-A-MPDU-key-search-issues-on-AR9003.patch
>
> Particularly it is now known AR9003 devices will only ship with OTP
> so..
So it turns out this is inaccurate, AR9003 devices can ship with
EEPROM only or with OTP, it will vary, so while 2.6.36 and 2.6.37 will
not support only OTP based devices 2.6.38 will support both. What we
can do is cherry pick the OTP patches to the 2.6.36 and 2.6.37
compat-wireless releases but those two older stock kernels won't have
support for these.
Luis
^ permalink raw reply
* Re: Start dropping PCMCIA from compat-wireless for 2.6.38+
From: Luis R. Rodriguez @ 2010-12-09 22:39 UTC (permalink / raw)
To: Jesper Juhl; +Cc: linux-wireless, linux-kernel, linux-bluetooth
In-Reply-To: <alpine.LNX.2.00.1012092329480.25880@swampdragon.chaosbits.net>
On Thu, Dec 9, 2010 at 2:31 PM, Jesper Juhl <jj@chaosbits.net> wrote:
> On Thu, 9 Dec 2010, Luis R. Rodriguez wrote:
>
>> I'm going to start dropping PCMCIA stuff from compat-wireless as I
>> don't think we have any users of it nor interest to keep backporting
>> it. This entails dropping drivers like orinoco, b43 PCMCIA support,
>> libertas, as well as bluetooth bluecard_cs, bluecard_cs, dtl1_cs,
>> bt3c_cs and of course CONFIG_SSB_PCMCIAHOST. If you are a user please
>> yell now.
>>
> Yelling.
> While I'm not personally a user, my mother is. She still has an old IBM
> Thinkpad 600 laptop with a PCMCIA card in it that uses the orinoco driver.
And you have your mother using compat-wireless?
Luis
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox