- 11 Feb, 2013 11 commits
-
-
Jan Luebbe authored
commit 72fca4a4 upstream. Previously the alarm event was not propagated into the RTC subsystem. By adding a call to rtc_update_irq, this fixes a timeout problem with the hwclock utility. Signed-off-by:
Jan Luebbe <jlu@pengutronix.de> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Vyacheslav Dubeyko authored
commit a9bae189 upstream. There exists a situation when GC can work in background alone without any other filesystem activity during significant time. The nilfs_clean_segments() method calls nilfs_segctor_construct() that updates superblocks in the case of NILFS_SC_SUPER_ROOT and THE_NILFS_DISCONTINUED flags are set. But when GC is working alone the nilfs_clean_segments() is called with unset THE_NILFS_DISCONTINUED flag. As a result, the update of superblocks doesn't occurred all this time and in the case of SPOR superblocks keep very old values of last super root placement. SYMPTOMS: Trying to mount a NILFS2 volume after SPOR in such environment ends with very long mounting time (it can achieve about several hours in some cases). REPRODUCING PATH: 1. It needs to use external USB HDD, disable automount and doesn't make any additional filesystem activity on the NILFS2 volume. 2. Generate temporary file with size about 100 - 500 GB (for example, dd if=/dev/zero of=<file_name> bs=1073741824 count=200). The size of file defines duration of GC working. 3. Then it needs to delete file. 4. Start GC manually by means of command "nilfs-clean -p 0". When you start GC by means of such way then, at the end, superblocks is updated by once. So, for simulation of SPOR, it needs to wait sometime (15 - 40 minutes) and simply switch off USB HDD manually. 5. Switch on USB HDD again and try to mount NILFS2 volume. As a result, NILFS2 volume will mount during very long time. REPRODUCIBILITY: 100% FIX: This patch adds checking that superblocks need to update and set THE_NILFS_DISCONTINUED flag before nilfs_clean_segments() call. Reported-by:
Sergey Alexandrov <splavgm@gmail.com> Signed-off-by:
Vyacheslav Dubeyko <slava@dubeyko.com> Tested-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Tested-by:
-
Shawn Bohrer authored
commit aa7f6730 upstream. When the system has multiple domains do_sched_rt_period_timer() can run on any CPU and may iterate over all rt_rq in cpu_online_mask. This means when balance_runtime() is run for a given rt_rq that rt_rq may be in a different rd than the current processor. Thus if we use smp_processor_id() to get rd in do_balance_runtime() we may borrow runtime from a rt_rq that is not part of our rd. This changes do_balance_runtime to get the rd from the passed in rt_rq ensuring that we borrow runtime only from the correct rd for the given rt_rq. This fixes a BUG at kernel/sched/rt.c:687! in __disable_runtime when we try reclaim runtime lent to other rt_rq but runtime has been lent to a rt_rq in another rd. Signed-off-by:
Shawn Bohrer <sbohrer@rgmadvisors.com> Acked-by:
Steven Rostedt <rostedt@goodmis.org> Acked-by:
Mike Galbraith <bitbucket@online.de> Cc: peterz@infradead.org Link: http://lkml.kernel.org/r/1358186131-29494-1-git-send-email-sbohrer@rgmadvisors.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Jan Beulich authored
commit 40a1ef95 upstream. For some reason they didn't get replaced so far by their paravirt equivalents, resulting in code to be run with interrupts disabled that doesn't expect so (causing, in the observed case, a BUG_ON() to trigger) when syscall auditing is enabled. David (Cc-ed) came up with an identical fix, so likely this can be taken to count as an ack from him. Reported-by:
Peter Moody <pmoody@google.com> Signed-off-by:
Jan Beulich <jbeulich@suse.com> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Link: http://lkml.kernel.org/r/5108E01902000078000BA9C5@nat28.tlf.novell.comSigned-off-by:
-
liu chuansheng authored
commit f2d68cf4 upstream. When kzalloc() failed in radeon_user_framebuffer_create(), need to call object_unreference() to match the object_reference(). Signed-off-by:
liu chuansheng <chuansheng.liu@intel.com> Signed-off-by:
xueminsu <xuemin.su@intel.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit fd5d93a0 upstream. If the requested number of DWs on the ring is larger than the size of the ring itself, return an error. In testing with large VM updates, we've seen crashes when we try and allocate more space on the ring than the total size of the ring without checking. This prevents the crash but for large VM updates or bo moves of very large buffers, we will need to break the transaction down into multiple batches. I have patches to use IBs for the next kernel. Signed-off-by:
-
Christopher Staite authored
commit bb588820 upstream. Force the crtc mem requests on/off immediately rather than waiting for the double buffered updates to kick in. Seems we miss the update in certain conditions. Also handle the DCE6 case. Signed-off-by:
Christopher Staite <chris@yourdreamnet.co.uk> Signed-off-by:
-
Alex Deucher authored
commit 9200ee49 upstream. vbios says external TMDS while the board is actually internal TMDS. fixes: https://bugs.freedesktop.org/show_bug.cgi?id=60037Signed-off-by:
-
Alex Deucher authored
commit 674a16f2 upstream. Newer versions of mesa emit this. Signed-off-by:
-
Alex Deucher authored
commit ed39fadd upstream. Some chips seem to need a little delay after blacking out the MC before the requests actually stop. May fix: https://bugs.freedesktop.org/show_bug.cgi?id=56139 https://bugs.freedesktop.org/show_bug.cgi?id=57567Signed-off-by:
-
YOSHIFUJI Hideaki authored
commit 7810cc1e upstream. digsig_verify_rsa() does not free kmalloc'ed buffer returned by mpi_get_buffer(). Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
Dmitry Kasatkin <dmitry.kasatkin@intel.com> Signed-off-by:
James Morris <james.l.morris@oracle.com> Signed-off-by:
-
- 04 Feb, 2013 29 commits
-
-
Greg Kroah-Hartman authored
-
Nicholas Bellinger authored
This is to fix a regression that only affect the stable (not for the mainline) that the stable commit fdf9d862 was incorrectly placed dev->dev_link_magic check before the *dev assignment in target_fabric_port_link() due to fuzzy automatically context adjustment during the back-porting. Reported-by:
Chris Boot <bootc@bootc.net> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
CAI Qian <caiqian@redhat.com> Signed-off-by:
-
H. Peter Anvin authored
commit e43b3cec upstream. early_pci_allowed() and read_pci_config_16() are only available if CONFIG_PCI is defined. Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Abdallah Chatila <abdallah.chatila@ericsson.com>
-
Matt Fleming authored
commit 712ba9e9 upstream. efi.runtime_version is erroneously being set to the value of the vendor's firmware revision instead of that of the implemented EFI specification. We can't deduce which EFI functions are available based on the revision of the vendor's firmware since the version scheme is likely to be unique to each vendor. What we really need to know is the revision of the implemented EFI specification, which is available in the EFI System Table header. Signed-off-by:
Matt Fleming <matt.fleming@intel.com> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by:
-
Nathan Zimmer authored
commit b8f2c21d upstream. Update efi_call_phys_prelog to install an identity mapping of all available memory. This corrects a bug on very large systems with more then 512 GB in which bios would not be able to access addresses above not in the mapping. The result is a crash that looks much like this. BUG: unable to handle kernel paging request at 000000effd870020 IP: [<0000000078bce331>] 0x78bce330 PGD 0 Oops: 0000 [#1] SMP Modules linked in: CPU 0 Pid: 0, comm: swapper/0 Tainted: G W 3.8.0-rc1-next-20121224-medusa_ntz+ #2 Intel Corp. Stoutland Platform RIP: 0010:[<0000000078bce331>] [<0000000078bce331>] 0x78bce330 RSP: 0000:ffffffff81601d28 EFLAGS: 00010006 RAX: 0000000078b80e18 RBX: 0000000000000004 RCX: 0000000000000004 RDX: 0000000078bcf958 RSI: 0000000000002400 RDI: 8000000000000000 RBP: 0000000078bcf760 R08: 000000effd870000 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000000000c3 R12: 0000000000000030 R13: 000000effd870000 R14: 0000000000000000 R15: ffff88effd870000 FS: 0000000000000000(0000) GS:ffff88effe400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000effd870020 CR3: 000000000160c000 CR4: 00000000000006b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper/0 (pid: 0, threadinfo ffffffff81600000, task ffffffff81614400) Stack: 0000000078b80d18 0000000000000004 0000000078bced7b ffff880078b81fff 0000000000000000 0000000000000082 0000000078bce3a8 0000000000002400 0000000060000202 0000000078b80da0 0000000078bce45d ffffffff8107cb5a Call Trace: [<ffffffff8107cb5a>] ? on_each_cpu+0x77/0x83 [<ffffffff8102f4eb>] ? change_page_attr_set_clr+0x32f/0x3ed [<ffffffff81035946>] ? efi_call4+0x46/0x80 [<ffffffff816c5abb>] ? efi_enter_virtual_mode+0x1f5/0x305 [<ffffffff816aeb24>] ? start_kernel+0x34a/0x3d2 [<ffffffff816ae5ed>] ? repair_env_string+0x60/0x60 [<ffffffff816ae2be>] ? x86_64_start_reservations+0xba/0xc1 [<ffffffff816ae120>] ? early_idt_handlers+0x120/0x120 [<ffffffff816ae419>] ? x86_64_start_kernel+0x154/0x163 Code: Bad RIP value. RIP [<0000000078bce331>] 0x78bce330 RSP <ffffffff81601d28> CR2: 000000effd870020 ---[ end trace ead828934fef5eab ]--- Signed-off-by:
Nathan Zimmer <nzimmer@sgi.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by:
Robin Holt <holt@sgi.com> Signed-off-by:
-
Alan Cox authored
commit c903f045 upstream. At the moment the MSR driver only relies upon file system checks. This means that anything as root with any capability set can write to MSRs. Historically that wasn't very interesting but on modern processors the MSRs are such that writing to them provides several ways to execute arbitary code in kernel space. Sample code and documentation on doing this is circulating and MSR attacks are used on Windows 64bit rootkits already. In the Linux case you still need to be able to open the device file so the impact is fairly limited and reduces the security of some capability and security model based systems down towards that of a generic "root owns the box" setup. Therefore they should require CAP_SYS_RAWIO to prevent an elevation of capabilities. The impact of this is fairly minimal on most setups because they don't have heavy use of capabilities. Those using SELinux, SMACK or AppArmor rules might want to consider if their rulesets on the MSR driver could be tighter. Signed-off-by:
Alan Cox <alan@linux.intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Wang YanQing authored
commit f44310b9 upstream. I get the following warning every day with v3.7, once or twice a day: [ 2235.186027] WARNING: at /mnt/sda7/kernel/linux/arch/x86/kernel/apic/ipi.c:109 default_send_IPI_mask_logical+0x2f/0xb8() As explained by Linus as well: | | Once we've done the "list_add_rcu()" to add it to the | queue, we can have (another) IPI to the target CPU that can | now see it and clear the mask. | | So by the time we get to actually send the IPI, the mask might | have been cleared by another IPI. | This patch also fixes a system hang problem, if the data->cpumask gets cleared after passing this point: if (WARN_ONCE(!mask, "empty IPI mask")) return; then the problem in commit 83d349f3 ("x86: don't send an IPI to the empty set of CPU's") will happen again. Signed-off-by:
Wang YanQing <udknight@gmail.com> Acked-by:
-
Trond Myklebust authored
commit ab225417 upstream. Ensure that any setattr and getattr requests for junctions and/or mountpoints are sent to the server. Ever since commit 0ec26fd0 (vfs: automount should ignore LOOKUP_FOLLOW), we have silently dropped any setattr requests to a server-side mountpoint. For referrals, we have silently dropped both getattr and setattr requests. This patch restores the original behaviour for setattr on mountpoints, and tries to do the same for referrals, provided that we have a filehandle... Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Stanislaw Gruszka authored
commit aacde9ee upstream. Since: commit b23b025f Author: Ben Greear <greearb@candelatech.com> Date: Fri Feb 4 11:54:17 2011 -0800 mac80211: Optimize scans on current operating channel. we do not disable PS while going back to operational channel (on ieee80211_scan_state_suspend) and deffer that until scan finish. But since we are allowed to send frames, we can send a frame to AP without PM bit set, so disable PS on AP side. Then when we switch to off-channel (in ieee80211_scan_state_resume) we do not enable PS. Hence we are off-channel with PS disabled, frames are not buffered by AP. To fix remove offchannel_ps_disable argument and always enable PS when going off-channel and disable it when going on-channel, like it was before. Cc: stable@vger.kernel.org # 2.6.39+ Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Tested-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Daniel Vetter authored
commit 9452618e upstream. DMAR support on g4x/gm45 integrated gpus seems to be totally busted. So don't bother, but instead disable it by default to allow distros to unconditionally enable DMAR support. v2: Actually wire up the right quirk entry, spotted by Adam Jackson. Note that according to intel marketing materials only g45 and gm45 support DMAR/VT-d. So we have reports for all relevant gen4 pci ids by now. Still, keep all the other gen4 ids in the quirk table in case the marketing stuff confused me again, which would not be the first time. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51921 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=538163 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=538163 Cc: Adam Jackson <ajax@redhat.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: stable@vger.kernel.org Acked-By:
David Woodhouse <David.Woodhouse@intel.com> Tested-by:
stathis <stathis@npcglib.org> Tested-by:
Mihai Moldovan <ionic@ionic.de> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Anderson Lizardo authored
commit 0a9ab9bd upstream. The length parameter should be sizeof(req->name) - 1 because there is no guarantee that string provided by userspace will contain the trailing '\0'. Can be easily reproduced by manually setting req->name to 128 non-zero bytes prior to ioctl(HIDPCONNADD) and checking the device name setup on input subsystem: $ cat /sys/devices/pnp0/00\:04/tty/ttyS0/hci0/hci0\:1/input8/name AAAAAA[...]AAAAAAAAf0:af:f0:af:f0:af ("f0:af:f0:af:f0:af" is the device bluetooth address, taken from "phys" field in struct hid_device due to overflow.) Signed-off-by:
Anderson Lizardo <anderson.lizardo@openbossa.org> Acked-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
-
Chris Rattray authored
commit a80cc734 upstream. Signed-off-by:
Chris Rattray <crattray@opensource.wolfsonmicro.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Dan Carpenter authored
commit 8024c4c0 upstream. We're testing for ->show but calling ->store(). Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit 0712eea3 upstream. A Packard-Bell desktop machine gives no proper pin configuration from BIOS. It's almost equivalent with the 6stack+fp standard config, just take the existing fixup. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=901846Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Clemens Ladisch authored
commit d56268fb upstream. Commit 23caaf19 (ALSA: usb-mixer: Add support for Audio Class v2.0) forgot to adjust the length check for UAC 2.0 feature unit descriptors. This would make the code abort on encountering a feature unit without per-channel controls, and thus prevented the driver to work with any device having such a unit, such as the RME Babyface or Fireface UCX. Reported-by:
Florian Hanisch <fhanisch@uni-potsdam.de> Tested-by:
Matthew Robbetts <wingfeathera@gmail.com> Tested-by:
Michael Beer <beerml@sigma6audio.de> Cc: Daniel Mack <daniel@caiaq.de> Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Felix Fietkau authored
commit 1adb2e2b upstream. When the next beacon is sent, the ath_buf from the previous run is reused. If getting a new beacon from mac80211 fails, bf->bf_mpdu is not reset, yet the skb is freed, leading to a double-free on the next beacon tx attempt, resulting in a system crash. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Felix Fietkau authored
commit a3dc48e8 upstream. On AR9300 the rx FIFO needs to be empty during reset to ensure that no further DMA activity is generated, otherwise it might lead to memory corruption issues. Signed-off-by:
-
Sujith Manoharan authored
commit 0981c3b2 upstream. SKBs that are allocated in the HTC layer do not have callbacks registered and hence ended up not being freed, Fix this by freeing them properly in the TX completion routine. Reported-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Tested-by:
-
Johannes Berg authored
commit 1626e0fa upstream. During FT roaming, wpa_supplicant attempts to set the key before association. This used to be rejected, but as a side effect of my commit 66e67e41 ("mac80211: redesign auth/assoc") the key was accepted causing hardware crypto to not be used for it as the station isn't added to the driver yet. It would be possible to accept the key and then add it to the driver when the station has been added. However, this may run into issues with drivers using the state- based station adding if they accept the key only after association like it used to be. For now, revert to the behaviour from before the auth and assoc change. Reported-by:
Cédric Debarge <cedric.debarge@acksys.fr> Tested-by:
-
Piotr Haber authored
commit a1fe5280 upstream. On hardware reintialization reference count of already existing timers would be increased again. This leads to problems on module unloading. Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by:
Hante Meuleman <meuleman@broadcom.com> Reviewed-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
Piotr Haber <phaber@broadcom.com> Signed-off-by:
-
Stanislaw Gruszka authored
commit fa4cffcb upstream. We do not correctly change interface type when switching from IBSS mode to STA mode, that results in microcode errors. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=886946Reported-by:
Jaroslav Skarvada <jskarvad@redhat.com> Signed-off-by:
-
Avinash Patil authored
commit 83f0c6d1 upstream. Add missing "!" as we are supposed to check "!card->adapter" in PCIe suspend handler. Signed-off-by:
Avinash Patil <patila@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Reviewed-by:
Sergey V. <sftp.mtuci@gmail.com> Signed-off-by:
-
Jan Kara authored
commit 4b05d09c upstream. Running AIO is pinning inode in memory using file reference. Once AIO is completed using aio_complete(), file reference is put and inode can be freed from memory. So we have to be sure that calling aio_complete() is the last thing we do with the inode. Signed-off-by:
Jan Kara <jack@suse.cz> CC: xfs@oss.sgi.com CC: Ben Myers <bpm@sgi.com> Reviewed-by:
Ben Myers <bpm@sgi.com> Signed-off-by:
-
Suravee Suthikulpanit authored
commit 318fe782 upstream. The IOMMU may stop processing page translations due to a perceived lack of credits for writing upstream peripheral page service request (PPR) or event logs. If the L2B miscellaneous clock gating feature is enabled the IOMMU does not properly register credits after the log request has completed, leading to a potential system hang. BIOSes are supposed to disable L2B micellaneous clock gating by setting L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) = 1b. This patch corrects that for those which do not enable this workaround. Signed-off-by:
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Acked-by:
Joerg Roedel <joro@8bytes.org> Signed-off-by:
-
xueminsu authored
commit b2f4b03f upstream. drm_mode_addfb() expects fb_create return error code instead of NULL. Signed-off-by:
-
Jerome Glisse authored
commit e521a290 upstream. Aruba and newer gpu does not need the avivo cursor work around, quite the opposite this work around lead to corruption. agd5f: check DCE6 rather than ARUBA since the issue is DCE version specific rather than family specific. Signed-off-by:
Jerome Glisse <jglisse@redhat.com> Signed-off-by:
-
Szymon Janc authored
commit dbccd791 upstream. After sending reset command wait for its command complete event before sending next command. Some chips sends CC event for command received before reset if reset was send before chip replied with CC. This is also required by specification that host shall not send additional HCI commands before receiving CC for reset. < HCI Command: Reset (0x03|0x0003) plen 0 [hci0] 18.404612 > HCI Event: Command Complete (0x0e) plen 4 [hci0] 18.405850 Write Extended Inquiry Response (0x03|0x0052) ncmd 1 Status: Success (0x00) < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0 [hci0] 18.406079 > HCI Event: Command Complete (0x0e) plen 4 [hci0] 18.407864 Reset (0x03|0x0003) ncmd 1 Status: Success (0x00) < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0 [hci0] 18.408062 > HCI Event: Command Complete (0x0e) plen 12 [hci0] 18.408835 Signed-off-by:
Szymon Janc <szymon.janc@tieto.com> Acked-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
-
Stephen Boyd authored
commit 568dca15 upstream. Patrik Kluba reports that the preempt count becomes invalid due to the preempt_enable() call being unbalanced with a preempt_disable() call in the vfp assembly routines. This happens because preempt_enable() and preempt_disable() update preempt counts under PREEMPT_COUNT=y but the vfp assembly routines do so under PREEMPT=y. In a configuration where PREEMPT=n and DEBUG_ATOMIC_SLEEP=y, PREEMPT_COUNT=y and so the preempt_enable() call in VFP_bounce() keeps subtracting from the preempt count until it goes negative. Fix this by always using PREEMPT_COUNT to decided when to update preempt counts in the ARM assembly code. Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Reported-by:
Patrik Kluba <pkluba@dension.com> Tested-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Jean-Christophe PLAGNIOL-VILLARD authored
commit 36224d0f upstream. Make BGA as the default version as we are supposed to just have to specify when we use the PQFP version. Issue was existing since commit: 3e90772f (ARM: at91: fix at91rm9200 soc subtype handling). Signed-off-by:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
