All of lore.kernel.org
 help / color / mirror / Atom feed
* pull request: wireless-next-2.6 2009-06-04
@ 2009-06-04 15:20 John W. Linville
  2009-06-07 10:37 ` David Miller
  0 siblings, 1 reply; 20+ messages in thread
From: John W. Linville @ 2009-06-04 15:20 UTC (permalink / raw)
  To: davem; +Cc: linux-wireless, netdev

Dave,

Hopefully this is (almost?) the last wireless pull request for
non-bugfix patches intended for 2.6.31...

Included are the usual round of driver updates, mac80211 updates, etc.
Also included is the long-awaited and slightly controversial rfkill
rewrite.  The userland guys (i.e. Dan and Marcel) are happy with it,
and it can clean-up a lot of driver code for wireless.  Henrique has
some lingering concerns about some corner cases for platform drivers,
but I think they are relatively minor and will be resolved amicably
soon.

Please let me know if there are problems!

Thanks,

John

---

Individual patches are available here:

	http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6/

---

The following changes since commit 047584ce94108012288554a5f84585d792cc7f8f:
  Haiying Wang (1):
        net/ucc_geth: Add SGMII support for UEC GETH driver

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master

Abhijeet Kolekar (2):
      iwl3945: port allow skb allocation in tasklet patch
      iwl3945/iwlwifi: fix led bug when SW rfkill

Bing Zhao (1):
      libertas: improve function init/shutdown handling for SD8688

Bob Copeland (3):
      ath5k: remove conf->beacon_int usage
      nl80211: use GFP_ATOMIC for michael mic failure message
      ath5k: disable beacon interrupt when interface is down

Christian Lamparter (11):
      ar9170: fix beacon plcp settings
      ar9170: update hardware definitions
      ar9170: 40mhz fixes
      ar9170: introduce functions for MAC programming
      ar9170: use bitop macros for tx filter flags
      ar9170: kill duplicated HT feature flag
      ar9170: fix LED power state handling
      ar9170: fix lockdep warning on hibernate
      ar9170usb: more minor fixes
      ar9170: cancel led worker properly on exit
      ar9170: remove deprecated code

Cliff Cai (1):
      wireless: libertas: fix unaligned accesses

Dan Williams (5):
      libertas: simplify and clean up association/start/join setup
      libertas: restyle Marvell & IEEE TLV structure names
      libertas: convert CMD_802_11_AUTHENTICATE to a direct command
      libertas: convert CMD_802_11_ASSOCIATE to a direct command
      libertas: fix WPA adhoc network creation

Ivo van Doorn (2):
      rt2x00: Add new rt2800usb USB ID's
      rt2x00: Remove last usage of beacon_int from ieee80211_config

Jeff Hansen (3):
      ath9k: Reset SC_OP_TSF_RESET flag after stuck beacon
      ath9k: Combine legacy and 11n rc statistics
      ath9k: Add "debug" file to debugfs

Johannes Berg (18):
      mac80211: deprecate conf.beacon_int properly
      cfg80211: validate AID of stations being added
      nl80211: bounce scan request back to userspace
      cfg80211: use key size constants
      mac80211: fix transposed min/max CW values
      cfg80211: disallow interfering with stations on non-AP (part 2)
      net: introduce pre-up netdev notifier
      mac80211_hwsim: remove deprecated radio_enabled
      rfkill: rewrite
      rfkill: create useful userspace interface
      cfg80211: move txpower wext from mac80211
      rfkill: add function to query state
      cfg80211: add rfkill support
      iwm: port to new cfg80211 rfkill
      rfkill: always init poll delayed work
      rfkill: document /dev/rfkill
      cfg80211: fix Kconfig for users of cfg80211
      wimax: depend on rfkill properly

John W. Linville (1):
      ath5k: avoid leaking mutex in ath5k_config

Jouni Malinen (1):
      ath9k: Add sanity check for beacon_int in adhoc/mesh case

Luis R. Rodriguez (8):
      mac80211: handle -EALREADY on cfg80211 op assoc req
      ar9170: add support for 1-stage firmware
      ar9170: add AVM FRITZ devices
      cfg80211: fix for duplicate userspace replies
      ath: make regulatory parsing more verbose on debug
      cfg80211: make ieee80211_get_mesh_hdrlen() static
      mac80211: extend sta kdoc - explain when they are added
      mac80211: removed unused variable in ieee80211_tx()

Mohamed Abbas (1):
      iwlagn: delay ict interrupt.

Rami Rosen (1):
      iwlwifi: avoid build warning in iwl-core.

Randy Dunlap (1):
      iwmc3200wifi: fix printk format

Reinette Chatre (3):
      iwlwifi: fix merge error
      iwlwifi: fix otp access init
      iwlwifi: fix comment describing disable_11n

Samuel Ortiz (3):
      iwmc3200wifi: fix fragmentation threshold setting
      iwmc3200wifi: shrink calibration lmac name
      wireless/p54: prepare for FIRMWARE_NAME_MAX removal

Sebastian Andrzej Siewior (1):
      net/libertas: make SPI interface big endian aware

Tomas Winkler (1):
      iwlwifi: unify station management

Vasanthakumar Thiagarajan (1):
      ath9k: Fix write callback of 'debug' which configures debug mask

Wey-Yi Guy (1):
      iwlwifi: add value and range define for link quality command

 Documentation/feature-removal-schedule.txt   |    7 +
 Documentation/rfkill.txt                     |  603 ++-----------
 MAINTAINERS                                  |    6 +-
 arch/arm/mach-pxa/tosa-bt.c                  |   30 +-
 arch/arm/mach-pxa/tosa.c                     |    1 -
 drivers/net/usb/hso.c                        |   42 +-
 drivers/net/wireless/Kconfig                 |    2 +-
 drivers/net/wireless/ath/ar9170/ar9170.h     |   10 +-
 drivers/net/wireless/ath/ar9170/hw.h         |    5 +-
 drivers/net/wireless/ath/ar9170/led.c        |   17 +-
 drivers/net/wireless/ath/ar9170/mac.c        |   55 ++-
 drivers/net/wireless/ath/ar9170/main.c       |   98 +-
 drivers/net/wireless/ath/ar9170/phy.c        |    6 +-
 drivers/net/wireless/ath/ar9170/usb.c        |   69 +-
 drivers/net/wireless/ath/ar9170/usb.h        |    2 +
 drivers/net/wireless/ath/ath5k/base.c        |   24 +-
 drivers/net/wireless/ath/ath9k/ath9k.h       |    7 +-
 drivers/net/wireless/ath/ath9k/beacon.c      |    9 +
 drivers/net/wireless/ath/ath9k/debug.c       |  155 ++--
 drivers/net/wireless/ath/ath9k/debug.h       |   10 +-
 drivers/net/wireless/ath/ath9k/main.c        |  115 +--
 drivers/net/wireless/ath/ath9k/pci.c         |   15 -
 drivers/net/wireless/ath/regd.c              |   29 +-
 drivers/net/wireless/b43/Kconfig             |    2 +-
 drivers/net/wireless/b43/leds.c              |    2 +-
 drivers/net/wireless/b43/main.c              |    4 +-
 drivers/net/wireless/b43/phy_a.c             |    4 +-
 drivers/net/wireless/b43/phy_common.c        |   17 +-
 drivers/net/wireless/b43/phy_common.h        |    4 +-
 drivers/net/wireless/b43/phy_g.c             |    4 +-
 drivers/net/wireless/b43/phy_lp.c            |    2 +-
 drivers/net/wireless/b43/phy_n.c             |    2 +-
 drivers/net/wireless/b43/rfkill.c            |  123 +--
 drivers/net/wireless/b43/rfkill.h            |    5 +-
 drivers/net/wireless/b43legacy/Kconfig       |    2 +-
 drivers/net/wireless/b43legacy/leds.c        |    3 +-
 drivers/net/wireless/b43legacy/rfkill.c      |  123 +--
 drivers/net/wireless/b43legacy/rfkill.h      |    6 +-
 drivers/net/wireless/iwlwifi/Kconfig         |    5 +-
 drivers/net/wireless/iwlwifi/iwl-3945-led.c  |    4 -
 drivers/net/wireless/iwlwifi/iwl-3945-rs.c   |    9 +-
 drivers/net/wireless/iwlwifi/iwl-3945.c      |   73 +--
 drivers/net/wireless/iwlwifi/iwl-3945.h      |    6 -
 drivers/net/wireless/iwlwifi/iwl-4965.c      |    8 -
 drivers/net/wireless/iwlwifi/iwl-5000.c      |   16 +-
 drivers/net/wireless/iwlwifi/iwl-6000.c      |    1 -
 drivers/net/wireless/iwlwifi/iwl-agn-rs.c    |   22 +-
 drivers/net/wireless/iwlwifi/iwl-agn.c       |   17 +-
 drivers/net/wireless/iwlwifi/iwl-commands.h  |   14 +-
 drivers/net/wireless/iwlwifi/iwl-core.c      |   14 +-
 drivers/net/wireless/iwlwifi/iwl-core.h      |   12 +-
 drivers/net/wireless/iwlwifi/iwl-dev.h       |    9 +-
 drivers/net/wireless/iwlwifi/iwl-eeprom.c    |   12 +-
 drivers/net/wireless/iwlwifi/iwl-led.c       |    4 -
 drivers/net/wireless/iwlwifi/iwl-rfkill.c    |   69 +-
 drivers/net/wireless/iwlwifi/iwl-sta.c       |   56 +-
 drivers/net/wireless/iwlwifi/iwl-sta.h       |    7 +-
 drivers/net/wireless/iwlwifi/iwl3945-base.c  |  228 ++----
 drivers/net/wireless/iwmc3200wifi/Kconfig    |    3 +-
 drivers/net/wireless/iwmc3200wifi/Makefile   |    2 +-
 drivers/net/wireless/iwmc3200wifi/cfg80211.c |    2 +-
 drivers/net/wireless/iwmc3200wifi/fw.c       |    2 +-
 drivers/net/wireless/iwmc3200wifi/iwm.h      |    4 -
 drivers/net/wireless/iwmc3200wifi/netdev.c   |   10 -
 drivers/net/wireless/iwmc3200wifi/rfkill.c   |   88 --
 drivers/net/wireless/iwmc3200wifi/sdio.c     |    2 +-
 drivers/net/wireless/libertas/11d.c          |   26 +-
 drivers/net/wireless/libertas/11d.h          |   29 +-
 drivers/net/wireless/libertas/assoc.c        |  758 ++++++++--------
 drivers/net/wireless/libertas/assoc.h        |   13 -
 drivers/net/wireless/libertas/cmd.c          |   16 +-
 drivers/net/wireless/libertas/cmdresp.c      |   17 +-
 drivers/net/wireless/libertas/debugfs.c      |    8 +-
 drivers/net/wireless/libertas/dev.h          |   10 +-
 drivers/net/wireless/libertas/hostcmd.h      |   41 +-
 drivers/net/wireless/libertas/if_sdio.c      |   76 +-
 drivers/net/wireless/libertas/if_spi.c       |   34 +-
 drivers/net/wireless/libertas/main.c         |   20 -
 drivers/net/wireless/libertas/scan.c         |   63 +-
 drivers/net/wireless/libertas/types.h        |  150 ++--
 drivers/net/wireless/mac80211_hwsim.c        |   27 +-
 drivers/net/wireless/p54/p54usb.c            |    4 +-
 drivers/net/wireless/rt2x00/rt2400pci.c      |    2 +-
 drivers/net/wireless/rt2x00/rt2500pci.c      |    2 +-
 drivers/net/wireless/rt2x00/rt2500usb.c      |    2 +-
 drivers/net/wireless/rt2x00/rt2800usb.c      |   12 +
 drivers/net/wireless/rt2x00/rt2x00.h         |    5 +
 drivers/net/wireless/rt2x00/rt2x00config.c   |    3 +
 drivers/net/wireless/rt2x00/rt61pci.c        |    2 +-
 drivers/net/wireless/rt2x00/rt73usb.c        |    2 +-
 drivers/platform/x86/Kconfig                 |   14 +-
 drivers/platform/x86/acer-wmi.c              |   50 +-
 drivers/platform/x86/dell-laptop.c           |  101 +--
 drivers/platform/x86/eeepc-laptop.c          |   99 +--
 drivers/platform/x86/hp-wmi.c                |  103 ++--
 drivers/platform/x86/sony-laptop.c           |  191 ++---
 drivers/platform/x86/thinkpad_acpi.c         |  873 ++++++++++---------
 drivers/platform/x86/toshiba_acpi.c          |  159 +---
 include/asm-generic/errno.h                  |    2 +
 include/linux/Kbuild                         |    1 +
 include/linux/ieee80211.h                    |    1 +
 include/linux/notifier.h                     |    1 +
 include/linux/rfkill.h                       |  381 +++++++--
 include/net/cfg80211.h                       |   51 ++
 include/net/mac80211.h                       |   26 +-
 include/net/wimax.h                          |    8 +-
 net/core/dev.c                               |    7 +-
 net/mac80211/Kconfig                         |    5 +-
 net/mac80211/cfg.c                           |   65 ++-
 net/mac80211/driver-ops.h                    |    7 +
 net/mac80211/iface.c                         |    4 +-
 net/mac80211/main.c                          |   12 +-
 net/mac80211/sta_info.c                      |    9 +
 net/mac80211/tx.c                            |    2 -
 net/mac80211/util.c                          |   10 +-
 net/mac80211/wext.c                          |   80 +--
 net/rfkill/Kconfig                           |   21 +-
 net/rfkill/Makefile                          |    5 +-
 net/rfkill/core.c                            | 1228 ++++++++++++++++++++++++++
 net/rfkill/input.c                           |  342 +++++++
 net/rfkill/rfkill-input.c                    |  390 --------
 net/rfkill/rfkill.c                          |  855 ------------------
 net/rfkill/{rfkill-input.h => rfkill.h}      |   10 +-
 net/wimax/Kconfig                            |   15 +-
 net/wimax/op-rfkill.c                        |  123 +--
 net/wireless/Kconfig                         |    3 +-
 net/wireless/core.c                          |   97 ++-
 net/wireless/core.h                          |    7 +
 net/wireless/nl80211.c                       |   57 +-
 net/wireless/reg.c                           |    8 +-
 net/wireless/scan.c                          |    3 +-
 net/wireless/util.c                          |   13 +-
 net/wireless/wext-compat.c                   |   83 ++
 133 files changed, 4465 insertions(+), 4698 deletions(-)
 delete mode 100644 drivers/net/wireless/iwmc3200wifi/rfkill.c
 create mode 100644 net/rfkill/core.c
 create mode 100644 net/rfkill/input.c
 delete mode 100644 net/rfkill/rfkill-input.c
 delete mode 100644 net/rfkill/rfkill.c
 rename net/rfkill/{rfkill-input.h => rfkill.h} (60%)

Omnibus patch is available here:

	http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2009-06-04.patch.bz2

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: pull request: wireless-next-2.6 2009-06-04
  2009-06-04 15:20 pull request: wireless-next-2.6 2009-06-04 John W. Linville
@ 2009-06-07 10:37 ` David Miller
  2009-06-07 14:18   ` Oliver Hartkopp
  0 siblings, 1 reply; 20+ messages in thread
From: David Miller @ 2009-06-07 10:37 UTC (permalink / raw)
  To: linville; +Cc: linux-wireless, netdev

From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 4 Jun 2009 11:20:11 -0400

> Hopefully this is (almost?) the last wireless pull request for
> non-bugfix patches intended for 2.6.31...
> 
> Included are the usual round of driver updates, mac80211 updates, etc.
> Also included is the long-awaited and slightly controversial rfkill
> rewrite.  The userland guys (i.e. Dan and Marcel) are happy with it,
> and it can clean-up a lot of driver code for wireless.  Henrique has
> some lingering concerns about some corner cases for platform drivers,
> but I think they are relatively minor and will be resolved amicably
> soon.
> 
> Please let me know if there are problems!

Pulled into net-next-2.6 and I'll push it back out to kernel.org
after some build testing.

Thanks!

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: pull request: wireless-next-2.6 2009-06-04
  2009-06-07 10:37 ` David Miller
@ 2009-06-07 14:18   ` Oliver Hartkopp
  2009-06-07 14:58     ` John W. Linville
  0 siblings, 1 reply; 20+ messages in thread
From: Oliver Hartkopp @ 2009-06-07 14:18 UTC (permalink / raw)
  To: linville; +Cc: David Miller, linux-wireless, netdev

David Miller wrote:
> From: "John W. Linville" <linville@tuxdriver.com>
> Date: Thu, 4 Jun 2009 11:20:11 -0400
> 
>> Hopefully this is (almost?) the last wireless pull request for
>> non-bugfix patches intended for 2.6.31...
>>

(..)

>>
>> Please let me know if there are problems!
> 
> Pulled into net-next-2.6 and I'll push it back out to kernel.org
> after some build testing.

Hi John,

after pulling the latest net-next-2.6 i got this warning which is probably
caused by CONFIG_RFKILL=m in my config:

hartko@vwagwolkf320:~/net-next-2.6$ make oldconfig
scripts/kconfig/conf -o arch/x86/Kconfig
.config:614:warning: symbol value 'm' invalid for RFKILL_INPUT
*
* Restart config...
*
*
* RF switch subsystem support
*
RF switch subsystem support (RFKILL) [M/n/y/?] m
  RF switch input support (RFKILL_INPUT) [Y/n] (NEW)
#
# configuration written to .config
#
hartko@vwagwolkf320:~/net-next-2.6$ make -j2
scripts/kconfig/conf -s arch/x86/Kconfig
include/config/auto.conf:578:warning: symbol value 'm' invalid for RFKILL_INPUT
  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  UPD     include/linux/utsrelease.h
...

Regards,
Oliver


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: pull request: wireless-next-2.6 2009-06-04
  2009-06-07 14:18   ` Oliver Hartkopp
@ 2009-06-07 14:58     ` John W. Linville
  2009-06-07 15:04         ` Oliver Hartkopp
  2009-06-07 15:11         ` Oliver Hartkopp
  0 siblings, 2 replies; 20+ messages in thread
From: John W. Linville @ 2009-06-07 14:58 UTC (permalink / raw)
  To: Oliver Hartkopp; +Cc: David Miller, linux-wireless, netdev

On Sun, Jun 07, 2009 at 04:18:41PM +0200, Oliver Hartkopp wrote:
> David Miller wrote:
> > From: "John W. Linville" <linville@tuxdriver.com>
> > Date: Thu, 4 Jun 2009 11:20:11 -0400
> > 
> >> Hopefully this is (almost?) the last wireless pull request for
> >> non-bugfix patches intended for 2.6.31...
> >>
> 
> (..)
> 
> >>
> >> Please let me know if there are problems!
> > 
> > Pulled into net-next-2.6 and I'll push it back out to kernel.org
> > after some build testing.
> 
> Hi John,
> 
> after pulling the latest net-next-2.6 i got this warning which is probably
> caused by CONFIG_RFKILL=m in my config:
> 
> hartko@vwagwolkf320:~/net-next-2.6$ make oldconfig
> scripts/kconfig/conf -o arch/x86/Kconfig
> .config:614:warning: symbol value 'm' invalid for RFKILL_INPUT

That functionality is no longer available as a module.  If you need
it, then select Y.

Hth!

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: pull request: wireless-next-2.6 2009-06-04
@ 2009-06-07 15:04         ` Oliver Hartkopp
  0 siblings, 0 replies; 20+ messages in thread
From: Oliver Hartkopp @ 2009-06-07 15:04 UTC (permalink / raw)
  To: John W. Linville; +Cc: David Miller, linux-wireless, netdev

John W. Linville wrote:
> On Sun, Jun 07, 2009 at 04:18:41PM +0200, Oliver Hartkopp wrote:
>> scripts/kconfig/conf -o arch/x86/Kconfig
>> .config:614:warning: symbol value 'm' invalid for RFKILL_INPUT
> 
> That functionality is no longer available as a module.  If you need
> it, then select Y.
> 
> Hth!

It does! Thanks for the clarification. I'll select CONFIG_RFKILL=y now.

Oliver


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: pull request: wireless-next-2.6 2009-06-04
@ 2009-06-07 15:04         ` Oliver Hartkopp
  0 siblings, 0 replies; 20+ messages in thread
From: Oliver Hartkopp @ 2009-06-07 15:04 UTC (permalink / raw)
  To: John W. Linville
  Cc: David Miller, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA

John W. Linville wrote:
> On Sun, Jun 07, 2009 at 04:18:41PM +0200, Oliver Hartkopp wrote:
>> scripts/kconfig/conf -o arch/x86/Kconfig
>> .config:614:warning: symbol value 'm' invalid for RFKILL_INPUT
> 
> That functionality is no longer available as a module.  If you need
> it, then select Y.
> 
> Hth!

It does! Thanks for the clarification. I'll select CONFIG_RFKILL=y now.

Oliver

--
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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: pull request: wireless-next-2.6 2009-06-04
@ 2009-06-07 15:11         ` Oliver Hartkopp
  0 siblings, 0 replies; 20+ messages in thread
From: Oliver Hartkopp @ 2009-06-07 15:11 UTC (permalink / raw)
  To: John W. Linville; +Cc: David Miller, linux-wireless, netdev

John W. Linville wrote:
> On Sun, Jun 07, 2009 at 04:18:41PM +0200, Oliver Hartkopp wrote:
>> David Miller wrote:
>>> From: "John W. Linville" <linville@tuxdriver.com>
>>> Date: Thu, 4 Jun 2009 11:20:11 -0400
>>>
>>>> Hopefully this is (almost?) the last wireless pull request for
>>>> non-bugfix patches intended for 2.6.31...
>>>>
>> (..)
>>
>>>> Please let me know if there are problems!
>>> Pulled into net-next-2.6 and I'll push it back out to kernel.org
>>> after some build testing.
>> Hi John,
>>
>> after pulling the latest net-next-2.6 i got this warning which is probably
>> caused by CONFIG_RFKILL=m in my config:
>>
>> hartko@vwagwolkf320:~/net-next-2.6$ make oldconfig
>> scripts/kconfig/conf -o arch/x86/Kconfig
>> .config:614:warning: symbol value 'm' invalid for RFKILL_INPUT
> 
> That functionality is no longer available as a module.  If you need
> it, then select Y.

Just some additional nitpicking:

You should update net/rfkill/Kconfig as it still allows a tristate selection
for RFKILL and the comment "To compile this driver as a module ..." should be
removed also.

Regards,
Oliver


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: pull request: wireless-next-2.6 2009-06-04
@ 2009-06-07 15:11         ` Oliver Hartkopp
  0 siblings, 0 replies; 20+ messages in thread
From: Oliver Hartkopp @ 2009-06-07 15:11 UTC (permalink / raw)
  To: John W. Linville
  Cc: David Miller, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA

John W. Linville wrote:
> On Sun, Jun 07, 2009 at 04:18:41PM +0200, Oliver Hartkopp wrote:
>> David Miller wrote:
>>> From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
>>> Date: Thu, 4 Jun 2009 11:20:11 -0400
>>>
>>>> Hopefully this is (almost?) the last wireless pull request for
>>>> non-bugfix patches intended for 2.6.31...
>>>>
>> (..)
>>
>>>> Please let me know if there are problems!
>>> Pulled into net-next-2.6 and I'll push it back out to kernel.org
>>> after some build testing.
>> Hi John,
>>
>> after pulling the latest net-next-2.6 i got this warning which is probably
>> caused by CONFIG_RFKILL=m in my config:
>>
>> hartko@vwagwolkf320:~/net-next-2.6$ make oldconfig
>> scripts/kconfig/conf -o arch/x86/Kconfig
>> .config:614:warning: symbol value 'm' invalid for RFKILL_INPUT
> 
> That functionality is no longer available as a module.  If you need
> it, then select Y.

Just some additional nitpicking:

You should update net/rfkill/Kconfig as it still allows a tristate selection
for RFKILL and the comment "To compile this driver as a module ..." should be
removed also.

Regards,
Oliver

--
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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: pull request: wireless-next-2.6 2009-06-04
  2009-06-07 15:11         ` Oliver Hartkopp
  (?)
@ 2009-06-07 15:26         ` John W. Linville
  -1 siblings, 0 replies; 20+ messages in thread
From: John W. Linville @ 2009-06-07 15:26 UTC (permalink / raw)
  To: Oliver Hartkopp; +Cc: David Miller, linux-wireless, netdev

On Sun, Jun 07, 2009 at 05:11:33PM +0200, Oliver Hartkopp wrote:
> John W. Linville wrote:
> > On Sun, Jun 07, 2009 at 04:18:41PM +0200, Oliver Hartkopp wrote:
> >> David Miller wrote:
> >>> From: "John W. Linville" <linville@tuxdriver.com>
> >>> Date: Thu, 4 Jun 2009 11:20:11 -0400
> >>>
> >>>> Hopefully this is (almost?) the last wireless pull request for
> >>>> non-bugfix patches intended for 2.6.31...
> >>>>
> >> (..)
> >>
> >>>> Please let me know if there are problems!
> >>> Pulled into net-next-2.6 and I'll push it back out to kernel.org
> >>> after some build testing.
> >> Hi John,
> >>
> >> after pulling the latest net-next-2.6 i got this warning which is probably
> >> caused by CONFIG_RFKILL=m in my config:
> >>
> >> hartko@vwagwolkf320:~/net-next-2.6$ make oldconfig
> >> scripts/kconfig/conf -o arch/x86/Kconfig
> >> .config:614:warning: symbol value 'm' invalid for RFKILL_INPUT
> > 
> > That functionality is no longer available as a module.  If you need
> > it, then select Y.
> 
> Just some additional nitpicking:
> 
> You should update net/rfkill/Kconfig as it still allows a tristate selection
> for RFKILL and the comment "To compile this driver as a module ..." should be
> removed also.

RFKILL and RFKILL_INPUT are different things... :-)

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: pull request: wireless-next-2.6 2009-06-04
@ 2009-06-07 15:29           ` Marcel Holtmann
  0 siblings, 0 replies; 20+ messages in thread
From: Marcel Holtmann @ 2009-06-07 15:29 UTC (permalink / raw)
  To: Oliver Hartkopp; +Cc: John W. Linville, David Miller, linux-wireless, netdev

Hi Oliver,

> >>>> Hopefully this is (almost?) the last wireless pull request for
> >>>> non-bugfix patches intended for 2.6.31...
> >>>>
> >> (..)
> >>
> >>>> Please let me know if there are problems!
> >>> Pulled into net-next-2.6 and I'll push it back out to kernel.org
> >>> after some build testing.
> >> Hi John,
> >>
> >> after pulling the latest net-next-2.6 i got this warning which is probably
> >> caused by CONFIG_RFKILL=m in my config:
> >>
> >> hartko@vwagwolkf320:~/net-next-2.6$ make oldconfig
> >> scripts/kconfig/conf -o arch/x86/Kconfig
> >> .config:614:warning: symbol value 'm' invalid for RFKILL_INPUT
> > 
> > That functionality is no longer available as a module.  If you need
> > it, then select Y.
> 
> Just some additional nitpicking:
> 
> You should update net/rfkill/Kconfig as it still allows a tristate selection
> for RFKILL and the comment "To compile this driver as a module ..." should be
> removed also.

compiling RFKILL itself as a module is still working perfectly fine. It
is just the RFKILL_INPUT that can't be built as a module anymore. That
part was pointless anyway. And in the future RFKILL_INPUT will go away
and be replaced by a userspace implementation with proper support for
platform specific policies.

Regards

Marcel



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: pull request: wireless-next-2.6 2009-06-04
@ 2009-06-07 15:29           ` Marcel Holtmann
  0 siblings, 0 replies; 20+ messages in thread
From: Marcel Holtmann @ 2009-06-07 15:29 UTC (permalink / raw)
  To: Oliver Hartkopp
  Cc: John W. Linville, David Miller,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA

Hi Oliver,

> >>>> Hopefully this is (almost?) the last wireless pull request for
> >>>> non-bugfix patches intended for 2.6.31...
> >>>>
> >> (..)
> >>
> >>>> Please let me know if there are problems!
> >>> Pulled into net-next-2.6 and I'll push it back out to kernel.org
> >>> after some build testing.
> >> Hi John,
> >>
> >> after pulling the latest net-next-2.6 i got this warning which is probably
> >> caused by CONFIG_RFKILL=m in my config:
> >>
> >> hartko@vwagwolkf320:~/net-next-2.6$ make oldconfig
> >> scripts/kconfig/conf -o arch/x86/Kconfig
> >> .config:614:warning: symbol value 'm' invalid for RFKILL_INPUT
> > 
> > That functionality is no longer available as a module.  If you need
> > it, then select Y.
> 
> Just some additional nitpicking:
> 
> You should update net/rfkill/Kconfig as it still allows a tristate selection
> for RFKILL and the comment "To compile this driver as a module ..." should be
> removed also.

compiling RFKILL itself as a module is still working perfectly fine. It
is just the RFKILL_INPUT that can't be built as a module anymore. That
part was pointless anyway. And in the future RFKILL_INPUT will go away
and be replaced by a userspace implementation with proper support for
platform specific policies.

Regards

Marcel


--
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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* rfkill regression in net-next-2.6
@ 2009-06-14  8:54             ` Oliver Hartkopp
  0 siblings, 0 replies; 20+ messages in thread
From: Oliver Hartkopp @ 2009-06-14  8:54 UTC (permalink / raw)
  To: Marcel Holtmann, John W. Linville; +Cc: David Miller, linux-wireless, netdev

Marcel Holtmann wrote:

> 
> compiling RFKILL itself as a module is still working perfectly fine. It
> is just the RFKILL_INPUT that can't be built as a module anymore. That
> part was pointless anyway. And in the future RFKILL_INPUT will go away
> and be replaced by a userspace implementation with proper support for
> platform specific policies.

Hi all,

i have a Dell Lattitude 830 with Bluetooh and b43 WLAN and my RFKILL-switch is
set to ON.

On power on the BT LED is on and when booting with 2.6.30 or with 2.6.30-git5
the WLAN LED becomes illuminated within the boot process after b43 pulled his
firmware.

With net-next-2.6 the BT LED is switched OFF(!) during the boot process and
the Kernel log says:

[   15.276568] b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
[   15.423540] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
[   15.545096] b43-phy0 debug: Chip initialized
[   15.545317] b43-phy0 debug: 32-bit DMA initialized
[   15.566383] b43-phy0 debug: Wireless interface started
[   15.566394] b43-phy0 debug: Adding Interface type 2
[   15.566670] b43-phy0: Radio hardware status changed to DISABLED
[   15.633069] b43-phy0: Radio turned on by software
[   15.647094] b43-phy0: The hardware RF-kill button still turns the radio
physically off. Press the button to turn it on.
[   15.673598] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   15.721053] b43-phy0 debug: Removing Interface type 2
[   15.733877] b43-phy0 debug: Wireless interface stopped

The WLAN LED is never illuminated with net-next-2.6.

The BT LED is switched off something around this time in the log:

[    7.639047] NET: Registered protocol family 31
[    7.651562] Bluetooth: HCI device and connection manager initialized
[    7.664155] Bluetooth: HCI socket layer initialized
[    7.756113] b43-pci-bridge 0000:0c:00.0: PCI INT A -> GSI 17 (level, low)
-> IRQ 17
[    7.769117] b43-pci-bridge 0000:0c:00.0: setting latency timer to 64
[    7.828160] yenta_cardbus 0000:03:01.0: CardBus bridge found [1028:01fe]
[    7.841107] yenta_cardbus 0000:03:01.0: O2: res at 0x94/0xD4: 00/ea
[    7.853830] yenta_cardbus 0000:03:01.0: O2: enabling read prefetch/write burst
[    7.867428] i801_smbus 0000:00:1f.3: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[    7.881369] ssb: Sonics Silicon Backplane found on PCI device 0000:0c:00.0
[    7.897694] Bluetooth: Generic Bluetooth USB driver ver 0.5
[    7.910910] usbcore: registered new interface driver btusb


When i see the BT LED switching to off, i can manually switch the RFKILL
switch to OFF and ON, and then both LEDs get illuminated and WLAN is
successfully initialized by the boot process.

As we discussed about RFKILL and modules, i set CONFIG_RFKILL=y in my
net-netx-2.6 tree with no change of the behaviour.

Any idea what changed in net-next-2.6 that could produce this behaviour?

Regards,
Oliver


^ permalink raw reply	[flat|nested] 20+ messages in thread

* rfkill regression in net-next-2.6
@ 2009-06-14  8:54             ` Oliver Hartkopp
  0 siblings, 0 replies; 20+ messages in thread
From: Oliver Hartkopp @ 2009-06-14  8:54 UTC (permalink / raw)
  To: Marcel Holtmann, John W. Linville
  Cc: David Miller, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA

Marcel Holtmann wrote:

> 
> compiling RFKILL itself as a module is still working perfectly fine. It
> is just the RFKILL_INPUT that can't be built as a module anymore. That
> part was pointless anyway. And in the future RFKILL_INPUT will go away
> and be replaced by a userspace implementation with proper support for
> platform specific policies.

Hi all,

i have a Dell Lattitude 830 with Bluetooh and b43 WLAN and my RFKILL-switch is
set to ON.

On power on the BT LED is on and when booting with 2.6.30 or with 2.6.30-git5
the WLAN LED becomes illuminated within the boot process after b43 pulled his
firmware.

With net-next-2.6 the BT LED is switched OFF(!) during the boot process and
the Kernel log says:

[   15.276568] b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
[   15.423540] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
[   15.545096] b43-phy0 debug: Chip initialized
[   15.545317] b43-phy0 debug: 32-bit DMA initialized
[   15.566383] b43-phy0 debug: Wireless interface started
[   15.566394] b43-phy0 debug: Adding Interface type 2
[   15.566670] b43-phy0: Radio hardware status changed to DISABLED
[   15.633069] b43-phy0: Radio turned on by software
[   15.647094] b43-phy0: The hardware RF-kill button still turns the radio
physically off. Press the button to turn it on.
[   15.673598] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   15.721053] b43-phy0 debug: Removing Interface type 2
[   15.733877] b43-phy0 debug: Wireless interface stopped

The WLAN LED is never illuminated with net-next-2.6.

The BT LED is switched off something around this time in the log:

[    7.639047] NET: Registered protocol family 31
[    7.651562] Bluetooth: HCI device and connection manager initialized
[    7.664155] Bluetooth: HCI socket layer initialized
[    7.756113] b43-pci-bridge 0000:0c:00.0: PCI INT A -> GSI 17 (level, low)
-> IRQ 17
[    7.769117] b43-pci-bridge 0000:0c:00.0: setting latency timer to 64
[    7.828160] yenta_cardbus 0000:03:01.0: CardBus bridge found [1028:01fe]
[    7.841107] yenta_cardbus 0000:03:01.0: O2: res at 0x94/0xD4: 00/ea
[    7.853830] yenta_cardbus 0000:03:01.0: O2: enabling read prefetch/write burst
[    7.867428] i801_smbus 0000:00:1f.3: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[    7.881369] ssb: Sonics Silicon Backplane found on PCI device 0000:0c:00.0
[    7.897694] Bluetooth: Generic Bluetooth USB driver ver 0.5
[    7.910910] usbcore: registered new interface driver btusb


When i see the BT LED switching to off, i can manually switch the RFKILL
switch to OFF and ON, and then both LEDs get illuminated and WLAN is
successfully initialized by the boot process.

As we discussed about RFKILL and modules, i set CONFIG_RFKILL=y in my
net-netx-2.6 tree with no change of the behaviour.

Any idea what changed in net-next-2.6 that could produce this behaviour?

Regards,
Oliver

--
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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: rfkill regression in net-next-2.6
@ 2009-06-14  9:17               ` Oliver Hartkopp
  0 siblings, 0 replies; 20+ messages in thread
From: Oliver Hartkopp @ 2009-06-14  9:17 UTC (permalink / raw)
  To: Marcel Holtmann, John W. Linville; +Cc: David Miller, linux-wireless, netdev

I missed the Dell dcdbas log output that seems to kill the LED ...
see below.

Oliver Hartkopp wrote:
> Marcel Holtmann wrote:
> 
>> compiling RFKILL itself as a module is still working perfectly fine. It
>> is just the RFKILL_INPUT that can't be built as a module anymore. That
>> part was pointless anyway. And in the future RFKILL_INPUT will go away
>> and be replaced by a userspace implementation with proper support for
>> platform specific policies.
> 
> Hi all,
> 
> i have a Dell Lattitude 830 with Bluetooh and b43 WLAN and my RFKILL-switch is
> set to ON.
> 
> On power on the BT LED is on and when booting with 2.6.30 or with 2.6.30-git5
> the WLAN LED becomes illuminated within the boot process after b43 pulled his
> firmware.
> 
> With net-next-2.6 the BT LED is switched OFF(!) during the boot process and
> the Kernel log says:
> 
> [   15.276568] b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
> [   15.423540] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
> [   15.545096] b43-phy0 debug: Chip initialized
> [   15.545317] b43-phy0 debug: 32-bit DMA initialized
> [   15.566383] b43-phy0 debug: Wireless interface started
> [   15.566394] b43-phy0 debug: Adding Interface type 2
> [   15.566670] b43-phy0: Radio hardware status changed to DISABLED
> [   15.633069] b43-phy0: Radio turned on by software
> [   15.647094] b43-phy0: The hardware RF-kill button still turns the radio
> physically off. Press the button to turn it on.
> [   15.673598] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [   15.721053] b43-phy0 debug: Removing Interface type 2
> [   15.733877] b43-phy0 debug: Wireless interface stopped
> 
> The WLAN LED is never illuminated with net-next-2.6.
> 
> The BT LED is switched off something around this time in the log:


[    4.079342] usb 7-1.2: configuration #1 chosen from 1 choice
[    6.663535] dcdbas dcdbas: Dell Systems Management Base Driver (version
5.6.0-3.2)
[    7.097116] usb 3-2: USB disconnect, address 2
[    7.623369] Bluetooth: Core ver 2.15
[    7.639047] NET: Registered protocol family 31

> 
> [    7.639047] NET: Registered protocol family 31
> [    7.651562] Bluetooth: HCI device and connection manager initialized
> [    7.664155] Bluetooth: HCI socket layer initialized
> [    7.756113] b43-pci-bridge 0000:0c:00.0: PCI INT A -> GSI 17 (level, low)
> -> IRQ 17
> [    7.769117] b43-pci-bridge 0000:0c:00.0: setting latency timer to 64
> [    7.828160] yenta_cardbus 0000:03:01.0: CardBus bridge found [1028:01fe]
> [    7.841107] yenta_cardbus 0000:03:01.0: O2: res at 0x94/0xD4: 00/ea
> [    7.853830] yenta_cardbus 0000:03:01.0: O2: enabling read prefetch/write burst
> [    7.867428] i801_smbus 0000:00:1f.3: PCI INT B -> GSI 17 (level, low) -> IRQ 17
> [    7.881369] ssb: Sonics Silicon Backplane found on PCI device 0000:0c:00.0
> [    7.897694] Bluetooth: Generic Bluetooth USB driver ver 0.5
> [    7.910910] usbcore: registered new interface driver btusb
> 
> 
> When i see the BT LED switching to off, i can manually switch the RFKILL
> switch to OFF and ON, and then both LEDs get illuminated and WLAN is
> successfully initialized by the boot process.
> 
> As we discussed about RFKILL and modules, i set CONFIG_RFKILL=y in my
> net-netx-2.6 tree with no change of the behaviour.
> 
> Any idea what changed in net-next-2.6 that could produce this behaviour?
> 
> Regards,
> Oliver

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: rfkill regression in net-next-2.6
@ 2009-06-14  9:17               ` Oliver Hartkopp
  0 siblings, 0 replies; 20+ messages in thread
From: Oliver Hartkopp @ 2009-06-14  9:17 UTC (permalink / raw)
  To: Marcel Holtmann, John W. Linville
  Cc: David Miller, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA

I missed the Dell dcdbas log output that seems to kill the LED ...
see below.

Oliver Hartkopp wrote:
> Marcel Holtmann wrote:
> 
>> compiling RFKILL itself as a module is still working perfectly fine. It
>> is just the RFKILL_INPUT that can't be built as a module anymore. That
>> part was pointless anyway. And in the future RFKILL_INPUT will go away
>> and be replaced by a userspace implementation with proper support for
>> platform specific policies.
> 
> Hi all,
> 
> i have a Dell Lattitude 830 with Bluetooh and b43 WLAN and my RFKILL-switch is
> set to ON.
> 
> On power on the BT LED is on and when booting with 2.6.30 or with 2.6.30-git5
> the WLAN LED becomes illuminated within the boot process after b43 pulled his
> firmware.
> 
> With net-next-2.6 the BT LED is switched OFF(!) during the boot process and
> the Kernel log says:
> 
> [   15.276568] b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
> [   15.423540] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
> [   15.545096] b43-phy0 debug: Chip initialized
> [   15.545317] b43-phy0 debug: 32-bit DMA initialized
> [   15.566383] b43-phy0 debug: Wireless interface started
> [   15.566394] b43-phy0 debug: Adding Interface type 2
> [   15.566670] b43-phy0: Radio hardware status changed to DISABLED
> [   15.633069] b43-phy0: Radio turned on by software
> [   15.647094] b43-phy0: The hardware RF-kill button still turns the radio
> physically off. Press the button to turn it on.
> [   15.673598] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [   15.721053] b43-phy0 debug: Removing Interface type 2
> [   15.733877] b43-phy0 debug: Wireless interface stopped
> 
> The WLAN LED is never illuminated with net-next-2.6.
> 
> The BT LED is switched off something around this time in the log:


[    4.079342] usb 7-1.2: configuration #1 chosen from 1 choice
[    6.663535] dcdbas dcdbas: Dell Systems Management Base Driver (version
5.6.0-3.2)
[    7.097116] usb 3-2: USB disconnect, address 2
[    7.623369] Bluetooth: Core ver 2.15
[    7.639047] NET: Registered protocol family 31

> 
> [    7.639047] NET: Registered protocol family 31
> [    7.651562] Bluetooth: HCI device and connection manager initialized
> [    7.664155] Bluetooth: HCI socket layer initialized
> [    7.756113] b43-pci-bridge 0000:0c:00.0: PCI INT A -> GSI 17 (level, low)
> -> IRQ 17
> [    7.769117] b43-pci-bridge 0000:0c:00.0: setting latency timer to 64
> [    7.828160] yenta_cardbus 0000:03:01.0: CardBus bridge found [1028:01fe]
> [    7.841107] yenta_cardbus 0000:03:01.0: O2: res at 0x94/0xD4: 00/ea
> [    7.853830] yenta_cardbus 0000:03:01.0: O2: enabling read prefetch/write burst
> [    7.867428] i801_smbus 0000:00:1f.3: PCI INT B -> GSI 17 (level, low) -> IRQ 17
> [    7.881369] ssb: Sonics Silicon Backplane found on PCI device 0000:0c:00.0
> [    7.897694] Bluetooth: Generic Bluetooth USB driver ver 0.5
> [    7.910910] usbcore: registered new interface driver btusb
> 
> 
> When i see the BT LED switching to off, i can manually switch the RFKILL
> switch to OFF and ON, and then both LEDs get illuminated and WLAN is
> successfully initialized by the boot process.
> 
> As we discussed about RFKILL and modules, i set CONFIG_RFKILL=y in my
> net-netx-2.6 tree with no change of the behaviour.
> 
> Any idea what changed in net-next-2.6 that could produce this behaviour?
> 
> Regards,
> Oliver
--
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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: rfkill regression in net-next-2.6
@ 2009-06-15 12:04               ` John W. Linville
  0 siblings, 0 replies; 20+ messages in thread
From: John W. Linville @ 2009-06-15 12:04 UTC (permalink / raw)
  To: Oliver Hartkopp
  Cc: Marcel Holtmann, David Miller, linux-wireless, netdev, johannes

On Sun, Jun 14, 2009 at 10:54:17AM +0200, Oliver Hartkopp wrote:

> Any idea what changed in net-next-2.6 that could produce this behaviour?

The rfkill subsystem rewrite would seem suspect... :-)

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: rfkill regression in net-next-2.6
@ 2009-06-15 12:04               ` John W. Linville
  0 siblings, 0 replies; 20+ messages in thread
From: John W. Linville @ 2009-06-15 12:04 UTC (permalink / raw)
  To: Oliver Hartkopp
  Cc: Marcel Holtmann, David Miller,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA, johannes-cdvu00un1VgdHxzADdlk8Q

On Sun, Jun 14, 2009 at 10:54:17AM +0200, Oliver Hartkopp wrote:

> Any idea what changed in net-next-2.6 that could produce this behaviour?

The rfkill subsystem rewrite would seem suspect... :-)

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: rfkill regression in net-next-2.6
@ 2009-06-15 12:24                 ` Johannes Berg
  0 siblings, 0 replies; 20+ messages in thread
From: Johannes Berg @ 2009-06-15 12:24 UTC (permalink / raw)
  To: John W. Linville
  Cc: Oliver Hartkopp, Marcel Holtmann, David Miller, linux-wireless, netdev

On Mon, 2009-06-15 at 08:04 -0400, John W. Linville wrote:
> On Sun, Jun 14, 2009 at 10:54:17AM +0200, Oliver Hartkopp wrote:
> 
> > Any idea what changed in net-next-2.6 that could produce this behaviour?
> 
> The rfkill subsystem rewrite would seem suspect... :-)

Maybe this fixes it?

johannes

--- wireless-testing.orig/drivers/platform/x86/dell-laptop.c	2009-06-15 14:23:25.000000000 +0200
+++ wireless-testing/drivers/platform/x86/dell-laptop.c	2009-06-15 14:23:35.000000000 +0200
@@ -177,7 +177,7 @@ dell_send_request(struct calling_interfa
 static int dell_rfkill_set(void *data, bool blocked)
 {
 	struct calling_interface_buffer buffer;
-	int disable = blocked ? 0 : 1;
+	int disable = blocked ? 1 : 0;
 	unsigned long radio = (unsigned long)data;
 
 	memset(&buffer, 0, sizeof(struct calling_interface_buffer));



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: rfkill regression in net-next-2.6
@ 2009-06-15 12:24                 ` Johannes Berg
  0 siblings, 0 replies; 20+ messages in thread
From: Johannes Berg @ 2009-06-15 12:24 UTC (permalink / raw)
  To: John W. Linville
  Cc: Oliver Hartkopp, Marcel Holtmann, David Miller,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA

On Mon, 2009-06-15 at 08:04 -0400, John W. Linville wrote:
> On Sun, Jun 14, 2009 at 10:54:17AM +0200, Oliver Hartkopp wrote:
> 
> > Any idea what changed in net-next-2.6 that could produce this behaviour?
> 
> The rfkill subsystem rewrite would seem suspect... :-)

Maybe this fixes it?

johannes

--- wireless-testing.orig/drivers/platform/x86/dell-laptop.c	2009-06-15 14:23:25.000000000 +0200
+++ wireless-testing/drivers/platform/x86/dell-laptop.c	2009-06-15 14:23:35.000000000 +0200
@@ -177,7 +177,7 @@ dell_send_request(struct calling_interfa
 static int dell_rfkill_set(void *data, bool blocked)
 {
 	struct calling_interface_buffer buffer;
-	int disable = blocked ? 0 : 1;
+	int disable = blocked ? 1 : 0;
 	unsigned long radio = (unsigned long)data;
 
 	memset(&buffer, 0, sizeof(struct calling_interface_buffer));


--
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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: rfkill regression in net-next-2.6
  2009-06-15 12:24                 ` Johannes Berg
  (?)
@ 2009-06-15 13:20                 ` Oliver Hartkopp
  -1 siblings, 0 replies; 20+ messages in thread
From: Oliver Hartkopp @ 2009-06-15 13:20 UTC (permalink / raw)
  To: Johannes Berg
  Cc: John W. Linville, Marcel Holtmann, David Miller, linux-wireless, netdev

Johannes Berg wrote:
> On Mon, 2009-06-15 at 08:04 -0400, John W. Linville wrote:
>> On Sun, Jun 14, 2009 at 10:54:17AM +0200, Oliver Hartkopp wrote:
>>
>>> Any idea what changed in net-next-2.6 that could produce this behaviour?
>> The rfkill subsystem rewrite would seem suspect... :-)
> 
> Maybe this fixes it?

Yes, that made it!

I booted with the RFKILL switch ON and OFF and the system and the LEDs are
working as one would expect it.

Thanks Johannes.

Tested-by: Oliver Hartkopp <oliver@hartkopp.net>


> 
> johannes
> 
> --- wireless-testing.orig/drivers/platform/x86/dell-laptop.c	2009-06-15 14:23:25.000000000 +0200
> +++ wireless-testing/drivers/platform/x86/dell-laptop.c	2009-06-15 14:23:35.000000000 +0200
> @@ -177,7 +177,7 @@ dell_send_request(struct calling_interfa
>  static int dell_rfkill_set(void *data, bool blocked)
>  {
>  	struct calling_interface_buffer buffer;
> -	int disable = blocked ? 0 : 1;
> +	int disable = blocked ? 1 : 0;
>  	unsigned long radio = (unsigned long)data;
>  
>  	memset(&buffer, 0, sizeof(struct calling_interface_buffer));
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2009-06-15 13:21 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-04 15:20 pull request: wireless-next-2.6 2009-06-04 John W. Linville
2009-06-07 10:37 ` David Miller
2009-06-07 14:18   ` Oliver Hartkopp
2009-06-07 14:58     ` John W. Linville
2009-06-07 15:04       ` Oliver Hartkopp
2009-06-07 15:04         ` Oliver Hartkopp
2009-06-07 15:11       ` Oliver Hartkopp
2009-06-07 15:11         ` Oliver Hartkopp
2009-06-07 15:26         ` John W. Linville
2009-06-07 15:29         ` Marcel Holtmann
2009-06-07 15:29           ` Marcel Holtmann
2009-06-14  8:54           ` rfkill regression in net-next-2.6 Oliver Hartkopp
2009-06-14  8:54             ` Oliver Hartkopp
2009-06-14  9:17             ` Oliver Hartkopp
2009-06-14  9:17               ` Oliver Hartkopp
2009-06-15 12:04             ` John W. Linville
2009-06-15 12:04               ` John W. Linville
2009-06-15 12:24               ` Johannes Berg
2009-06-15 12:24                 ` Johannes Berg
2009-06-15 13:20                 ` Oliver Hartkopp

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.