Clean up mdio_read routines in 3c59x.c to use the MII_* macros defined in
include/linux/mii.h
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Convert 3c59x driver to use pci_iomap API. This makes it easier to enable
the use of memory-mapped PCI I/O resources.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Chen noticed that cache_reap uses REAPTIMEOUT_CPUC+smp_processor_id() as
the timeout for rescheduling.
The "+smp_processor_id()" part is wrong, the timeout should be identical
for all cpus: start_cpu_timer already adds a cpu dependant offset to avoid
any clustering.
The attached patch removes smp_processor_id().
Signed-Off-By: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch renames struct kmem_cache_s to kmem_cache so we can start using
it instead of kmem_cache_t typedef.
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
slab presently goes BUG if someone tries to register an already-registered
cache.
But this can happen if the user accidentally loads a module which is already
statically linked into the kernel. Nuking the kernel is rather a harsh
reaction.
Change it into a warning, and just fail the kmem_cache_alloc() attempt. If
the module is well-behaved, the modprobe will fail and all is well.
Notes:
- Swaps the ranking of cache_chain_sem and lock_cpu_hotplug(). Doesn't seem
important.
Acked-by: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
!unlikely(expr) hurts my brain. likely(!expr) is more straightforward.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Oops, some last minute changes caused the 64K pages patch to break ppc32
build, this fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The zImage wrapper has a bug where it doesn't claim() the memory for the
kernel properly, it forgets to take into account the offset between the ELF
header and the kernel itself. This results on some machines, like G5s,
into a kernel that crashes at boot when clearing the BSS.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Suppress split ptlock on arches which may use one page for multiple page
tables. Reconsider what better to do (particularly on ppc64) later on.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Two CONFIG_SMP=n build fixes due to missing <asm/smp.h> includes.
Signed-off-by: Olof Johansson <olof@lixom.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The current ia64 implementation of dma_get_cache_alignment does not work
for modules because it relies on a symbol which is not exported. Direct
access to a global is a little ugly anyway, so this patch re-implements
dma_get_cache_alignment in a manner similar to what is currently used for
x86_64.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
A typo fix for fix-build-on-nls-free-systems.patch that caused all systems
to be detected as not having NLS.
Signed-off-by: Yuri Vasilevski <yvasilev@duke.math.cinvestav.mx>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch, however, should be applied on top of the 64k-page-size patch to
fix some problems with hugepage (some pre-existing, another introduced by
this patch).
The patch fixes a bug in the SLB miss handler for hugepages on ppc64
introduced by the dynamic hugepage patch (commit id
c594adad56) due to a misunderstanding of the
srd instruction's behaviour (mea culpa). The problem arises when a 64-bit
process maps some hugepages in the low 4GB of the address space (unusual).
In this case, as well as the 256M segment in question being marked for
hugepages, other segments at 32G intervals will be incorrectly marked for
hugepages.
In the process, this patch tweaks the semantics of the hugepage bitmaps to
be more sensible. Previously, an address below 4G was marked for hugepages
if the appropriate segment bit in the "low areas" bitmask was set *or* if
the low bit in the "high areas" bitmap was set (which would mark all
addresses below 1TB for hugepage). With this patch, any given address is
governed by a single bitmap. Addresses below 4GB are marked for hugepage
if and only if their bit is set in the "low areas" bitmap (256M
granularity). Addresses between 4GB and 1TB are marked for hugepage iff
the low bit in the "high areas" bitmap is set. Higher addresses are marked
for hugepage iff their bit in the "high areas" bitmap is set (1TB
granularity).
To avoid conflicts, this patch must be applied on top of BenH's pending
patch for 64k base page size [0]. As such, this patch also addresses a
hugepage problem introduced by that patch. That patch allows hugepages of
1MB in size on hardware which supports it, however, that won't work when
using 4k pages (4 level pagetable), because in that case hugepage PTEs are
stored at the PMD level, and each PMD entry maps 2MB. This patch simply
disallows hugepages in that case (we can do something cleverer to re-enable
them some other day).
Built, booted, and a handful of hugepage related tests passed on POWER5
LPAR (both ARCH=powerpc and ARCH=ppc64).
[0] http://gate.crashing.org/~benh/ppc64-64k-pages.diff
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Adds a new CONFIG_PPC_64K_PAGES which, when enabled, changes the kernel
base page size to 64K. The resulting kernel still boots on any
hardware. On current machines with 4K pages support only, the kernel
will maintain 16 "subpages" for each 64K page transparently.
Note that while real 64K capable HW has been tested, the current patch
will not enable it yet as such hardware is not released yet, and I'm
still verifying with the firmware architects the proper to get the
information from the newer hypervisors.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
glibc expects to count lines beginning with "processor" to determine
the number of processors, not lines beginning with "Processor". So,
give glibc the format it expects.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
We don't want to call dump_cpu_info() from cpu_init() after boot since
it produces a lot of unnecessary noise - since cpu_init() gets called
on resume and hotplug cpu insertion events.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Richard Purdie
Update the PXA pm.c file to allow machines (such as the Sharp
Zaurus) to override the standard pm functions but reuse/wrap them
where needed.
The init call is made slightly earlier to give machine code an init
level to override them in removing any race.
Signed-off-by: Richard Purdie
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Nicolas Pitre
Since we know the value of cpsr on entry, we can replace the bic+orr with
a single eor. Also remove a possible result delay (at least on XScale).
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Lennert Buytenhek
Make the uengine loader use ixp2000_reg_wrb in the right places.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Alessandro Zummo
This patch fixes AHB/PCI endianness problems when the
processor is in little-endian mode.
The patch configures the CSR register closely following the directives
in [1], paragraph 4.1, page 19.
According to the considerations in [1], page 11, while the AHB bus
supports both endian modes, on the IXP4XX it always uses big-endian.
The PCI bus is connected to the South AHB. A wrong setting in the CSR
register will thus cause a malfunctional PCI bus.
A schematic diagram of the bus interconnections on the IXP4XX
can be found in [1], page 18.
The patch has been verified to work on the NSLU2 in
both LE and BE modes.
The author is Peter Korsgaard.
[1] Intel IXP4XX Product Line of Network Processors and IXC1100
Control Plane Processor:
Understanding Big Endian and Little Endian Modes
http://www.intel.com/design/network/applnots/25423701.pdf
Signed-off-by: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Deepak Saxena <dsaxena@plexity.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Dirk Opfer
This patch adds basic machine support for the Sharp SL-6000x (Tosa) PDAs.
Signed-off-by: Dirk Opfer
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
From: Than Ngo <than@redhat.com>
qt as installed on fedora core (2 and 3) does not work with vanilla
kernel. The linker fails to locate the qt lib:
Actual Results: # make xconfig
HOSTLD scripts/kconfig/qconf
/usr/bin/ld: cannot find -lqt
collect2: ld returned 1 exit status
Than Ngo has provided following fix for the bug.
Cc: Than Ngo <than@redhat.com>
Acked-by: Dave Jones <davej@redhat.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Include autoconf.h into every kernel compilation via the gcc command line
using -imacros. This ensures that we have the kernel configuration
included from the start, rather than relying on each file having #include
<linux/config.h> as appropriate. History has shown that this is something
which is difficult to get right.
Since we now include the kernel configuration automatically, make
configcheck becomes meaningless, so remove it.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
The offsets of the registers are in a different place, and
some parts cannot handle a full set of modem control signals.
Signed-off-by: Pantelis Antoniou <pantelis@embeddedalley.ocm>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
my patch "x86: initialise tss->io_bitmap_owner to something" (commit ID
d5cd4aadd3) introduced a problem with a
program (DOSEMU) that called ioperm after already doing some port i/o.
The problem is that a process switch return causes tss->io_bitmap_base
to be set to IO_BITMAP_OFFSET so that the fault (that *really* sets the
io bitmap) never triggers.
This fixes that regression.
Signed-off-by: Bart Oldeman <bartoldeman@users.sourceforge.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Some visually impaired people use hardware devices which directly read
the vga screen. When newt for instance asks to hide the cursor for
better visual aspect, the kernel puts the vga cursor out of the screen,
so that the cursor position can't be read by the hardware device. This
is a great loss for such people.
Here is a patch which uses the same technique as CUR_NONE for hiding the
cursor while still moving it.
Mario, you should apply it to the speakup kernel for access floppies
asap. I'll submit a 2.4 patch too.
Signed-off-by: samuel.thibault@ens-lyon.org
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Statically allocated devices in module data is a potential cause
of oopsen. The device may be in use by a userspace process, which
will keep a reference to the device. If the module is unloaded,
the module data will be freed. Subsequent use of the platform
device will cause a kernel oops.
Use generic platform device allocation/release code in modules.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Statically allocated devices in module data is a potential cause
of oopsen. The device may be in use by a userspace process, which
will keep a reference to the device. If the module is unloaded,
the module data will be freed. Subsequent use of the platform
device will cause a kernel oops.
Use generic platform device allocation/release code in modules.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Release code in driver modules is a potential cause of oopsen.
The device may be in use by a userspace process, which will keep
a reference to the device. If the module is unloaded, the module
text will be freed. Subsequently, when the last reference is
dropped, the release code will be called, which no longer exists.
Use generic platform device allocation/release code in modules.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Release code in driver modules is a potential cause of oopsen.
The device may be in use by a userspace process, which will keep
a reference to the device. If the module is unloaded, the module
text will be freed. Subsequently, when the last reference is
dropped, the release code will be called, which no longer exists.
Use generic platform device allocation/release code in modules.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Release code in driver modules is a potential cause of oopsen.
The device may be in use by a userspace process, which will keep
a reference to the device. If the module is unloaded, the module
text will be freed. Subsequently, when the last reference is
dropped, the release code will be called, which no longer exists.
Use generic platform device allocation/release code in modules.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Release code in driver modules is a potential cause of oopsen.
The device may be in use by a userspace process, which will keep
a reference to the device. If the module is unloaded, the module
text will be freed. Subsequently, when the last reference is
dropped, the release code will be called, which no longer exists.
Use generic platform device allocation/release code in modules.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Re-jig the simple platform device support to allow private data
to be attached to a platform device, as well as allowing the
parent device to be set.
Example usage:
pdev = platform_device_alloc("mydev", id);
if (pdev) {
err = platform_device_add_resources(pdev, &resources,
ARRAY_SIZE(resources));
if (err == 0)
err = platform_device_add_data(pdev, &platform_data,
sizeof(platform_data));
if (err == 0)
err = platform_device_add(pdev);
} else {
err = -ENOMEM;
}
if (err)
platform_device_put(pdev);
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Adds a phy_mask field to struct mii_bus and uses it. This field
indicates each phy address to be ignored when probing the mdio bus.
This support is needed for the fs_enet and ibm_emac drivers to be
converted to the generic phy layer among other drivers. Many systems
lock up on probing certain phy addresses or probing doesn't return
0xffff when nothing is found at the address. A new driver I'm
working on also makes use of this mask.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Some boards using the 79c976 pcnet32 chip will hang the system if the
ethtool --register-dump is performed with the device operational. The
request to read bcr30 is retried by the PCI device infinitely without
returning data, hanging the system.
Tested ia32 and ppc64.
Signed-off-by: Don Fry <brazilnut@us.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
This patch is a better fix for Allied Telesyn 2700/2701 FX boards than
the change made in early January this year. It allows the user to
select the speed/duplex via module_param, but if no selection is made,
forces the speed to 100 FD. It fixes both Bugzilla bugs 2669 and 4551.
Tested ia32 and ppc64 by myself, and by the originator of bug 2669.
Signed-off-by: Don Fry <brazilnut@us.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Display the name eth%d or pci_name() of device which fails to allocate
memory. When changing ring size via ethtool, it also releases the
lock before returning on error. Added comment that the caller of
pcnet32_alloc_ring must call pcnet32_free_ring on error, to avoid leak.
Tested ia32 by forcing allocation errors.
Signed-off-by: Don Fry <brazilnut@us.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Hi,
This patch provides updated documentation on the Neterion(S2io) driver.
Please review the patch.
Signed-off-by: Ravinandan Arakali <ravinandan.arakali@neterion.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Hi,
This patch provides dynamic two buffer-mode and 3 buffer-mode options.
Previously 2 buffer-mode was compilation option. Now with this patch applied
one can load driver in 2 buffer-mode with module-load parameter
ie.
#insmod s2io.ko rx_ring_mode=2
This patch also provides 3 buffer-mode which provides header separation
functionality. In 3 buffer-mode skb->data will have L2/L3/L4 headers and
"skb_shinfo(skb)->frag_list->data" will have have L4 payload.
one can load driver in 3 buffer-mode with same above module-load parameter
ie.
#insmod s2io.ko rx_ring_mode=3
Please review the patch.
Signed-off-by: Ananda Raju <ananda.raju@neterion.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
fid is declared as a u32 (unsigned int), and then a few lines later, it is checked for a value < 0, which is clearly useless.
In the two locations this function is used, in one it is *explicitly* given a negative number, which would be ignored with the
current definition.
Thanks to LinuxICC (http://linuxicc.sf.net).
Signed-off-by: Gabriel A. Devenyi <ace@staticwave.ca>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
