- 24 2月, 2012 4 次提交
-
-
由 Olof Johansson 提交于
It's not perfect, but way better than before. Mark efi_enabled as false in case of error and at least stop dereferencing pointers that are known to be invalid. The only significant missing piece is the lack of undoing the memblock_reserve of the memory that efi marks as in use. On the other hand, it's not a large amount of memory, and leaving it unavailable for system use should be the safer choice anyway. Signed-off-by: NOlof Johansson <olof@lixom.net> Link: http://lkml.kernel.org/r/1329081869-20779-5-git-send-email-olof@lixom.netAcked-by: NMatt Fleming <matt.fleming@intel.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
由 Olof Johansson 提交于
Trivial cleanup, move guid and table pointers to local copies to make the code cleaner. Signed-off-by: NOlof Johansson <olof@lixom.net> Link: http://lkml.kernel.org/r/1329081869-20779-4-git-send-email-olof@lixom.netAcked-by: NMatt Fleming <matt.fleming@intel.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
由 Olof Johansson 提交于
Alright, I guess I'll go through and convert them, even though there's no net gain to speak of. v4: * Switched to pr_fmt and removed some redundant use of "EFI" in messages. Signed-off-by: NOlof Johansson <olof@lixom.net> Link: http://lkml.kernel.org/r/1329081869-20779-3-git-send-email-olof@lixom.net Cc: Joe Perches <joe@perches.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
由 Olof Johansson 提交于
Break out some of the init steps into helper functions. Only change to execution flow is the removal of the warning when the kernel memdesc structure differ in size from what firmware specifies since it's a bogus warning (it's a valid difference per spec). v4: * Removed memdesc warning as per above Signed-off-by: NOlof Johansson <olof@lixom.net> Link: http://lkml.kernel.org/r/1329081869-20779-2-git-send-email-olof@lixom.netAcked-by: NMatt Fleming <matt.fleming@intel.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
- 19 2月, 2012 2 次提交
-
-
由 Linus Torvalds 提交于
After all the FPU state cleanups and finally finding the problem that caused all our FPU save/restore problems, this re-introduces the preloading of FPU state that was removed in commit b3b0870e ("i387: do not preload FPU state at task switch time"). However, instead of simply reverting the removal, this reimplements preloading with several fixes, most notably - properly abstracted as a true FPU state switch, rather than as open-coded save and restore with various hacks. In particular, implementing it as a proper FPU state switch allows us to optimize the CR0.TS flag accesses: there is no reason to set the TS bit only to then almost immediately clear it again. CR0 accesses are quite slow and expensive, don't flip the bit back and forth for no good reason. - Make sure that the same model works for both x86-32 and x86-64, so that there are no gratuitous differences between the two due to the way they save and restore segment state differently due to architectural differences that really don't matter to the FPU state. - Avoid exposing the "preload" state to the context switch routines, and in particular allow the concept of lazy state restore: if nothing else has used the FPU in the meantime, and the process is still on the same CPU, we can avoid restoring state from memory entirely, just re-expose the state that is still in the FPU unit. That optimized lazy restore isn't actually implemented here, but the infrastructure is set up for it. Of course, older CPU's that use 'fnsave' to save the state cannot take advantage of this, since the state saving also trashes the state. In other words, there is now an actual _design_ to the FPU state saving, rather than just random historical baggage. Hopefully it's easier to follow as a result. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Linus Torvalds 提交于
This moves the bit that indicates whether a thread has ownership of the FPU from the TS_USEDFPU bit in thread_info->status to a word of its own (called 'has_fpu') in task_struct->thread.has_fpu. This fixes two independent bugs at the same time: - changing 'thread_info->status' from the scheduler causes nasty problems for the other users of that variable, since it is defined to be thread-synchronous (that's what the "TS_" part of the naming was supposed to indicate). So perfectly valid code could (and did) do ti->status |= TS_RESTORE_SIGMASK; and the compiler was free to do that as separate load, or and store instructions. Which can cause problems with preemption, since a task switch could happen in between, and change the TS_USEDFPU bit. The change to TS_USEDFPU would be overwritten by the final store. In practice, this seldom happened, though, because the 'status' field was seldom used more than once, so gcc would generally tend to generate code that used a read-modify-write instruction and thus happened to avoid this problem - RMW instructions are naturally low fat and preemption-safe. - On x86-32, the current_thread_info() pointer would, during interrupts and softirqs, point to a *copy* of the real thread_info, because x86-32 uses %esp to calculate the thread_info address, and thus the separate irq (and softirq) stacks would cause these kinds of odd thread_info copy aliases. This is normally not a problem, since interrupts aren't supposed to look at thread information anyway (what thread is running at interrupt time really isn't very well-defined), but it confused the heck out of irq_fpu_usable() and the code that tried to squirrel away the FPU state. (It also caused untold confusion for us poor kernel developers). It also turns out that using 'task_struct' is actually much more natural for most of the call sites that care about the FPU state, since they tend to work with the task struct for other reasons anyway (ie scheduling). And the FPU data that we are going to save/restore is found there too. Thanks to Arjan Van De Ven <arjan@linux.intel.com> for pointing us to the %esp issue. Cc: Arjan van de Ven <arjan@linux.intel.com> Reported-and-tested-by: NRaphael Prevost <raphael@buro.asia> Acked-and-tested-by: NSuresh Siddha <suresh.b.siddha@intel.com> Tested-by: NPeter Anvin <hpa@zytor.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 17 2月, 2012 5 次提交
-
-
由 Linus Torvalds 提交于
The AMD K7/K8 CPUs don't save/restore FDP/FIP/FOP unless an exception is pending. In order to not leak FIP state from one process to another, we need to do a floating point load after the fxsave of the old process, and before the fxrstor of the new FPU state. That resets the state to the (uninteresting) kernel load, rather than some potentially sensitive user information. We used to do this directly after the FPU state save, but that is actually very inconvenient, since it (a) corrupts what is potentially perfectly good FPU state that we might want to lazy avoid restoring later and (b) on x86-64 it resulted in a very annoying ordering constraint, where "__unlazy_fpu()" in the task switch needs to be delayed until after the DS segment has been reloaded just to get the new DS value. Coupling it to the fxrstor instead of the fxsave automatically avoids both of these issues, and also ensures that we only do it when actually necessary (the FP state after a save may never actually get used). It's simply a much more natural place for the leaked state cleanup. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Linus Torvalds 提交于
Yes, taking the trap to re-load the FPU/MMX state is expensive, but so is spending several days looking for a bug in the state save/restore code. And the preload code has some rather subtle interactions with both paravirtualization support and segment state restore, so it's not nearly as simple as it should be. Also, now that we no longer necessarily depend on a single bit (ie TS_USEDFPU) for keeping track of the state of the FPU, we migth be able to do better. If we are really switching between two processes that keep touching the FP state, save/restore is inevitable, but in the case of having one process that does most of the FPU usage, we may actually be able to do much better than the preloading. In particular, we may be able to keep track of which CPU the process ran on last, and also per CPU keep track of which process' FP state that CPU has. For modern CPU's that don't destroy the FPU contents on save time, that would allow us to do a lazy restore by just re-enabling the existing FPU state - with no restore cost at all! Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Linus Torvalds 提交于
This creates three helper functions that do the TS_USEDFPU accesses, and makes everybody that used to do it by hand use those helpers instead. In addition, there's a couple of helper functions for the "change both CR0.TS and TS_USEDFPU at the same time" case, and the places that do that together have been changed to use those. That means that we have fewer random places that open-code this situation. The intent is partly to clarify the code without actually changing any semantics yet (since we clearly still have some hard to reproduce bug in this area), but also to make it much easier to use another approach entirely to caching the CR0.TS bit for software accesses. Right now we use a bit in the thread-info 'status' variable (this patch does not change that), but we might want to make it a full field of its own or even make it a per-cpu variable. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Linus Torvalds 提交于
Touching TS_USEDFPU without touching CR0.TS is confusing, so don't do it. By moving it into the callers, we always do the TS_USEDFPU next to the CR0.TS accesses in the source code, and it's much easier to see how the two go hand in hand. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Linus Torvalds 提交于
Commit 5b1cbac3 ("i387: make irq_fpu_usable() tests more robust") added a sanity check to the #NM handler to verify that we never cause the "Device Not Available" exception in kernel mode. However, that check actually pinpointed a (fundamental) race where we do cause that exception as part of the signal stack FPU state save/restore code. Because we use the floating point instructions themselves to save and restore state directly from user mode, we cannot do that atomically with testing the TS_USEDFPU bit: the user mode access itself may cause a page fault, which causes a task switch, which saves and restores the FP/MMX state from the kernel buffers. This kind of "recursive" FP state save is fine per se, but it means that when the signal stack save/restore gets restarted, it will now take the '#NM' exception we originally tried to avoid. With preemption this can happen even without the page fault - but because of the user access, we cannot just disable preemption around the save/restore instruction. There are various ways to solve this, including using the "enable/disable_page_fault()" helpers to not allow page faults at all during the sequence, and fall back to copying things by hand without the use of the native FP state save/restore instructions. However, the simplest thing to do is to just allow the #NM from kernel space, but fix the race in setting and clearing CR0.TS that this all exposed: the TS bit changes and the TS_USEDFPU bit absolutely have to be atomic wrt scheduling, so while the actual state save/restore can be interrupted and restarted, the act of actually clearing/setting CR0.TS and the TS_USEDFPU bit together must not. Instead of just adding random "preempt_disable/enable()" calls to what is already excessively ugly code, this introduces some helper functions that mostly mirror the "kernel_fpu_begin/end()" functionality, just for the user state instead. Those helper functions should probably eventually replace the other ad-hoc CR0.TS and TS_USEDFPU tests too, but I'll need to think about it some more: the task switching functionality in particular needs to expose the difference between the 'prev' and 'next' threads, while the new helper functions intentionally were written to only work with 'current'. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 16 2月, 2012 6 次提交
-
-
由 Anton Blanchard 提交于
perf on POWER stopped working after commit e050e3f0 (perf: Fix broken interrupt rate throttling). That patch exposed a bug in the POWER perf_events code. Since the PMCs count upwards and take an exception when the top bit is set, we want to write 0x80000000 - left in power_pmu_start. We were instead programming in left which effectively disables the counter until we eventually hit 0x80000000. This could take seconds or longer. With the patch applied I get the expected number of samples: SAMPLE events: 9948 Signed-off-by: NAnton Blanchard <anton@samba.org> Acked-by: NPaul Mackerras <paulus@samba.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Cc: <stable@kernel.org>
-
由 Benjamin Herrenschmidt 提交于
Program Check exceptions are the result of WARNs, BUGs, some type of breakpoints, kprobe, and other illegal instructions. We want interrupts (and thus preemption) to remain disabled while doing the initial stage of testing the reason and branching off to a debugger or kprobe, so we are still on the original CPU which makes debugging easier in various cases. This is how the code was intended, hence the local_irq_enable() right in the middle of program_check_exception(). However, the assembly exception prologue for that exception was incorrectly marked as enabling interrupts, which defeats that (and records a redundant enable with lockdep). Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Stephen Rothwell 提交于
Since we are heading towards removing the Legacy iSeries platform, start by no longer building it for ppc64_defconfig. Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Benjamin Herrenschmidt 提交于
Upstream changes to the way PHB resources are registered broke the resource fixup for FSL boards. We can no longer rely on the resource pointer array for the PHB's pci_bus structure, so let's leave it alone and go straight for the PHB resources instead. This also makes the code generally more readable. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Ira Snyder 提交于
A kernel oops/panic prints an instruction dump showing several instructions before and after the instruction which caused the oops/panic. The code intended that the faulting instruction be enclosed in angle brackets, however a bug caused the faulting instruction to be interpreted by printk() as the message log level. To fix this, the KERN_CONT log level is added before the actual text of the printed message. === Before the patch === [ 1081.587266] Instruction dump: [ 1081.590236] 7c000110 7c0000f8 5400077c 552907f6 7d290378 992b0003 4e800020 38000001 [ 1081.598034] 3d20c03a 9009a114 7c0004ac 39200000 [ 1081.602500] 4e800020 3803ffd0 2b800009 <4>[ 1081.587266] Instruction dump: <4>[ 1081.590236] 7c000110 7c0000f8 5400077c 552907f6 7d290378 992b0003 4e800020 38000001 <4>[ 1081.598034] 3d20c03a 9009a114 7c0004ac 39200000 <98090000>[ 1081.602500] 4e800020 3803ffd0 2b800009 === After the patch === [ 51.385216] Instruction dump: [ 51.388186] 7c000110 7c0000f8 5400077c 552907f6 7d290378 992b0003 4e800020 38000001 [ 51.395986] 3d20c03a 9009a114 7c0004ac 39200000 <98090000> 4e800020 3803ffd0 2b800009 <4>[ 51.385216] Instruction dump: <4>[ 51.388186] 7c000110 7c0000f8 5400077c 552907f6 7d290378 992b0003 4e800020 38000001 <4>[ 51.395986] 3d20c03a 9009a114 7c0004ac 39200000 <98090000> 4e800020 3803ffd0 2b800009 Signed-off-by: NIra W. Snyder <iws@ovro.caltech.edu> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Linus Torvalds 提交于
The check for save_init_fpu() (introduced in commit 5b1cbac3: "i387: make irq_fpu_usable() tests more robust") was the wrong way around, but I hadn't noticed, because my "tests" were bogus: the FPU exceptions are disabled by default, so even doing a divide by zero never actually triggers this code at all unless you do extra work to enable them. So if anybody did enable them, they'd get one spurious warning. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 14 2月, 2012 11 次提交
-
-
EEH may happen during a PCI driver probe. If the driver is trying to access some register in a loop, the EEH code will try to print the driver name. But the driver pointer in struct pci_dev is not set until probe returns successfully. Use a function to test if the device and the driver pointer is NULL before accessing the driver's name. Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Brian King 提交于
This fixes a hang that was observed during live partition migration. Since stop_topology_update must not be called from an interrupt context, call it earlier in the migration process. The hang observed can be seen below: WARNING: at kernel/timer.c:1011 Modules linked in: ip6t_LOG xt_tcpudp xt_pkttype ipt_LOG xt_limit ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw xt_NOTRACK ipt_REJECT xt_state iptable_raw iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables ip6table_filter ip6_tables x_tables ipv6 fuse loop ibmveth sg ext3 jbd mbcache raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid10 raid1 raid0 scsi_dh_alua scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc dm_round_robin dm_multipath scsi_dh sd_mod crc_t10dif ibmvfc scsi_transport_fc scsi_tgt scsi_mod dm_snapshot dm_mod NIP: c0000000000c52d8 LR: c00000000004be28 CTR: 0000000000000000 REGS: c00000005ffd77d0 TRAP: 0700 Not tainted (3.2.0-git-00001-g07d106d0) MSR: 8000000000021032 <ME,CE,IR,DR> CR: 48000084 XER: 00000001 CFAR: c00000000004be20 TASK = c00000005ec78860[0] 'swapper/3' THREAD: c00000005ec98000 CPU: 3 GPR00: 0000000000000001 c00000005ffd7a50 c000000000fbbc98 c000000000ec8340 GPR04: 00000000282a0020 0000000000000000 0000000000004000 0000000000000101 GPR08: 0000000000000012 c00000005ffd4000 0000000000000020 c000000000f3ba88 GPR12: 0000000000000000 c000000007f40900 0000000000000001 0000000000000004 GPR16: 0000000000000001 0000000000000000 0000000000000000 c000000001022310 GPR20: 0000000000000001 0000000000000000 0000000000200200 c000000001029e14 GPR24: 0000000000000000 0000000000000001 0000000000000040 c00000003f74bc80 GPR28: c00000003f74bc84 c000000000f38038 c000000000f16b58 c000000000ec8340 NIP [c0000000000c52d8] .del_timer_sync+0x28/0x60 LR [c00000000004be28] .stop_topology_update+0x20/0x38 Call Trace: [c00000005ffd7a50] [c00000005ec78860] 0xc00000005ec78860 (unreliable) [c00000005ffd7ad0] [c00000000004be28] .stop_topology_update+0x20/0x38 [c00000005ffd7b40] [c000000000028378] .__rtas_suspend_last_cpu+0x58/0x260 [c00000005ffd7bf0] [c0000000000fa230] .generic_smp_call_function_interrupt+0x160/0x358 [c00000005ffd7cf0] [c000000000036ec8] .smp_ipi_demux+0x88/0x100 [c00000005ffd7d80] [c00000000005c154] .icp_hv_ipi_action+0x5c/0x80 [c00000005ffd7e00] [c00000000012a088] .handle_irq_event_percpu+0x100/0x318 [c00000005ffd7f00] [c00000000012e774] .handle_percpu_irq+0x84/0xd0 [c00000005ffd7f90] [c000000000022ba8] .call_handle_irq+0x1c/0x2c [c00000005ec9ba20] [c00000000001157c] .do_IRQ+0x22c/0x2a8 [c00000005ec9bae0] [c0000000000054bc] hardware_interrupt_entry+0x18/0x1c Exception: 501 at .cpu_idle+0x194/0x2f8 LR = .cpu_idle+0x194/0x2f8 [c00000005ec9bdd0] [c000000000017e58] .cpu_idle+0x188/0x2f8 (unreliable) [c00000005ec9be90] [c00000000067ec18] .start_secondary+0x3e4/0x524 [c00000005ec9bf90] [c0000000000093e8] .start_secondary_prolog+0x10/0x14 Instruction dump: ebe1fff8 4e800020 fbe1fff8 7c0802a6 f8010010 7c7f1b78 f821ff81 78290464 80090014 5400019e 7c0000d0 78000fe0 <0b000000> 4800000c 7c210b78 7c421378 Signed-off-by: NBrian King <brking@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Michael Ellerman 提交于
We need to disable interrupts when taking the phb->lock. Otherwise we could deadlock with pci_lock taken from an interrupt. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Benjamin Herrenschmidt 提交于
We use __get_cpu_var() which triggers a false positive warning in smp_processor_id() thinking interrupts are enabled (at this point, they are soft-enabled but hard-disabled). Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Benjamin Herrenschmidt 提交于
We call the cache_hwirq_map() function with a linux IRQ number but it expects a HW irq number. This triggers a BUG on multic-chip setups in addition to not doing the right thing. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Srikar Dronamraju 提交于
With this change, helpers such as instruction_pointer() et al, get defined in the generic header in terms of GET_IP Removed the unnecessary definition of profile_pc in !CONFIG_SMP case as suggested by Mike Frysinger. Signed-off-by: NSrikar Dronamraju <srikar@linux.vnet.ibm.com> Signed-off-by: NAnanth N Mavinakayanahalli <ananth@in.ibm.com> Acked-by: NMike Frysinger <vapier@gentoo.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Benjamin Herrenschmidt 提交于
It appears that on the Chroma card, the class code of the root complex is still wrong even on DD2 or later chips. This could be a firmware issue, but that breaks resource allocation so let's unconditionally fix it up. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Linus Torvalds 提交于
Some code - especially the crypto layer - wants to use the x86 FP/MMX/AVX register set in what may be interrupt (typically softirq) context. That *can* be ok, but the tests for when it was ok were somewhat suspect. We cannot touch the thread-specific status bits either, so we'd better check that we're not going to try to save FP state or anything like that. Now, it may be that the TS bit is always cleared *before* we set the USEDFPU bit (and only set when we had already cleared the USEDFP before), so the TS bit test may actually have been sufficient, but it certainly was not obviously so. So this explicitly verifies that we will not touch the TS_USEDFPU bit, and adds a few related sanity-checks. Because it seems that somehow AES-NI is corrupting user FP state. The cause is not clear, and this patch doesn't fix it, but while debugging it I really wanted the code to be more obviously correct and robust. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Linus Torvalds 提交于
It was marked asmlinkage for some really old and stale legacy reasons. Fix that and the equally stale comment. Noticed when debugging the irq_fpu_usable() bugs. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
Driver at91_ide is broken and should not be fixed: remove it. Modification of device files that where making use of it. The PATA driver (pata_at91) is able to replace at91_ide. Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
SMC, Static Memory Controller will need more accessors to fine configure its parameters. Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
- 13 2月, 2012 12 次提交
-
-
由 Nicolas Ferre 提交于
Registration of at91_udc as a module will enable SoC related code. Fix following an idea from Karel Znamenacek. Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com> Acked-by: NKarel Znamenacek <karel@ryston.cz> Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Cc: stable <stable@vger.kernel.org>
-
由 Russell King 提交于
It's useful to print the error code when a called function fails so a diagnosis of why it failed is possible. In this case, it fails because we try to register some data for the wl12xx driver, but as the driver is not configured, a stub function is used which simply returns -ENOSYS. Let's do the simple thing for -rc and print the error code. Also, the return code from platform_register_device() at each of these sites was not being checked. Add some checking, and again print the error code. This should be fixed properly for the next merge window so we don't issue error messages merely because a driver is not configured. Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
While trying to debug my OMAP platforms, they emitted this message: omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state The following backtrace said it was from a function called '_enable', which didn't provide much clue. Grepping didn't find it either. The message is wrapped, so unwrap the message so grep can find it. Do the same for three other messages in this file. Acked-by: NPaul Walmsley <paul@pwsan.com> Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
The previous commit causes new section mismatch warnings: WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb30): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_gpio() The function omap_init_hsmmc() references the function __init omap_mux_init_gpio(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_gpio is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb4c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_gpio() The function omap_init_hsmmc() references the function __init omap_mux_init_gpio(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_gpio is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb60): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb6c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb78): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb90): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb9c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdba8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbc0): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbcc): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbd8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbf8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc04): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc10): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc28): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc34): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc40): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc58): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc64): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc70): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc7c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal() The function omap_init_hsmmc() references the function __init omap_mux_init_signal(). This is often because omap_init_hsmmc lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. Again, as for omap2_hsmmc_init(), these functions are callable at runtime via the gpio-twl4030.c driver, and so these can't be marked __init. Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xd0f0): Section mismatch in reference from the function sdp3430_twl_gpio_setup() to the function .init.text:omap2_hsmmc_init() The function sdp3430_twl_gpio_setup() references the function __init omap2_hsmmc_init(). This is often because sdp3430_twl_gpio_setup lacks a __init annotation or the annotation of omap2_hsmmc_init is wrong. sdp3430_twl_gpio_setup() is called via platform data from the gpio-twl4030 module, which can be inserted and removed at runtime. This makes sdp3430_twl_gpio_setup() callable at runtime, and prevents it being marked with an __init annotation. As it calls omap2_hsmmc_init() unconditionally, the only resolution to this warning is to remove the __init markings from omap2_hsmmc_init() and its called functions. This addresses the functions in hsmmc.c. Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xb798): Section mismatch in reference from the function omap_4430sdp_display_init() to the function .init.text:omap_display_init() The function omap_4430sdp_display_init() references the function __init omap_display_init(). This is often because omap_4430sdp_display_init lacks a __init annotation or the annotation of omap_display_init is wrong. Fix this by adding __init to omap_4430sdp_display_init(). Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
WARNING: vmlinux.o(.text+0x1c664): Section mismatch in reference from the function omap_secondary_startup() to the function .cpuinit.text:secondary_startup() The function omap_secondary_startup() references the function __cpuinit secondary_startup(). This is often because omap_secondary_startup lacks a __cpuinit annotation or the annotation of secondary_startup is wrong. Unfortunately, fixing this causes a new warning which is harder to solve: WARNING: arch/arm/mach-omap2/built-in.o(.text+0x5328): Section mismatch in reference from the function omap4_hotplug_cpu() to the function .cpuinit.text:omap_secondary_startup() The function omap4_hotplug_cpu() references the function __cpuinit omap_secondary_startup(). This is often because omap4_hotplug_cpu lacks a __cpuinit annotation or the annotation of omap_secondary_startup is wrong. because omap4_hotplug_cpu() is used by power management code as well, which may not end up using omap_secondary_startup(). Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Found by review. omap4_sdp4430_wifi_mux_init() is called by an __init marked function, and only calls omap_mux_init_gpio() and omap_mux_init_signal() which are both also an __init marked functions. The only reason this doesn't issue a warning is because the compiler inlines omap4_sdp4430_wifi_mux_init() into omap4_sdp4430_wifi_init(). So, lets add the __init annotation to ensure this remains safe should the compiler choose not to inline. Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x15a4): Section mismatch in reference from the function omap_mux_init_signals() to the function .init.text:omap_mux_init_signal() The function omap_mux_init_signals() references the function __init omap_mux_init_signal(). This is often because omap_mux_init_signals lacks a __init annotation or the annotation of omap_mux_init_signal is wrong. Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
On my OMAP4 platform, I'm getting this error message repeated several times at boot: omap_vc_i2c_init: I2C config for all channels must match. omap_vc_i2c_init: I2C config for all channels must match. This doesn't help identify what the problem is. Fix this message to be more informative: omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0). omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels (0). This allows us to identify which voltage domains have a problem, and what the I2C configuration state (a boolean, i2c_high_speed) setting being used actually is. From this we find that omap4_core_pmic has i2c_high_speed false, but omap4_iva_pmic and omap4_mpu_pmic both have it set true. Acked-by: NTony Lindgren <tony@atomide.com> Acked-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
While testing on my OMAP3430 platform, this error message was emitted: omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc Trying to find this message was difficult because it was wrapped across several lines. It also mis-spells "required", doesn't read very well, and has spaces lacking. Let's replace it with a more concise: omap_vc_init_channel: No PMIC info for vdd_core While we're here, fix a simple spelling error in a comment. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
When CONFIG_OF is disabled, the compile fails with: arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function) Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-