- 21 Feb, 2016 40 commits
-
-
Vinson Lee authored
commit 85df3b3769222894e9692b383c7af124b7721086 upstream. The %name-prefix "prefix" syntax is not available on bison 2.3 and older. Substitute with the -p "prefix" command-line option for compatibility with older versions of bison. This patch fixes this build error with older versions of bison. CC util/sysfs.o BISON util/pmu-bison.c util/pmu.y:2.14-24: syntax error, unexpected string, expecting = make: *** [util/pmu-bison.c] Error 1 Signed-off-by:Vinson Lee <vlee@twitter.com> Tested-by:
Li Zefan <lizefan@huawei.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Li Zefan <lizefan@huawei.com> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Pekka Enberg <penberg@kernel.org> Link: http://lkml.kernel.org/r/1360792138-29186-1-git-send-email-vlee@twitter.com Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Nikola Majkić authored
This reverts commit 3f9fee8a.
-
Nikola Majkić authored
This reverts commit afc733137089159e86e3bcd4fb2fb5aab66726ce.
-
Nikola Majkić authored
This reverts commit 15f27772.
-
Nikola Majkić authored
This reverts commit 2eeca7c64aac4e9271d689649a9b85a82a02fc38.
-
Krishna Chaitanya Parimi authored
MDP3 LUT programming has incorrect RGB order as per HW. The correct order is to have color0 for green, color1 for red and color2 for blue. Correcting the order in mdp3. Change-Id: Ie7b6ab7f83e18495e83a05102e288fee6841e3ab Signed-off-by:Krishna Chaitanya Parimi <cparimi@codeaurora.org>
-
Sandeep Panda authored
Support more than 2 bytes DSI read for DSI v2 driver. Change-Id: Ie1b1a7990aed6944036ce82cf4202472604e8e87 Signed-off-by:Sandeep Panda <spanda@codeaurora.org>
-
Jed Davis authored
commit c5f927a6f62196226915f12194c9d0df4e2210d7 upstream. With this change, we no longer lose the innermost entry in the user-mode part of the call chain. See also the x86 port, which includes the ip. It's possible to partially work around this problem by post-processing the data to use the PERF_SAMPLE_IP value, but this works only if the CPU wasn't in the kernel when the sample was taken. Signed-off-by:
Jed Davis <jld@mozilla.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
qiuxishi authored
commit f14851af0ebb32745c6c5a2e400aa0549f9d20df upstream. There may be a bug when registering section info. For example, on my Itanium platform, the pfn range of node0 includes the other nodes, so other nodes' section info will be double registered, and memmap's page count will equal to 3. node0: start_pfn=0x100, spanned_pfn=0x20fb00, present_pfn=0x7f8a3, => 0x000100-0x20fc00 node1: start_pfn=0x80000, spanned_pfn=0x80000, present_pfn=0x80000, => 0x080000-0x100000 node2: start_pfn=0x100000, spanned_pfn=0x80000, present_pfn=0x80000, => 0x100000-0x180000 node3: start_pfn=0x180000, spanned_pfn=0x80000, present_pfn=0x80000, => 0x180000-0x200000 free_all_bootmem_node() register_page_bootmem_info_node() register_page_bootmem_info_section() When hot remove memory, we can't free the memmap's page because page_count() is 2 after put_page_bootmem(). sparse_remove_one_section() free_section_usemap() free_map_bootmem() put_page_bootmem() [akpm@linux-foundation.org: add code comment] Signed-off-by:
Xishi Qiu <qiuxishi@huawei.com> Signed-off-by:
Jiang Liu <jiang.liu@huawei.com> Acked-by:
Mel Gorman <mgorman@suse.de> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Gavin Shan authored
commit 4e2f07750d9a94e8f23e86408df5ab95be88bf11 upstream. The overall memblock has been organized into the memory regions and reserved regions. Initially, the memory regions and reserved regions are stored in the predetermined arrays of "struct memblock _region". It's possible for the arrays to be enlarged when we have newly added regions for them, but no enough space there. Under the situation, We will created double-sized array to meet the requirement. However, the original implementation converted the VA (Virtual Address) of the newly allocated array of regions to PA (Physical Address), then translate back when we allocates the new array from slab. That's actually unnecessary. The patch removes the duplicate VA/PA conversion. Signed-off-by:
Gavin Shan <shangw@linux.vnet.ibm.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by:
-
Greg Thelen authored
commit 2bff24a3707093c435ab3241c47dcdb5f16e432b upstream. A memory cgroup with (1) multiple threshold notifications and (2) at least one threshold >=2G was not reliable. Specifically the notifications would either not fire or would not fire in the proper order. The __mem_cgroup_threshold() signaling logic depends on keeping 64 bit thresholds in sorted order. mem_cgroup_usage_register_event() sorts them with compare_thresholds(), which returns the difference of two 64 bit thresholds as an int. If the difference is positive but has bit[31] set, then sort() treats the difference as negative and breaks sort order. This fix compares the two arbitrary 64 bit thresholds returning the classic -1, 0, 1 result. The test below sets two notifications (at 0x1000 and 0x81001000): cd /sys/fs/cgroup/memory mkdir x for x in 4096 2164264960; do cgroup_event_listener x/memory.usage_in_bytes $x | sed "s/^/$x listener:/" & done echo $$ > x/cgroup.procs anon_leaker 500M v3.11-rc7 fails to signal the 4096 event listener: Leaking... Done leaking pages. Patched v3.11-rc7 properly notifies: Leaking... 4096 listener:2013:8:31:14:13:36 Done leaking pages. The fixed bug is old. It appears to date back to the introduction of memcg threshold notifications in v2.6.34-rc1-116-g2e72b634 "memcg: implement memory thresholds" Signed-off-by:Greg Thelen <gthelen@google.com> Acked-by:
Michal Hocko <mhocko@suse.cz> Acked-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by:
Johannes Weiner <hannes@cmpxchg.org> Signed-off-by:
-
Jordan Crouse authored
Only call the pt_log callback for active fences. CRs-Fixed: 744197 Change-Id: Ic0dedbadf0f5979fc155cdef332fedda9047f440 Signed-off-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
Lynus Vaz <lvaz@codeaurora.org> (cherry picked from commit c1ea464ed28baa6e3b896657e869bdfdb9eb9c77) Reviewed-on: http://gerrit.mot.com/726707 SLTApproved: Slta Waiver <sltawvr@motorola.com> SME-Granted: SME Approvals Granted Submit-Approved: Jira Key <jirakey@motorola.com> Tested-by:
Jira Key <jirakey@motorola.com> Reviewed-by:
Fred Fettinger <fettinge@motorola.com> Reviewed-by:
Stephen Rossbach <rossbach@motorola.com>
-
Jordan Crouse authored
Allow drivers to add a callback for expanded details about a sync point. This provides for a much richer debug experience than can be provided by the simpler callbacks. Change-Id: Ic0dedbad19fddc2f9b753d886994247e8025d6dc Signed-off-by:
-
Cody Ferber authored
I know we aren't even close to using gcc 4.9, so this might not get merged for a while, but here it is for when the time comes. :) 4.9 is even more finicky. Missing include. Change-Id: Ia1a0b675f37623735bc1c041fbdd0be61cdaa427
-
Abhijeet Dharmapurikar authored
commit 7eba2ac5de2b5a80898b7dbb42d8f0c0ec461c00 upstream. When asked to set a LDO voltage the driver rounds it up to the nearest step value. However, when checking if the requested voltage is already set it doesn't account for the rounding up. Fix this by rounding up the requested value, which avoids unnecessary calls to set the LDO voltage and switch to LDO. CRs-Fixed: 609879 Change-Id: Ia5a201721e39eece49dea3f61fbc585f116d5060 Signed-off-by:
Abhijeet Dharmapurikar <adharmap@codeaurora.org> Reviewed-on: http://gerrit.mot.com/680993 SLTApproved: Slta Waiver <sltawvr@motorola.com> Submit-Approved: Jira Key <jirakey@motorola.com> Tested-by:
Christopher Fries <cfries@motorola.com>
-
Will Deacon authored
commit f5f2025ef3e2cdb593707cbf87378761f17befbe upstream. Page migration encodes the pfn in the offset field of a swp_entry_t. For LPAE, we support physical addresses of up to 36 bits (due to sparsemem limitations with the size of page flags), requiring 24 bits to represent a pfn. A further 3 bits are used to encode a swp_entry into a pte, leaving 5 bits for the type field. Furthermore, the core code defines MAX_SWAPFILES_SHIFT as 5, so the additional type bit does not get used. This patch reduces the width of the type field to 5 bits, allowing us to create up to 31 swapfiles of 64GB each. Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Dan Carpenter authored
commit de1e0c40aceb9d5bff09c3a3b97b2f1b178af53f upstream. The ->reserved field isn't cleared so we leak one byte of stack information to userspace. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Eric Paris <eparis@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Anurup m authored
commit ec686c9239b4d472052a271c505d04dae84214cc upstream. There is a kernel memory leak observed when the proc file /proc/fs/fscache/stats is read. The reason is that in fscache_stats_open, single_open is called and the respective release function is not called during release. Hence fix with correct release function - single_release(). Addresses https://bugzilla.kernel.org/show_bug.cgi?id=57101 Signed-off-by:
Anurup m <anurup.m@huawei.com> Cc: shyju pv <shyju.pv@huawei.com> Cc: Sanil kumar <sanil.kumar@huawei.com> Cc: Nataraj m <nataraj.m@huawei.com> Cc: Li Zefan <lizefan@huawei.com> Cc: David Howells <dhowells@redhat.com> Signed-off-by:
-
majianpeng authored
commit 2d32b29a1c2830f7c42caa8258c714acd983961f upstream. When free nfs-client, it must free the ->cl_stateids. Signed-off-by:
Jianpeng Ma <majianpeng@gmail.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Xu Kai authored
Previously, when the leds were working in LPG mode, the pwm period was always set to the minimum value supported by hardware. That's unreasonable. The better way is to set the period to the expected value. CRs-Fixed: 655566 Change-Id: I30b17cbfe98639ec132484f314cb9b9234e74354 Signed-off-by:Xu Kai <kaixu@codeaurora.org>
-
Javi Merino authored
pl330_update() stores a pointer to the thrd->req that finished, which contains a pointer to the corresponding pl330_req. This is done with the pl330_lock held. Then, it iterates through the req_done list, calling the callback for each of the requests that are done. The problem is that the driver releases the lock before calling the callback for each of the callbacks. pl330_submit_req() running in another processor can then acquire the lock and insert another request in one of the thrd->req that hasn't been processed yet, replacing the pointer to pl330_req there. When the callback returns in pl330_update() and the next rqdone is popped from the list, it dereferences the pl330_req pointer to the just scheduled pl330_req, instead of the one that has finished, calling pl330 with the wrong r. This patch fixes this by storing the pointer to pl330_req directly in the list. (cherry picked from commit fdec53d5203ee3d44be7c09d1524e3a6287d46a7 from android-3.10) Bug: 15828462 Bug: 15859101 Change-Id: Icb6f7bc08fd372c8688fd157eda6add721d43c29 Signed-off-by:
Javi Merino <javi.merino@arm.com> Cc: Jassi Brar <jaswinder.singh@linaro.org> Acked-by:
Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by:
Vinod Koul <vinod.koul@linux.intel.com>
-
Chen Gang authored
commit 12b2f117f3bf738c1a00a6f64393f1953a740bd4 upstream. audit_trim_trees() calls get_tree(). If a failure occurs we must call put_tree(). [akpm@linux-foundation.org: run put_tree() before mutex_lock() for small scalability improvement] Signed-off-by:
Chen Gang <gang.chen@asianux.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Eric Paris <eparis@redhat.com> Signed-off-by:
Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by:
-
Anton Blanchard authored
commit cdee3904b4ce7c03d1013ed6dd704b43ae7fc2e9 upstream. Commit b05d8447 (audit: inline audit_syscall_entry to reduce burden on archs) changed audit_syscall_entry to check for a dummy context before calling __audit_syscall_entry. Unfortunately the dummy context state is maintained in __audit_syscall_entry so once set it never gets cleared, even if the audit rules change. As a result, if there are no auditing rules when a process starts then it will never be subject to any rules added later. x86 doesn't see this because it has an assembly fast path that calls directly into __audit_syscall_entry. I noticed this issue when working on audit performance optimisations. I wrote a set of simple test cases available at: http://ozlabs.org/~anton/junkcode/audit_tests.tar.gz 02_new_rule.py fails without the patch and passes with it. The test case clears all rules, starts a process, adds a rule then verifies the process produces a syscall audit record. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Eric Paris <eparis@redhat.com> Signed-off-by:
-
JP Abgrall authored
Bail out early if IRQs are disabled in do_page_fault or else [14415.157266] BUG: sleeping function called from invalid context at arch/arm/mm/fault.c:301 Russell King's idea from http://comments.gmane.org/gmane.linux.ports.arm.omap/59256 Signed-off-by:
JP Abgrall <jpa@google.com>
-
Zefan Li authored
Reported-by:
Jim Faulkner <jfaulkne@ccs.neu.edu> Fixed-by:
Nicolas Schichan <nschichan@freebox.fr> Signed-off-by:
-
Liu Hua authored
commit 8fad87bca7ac9737e413ba5f1656f1114a8c314d upstream. When we configure CONFIG_ARM_LPAE=y, pfn << PAGE_SHIFT will overflow if pfn >= 0x100000 in copy_oldmem_page. So use __pfn_to_phys for converting. Signed-off-by:
Liu Hua <sdu.liu@huawei.com> Signed-off-by:
-
Jean-Jacques Hiblot authored
commit 1588c51cf6d782e63a8719681d905ef0ac22ee62 upstream. There was a copy/paste error when reading the nwe_pulse value. Signed-off-by:
Jean-Jacques Hiblot <jjhiblot@traphandler.com> Acked-by:
Boris BREZILLON <b.brezillon@overkiz.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Kevin Hilman <khilman@linaro.org> Signed-off-by:
-
Vinay Kalia authored
Venus has some additional alignment requirements on top of standard NV12/NV21 color format. This change explains these requirements. Change-Id: I3c9ce7d93744c529790a0828085125e71cb7affe Signed-off-by:Vinay Kalia <vkalia@codeaurora.org>
-
Al Viro authored
commit 64cb927371cd2ec43758d8a094a003d27bc3d0dc upstream. Both ext3 and ext4 htree_dirblock_to_tree() is just filling the in-core rbtree for use by call_filldir(). All updates of ->f_pos are done by the latter; bumping it here (on error) is obviously wrong - we might very well have it nowhere near the block we'd found an error in. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Jan Kara authored
commit 8af8eecc1331dbf5e8c662022272cf667e213da5 upstream. The arithmetics adding delalloc blocks to the number of used blocks in ext4_getattr() can easily overflow on 32-bit archs as we first multiply number of blocks by blocksize and then divide back by 512. Make the arithmetics more clever and also use proper type (unsigned long long instead of unsigned long). Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
yonghua zheng authored
commit 8c8296223f3abb142be8fc31711b18a704c0e7d8 upstream. Recently we met quite a lot of random kernel panic issues after enabling CONFIG_PROC_PAGE_MONITOR. After debuggind we found this has something to do with following bug in pagemap: In struct pagemapread: struct pagemapread { int pos, len; pagemap_entry_t *buffer; bool v2; }; pos is number of PM_ENTRY_BYTES in buffer, but len is the size of buffer, it is a mistake to compare pos and len in add_page_map() for checking buffer is full or not, and this can lead to buffer overflow and random kernel panic issue. Correct len to be total number of PM_ENTRY_BYTES in buffer. [akpm@linux-foundation.org: document pagemapread.pos and .len units, fix PM_ENTRY_BYTES definition] Signed-off-by:Yonghua Zheng <younghua.zheng@gmail.com> Signed-off-by:
-
Roland Dreier authored
commit 35dc248383bbab0a7203fca4d722875bc81ef091 upstream. There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances leads to one process writing data into the address space of some other random unrelated process if the ioctl is interrupted by a signal. What happens is the following: - A process issues an SG_IO ioctl with direction DXFER_FROM_DEV (ie the underlying SCSI command will transfer data from the SCSI device to the buffer provided in the ioctl) - Before the command finishes, a signal is sent to the process waiting in the ioctl. This will end up waking up the sg_ioctl() code: result = wait_event_interruptible(sfp->read_wait, (srp_done(sfp, srp) || sdp->detached)); but neither srp_done() nor sdp->detached is true, so we end up just setting srp->orphan and returning to userspace: srp->orphan = 1; write_unlock_irq(&sfp->rq_list_lock); return result; /* -ERESTARTSYS because signal hit process */ At this point the original process is done with the ioctl and blithely goes ahead handling the signal, reissuing the ioctl, etc. - Eventually, the SCSI command issued by the first ioctl finishes and ends up in sg_rq_end_io(). At the end of that function, we run through: write_lock_irqsave(&sfp->rq_list_lock, iflags); if (unlikely(srp->orphan)) { if (sfp->keep_orphan) srp->sg_io_owned = 0; else done = 0; } srp->done = done; write_unlock_irqrestore(&sfp->rq_list_lock, iflags); if (likely(done)) { /* Now wake up any sg_read() that is waiting for this * packet. */ wake_up_interruptible(&sfp->read_wait); kill_fasync(&sfp->async_qp, SIGPOLL, POLL_IN); kref_put(&sfp->f_ref, sg_remove_sfp); } else { INIT_WORK(&srp->ew.work, sg_rq_end_io_usercontext); schedule_work(&srp->ew.work); } Since srp->orphan *is* set, we set done to 0 (assuming the userspace app has not set keep_orphan via an SG_SET_KEEP_ORPHAN ioctl), and therefore we end up scheduling sg_rq_end_io_usercontext() to run in a workqueue. - In workqueue context we go through sg_rq_end_io_usercontext() -> sg_finish_rem_req() -> blk_rq_unmap_user() -> ... -> bio_uncopy_user() -> __bio_copy_iov() -> copy_to_user(). The key point here is that we are doing copy_to_user() on a workqueue -- that is, we're on a kernel thread with current->mm equal to whatever random previous user process was scheduled before this kernel thread. So we end up copying whatever data the SCSI command returned to the virtual address of the buffer passed into the original ioctl, but it's quite likely we do this copying into a different address space! As suggested by James Bottomley <James.Bottomley@hansenpartnership.com>, add a check for current->mm (which is NULL if we're on a kernel thread without a real userspace address space) in bio_uncopy_user(), and skip the copy if we're on a kernel thread. There's no reason that I can think of for any caller of bio_uncopy_user() to want to do copying on a kernel thread with a random active userspace address space. Huge thanks to Costa Sapuntzakis <costa@purestorage.com> for the original pointer to this bug in the sg code. Signed-off-by:Roland Dreier <roland@purestorage.com> Tested-by:
David Milburn <dmilburn@redhat.com> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> [lizf: backported to 3.4: - Use __bio_for_each_segment() instead of bio_for_each_segment_all()] Signed-off-by:
-
Theodore Ts'o authored
commit 0e9a9a1ad619e7e987815d20262d36a2f95717ca upstream. When trying to mount a file system which does not contain a journal, but which does have a orphan list containing an inode which needs to be truncated, the mount call with hang forever in ext4_orphan_cleanup() because ext4_orphan_del() will return immediately without removing the inode from the orphan list, leading to an uninterruptible loop in kernel code which will busy out one of the CPU's on the system. This can be trivially reproduced by trying to mount the file system found in tests/f_orphan_extents_inode/image.gz from the e2fsprogs source tree. If a malicious user were to put this on a USB stick, and mount it on a Linux desktop which has automatic mounts enabled, this could be considered a potential denial of service attack. (Not a big deal in practice, but professional paranoids worry about such things, and have even been known to allocate CVE numbers for such problems.) -js: This is a fix for CVE-2013-2015. Signed-off-by:
Zheng Liu <wenqing.lz@taobao.com> Acked-by:
-
JP Abgrall authored
* What This provides an interface for issuing an FITRIM which uses the secure discard instead of just a discard. Only the eMMC command is "secure", and not how the FS uses it: due to the fact that the FS might reassign a region somewhere else, the original deleted data will not be affected by the "trim" which only handles un-used regions. So we'll just call it "deep discard", and note that this is a "best effort" cleanup. * Why Once in a while, We want to be able to cleanup most of the unused blocks after erasing a bunch of files. We don't want to constantly secure-discard via a mount option. From an eMMC spec perspective, it tells the device to really get rid of all the data for the specified blocks and not just put them back into the pool of free ones (unlike the normal TRIM). The eMMC spec says the secure trim handling must make sure the data (and metadata) is not available anymore. A simple TRIM doesn't clear the data, it just puts blocks in the free pool. JEDEC Standard No. 84-A441 7.6.9 Secure Erase 7.6.10 Secure Trim From an FS perspective, it is acceptable to leave some data behind. - directory entries related to deleted files - databases entries related to deleted files - small-file data stored in inode extents - blocks held by the FS waiting to be re-used (mitigated by sync). - blocks reassigned by the FS prior to FIDTRIM. Change-Id: I676a1404a80130d93930c84898360f2e6fb2f81e Signed-off-by:
Geremy Condra <gcondra@google.com> Signed-off-by:
-
Subbaraman Narayanamurthy authored
Some GIC register accesses happens more frequently flooding the RTB logs. Since they're not that useful for debugging purposes, use _no_log variants while accessing those registers. Change-Id: Idfb48c668eb90a3187fa3afdd7df5cd64062559d Signed-off-by:Subbaraman Narayanamurthy <subbaram@codeaurora.org>
-
Al Viro authored
Change-Id: Id43457ef30eaf9e90048644fae1d89030cb6fec9 CRs-fixed: 592079 Signed-off-by:
Joonwoo Park <joonwoop@codeaurora.org>
-
Matt Wagantall authored
There is an unhandled corner case with the current check which has recently been hit. The nbytes argument may be large enough for the range being dumped to cross a boundary between page-table mappings, and dump addresses which are vmalloc'd in the neighboring mapping. Check every address being dumped to see if its vmalloc'd, not just the address passed to show_data(). CRs-Fixed: 625442 Change-Id: I255b093808177321f5202dcacea337ee333bfc63 Signed-off-by:Matt Wagantall <mattw@codeaurora.org>
-
Kishan Kumar authored
A new socinfo format version 9 is added with support for foundry id. Update the socinfo struct to reflect this change. CRs-Fixed: 645243 Change-Id: I8cfd961cd29fc8b7173650e22738db81a7069811 Signed-off-by:Kishan Kumar <kishank@codeaurora.org>
-
Abhimanyu Kapur authored
Add sysfs node to socinfo to read the platform subtype id. This is meant to deprecate the platform_subtype string sysfs node. Change-Id: I4bcb6f9cc6af18fd0cf7ea5aeb6da12a124c9ae1 Signed-off-by:Abhimanyu Kapur <abhimany@codeaurora.org>
-
Hareesh Gundu authored
Remove unused variables from legacy IB timeout detection. Change-Id: I4df94ee43072ccebff4045c5950edbc406de38a8 Signed-off-by:Hareesh Gundu <hareeshg@codeaurora.org>
-
