Re: pull request: wireless-next-2.6 2011-02-22

From: "John W. Linville" <redacted>
Date: Tue, 22 Feb 2011 16:52:30 -0500

Here is the latest batch of wireless bits intended for 2.6.39.  It seems
I neglected to send a pull request last week, so this one is a bit big
-- I apologize!

This includes a rather large batch of bluetooth bits by way of Gustavo.
It looks like a variety of bits, including some code refactoring, some
protocol support enhancements, some bugfixes, etc. -- nothing too
unusual.

Other items of interest include a new driver from Realtek, some ssb
support enhancements, and the usual sort of updates for mac80211 and a
variety of drivers.  Also included is a wireless-2.6 pull to resolve
some build breakage.

Please let me know if there are problems!

Pulled, thanks a lot John.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Date: Thu, 24 Feb 2011 22:43:44 -0800 (PST)

From: "John W. Linville" <redacted>
Date: Tue, 22 Feb 2011 16:52:30 -0500

quoted

Here is the latest batch of wireless bits intended for 2.6.39.  It seems
I neglected to send a pull request last week, so this one is a bit big
-- I apologize!

This includes a rather large batch of bluetooth bits by way of Gustavo.
It looks like a variety of bits, including some code refactoring, some
protocol support enhancements, some bugfixes, etc. -- nothing too
unusual.

Other items of interest include a new driver from Realtek, some ssb
support enhancements, and the usual sort of updates for mac80211 and a
variety of drivers.  Also included is a wireless-2.6 pull to resolve
some build breakage.

Please let me know if there are problems!

Pulled, thanks a lot John.

John a few things:

1) I had to add some vmalloc.h includes to fix the build on sparc64,
   see commit b08cd667c4b6641c4d16a3f87f4550f81a6d69ac in net-next-2.6

2) Something is screwey with the bluetooth config options now.

   I have an allmodconfig tree, and when I run "make oldconfig" after
   this pull, BT_L2CAP and BT_SCO both prompt me, claiming that they
   can only be built statically.

   I give it 'y' just to make it happen, for both, and afterways no
   matter how many times I rerun "make oldconfig" I keep seeing things
   like this in my build:

scripts/kconfig/conf --silentoldconfig Kconfig
include/config/auto.conf:986:warning: symbol value 'm' invalid for BT_SCO
include/config/auto.conf:3156:warning: symbol value 'm' invalid for BT_L2CAP

   First, what the heck is going on here?  Second, why the heck can't these
   non-trivial pieces of code be built modular any more?

   You can't make something "bool", have it depend on something that
   might be modular, and then build it into what could in fact be a
   module.  That's exactly what the bluetooth stuff seems to be doing
   now.

   I suspect commit 642745184f82688eb3ef0cdfaa4ba632055be9af

Thanks.

Hi David,

* David Miller [off-list ref] [2011-02-25 11:15:00 -0800]:

From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Date: Thu, 24 Feb 2011 22:43:44 -0800 (PST)

quoted

From: "John W. Linville" <redacted>
Date: Tue, 22 Feb 2011 16:52:30 -0500

quoted

Here is the latest batch of wireless bits intended for 2.6.39.  It seems
I neglected to send a pull request last week, so this one is a bit big
-- I apologize!

This includes a rather large batch of bluetooth bits by way of Gustavo.
It looks like a variety of bits, including some code refactoring, some
protocol support enhancements, some bugfixes, etc. -- nothing too
unusual.

Other items of interest include a new driver from Realtek, some ssb
support enhancements, and the usual sort of updates for mac80211 and a
variety of drivers.  Also included is a wireless-2.6 pull to resolve
some build breakage.

Please let me know if there are problems!

Pulled, thanks a lot John.

John a few things:

1) I had to add some vmalloc.h includes to fix the build on sparc64,
   see commit b08cd667c4b6641c4d16a3f87f4550f81a6d69ac in net-next-2.6

2) Something is screwey with the bluetooth config options now.

   I have an allmodconfig tree, and when I run "make oldconfig" after
   this pull, BT_L2CAP and BT_SCO both prompt me, claiming that they
   can only be built statically.

   I give it 'y' just to make it happen, for both, and afterways no
   matter how many times I rerun "make oldconfig" I keep seeing things
   like this in my build:

scripts/kconfig/conf --silentoldconfig Kconfig
include/config/auto.conf:986:warning: symbol value 'm' invalid for BT_SCO
include/config/auto.conf:3156:warning: symbol value 'm' invalid for BT_L2CAP

   First, what the heck is going on here?  Second, why the heck can't these
   non-trivial pieces of code be built modular any more?

We now have L2CAP and SCO built-in in the main bluetooth.ko module.

   You can't make something "bool", have it depend on something that
   might be modular, and then build it into what could in fact be a
   module.  That's exactly what the bluetooth stuff seems to be doing
   now.

Seems I did the Kconfig change wrong, I'll fix it ASAP and send it to you
guys.

-- 
Gustavo F. Padovan
http://profusion.mobi

On Fri, Feb 25, 2011 at 11:15:00AM -0800, David Miller wrote:

From: David Miller <davem@davemloft.net>
Date: Thu, 24 Feb 2011 22:43:44 -0800 (PST)

quoted

Pulled, thanks a lot John.

John a few things:

1) I had to add some vmalloc.h includes to fix the build on sparc64,
   see commit b08cd667c4b6641c4d16a3f87f4550f81a6d69ac in net-next-2.6

I have a patch in my tree for that -- seems they hit it on ARM as well.

2) Something is screwey with the bluetooth config options now.

   I have an allmodconfig tree, and when I run "make oldconfig" after
   this pull, BT_L2CAP and BT_SCO both prompt me, claiming that they
   can only be built statically.

   I give it 'y' just to make it happen, for both, and afterways no
   matter how many times I rerun "make oldconfig" I keep seeing things
   like this in my build:

scripts/kconfig/conf --silentoldconfig Kconfig
include/config/auto.conf:986:warning: symbol value 'm' invalid for BT_SCO
include/config/auto.conf:3156:warning: symbol value 'm' invalid for BT_L2CAP

   First, what the heck is going on here?  Second, why the heck can't these
   non-trivial pieces of code be built modular any more?

   You can't make something "bool", have it depend on something that
   might be modular, and then build it into what could in fact be a
   module.  That's exactly what the bluetooth stuff seems to be doing
   now.

   I suspect commit 642745184f82688eb3ef0cdfaa4ba632055be9af

Thanks.

Sorry, I overlooked that.  Hopefully Gustavo will figure it out quickly.

Thanks,

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

* Gustavo F. Padovan [off-list ref] [2011-02-25 16:36:18 -0300]:

Hi David,

* David Miller [off-list ref] [2011-02-25 11:15:00 -0800]:

quoted

From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Date: Thu, 24 Feb 2011 22:43:44 -0800 (PST)

quoted

From: "John W. Linville" <redacted>
Date: Tue, 22 Feb 2011 16:52:30 -0500

quoted

Here is the latest batch of wireless bits intended for 2.6.39.  It seems
I neglected to send a pull request last week, so this one is a bit big
-- I apologize!

This includes a rather large batch of bluetooth bits by way of Gustavo.
It looks like a variety of bits, including some code refactoring, some
protocol support enhancements, some bugfixes, etc. -- nothing too
unusual.

Other items of interest include a new driver from Realtek, some ssb
support enhancements, and the usual sort of updates for mac80211 and a
variety of drivers.  Also included is a wireless-2.6 pull to resolve
some build breakage.

Please let me know if there are problems!

Pulled, thanks a lot John.

John a few things:

1) I had to add some vmalloc.h includes to fix the build on sparc64,
   see commit b08cd667c4b6641c4d16a3f87f4550f81a6d69ac in net-next-2.6

2) Something is screwey with the bluetooth config options now.

   I have an allmodconfig tree, and when I run "make oldconfig" after
   this pull, BT_L2CAP and BT_SCO both prompt me, claiming that they
   can only be built statically.

   I give it 'y' just to make it happen, for both, and afterways no
   matter how many times I rerun "make oldconfig" I keep seeing things
   like this in my build:

scripts/kconfig/conf --silentoldconfig Kconfig
include/config/auto.conf:986:warning: symbol value 'm' invalid for BT_SCO
include/config/auto.conf:3156:warning: symbol value 'm' invalid for BT_L2CAP

   First, what the heck is going on here?  Second, why the heck can't these
   non-trivial pieces of code be built modular any more?

We now have L2CAP and SCO built-in in the main bluetooth.ko module.

quoted

   You can't make something "bool", have it depend on something that
   might be modular, and then build it into what could in fact be a
   module.  That's exactly what the bluetooth stuff seems to be doing
   now.

Seems I did the Kconfig change wrong, I'll fix it ASAP and send it to you
guys.

I Figured the problem. When I first wrote this I based the work in other
Kconfig in net/ (as it was my very first time doing such kind of changes in a
Kconfig). For example, net/decnet/ and net/ax25/ do exactly the same as the
Bluetooth Kconfig. "bool" depending on "tristate" and build both together.

But doing another look after your report there is some places where this is
done a bit different, net/ipv6 and net/mac80211 are examples. Then I changed
to this new approach to remove the direct dependency from BT_L2CAP and BT_SCO.
Patch follows this e-mail.

That point me out that we may have other subsystems doing it wrong and we have
to fix this.

-- 
Gustavo F. Padovan
http://profusion.mobi

If we want something "bool" built-in in something "tristate" it can't
"depend on" the tristate config option.

Report by DaveM:

   I give it 'y' just to make it happen, for both, and afterways no
   matter how many times I rerun "make oldconfig" I keep seeing things
   like this in my build:

scripts/kconfig/conf --silentoldconfig Kconfig
include/config/auto.conf:986:warning: symbol value 'm' invalid for BT_SCO
include/config/auto.conf:3156:warning: symbol value 'm' invalid for BT_L2CAP

Reported-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Signed-off-by: Gustavo F. Padovan <redacted>
---
 net/bluetooth/Kconfig |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig
index c6f9c2f..6ae5ec5 100644
--- a/net/bluetooth/Kconfig
+++ b/net/bluetooth/Kconfig

@@ -31,9 +31,10 @@ menuconfig BT
 	  to Bluetooth kernel modules are provided in the BlueZ packages.  For
 	  more information, see <http://www.bluez.org/>.
 
+if BT != n
+
 config BT_L2CAP
 	bool "L2CAP protocol support"
-	depends on BT
 	select CRC16
 	help
 	  L2CAP (Logical Link Control and Adaptation Protocol) provides

@@ -42,11 +43,12 @@ config BT_L2CAP
 
 config BT_SCO
 	bool "SCO links support"
-	depends on BT
 	help
 	  SCO link provides voice transport over Bluetooth.  SCO support is
 	  required for voice applications like Headset and Audio.
 
+endif
+
 source "net/bluetooth/rfcomm/Kconfig"
 
 source "net/bluetooth/bnep/Kconfig"

-- 
1.7.4.1

Hi Gustavo,

On Sat, Feb 26, 2011 at 2:41 AM, Gustavo F. Padovan
[off-list ref] wrote:

Ugh, isn't it far cleaner to change initial dependencies to "depends
on BT != n" ?

Thanks,
   Vitaly

Hi Vitaly,

* Vitaly Wool [off-list ref] [2011-02-26 18:52:44 +0100]:

Hi Gustavo,

On Sat, Feb 26, 2011 at 2:41 AM, Gustavo F. Padovan
[off-list ref] wrote:

quoted

If we want something "bool" built-in in something "tristate" it can't
"depend on" the tristate config option.

Report by DaveM:

  I give it 'y' just to make it happen, for both, and afterways no
  matter how many times I rerun "make oldconfig" I keep seeing things
  like this in my build:

scripts/kconfig/conf --silentoldconfig Kconfig
include/config/auto.conf:986:warning: symbol value 'm' invalid for BT_SCO
include/config/auto.conf:3156:warning: symbol value 'm' invalid for BT_L2CAP

Reported-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Signed-off-by: Gustavo F. Padovan <redacted>
---
 net/bluetooth/Kconfig |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig
index c6f9c2f..6ae5ec5 100644
--- a/net/bluetooth/Kconfig
+++ b/net/bluetooth/Kconfig

@@ -31,9 +31,10 @@ menuconfig BT

         to Bluetooth kernel modules are provided in the BlueZ packages.  For
         more information, see <http://www.bluez.org/>.

+if BT != n
+
 config BT_L2CAP
       bool "L2CAP protocol support"
-       depends on BT
       select CRC16
       help
         L2CAP (Logical Link Control and Adaptation Protocol) provides

@@ -42,11 +43,12 @@ config BT_L2CAP

 config BT_SCO
       bool "SCO links support"
-       depends on BT
       help
         SCO link provides voice transport over Bluetooth.  SCO support is
         required for voice applications like Headset and Audio.

+endif
+

Ugh, isn't it far cleaner to change initial dependencies to "depends
on BT != n" ?

I just followed the same approach as net/ipv6/Kconfig and
net/mac80211/Kconfig. 

Dave, how do you prefer this?

-- 
Gustavo F. Padovan
http://profusion.mobi

From: "Gustavo F. Padovan" <redacted>
Date: Fri, 25 Feb 2011 22:41:25 -0300

If we want something "bool" built-in in something "tristate" it can't
"depend on" the tristate config option.

Report by DaveM:

   I give it 'y' just to make it happen, for both, and afterways no
   matter how many times I rerun "make oldconfig" I keep seeing things
   like this in my build:

scripts/kconfig/conf --silentoldconfig Kconfig
include/config/auto.conf:986:warning: symbol value 'm' invalid for BT_SCO
include/config/auto.conf:3156:warning: symbol value 'm' invalid for BT_L2CAP

Reported-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Signed-off-by: Gustavo F. Padovan <redacted>

I think this approach is fine since it mirrors what we use in other similar
situations.

I am assuming this patch will propagate via bluetooth --> wireless --> me.

Thanks.

On Wed, Mar 02, 2011 at 09:54:33PM -0800, David Miller wrote:

From: "Gustavo F. Padovan" <redacted>
Date: Fri, 25 Feb 2011 22:41:25 -0300

quoted

If we want something "bool" built-in in something "tristate" it can't
"depend on" the tristate config option.

Report by DaveM:

   I give it 'y' just to make it happen, for both, and afterways no
   matter how many times I rerun "make oldconfig" I keep seeing things
   like this in my build:

scripts/kconfig/conf --silentoldconfig Kconfig
include/config/auto.conf:986:warning: symbol value 'm' invalid for BT_SCO
include/config/auto.conf:3156:warning: symbol value 'm' invalid for BT_L2CAP

Reported-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Signed-off-by: Gustavo F. Padovan <redacted>

I think this approach is fine since it mirrors what we use in other similar
situations.

I am assuming this patch will propagate via bluetooth --> wireless --> me.

Yes, I have it queued.

-- 
John W. Linville		Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org			might be all we have.  Be ready.