- 22 Feb, 2016 10 commits
-
-
Shubhraprakash Das authored
Add commands to flush the GPU UCHE when a new context submits commands to GPU. The ensures that the new context does not use stale data present in UCHE. CRs-Fixed: 607976 Change-Id: I123a323be5f3fb9d1f9f96fed5bb68b8d0d27d76 Signed-off-by:
Shubhraprakash Das <sadas@codeaurora.org> Signed-off-by:
Hareesh Gundu <hareeshg@codeaurora.org>
-
Thomas Gleixner authored
commit 5b39939a4 (nohz: Move ts->idle_calls incrementation into strict idle logic) moved code out of tick_nohz_stop_sched_tick() and missed to bail out when the cpu is offline. That's causing subsequent failures as an offline CPU is supposed to die and not to fiddle with nohz magic. Return false in can_stop_idle_tick() if the cpu is offline. Change-Id: I635b765ae5dc2f4e81a38dff21dc8631fca73c49 Reported-and-tested-by:
Jiri Kosina <jkosina@suse.cz> Reported-and-tested-by:
Prarit Bhargava <prarit@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Tony Luck <tony.luck@intel.com> Cc: x86@kernel.org Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1305132138160.2863@ionos Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> [zwliew: Backport to 3.4] Signed-off-by:
Zhao Wei Liew <zhaoweiliew@gmail.com>
-
Nikola Majkić authored
We are not using it
-
Ping Li authored
Check the whether partial update feature is enabled or not before enabling any post processing features. Change-Id: Ibf2111d5ca8714279903980d14e63bab556bb41f Signed-off-by:Ping Li <quicpingli@codeaurora.org>
-
William Clark authored
According to the specification of AEAD, AEAD request crypt length is not a fixed maximum and associated length is also same. This could lead to potential integer overflow, thus allocating less memory. So we need to check potential integer overflow on AEAD request length. CRs-Fixed: 726872 Change-Id: Ie7708000bfd8c57e2fba8e02230a7ce9cdc9634c Signed-off-by:William Clark <wclark@codeaurora.org>
-
Vinu Deokaran authored
Fix a typo that was comparing the width instead of the height parameter that lead to black stripe flickering when scrolling on browser. Change-Id: I10e57f876458f46d445b3404d09a5e7606aeb666 Signed-off-by:Vinu Deokaran <vinud@codeaurora.org>
-
David Howells authored
Add support for invalidating a key - which renders it immediately invisible to further searches and causes the garbage collector to immediately wake up, remove it from keyrings and then destroy it when it's no longer referenced. It's better not to do this with keyctl_revoke() as that marks the key to start returning -EKEYREVOKED to searches when what is actually desired is to have the key refetched. To invalidate a key the caller must be granted SEARCH permission by the key. This may be too strict. It may be better to also permit invalidation if the caller has any of READ, WRITE or SETATTR permission. The primary use for this is to evict keys that are cached in special keyrings, such as the DNS resolver or an ID mapper. Change-Id: I923ea0f0b8f9d6b3ff8ec8beca77b1774984f1c3 Signed-off-by:David Howells <dhowells@redhat.com>
-
David Howells authored
Make use of the previous patch that makes the garbage collector perform RCU synchronisation before destroying defunct keys. Key pointers can now be replaced in-place without creating a new keyring payload and replacing the whole thing as the discarded keys will not be destroyed until all currently held RCU read locks are released. If the keyring payload space needs to be expanded or contracted, then a replacement will still need allocating, and the original will still have to be freed by RCU. Change-Id: I6c4f784f120951fb51ac9c23856ea37f51770bb9 Signed-off-by: -
Nirmal Abraham authored
Commit bd9474e059bbb2bb62f7e93894cfc3d3ba473fb2 (cpufreq_stats: Adds the fucntionality to load current values for each frequency for all the cores) introduced a change by which 'cpufreq_allstats_create' gets called at initialization (from 'cpufreq_stats_init' instead of 'cpufreq_stat_notifier_policy'). This causes 'cpufreq_allstate_create' to be called before the freq_table is allocated from 'create_all_freq_table'. Due to this, the data for cpu's which are online at boot are not added to the 'all_freq_table' leading to the incorrect reporting of data when the below sysfs command is run - 'cat sys/devices/system/cpu/cpufreq/all_time_in_state'. Correct this behaviour by altering the cpufreq_stats init sequence by which the memory for 'all_freq_table' is allocated before the 'cpufreq_allstats_create' function is called. Change-Id: I2232dacdc0deec4d1987c418e833fe28f74623fc Signed-off-by:
Nirmal Abraham <nabrah@codeaurora.org> Signed-off-by:
Srinivasarao P <spathi@codeaurora.org>
-
Laura Abbott authored
Currently, when dynamically placing regions CMA will allow the memory to be placed anywhere, including highmem. Due to system restrictions, regions may need to be placed in a smaller range. Add support to devicetree to allow these regions to have an upper bound on where they will be placed. Change-Id: Ib4ae194cbb6389e1091e7e04cfd331e9ab67ad05 Signed-off-by:
Laura Abbott <lauraa@codeaurora.org> [skhiani@codeaurora.org: Resolve merge conflicts] Signed-off-by:
Susheel Khiani <skhiani@codeaurora.org>
-
- 21 Feb, 2016 30 commits
-
-
Nikola Majkić authored
This reverts commit abdc7b3d.
-
Nikola Majkić authored
This reverts commit 564ebe5c.
-
Nikola Majkić authored
This reverts commit e03742da.
-
Dave Chinner authored
When sync does it's WB_SYNC_ALL writeback, it issues data Io and then immediately waits for IO completion. This is done in the context of the flusher thread, and hence completely ties up the flusher thread for the backing device until all the dirty inodes have been synced. On filesystems that are dirtying inodes constantly and quickly, this means the flusher thread can be tied up for minutes per sync call and hence badly affect system level write IO performance as the page cache cannot be cleaned quickly. We already have a wait loop for IO completion for sync(2), so cut this out of the flusher thread and delegate it to wait_sb_inodes(). Hence we can do rapid IO submission, and then wait for it all to complete. Effect of sync on fsmark before the patch: FSUse% Count Size Files/sec App Overhead ..... 0 640000 4096 35154.6 1026984 0 720000 4096 36740.3 1023844 0 800000 4096 36184.6 916599 0 880000 4096 1282.7 1054367 0 960000 4096 3951.3 918773 0 1040000 4096 40646.2 996448 0 1120000 4096 43610.1 895647 0 1200000 4096 40333.1 921048 And a single sync pass took: real 0m52.407s user 0m0.000s sys 0m0.090s After the patch, there is no impact on fsmark results, and each individual sync(2) operation run concurrently with the same fsmark workload takes roughly 7s: real 0m6.930s user 0m0.000s sys 0m0.039s IOWs, sync is 7-8x faster on a busy filesystem and does not have an adverse impact on ongoing async data write operations. Signed-off-by:Dave Chinner <dchinner@redhat.com> Reviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Change-Id: I9e55d65f5ecb2305497711d4688f0647d9346035
-
Jan Kara authored
In case when system contains no dirty pages, wakeup_flusher_threads() will submit WB_SYNC_NONE writeback for 0 pages so wb_writeback() exits immediately without doing anything. Thus sync(1) will write all the dirty inodes from a WB_SYNC_ALL writeback pass which is slow. Fix the problem by using get_nr_dirty_pages() in wakeup_flusher_threads() instead of calculating number of dirty pages manually. That function also takes number of dirty inodes into account. Change-Id: I458027ae08d9a5a93202a7b97ace1f8da7a18a07 CC: stable@vger.kernel.org Reported-by:
Paul Taysom <taysom@chromium.org> Signed-off-by:
-
VijayKumar Gn authored
Front camera in Thea P1B uses MCLK1 where as Thea P1A & Titan Uses MCLK0. Providing a facility to introduce Overriding logic Change-Id: Iac48eda90e7b74229d81d88991e7cce606c42f20 Signed-off-by:
VijayKumar Gn <gxnf38@motorola.com> Reviewed-on: http://gerrit.mot.com/663248 Tested-by:
Jira Key <jirakey@motorola.com> Reviewed-by:
Sudharsan Yettapu <sudharsan.yettapu@motorola.com> Reviewed-by:
Jian-Jun Fan <stevenfan@motorola.com> Reviewed-by:
Christopher Fries <cfries@motorola.com> SLTApproved: Christopher Fries <cfries@motorola.com> Submit-Approved: Jira Key <jirakey@motorola.com>
-
Alok Chauhan authored
mutex is not released while checking for null pdata which can lead to possible deadlock condition. Change-Id: I1dc3efd725df5bb75c96434a81d9a8f3f868cd0a Signed-off-by:
Alok Chauhan <alokc@codeaurora.org> Reviewed-on: http://gerrit.mot.com/681902 Submit-Approved: Jira Key <jirakey@motorola.com> Tested-by:
Yi-Wei Zhao <gbjc64@motorola.com> Reviewed-by:
Lian-Wei Wang <lian-wei.wang@motorola.com>
-
Andrew Wheeler authored
The phone will not boot with this change. This reverts commit 8016dca8. Conflicts: arch/arm/mach-msm/acpuclock-8226.c Change-Id: I0d99de60ba139d819a9521a2f2a9f606ed716b7d Reviewed-on: http://gerrit.pcs.mot.com/547213 SLT-Approved: Slta Waiver <sltawvr@motorola.com> Submit-Approved: Jira Key <jirakey@motorola.com> Tested-by:
Andrew Wheeler <thf876@motorola.com>
-
Naveen Ramaraj authored
Certain clients of ocmem always have exclusive regions set aside in the OCMEM memory map. Allocation requests for such clients do not have to wait for any pending evictions in progress to be completed nor will trigger any new evictions and can be safely scheduled right away. CRs-Fixed: 599002 Change-Id: I54369bca9d26378a9aa70db83d35ab94866a3ff1 Signed-off-by:
Naveen Ramaraj <nramaraj@codeaurora.org> Signed-off-by:
Neeti Desai <neetid@codeaurora.org> Reviewed-on: http://gerrit.mot.com/681940 Submit-Approved: Jira Key <jirakey@motorola.com> Tested-by:
-
Yuanyuan Zhong authored
Three timespec tv_nsec values are added together when calculating monotonic boottime. They may have overflowed 32bit before adding with s64 nsecs. User will observe the monotonic boottime going backwards. Cast the tv_nsec value to s64 before doing the math. Change-Id: Iddd476bf26bc60e2830c5e90ccc4747790ac03a3 Signed-off-by:
Yuanyuan Zhong <zyy@motorola.com> Reviewed-on: http://gerrit.mot.com/688924 Tested-by:
Igor Kovalenko <igork@motorola.com> Submit-Approved: Jira Key <jirakey@motorola.com> SLTApproved: Christopher Fries <cfries@motorola.com>
-
Sunil Khatri authored
In existing code we calculate nbytes based on the byte boundary, but genalloc uses bitmap for maintaining the memory allocation aligned to long. So while calculating nbytes we end up getting wrong nbytes. example: lets say nbytes comes to 9 bytes for 70 bits when bytes aligned,but if long aligned we will have 3 long words i.e 12 bytes. This difference may lead to choosing the wrong api for freeing the memory i.e Between kfree() and vfree(). Fix was inspired by an upstream commit eedce141cd2dad8d0cefc5468ef41898949a7031, bringing same fix into the gen_pool_detroy path. Change-Id: I942caf59e25515c780896b328b912604df9e10bf Signed-off-by:
Sunil Khatri <sunilkh@codeaurora.org>
-
Lianwei Wang authored
commit upstream 22939ea455c4290b32853c2e4fd79794e5336ddf. We saw the idle time report from /proc/stat is weird jump just after cpu hotplug. User 150 + Nice 0 + Sys 141 + Idle -44061 + IOW -1492 + IRQ 0 + SIRQ 4 = -45258 There are two reasons to cause this issue. 1. All the ts history data are cleaned by below patch. 4b0c0f2 tick: Cleanup NOHZ per cpu data on cpu down We don't need to clean all the ts data to fix the cpu hotplug race, but just clean the inidle and tick_stopped, and keep all the other ts data to record the history idle/iowait time data. 2. The idle/iowait time is read from different place by below patch. 7386cdb "nohz: Fix idle ticks in cpu summary line of /proc/stat" The idle/iowait time is read from get_cpu_idle/iowait_time_us when cpu is online, but is read from cpustat when cpu is offline. So we may compare the data with different base and get wrong result. Since the off time is no longer counted as idle time, it is safe to revert it now. Change-Id: I828caf375f882fdc92c41fe65ebd13a6ffbbd92e Signed-off-by:Lianwei Wang <a22439@motorola.com> Reviewed-on: http://gerrit.mot.com/696792 Tested-by:
-
Jan Kara authored
commit ad56edad089b56300fd13bb9eeb7d0424d978239 upstream. jbd2_journal_dirty_metadata() didn't get a reference to journal_head it was working with. This is OK in most of the cases since the journal head should be attached to a transaction but in rare occasions when we are journalling data, __ext4_journalled_writepage() can race with jbd2_journal_invalidatepage() stripping buffers from a page and thus journal head can be freed under hands of jbd2_journal_dirty_metadata(). Fix the problem by getting own journal head reference in jbd2_journal_dirty_metadata() (and also in jbd2_journal_set_triggers() which can possibly have the same issue). Reported-by:
Zheng Liu <gnehzuil.liu@gmail.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Eric Sandeen authored
commit eeecef0af5ea4efd763c9554cf2bd80fc4a0efd3 upstream. This sequence: # truncate --size=1g fsfile # mkfs.ext4 -F fsfile # mount -o loop,ro fsfile /mnt # umount /mnt # dmesg | tail results in an IO error when unmounting the RO filesystem: [ 318.020828] Buffer I/O error on device loop1, logical block 196608 [ 318.027024] lost page write due to I/O error on loop1 [ 318.032088] JBD2: Error -5 detected when updating journal superblock for loop1-8. This was a regression introduced by commit 24bcc89c : "jbd2: split updating of journal superblock and marking journal empty". Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
-
Laura Abbott authored
Secure buffers are never passed to userspace and are controled by the secure world so there is no real need to zero. Pass the dma attribute to skip zeroing. Change-Id: Iad870d0d7732d3dea09443418b9294cb9e05b5e0 Signed-off-by: -
Abhijeet Dharmapurikar authored
The PWM_CL register is secure i.e. driver has to write 0xA5 to 0XD0 register to allow updates to PWM_CL register. Fix it. Change-Id: I3f273627bdc137d8c10768c7d5824abe96ee8707 Signed-off-by:Abhijeet Dharmapurikar <adharmap@codeaurora.org>
-
Hariram Purushothaman authored
V4L2 only allow 32 buffers. Check the num_buf to make sure that user space passed value is not out of bound. CRs-Fixed: 514698 Change-Id: I662ec1eb998ed8bfb2a7f188e645410aa78c83b0 Signed-off-by:
Hariram Purushothaman <hpurus@codeaurora.org> Signed-off-by:
Ankit Premrajka <ankitp@codeaurora.org> Signed-off-by:
Raghu DP <dp.raghu@codeaurora.org>
-
Ravi Kiran Vonteddu authored
Maximum width capability check is required to take care of indefinite behavior when a clip having width more than Q6 capability is played. Also, make the capability check generic for Q6 and Venus. CRs-fixed: 626642 Change-Id: Ic10be0ad4434019fea45e7a090b21ba5cf54d9a6 Signed-off-by:Ravi Kiran Vonteddu <rvontedd@codeaurora.org>
-
Sarada Prasanna Garnayak authored
Upgarde firmware on the touch controller when the new firmware version is geater than the current firmware version. Update the version id after successful firmware update. skip firmware update process when device is in suspend state. CRs-Fixed: 623803 Change-Id: Ic462f6483887a3654665852e58ae9891de9f5eff Signed-off-by:Sarada Prasanna Garnayak <c_sgarna@codeaurora.org>
-
Saravana Kannan authored
devfreq already provides a sysfs interface for changing polling/sampling period. So, there is no need for the governor to separately expose sampling_ms. Also, sampling_ms had to be explicitly updated whenever polling_ms was updated for the governor to function correctly. Make the interface simpler by combining sample_ms with polling_interval control provided by devfreq. The rounding of freq to multiples of bw_step is unnecessary since the devfreq device already does the rounding to the next valid level. Rounding of AB to multiples of bw_step is still necessary since it's a vote that's summed up and doesn't have a direct 1-to-1 mapping to frequencies. Also update default bw_step to 190 MB/s instead of 200 MB/s to account for the fact that MB/s to MHz conversion needs to take into account the difference in the meaning of M (2^20 vs 10^6) between MB and MHz. Similarly also update io_percent to 16. Change-Id: I5fea989c647955103de3813be8eb9ec612f131bc Signed-off-by:Saravana Kannan <skannan@codeaurora.org>
-
Eric Dumazet authored
[ Upstream commit cd6b423afd3c08b27e1fed52db828ade0addbc6b ] While investigating about strange increase of retransmit rates on hosts ~24 days after boot, Van found hystart was disabled if ca->epoch_start was 0, as following condition is true when tcp_time_stamp high order bit is set. (s32)(tcp_time_stamp - ca->epoch_start) < HZ Quoting Van : At initialization & after every loss ca->epoch_start is set to zero so I believe that the above line will turn off hystart as soon as the 2^31 bit is set in tcp_time_stamp & hystart will stay off for 24 days. I think we've observed that cubic's restart is too aggressive without hystart so this might account for the higher drop rate we observe. Diagnosed-by:
Van Jacobson <vanj@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Neal Cardwell <ncardwell@google.com> Cc: Yuchung Cheng <ycheng@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 2ed0edf9090bf4afa2c6fc4f38575a85a80d4b20 ] commit 17a6e9f1 ("tcp_cubic: fix clock dependency") added an overflow error in bictcp_update() in following code : /* change the unit from HZ to bictcp_HZ */ t = ((tcp_time_stamp + msecs_to_jiffies(ca->delay_min>>3) - ca->epoch_start) << BICTCP_HZ) / HZ; Because msecs_to_jiffies() being unsigned long, compiler does implicit type promotion. We really want to constrain (tcp_time_stamp - ca->epoch_start) to a signed 32bit value, or else 't' has unexpected high values. This bugs triggers an increase of retransmit rates ~24 days after boot [1], as the high order bit of tcp_time_stamp flips. [1] for hosts with HZ=1000 Big thanks to Van Jacobson for spotting this problem. Diagnosed-by:
-
Lars-Peter Clausen authored
commit 8abac3ba51b5525354e9b2ec0eed1c9e95c905d9 upstream. The last register block, which falls into the specified range, is not handled correctly. The formula which calculates the number of register which should be synced is inverse (and off by one). E.g. if all registers in that block should be synced only one is synced, and if only one should be synced all (but one) are synced. To calculate the number of registers that need to be synced we need to subtract the number of the first register in the block from the max register number and add one. This patch updates the code accordingly. The issue was introduced in commit ac8d91c8 ("regmap: Supply ranges to the sync operations"). Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Balakumaran Kannan authored
[ Upstream commit 25fb6ca4ed9cad72f14f61629b68dc03c0d9713f ] IPv6 Routing table becomes broken once we do ifdown, ifup of the loopback(lo) interface. After down-up, routes of other interface's IPv6 addresses through 'lo' are lost. IPv6 addresses assigned to all interfaces are routed through 'lo' for internal communication. Once 'lo' is down, those routing entries are removed from routing table. But those removed entries are not being re-created properly when 'lo' is brought up. So IPv6 addresses of other interfaces becomes unreachable from the same machine. Also this breaks communication with other machines because of NDISC packet processing failure. This patch fixes this issue by reading all interface's IPv6 addresses and adding them to IPv6 routing table while bringing up 'lo'. ==Testing== Before applying the patch: $ route -A inet6 Kernel IPv6 routing table Destination Next Hop Flag Met Ref Use If 2000::20/128 :: U 256 0 0 eth0 fe80::/64 :: U 256 0 0 eth0 ::/0 :: !n -1 1 1 lo ::1/128 :: Un 0 1 0 lo 2000::20/128 :: Un 0 1 0 lo fe80::xxxx:xxxx:xxxx:xxxx/128 :: Un 0 1 0 lo ff00::/8 :: U 256 0 0 eth0 ::/0 :: !n -1 1 1 lo $ sudo ifdown lo $ sudo ifup lo $ route -A inet6 Kernel IPv6 routing table Destination Next Hop Flag Met Ref Use If 2000::20/128 :: U 256 0 0 eth0 fe80::/64 :: U 256 0 0 eth0 ::/0 :: !n -1 1 1 lo ::1/128 :: Un 0 1 0 lo ff00::/8 :: U 256 0 0 eth0 ::/0 :: !n -1 1 1 lo $ After applying the patch: $ route -A inet6 Kernel IPv6 routing table Destination Next Hop Flag Met Ref Use If 2000::20/128 :: U 256 0 0 eth0 fe80::/64 :: U 256 0 0 eth0 ::/0 :: !n -1 1 1 lo ::1/128 :: Un 0 1 0 lo 2000::20/128 :: Un 0 1 0 lo fe80::xxxx:xxxx:xxxx:xxxx/128 :: Un 0 1 0 lo ff00::/8 :: U 256 0 0 eth0 ::/0 :: !n -1 1 1 lo $ sudo ifdown lo $ sudo ifup lo $ route -A inet6 Kernel IPv6 routing table Destination Next Hop Flag Met Ref Use If 2000::20/128 :: U 256 0 0 eth0 fe80::/64 :: U 256 0 0 eth0 ::/0 :: !n -1 1 1 lo ::1/128 :: Un 0 1 0 lo 2000::20/128 :: Un 0 1 0 lo fe80::xxxx:xxxx:xxxx:xxxx/128 :: Un 0 1 0 lo ff00::/8 :: U 256 0 0 eth0 ::/0 :: !n -1 1 1 lo $ Signed-off-by:
Balakumaran Kannan <Balakumaran.Kannan@ap.sony.com> Signed-off-by:
Maruthi Thotad <Maruthi.Thotad@ap.sony.com> Signed-off-by:
-
Jiri Slaby authored
commit 37b7f3c76595e23257f61bd80b223de8658617ee upstream. In commit b0de59b5733d ("TTY: do not update atime/mtime on read/write") we removed timestamps from tty inodes to fix a security issue and waited if something breaks. Well, 'w', the utility to find out logged users and their inactivity time broke. It shows that users are inactive since the time they logged in. To revert to the old behaviour while still preventing attackers to guess the password length, we update the timestamps in one-minute intervals by this patch. Signed-off-by:Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Jiri Slaby authored
commit b0de59b5733d18b0d1974a060860a8b5c1b36a2e upstream. On http://vladz.devzero.fr/013_ptmx-timing.php , we can see how to find out length of a password using timestamps of /dev/ptmx. It is documented in "Timing Analysis of Keystrokes and Timing Attacks on SSH". To avoid that problem, do not update time when reading from/writing to a TTY. I am afraid of regressions as this is a behavior we have since 0.97 and apps may expect the time to be current, e.g. for monitoring whether there was a change on the TTY. Now, there is no change. So this would better have a lot of testing before it goes upstream. References: CVE-2013-0160 Signed-off-by:
-
Russell King authored
commit b6c7aabd923a17af993c5a5d5d7995f0b27c000a upstream. Let's do the changes properly and fix the same problem everywhere, not just for one case. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Lukas Czerner authored
commit 810da240f221d64bf90020f25941b05b378186fe upstream. We're using macro EXT4_B2C() to convert number of blocks to number of clusters for bigalloc file systems. However, we should be using EXT4_NUM_B2C(). Signed-off-by:
Lukas Czerner <lczerner@redhat.com> Signed-off-by:
CAI Qian <caiqian@redhat.com> Signed-off-by:
Lingzhu Xiang <lxiang@redhat.com> Signed-off-by:
-
Riley Andrews authored
Fix build broken by commit b0bd81a67ae5ced88b ("android: drivers: workaround debugfs race in binder"). Change-Id: I10c5c0211144a4a1c270dc03f92cf6a1a829e8f8 -
Russell King authored
commit 43659222e7a0113912ed02f6b2231550b3e471ac upstream. It's no good setting vga_base after the VGA console has been initialised, because if we do that we get this: Unable to handle kernel paging request at virtual address 000b8000 pgd = c0004000 [000b8000] *pgd=07ffc831, *pte=00000000, *ppte=00000000 0Internal error: Oops: 5017 [#1] ARM Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0+ #49 task: c03e2974 ti: c03d8000 task.ti: c03d8000 PC is at vgacon_startup+0x258/0x39c LR is at request_resource+0x10/0x1c pc : [<c01725d0>] lr : [<c0022b50>] psr: 60000053 sp : c03d9f68 ip : 000b8000 fp : c03d9f8c r10: 000055aa r9 : 4401a103 r8 : ffffaa55 r7 : c03e357c r6 : c051b460 r5 : 000000ff r4 : 000c0000 r3 : 000b8000 r2 : c03e0514 r1 : 00000000 r0 : c0304971 Flags: nZCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel which is an access to the 0xb8000 without the PCI offset required to make it work. Fixes: cc22b4c1 ("ARM: set vga memory base at run-time") Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Cc: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
