- 27 Aug, 2009 40 commits
-
-
Mark Brown authored
Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
Liam Girdwood <lrg@slimlogic.co.uk>
-
Mark Brown authored
Signed-off-by:
-
Mike Rapoport authored
Signed-off-by:
Mike Rapoport <mike@compulab.co.il> Signed-off-by:
-
Mark Brown authored
This is useful for implementing get_status() in terms of get_mode(). Signed-off-by: -
Mark Brown authored
Report errors to the user and try harder to clean up if we're not able to probe. Signed-off-by:
-
Mark Brown authored
The patch to add support for looking up consumers by device name had the side effect of causing us to require a device which is at best premature since at least cpufreq still operates outside the device model. Remove that requirement. Reported-by:
Haojian Zhuang <haojian.zhuang@gmail.com> Signed-off-by:
-
Mark Brown authored
We're probably going to start oopsing fairly soon after this happens. Signed-off-by:
-
Mark Brown authored
Simplify checking of support for voltage ranges by providing an API which wraps the existing count and list operations. Signed-off-by:
-
Mark Brown authored
Some consumers require complete control of the regulator and can't tolerate sharing it with other consumers, most commonly because they need to have the regulator actually disabled so can't have other consumers forcing it on. This new regulator_get_exclusive() API call allows these consumers to explicitly request this, documenting the assumptions that they are making. In order to simplify coding of such consumers the use count for regulators they request is forced to match the enabled state of the regulator when it is requested. This is not possible for consumers which can share regulators due to the need to keep track of the ownership of use counts. A new API call is used rather than an additional argument to the existing regulator_get() in order to avoid merge headaches with driver code in other trees. Signed-off-by:
-
Haojian Zhuang authored
Make da903x driver to list voltage and count voltage. Signed-off-by:
Haojian Zhuang <haojian.zhuang@marvell.com> Acked-by:
Eric Miao <eric.y.miao@gmail.com> Signed-off-by:
-
roald authored
Signed-off-by:
-
Haojian Zhuang authored
In PXA3xx SoC family, V_CORE power doamin is supplied by BUCK1 that is controller by ADTV1 or ADTV2 register. By default, v1 and v2 has the same copy. If v1 or v2 is updated, the last value that is written to either register takes effect. It means that v1 and v2 has different copy. And the actual voltage output is determinated by last update on either register. DA9034/35 is binded with PXA3xx SoC family. While SoC is scaling OP or entering/exiting lower power mode, SoC needs to change voltage of V_CORE power doamin. In order to be efficient, POWER I2C (hardcode) mode could be enabled in SoC. In this mode, SoC will control v2 register directly. In original DA903x driver, software will only read regulator data from v1 register. But SoC controls v2 register directly. It results that v1 and v2 isn't synchronized. Wrong data will be read from v1 register. So access v2 register in da903x driver instead. Signed-off-by:
-
Haojian Zhuang authored
Support the operation of DA9030 BUCK2 in da903x driver. Signed-off-by:
-
Haojian Zhuang authored
BUCK3 is the new component in DA9035. So there're three BUCKs in DA9035. And there're two BUCKs in DA9034. Signed-off-by:
-
Mark Brown authored
This allows machine drivers to build without ifdefs if they have full constraints. Suggested by machine drivers contributed by Haojian Zhuang <haojian.zhuang@gmail.com>. Signed-off-by:
-
Joe Perches authored
Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Mark Brown authored
Follow the approach suggested by Russell King and implemented by him in the clkdev API and allow consumer device supply mapings to be set up using the dev_name() for the consumer instead of the struct device. In order to avoid making existing machines instabuggy and creating merge issues the use of struct device is still supported for the time being. This resolves problems working with buses such as I2C which make the struct device available late providing that the final device name is known, which is the case for most embedded systems with fixed setups. Consumers must still use the struct device when calling regulator_get(). Signed-off-by:
-
Mark Brown authored
This makes it easier to read the logs when doing testing. Signed-off-by:
-
Mark Brown authored
Signed-off-by:
-
Mark Brown authored
The core will no longer complain so we should log an error here. Signed-off-by:
-
Roel Kluin authored
Ensure that reg is within the bounds of array wm8350->pmic.pdev[]. Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Acked-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: virtio: net refill on out-of-memory smc91x: fix compilation on SMP
-
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpcLinus Torvalds authored
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: powerpc/ps3: Update ps3_defconfig powerpc/ps3: Add missing check for PS3 to rtc-ps3 platform device registration
-
Geoff Levand authored
Update ps3_defconfig. o Refresh for 2.6.31. o Remove MTD support. o Add more HID drivers. Signed-off-by:
Geoff Levand <geoffrey.levand@am.sony.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Geert Uytterhoeven authored
On non-PS3, we get: | kernel BUG at drivers/rtc/rtc-ps3.c:36! because the rtc-ps3 platform device is registered unconditionally in a kernel with builtin support for PS3. Reported-by:
Sachin Sant <sachinp@in.ibm.com> Signed-off-by:
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Acked-by:
-
Linus Torvalds authored
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6: IMA: iint put in ima_counts_get and put
-
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68kLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k: m68k,m68knommu: Wire up rt_tgsigqueueinfo and perf_counter_open m68k: Fix redefinition of pgprot_noncached arch/m68k/include/asm/motorola_pgalloc.h: fix kunmap arg m68k: cnt reaches -1, not 0 m68k: count can reach 51, not 50
-
Thadeu Lima de Souza Cascardo authored
If we change the inverted attribute to another value, the LED will not be inverted until we change the GPIO state. Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Cc: Samuel R. C. Vale <srcvale@holoscopio.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Thadeu Lima de Souza Cascardo authored
When setting the same GPIO number, multiple IRQ shared requests will be done without freing the previous request. It will also try to free a failed request or an already freed IRQ if 0 was written to the gpio file. All these oops and leaks were fixed with the following solution: keep the previous allocated GPIO (if any) still allocated in case the new request fails. The alternative solution would desallocate the previous allocated GPIO and set gpio as 0. Signed-off-by:
Samuel R. C. Vale <srcvale@holoscopio.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Frans Pop authored
This failure is very common on many platforms. Handling it in the ACPI processor driver is enough, and we don't need a warning message unless CONFIG_ACPI_DEBUG is set. Based on a patch from Zhang Rui. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389Signed-off-by:
Frans Pop <elendil@planet.nl> Acked-by:
Zhang Rui <rui.zhang@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by:
-
Frans Pop authored
If the BIOS reports an invalid throttling state (which seems to be fairly common after system boot), a reset is done to state T0. Because of a check in acpi_processor_get_throttling_ptc(), the reset never actually gets executed, which results in the error reoccurring on every access of for example /proc/acpi/processor/CPU0/throttling. Add a 'force' option to acpi_processor_set_throttling() to ensure the reset really takes effect. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389 This patch, together with the next one, fixes a regression introduced in 2.6.30, listed on the regression list. They have been available for 2.5 months now in bugzilla, but have not been picked up, despite various reminders and without any reason given. Google shows that numerous people are hitting this issue. The issue is in itself relatively minor, but the bug in the code is clear. The patches have been in all my kernels and today testing has shown that throttling works correctly with the patches applied when the system overheats (http://bugzilla.kernel.org/show_bug.cgi?id=13918#c14). Signed-off-by:
-
Costantino Leandro authored
Summary: Kernel panic arise when stack protection is enabled, since strncat will add a null terminating byte '\0'; So in functions like this one (wmi_query_block): char wc[4]="WC"; .... strncat(method, block->object_id, 2); ... the length of wc should be n+1 (wc[5]) or stack protection fault will arise. This is not noticeable when stack protection is disabled,but , isn't good either. Config used: [CONFIG_CC_STACKPROTECTOR_ALL=y, CONFIG_CC_STACKPROTECTOR=y] Panic Trace ------------ .... stack-protector: kernel stack corrupted in : fa7b182c 2.6.30-rc8-obelisco-generic call_trace: [<c04a6c40>] ? panic+0x45/0xd9 [<c012925d>] ? __stack_chk_fail+0x1c/0x40 [<fa7b182c>] ? wmi_query_block+0x15a/0x162 [wmi] [<fa7b182c>] ? wmi_query_block+0x15a/0x162 [wmi] [<fa7e7000>] ? acer_wmi_init+0x00/0x61a [acer_wmi] [<fa7e7135>] ? acer_wmi_init+0x135/0x61a [acer_wmi] [<c0101159>] ? do_one_initcall+0x50+0x126 Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13514Signed-off-by:Costantino Leandro <lcostantino@gmail.com> Signed-off-by:
Carlos Corbacho <carlos@strangeworlds.co.uk> Cc: Len Brown <len.brown@intel.com> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: <stable@kernel.org> Signed-off-by:
-
Yinghai Lu authored
Jens reported early_ioremap messages with old ASUS board... > [ 1.507461] pci 0000:00:09.0: Firmware left e100 interrupts enabled; disabling > [ 1.532778] early_ioremap(3fffd080, 0000005c) [0] => Pid: 1, comm: swapper Not tainted 2.6.31-rc4 #36 > [ 1.561007] Call Trace: > [ 1.568638] [<c136e48b>] ? printk+0x18/0x1d > [ 1.581734] [<c15513ff>] __early_ioremap+0x74/0x1e9 > [ 1.596898] [<c15515aa>] early_ioremap+0x1a/0x1c > [ 1.611270] [<c154a187>] __acpi_map_table+0x18/0x1a > [ 1.626451] [<c135a7f8>] acpi_os_map_memory+0x1d/0x25 > [ 1.642129] [<c119459c>] acpi_tb_verify_table+0x20/0x49 > [ 1.658321] [<c1193e50>] acpi_get_table_with_size+0x53/0xa1 > [ 1.675553] [<c1193eae>] acpi_get_table+0x10/0x15 > [ 1.690192] [<c155cc19>] acpi_processor_init+0x23/0xab > [ 1.706126] [<c1001043>] do_one_initcall+0x33/0x180 > [ 1.721279] [<c155cbf6>] ? acpi_processor_init+0x0/0xab > [ 1.737479] [<c106893a>] ? register_irq_proc+0xaa/0xc0 > [ 1.753411] [<c10689b7>] ? init_irq_proc+0x67/0x80 > [ 1.768316] [<c15405e7>] kernel_init+0x120/0x176 > [ 1.782678] [<c15404c7>] ? kernel_init+0x0/0x176 > [ 1.797062] [<c10038b7>] kernel_thread_helper+0x7/0x10 > [ 1.812984] 00000080 + ffe00000 that is rather later. acpi_gbl_permanent_mmap should be set in acpi_early_init() if acpi is not disabled and we have > [ 0.000000] ASUS P2B-DS detected: force use of acpi=ht just don't load acpi_processor_init... Reported-and-tested-by:
Jens Rosenboom <jens@leia.mcbone.net> Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Acked-by:
Ingo Molnar <mingo@elte.hu> Cc: Len Brown <lenb@kernel.org> Signed-off-by:
-
Michael Brunner authored
The return value of the get_temp function is not checked when doing a thermal zone update. This may lead to a critical shutdown if get_temp fails and the content of the temp variable is incorrectly set higher than the critical trip point. This has been observed on a system with incorrect ACPI implementation where the corresponding methods were not serialized and therefore sometimes triggered ACPI errors (AE_ALREADY_EXISTS). The following critical shutdowns indicated a temperature of 2097 C, which was obviously wrong. The patch adds a return value check that jumps over all trip point evaluations printing a warning if get_temp fails. The trip points are evaluated again on the next polling interval with successful get_temp execution. Signed-off-by:
Michael Brunner <mibru@gmx.de> Acked-by:
-
Oleg Nesterov authored
Spotted by Hiroshi Shimamoto who also provided the test-case below. copy_process() uses signal->count as a reference counter, but it is not. This test case #include <sys/types.h> #include <sys/wait.h> #include <unistd.h> #include <stdio.h> #include <errno.h> #include <pthread.h> void *null_thread(void *p) { for (;;) sleep(1); return NULL; } void *exec_thread(void *p) { execl("/bin/true", "/bin/true", NULL); return null_thread(p); } int main(int argc, char **argv) { for (;;) { pid_t pid; int ret, status; pid = fork(); if (pid < 0) break; if (!pid) { pthread_t tid; pthread_create(&tid, NULL, exec_thread, NULL); for (;;) pthread_create(&tid, NULL, null_thread, NULL); } do { ret = waitpid(pid, &status, 0); } while (ret == -1 && errno == EINTR); } return 0; } quickly creates an unkillable task. If copy_process(CLONE_THREAD) races with de_thread() copy_signal()->atomic(signal->count) breaks the signal->notify_count logic, and the execing thread can hang forever in kernel space. Change copy_process() to increment count/live only when we know for sure we can't fail. In this case the forked thread will take care of its reference to signal correctly. If copy_process() fails, check CLONE_THREAD flag. If it it set - do nothing, the counters were not changed and current belongs to the same thread group. If it is not set, ->signal must be released in any case (and ->count must be == 1), the forked child is the only thread in the thread group. We need more cleanups here, in particular signal->count should not be used by de_thread/__exit_signal at all. This patch only fixes the bug. Reported-by:Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Tested-by:
Oleg Nesterov <oleg@redhat.com> Acked-by:
Roland McGrath <roland@redhat.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: <stable@kernel.org> Signed-off-by:
-
Minchan Kim authored
An mlocked page might lose the isolatation race. This causes the page to clear PG_mlocked while it remains in a VM_LOCKED vma. This means it can be put onto the [in]active list. We can rescue it by using try_to_unmap() in shrink_page_list(). But now, As Wu Fengguang pointed out, vmscan has a bug. If the page has PG_referenced, it can't reach try_to_unmap() in shrink_page_list() but is put into the active list. If the page is referenced repeatedly, it can remain on the [in]active list without being moving to the unevictable list. This patch fixes it. Reported-by:
Wu Fengguang <fengguang.wu@intel.com> Signed-off-by:
Minchan Kim <minchan.kim@gmail.com> Reviewed-by:
KOSAKI Motohiro <<kosaki.motohiro@jp.fujitsu.com> Cc: Lee Schermerhorn <lee.schermerhorn@hp.com> Acked-by:
Rik van Riel <riel@redhat.com> Signed-off-by:
-
David Rientjes authored
It's problematic to allow signed element_nr's or total's to be passed as part of the flex array API. flex_array_alloc() allows total_nr_elements to be set to a negative quantity, which is obviously erroneous. flex_array_get() and flex_array_put() allows negative array indices in dereferencing an array part, which could address memory mapped before struct flex_array. The fix is to convert all existing element_nr formals to be qualified as unsigned. Existing checks to compare it to total_nr_elements or the max array size based on element_size need not be changed. Signed-off-by:
David Rientjes <rientjes@google.com> Cc: Dave Hansen <dave@linux.vnet.ibm.com> Signed-off-by:
-
David Rientjes authored
The `parts' member of struct flex_array should evaluate to an incomplete type so that sizeof() cannot be used and C99 does not require the zero-length specification. Signed-off-by:
Dave Hansen <dave@linux.vnet.ibm.com> Signed-off-by:
-
David Rientjes authored
flex_array_free_parts() does not take `src' or `element_nr' formals, so remove their respective comments. Signed-off-by:
-
David Rientjes authored
If all array elements fit into the base structure and data is copied using flex_array_put() starting at a non-zero index, flex_array_get() will fail to return the data. This fixes the bug by only checking for NULL parts when all elements do not fit in the base structure when flex_array_get() is used. Otherwise, fa_element_to_part_nr() will always be 0 since there are no parts structures needed and such element may never have been put. Thus, it will remain NULL due to the kzalloc() of the base. Additionally, flex_array_put() now only checks for a NULL part when all elements do not fit in the base structure. This is otherwise unnecessary since the base structure is guaranteed to exist (or we would have already hit a NULL pointer). Signed-off-by:
-
