Kevin Hilman [Mon, 8 Dec 2008 17:38:14 +0000 (09:38 -0800)]
OMAP3: PM: UART: disable clocks when idle
This patch allows the UART clocks to be disabled when the OMAP UARTs
are inactive, thus permitting the chip to hit retention in idle.
After the timeout of an activity timer, each UART is allowed to
disable its clocks so the system can enter retention. The activity
timer is (re)activated on any UART interrupt, UART wake event or any
IO pad wakeup. The actual disable of the UART clocks is done in the
'prepare_idle' hook called from the OMAP idle loop.
While the activity timer is active, the smart-idle mode of the UART is
also disabled. This is due to a "feature" of the UART module that
after a UART wakeup, the smart-idle mode may be entered before the
UART has communicated the interrupt, or upon TX, an idle mode may be
entered before the TX FIFOs are emptied.
Upon suspend, the 'prepare_suspend' hook cancels any pending activity
timers and allows the clocks to be disabled.
To enable the clock-disabling feature of this patch, do
# echo 1 > /sys/power/clocks_off_while_idle
Special thanks to Tero Kristo for the initial ideas and first versions
of UART idle support, and to Jouni Hogander for extra testing and
bugfixes.
Tested on OMAP3 (Beagle, custom HW) and OMAP2 (n810)
Cc: Tero Kristo <tero.kristo@nokia.com> Cc: Jouni Hogander <jouni.hogander@nokia.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Paul Walmsley [Wed, 7 Jan 2009 15:23:46 +0000 (17:23 +0200)]
OMAP3 SmartReflex: get rid of custom clocks
smartreflex.c defines some custom clocks that don't have clockdomains
associated with them, which is now disallowed. The custom clocks are
not actually needed, so remove them. This patch should not cause any
functional change.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kalle Jokiniemi <ext-kalle.jokiniemi@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:23:46 +0000 (17:23 +0200)]
OMAP2/3 clock: don't tinker with hardirqs when they are supposed to be disabled
Clock rate change code executes inside a spinlock with hardirqs
disabled. The only code that should be messing around with the
hardirq state should be the plat-omap/clock.c code. In the
omap2_reprogram_dpllcore() case, this probably just wastes cycles, but
in the omap3_core_dpll_m2_set_rate() case, this is a nasty bug.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:23:45 +0000 (17:23 +0200)]
OMAP2/3 clock: omap2_clk_enable(): fix bugs in clockdomain handling
omap2_clk_enable() should enable a clock's clockdomain before
attempting to enable its parent clock's clockdomain. Similarly, in
the unlikely event that the parent clock enable fails, the clockdomain
should be disabled.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:23:45 +0000 (17:23 +0200)]
OMAP2/3 clock: every clock must have a clkdm
Every OMAP2/3 clock must now have an assigned clockdomain, so we can
remove the checks from clk_enable()/clk_disable(). Instead, verify
that the clockdomain is present only at clock init time via the
arch_clock clk_register() hook.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Provide a mechanism for OMAP chip family (e.g., OMAP1, 2, 3) clock
code to define a clk_register function via struct clk_functions. This
is currently only used for OMAP2/3, to handle clock->clockdomain
registration.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:23:45 +0000 (17:23 +0200)]
OMAP clock: drop clk_get_usecount()
This function is race-prone and mistakenly conveys the impression to
drivers that it is part of the clock interface. Get rid of it: core
code that absolutely needs this can just check clk->usecount. Drivers
should not use it at all.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:23:45 +0000 (17:23 +0200)]
OMAP2/3 clock: convert remaining MPU barriers into OCP barriers
Several parts of the OMAP2/3 clock code use wmb() to try to ensure
that the hardware write completes before continuing. This approach is
problematic: wmb() only ensures that the write leaves the ARM. It
does not ensure that the write actually reaches the endpoint device.
The endpoint device in this case - either the PRM, CM, or SCM - is
three interconnects away from the ARM - and the final interconnect is
low-speed. And the OCP interconnects will post the write, and who
knows how long that will take to complete. So the wmb() is not what
we want. Worse, the wmb() is indiscriminate; it causes the ARM to
flush any other unrelated buffered writes and wait for the local
interconnect to acknowledge them - potentially very expensive.
Fix this by converting the wmb()s into readbacks of the same PRM/CM/SCM
register. Since the PRM/CM/SCM devices use a single OCP thread, this
will cause the MPU to block while waiting for posted writes to that device
to complete.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Consolidate the commit code for DELAYED_APP clocks into a subroutine,
_omap2xxx_clk_commit(). Also convert the MPU barrier wmb() into an
OCP barrier, since with an MPU barrier, we have no guarantee that the
write actually reached the endpoint device.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:23:21 +0000 (17:23 +0200)]
OMAP2/3 clock: don't use a barrier after clk_disable()
clk_disable() previously used an ARM barrier, wmb(), to try to ensure
that the hardware write completed before continuing. There are some
problems with this approach.
The first problem is that wmb() only ensures that the write leaves the
ARM -- not that it actually reaches the endpoint device. In this
case, the endpoint device - either the PRM, CM, or SCM - is three
interconnects away from the ARM, and the final interconnect is
low-speed. And the OCP interconnects will post the write, who knows
how long that will take to complete. So the wmb() is not really what
we want.
Worse, the wmb() is indiscriminate; it will cause the ARM to flush any
other unrelated buffered writes and wait for the local interconnect to
acknowledge them - potentially very expensive.
This first problem could be fixed by doing a readback of the same PRM/CM/SCM
register. Since these devices use a single OCP thread, this will cause the
MPU to wait for the write to complete.
But the primary problem is a conceptual one: clk_disable() should not
need any kind of barrier. clk_enable() needs one since device driver
code must not access a device until its clocks are known to be
enabled. But clk_disable() has no such restriction.
Since blocking the MPU on a PRM/CM/SCM write can be a very
high-latency operation - several hundred MPU cycles - it's worth
avoiding this barrier if possible.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Russell King [Wed, 7 Jan 2009 15:23:21 +0000 (17:23 +0200)]
OMAP clock: rearrange clock.h structure order
... to eliminate unnecessary padding. We have rather a lot of these
structures, so eliminating unnecessary padding results in a saving of
1488 bytes.
[paul@pwsan.com: updated against current linux-omap clock tree, now saves
1512 bytes on OMAP3 builds]
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Russell King [Wed, 7 Jan 2009 15:20:26 +0000 (17:20 +0200)]
OMAP2/3 clock: remove clk->owner
clk->owner is always NULL, so its existence doesn't serve any useful
function other than bloating the kernel by 992 bytes. Remove it.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:20:25 +0000 (17:20 +0200)]
OMAP2 clock: drop CONFIG_PARTICIPANT clock flag
The CONFIG_PARTICIPANT flags indicates to the clock rate and parent
changing functions that they should not be used on this clock. Better
just to remove the clock function pointers that operate on those
clocks. The name of the flag is just terrible: its meaning has almost
nothing to do with its name, and the use of the CONFIG_ prefix makes
it appear to be a Kconfig option. Get rid of it.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Russell King [Wed, 7 Jan 2009 15:20:25 +0000 (17:20 +0200)]
OMAP clock: remove VIRTUAL_CLOCK
Nothing tests the clock flags for this bit, so it serves no purpose.
Remove it.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:20:25 +0000 (17:20 +0200)]
OMAP clock: drop RATE_FIXED
The RATE_FIXED flag currently has no useful purpose. Fixed rate clocks
should simply not implement the recalc, set_rate, set_parent, and round_rate
function pointers.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:20:24 +0000 (17:20 +0200)]
OMAP clock: track child clocks
Track child clocks for each struct clk. This optimizes traversals of the
clock tree from parent to child, which happens during rate propagation, and
in the future, clock notifiers.
Previously, parent-to-child traversals sequentially scanned the entire
clock list at each step to determine the children of a particular
clock node. Now each struct clk maintains a clock list of its
children. For a DPLL3_M2_CK rate change, this converts what were
about O(6*180*2) operations into O(6*6*2) operations. The savings
will be even more significant after the future notifier patches:
something like O(6*180*6) to O(6*6*6).
The price paid is additional runtime memory consumption - 8 bytes per
clock and 16 bytes per child clock - roughly 4.5KiB on OMAP3. The
memory comes mostly from bootmem, since initial clock registration
takes place before slab is ready. Several other operations will take
slightly more time due the extra bookkeeping: clk_register(),
clk_unregister(), clk_set_parent(), and omap2_init_clksel_parent().
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:20:24 +0000 (17:20 +0200)]
OMAP clock: support "dry run" rate and parent changes
For upcoming notifier support, modify the rate recalculation code to
take parent rate and rate storage parameters. The goal here is to
allow the clock code to determine what the clock's rate would be after
a parent change or a rate change, without actually changing the
hardware registers. This is used by the upcoming notifier patches to
pass a clock's current and planned rates to the notifier callbacks.
Also add a new clock flag, RECALC_ON_ENABLE, which causes the clock
framework code to recalculate the current clock's rate and propagate
down the tree after a clk_enable() or clk_disable(). This is used by
the OMAP3 DPLLs, which change rates when they enable or disable, unlike
most clocks.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:20:23 +0000 (17:20 +0200)]
OMAP2/3 clock: drop recalc function pointers from fixed rate clocks
Now that rate recalculation and rate propagation are two separate
operations, drop recalc function pointers from all fixed rate clocks.
Their rates are fixed, so there's no need to recalculate.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:20:23 +0000 (17:20 +0200)]
OMAP clock: move rate recalc, propagation code up to plat-omap/clock.c
Previously the individual clock recalculation functions handled their
own rate recalculation. This can be handled in the clk_set_rate(),
clk_set_parent(), and recalculate_root_clocks() functions in
plat-omap/clock.c. Removes duplicate code and clarifies the role of the
recalc functions.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:20:23 +0000 (17:20 +0200)]
OMAP2/3 clock: use standard set_rate fn in omap2_clk_arch_init()
Use the standard clk_set_rate() function in omap2_clk_arch_init()
rather than omap2_select_table_rate() -- this will ensure that clock
rates are recalculated and propagated correctly after those operations
are consolidated into clk_set_rate().
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Tony Lindgren [Mon, 29 Dec 2008 16:15:47 +0000 (18:15 +0200)]
hsmmc: Fix bus voltage reset, clean-up for checkpatch
The bus voltage was being reset to 3V even if card was not
removed. Move the reset code to happen after slot has been
powered down. Also clean-up for checkpatch.
Tony Lindgren [Mon, 29 Dec 2008 14:24:25 +0000 (16:24 +0200)]
hsmmc: Fix setting the voltage back to 3V
We should not set it in mmc_omap_detect, as that does not necessarily
tell that card got removed. Reset the voltage back to 3V after powering
off the slot instead.
and are queued up for v2.6.29. This shows that the facility is still not
tested well enough to release into a stable kernel - disable it for now and
reactivate in .29. In .29 the hardware-branch-tracer will use the DS/BTS
facilities too - hopefully resulting in better code.
Kyle McMartin [Tue, 23 Dec 2008 13:44:30 +0000 (08:44 -0500)]
parisc: disable UP-optimized flush_tlb_mm
flush_tlb_mm's "optimized" uniprocessor case of allocating a new
context for userspace is exposing a race where we can suddely return
to a syscall with the protection id and space id out of sync, trapping
on the next userspace access.
Harry Ciao [Tue, 23 Dec 2008 21:57:16 +0000 (13:57 -0800)]
edac: fix edac core deadlock when removing a device
When deleting an edac device, we have to wait for its edac_dev.work to be
completed before deleting the whole edac_dev structure. Since we have no
idea which work in current edac_poller's workqueue is the work we are
conerned about, we wait for all work in the edac_poller's workqueue to be
proceseed. This is done via flush_cpu_workqueue() which inserts a
wq_barrier into the tail of the workqueue and then sleeping on the
completion of this wq_barrier. The edac_poller will wake up sleepers when
it is found.
EDAC core creates only one kernel worker thread, edac_poller, to run the
works of all current edac devices. They share the same callback function
of edac_device_workq_function(), which would grab the mutex of
device_ctls_mutex first before it checks the device. This is exactly
where edac_poller and rmmod would have a great chance to deadlock.
In below call trace of rmmod > ... >
edac_device_del_device >
edac_device_workq_teardown > flush_workqueue > flush_cpu_workqueue,
device_ctls_mutex would have already been grabbed by
edac_device_del_device(). So, on one hand rmmod would sleep on the
completion of a wq_barrier, holding device_ctls_mutex; on the other hand
edac_poller would be blocked on the same mutex when it's running any one
of works of existing edac evices(Note, this edac_dev.work is likely to be
totally irrelevant to the one that is being removed right now)and never
would have a chance to run the work of above wq_barrier to wake rmmod up.
edac_device_workq_teardown() should not be called within the critical
region of device_ctls_mutex. Just like is done in edac_pci_del_device()
and edac_mc_del_mc(), where edac_pci_workq_teardown() and
edac_mc_workq_teardown() are called after related mutex are released.
Moreover, an edac_dev.work should check first if it is being removed. If
this is the case, then it should bail out immediately. Since not all of
existing edac devices are to be removed, this "shutting flag" should be
contained to edac device being removed. The current edac_dev.op_state can
be used to serve this purpose.
The original deadlock problem and the solution have been witnessed and
tested on actual hardware. Without the solution, rmmod an edac driver
would result in below deadlock:
Evgeniy Polyakov [Tue, 23 Dec 2008 21:57:12 +0000 (13:57 -0800)]
w1: fix slave selection on big-endian systems
During test of the w1-gpio driver i found that in "w1.c:679
w1_slave_found()" the device id is converted to little-endian with
"cpu_to_le64()", but its not converted back to cpu format in "w1_io.c:293
w1_reset_select_slave()".
Based on a patch created by Andreas Hummel.
[akpm@linux-foundation.org: remove unneeded cast] Reported-by: Andreas Hummel <andi_hummel@gmx.de> Signed-off-by: Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Paul Walmsley [Tue, 23 Dec 2008 06:28:10 +0000 (23:28 -0700)]
OMAP2: fix recent build breakage
Fix recent build breakage. Boot-tested on N800.
CC arch/arm/mach-omap2/devices.o
arch/arm/mach-omap2/devices.c:110: error: 'OMAP34XX_MAILBOX_BASE' undeclared here (not in a function)
arch/arm/mach-omap2/devices.c:115: error: 'INT_34XX_MAIL_U0_MPU' undeclared here (not in a function)
make[1]: *** [arch/arm/mach-omap2/devices.o] Error 1
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
V4L/DVB (9920): em28xx: fix NULL pointer dereference in call to VIDIOC_INT_RESET command
Fix a NULL pointer dereference that would occur if the video decoder tied to
the em28xx supports the VIDIOC_INT_RESET call (for example: the cx25840 driver)
Thomas Gleixner [Sat, 20 Dec 2008 20:27:34 +0000 (21:27 +0100)]
Null pointer deref with hrtimer_try_to_cancel()
Impact: Prevent kernel crash with posix timer clockid CLOCK_MONOTONIC_RAW
commit 2d42244ae71d6c7b0884b5664cf2eda30fb2ae68 (clocksource:
introduce CLOCK_MONOTONIC_RAW) introduced a new clockid, which is only
available to read out the raw not NTP adjusted system time.
The above commit did not prevent that a posix timer can be created
with that clockid. The timer_create() syscall succeeds and initializes
the timer to a non existing hrtimer base. When the timer is deleted
either by timer_delete() or by the exit() cleanup the kernel crashes.
Prevent the creation of timers for CLOCK_MONOTONIC_RAW by setting the
posix clock function to no_timer_create which returns an error code.
Reported-and-tested-by: Eric Sesterhenn <snakebyte@gmx.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Sat, 20 Dec 2008 19:07:31 +0000 (11:07 -0800)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs:
fs/9p: change simple_strtol to simple_strtoul
9p: convert d_iname references to d_name.name
9p: Remove potentially bad parameter from function entry debug print.
Linus Torvalds [Sat, 20 Dec 2008 19:07:18 +0000 (11:07 -0800)]
Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86: fix resume (S2R) broken by Intel microcode module, on A110L
x86 gart: don't complain if no AMD GART found
AMD IOMMU: panic if completion wait loop fails
AMD IOMMU: set cmd buffer pointers to zero manually
x86: re-enable MCE on secondary CPUS after suspend/resume
AMD IOMMU: allocate rlookup_table with __GFP_ZERO
might hang upon resuming, OTOH it should have likely hanged each and every time.
(1) possible deadlock in microcode_resume_cpu() if either 'if' section is
taken;
(2) now, I don't see it in spec. and can't experimentally verify it (newer
ucodes don't seem to be available for my Core2duo)... but logically-wise, I'd
think that when read upon resuming, the 'microcode revision' (MSR 0x8B) should
be back to its original one (we need to reload ucode anyway so it doesn't seem
logical if a cpu doesn't drop the version)... if so, the comparison with
memcmp() for the full 'struct cpu_signature' is wrong... and that's how one of
the aforementioned 'if' sections might have been triggered - leading to a
deadlock.
Obviously, in my tests I simulated loading/resuming with the ucode of the same
version (just to see that the file is loaded/re-loaded upon resuming) so this
issue has never popped up.
I'd appreciate if someone with an appropriate system might give a try to the
2nd patch (titled "fix a comparison && deadlock...").
In any case, the deadlock situation is a must-have fix.
* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
[SCSI] mpt fusion: clear list of outstanding commands on host reset
[SCSI] scsi_lib: only call scsi_unprep_request() under queue lock
[SCSI] ibmvstgt: move crq_queue_create to the end of initialization
[SCSI] libiscsi REGRESSION: fix passthrough support with older iscsi tools
[SCSI] aacraid: disable Dell Percraid quirk on Adaptec 2200S and 2120S
Linus Torvalds [Fri, 19 Dec 2008 19:36:04 +0000 (11:36 -0800)]
Merge branch 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/i915: GEM on PAE has problems - disable it for now.
drm/i915: Don't return busy for buffers left on the flushing list.
Stanley Miao [Fri, 19 Dec 2008 14:08:22 +0000 (22:08 +0800)]
ALSA: Fix a Oops bug in omap soc driver.
There will be a Oops or frequent underrun messages when playing music with
omap soc driver, this is because a data region is incorretly sized, other data
region will be overwriten when writing to this data region.
Signed-off-by: Stanley Miao <stanley.miao@windriver.com> Acked-by: Jarkko Nikula <jarkko.nikula@nokia.com> Cc: stable@kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Fri, 19 Dec 2008 13:02:32 +0000 (14:02 +0100)]
ALSA: hda - Remove non-working headphone control for Dell laptops
The previous commit re-enabled hp_nid setup for IDT92HD73*, but
it's unneeded indeed for Dell laptops that have multiple headphones.
Setting the extra hp_nid results in a non-working "Headpohne" mixer
control. Thus hp_nid should be 0 for these dell models.
Also, the automatic addition of hp_nid should check whether it's
a dual-HP model or not. For dual-HPs, the pins are already checked
by the early workaround.
Hiroshi DOYU [Mon, 24 Nov 2008 21:57:10 +0000 (23:57 +0200)]
omap mailbox: fix empty struct device for omap_mbox
Since "mbox->dev" doesn't exist and isn't created either at
registration, this patch will create "struct device", which belongs to
"omap-mailbox" class and set this pointer for the member of
"struct omap_mbox".
Wu Fengguang [Wed, 26 Nov 2008 06:35:22 +0000 (14:35 +0800)]
ACPI: don't cond_resched() when irqs_disabled()
The ACPI interpreter usually runs with irqs enabled.
However, during suspend/resume it runs with
irqs disabled to evaluate _GTS/_BFS, as well as
by irqrouter_resume() which evaluates _CRS, _PRS, _SRS.
http://bugzilla.kernel.org/show_bug.cgi?id=12252
Signed-off-by: Wu Fengguang <wfg@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
Bjorn Helgaas [Thu, 13 Nov 2008 23:30:13 +0000 (17:30 -0600)]
ACPI: fix 2.6.28 acpi.debug_level regression
acpi_early_init() was changed to over-write the cmdline param,
making it really inconvenient to set debug flags at boot-time.
Also,
This sets the default level to "info", which is what all the ACPI
drivers use. So to enable messages from drivers, you only have to
supply the "layer" (a.k.a. "component"). For non-"info" ACPI core
and ACPI interpreter messages, you have to supply both level and
layer masks, as before.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
Takashi Iwai [Wed, 17 Dec 2008 13:51:01 +0000 (14:51 +0100)]
ALSA: hda - Add no-jd model for IDT 92HD73xx
Added the model without the jack-detection for some desktops that
have really no jack-detection. The recent driver caused regressions
regarding the sound output on such machines.
cciss: fix problem that deleting multiple logical drives could cause a panic
Fix problem that deleting multiple logical drives could cause a panic.
It fixes a panic which can be easily reproduced in the following way: Just
create several "arrays," each with multiple logical drives via hpacucli,
then delete the first array, and it will blow up in deregister_disk(), in
the call to get_host() when it tries to dig the hba pointer out of a NULL
queue pointer.
The problem has been present since my code to make rebuild_lun_table
behave better went in.
Signed-off-by: Stephen M. Cameron <scameron@beardog.cca.cpqcorp.net> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Dave Airlie [Fri, 19 Dec 2008 05:38:34 +0000 (15:38 +1000)]
drm/i915: GEM on PAE has problems - disable it for now.
On PAE systems, GEM allocates pages using shmem, and passes these
pages to be bound into AGP, however the AGP interfaces + the x86
set_memory interfaces all take unsigned long not dma_addr_t.
The initial fix for this was a mess, so we need to do this correctly
for 2.6.29.
Eric Anholt [Mon, 15 Dec 2008 03:05:04 +0000 (19:05 -0800)]
drm/i915: Don't return busy for buffers left on the flushing list.
These buffers don't have active rendering still occurring to them, they just
need either a flush to be emitted or a retire_requests to occur so that we
notice they're done. Return unbusy so that one of the two occurs. The two
expected consumers of this interface (OpenGL and libdrm_intel BO cache) both
want this behavior.
Signed-off-by: Eric Anholt <eric@anholt.net> Acked-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
NeilBrown [Fri, 19 Dec 2008 05:25:01 +0000 (16:25 +1100)]
md: Don't read past end of bitmap when reading bitmap.
When we read the write-intent-bitmap off the device, we currently
read a whole number of pages.
When PAGE_SIZE is 4K, this works due to the alignment we enforce
on the superblock and bitmap.
When PAGE_SIZE is 64K, this case read past the end-of-device
which causes an error.
When we write the superblock, we ensure to clip the last page
to just be the required size. Copy that code into the read path
to just read the required number of sectors.
Signed-off-by: Neil Brown <neilb@suse.de> Cc: stable@kernel.org
James Chapman [Wed, 17 Dec 2008 12:02:16 +0000 (12:02 +0000)]
ppp: fix segfaults introduced by netdev_priv changes
This patch fixes a segfault in ppp_shutdown_interface() and
ppp_destroy_interface() when a PPP connection is closed. I bisected
the problem to the following commit:
netdevice ppp: Convert directly reference of netdev->priv
1. Use netdev_priv(dev) to replace dev->priv.
2. Alloc netdev's private data by alloc_netdev().
Signed-off-by: Wang Chen <wangchen@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
The original ppp_generic code treated the netdev and struct ppp as
independent data structures which were freed separately. In moving the
ppp struct into the netdev, it is now possible for the private data to
be freed before the call to ppp_shutdown_interface(), which is bad.
The kfree(ppp) in ppp_destroy_interface() is also wrong; presumably
ppp hasn't worked since the above commit.
The following patch fixes both problems.
Signed-off-by: James Chapman <jchapman@katalix.com> Reviewed-by: Wang Chen <wangchen@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Wei Yongjun [Fri, 19 Dec 2008 03:35:10 +0000 (19:35 -0800)]
net: Fix module refcount leak in kernel_accept()
The kernel_accept() does not hold the module refcount of newsock->ops->owner,
so we need __module_get(newsock->ops->owner) code after call kernel_accept()
by hand.
In sunrpc, the module refcount is missing to hold. So this cause kernel panic.
Used following script to reproduct:
while [ 1 ];
do
mount -t nfs4 192.168.0.19:/ /mnt
touch /mnt/file
umount /mnt
lsmod | grep ipv6
done
This patch fixed the problem by add __module_get(newsock->ops->owner) to
kernel_accept(). So we do not need to used __module_get(newsock->ops->owner)
in every place when used kernel_accept().
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
projects / linux-2.6-omap-h63xx.git / log