We call alloc_page where we should be calling __page_cache_alloc.
__page_cache_alloc performs cpuset memory spreading. alloc_page does not.
There is no reason that pages allocated via find_or_create should be
exempt.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
alpha:
drivers/parport/parport_pc.c: In function 'parport_pc_fifo_write_block_dma':
drivers/parport/parport_pc.c:636: warning: implicit declaration of function 'dma_map_single'
drivers/parport/parport_pc.c:637: error: 'DMA_TO_DEVICE' undeclared (first use in this function)
drivers/parport/parport_pc.c:637: error: (Each undeclared identifier is reported only once
drivers/parport/parport_pc.c:637: error: for each function it appears in.)
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
find_first_zero_bit accepts number of bits, not longs.
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
afs_prepare_write() should not mark a page up to date if it only partially
fills it in, in expectation of the caller filling in the rest prior to calling
commit_write(). commit_write(), however, should mark the page up to date.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
kmem_cache_create() was swapping ctor and dtor in calling find_mergeable():
though it caused no bug, and probably never would, even if destructors are
retained; but fix it so as not to generate anxiety ;)
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Cc: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Sorry I screwed up the comparison. It is only an error if we attempt
to allocate a slab larger than the maximum allowed size.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix AFS to write back dirty on unmounting. This didn't happen because
afs_super_ops.drop_inode was pointing to generic_delete_inode. Now this
pointer is left set to NULL so that the default behaviour occurs instead.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In commit e3c7db621b we fixed the resume
ordering, so that the ACPI low-level resume code was called before the
actual driver resume was called. However, that broke the nesting logic
of suspend and resume, and we continued to suspend the devices _after_
we the ACPI device suspend code was called.
That resulted in us saving PCI state for devices that had already been
changed by ACPI, and in some cases disabled entirely (causing the PCI
save_state to be all-ones). Which in turn caused the wrong state to be
written back on resume.
This moves the ACPI device suspend to after the device model per-device
suspend() calls. This fixes the bogus state save.
Thanks to Lukáš Hejtmánek for testing.
Acked-by: Lukas Hejtmanek <xhejtman@ics.muni.cz>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Get rid of the notifier list and call the kprobes code directly
if compiled in. This mirrors the changes that recently went
into powerpc, s390 and sparc64.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Hypervisor interfaces need to be negotiated in order to use
some API calls reliably. So add a small set of interfaces
to request API versions and query current settings.
This allows us to fix some bugs in the hypervisor console:
1) If we can negotiate API group CORE of at least major 1
minor 1 we can use con_read and con_write which can improve
console performance quite a bit.
2) When we do a console write request, we should hold the
spinlock around the whole request, not a byte at a time.
What would happen is that it's easy for output from
different cpus to get mixed with each other.
3) Use consistent udelay() based polling, udelay(1) each
loop with a limit of 1000 polls to handle stuck hypervisor
console.
Signed-off-by: David S. Miller <davem@davemloft.net>
__NR_syscall_max is done in x86_64 asm-offsets; do an equivalent in
uml kern_constants.h
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
it depends on elimination of unreachable branches in switch (by object
size), so we must declare it always_inline
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Hirokazu Takata <takata@linux-m32r.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
.. because video-buf.c requires PCI, and VIDEO_EM28XX selects it.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
end up with unbuildable configs.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
need it for page_private(), not all targets have it pulled indirectly
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* master.kernel.org:/pub/scm/linux/kernel/git/bart/ide-2.6:
Use menuconfig objects: IDE
sl82c105: Switch to ref counting API
ide: remove ide_use_dma()
ide: add missing validity checks for identify words 62 and 63
ide: remove ide_dma_enable()
sl82c105: add speedproc() method and MWDMA0/1 support
cs5530/sc1200: add ->speedproc support
cs5530/sc1200: DMA support cleanup
ide: use ide_tune_dma() part #2
cs5530/sc1200: add ->udma_filter methods
ide: always disable DMA before tuning it
pdc202xx_new: use ide_tune_dma()
alim15x3: use ide_tune_dma()
sis5513: PIO mode setup fixes
serverworks: PIO mode setup fixes
pdc202xx_old: rewrite mode programming code (v2)
It's not necessarily a very sane configuration, but people running "make
randconfig" noticed it wouldn't compile. This fixes some obvious
problems in discontig.c to allow a clean compile.
Acked-by: andrew hendry <andrew.hendry@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Use menuconfigs instead of menus, so the whole menu can be disabled at once
instead of going through all options.
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Not sure how this one got missed in the great purge some time ago but it did.
Signed-off-by: Alan Cox <alan@redhat.com>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
ide_use_dma() duplicates a lot of ide_max_dma_mode() functionality
and as all users of ide_use_dma() were converted to use ide_tune_dma()
now it is possible to add missing checks to ide_tune_dma() and remove
ide_use_dma() completely, so do it.
There should be no functionality changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* check ->speedproc return value in ide_tune_dma()
* use ide_tune_dma() in cmd64x/cs5530/sc1200/siimage/sl82c105/scc_pata drivers
* remove no longer needed ide_dma_enable()
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Add the speedproc() method for setting transfer modes, modify config_for_dma()
to call it and use ide_max_dma_mode() to select the best DMA mode.
Add support for the multiword DMA modes 0 and 1, using the upper half of the
'drive_data' field to store the DMA timings to program into the drive control
register when DMA is turned on for real.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* add {cs5530,sc1200}_tunepio() for programming PIO timings
* add {cs5530,sc1200}_tune_chipset() (->speedproc method) for setting
transfer mode and convert {cs5530,sc1200}_config_dma() to use it
* bump driver version
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
sc1200.c:
* remove open-coded variant of ide_dma_host_off() (== ->dma_host_off),
it is not needed because ->dma_off_quietly calls ->dma_host_off
* use ->dma_host_on (== ide_dma_host_on() for this driver) instead of
open-coded variant, call it from the users of sc1200_config_dma2()
[ there is no need to call ->dma_host_on in sc1200_config_dma() because
core code takes care of calling ->ide_dma_on on successful execution
of ->ide_dma_check ]
* add comment about ->tuneproc interface abuse
cs5530.c/sc1200.c:
* core code takes care of calling ->dma_off_quietly before calling
->ide_dma_check so there is no need to call it in ->ide_dma_check methods
* bump driver version
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
CS5530/SC1200 specifies that two drives on the same cable cannot mix
UDMA/MDMA. Add {cs5530,sc1200}_udma_filter() to handle this. This also
makes it possible to remove open-coded best DMA mode selection and use
standard ide_use_dma()/ide_max_dma_mode() helpers. While at it bump
version numbers.
There should be no functionality changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
ide_start_power_step() and set_using_dma() were missing ->dma_off_quietly
call (comment in probe_hwif() states that DMA should be always cleared before
tuning is attempted). Fix it.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* remove code enabling IORDY and prefetch from config_chipset_for_dma(),
as the comment states it has no real effect because these settings are
overriden when the PIO mode is set (and for this driver ->autotune == 1
so PIO mode is always programmed)
* use ide_tune_dma() in pdcnew_config_drive_xfer_rate() and remove no longer
needed config_chipset_for_dma()
There should be no functionality changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Use ide_tune_dma() in ali15x3_config_drive_for_dma() and remove all the open
coded DMA tuning code and also config_chipset_for_dma(). Set ->atapi_dma flag
correctly in init_hwif_common_ali15x3() so ide_tune_dma() can take care of
checking if ATAPI DMA is allowed and remove open coded ATAPI DMA check from
ali15x3_config_drive_for_dma().
There should be no functionality changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* limit max PIO mode to PIO4, this driver doesn't support PIO5 and attempt
to program PIO5 by config_art_rwp_pio() could result in incorrect PIO
timings being programmed and possibly the data corruption (for < ATA100
family chipsets PIO0 timings were used, for ATA100 and ATA100a - the random
content of test1 variable was used, for ATA133 - MWDMA0 timings were used)
* BUG() in sis5513_tune_chipset() if somebody tries to force unsupported PIO5,
also cleanup this function a bit while at it
* add comment about PIO0 timings for < ATA100 family chipsets
* remove open-coded best PIO mode selection from config_art_rwp_pio(),
it contained numerous bugs:
- it didn't check for validity of id->eide_pio_modes and id->eide_pio_iordy
before using them
- it tried to found out maximum PIO mode basing on minimum IORDY cycle time
(moreover wrong cycle times were used for PIO1/5)
- it was overriding PIO blacklist and conservative PIO "downgrade" done
by ide_get_best_pio_mode()
* use sis5513_tune_drive() instead of config_art_rwp_pio()
in sis5513_config_xfer_rate() so the correct PIO mode is also set
on drive even if the device is not IORDY/DMA capable
* config_art_rwp_pio() was always setting the best possible mode and not
the wanted one - fix it and move ide_get_best_pio_mode() call to
config_chipset_for_pio()
* don't use ide_find_best_mode() in config_chipset_for_pio(), it was being
overriden by config_art_rwp_pio() for the host timings anyway + we need to
set the same PIO mode on the device and the host
* pass correct "pio" argument (255 instead of 5) to sis5513_tune_drive() call
in sis5513_config_xfer_rate() so the best PIO mode is set on the drive
and not PIO4
* rename sis5513_tune_drive() to sis5513_tuneproc()
and config_chipset_for_pio() to sis5513_tune_driver()
* bump driver version
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* limit max PIO mode to PIO4, this driver doesn't support PIO5 and attempt
to program PIO5 by svwks_tune_chipset() could result in incorrect PIO
timings being programmed and possibly the data corruption (it seems that
the minimum possible values were used but I lack the datasheets to be sure)
* select best PIO mode in svwks_tune_drive() and not in svwks_tune_chipset()
when doing PIO autotuning (pio == 255)
* don't try to tune PIO in config_chipset_for_dma() as ide_dma_enable() could
return 1 if DMA was previously enabled (svwks_config_drive_xfer_rate()
takes care of PIO tuning if no suitable DMA mode is found)
* remove config_chipset_for_pio() and use svwks_tune_drive() instead,
config_chipset_for_pio() contained numerous bugs when selecting PIO mode
(luckily it was only used for devices limited to PIO by capabilities/BIOS):
- it didn't check for validity of id->eide_pio_modes and id->eide_pio_iordy
before using them
- it tried to found out maximum PIO mode basing on minimum IORDY cycle time
(moreover wrong cycle times were used for PIO0/1/5)
- it was overriding PIO blacklist and conservative PIO "downgrade" done
by ide_get_best_pio_mode()
- if the max drive PIO was PIO5 then XFER_PIO_0/XFER_PIO_SLOW was selected
(XFER_PIO_SLOW is not supported by svwks_tune_chipset() so the result
was the same as if using XFER_PIO_5 => wrong PIO timings were set)
- it was overriding drive->current_speed
* bump driver version
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
This patch is based on the documentation (I would like to thank Promise
for it) and also partially on the older vendor driver.
Rewrite mode programming code:
* disable 66MHz clock in pdc202xx_tune_chipset() so it is correctly disabled
even if both devices on the channel are not DMA capable and after reset
* enable/disable IORDY and PREFETCH bits in pdc202xx_tune_chipset()
as they need to be setup correctly also for PIO only devices, plus IORDY
wasn't disabled for non-IORDY devices and PREFETCH wasn't disabled for
ATAPI devices
* remove dead code for setting SYNC_ERDDY_EN bits from config_chipset_for_dma()
(driver sets ->autotune to 1 so PIO modes are always programmed => lower
nibble of register A never equals 4 => "chipset_is_set" is always true)
* enable PIO mode programming for all ATAPI devices
(it was limited to ->media == ide_cdrom devices)
* remove extra reads of registers A/B/C, don't read register D et all
* do clearing / programming of registers A/B/C in one go
(gets rid of extra PCI config space read/write cycle)
* set initial values of drive_conf/AP/BP/CP variables to zero
(paranoia for the case when PCI reads fail)
* remove XFER_UDMA6 to XFER_UDMA5 remapping case - it can't happen
(ide_rate_filter() takes care of it)
* fix XFER_MW_DMA0 timings (they were overclocked, use the official ones)
* fix bitmasks for clearing bits of register B:
- when programming DMA mode bit 0x10 of register B was cleared which
resulted in overclocked PIO timing setting (iff PIO0 was used)
- when programming PIO mode bits 0x18 weren't cleared so suboptimal
timings were used for PIO1-4 if PIO0 was previously set (bit 0x10)
and for PIO0/3/4 if PIO1/2 was previously set (bit 0x08)
* add FIXME comment about missing locking for 66MHz clock register
Also while at it:
* remove unused defines
* do a few cosmetic / CodingStyle fixes
* bump driver version
v2:
* in pdc202xx_tune_chipset() the old content of drive configuration
registers is used only by the debugging code so cover "drive_conf"
PCI registers read by #if PDC202XX_DEBUG_DRIVE_INFO
(Noticed by Sergei Shtylyov)
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
It was agreed that phy-connection-type was a better name for
the interface-type property, so this patch renames it.
Also, the max-speed property name was determined too generic,
and is therefore eliminated in favour of phy-connection-type
derivation logic.
includes corrections to copyright text.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Looks like the new version of this patch has been overlooked,
so I'm resending it.
It just adapts the driver to the new IRQ API
according to what Russell has pointed out.
drivers/net/smc911x.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Turns out we have an old version of firmware that stores the mac address
in 'mac-address' as a string instead of a byte array. All versions that
use local-mac-address should have it as byte array, so no need to do
string parsing for that case.
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
This caused some very interesting behaviour depending on what happened to
be built at the same time. Add terminating empty entry to the list of IDs.
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Interrupt ack fixes
Fix the packet count resets at interrupt time, using the cacheable
packet count status to set number of processed/received packets, since
the ack count is the cumulative number of packets processed, and not
incremental.
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Some shift values were obviously wrong. Fix them to correspond with
the masks.
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Building with GCC 4.2, I get the following error:
CC arch/ia64/kernel/mca.o
arch/ia64/kernel/mca.c:275: error: __ksymtab_ia64_mlogbuf_finish causes a
section type conflict
This is because ia64_mlogbuf_finish is both declared static and exported.
Fix by removing the export (which is unneeded now).
Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
