If the user gives a packet under 14 bytes, we'll end up reading off the end
of the skb (not oopsing, just reading off the end).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Acked-by: Max Krasnyanskiy <maxk@qualcomm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There's no reason for this to be in the header, and it just hurts
recompile time.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Acked-by: Max Krasnyanskiy <maxk@qualcomm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The driver stores the PCI resource addresses into 'unsigned long' variable
before calling ioremap_nocache() on them. This warrants kernel oops when the
registers are accessed on PPC 44x platforms which (being 32-bit) have PCI
memory space mapped beyond 4 GB.
The arch/ppc/ kernel has a fixup in ioremap() that creates an illusion that
the PCI memory resource is mapped below 4 GB, but arch/powerpc/ code got rid
of this trick, having instead CONFIG_RESOURCES_64BIT enabled.
[ Bump driver version and release date -DaveM ]
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
PPP support in generic HDLC in Linux 2.6.25 is broken and will cause
a kernel panic when a device configured in PPP mode is activated.
It will be replaced by new PPP implementation after Linux 2.6.25 is
released.
This affects only PPP support in generic HDLC (mostly Hitachi SCA
and SCA-II based drivers, wanxl, and few others). Standalone syncppp
and async PPP support are not affected.
Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
This patch fixes two weaknesses in send/receive packet handling which may
lead to kernel panics during DLPAR memory add operations.
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
This critical patch fixes a mac address issue recently introduced. If the
device's mac address was in correct order and the flag
NVREG_TRANSMITPOLL_MAC_ADDR_REV was set, during nv_remove the flag would get
cleared. During next load, the mac address would get reversed because the
flag is missing.
As it has been indicated previously, the flag is cleared across a low power
transition. Therefore, the driver should set the mac address back into the
reversed order when clearing the flag.
Also, the driver should set back the flag after a low power transition to
protect against kexec command calling nv_probe a second time.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Cc: "Yinghai Lu" <yhlu.kernel@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Call phy_disconnect() on remove routine. Otherwise the phy timer
causes a kernel crash when unloading.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
The new Fixed PHY method, fixed-link property, isn't
impl. for ucc_geth which makes fixed PHYs non functional.
Add support for the new method to restore the Fixed PHY
functionality.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Any usage of sky2 on new Yukon Supreme would cause a NULL dereference.
The chip is very new, so the support is still untested; vendor has
not sent any eval hardware.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Fixed bug: Wrong register was written to when bringing the chip out of
reset.
[ Bump driver version and release date -DaveM ]
Signed-off-by: Eliezer Tamir <eliezert@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The layer above will free the skb in an error case.
Signed-off-by: Daniel Wagner <wagi@monom.org>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If print_mac() is used inside of a pr_debug() the compiler
can't see that the call is redundant so still performs it
even of pr_debug() ends up being a nop.
So don't use print_mac() in such cases in hot code paths,
use MAC_FMT et al. instead.
As noted by Joe Perches, pr_debug() could be modified to
handle this better, but that is a change to an interface
used by the entire kernel and thus needs to be validated
carefully. This here is thus the less risky fix for
2.6.25
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch enables the IWL4965_HT flag (n-band) in Kconfig.
Removed the "depends on n" from Kconfig for config IWL4965_HT
Signed-off-by: Abhijeet Kolekar <abhijeet.kolekar@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commit bada339ba2 enforces that all
interfaces have a valid MAC address before they are brought up.
ipw2200 does not assign a MAC address to it's radiotap interface, meaning
that the radiotap interface cannot be brought up in 2.6.24.
https://bugs.gentoo.org/show_bug.cgi?id=215714
Fix this by copying the MAC address from the real interface.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
After moving lbs_find_best_network_ssid() from scan.c to assoc.c gcc was
able to deduce that new_mode might stay uninitialized.
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
a) if you initialize something with le32_to_cpu(...), then |= it
with host-endian and feed to cpu_to_le32(), it's most definitely
*not* __le32. As sparse would've told you...
b) the whole sequence is |= cpu_to_le32(host-endian constant)
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
My previous section fix only turned one section problem into another
section problem.
This patch fixes it for real.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The other if blocks don't redeclare temp, remove the redeclaration in
the final if() block.
drivers/net/phy/marvell.c:214:7: warning: symbol 'temp' shadows an earlier one
drivers/net/phy/marvell.c:160:6: originally declared here
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The 5784 B step and newer chips require the PHY DSPs to be fine-tuned
based on one-time programmable values stored in the chip. This is
essential to achieve optimal PHY operations especially when using
long cables. We also need to properly handle the 10Mbit RX bit in the
CPMU_CTRL register during PHY reset.
Update version to 3.89.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There are a couple of possible races on suspend/resume.
First the driver needs to block new packets from being queued for Tx.
The other less likely problem is the watchdog timer going off
during resume.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (45 commits)
[VLAN]: Proc entry is not renamed when vlan device name changes.
[IPV6]: Fix ICMP relookup error path dst leak
[ATM] drivers/atm/iphase.c: compilation warning fix
IPv6: do not create temporary adresses with too short preferred lifetime
IPv6: only update the lifetime of the relevant temporary address
bluetooth : __rfcomm_dlc_close lock fix
bluetooth : use lockdep sub-classes for diffrent bluetooth protocol
[ROSE/AX25] af_rose: rose_release() fix
mac80211: correct use_short_preamble handling
b43: Fix PCMCIA IRQ routing
b43: Add DMA mapping failure messages
mac80211: trigger ieee80211_sta_work after opening interface
[LLC]: skb allocation size for responses
[IP] UDP: Use SEQ_START_TOKEN.
[NET]: Remove Documentation/networking/sk98lin.txt
[ATM] atm/idt77252.c: Make 2 functions static
[ATM]: Make atm/he.c:read_prom_byte() static
[IPV6] MCAST: Ensure to check multicast listener(s).
[LLC]: Kill llc_station_mac_sa symbol export.
forcedeth: fix locking bug with netconsole
...
This fixes the IRQ routing on PCMCIA devices.
With this patch the card will finally be able to receive IRQs.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This adds messages for some DMA mapping failures.
These are useful for debugging DMA address problems, as they appear
on x86_64 machines with IOMMU enabled.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Plip uses spin_lock_irq/spin_unlock_irq in its IRQ handler (called from
parport IRQ handler), the latter enables interrupts without parport
subsystem IRQ handler expecting it.
The bug can be seen if you compile kernel with lock dependency checking
and use plip --- it produces a warning.
This patch changes it to spin_lock_irqsave/spin_lock_irqrestore, so that
it doesn't enable interrupts when already disabled.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The asix usb driver currently depends on NET_ETHERNET which means you
cannot enable this driver if you only have 1000mbit enabled in your kernel.
Since there is no real dependency between the NET_ETHERNET portion and the
asix driver, simply drop it.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Cc: Greg KH <greg@kroah.com>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Move the "&& skb->ip_summed == CHECKSUM_PARTIAL" part out of
emac_has_feature parameters.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
drivers/net/pasemi_mac.c is enabled by CONFIG_PASEMI_MAC, which depends on
PPC64 && PCI. However pasemi_mac.c uses several routines that are only
built when PPC_PASEMI is selected. This can lead to an unbuildable config:
ERROR: ".pasemi_dma_start_chan" [drivers/net/pasemi_mac.ko] undefined!
So make CONFIG_PASEMI_MAC depend on PPC_PASEMI instead of PPC64.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
- Updated version number.
- Resubmitting with correct version update.
- this patch to be applied for upstream-davem branch
Signed-off-by: Surjit Reang <surjit.reang@neterion.com>
Signed-off-by: Sreenivasa Honnur <sreenivasa.honnur@neterion.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Remove superfluous in-atomic() check; ethtool MII ops are called from task
context.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Greg KH <greg@kroah.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The loop forgot to walk the net->mc_list list, so only the first
multicast address was programmed into the hash table.
Signed-off-by: Jeff Garzik <jeff@garzik.org>
If "location" is > "addr_len" bits, the high bits of location would interfere
with the READ_CMD sent to the eeprom controller.
A patch was submitted to bug:
http://bugzilla.kernel.org/show_bug.cgi?id=4420
which simply truncated the "location", read whatever was in "location
modulo addr_len", and returned that value. That avoids confusing the
eeprom but seems like the wrong solution to me.
Correct would be to not read beyond "1 << addr_len" address of the eeprom.
I am submitting two changes to implement this:
1) tulip_read_eeprom will return zero (since we can't return -EINVAL)
if this is attempted (defensive programming).
2) In tulip_core.c, fix the tulip_read_eeprom caller so they don't
iterate past addr_len bits and make sure the entire tp->eeprom[]
array is cleared.
I konw we don't strictly need both. I would prefer both in the tree
since it documents the issue and provides a second "defense" from
the bug from creeping back in.
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
original_mtu is only used if we end up with a non-NULL
dev, and it is assigned in all such cases, but GCC can't
see that.
Signed-off-by: David S. Miller <davem@davemloft.net>
Some hardware never seem to accept the "goto sleep" command, since the legacy
drivers don't have suspend and resume handlers the entire code for it was
basically a educated guess (based on the "enable radio" code).
This patch will only print a warning when the "goto sleep" command fails, and
just continues as usual. Perhaps that means the device will not reach a sleep
state and consumes more power then it should, but it is equally possible it
simply needs some seconds longer to sleep. Anyway, by making the command
non-fatal it will not block the rest of the suspend procedure.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In commit e6bafba5b4, a bug was fixed that
involved converting !x & y to !(x & y). The code below shows the same
pattern, and thus should perhaps be fixed in the same way.
This is not tested and clearly changes the semantics, so it is only
something to consider.
The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@@ expression E1,E2; @@
(
!E1 & !E2
|
- !E1 & E2
+ !(E1 & E2)
)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: Guy Cohen <guy.cohen@intel.com>
Cc: Reinette Chatre <reinette.chatre@intel.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>
This fixes a bug detected by CONFIG_DEBUG_SPINLOCK:
if_cs_get_int_status() is only called from lbs_thread(), via
priv->hw_get_int_status. However, lbs_thread() has already taken the
priv->driver_lock. So it's a fault to take the same lock again here.
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
- Handling TX completions on the same cpu as the sender.
Signed-off-by: Surjit Reang <surjit.reang@neterion.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Some ROMs on embedded devices store incorrect values for
the PHY address of the ethernet device.
It looks like the number is sign-extended.
Truncate the value by applying the PHY-address mask to it.
The patch was tested on a bcm47xx embedded system (where the bug
triggers) and a bcm4400 PCI card.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
