- 24 Feb, 2008 40 commits
-
-
Adrian Bunk authored
This patch fixes a check-after-use spotted by the Coverity checker. Signed-off-by:
Adrian Bunk <bunk@kernel.org> Signed-off-by:
Jeff Garzik <jeff@garzik.org>
-
Bill Hayes authored
This patch eliminates a kernel panic with the igb driver in 2.6.25-rc2 when running on a Intel 82575 Ethernet controller with a 1000BASE-SX PHY. The panic does not happen with the 1000BASE-T PHY, only with a SX connection. Signed-off-by:
Bill Hayes <bill.hayes@hp.com> Signed-off-by:
Andy Gospodarek <andy@greyhouse.net> Signed-off-by:
Auke Kok <auke-jan.h.kok@intel.com> Signed-off-by:
-
Becky Bruce authored
Change all dma op invocations in gianfar.c to actually pass in the device pointer. Currently, the value is ignored, but it will be used going forward as we implement archdata for 32-bit powerpc. Signed-off-by:
Becky Bruce <becky.bruce@freescale.com> Acked-by:
Andy Fleming <afleming@freescale.com> Signed-off-by:
-
Francois Romieu authored
Reading a serie of zero from the cmos sram area do not work well with is_valid_ether_addr(). Let's read the mac address from the eeprom first as it seems more reliable. Fix for http://bugzilla.kernel.org/show_bug.cgi?id=9831Signed-off-by:
Francois Romieu <romieu@fr.zoreil.com> Signed-off-by:
-
Harvey Harrison authored
The forward declarations were already marked static, make the definitions be static as well. Fixes the sparse warnings as well. drivers/net/tlan.c:1403:5: warning: symbol 'TLan_HandleInvalid' was not declared. Should it be static? drivers/net/tlan.c:1435:5: warning: symbol 'TLan_HandleTxEOF' was not declared. Should it be static? drivers/net/tlan.c:1521:5: warning: symbol 'TLan_HandleStatOverflow' was not declared. Should it be static? drivers/net/tlan.c:1557:5: warning: symbol 'TLan_HandleRxEOF' was not declared. Should it be static? drivers/net/tlan.c:1692:5: warning: symbol 'TLan_HandleDummy' was not declared. Should it be static? drivers/net/tlan.c:1722:5: warning: symbol 'TLan_HandleTxEOC' was not declared. Should it be static? drivers/net/tlan.c:1770:5: warning: symbol 'TLan_HandleStatusCheck' was not declared. Should it be static? drivers/net/tlan.c:1845:5: warning: symbol 'TLan_HandleRxEOC' was not declared. Should it be static? drivers/net/tlan.c:1905:6: warning: symbol 'TLan_Timer' was not declared. Should it be static? drivers/net/tlan.c:1986:6: warning: symbol 'TLan_ResetLists' was not declared. Should it be static? drivers/net/tlan.c:2046:6: warning: symbol 'TLan_FreeLists' was not declared. Should it be static? drivers/net/tlan.c:2095:6: warning: symbol 'TLan_PrintDio' was not declared. Should it be static? drivers/net/tlan.c:2130:6: warning: symbol 'TLan_PrintList' was not declared. Should it be static? drivers/net/tlan.c:2166:6: warning: symbol 'TLan_ReadAndClearStats' was not declared. Should it be static? drivers/net/tlan.c:2242:1: warning: symbol 'TLan_ResetAdapter' was not declared. Should it be static? drivers/net/tlan.c:2328:1: warning: symbol 'TLan_FinishReset' was not declared. Should it be static? drivers/net/tlan.c:2451:6: warning: symbol 'TLan_SetMac' was not declared. Should it be static? drivers/net/tlan.c:2493:6: warning: symbol 'TLan_PhyPrint' was not declared. Should it be static? drivers/net/tlan.c:2542:6: warning: symbol 'TLan_PhyDetect' was not declared. Should it be static? drivers/net/tlan.c:2589:6: warning: symbol 'TLan_PhyPowerDown' was not declared. Should it be static? drivers/net/tlan.c:2614:6: warning: symbol 'TLan_PhyPowerUp' was not declared. Should it be static? drivers/net/tlan.c:2635:6: warning: symbol 'TLan_PhyReset' was not declared. Should it be static? drivers/net/tlan.c:2663:6: warning: symbol 'TLan_PhyStartLink' was not declared. Should it be static? drivers/net/tlan.c:2750:6: warning: symbol 'TLan_PhyFinishAutoNeg' was not declared. Should it be static? drivers/net/tlan.c:2906:5: warning: symbol 'TLan_MiiReadReg' was not declared. Should it be static? drivers/net/tlan.c:2996:6: warning: symbol 'TLan_MiiSendData' was not declared. Should it be static? drivers/net/tlan.c:3038:6: warning: symbol 'TLan_MiiSync' was not declared. Should it be static? drivers/net/tlan.c:3077:6: warning: symbol 'TLan_MiiWriteReg' was not declared. Should it be static? drivers/net/tlan.c:3147:6: warning: symbol 'TLan_EeSendStart' was not declared. Should it be static? drivers/net/tlan.c:3187:5: warning: symbol 'TLan_EeSendByte' was not declared. Should it be static? drivers/net/tlan.c:3248:6: warning: symbol 'TLan_EeReceiveByte' was not declared. Should it be static? drivers/net/tlan.c:3306:5: warning: symbol 'TLan_EeReadByte' was not declared. Should it be static? Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by:
-
Julia Lawall authored
The kernel.h macro DIV_ROUND_UP performs the computation (((n) + (d) - 1) / (d)) but is perhaps more readable. Signed-off-by:
Ursula Braun <braunu@de.ibm.com> Signed-off-by:
-
Komuro authored
* If ConfigBase is 0x03c0 && manfid is (0x0149,0xc1ab), printk "use axnet_cs instead" message. Actually, most of the card with manfid(0x0149, 0xc1ab) use pcnet_cs driver. * remove entry (0x021b, 0x0202) Signed-off-by:Komuro <komurojun-mbn@nifty.com> Signed-off-by:
-
Leonardo Potenza authored
Suppress the warning message about the 'netcard_portlist' defined but not used. Signed-off-by:
Leonardo Potenza <lpotenza@inwind.it> Signed-off-by:
-
Christian Borntraeger authored
Signed-off-by: -
Grant Grundler authored
Patch fixes: http://bugzilla.kernel.org/show_bug.cgi?id=5839 Init sequence needs to poll phy until phy reset is complete. This is the same problem that I fixed in 2002 in tulip driver. Thanks to manty@manty.net for testing this patch. Thanks to Pozsar Balazs <pozsy@uhulinux.hu> for posting/testing a similar patch before: http://lkml.org/lkml/2006/8/21/45Signed-off-by:Grant Grundler <grundler@parisc-linux.org> Signed-off-by:
-
Grant Grundler authored
Kyle and I are co-maintaining tulip driver. Normally kyle will review my patchs and submit them. I'll deal with bugzilla.kernel.org bugs and try to resolve those bugs. Signed-off-by:
-
Andy Gospodarek authored
I booted an igb kernel with the option pci=nomsi and instantly noticed that interrupts no longer worked on my igb device. I took a look at the interrupt initialization and quickly discovered a comment stating: "DO NOT USE EIAME or IAME in legacy mode" It seemed a bit odd that bits to enable IAM were being set in legacy interrupt mode, so I dropped out the following parts and interrupts began working fine again. [Updated code flow and a nitpick spelling error --Auke] Signed-off-by:
-
Scott Wood authored
The lock acquisition in fs_ioctl() does not appear to actually be necessary, and thus is simply removed. Signed-off-by:
Scott Wood <scottwood@freescale.com> Signed-off-by:
-
Thomas Klein authored
This patch adds kdump support to the ehea driver. As the firmware doesn't free resource handles automatically, the driver has to run an as simple as possible free resource function in case of a crash shutdown. The function iterates over two arrays freeing all resource handles which are stored there. The arrays are kept up-to-date during normal runtime. The crash handler fn is triggered by the recently introduced PPC crash shutdown reg/unreg functions. Signed-off-by:
Thomas Klein <tklein@de.ibm.com> Signed-off-by:
-
David S. Miller authored
-
Mirco Tischler authored
This fixes the following compile error caused by commit 3a2d5b70 ("PM: Introduce PM_EVENT_HIBERNATE callback state") CC [M] drivers/usb/host/u132-hcd.o drivers/usb/host/u132-hcd.c: In function ‘u132_suspend’: drivers/usb/host/u132-hcd.c:3224: error: expected expression before ‘int’ drivers/usb/host/u132-hcd.c:3225: error: ‘ports’ undeclared (first use in this function) ... Signed-off-by:
Mirco Tischler <mt-ml@gmx.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Joonwoo Park authored
The function ebt_do_table doesn't take NF_DROP as a verdict from the targets. Signed-off-by:
Joonwoo Park <joonwpark81@gmail.com> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Pavel Emelyanov authored
Use the added dev_alloc_name() call to create tunnel device name, rather than iterate in a hand-made loop with an artificial limit. Thanks Patrick for noticing this. [ The way this works is, when the device is actually registered, the generic code noticed the '%' in the name and invokes dev_alloc_name() to fully resolve the name. -DaveM ] Signed-off-by:
Pavel Emelyanov <xemul@openvz.org> Signed-off-by:
-
David S. Miller authored
MAC_FMT had only one user and we tried to get rid of that, but this created more problems than it solved. As a result, this reverts three commits: 235365f3 ("net/8021q/vlan_dev.c: Use print_mac."), fea5fa87 ("[NET]: Remove MAC_FMT"), and 8f789c48 ("[NET]: Elminate spurious print_mac() calls.") Signed-off-by:
-
Pavel Emelyanov authored
The neigh_hash_grow() may update the tbl->hash_rnd value, which is used in all tbl->hash callbacks to calculate the hashval. Two lookup routines may race with this, since they call the ->hash callback without the tbl->lock held. Since the hash_rnd is changed with this lock write-locked moving the calls to ->hash under this lock read-locked closes this gap. Signed-off-by:
-
Thomas Graf authored
RTM_NEWLINK allows for already existing links to be modified. For this purpose do_setlink() is called which expects address attributes with a payload length of at least dev->addr_len. This patch adds the necessary validation for the RTM_NEWLINK case. The address length for links to be created is not checked for now as the actual attribute length is used when copying the address to the netdevice structure. It might make sense to report an error if less than addr_len bytes are provided but enforcing this might break drivers trying to be smart with not transmitting all zero addresses. Signed-off-by:
Thomas Graf <tgraf@suug.ch> Signed-off-by:
-
Stephen Hemminger authored
When asked to blink LEDs the tg3 driver behaves when using: ethtool -p ethX The default value for data is zero, and other drivers interpret this as blink forever (or at least a really long time). The tg3 driver interprets this as blink once. All drivers should have the same behaviour. Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Acked-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
-
Michael Chan authored
Signed-off-by:
-
Oliver Pinter authored
Signed-off-by:
Oliver Pinter <oliver.pntr@gmail.com> Signed-off-by:
-
Michael Chan authored
Because of some board issues, we need to disable parallel detect on an HP blade. Without this patch, the link state can become stuck when it goes into parallel detect mode. Signed-off-by:
-
Michael Chan authored
The previous patches to workaround the 5706S on an HP blade were not sufficient. The link state still does not change properly in some cases. This patch adds polling to make it completely reliable. Signed-off-by:
-
Linus Torvalds authored
Oleg Nesterov and others have pointed out that on some architectures, the traditional sequence of set_current_state(TASK_INTERRUPTIBLE); if (CONDITION) return; schedule(); is racy wrt another CPU doing CONDITION = 1; wake_up_process(p); because while set_current_state() has a memory barrier separating setting of the TASK_INTERRUPTIBLE state from reading of the CONDITION variable, there is no such memory barrier on the wakeup side. Now, wake_up_process() does actually take a spinlock before it reads and sets the task state on the waking side, and on x86 (and many other architectures) that spinlock is in fact equivalent to a memory barrier, but that is not generally guaranteed. The write that sets CONDITION could move into the critical region protected by the runqueue spinlock. However, adding a smp_wmb() to before the spinlock should now order the writing of CONDITION wrt the lock itself, which in turn is ordered wrt the accesses within the spinlock (which includes the reading of the old state). This should thus close the race (which probably has never been seen in practice, but since smp_wmb() is a no-op on x86, it's not like this will make anything worse either on the most common architecture where the spinlock already gave the required protection). Acked-by:
Oleg Nesterov <oleg@tv-sign.ru> Acked-by:
Dmitry Adamushko <dmitry.adamushko@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by:
-
Jeff Garzik authored
- Fix build 'make randconfig' build warning spotted by Toralf Foerster: drivers/scsi/mvsas.c: In function 'mvs_hexdump': drivers/scsi/mvsas.c:715: error: implicit declaration of function 'isalnum' - Remove unneeded prototypes (spotted by hch) Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Oleg Nesterov authored
(sorry for being offtpoic, but while experts are here...) A "typical" implementation of atomic_add_unless() can return 0 immediately after the first atomic_read() (before doing cmpxchg). In that case it doesn't provide any barrier semantics. See include/asm-ia64/atomic.h as an example. We should either change the implementation, or fix the docs. Signed-off-by:
Nick Piggin <npiggin@suse.de> Signed-off-by:
-
Li Zefan authored
Cgroup requires the subsystem to return negative error code on error in the create method. Signed-off-by:
Li Zefan <lizf@cn.fujitsu.com> Acked-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Acked-by:
Balbir Singh <balbir@in.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Li Zefan authored
Remove this VM_BUG_ON(), as Balbir stated: We used to have a for loop with !list_empty() as a termination condition and VM_BUG_ON(!pc) is a spill over. With the new loop, VM_BUG_ON(!pc) does not make sense. Signed-off-by:
-
Li Zefan authored
- remove trailing " Bytes"s in the demonstration - remove section 4.4 (feature control_type has been removed) - fix reference section Signed-off-by:
-
Li Zefan authored
Signed-off-by:
Paul Menage <menage@google.com> Signed-off-by:
-
Li Zefan authored
The list head res->tasks gets initialized twice in find_css_set(). Signed-off-by:
-
Li Zefan authored
Cgroup uses unsigned long for subsys bitops, not unsigned long long. Signed-off-by:
-
Li Zefan authored
opts.release_agent is not kfree()ed in all necessary places. Signed-off-by:
-
Li Zefan authored
- replace old name 'cont' with 'cgrp' (Paul Menage did this cleanup for cgroup.c in commit bd89aabc) - remove a duplicate declaration of cgroup_path() Signed-off-by:
-
Li Zefan authored
fix: - comments about need_forkexit_callback - comments about release agent - typo and comment style, etc. Signed-off-by:
-
Li Zefan authored
Misc fixes and updates, make the doc consistent with current cgroup implementation. Signed-off-by:
-
Alexander van Heukelum authored
WARNING: vmlinux.o(.meminit.text+0x649): Section mismatch in reference from the function free_area_init_core() to the function .init.text:setup_usemap() The function __meminit free_area_init_core() references a function __init setup_usemap(). If free_area_init_core is only used by setup_usemap then annotate free_area_init_core with a matching annotation. The warning is covers this stack of functions in mm/page_alloc.c: alloc_bootmem_node must be marked __init. alloc_bootmem_node is used by setup_usemap, if !SPARSEMEM. (usemap_size is only used by setup_usemap, if !SPARSEMEM.) setup_usemap is only used by free_area_init_core. free_area_init_core is only used by free_area_init_node. free_area_init_node is used by: arch/alpha/mm/numa.c: __init paging_init() arch/arm/mm/init.c: __init bootmem_init_node() arch/avr32/mm/init.c: __init paging_init() arch/cris/arch-v10/mm/init.c: __init paging_init() arch/cris/arch-v32/mm/init.c: __init paging_init() arch/m32r/mm/discontig.c: __init zone_sizes_init() arch/m32r/mm/init.c: __init zone_sizes_init() arch/m68k/mm/motorola.c: __init paging_init() arch/m68k/mm/sun3mmu.c: __init paging_init() arch/mips/sgi-ip27/ip27-memory.c: __init paging_init() arch/parisc/mm/init.c: __init paging_init() arch/sparc/mm/srmmu.c: __init srmmu_paging_init() arch/sparc/mm/sun4c.c: __init sun4c_paging_init() arch/sparc64/mm/init.c: __init paging_init() mm/page_alloc.c: __init free_area_init_nodes() mm/page_alloc.c: __init free_area_init() and mm/memory_hotplug.c: hotadd_new_pgdat() hotadd_new_pgdat can not be an __init function, but: It is compiled for MEMORY_HOTPLUG configurations only MEMORY_HOTPLUG depends on SPARSEMEM || X86_64_ACPI_NUMA X86_64_ACPI_NUMA depends on X86_64 ARCH_FLATMEM_ENABLE depends on X86_32 ARCH_DISCONTIGMEM_ENABLE depends on X86_32 So X86_64_ACPI_NUMA implies SPARSEMEM, right? So we can mark the stack of functions __init for !SPARSEMEM, but we must mark them __meminit for SPARSEMEM configurations. This is ok, because then the calls to alloc_bootmem_node are also avoided. Compile-tested on: silly minimal config defconfig x86_32 defconfig x86_64 defconfig x86_64 -HIBERNATION +MEMORY_HOTPLUG Signed-off-by:
Alexander van Heukelum <heukelum@fastmail.fm> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
