Kevin Hilman [Wed, 19 Mar 2008 22:47:05 +0000 (15:47 -0700)]
ARM: OMAP: HSMMC: enable use as a module
When building as a module, the board support code (which is compiled
in) cannot directly call the driver code (which may be in a module.)
This patch the separates the card-detect IRQ usage into board-specific
code and driver code, and adds a couple slot-specific items to the MMC
platform data.
Tested on 3430SDP ES2.
Signed-off-by: Kevin Hilman <khilman@mvista.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
CC arch/arm/mach-omap2/pm.o
arch/arm/mach-omap2/pm.c: In function 'omap2_pm_init':
arch/arm/mach-omap2/pm.c:840: warning: passing argument 2 of 'sysfs_create_file' from incompatible pointer type
Signed-off-by: Carlos Eduardo Aguiar <carlos.aguiar@indt.org.br> Signed-off-by: Tony Lindgren <tony@atomide.com>
These changes is the result of the discussion with Paul Walmsley.
His ideas are included into this patch.
Remove DPLL output divider handling from DPLLs and CLKOUTX2 clocks,
and place it into specific DPLL output divider clocks (e.g., dpll3_m2_clk).
omap2_get_dpll_rate() now returns the correct DPLL rate, as represented
by the DPLL's CLKOUT output. Also add MPU and IVA2 subsystem clocks, along
with high-frequency bypass support.
Add support for DPLLs function in locked and bypass clock modes.
Signed-off-by: Roman Tereshonkov <roman.tereshonkov@nokia.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Hiroshi DOYU [Tue, 18 Mar 2008 10:28:40 +0000 (12:28 +0200)]
OMAP: MMU: Fix inconsistency to unregister device MMU
There was a problem that kernel counldn't find struct device for
device MMU when unregistering it for class. This is because device
MMUs are the pseudo devices and they were not created when registering
into MMU class. This patch will create struct device when registering
device MMU into class and will fix the problem that "dspctl cleanup"
encountered kernel Oops.
Signed-off-by: Hiroshi DOYU <Hiroshi.DOYU@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Jarkko Nikula [Mon, 17 Mar 2008 15:01:10 +0000 (17:01 +0200)]
ARM: OMAP: DMA: Fix incorrect channel linking
Function enable_lnk does incorrect channel link on non-omap1 builds if chain
is created manually with omap_request_dma and omap_dma_link_lch functions.
Fix this by making sure that next_linked_ch field is initialized to -1 just
in omap_request_dma.
Signed-off-by: Jarkko Nikula <jarkko.nikula@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Helge Deller [Wed, 26 Dec 2007 17:07:01 +0000 (18:07 +0100)]
[PARISC] head.S: section mismatch fixes
- move boot_args[] into the init section
- move $global$ into the read_mostly section
- fix the following two section mismatches:
WARNING: vmlinux.o(.text+0x9c): Section mismatch: reference to .init.text:start_kernel (between '$pgt_fill_loop' and '$is_pa20')
WARNING: vmlinux.o(.text+0xa0): Section mismatch: reference to .init.text:start_kernel (between '$pgt_fill_loop' and '$is_pa20')
This is bogus on parisc, since page zero in kernel virtual space is the
gateway page for syscall entry, and should not be read from the kernel.
(That, and we really don't like the kernel faulting on its own address
space...)
Kyle McMartin [Sat, 1 Mar 2008 18:30:19 +0000 (10:30 -0800)]
[PARISC] clean up show_stack
When we show_regs, we obviously have a struct pt_regs of the calling
frame. Use these in show_stack so we don't have the entire bogus call trace
up to the show_stack call.
Adrian Bunk [Tue, 26 Feb 2008 19:55:17 +0000 (21:55 +0200)]
[PARISC] move defconfig to arch/parisc/configs/
This patch moves the default parisc defconfig to
arch/parisc/configs/generic_defconfig where it belongs and selects it as
the default defconfig through KBUILD_DEFCONFIG.
Signed-off-by: Adrian Bunk <adrian.bunk@movial.fi> Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
Kyle McMartin [Tue, 19 Feb 2008 07:34:34 +0000 (23:34 -0800)]
[PARISC] pdc_console: fix bizarre panic on boot
Commit 721fdf34167580ff98263c74cead8871d76936e6 introduced a subtle bug
by accidently removing the "static" from iodc_dbuf. This resulted in, what
appeared to be, a trap without *current set to a task. Probably the result of
a trap in real mode while calling firmware.
Also do other misc clean ups. Since the only input from firmware is non
blocking, share iodc_dbuf between input and output, and spinlock the
only callers.
Kyle McMartin [Tue, 19 Feb 2008 07:26:46 +0000 (23:26 -0800)]
[PARISC] dump_stack in show_regs
Originally, show_stack was used in BUG() output. However, a recent commit
changed it to print register state (no idea what that's supposed to help,
really...) and parisc was missing a backtrace because of it.
It did ugly things to the init sequence to populate the rootfs image
early, but that just ended up showing other problems with the whole
approach. The fact is, the VFS layer simply isn't initialized this
early, and the relevant ACPI code should either run much later, or this
shouldn't be done at all.
For 2.6.25, we'll just pick the latter option. We can revisit this
concept later if necessary.
Cc: Dave Hansen <haveblue@us.ibm.com> Cc: Tilman Schmidt <tilman@imap.cc> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Thomas Renninger <trenn@suse.de> Cc: Eric Piel <eric.piel@tremplin-utc.net> Cc: Len Brown <len.brown@intel.com> Cc: Christoph Hellwig <hch@infradead.org> Cc: Markus Gaugusch <dsdt@gaugusch.at> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Ingo Molnar [Fri, 14 Mar 2008 21:17:08 +0000 (22:17 +0100)]
sched: simplify sched_slice()
Use the existing calc_delta_mine() calculation for sched_slice(). This
saves a divide and simplifies the code because we share it with the
other /cfs_rq->load users.
It also improves code size:
text data bss dec hex filename
42659 2740 144 45543 b1e7 sched.o.before
42093 2740 144 44977 afb1 sched.o.after
Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Peter Zijlstra [Fri, 14 Mar 2008 20:12:12 +0000 (21:12 +0100)]
sched: fix overload performance: buddy wakeups
Currently we schedule to the leftmost task in the runqueue. When the
runtimes are very short because of some server/client ping-pong,
especially in over-saturated workloads, this will cycle through all
tasks trashing the cache.
Reduce cache trashing by keeping dependent tasks together by running
newly woken tasks first. However, by not running the leftmost task first
we could starve tasks because the wakee can gain unlimited runtime.
Therefore we only run the wakee if its within a small
(wakeup_granularity) window of the leftmost task. This preserves
fairness, but does alternate server/client task groups.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Peter Zijlstra [Fri, 14 Mar 2008 19:55:51 +0000 (20:55 +0100)]
sched: min_vruntime fix
Current min_vruntime tracking is incorrect and will cause serious
problems when we don't run the leftmost task for some reason.
min_vruntime does two things; 1) it's used to determine a forward
direction when the u64 vruntime wraps, 2) it's used to track the
leftmost vruntime to position newly enqueued tasks from.
The current logic advances min_vruntime whenever the current task's
vruntime advance. Because the current task may pass the leftmost task
still waiting we're failing the second goal. This causes new tasks to be
placed too far ahead and thus penalizes their runtime.
Fix this by making min_vruntime the min_vruntime of the waiting tasks by
tracking it in enqueue/dequeue, and compare against current's vruntime
to obtain the absolute minimum when placing new tasks.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Fix a hard to trigger crash seen in the -rt kernel that also affects
the vanilla scheduler.
There is a race condition between schedule() and some dequeue/enqueue
functions; rt_mutex_setprio(), __setscheduler() and sched_move_task().
When scheduling to idle, idle_balance() is called to pull tasks from
other busy processor. It might drop the rq lock. It means that those 3
functions encounter on_rq=0 and running=1. The current task should be
put when running.
The current process of CPU1(P1) is scheduling. Deactivated P1, and the
scheduler looks for another process on other CPU's runqueue because CPU1
will be idle. idle_balance(), load_balance_newidle() and
double_lock_balance() are called and double_lock_balance() could drop
the rq lock. On the other hand, CPU0 is trying to boost the priority of
P1. The result of boosting only P1's prio and sched_class are changed to
RT. The sched entities of P1 and P1's group are never put. It makes
cfs_rq invalid, because the cfs_rq has curr and no leaf, but
pick_next_task_fair() is called, then the kernel panics.
J. Bruce Fields [Fri, 14 Mar 2008 23:37:11 +0000 (19:37 -0400)]
nfsd: fix oops on access from high-numbered ports
This bug was always here, but before my commit 6fa02839bf9412e18e77
("recheck for secure ports in fh_verify"), it could only be triggered by
failure of a kmalloc(). After that commit it could be triggered by a
client making a request from a non-reserved port for access to an export
marked "secure". (Exports are "secure" by default.)
The result is a struct svc_export with a reference count one too low,
resulting in likely oopses next time the export is accessed.
The reference counting here is not straightforward; a later patch will
clean up fh_verify().
Thanks to Lukas Hejtmanek for the bug report and followup.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Cc: Lukas Hejtmanek <xhejtman@ics.muni.cz> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Jarod Wilson [Wed, 12 Mar 2008 21:43:26 +0000 (17:43 -0400)]
firewire: fw-ohci: use dma_alloc_coherent for ar_buffer
Currently, we do nothing to guarantee we have a consistent DMA buffer for
asynchronous receive packets. Rather than doing several sync's following a
dma_map_single() to get consistent buffers, just switch to using
dma_alloc_coherent().
Resolves constant buffer failures on my own x86_64 laptop w/4GB of RAM and
likely to fix a number of other failures witnessed on x86_64 systems with
4GB of RAM or more.
Signed-off-by: Jarod Wilson <jwilson@redhat.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Stefan Richter [Tue, 11 Mar 2008 21:32:52 +0000 (22:32 +0100)]
ieee1394: sbp2: fix for SYM13FW500 bridge (Datafab disk)
Fix I/O errors due to SYM13FW500's inability to handle larger request
sizes. Reported by Piergiorgio Sartor <piergiorgio.sartor@nexgo.de> for
firewire-sbp2 in https://bugzilla.redhat.com/show_bug.cgi?id=436879
This fix is necessary because sbp2's default request size limit has been
lifted since 2.6.25-rc1.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Jarod Wilson <jwilson@redhat.com>
Stefan Richter [Tue, 11 Mar 2008 21:32:03 +0000 (22:32 +0100)]
firewire: fw-sbp2: fix for SYM13FW500 bridge (Datafab disk)
Fix I/O errors due to SYM13FW500's inability to handle larger request
sizes. Reported by Piergiorgio Sartor <piergiorgio.sartor@nexgo.de> in
https://bugzilla.redhat.com/show_bug.cgi?id=436879
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Jarod Wilson <jwilson@redhat.com>
Jarod Wilson [Fri, 7 Mar 2008 06:43:01 +0000 (01:43 -0500)]
firewire: fw-sbp2: set single-phase retry_limit
Per the SBP-2 specification, all SBP-2 target devices must have a BUSY_TIMEOUT
register. Per the 1394-1995 specification, the retry_limt portion of the
register should be set to 0x0 initially, and set on the target by a logged in
initiator (i.e., a Linux host w/firewire controller(s)).
Well, as it turns out, lots of devices these days have actually moved on to
starting to implement SBP-3 compliance, which says that retry_limit should
default to 0xf instead (yes, SBP-3 stomps directly on 1394-1995, oops).
Prior to this change, the firewire driver stack didn't touch retry_limit, and
any SBP-3 compliant device worked fine, while SBP-2 compliant ones were unable
to retransmit when the host returned an ack_busy_X, which resulted in stalled
out I/O, eventually causing the SCSI layer to give up and offline the device.
The simple fix is for us to set retry_limit to 0xf in the register for all
devices (which actually matches what the old ieee1394 stack did).
Prior to this change, a hard disk behind an SBP-2 Prolific PL-3507 bridge chip
would routinely encounter buffer I/O errors and wind up offlined by the SCSI
layer. With this change, I've encountered zero I/O failures moving tens of GB
of data around.
Signed-off-by: Jarod Wilson <jwilson@redhat.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Stefan Richter [Sat, 1 Mar 2008 01:42:56 +0000 (02:42 +0100)]
firewire: fw-ohci: PPC PMac platform code
Copied from ohci1394.c. This code is necessary to prevent machine check
exceptions when reloading or resuming the driver.
Tested on a 1st generation PowerBook G4 Titanium, which also needs the
pci_probe() hunk.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
I was able to reproduce the system exception on resume with a 3rd-gen
Titanium PowerBook G4 667, and this patch does let the system resume
successfully now.
Not quite clear if there was possibly an updated version coming using
pci_enable_device() instead of the pair of pmac_call_feature() calls,
but either way, this is a definite must-have, at least for older ppc
macs -- my Aluminum PowerBook G4/1.67 suspends and resumes without this
patch just fine.
Signed-off-by: Jarod Wilson <jwilson@redhat.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Stefan Richter [Sat, 23 Feb 2008 11:24:57 +0000 (12:24 +0100)]
firewire: endianess annotations
Kills warnings from 'make C=1 CHECKFLAGS="-D__CHECK_ENDIAN__" modules':
drivers/firewire/fw-transaction.c:771:10: warning: incorrect type in assignment (different base types)
drivers/firewire/fw-transaction.c:771:10: expected unsigned int [unsigned] [usertype] <noident>
drivers/firewire/fw-transaction.c:771:10: got restricted unsigned int [usertype] <noident>
drivers/firewire/fw-transaction.h:93:10: warning: incorrect type in assignment (different base types)
drivers/firewire/fw-transaction.h:93:10: expected unsigned int [unsigned] [usertype] <noident>
drivers/firewire/fw-transaction.h:93:10: got restricted unsigned int [usertype] <noident>
drivers/firewire/fw-ohci.c:1490:8: warning: restricted degrades to integer
drivers/firewire/fw-ohci.c:1490:35: warning: restricted degrades to integer
drivers/firewire/fw-ohci.c:1516:5: warning: cast to restricted type
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Jarod Wilson <jwilson@redhat.com>
Linus Torvalds [Thu, 13 Mar 2008 20:25:32 +0000 (13:25 -0700)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband:
IPoIB: Allocate priv->tx_ring with vmalloc()
IPoIB/cm: Set tx_wr.num_sge in connected mode post_send()
IPoIB: Don't drop multicast sends when they can be queued
IB/ipath: Reset the retry counter for RDMA_READ_RESPONSE_MIDDLE packets
IB/ipath: Fix error completion put on send CQ instead of recv CQ
IB/ipath: Fix RC QP initialization
IB/ipath: Fix potentially wrong RNR retry counter returned in ipath_query_qp()
IB/ipath: Fix IB compliance problems with link state vs physical state
Jan Beulich [Thu, 13 Mar 2008 09:13:30 +0000 (09:13 +0000)]
avoid endless loops in lib/swiotlb.c
Commit 681cc5cd3efbeafca6386114070e0bfb5012e249 ("iommu sg merging:
swiotlb: respect the segment boundary limits") introduced two
possibilities for entering an endless loop in lib/swiotlb.c:
- if max_slots is zero (possible if mask is ~0UL)
- if the number of slots requested fits into a swiotlb segment, but is
too large for the part of a segment which remains after considering
offset_slots
This fixes them
Signed-off-by: Jan Beulich <jbeulich@novell.com> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Thu, 13 Mar 2008 20:13:47 +0000 (13:13 -0700)]
Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (32 commits)
ACPI: thermal: show temperature in millidegree Celsius
thermal: fix generic thermal I/F for hwmon
acer-wmi: build depends on i8042
documentation: Move power-related files to Documentation/power/
ACPI: buffer array too short in drivers/acpi/system.c
acer-wmi: Add DMI quirk for mail LED support on Acer Aspire 3610/ 5610
acer-wmi: Fix DSDT path in documentation
acer-wmi: Make device detection error messages more descriptive
laptops: move laptop-mode.txt to Documentation/laptops/
ACPICA: Warn if packages with invalid references are evaluated
ACPI: add _PRT quirks to work around broken firmware
Hibernation: Fix mark_nosave_pages()
ACPI: Ignore _BQC object when registering backlight device
ACPI: WMI: Clean up handling of spec violating data blocks
acer-wmi: Don't warn if mail LED cannot be detected
acer-wmi: Rename mail LED correctly & remove hardcoded colour
ACPI: use ACPI_DEBUG_PRINT instead of printk in acpi_processor_hotplug_notify()
ACPI: button: make real parent for input devices in device tree
toshiba_acpi: Enable autoloading
ACPI: EC: Handle IRQ storm on Acer laptops
...
Jiri Slaby [Thu, 13 Mar 2008 19:32:43 +0000 (12:32 -0700)]
block: floppy: fix rmmod lockup
Floppy rmmod locks up when no such hardware was initialized, since there is
nobody to wake the remove code up. Remove the completion, because release is
called during platform_unregister anyway.
Randy Dunlap [Thu, 13 Mar 2008 19:32:43 +0000 (12:32 -0700)]
kernel-doc: set verbose mode via environment
Honor the environment variable "KBUILD_VERBOSE=1" (as set by make V=1) to
enable verbose mode in scripts/kernel-doc. Useful for getting more info and
warnings from kernel-doc.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Jan Nikitenko [Thu, 13 Mar 2008 19:32:39 +0000 (12:32 -0700)]
spi_bitbang: short transfer status fix
SPI controller drivers return number of bytes actually transfered from
bitbang->txrx_bufs() method. This updates handling of short transfers (where
the transfer size is less than requested):
- Even zero byte short transfers should report errors;
- Include short transfers in the total of transferred bytes;
- Use EREMOTEIO (like USB) not EMSGSIZE to report short transfers
Short transfers don't normally mean invalid message sizes, but if the
underlying controller driver needs to use EMSGSIZE it can still do so.
[db: fix two more minor issues] Signed-off-by: Jan Nikitenko <jan.nikitenko@gmail.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>
Yoshinori Sato [Thu, 13 Mar 2008 19:32:37 +0000 (12:32 -0700)]
h8300: fix recent uaccess breakage
Al Viro wrote:
>
> After that commit in asm-h8300/uaccess.h we have
>
> #define get_user(x, ptr) \
> ({ \
> int __gu_err = 0; \
> uint32_t __gu_val = 0; \
> ^^^^^^^^^^^^^^^^^
> switch (sizeof(*(ptr))) { \
> case 1: \
> case 2: \
> case 4: \
> __gu_val = *(ptr); \
> break; \
> case 8: \
> memcpy(&__gu_val, ptr, sizeof (*(ptr))); \
> ^^^^^^^^^^^^^^^^
>
> which, of course, is FUBAR whenever we actually hit that case - memcpy of
> 8 bytes into uint32_t is obviously wrong. Why don't we simply do
Cc: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Ahmed S. Darwish [Thu, 13 Mar 2008 19:32:34 +0000 (12:32 -0700)]
smackfs: do not trust `count' in inodes write()s
Smackfs write() implementation does not put a higher bound on the number of
bytes to copy from user-space. This may lead to a DOS attack if a malicious
`count' field is given.
Assure that given `count' is exactly the length needed for a /smack/load rule.
In case of /smack/cipso where the length is relative, assure that `count'
does not exceed the size needed for a buffer representing maximum possible
number of CIPSO 2.2 categories.
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Zhang Wei [Fri, 14 Mar 2008 00:45:28 +0000 (17:45 -0700)]
fsldma: Add a completed cookie updated action in DMA finish interrupt.
The patch 'fsldma: do not cleanup descriptors in hardirq context'
(commit 222ccf9ab838a1ca7163969fabd2cddc10403fb5) removed descriptors
cleanup function to tasklet but the completed cookie do not updated.
Thus, the DMA controller will get lots of duplicated transfer
interrupts. Just make a completed cookie update in interrupt handler.
And keep other cleanup jobs in tasklet function.
Tested-by: Sebastian Siewior <bigeasy@linutronix.de> Signed-off-by: Zhang Wei <wei.zhang@freescale.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Zhang Wei [Fri, 14 Mar 2008 00:45:28 +0000 (17:45 -0700)]
fsldma: Add device_prep_dma_interrupt support to fsldma.c
This is a bug that I assigned DMA_INTERRUPT capability to fsldma
but missing device_prep_dma_interrupt function. For a bug in
dmaengine.c the driver passed BUG_ON() checking. The patch fixes it.
Signed-off-by: Zhang Wei <wei.zhang@freescale.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Zhang Wei [Fri, 14 Mar 2008 00:45:28 +0000 (17:45 -0700)]
dmaengine: Fix a bug about BUG_ON() on DMA engine capability DMA_INTERRUPT.
The device->device_prep_dma_interrupt function is used by
DMA_INTERRUPT capability, not DMA_ZERO_SUM.
Signed-off-by: Zhang Wei <wei.zhang@freescale.com> Acked-by: Maciej Sosnowski <maciej.sosnowski@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Zhang Wei [Thu, 13 Mar 2008 17:45:27 +0000 (10:45 -0700)]
fsldma: Fix fsldma.c warning messages when it's compiled under PPC64.
There are warning messages reported by Stephen Rothwell with
ARCH=powerpc allmodconfig build:
drivers/dma/fsldma.c: In function 'fsl_dma_prep_memcpy':
drivers/dma/fsldma.c:439: warning: comparison of distinct pointer types
lacks a cast
drivers/dma/fsldma.c: In function 'fsl_chan_xfer_ld_queue':
drivers/dma/fsldma.c:584: warning: format '%016llx' expects type 'long long
unsigned int', but argument 4 has type 'dma_addr_t'
drivers/dma/fsldma.c: In function 'fsl_dma_chan_do_interrupt':
drivers/dma/fsldma.c:668: warning: format '%x' expects type 'unsigned int',
but argument 5 has type 'dma_addr_t'
drivers/dma/fsldma.c:684: warning: format '%016llx' expects type 'long long
unsigned int', but argument 4 has type 'dma_addr_t'
drivers/dma/fsldma.c:684: warning: format '%016llx' expects type 'long long
unsigned int', but argument 5 has type 'dma_addr_t'
drivers/dma/fsldma.c:701: warning: format '%02x' expects type 'unsigned
int', but argument 4 has type 'dma_addr_t'
drivers/dma/fsldma.c: In function 'fsl_dma_self_test':
drivers/dma/fsldma.c:840: warning: format '%d' expects type 'int', but
argument 5 has type 'size_t'
drivers/dma/fsldma.c: In function 'of_fsl_dma_probe':
drivers/dma/fsldma.c:1010: warning: format '%08x' expects type 'unsigned
int', but argument 5 has type 'resource_size_t'
This patch fixed the above warning messages.
Signed-off-by: Zhang Wei <wei.zhang@freescale.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
PCI: fix issue with busses registering multiple times in sysfs
PCI busses can be registered multiple times, so we need to detect if we
have registered our bus structure in sysfs already. If so, don't do it
again.
Thanks to Guennadi Liakhovetski <g.liakhovetski@gmx.de> for reporting
the problem, and to Linus for poking me to get me to believe that it was
a real problem.
Tony Lindgren [Tue, 11 Mar 2008 11:53:07 +0000 (13:53 +0200)]
ARM: OMAP2: Fix _REGADDR macro offset calculations and cm.h for assembly
Make sure unexpected register offsets don't get calculated because of
(unlikely) macro parameter calculations. Also fix cm.h so it can be
included from assembly functions.
projects / linux-2.6-omap-h63xx.git / log