aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net
Commit message (Collapse)AuthorAge
* tg3: adapt tg3 to use reworked PCI PM codeRafael J. Wysocki2008-07-30
| | | | | | | | | | Adapt the tg3 driver to use the reworked PCI PM and make it use the exported PCI PM core functions instead of accessing the PCI PM registers directly by itself. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: use the common ascii hex helpersHarvey Harrison2008-07-30
| | | | | | Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'upstream-davem' of ↵David S. Miller2008-07-30
|\ | | | | | | master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6
| * drivers/net/ehea/ehea_main.c: Release mutex in error handling codeJulia Lawall2008-07-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The mutex is released on a successful return, so it would seem that it should be released on an error return as well. The semantic patch finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ expression l; @@ mutex_lock(l); ... when != mutex_unlock(l) when any when strict ( if (...) { ... when != mutex_unlock(l) + mutex_unlock(l); return ...; } | mutex_unlock(l); ) // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * sh_eth: Add support of SH7763 to sh_ethNobuhiro Iwamatsu2008-07-30
| | | | | | | | | | | | | | | | | | SH7763 has Ethernet core same as SH7710/SH7712. Positions of some registry are different, but the basic part is the same. I add support of ethernet of sh7763 to sh_eth. Signed-off-by: Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * fix NE2000 linkage errorMikael Pettersson2008-07-30
| | | | | | | | | | | | | | | | | | | | | | | | | | Trying to build with CONFIG_NE2000=m fails with: scripts/mod/modpost -o /tmp/tmp/linux-2.6.27-rc1/Module.symvers -S -s ERROR: "NS8390_init" [drivers/net/ne.ko] undefined! This is because the split of 8390 into pausing and non-pausing versions was incompletely propagated to ne.c. This fixes it. Signed-off-by: Mikael Pettersson <mikpe@it.uu.se> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * [netdrvr] wd: fix build breakage with new NS8390p APIAlan Cox2008-07-30
| | | | | | | | | | | | From: Alan Cox <alan@redhat.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * dm9601: don't do usb transfers of data on stackPeter Korsgaard2008-07-30
| | | | | | | | | | | | | | | | | | | | dm_{read,write}() were doing USB transfers of data on stack, which isn't allowed. Fix it by kmalloc'ing a temporary buffer. Clean up the error handling for short transfers while we're at it. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * S2io: fix statistics flush after a MTU changeBreno Leitao2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On s2io driver, when you change the interface MTU, it invokes a card reset, which flush some statistics. This patch solves this problem, and also set the net_device->stats as the default statistics structure, instead of s2io_nic->stats. To do that, s2io_nic->stats turned into a staging area, where is saved statistics of the last hardware statistics query. So, the difference between the current hardware statistics and s2io_nic->stats, is the value that should be summed up, in order to get the correct statistics value, even after a reset. Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * enc28j60: don't specify (wrong) IRQ typeDavid Brownell2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recent changes to the IRQ framework have made passing the wrong trigger type to request_irq() become a fatal error. In the case of the enc28j60 driver, it stopped working in my test harness. (Specifically: the signal detects "pin change" events, both edges, not just falling edges. Similarly, other boards might route it through an inverter. Trigger type are board-specific.) This fixes that problem by the usual fix of expecting board setup code to have set up the correct IRQ trigger type. The best known example of that being x86 setup. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * blackfin_mac: unneeded assignmentStephen Hemminger2008-07-29
| | | | | | | | | | | | | | skb->dev is set by eth_type_trans already. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * Merge branch 'for-2.6.27' of git://git.marvell.com/mv643xx_eth into ↵Jeff Garzik2008-07-29
| |\ | | | | | | | | | upstream-fixes
| | * mv643xx_eth: bump version to 1.2Lennert Buytenhek2008-07-24
| | | | | | | | | | | | Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
| | * mv643xx_eth: enable hardware TX checksumming with vlan tagsLennert Buytenhek2008-07-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although mv643xx_eth has no hardware support for inserting a vlan tag by twiddling some bits in the TX descriptor, it does support hardware TX checksumming on packets where the IP header starts {a limited set of values other than 14} bytes into the packet. This patch sets mv643xx_eth's ->vlan_features to NETIF_F_SG | NETIF_F_IP_CSUM, which prevents the stack from checksumming vlan'ed packets in software, and if vlan tags are present on a transmitted packet, notifies the hardware of this fact by toggling the right bits in the TX descriptor. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
| | * mv643xx_eth: print message on link status changeLennert Buytenhek2008-07-24
| | | | | | | | | | | | | | | | | | | | | When there is a link status change (link or phy status interrupt), print a message notifying the user of the new link status. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
| | * mv643xx_eth: use auto phy polling for configuring (R)(G)MII interfaceLennert Buytenhek2008-07-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The mv643xx_eth hardware has a provision for polling the PHY's MII management registers to obtain the (R)(G)MII interface speed (10/100/1000) and duplex (half/full) and pause (off/symmetric) settings to use to talk to the PHY. The driver currently does not make use of this feature. Instead, whenever there is a link status change event, it reads the current link parameters from the PHY, and programs those parameters into the mv643xx_eth MAC by hand. This patch switches the mv643xx_eth driver to letting the MAC auto-determine the (R)(G)MII link parameters by PHY polling, if there is a PHY present. For PHYless ports (when e.g. the (R)(G)MII interface is connected to a hardware switch), we keep hardcoding the MII interface parameters. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
| | * mv643xx_eth: print driver version on initLennert Buytenhek2008-07-24
| | | | | | | | | | | | | | | | | | Print the mv643xx_eth driver version on init to help debugging. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
| | * mv643xx_eth: use symbolic MII register addresses and valuesLennert Buytenhek2008-07-24
| | | | | | | | | | | | | | | | | | | | | Instead of hardcoding MII register addresses and values, use the symbolic constants defined in linux/mii.h. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
| | * mv643xx_eth: use longer DMA burstsLennert Buytenhek2008-07-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The mv643xx_eth driver is limiting DMA bursts to 32 bytes, while using the largest burst size (128 bytes) gives a couple percentage points performance improvement in throughput tests, and the docs say that the 128 byte default should not need to be changed, so use 128 byte bursts instead. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
| | * mv643xx_eth: also check TX_IN_PROGRESS when disabling transmit pathLennert Buytenhek2008-07-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | The recommended sequence for waiting for the transmit path to clear after disabling all of the transmit queues is to wait for the TX_FIFO_EMPTY bit in the Port Status register to become set as well as the TX_IN_PROGRESS bit to clear. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
| | * mv643xx_eth: don't fiddle with maximum receive packet size settingLennert Buytenhek2008-07-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The maximum receive packet size field in the Port Serial Control register controls at what size received packets are flagged overlength in the receive descriptor, but it doesn't prevent overlength packets from being DMAd to memory and signaled to the host like other received packets. mv643xx_eth does not support receiving jumbo frames in 10/100 mode, but setting the packet threshold to larger than 1522 bytes in 10/100 mode won't cause breakage by itself. If we really want to enforce maximum packet size on the receiving end instead of on the sending end where it should be done, we can always just add a length check to the software receive handler instead of relying on the hardware to do the comparison for us. What's more, changing the maximum packet size field requires temporarily disabling the RX/TX paths. So once the link comes up in 10/100 Mb/s mode or 1000 Mb/s mode, we'd have to disable it again just to set the right maximum packet size field (1522 in 10/100 Mb/s mode or 9700 in 1000 Mb/s mode), just so that we can offload one comparison operation to hardware that we might as well do in software, assuming that we'd want to do it at all. Contrary to what the documentation suggests, there is no harm in just setting a 9700 byte maximum packet size in 10/100 mode, so use the maximum maximum packet size for all modes. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
| | * mv643xx_eth: fix transmit-reclaim-in-napi-pollLennert Buytenhek2008-07-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The mv643xx_eth driver allows doing transmit reclaim from within the napi poll routine, but after doing reclaim, it would forget to check the free transmit descriptor count and wake up the transmit queue if the reclaim caused enough descriptors for a new packet to become available. This would cause the netdev watchdog to occasionally kick in during certain workloads with combined receive and transmit traffic. Fix this by adding a wakeup check identical to the one in the interrupt handler to the napi poll routine. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
| | * mv643xx_eth: prevent breakage when link goes down during transmitLennert Buytenhek2008-07-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the ethernet link goes down while mv643xx_eth is transmitting data, transmit DMA can stop before all queued transmit descriptors have been processed. But even the descriptors that _have_ been processed might not be properly marked as done before the transmit DMA unit shuts down. Then when the link comes up again, the hardware transmit pointer might have advanced while not all previous packet descriptors have been marked as transmitted, causing software transmit reclaim to hang waiting for the hardware to finish transmitting a descriptor that it has already skipped. This patch forcibly reclaims all packets on the transmit ring on a link down interrupt, and then resyncs the hardware transmit pointer to what the software's idea of the first free descriptor is. Also, we need to prevent re-waking the transmit queue if we get a 'transmit done' interrupt at the same time as a 'link down' interrupt, which this patch does as well. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
| | * mv643xx_eth: fix TX hang erratum workaroundLennert Buytenhek2008-07-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previously merged TX hang erratum workaround ("mv643xx_eth: work around TX hang hardware issue") assumes that TX_END interrupts are delivered simultaneously with or after their corresponding TX interrupts, but this is not always true in practise. In particular, it appears that TX_END interrupts are issued as soon as descriptor fetch returns an invalid descriptor, which may happen before earlier descriptors have been fully transmitted and written back to memory as being done. This hardware behavior can lead to a situation where the current driver code mistakenly assumes that the MAC has given up transmitting before noticing the packets that it is in fact still currently working on, causing the driver to re-kick the transmit queue, which will only cause the MAC to re-fetch the invalid head descriptor, and generate another TX_END interrupt, et cetera, until the packets in the pipe finally finish transmitting and have their descriptors written back to memory, which will then finally break the loop. Fix this by having the erratum workaround not check the 'number of unfinished descriptor', but instead, to compare the software's idea of what the head descriptor pointer should be to the hardware's head descriptor pointer (which is updated on the same conditions as the TX_END interupt is generated on, i.e. possibly before all previous descriptors have been transmitted and written back). Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
| * | cxgb3: Allow 64KB firmware images.Steve Wise2008-07-29
| | | | | | | | | | | | | | | | | | | | | Starting with FW version 7.0, the driver needs to allow larger images. Signed-off-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * | Blackfin EMAC Driver: Functional power management supportMichael Hennerich2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | Reprogram MAC address after resume from Suspend Mem (Blackfin Hibernate looses all CORE and SYSTEM register content) Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * | Blackfin EMAC Driver: enable TXDWA new feature for new silicon (rev > 0.2)Bryan Wu2008-07-29
| | | | | | | | | | | | | | | Signed-off-by: Bryan Wu <cooloney@kernel.org> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * | Blackfin EMAC Driver: add proper __devinit/__devexit markingsMike Frysinger2008-07-29
| | | | | | | | | | | | | | | | | | Signed-off-by: Mike Frysinger <vapier.adi@gmail.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
| * | forcedeth bug fix: realtek phy 8211c errataAyaz Abdulla2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for the realtek 8211c phy. The driver must perform a hardware reset of the phy due to an errata where the phy could not detect the link. Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
* | | niu: Fix error checking in niu_ethflow_to_class.Andreas Schwab2008-07-30
| | | | | | | | | | | | | | | | | | | | | | | | The callers of niu_ethflow_to_class expect zero as error, but it returns -1 instead. Signed-off-by: Andreas Schwab <schwab@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | Merge branch 'master' of ↵David S. Miller2008-07-30
|\ \ \ | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
| * | | PS3: gelic: use unsigned long for irqflagsVegard Nossum2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The semantic patch I used was this: @@ expression lock; identifier flags; expression subclass; @@ - unsigned int flags; + unsigned long flags; ... <+... ( spin_lock_irqsave(lock, flags) | _spin_lock_irqsave(lock) | spin_unlock_irqrestore(lock, flags) | _spin_unlock_irqrestore(lock, flags) | read_lock_irqsave(lock, flags) | _read_lock_irqsave(lock) | read_unlock_irqrestore(lock, flags) | _read_unlock_irqrestore(lock, flags) | write_lock_irqsave(lock, flags) | _write_lock_irqsave(lock) | write_unlock_irqrestore(lock, flags) | _write_unlock_irqrestore(lock, flags) | spin_lock_irqsave_nested(lock, flags, subclass) | _spin_lock_irqsave_nested(lock, subclass) | spin_unlock_irqrestore(lock, flags) | _spin_unlock_irqrestore(lock, flags) | _raw_spin_lock_flags(lock, flags) | __raw_spin_lock_flags(lock, flags) ) ...+> This patch was generated using the Coccinelle framework. Cc: Masakazu Mokuno <mokuno@sm.sony.co.jp> Cc: Julia Lawall <julia@diku.dk> Cc: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | mac80211: partially fix skb->cb useJohannes Berg2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes mac80211 to not use the skb->cb over the queue step from virtual interfaces to the master. The patch also, for now, disables aggregation because that would still require requeuing, will fix that in a separate patch. There are two other places (software requeue and powersaving stations) where requeue can happen, but that is not currently used by any drivers/not possible to use respectively. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | rtl8187: Improve wireless statistics for RTL8187BLarry Finger2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Wireless statistics produced by the RTL8187B driver are not particularly informative about the strength of the received signal. From the data sheet provided by Realtek, I discovered that certain parts of the RX header should have the information necessary to calculate signal quality and strength. With testing, it became clear that most of these quantities were very jittery - only the AGC correlated with the signals expected from nearby AP's. As a result, the quality and strength are derived from the agc value. The scaling has been determined so that the numbers are close to those obtained by b43 under the same conditions. The results are qualitatively correct. Statistics derived for the RTL8187 have not been changed. The RX header variables have been renamed to match the quantites described in the Realtek data sheet. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | rtl8187: Fix for TX sequence number problemLarry Finger2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "mac80211: fix TX sequence numbers" broke rtl8187. This patch makes the same kind of fix that was done for rt2x00. Note that this code will have to be reworked for proper sequence numbers on beacons. In addition, the sequence number has been placed in the hardware state, not the vif state. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | mac80211: fix sparse integer as NULL pointer warningHarvey Harrison2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | drivers/net/wireless/mac80211_hwsim.c:503:20: warning: Using plain integer as NULL pointer Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | drivers/net/wireless/iwlwifi/iwl-led.c: printk fixAndrew Morton2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ia64: drivers/net/wireless/iwlwifi/iwl-led.c: In function `iwl_get_blink_rate': drivers/net/wireless/iwlwifi/iwl-led.c:271: warning: long long int format, s64 arg (arg 6) drivers/net/wireless/iwlwifi/iwl-led.c:271: warning: long long int format, u64 arg (arg 7) We do not know what type the architecture uses to impement u64 and s64, hence we must cast the variables for printing. Cc: Tomas Winkler <tomas.winkler@intel.com> Cc: John W. Linville <linville@tuxdriver.com> Cc: Zhu Yi <yi.zhu@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | rt2x00: Clear queue entry flags during initializationIvo van Doorn2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the queues are being initialized the entry flags fields must be reset to 0. When this does not happen some entries might still be marked as "occupied" after an ifdown & ifup cycle which would trigger errors when the entry is being accessed: phy0 -> rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 0. Please file bug report to http://rt2x00.serialmonkey.com. This also fixes the mac80211 warning: ------------[ cut here ]------------ WARNING: at net/mac80211/tx.c:1238 ieee80211_master_start_xmit+0x30a/0x350 [mac80211]() which was triggered by the queue error. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | rt2x00: Force full register config after start()Ivo van Doorn2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rt2x00 will only perform configuration changes from mac80211 when the configuration option has changed. This means it keeps track of the current active configuration and will check these values when the config() callback function is used. However this causes breakage when the interface has been brought down and up again, since all stored active values aren't reset while the registers might have. This is for example the case with rt61pci antenna registers which will jump to invalid values when the interface has been started. To make sure a full configuration takes place after the start() callback function, a new flag is added which will be checked during config() and skips the "what's changed" phase. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | b43legacy: Release mutex in error handling codeJulia Lawall2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The mutex is released on a successful return, so it would seem that it should be released on an error return as well. The semantic patch finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ expression l; @@ mutex_lock(l); ... when != mutex_unlock(l) when any when strict ( if (...) { ... when != mutex_unlock(l) + mutex_unlock(l); return ...; } | mutex_unlock(l); ) // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: Michael Buesch <mb@bu3sch.de> Cc: stable <stable@kernel.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | drivers/net/wireless/ipw2100.c: Release mutex in error handling codeJulia Lawall2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The mutex is released on a successful return, so it would seem that it should be released on an error return as well. The semantic patch finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ expression l; @@ mutex_lock(l); ... when != mutex_unlock(l) when any when strict ( if (...) { ... when != mutex_unlock(l) + mutex_unlock(l); return ...; } | mutex_unlock(l); ) // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | rt2x00: Fix memleak when RTS/CTS failsIvo van Doorn2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When sending the RTS/CTS frame fails, we should free the skb buffer which was created. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | rt2x00: Fix QOS sequence countingIvo van Doorn2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When IEEE80211_TX_CTL_ASSIGN_SEQ is not set, the driver should disable hardware sequence counting to make sure the mac80211 provided counter is used. This fixes QOS sequence counting, since that is one of the cases where mac80211 provides a seperate sequence counter. By moving the sequence counting code to rt2x00queue we make sure that _all_ frames get the sequence counter, including RTS/CTS and Beacon frames. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | rt2x00: Fix the beacon length bugIwo Mergler2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When setting up a beacon template, the length of the beacon is calculated with the assumption that the SKB already contains the Tx descriptor. In the case of beacons it doesn't. This patch undoes the damage by adding the Tx descriptor length to the beacon length. This is safe, because the shortest possible beacon is longer than the Tx header. Signed-off-by: Iwo Mergler <Iwo@call-direct.com.au> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | rt2x00: Large vendor requests for rt73usb firmware upload and beaconsIwo Mergler2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Switches rt73usb to use large vendor requests for firmware and beacons. This also fixes the garbled beacon bug. Signed-off-by: Iwo Mergler <Iwo@call-direct.com.au> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | rt2x00: Support for large vendor requestsIwo Mergler2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds an extra rt2x00 vendor request function to support register transfers beyond the CSR_CACHE_SIZE / USB packet size limit. This is useful for firmware uploads, beacon templates and keys, all of which are to large to do with a single USB request. Signed-off-by: Iwo Mergler <Iwo@call-direct.com.au> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | rt2x00: Fix EIFS timing valueIvo van Doorn2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Olivier reported a difference between the EIFS values used in the legacy driver and the one in the rt2x00 drivers. In rt2x00 the value was ( SIFS + (8 * (IEEE80211_HEADER + ACK_SIZE)) ) which comes down to 314us while the legacy driver uses the value 364us This was caused because EIFS is: SIFS + DIFS + AckTime This patch will fix this by adding the DIFS by the above value, and creating a SHORT_EIFS define which uses the SHORT_DIFS. Reported-by: Olivier Cornu <o.cornu@gmail.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | rt2x00: Remove duplicate declarationIvo van Doorn2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | rt2x00queue_free_skb() was declared twice. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | ath5k: don't enable MSI, we cannot handle it yetPavel Roskin2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MSI is a nice thing, but we cannot enable it without changing the interrupt handler. If we do it, we break MSI capable hardware, specifically AR5006 chipset. Signed-off-by: Pavel Roskin <proski@gnu.org> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Cc: stable <stable@kernel.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | ath5k: fix recursive locking in ath5k_beacon_updateBob Copeland2008-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ath5k_beacon_update takes sc->lock upon entry. However, it is only called from within ath5k_config_interface, which already holds the lock. Remove the unnecessary locking from ath5k_beacon_update. Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
generated by cgit v1.2.2 (git 2.25.0) at 2024-12-17 18:21:41 -0500