Cancel - Wrong repo. #1
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…nd adapations for AOSP base. Signed-off-by: Tk-Glitch <[email protected]>
Signed-off-by: Tk-Glitch <[email protected]>
Signed-off-by: Tk-Glitch <[email protected]>
Signed-off-by: Tk-Glitch <[email protected]>
Commit 455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by
recent GCC (4.7.2) optimizations") attempted to fix a compliance issue
with the memset return value. However the memset itself became broken
by that patch for misaligned pointers.
This fixes the above by branching over the entry code from the
misaligned fixup code to avoid reloading the original pointer.
Also, because the function entry alignment is wrong in the Thumb mode
compilation, that fixup code is moved to the end.
While at it, the entry instructions are slightly reworked to help dual
issue pipelines.
Signed-off-by: Nicolas Pitre <[email protected]>
Tested-by: Alexander Holler <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Tk-Glitch <[email protected]>
Signed-off-by: Tk-Glitch <[email protected]>
Signed-off-by: Tk-Glitch <[email protected]>
Date Thu, 03 Jan 2013 23:49:40 -0800 In various network workloads, __do_softirq() latencies can be up to 20 ms if HZ=1000, and 200 ms if HZ=100. This is because we iterate 10 times in the softirq dispatcher, and some actions can consume a lot of cycles. This patch changes the fallback to ksoftirqd condition to : - A time limit of 2 ms. - need_resched() being set on current task When one of this condition is met, we wakeup ksoftirqd for further softirq processing if we still have pending softirqs. Using need_resched() as the only condition can trigger RCU stalls, as we can keep BH disabled for too long. I ran several benchmarks and got no significant difference in throughput, but a very significant reduction of latencies (one order of magnitude) : In following bench, 200 antagonist "netperf -t TCP_RR" are started in background, using all available cpus. Then we start one "netperf -t TCP_RR", bound to the cpu handling the NIC IRQ (hard+soft) Before patch : RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind RT_LATENCY=550110.424 MIN_LATENCY=146858 MAX_LATENCY=997109 P50_LATENCY=305000 P90_LATENCY=550000 P99_LATENCY=710000 MEAN_LATENCY=376989.12 STDDEV_LATENCY=184046.92 After patch : RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind RT_LATENCY=40545.492 MIN_LATENCY=9834 MAX_LATENCY=78366 P50_LATENCY=33583 P90_LATENCY=59000 P99_LATENCY=69000 MEAN_LATENCY=38364.67 STDDEV_LATENCY=12865.26 Signed-off-by: Eric Dumazet <[email protected]> Cc: David Miller <[email protected]> Cc: Tom Herbert <[email protected]> Cc: Ben Hutchings <[email protected]> Signed-off-by: Tk-Glitch <[email protected]>
…le s2w/dt2w when magnetic cover is used Signed-off-by: flar2 <[email protected]> Signed-off-by: Tk-Glitch <[email protected]>
Signed-off-by: Paul Reioux <[email protected]>
…of task ID Signed-off-by: godmachine81
issues (Use this only for devices with audio reset issues) Also bump version to 3.1 Signed-off-by: Paul Reioux <[email protected]> wcd9xxx-core: add register write without mutex protection This is assuming the calling function will take care of the mutex. Signed-off-by: Paul Reioux <[email protected]>
control as well Signed-off-by: Paul Reioux <[email protected]>
bump to version 3.2 Signed-off-by: Paul Reioux <[email protected]>
Signed-off-by: Paul Reioux <[email protected]>
touch event On a device where the primary input is a touchscreen nobody is surprised that touch events are often the catalyst for drawing frames. If the GPU is in slumber we can get a jump on the action by watching for touch events and turning the GPU on in anticipation of a draw call. Register for events from all input drivers returning EV_ABS events and queue a work task to power up the GPU if it is currently in slumber. Change-Id: Ic0dedbadbdc96ef9ddd78252ea65f8e1cdd00110 Signed-off-by: Jordan Crouse <[email protected]> adapted for FLO/DEB use Signed-off-by: Paul Reioux <[email protected]>
Signed-off-by: Paul Reioux <[email protected]>
Signed-off-by: Paul Reioux <[email protected]>
Signed-off-by: Paul Reioux <[email protected]>
Signed-off-by: Tk-Glitch <[email protected]>
Enable compiler optimizations specific to the Cortex-A15 processor when targeting MSM Krait CPUs. This is necessary take advantage of the UDIV/SDIV instructions supported by these processors. To accomplish this, we need to remove the -march=armv7-a ISA restriction from the compiler options because 'cortex-a15' is a superset of 'armv7-a'. Change-Id: I6215aecc11fb4f77c971de7b84f68649ef234357 Signed-off-by: Stepan Moskovchenko <[email protected]>
Fix commit 064206656b
This reverts commit 2017219.
Unbound wqs aren't concurrency-managed and try to execute work items as soon as possible. This is currently achieved by implicitly setting %WQ_HIGHPRI on all unbound workqueues; however, WQ_HIGHPRI implementation is about to be restructured and this usage won't be valid anymore. Add an explicit chain-wakeup path for unbound workqueues in process_one_work() instead of piggy backing on %WQ_HIGHPRI. Change-Id: Iecd17a9935ee28f856d8b726bb4c296762922bed Signed-off-by: Tejun Heo <[email protected]> Git-commit: 974271c485a4d8bb801decc616748f90aafb07ec Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Signed-off-by: Matt Wagantall <[email protected]> Conflicts: kernel/workqueue.c
This reverts commit 5e18251.
…so apply a theme.
Currently the load of the system is calculated using the max frequency that is read during startup(It does not get updated when the policy changes). As a result, the average load of the system is incorrectly calculated and the system might not bring the cpus online to manage the additional load. This reduces the performance of the system. To fix this issue, register rq_stats to receive cpufreq policy notifications. Update the policy's max frequency when a notification is received and use that value to calculate the load. Change-Id: Icc78e28c736c170e198f723fd96c13dfb2dafe8a Signed-off-by: Archana Sathyakumar <[email protected]> Signed-off-by: Anji Jonnala <[email protected]>
When the workqueue runs at a lower priority, it gets starved by higher priority threads. Bump the WQ priority to high to ensure rpm smd work queue gets a fair chance Change-Id: I06b864611cf45afe6931d6030327806032894663 Signed-off-by: Mahesh Sivasubramanian <[email protected]> (cherry picked from commit e0eccf8f6dece61cdb639c4b43374c34c3acf3ea)
Signed-off-by: franciscofranco <[email protected]>
behavior, and can hold unix_table_lock for a while if high number of unix sockets are alive. (90 ms for 200k sockets...) We already have a hash table, so its quite easy to use it. Problem is unbound sockets are still hashed in a single hash slot (unix_socket_table[UNIX_HASH_TABLE]) This patch also spreads unbound sockets to 256 hash slots, to speedup both /proc/net/unix and unix_diag. Time to read /proc/net/unix with 200k unix sockets : (time dd if=/proc/net/unix of=/dev/null bs=4k) before : 520 secs after : 2 secs Signed-off-by: Eric Dumazet <[email protected]> Cc: Steven Whitehouse <[email protected]> Cc: Pavel Emelyanov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
…ENT_UNALIGNED_ACCESS=y
KVM: x86: Convert vapic synchronization to _cached functions (CVE-2013-6368) commit fda4e2e85589191b123d31cdc21fd33ee70f50fd upstream. In kvm_lapic_sync_from_vapic and kvm_lapic_sync_to_vapic there is the potential to corrupt kernel memory if userspace provides an address that is at the end of a page. This patches concerts those functions to use kvm_write_guest_cached and kvm_read_guest_cached. It also checks the vapic_address specified by userspace during ioctl processing and returns an error to userspace if the address is not a valid GPA. This is generally not guest triggerable, because the required write is done by firmware that runs before the guest. Also, it only affects AMD processors and oldish Intel that do not have the FlexPriority feature (unless you disable FlexPriority, of course; then newer processors are also affected). Fixes: b93463a ('KVM: Accelerated apic support') Reported-by: Andrew Honig <[email protected]> Cc: [email protected] Signed-off-by: Andrew Honig <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> [ lizf: backported to 3.4: based on Paolo's backport hints for <3.10 ] Signed-off-by: Li Zefan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> staging: comedi: 8255_pci: fix for newer PCI-DIO48H commit 0283f7a100882684ad32b768f9f1ad81658a0b92 upstream. At some point, Measurement Computing / ComputerBoards redesigned the PCI-DIO48H to use a PLX PCI interface chip instead of an AMCC chip. This meant they had to put their hardware registers in the PCI BAR 2 region instead of PCI BAR 1. Unfortunately, they kept the same PCI device ID for the new design. This means the driver recognizes the newer cards, but doesn't work (and is likely to screw up the local configuration registers of the PLX chip) because it's using the wrong region. Since the PCI subvendor and subdevice IDs were both zero on the old design, but are the same as the vendor and device on the new design, we can tell the old design and new design apart easily enough. Split the existing entry for the PCI-DIO48H in `pci_8255_boards[]` into two new entries, referenced by different entries in the PCI device ID table `pci_8255_pci_table[]`. Use the same board name for both entries. Signed-off-by: Ian Abbott <[email protected]> Acked-by: H Hartley Sweeten <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> perf/x86/amd/ibs: Fix waking up from S3 for AMD family 10h commit bee09ed91cacdbffdbcd3b05de8409c77ec9fcd6 upstream. On AMD family 10h we see following error messages while waking up from S3 for all non-boot CPUs leading to a failed IBS initialization: Enabling non-boot CPUs ... smpboot: Booting Node 0 Processor 1 APIC 0x1 [Firmware Bug]: cpu 1, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu perf: IBS APIC setup failed on cpu #1 process: Switch to broadcast mode on CPU1 CPU1 is up ... ACPI: Waking up from system sleep state S3 Reason for this is that during suspend the LVT offset for the IBS vector gets lost and needs to be reinialized while resuming. The offset is read from the IBSCTL msr. On family 10h the offset needs to be 1 as offset 0 is used for the MCE threshold interrupt, but firmware assings it for IBS to 0 too. The kernel needs to reprogram the vector. The msr is a readonly node msr, but a new value can be written via pci config space access. The reinitialization is implemented for family 10h in setup_ibs_ctl() which is forced during IBS setup. This patch fixes IBS setup after waking up from S3 by adding resume/supend hooks for the boot cpu which does the offset reinitialization. Marking it as stable to let distros pick up this fix. Signed-off-by: Robert Richter <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> Cc: Linus Torvalds <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Conflicts: arch/x86/kernel/cpu/perf_event_amd_ibs.c mm/memory-failure.c: recheck PageHuge() after hugetlb page migrate successfully commit a49ecbcd7b0d5a1cda7d60e03df402dd0ef76ac8 upstream. After a successful hugetlb page migration by soft offline, the source page will either be freed into hugepage_freelists or buddy(over-commit page). If page is in buddy, page_hstate(page) will be NULL. It will hit a NULL pointer dereference in dequeue_hwpoisoned_huge_page(). BUG: unable to handle kernel NULL pointer dereference at 0000000000000058 IP: [<ffffffff81163761>] dequeue_hwpoisoned_huge_page+0x131/0x1d0 PGD c23762067 PUD c24be2067 PMD 0 Oops: 0000 [#1] SMP So check PageHuge(page) after call migrate_pages() successfully. [wujg: backport to 3.4: - adjust context - s/num_poisoned_pages/mce_bad_pages/] Signed-off-by: Jianguo Wu <[email protected]> Tested-by: Naoya Horiguchi <[email protected]> Reviewed-by: Naoya Horiguchi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> hwmon: (coretemp) Fix truncated name of alarm attributes commit 3f9aec7610b39521c7c69d754de7265f6994c194 upstream. When the core number exceeds 9, the size of the buffer storing the alarm attribute name is insufficient and the attribute name is truncated. This causes libsensors to skip these attributes as the truncated name is not recognized. Reported-by: Andreas Hollmann <[email protected]> Signed-off-by: Jean Delvare <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> SELinux: Fix possible NULL pointer dereference in selinux_inode_permission() commit 3dc91d4338d698ce77832985f9cb183d8eeaf6be upstream. While running stress tests on adding and deleting ftrace instances I hit this bug: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: selinux_inode_permission+0x85/0x160 PGD 63681067 PUD 7ddbe067 PMD 0 Oops: 0000 [#1] PREEMPT CPU: 0 PID: 5634 Comm: ftrace-test-mki Not tainted 3.13.0-rc4-test-00033-gd2a6dde-dirty #20 Hardware name: /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006 task: ffff880078375800 ti: ffff88007ddb0000 task.ti: ffff88007ddb0000 RIP: 0010:[<ffffffff812d8bc5>] [<ffffffff812d8bc5>] selinux_inode_permission+0x85/0x160 RSP: 0018:ffff88007ddb1c48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000800000 RCX: ffff88006dd43840 RDX: 0000000000000001 RSI: 0000000000000081 RDI: ffff88006ee46000 RBP: ffff88007ddb1c88 R08: 0000000000000000 R09: ffff88007ddb1c54 R10: 6e6576652f6f6f66 R11: 0000000000000003 R12: 0000000000000000 R13: 0000000000000081 R14: ffff88006ee46000 R15: 0000000000000000 FS: 00007f217b5b6700(0000) GS:ffffffff81e21000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033^M CR2: 0000000000000020 CR3: 000000006a0fe000 CR4: 00000000000007f0 Call Trace: security_inode_permission+0x1c/0x30 __inode_permission+0x41/0xa0 inode_permission+0x18/0x50 link_path_walk+0x66/0x920 path_openat+0xa6/0x6c0 do_filp_open+0x43/0xa0 do_sys_open+0x146/0x240 SyS_open+0x1e/0x20 system_call_fastpath+0x16/0x1b Code: 84 a1 00 00 00 81 e3 00 20 00 00 89 d8 83 c8 02 40 f6 c6 04 0f 45 d8 40 f6 c6 08 74 71 80 cf 02 49 8b 46 38 4c 8d 4d cc 45 31 c0 <0f> b7 50 20 8b 70 1c 48 8b 41 70 89 d9 8b 78 04 e8 36 cf ff ff RIP selinux_inode_permission+0x85/0x160 CR2: 0000000000000020 Investigating, I found that the inode->i_security was NULL, and the dereference of it caused the oops. in selinux_inode_permission(): isec = inode->i_security; rc = avc_has_perm_noaudit(sid, isec->sid, isec->sclass, perms, 0, &avd); Note, the crash came from stressing the deletion and reading of debugfs files. I was not able to recreate this via normal files. But I'm not sure they are safe. It may just be that the race window is much harder to hit. What seems to have happened (and what I have traced), is the file is being opened at the same time the file or directory is being deleted. As the dentry and inode locks are not held during the path walk, nor is the inodes ref counts being incremented, there is nothing saving these structures from being discarded except for an rcu_read_lock(). The rcu_read_lock() protects against freeing of the inode, but it does not protect freeing of the inode_security_struct. Now if the freeing of the i_security happens with a call_rcu(), and the i_security field of the inode is not changed (it gets freed as the inode gets freed) then there will be no issue here. (Linus Torvalds suggested not setting the field to NULL such that we do not need to check if it is NULL in the permission check). Note, this is a hack, but it fixes the problem at hand. A real fix is to restructure the destroy_inode() to call all the destructor handlers from the RCU callback. But that is a major job to do, and requires a lot of work. For now, we just band-aid this bug with this fix (it works), and work on a more maintainable solution in the future. Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> nilfs2: fix segctor bug that causes file system corruption commit 70f2fe3a26248724d8a5019681a869abdaf3e89a upstream. There is a bug in the function nilfs_segctor_collect, which results in active data being written to a segment, that is marked as clean. It is possible, that this segment is selected for a later segment construction, whereby the old data is overwritten. The problem shows itself with the following kernel log message: nilfs_sufile_do_cancel_free: segment 6533 must be clean Usually a few hours later the file system gets corrupted: NILFS: bad btree node (blocknr=8748107): level = 0, flags = 0x0, nchildren = 0 NILFS error (device sdc1): nilfs_bmap_last_key: broken bmap (inode number=114660) The issue can be reproduced with a file system that is nearly full and with the cleaner running, while some IO intensive task is running. Although it is quite hard to reproduce. This is what happens: 1. The cleaner starts the segment construction 2. nilfs_segctor_collect is called 3. sc_stage is on NILFS_ST_SUFILE and segments are freed 4. sc_stage is on NILFS_ST_DAT current segment is full 5. nilfs_segctor_extend_segments is called, which allocates a new segment 6. The new segment is one of the segments freed in step 3 7. nilfs_sufile_cancel_freev is called and produces an error message 8. Loop around and the collection starts again 9. sc_stage is on NILFS_ST_SUFILE and segments are freed including the newly allocated segment, which will contain active data and can be allocated at a later time 10. A few hours later another segment construction allocates the segment and causes file system corruption This can be prevented by simply reordering the statements. If nilfs_sufile_cancel_freev is called before nilfs_segctor_extend_segments the freed segments are marked as dirty and cannot be allocated any more. Signed-off-by: Andreas Rohner <[email protected]> Reviewed-by: Ryusuke Konishi <[email protected]> Tested-by: Andreas Rohner <[email protected]> Signed-off-by: Ryusuke Konishi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> md/raid10: fix bug when raid10 recovery fails to recover a block. commit e8b849158508565e0cd6bc80061124afc5879160 upstream. commit e875ece md/raid10 record bad blocks as needed during recovery. added code to the "cannot recover this block" path to record a bad block rather than fail the whole recovery. Unfortunately this new case was placed *after* r10bio was freed rather than *before*, yet it still uses r10bio. This is will crash with a null dereference. So move the freeing of r10bio down where it is safe. Fixes: e875ece Reported-by: Damian Nowak <[email protected]> URL: https://bugzilla.kernel.org/show_bug.cgi?id=68181 Signed-off-by: NeilBrown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> md/raid10: fix two bugs in handling of known-bad-blocks. commit b50c259e25d9260b9108dc0c2964c26e5ecbe1c1 upstream. If we discover a bad block when reading we split the request and potentially read some of it from a different device. The code path of this has two bugs in RAID10. 1/ we get a spin_lock with _irq, but unlock without _irq!! 2/ The calculation of 'sectors_handled' is wrong, as can be clearly seen by comparison with raid1.c This leads to at least 2 warnings and a probable crash is a RAID10 ever had known bad blocks. Fixes: 856e08e Reported-by: Damian Nowak <[email protected]> URL: https://bugzilla.kernel.org/show_bug.cgi?id=68181 Signed-off-by: NeilBrown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
… and add support for them in Aroma. Also add a basic backup/restore mechanism and fix some inconcistencies. Signed-off-by: Tk-Glitch <[email protected]>
Signed-off-by: Tk-Glitch <[email protected]> Conflicts: release/aroma/META-INF/com/google/android/updater-script
…hotplug driver so it's restored as well. Conflicts: release/aroma/META-INF/com/google/android/updater-script
…t to Aroma as well with presets.
…oice made previously if coming back to it.
…opy/pasted: ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- commit bbb00be0b838eb0812c0a97c95ee6787fada85e4 Author: Hardik Kantilal Patel <[email protected]> Date: Fri Jan 24 09:19:21 2014 +0530 wlan : Revision 3.2.3.16 wlan : Revision 3.2.3.16 commit e5cb4d6074f64fd9c064926230e703b005ca3e35 Author: Hardik Kantilal Patel <[email protected]> Date: Sat Jan 18 01:28:34 2014 +0530 wlan: Initilize country IE prefrence flag Initialize country IE prefrence flag to disable country IE hints issued by the CORE CRs-Fixed: 542802 commit 04b4db0bfbd919b71ca444abe519ed51020697f5 Author: Hardik Kantilal Patel <[email protected]> Date: Sat Jan 18 01:37:03 2014 +0530 wlan: VOS ASSERT in csrRoamCompletion due to Assoc ref count. While switching between two AP, csr will reissue roam command again to the nextbss if it was interrupted by the dissconnect req for the previous bss.During this csr is incrementing bRefAssocStartCnt twice. When CSR will reissue the roam command it will reset the bRefAssocStartCnt if it was already set. CRs-fixed: 554723 commit 10801e4d01f01ca3a6296b4ccaba8a3790851501 Author: Hardik Kantilal Patel <[email protected]> Date: Sat Jan 18 01:53:45 2014 +0530 wifi: Scan list not updated with correct APs on band change. To support P2P functionality driver will add 1, 6 and 11 irrespective of selected bands. When we set 5G band scan list is updated with APs on channel 1, 6 and 11 as well. Hence we are able to see APs on channel 1,6 and 11 when we receive beacons during p2p functionality. To mitigate this issue for P2P search don't consider beacons and probe responses which doesn't contain P2P IE. CRs-Fixed: 505337 commit 6157d557d2dbacf7fdacf59f4f4686c7dcfc1700 Author: Hardik Kantilal Patel <[email protected]> Date: Mon Jan 20 22:14:54 2014 +0530 wlan : Revision 3.2.3.15 wlan : Revision 3.2.3.15 commit 118d50bf7b9c4af57961c3e8524293b0848b8a24 Author: Hardik Kantilal Patel <[email protected]> Date: Mon Jan 20 21:55:07 2014 +0530 wlan: Fix to pass global temporary dynamic IPv6 addr Fix to pass global temporary dynamic IPv6 addr while configuring NS offload CRs-Fixed: 592499 commit 9c5a1899b286d9a1115fa5c7487eb5bd3ae1263b Author: Hardik Kantilal Patel <[email protected]> Date: Mon Jan 20 11:44:58 2014 +0530 wlan: Fix for handling IPv6 notifier block rightly. Correct the register and unregister sequence of IPv6 notifier block. CRs-Fixed: 600300 commit ff6ea2ce4cfebfbe2b01c86c79079a951b2089d9 Author: Vinay Krishna Eranna <[email protected]> Date: Sun Dec 1 17:00:15 2013 +0530 Registering IPv6 notifier to notify change in IP. Not able to retrieve IPv6 addresses on the interface when queried during the re-connection in suspend mode and thus failing to set NS offload during SETSUSPEND. Registering IPv6 notifier to get notification if any change in IP, so that we can reconfigure the offload parameters for new IP. CRs-Fixed: 557306 Change-Id: Id90112f346349fe48aa36de104efb532433af2aa commit 8482b3606c8dc6f434837ce135c7b220764c9c8b Author: Madan Mohan Koyyalamudi <[email protected]> Date: Thu Nov 21 09:40:35 2013 -0800 wlan : Revision 3.2.3.14 wlan : Revision 3.2.3.14 commit 515bf61908be2615a29163b9c638d45b23d792c8 Author: pratik Bhalgat <[email protected]> Date: Thu Nov 21 17:13:49 2013 +0530 wlan : Updated TDLS parameters in ini CRs-fixed: 575365 commit 8178e94c4cc9505524b360791bab6f443b7250ae Author: pratik Bhalgat <[email protected]> Date: Thu Nov 21 17:09:20 2013 +0530 wlan: Flush scan results on PNO indication event. Flush scan results during PNO indication, so as to avoid indication/updation of stale entries to above layers, which may not have aged out during APPS collapse.
Signed-off-by: Tk-Glitch <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cancel, wrong repo. -_-