- 10 10月, 2011 8 次提交
-
-
由 Robert Richter 提交于
This patch implements IBS feature detection and initialzation. The code is shared between perf and oprofile. If IBS is available on the system for perf, a pmu is setup. Signed-off-by: NRobert Richter <robert.richter@amd.com> Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1316597423-25723-3-git-send-email-robert.richter@amd.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Robert Richter 提交于
Moving IBS macros from oprofile to <asm/perf_event.h> to make it available to perf. No additional changes. Signed-off-by: NRobert Richter <robert.richter@amd.com> Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1316597423-25723-2-git-send-email-robert.richter@amd.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Don Zickus 提交于
Now that the NMI handler are broken into lists, increment the appropriate stats for each list. This allows us to see what is going on when they get printed out in the next patch. Signed-off-by: NDon Zickus <dzickus@redhat.com> Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1317409584-23662-6-git-send-email-dzickus@redhat.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Don Zickus 提交于
Previous patches allow the NMI subsystem to process multipe NMI events in one NMI. As previously discussed this can cause issues when an event triggered another NMI but is processed in the current NMI. This causes the next NMI to go unprocessed and become an 'unknown' NMI. To handle this, we first have to flag whether or not the NMI handler handled more than one event or not. If it did, then there exists a chance that the next NMI might be already processed. Once the NMI is flagged as a candidate to be swallowed, we next look for a back-to-back NMI condition. This is determined by looking at the %rip from pt_regs. If it is the same as the previous NMI, it is assumed the cpu did not have a chance to jump back into a non-NMI context and execute code and instead handled another NMI. If both of those conditions are true then we will swallow any unknown NMI. There still exists a chance that we accidentally swallow a real unknown NMI, but for now things seem better. An optimization has also been added to the nmi notifier rountine. Because x86 can latch up to one NMI while currently processing an NMI, we don't have to worry about executing _all_ the handlers in a standalone NMI. The idea is if multiple NMIs come in, the second NMI will represent them. For those back-to-back NMI cases, we have the potentail to drop NMIs. Therefore only execute all the handlers in the second half of a detected back-to-back NMI. Signed-off-by: NDon Zickus <dzickus@redhat.com> Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1317409584-23662-5-git-send-email-dzickus@redhat.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Don Zickus 提交于
Just convert all the files that have an nmi handler to the new routines. Most of it is straight forward conversion. A couple of places needed some tweaking like kgdb which separates the debug notifier from the nmi handler and mce removes a call to notify_die. [Thanks to Ying for finding out the history behind that mce call https://lkml.org/lkml/2010/5/27/114 And Boris responding that he would like to remove that call because of it https://lkml.org/lkml/2011/9/21/163] The things that get converted are the registeration/unregistration routines and the nmi handler itself has its args changed along with code removal to check which list it is on (most are on one NMI list except for kgdb which has both an NMI routine and an NMI Unknown routine). Signed-off-by: NDon Zickus <dzickus@redhat.com> Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl> Acked-by: NCorey Minyard <minyard@acm.org> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Robert Richter <robert.richter@amd.com> Cc: Huang Ying <ying.huang@intel.com> Cc: Corey Minyard <minyard@acm.org> Cc: Jack Steiner <steiner@sgi.com> Link: http://lkml.kernel.org/r/1317409584-23662-4-git-send-email-dzickus@redhat.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Don Zickus 提交于
The NMI handlers used to rely on the notifier infrastructure. This worked great until we wanted to support handling multiple events better. One of the key ideas to the nmi handling is to process _all_ the handlers for each NMI. The reason behind this switch is because NMIs are edge triggered. If enough NMIs are triggered, then they could be lost because the cpu can only latch at most one NMI (besides the one currently being processed). In order to deal with this we have decided to process all the NMI handlers for each NMI. This allows the handlers to determine if they recieved an event or not (the ones that can not determine this will be left to fend for themselves on the unknown NMI list). As a result of this change it is now possible to have an extra NMI that was destined to be received for an already processed event. Because the event was processed in the previous NMI, this NMI gets dropped and becomes an 'unknown' NMI. This of course will cause printks that scare people. However, we prefer to have extra NMIs as opposed to losing NMIs and as such are have developed a basic mechanism to catch most of them. That will be a later patch. To accomplish this idea, I unhooked the nmi handlers from the notifier routines and created a new mechanism loosely based on doIRQ. The reason for this is the notifier routines have a couple of shortcomings. One we could't guarantee all future NMI handlers used NOTIFY_OK instead of NOTIFY_STOP. Second, we couldn't keep track of the number of events being handled in each routine (most only handle one, perf can handle more than one). Third, I wanted to eventually display which nmi handlers are registered in the system in /proc/interrupts to help see who is generating NMIs. The patch below just implements the new infrastructure but doesn't wire it up yet (that is the next patch). Its design is based on doIRQ structs and the atomic notifier routines. So the rcu stuff in the patch isn't entirely untested (as the notifier routines have soaked it) but it should be double checked in case I copied the code wrong. Signed-off-by: NDon Zickus <dzickus@redhat.com> Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1317409584-23662-3-git-send-email-dzickus@redhat.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Don Zickus 提交于
The nmi stuff is changing a lot and adding more functionality. Split it out from the traps.c file so it doesn't continue to pollute that file. This makes it easier to find and expand all the future nmi related work. No real functional changes here. Signed-off-by: NDon Zickus <dzickus@redhat.com> Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1317409584-23662-2-git-send-email-dzickus@redhat.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Gleb Natapov 提交于
Intel does not have guest/host-only bit in perf counters like AMD does. To support GO/HO bits KVM needs to switch EVENTSELn values (or PERF_GLOBAL_CTRL if available) at a guest entry. If a counter is configured to count only in a guest mode it stays disabled in a host, but VMX is configured to switch it to enabled value during guest entry. This patch adds GO/HO tracking to Intel perf code and provides interface for KVM to get a list of MSRs that need to be switched on a guest entry. Only cpus with architectural PMU (v1 or later) are supported with this patch. To my knowledge there is not p6 models with VMX but without architectural PMU and p4 with VMX are rare and the interface is general enough to support them if need arise. Signed-off-by: NGleb Natapov <gleb@redhat.com> Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1317816084-18026-7-git-send-email-gleb@redhat.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
-
- 06 10月, 2011 1 次提交
-
-
由 Joerg Roedel 提交于
The AMD perf-counters support counting in guest or host-mode only. Make use of that feature when user-space specified guest/host-mode only counting. Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com> Signed-off-by: NGleb Natapov <gleb@redhat.com> Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1317816084-18026-3-git-send-email-gleb@redhat.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
-
- 30 9月, 2011 2 次提交
-
-
由 Benjamin Herrenschmidt 提交于
Apple Quad G5 has some oddity in it's device-tree which causes the new generic matching code to fail to relate nodes for PCI-E devices below U4 with their respective struct pci_dev. This breaks graphics on those machines among others. This fixes it using a quirk which copies the node pointer from the host bridge for the root complex, which makes the generic code work for the children afterward. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 David S. Miller 提交于
In the OF 'translations' property, the template TTEs in the mappings never specify the executable bit. This is the case even though some of these mappings are for OF's code segment. Therefore, we need to force the execute bit on in every mapping. This problem can only really trigger on Niagara/sun4v machines and the history behind this is a little complicated. Previous to sun4v, the sun4u TTE entries lacked a hardware execute permission bit. So OF didn't have to ever worry about setting anything to handle executable pages. Any valid TTE loaded into the I-TLB would be respected by the chip. But sun4v Niagara chips have a real hardware enforced executable bit in their TTEs. So it has to be set or else the I-TLB throws an instruction access exception with type code 6 (protection violation). We've been extremely fortunate to not get bitten by this in the past. The best I can tell is that the OF's mappings for it's executable code were mapped using permanent locked mappings on sun4v in the past. Therefore, the fact that we didn't have the exec bit set in the OF translations we would use did not matter in practice. Thanks to Greg Onufer for helping me track this down. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 28 9月, 2011 1 次提交
-
-
由 Randy Dunlap 提交于
Fix (rare) build error by adding <asm/apicdef.h> header file: arch/x86/kernel/cpu/perf_event_amd.c:350:2: error: 'BAD_APICID' undeclared (first use in this function) Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net> Cc: Robert Richter <robert.richter@amd.com> Cc: Andre Przywara <andre.przywara@amd.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Link: http://lkml.kernel.org/r/4E820138.90301@xenotime.netSigned-off-by: NIngo Molnar <mingo@elte.hu>
-
- 27 9月, 2011 2 次提交
-
-
由 Sylwester Nawrocki 提交于
The sclk_cam clocks are now controlled by the top level FIMC media device driver bound to "s5p-fimc-md" platform device. Rename sclk_cam clocks so they accessible by the corresponding driver. Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
-
由 Sylwester Nawrocki 提交于
The sclk_cam clocks are now controlled by the top level FIMC media device driver bound to "s5p-fimc-md" platform device. Rename sclk_cam clocks so they accessible by the corresponding driver. Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
-
- 26 9月, 2011 9 次提交
-
-
由 Carsten Otte 提交于
If gmap_unmap_segment figures that the segment was not mapped in the first place, it need to up mmap_sem on exit. Cc: <stable@kernel.org> Signed-off-by: NCarsten Otte <cotte@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Martin Schwidefsky 提交于
Analog to git commit 59e4c3a2 do not clear the additional personality flags on exec. We need to inherit the personality bits in PER_MASK across exec. Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Will Deacon 提交于
The SMP implementation of __futex_atomic_op clobbers oldval with the status flag from the exclusive store. This causes it to always read as zero when performing the FUTEX_OP_CMP_* operation. This patch updates the ARM __futex_atomic_op implementations to take a tmp argument, allowing us to store the strex status flag without overwriting the register containing oldval. Cc: stable@kernel.org Reported-by: NMinho Ban <mhban@samsung.com> Reviewed-by: NNicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Kevin Winchester 提交于
The CPU support for perf events on x86 was implemented via included C files with #ifdefs. Clean this up by creating a new header file and compiling the vendor-specific files as needed. Signed-off-by: NKevin Winchester <kjwinchester@gmail.com> Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1314747665-2090-1-git-send-email-kjwinchester@gmail.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Russell King 提交于
If the attempt to map a page for DMA fails (eg, because we're out of mapping space) then we must not hold on to the page we allocated for DMA - doing so will result in a memory leak. Cc: <stable@kernel.org> Reported-by: NBryan Phillippe <bp@darkforest.org> Tested-by: NBryan Phillippe <bp@darkforest.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Marek Szyprowski 提交于
Loop iterator value after terminating list_for_each_entry() is not NULL. This patch fixes incorrect iterator usage in GPIO interrupt code for SAMSUNG S5P platforms. Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
-
由 Heiko Stuebner 提交于
The changed statement should set the old armdiv bits to 0 and not everything else, before setting the new value. Signed-off-by: NHeiko Stuebner <heiko@sntech.de> Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
-
由 Avi Kivity 提交于
Src2CL decode (used for double width shifts) erronously decodes only bit 3 of %rcx, instead of bits 7:0. Fix by decoding %cl in its entirety. Signed-off-by: NAvi Kivity <avi@redhat.com> Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
-
由 Zhao Jin 提交于
__update_clear_spte_slow should return original spte while the current code returns low half of original spte combined with high half of new spte. Signed-off-by: NZhao Jin <cronozhj@gmail.com> Reviewed-by: NXiao Guangrong <xiaoguangrong@cn.fujitsu.com> Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
-
- 22 9月, 2011 1 次提交
-
-
由 David S. Miller 提交于
If "-p" is given on the command line, clear the CON_BOOT flag for the initial early boot PROM console. This is necessary to try and see crash messages that occur between the registry of the VT console and the probing of the first framebuffer or serial console. During this time no console messages are emitted because the VT console registry (even if no backend is registered to it) removes the early console if CON_BOOT is set. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 21 9月, 2011 5 次提交
-
-
由 Matt Fleming 提交于
A deadlock was introduced on x86 in commit ef68c8f8 ("x86: Serialize EFI time accesses on rtc_lock") because efi_get_time() and friends can be called with rtc_lock already held by read_persistent_time(), e.g.: timekeeping_init() read_persistent_clock() <-- acquire rtc_lock efi_get_time() phys_efi_get_time() <-- acquire rtc_lock <DEADLOCK> To fix this let's push the locking down into the get_wallclock() and set_wallclock() implementations. Only the clock implementations that access the x86 RTC directly need to acquire rtc_lock, so it makes sense to push the locking down into the rtc, vrtc and efi code. The virtualization implementations don't require rtc_lock to be held because they provide their own serialization. Signed-off-by: NMatt Fleming <matt.fleming@intel.com> Acked-by: NJan Beulich <jbeulich@novell.com> Acked-by: Avi Kivity <avi@redhat.com> [for the virtualization aspect] Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Josh Boyer <jwboyer@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Mathias Krause 提交于
The address limit is already set in flush_old_exec() so this assignment of USER_DS is redundant. Signed-off-by: NMathias Krause <minipli@googlemail.com> Cc: David Miller <davem@davemloft.net> Signed-off-by: NAndrew Morton <akpm@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Russell King 提交于
We are seeing linker errors caused by sections being discarded, despite the linker script trying to keep them. The result is (eg): `.exit.text' referenced in section `.alt.smp.init' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o `.exit.text' referenced in section `.alt.smp.init' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o This is the relevent part of the linker script (reformatted to make it clearer): | SECTIONS | { | /* | * unwind exit sections must be discarded before the rest of the | * unwind sections get included. | */ | /DISCARD/ : { | *(.ARM.exidx.exit.text) | *(.ARM.extab.exit.text) | } | ... | .exit.text : { | *(.exit.text) | *(.memexit.text) | } | ... | /DISCARD/ : { | *(.exit.text) | *(.memexit.text) | *(.exit.data) | *(.memexit.data) | *(.memexit.rodata) | *(.exitcall.exit) | *(.discard) | *(.discard.*) | } | } Now, this is what the linker manual says about discarded output sections: | The special output section name `/DISCARD/' may be used to discard | input sections. Any input sections which are assigned to an output | section named `/DISCARD/' are not included in the output file. No questions, no exceptions. It doesn't say "unless they are listed before the /DISCARD/ section." Now, this is what asn-generic/vmlinux.lds.S says: | /* | * Default discarded sections. | * | * Some archs want to discard exit text/data at runtime rather than | * link time due to cross-section references such as alt instructions, | * bug table, eh_frame, etc. DISCARDS must be the last of output | * section definitions so that such archs put those in earlier section | * definitions. | */ And guess what - the list _always_ includes .exit.text etc. Now, what's actually happening is that the linker is reading the script, and it finds the first /DISCARD/ output section at the beginning of the script. It continues reading the script, and finds the 'DISCARD' macro at the end, which having been postprocessed results in another /DISCARD/ output section. As the linker already contains the earlier /DISCARD/ output section, it adds it to that existing section, so it effectively is placed at the start. This can be seen by using the -M option to ld: | Linker script and memory map | | 0xc037c080 jiffies = jiffies_64 | | /DISCARD/ | *(.ARM.exidx.exit.text) | *(.ARM.extab.exit.text) | *(.exit.text) | *(.memexit.text) | *(.exit.data) | *(.memexit.data) | *(.memexit.rodata) | *(.exitcall.exit) | *(.discard) | *(.discard.*) | | 0xc0008000 . = 0xc0008000 | | .head.text 0xc0008000 0x1d0 | 0xc0008000 _text = . | *(.head.text) | .head.text 0xc0008000 0x1d0 arch/arm/kernel/head.o | 0xc0008000 stext | | .text 0xc0008200 0x2d78d0 | 0xc0008200 _stext = . | 0xc0008200 __exception_text_start = . | *(.exception.text) | .exception.text | ... As you can see, all the discarded sections are grouped together - and as a result of it being the first output section, they all appear before any other section. The result is that not only is the unwind information discarded (as intended), but also the .exit.text, despite us wanting to have the .exit.text preserved. We can't move the unwind information elsewhere, because it'll then be included even when we do actually discard the .exit.text (and similar) sections. So, work around this by avoiding the generic DISCARDS macro, and instead conditionalize the sections to be discarded ourselves. This avoids the ambiguity in how the linker assigns input sections to output sections, making our script less dependent on undocumented linker behaviour. Reported-by: NRob Herring <robherring2@gmail.com> Tested-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Linus Walleij 提交于
The changes introduced in commit cc22b4c1 "ARM: set vga memory base at run-time" Makes the Integrator/AP freeze completely. I appears that this is due to the VGA base address being assigned at PCI init time, while this base is needed earlier than that. Moving the initialization of the base address to the .map_io function solves this problem. Cc: Rob Herring <rob.herring@calxeda.com> Cc: Nicolas Pitre <nicolas.pitre@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com> Acked-by: NRob Herring <rob.herring@calxeda.com> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Stephen Warren 提交于
The bindings were recently updated to have separate properties for each type of GPIO. Update the Device Tree source to match that. Signed-off-by: NStephen Warren <swarren@nvidia.com> Acked-by: NOlof Johansson <olof@lixom.net> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 20 9月, 2011 2 次提交
-
-
由 Christian Borntraeger 提交于
598841ca ([S390] use gmap address spaces for kvm guest images) changed kvm on s390 to use a separate address space for kvm guests. We can now put KVM guests anywhere in the user address mode with a size up to 8PB - as long as the memory is 1MB-aligned. This change was done without KVM extension capability bit. The change was added after 3.0, but we still have a chance to add a feature bit before 3.1 (keeping the releases in a sane state). We use number 71 to avoid collisions with other pending kvm patches as requested by Alexander Graf. Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com> Acked-by: NAvi Kivity <avi@redhat.com> Cc: Alexander Graf <agraf@suse.de> Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
-
由 Christian Borntraeger 提交于
598841ca ([S390] use gmap address spaces for kvm guest images) changed kvm to use a separate address space for kvm guests. This address space was switched in __vcpu_run In some cases (preemption, page fault) there is the possibility that this address space switch is lost. The typical symptom was a huge amount of validity intercepts or random guest addressing exceptions. Fix this by doing the switch in sie_loop and sie_exit and saving the address space in the gmap structure itself. Also use the preempt notifier. Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com> Acked-by: NAvi Kivity <avi@redhat.com> Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
-
- 17 9月, 2011 3 次提交
-
-
由 Russell King 提交于
CALL scripts/checksyscalls.sh <stdin>:46:1: warning: "__IGNORE_migrate_pages" redefined In file included from <stdin>:2: arch/arm/include/asm/unistd.h:482:1: warning: this is the location of the previous definition This is caused because we define __IGNORE_migrate_pages to be 1, but in the case of nommu, it's defined to be empty. Fix this by just defining the __IGNORE_ symbols to be empty. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Will Deacon 提交于
This patch implements a workaround for erratum 764369 affecting Cortex-A9 MPCore with two or more processors (all current revisions). Under certain timing circumstances, a data cache line maintenance operation by MVA targeting an Inner Shareable memory region may fail to proceed up to either the Point of Coherency or to the Point of Unification of the system. This workaround adds a DSB instruction before the relevant cache maintenance functions and sets a specific bit in the diagnostic control register of the SCU. Cc: <stable@kernel.org> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com> Tested-by: NMark Rutland <mark.rutland@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 David S. Miller 提交于
Recognize T4 and T5 chips. Treating them both as "T2 plus other stuff" should be extremely safe and make sure distributions will work when those chips actually ship to customers. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 16 9月, 2011 1 次提交
-
-
由 Linus Torvalds 提交于
On x86-64, they were just wasteful: with the explicitly added (now unnecessary) padding, the size of the alternatives structure was 16 bytes, and an alignment of 8 bytes didn't hurt much. However, it was still silly, since the natural size and alignment for the structure is actually just 12 bytes, 4-byte aligned since commit 59e97e4d ("x86: Make alternative instruction pointers relative"). So removing the padding, and removing the extra alignment is just a good idea. On x86-32, the alignment of 4 bytes was correct, but was incorrectly hardcoded as 8 bytes in <asm/alternative-asm.h>. That header file had used to be an x86-64 only header file, but various unification efforts have made it be used for x86-32 too (ie the unification of rwlock and rwsem). That in turn caused x86-32 boot failures, because the extra alignment would result in random zero-filled words in the altinstructions section, causing oopses early at boot when doing alternative instruction replacement. So just remove all the alignment noise entirely. It's wrong, and it's unnecessary. The section itself is already properly aligned by the linker scripts, and all additions to the section had better be of the proper 12-byte format, keeping it aligned. So if the align directive were to ever make a difference, that would be an indication of a serious bug to begin with. Reported-by: NWerner Landgraf <w.landgraf@ru.r> Acked-by: NAndrew Lutomirski <luto@mit.edu> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 15 9月, 2011 5 次提交
-
-
由 Jan Beulich 提交于
The numbers obtained from the hypervisor really can't ever lead to an overflow here, only the original calculation going through the order of the range could have. This avoids the (as Jeremy points outs) somewhat ugly NULL-based calculation here. Signed-off-by: NJan Beulich <jbeulich@novell.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
由 Thomas Abraham 提交于
The keypad controller requires a external pull-up for all the keypad row lines. Fix the incorrect pad configuration for keypad controller row lines by enabling the pad pull-up for the all row lines of the keypad controller. Signed-off-by: NThomas Abraham <thomas.abraham@linaro.org> Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
-
由 Kukjin Kim 提交于
The plat/clock.h revised to prevent declaring duplicated. Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
-
由 Marek Szyprowski 提交于
clkdev framework uses global mutex to protect clock tree, so it is not possible to call clk_get() in interrupt context. This patch fixes this issue and makes system reset by watchdog call working again. Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
-
由 Banajit Goswami 提交于
According to commit 96d78686("ARM: S3C64XX: Add PWM backlight support on SMDK6410") and commit f00207b2("ARM: SAMSUNG: Create a common infrastructure for PWM backlight support"), this should not be used anymore. And this patch fixes follwing warning: arch/arm/mach-s3c64xx/mach-smdk6410.c:296: warning: 'smdk6410_backlight_device' defined but not used Signed-off-by: NBanajit Goswami <banajit.g@samsung.com> [kgene.kim@samsung.com: modified commit message] Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
-