- 10 Sep, 2009 2 commits
-
-
Patrick McHardy authored
When new child qdiscs are attached to the mq qdisc, they are actually attached as root qdiscs to the device queues. The lock selection for new estimators incorrectly picks the root lock of the existing and to be replaced qdisc, which results in a use-after-free once the old qdisc has been destroyed. Mark mq qdisc instances with a new flag and treat qdiscs attached to mq as children similar to regular root qdiscs. Additionally prevent estimators from being attached to the mq qdisc itself since it only updates its byte and packet counters during dumps. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 09 Sep, 2009 17 commits
-
-
Holger Schurig authored
Handles the case when SIOCSIWSCAN specified iw_scan_req.num_channels and iw_scan_req.channels[]. Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Vasanthakumar Thiagarajan authored
Oops, a stupid mistake in the original patch which adds coex 3-wire support. Bluetooth priority gpio needs to be gpio 7. Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Vasanthakumar Thiagarajan authored
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Vasanthakumar Thiagarajan authored
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Vasanthakumar Thiagarajan authored
This subsystem id will be used later to turn on the btcoex support. Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
The preferred module is p54pci which also supports FullMAC PCI / Cardbus devices. We schedule removal for 2.6.34. Reason to remove this is no one really is testing prism54 anymore, and while it works p54pci provides support for the same hardware. It should be noted I have been told some FullMAC devices may not have worked with the SoftMAC driver but to date we have yet to recieve a single bug report regarding this. If there are users out there please let us know! Cc: aquilaver@yahoo.com Cc: linux-kernel@vger.kernel.org Cc: Dan Williams <dcbw@redhat.com> Cc: Kai Engert <kengert@redhat.com> Cc: Jean Tourrilhes <jt@hpl.hp.com> Cc: Tim de Waal<tim.dewaal@yahoo.com> Cc: Roy Marples <uberlord@gentoo.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Christian Lamparter <chunkeey@web.de> Cc: Björn Steinbrink <B.Steinbrink@gmx.de> Cc: Tim Gardner <tim.gardner@canonical.com> Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Michael Buesch authored
This fixes some gcc warnings for switch statements. Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Albert Herranz authored
Add support for communicating with a Sonics Silicon Backplane through a SDIO interface, as found in the Nintendo Wii WLAN daughter card. The Nintendo Wii WLAN card includes a custom Broadcom 4318 chip with a SDIO host interface. Signed-off-by: Albert Herranz <albert_herranz@yahoo.es> Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Vasanthakumar Thiagarajan authored
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Vasanthakumar Thiagarajan authored
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Joe Perches authored
On Sun, 2009-09-06 at 12:26 -0700, Luis R. Rodriguez wrote: > On Sun, Sep 6, 2009 at 10:59 AM, Joe Perches<joe@perches.com> wrote: > > On Thu, 2009-09-03 at 15:54 -0700, Luis R. Rodriguez wrote: > >> I'm pleased to announce the new home page to Atheros Linux wireless drivers: > >> http://wireless.kernel.org/en/users/Drivers/Atheros > > Perhaps add this to MAINTAINERS? > Fine by me, except ath5k and ath9k also have their own respective page > so those can also be added. (cc's trimmed and maintainers added) Perhaps this instead: Signed-off-by: Joe Perches <joe@perches.com> Acked-by: Luis R. Rodriguez <mcgrof@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Michael Buesch authored
This fixes a sparse warning in the hardware-TKIP code: drivers/net/wireless/b43/xmit.c:272:18: warning: incorrect type in assignment (different base types) drivers/net/wireless/b43/xmit.c:272:18: expected unsigned short [unsigned] [short] <noident> drivers/net/wireless/b43/xmit.c:272:18: got restricted unsigned short [usertype] <noident> The code should work correctly with and without this patch applied. Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Michael Buesch authored
Currently, when QoS-disable is requested, we would leave QoS enabled in firmware, but only queue frames on one queue. Change that and also tell firmware about disabled QoS, so it completely ignores all the QoS parameters. Also don't upload the parameters, if QoS is disabled. Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
The calculated values for the ACK timeout and ACK consume time are different then the values as used by the Legacy drivers. After testing from James Ledwith it appeared that the calculated values caused a high amount of TX failures, and the values from the Legacy drivers were the most optimal to prevent TX failure due to excessive retries. The symptoms of this problem: - Rate control module always falls back to 1Mbs - Low throughput when bitrate was fixed Possible side-effects (not confirmed but highly likely) - Problems with DHCP - Broken connections due to lack of probe response This should fix at least: Kernel bugzilla reports: [13362], [13009], [9273] Fedora bugzilla reports: [443203] but possible some additional bugs as well. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Alexey Dobriyan authored
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tushar Gohad authored
Fix apparent thinko related to RTM_DELADDRLABEL, introduced by commit 2a8cc6c8 ("[IPV6] ADDRCONF: Support RFC3484 configurable address selection policy table."). Signed-off-by: Tushar Gohad <tgohad@mvista.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tobias Klauser authored
The function res_size in drivers/net/niu.c is a copy of resource_size in linux/ioport.h. Remove the function and use resource_size instead. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 08 Sep, 2009 17 commits
-
-
Michael Buesch authored
PCMCIA support works well and is not experimental anymore. Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Joerg Albert authored
apply the conformance test limits (CTL) stored in the eeprom upon the values calculated for the tx power (ar->power_*). This is based on the implementation in the vendor driver (hal/hpmain.c, line 3700 ff.) with one difference: If any ctl mode isn't found in the eeprom, we fall back to the "lower", legacy modes (5GHT20,11A or 2GHT20,11G,11B). Otus only did 5GHT20->11A. Currently CTL are applied for the FCC group only. Signed-off-by: Joerg Albert <jal2@gmx.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Joerg Albert authored
The ar9170 driver needs the defines for conformance test limit groups and cannot include regd_common.h Signed-off-by: Joerg Albert <jal2@gmx.de> Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Michael Buesch authored
SSB modinit should not succeed, if busattach failed. Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Michael Buesch authored
This removes the SHM spinlock. SHM is protected by wl->mutex. Signed-off-by: Michael Buesch <mb@bu3sch.de> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Michael Buesch authored
This removes the PIO RX work. It's not needed anymore, because we can sleep in the threaded interrupt handler. Signed-off-by: Michael Buesch <mb@bu3sch.de> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Michael Buesch authored
This removes the DMA/PIO queue locks. Locking is handled by wl->mutex now. Signed-off-by: Michael Buesch <mb@bu3sch.de> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Michael Buesch authored
This removes the TX spinlock and defers TX to a workqueue to allow locking wl->mutex instead and to allow sleeping for register accesses. Signed-off-by: Michael Buesch <mb@bu3sch.de> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Michael Buesch authored
Use a threaded IRQ handler to allow locking the mutex and sleeping while executing an interrupt. This removes usage of the irq_lock spinlock, but introduces a new hardirq_lock, which is _only_ used for the PCI/SSB lowlevel hard-irq handler. Sleeping busses (SDIO) will use mutex instead. Signed-off-by: Michael Buesch <mb@bu3sch.de> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
cfg80211 is now *the* wireless configuration API. Lets also give a little explanation as to what it is and refer people to the wireless wiki for more information. Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
This patch ports some code from the vendor driver, which is supposed to upload the right calibration values for the chosen frequency. In theory, this should give a better range and throughput for all users with the open, or one-stage firmware. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith authored
CHANNEL_G has to be set for 2GHZ channels since IS_CHAN_G() checks for this in channelFlags and not in chanmode. To make things messier, ath9k_hw_process_ini() checks for CHANNEL_G in chanmode and not in channelFlags. The supreme, brain-searing fix is to set the flag in both cases. Signed-off-by: Sujith <Sujith.Manoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sujith authored
BAR frames have to be sent to mac80211 only if the current channel is HT. Also, move the macro to enum ath9k_rx_filter. Signed-off-by: Sujith <Sujith.Manoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
ath9k ahb requests an IRQ and indicates 'ath9k' claimed it, ath9k pci requests an IRQ and indicates 'ath' claims it; since 'ath' is another module sync both ahb and pci to claim the irq using 'ath9k'. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
We've cleaned up ath_init_device() and its children enough to pass meaninful errors back from probe. When this fails it means our device could not be initialized and a meaninful error will have been passed. Do the same for request_irq() and also synchronize the error messages while at it. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
The -ENOMEM was never being passed on failure. While at it use dev_err() as ahb does upon failure. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Joerg Albert authored
This patch adds the initialisation of some PHY registers from the modal_header[] values in the EEPROM (see otus/hal/hpmain.c, line 333 ff.) Signed-off-by: Joerg Albert <jal2@gmx.de> Acked-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 07 Sep, 2009 4 commits
-
-
David S. Miller authored
Reported by Stephen Rothwell: drivers/net/r8169.c: In function 'rtl8169_start_xmit': drivers/net/r8169.c:3421: warning: label 'out' defined but not used Introduced by commit 61357325 ("netdev: convert bulk of drivers to netdev_tx_t"). Signed-off-by: David S. Miller <davem@davemloft.net>
-
Randy Dunlap authored
m68k: drivers/net/hydra.c:178: warning: format '%08lx' expects type 'long unsigned int', but argument 3 has type 'resource_size_t' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Krzysztof Halasa authored
HSS usually uses external clocks, so it's not a big deal. Internal clock is used for direct DTE-DTE connections and when the DCE doesn't provide it's own clock. This also depends on the oscillator frequency. Intel seems to have calculated the clock register settings for 33.33 MHz (66.66 MHz timer base). Their settings seem quite suboptimal both in terms of average frequency (60 ppm is unacceptable for G.703 applications, their primary intended usage(?)) and jitter. Many (most?) platforms use a 33.333 MHz oscillator, a 10 ppm difference from Intel's base. Instead of creating static tables, I've created a procedure to program the HSS clock register. The register consists of 3 parts (A, B, C). The average frequency (= bit rate) is: 66.66x MHz / (A + (B + 1) / (C + 1)) The procedure aims at the closest average frequency, possibly at the cost of increased jitter. Nobody would be able to directly drive an unbufferred transmitter with a HSS anyway, and the frequency error is what it really counts. I've verified the above with an oscilloscope on IXP425. It seems IXP46x and possibly IXP43x use a bit different clock generation algorithm - it looks like the avg frequency is: (on IXP465) 66.66x MHz / (A + B / (C + 1)). Also they use much greater precomputed A and B - on IXP425 it would simply result in more jitter, but I don't know how does it work on IXP46x (perhaps 3 least significant bits aren't used?). Anyway it looks that they were aiming for exactly +60 ppm or -60 ppm, while <1 ppm is typically possible (with a synchronized clock, of course). The attached patch makes it possible to set almost any bit rate (my IXP425 533 MHz quits at > 22 Mb/s if a single port is used, and the minimum is ca. 65 Kb/s). This is independent of MVIP (multi-E1/T1 on one HSS) mode. Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Krzysztof Halasa authored
PCI200SYN has its own PCI subsystem device ID for 3+ years, now it's time to remove the generic PLX905[02] ID from the driver. Anyone with old EEPROM data will have to run the upgrade. Having the generic PLX905[02] (PCI-local bus bridge) ID is harmful as the driver tries to handle other devices based on these bridges. Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
-