- 09 May, 2012 40 commits
-
-
David Herrmann authored
We initialize the "struct device" in hci_alloc_dev() for a long time now so we can access hdev->dev.parent directly. Hence, we can drop the temporary field hdev->parent which is used in no other place than hci_add_sysfs(). SET_HCIDEV_DEV() is never called after registering a device by the drivers so we do not overwrite internal device-state. Furthermore, hdev->dev is initialized to 0 by kzalloc() inside hci_alloc_dev() so the default behavior with dev.parent = NULL is kept. Signed-off-by:
David Herrmann <dh.herrmann@googlemail.com> Acked-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com>
-
Andre Guedes authored
In order to do interleaved discovery we should be in DISCOVERY_ FINDING state. Otherwise, discovery should be stopped. Signed-off-by:
Andre Guedes <andre.guedes@openbossa.org> Signed-off-by:
Gustavo F. Padovan <padovan@profusion.mobi>
-
Andrei Emeltchenko authored
chan->psm is kept in __le16 format which was not always taken into account. Fix several bugs related to extra conversion. Signed-off-by:
Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by:
-
Andrei Emeltchenko authored
Value to be converted is already in __le32 format. Signed-off-by:
-
Andrei Emeltchenko authored
Correct type warnings reported by sparse to show that this functions takes ediv argument in __le16 format. Signed-off-by:
-
Andrei Emeltchenko authored
Keep lmp_subver in host byte order. We have following conversion in hci_cc_read_local_version: hdev->lmp_subver = __le16_to_cpu(rp->lmp_subver); Signed-off-by:
-
Andrei Emeltchenko authored
Correct endian conversion reported by sparse Signed-off-by:
-
John W. Linville authored
Signed-off-by:John W. Linville <linville@tuxdriver.com>
-
Ashok Nagarajan authored
This patch introduces a new mesh configuration parameter "ht_opmode" and will allow user to check the current HT protection mode selected. Users could configure the protection mode by the command "iw mesh_iface set mesh_param mesh_ht_protection_mode=2". The default protection mode of mesh is set to non-HT mixed mode. Signed-off-by:
Ashok Nagarajan <ashok@cozybit.com> Reviewed-by:
Thomas Pedersen <thomas@cozybit.com> Signed-off-by:
-
Ashok Nagarajan authored
Now that we have protection enabled, allow non-HT and HT20 stations to peer with HT40+/- stations. Peering is still disallowed for HT40+/- mismatch. Signed-off-by:
-
Ashok Nagarajan authored
Section 9.23.3.5 of IEEE 80211s standard describes the protection rules for HT mesh STA in a MBSS. Three HT protection modes are supported for now: non-HT mixed mode - is selected if any non-HT peers are present in our MBSS. 20MHz-protection mode - is selected if all peers in our 20/40MHz MBSS support HT and atleast one HT20 peer is present. no-protection mode - is selected otherwise. This is a limited implementation of 9.23.3.5, which only considers mesh peers when determining the HT protection mode. Station's channel_type needs to be maintained. Signed-off-by:
-
Ashok Nagarajan authored
Signed-off-by:
-
Emmanuel Grumbach authored
Since the BSS table is organized in a RB tree, the BSSs need to be comparable. This means that we must define a < and > operator to the BSS object. compare_ethr_addr isn't enough since it returns only a binary value. Since Felix's cfg80211: use compare_ether_addr on MAC addresses instead of memcmp Because of the constant size and guaranteed 16 bit alignment, the inline compare_ether_addr function is much cheaper than calling memcmp. Signed-off-by:Felix Fietkau <nbd@openwrt.org> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Acked-by:
-
Franky Lin authored
Some sdio host controllers do not support real in band interrupt. Software polling mode as a replacement is not fast enough for high throughput and new features. Also some in band interrupts do not support host wake up on embedded platform even when they are real physical interrupts. Therefore out of band (oob) interrupt mechanism is implemented for these scenarios. To provide oob irq number and flags used for irq registration in brcmfmac, a platform device contains irq resource must be registered in board specific code. Here is an example of platform device structure: struct resource brcmf_sdio_res[] = { { .start = GPIO_BRCMF_SDIO_OOB_NUM, .end = GPIO_BRCMF_SDIO_OOB_NUM, .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL, } }; struct platform_device brcmf_sdio_device = { .name = "brcmf_sdio_pd", .id = -1, .num_resources = ARRAY_SIZE(brcmf_sdio_res), .resource = brcmf_sdio_res, }; Reviewed-by:pieter-paul giesberts <pieterpg@broadcom.com> Reviewed-by:
arend van spriel <arend@broadcom.com> Signed-off-by:
franky lin <frankyl@broadcom.com> Signed-off-by:
-
Franky Lin authored
For out of band interrupt which is going to be introduced shortly, the interrupt register function must be called after firmware is downloaded. This patch moves it from brcmf_sdbrcm_probe to brcmf_sdbrcm_bus_init. Reviewed-by:
-
Franky Lin authored
Bus state should be the correct flag for bus status. Use it instead of result from previous function call for backplane clock switch. Reviewed-by:
-
Franky Lin authored
brcmf_sdbrcm_isr doesn't access to the dongle through SDIO bus. Stop releasing and claiming host in irq handler to eliminate any potential risk. Reviewed-by:
-
Ben Greear authored
The signal and noise are forced to be positive since ethtool deals in unsigned 64-bit values and this number should be human readable. This gives easy access to some of the data formerly exposed in the deprecated /proc/net/wireless file. Signed-off-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
-
Ben Greear authored
This adds hooks to call into the driver to get additional stats for the ethtool API. Signed-off-by:
-
Ben Greear authored
This lets ethtool print out stats related to stations connected to the interface. Does not yet get stats from the underlying driver. Signed-off-by:
-
Ben Greear authored
Signed-off-by:
-
Wey-Yi Guy authored
"iwlwifi: use correct released ucode version" change the ucode api ok from 6000G2 to 6000G2B, but it shall belong to 6030 device series, not the 6005 device series. Fix it Cc: stable@vger.kernel.org #3.3+ Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
Meenakshi Venkataraman authored
Report correctly the latest released version of the iwlwifi firmware for all iwlwifi-supported devices. Cc: stable@vger.kernel.org #3.3+ Signed-off-by:
Meenakshi Venkataraman <meenakshi.venkataraman@intel.com> Signed-off-by:
-
Ben Hutchings authored
Currently cfg80211 fails to create a "phy80211" symlink in sysfs from the net device to the wiphy device. The latter needs to be registered first. Compile-tested only. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Ben Hutchings authored
Currently cfg80211 fails to create a "phy80211" symlink in sysfs from the net device to the wiphy device. The latter needs to be registered first. Compile-tested only. Reported-by:
Cesare Leonardi <celeonar@gmail.com> Signed-off-by:
-
Anisse Astier authored
RFCSR is only used in rt2800. For other chipsets, the debug struct for rfcsr should be zeroed, which isn't be an issue, since the code can now cope with that. Signed-off-by:
Anisse Astier <anisse@astier.eu> Acked-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
-
Anisse Astier authored
Allow a register to be unspecified, therefore not creating its debugfs file entry. Signed-off-by:
-
Stanislav Yakovlev authored
The problem was found by Stefan Lippers-Hollmann http://marc.info/?l=linux-wireless&m=132720334512946&w=2 WARNING: at /tmp/buildd/linux-aptosid-3.2/debian/build/source_i386_none/net/wireless/core.c:562 wiphy_register+0x45/0x38d [cfg80211]() Hardware name: TravelMate 290 \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff Modules linked in: ipw2200(+) iTCO_wdt libipw joydev drm snd_seq snd_timer snd_seq_device iTCO_vendor_support yenta_socket snd intel_agp i2c_i801 pcmcia_rsrc cfg80211 soundcore parport_pc psmouse parport rng_core snd_page_alloc serio_raw pcspkr i2c_algo_bit intel_gtt pcmcia_core evdev irda crc_ccitt rfkill lib80211 processor container ac battery shpchp pci_hotplug button ext4 mbcache jbd2 crc16 dm_mod sd_mod sr_mod crc_t10dif cdrom ata_generic pata_acpi ata_piix libata scsi_mod firewire_ohci firewire_core crc_itu_t 8139too 8139cp mii uhci_hcd ehci_hcd usbcore usb_common [last unloaded: scsi_wait_scan] Pid: 328, comm: modprobe Not tainted 3.2-1.slh.4-aptosid-686 #1 Call Trace: [<c012eaf4>] ? warn_slowpath_common+0x7c/0x8f [<e0ff0b3e>] ? wiphy_register+0x45/0x38d [cfg80211] [<e0ff0b3e>] ? wiphy_register+0x45/0x38d [cfg80211] [<c012eb22>] ? warn_slowpath_null+0x1b/0x1f [<e0ff0b3e>] ? wiphy_register+0x45/0x38d [cfg80211] [<c01f89d7>] ? internal_create_group+0xf5/0xff [<e0a2de1c>] ? ipw_pci_probe+0xa9a/0xbd0 [ipw2200] [<c01519f4>] ? arch_local_irq_save+0xf/0x14 [<c0252986>] ? pci_device_probe+0x53/0x9a [<c02c2820>] ? driver_probe_device+0x94/0x124 [<c0252871>] ? pci_match_id+0x15/0x34 [<c02c28f0>] ? __driver_attach+0x40/0x5b [<c02c1d81>] ? bus_for_each_dev+0x37/0x60 [<c02c25aa>] ? driver_attach+0x17/0x1a [<c02c28b0>] ? driver_probe_device+0x124/0x124 [<c02c22c4>] ? bus_add_driver+0x92/0x1d1 [<e099d000>] ? 0xe099cfff [<c02c2cb8>] ? driver_register+0x7d/0xd4 [<c017cd50>] ? jump_label_module_notify+0xec/0x167 [<e099d000>] ? 0xe099cfff [<c0253017>] ? __pci_register_driver+0x32/0x87 [<e099d000>] ? 0xe099cfff [<e099d02e>] ? ipw_init+0x2e/0x72 [ipw2200] [<c0101173>] ? do_one_initcall+0x7d/0x132 [<c0145016>] ? __blocking_notifier_call_chain+0x47/0x4f [<c0154a73>] ? sys_init_module+0x13a4/0x159c [<c03a639f>] ? sysenter_do_call+0x12/0x28 This warning appears only if we apply Ben Hutchings' fix http://marc.info/?l=linux-wireless&m=132720195012653&w=2 for the bug reported by Cesare Leonardi http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656813 with cfg80211 warning during device registration ("cfg80211: failed to add phy80211 symlink to netdev!"). We separate device bring up and registration with network stack to avoid the problem. After that Ben Hutchings' fix can be applied to fix the bug. Cc: stable@kernel.org Signed-off-by:
Stanislav Yakovlev <stas.yakovlev@gmail.com> Tested-by:
Stefan Lippers-Hollmann <s.l-h@gmx.de> Signed-off-by:
-
Wey-Yi Guy authored
Change-Id: I10e42e0cc7dd91047f093ea2c5a55d65c004ada6 Signed-off-by:
-
Wey-Yi Guy authored
Signed-off-by: -
Thomas Pedersen authored
If a mesh peer indicates it is operating as 20MHz-only in its HT operation IE, have the rate control algorithm respect this by disabling the equivalent bit in the ieee80211_sta HT capabilities. Signed-off-by:
-
Thomas Pedersen authored
Drivers need the station rate info when inserting a new sta_info. The patch "mac80211: refactor mesh peer initialization" wrongly assumed the rate info could be applied after insertion. After further review, this is clearly not the case. This fixes a regression where HT parameters were not applied before inserting the sta_info, causing performance degradation. Signed-off-by:
-
Amitkumar Karwar authored
"oui_type" in structure "ieee_types_vendor_header" is not used separately, so include it in "oui" array. Now complete oui will be compared fixing following warnings. drivers/net/wireless/mwifiex/sta_ioctl.c:1410 mwifiex_set_gen_ie_helper() error: memcmp() 'pvendor_ie->oui' too small (3 vs 4) drivers/net/wireless/mwifiex/sta_ioctl.c:1435 mwifiex_set_gen_ie_helper() error: memcmp() 'pvendor_ie->oui' too small (3 vs 4) drivers/net/wireless/mwifiex/scan.c:1177 mwifiex_update_bss_desc_with_ie() error: memcmp() 'vendor_ie->vend_hdr.oui' too small (3 vs 4) drivers/net/wireless/mwifiex/scan.c:1185 mwifiex_update_bss_desc_with_ie() error: memcmp() 'vendor_ie->vend_hdr.oui' too small (3 vs 4) Reported-by:Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Avinash Patil <patila@marvell.com> Signed-off-by:
Kiran Divekar <dkiran@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
Rajkumar Manoharan authored
The rate control updation never be called on 2040 BSS change. The station should update its rate control on receiving beacon with different HT mode in the HT operation IE. Not doing so, leads to sending frames with higher(ht40) rates whereas AP is operating in lower mode (ht20). Signed-off-by:
Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by:
-
WarheadsSE authored
modified: drivers/net/wireless/mwifiex/Kconfig - notate additional chipset modified: drivers/net/wireless/mwifiex/sdio.c - add definition of id (0x9116) - add to switch for firmware load - add MODULE_FIRMWARE modified: drivers/net/wireless/mwifiex/sdio.h - add definition of default firmware name Signed-off-by:
Jason Plum <max@warheads.net> Acked-by:
-
Dan Carpenter authored
This is a cut and paste mistake, sizeof(struct mib_local) was intended instead of sizeof(struct mib_phy). The call to at76_get_mib() uses sizeof(struct mib_local) correctly, although I changed that to sizeof(*m) for style reasons after discussion with some of the wireless maintainers. The current code works fine because mib_phy structs are larger than mib_local structs. But we may as well clean it up. Signed-off-by:
-
Emmanuel Grumbach authored
This doesn't make any sense. Init it from the transport instead. Signed-off-by:
-
Stanislaw Gruszka authored
There are various problems happened on 5GHz band not observed on 2.4 GHz (microcode errors, queue stuck, etc... ) . Also roaming between 5GHz AP and 2GHz does not work very well. To workaround the problems add option to disable 5GHz support. This will help on environments where APs are dual-band, and devices will not try to associate on band where issues happen. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Emmanuel Grumbach authored
Also remove a debug print when allocation error occurred. The kernel will complain anyway. Signed-off-by:
-
Wey-Yi Guy authored
Add the Loose coex LUT and will use later for better bt coex tpt Signed-off-by:
-
