- 01 Dec, 2019 40 commits
-
-
Masahiro Yamada authored
[ Upstream commit 39226aaa ] Currently, a timeout error could happen at a repeated START condition. For a (non-repeated) START condition, the controller starts sending data when the UNIPHIER_FI2C_CR_STA bit is set. However, for a repeated START condition, the hardware starts running when the slave address is written to the TX FIFO - the write to the UNIPHIER_FI2C_CR register is actually unneeded. Because the hardware is already running before the IRQ is enabled for a repeated START, the driver may miss the IRQ event. In most cases, this problem does not show up since modern CPUs are much faster than the I2C transfer. However, it is still possible that a context switch happens after the controller starts, but before the IRQ register is set up. To fix this, - Do not write UNIPHIER_FI2C_CR for repeated START conditions. - Enable IRQ *before* writing the slave address to the TX FIFO. - Disable IRQ for the current CPU while queuing up the TX FIFO; If the CPU is interrupted by some task, the interrupt handler might be invoked due to the empty TX FIFO before completing the setup. Fixes: 6a62974b ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver") Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Masahiro Yamada authored
[ Upstream commit f1fdcbbd ] This is unlikely to happen, but it is possible for a CPU to enter the interrupt handler just after wait_for_completion_timeout() has expired. If this happens, the hardware is accessed from multiple contexts concurrently. Disable the IRQ after wait_for_completion_timeout(), and do nothing from the handler when the IRQ is disabled. Fixes: 6a62974b ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver") Signed-off-by:
-
Jianchao Wang authored
[ Upstream commit 69840466 ] There are two cases when handle DISCARD merge. If max_discard_segments == 1, the bios/requests need to be contiguous to merge. If max_discard_segments > 1, it takes every bio as a range and different range needn't to be contiguous. But now, attempt_merge screws this up. It always consider contiguity for DISCARD for the case max_discard_segments > 1 and cannot merge contiguous DISCARD for the case max_discard_segments == 1, because rq_attempt_discard_merge always returns false in this case. This patch fixes both of the two cases above. Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Ming Lei <ming.lei@redhat.com> Signed-off-by:
Jianchao Wang <jianchao.w.wang@oracle.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Sabrina Dubroca authored
[ Upstream commit 07bddef9 ] Currently, the kernel doesn't let the administrator set a macsec device up unless its lower device is currently up. This is inconsistent, as a macsec device that is up won't automatically go down when its lower device goes down. Now that linkstate propagation works, there's really no reason for this limitation, so let's remove it. Fixes: c09440f7 ("macsec: introduce IEEE 802.1AE driver") Reported-by:
Radu Rendec <radu.rendec@gmail.com> Signed-off-by:
Sabrina Dubroca <sd@queasysnail.net> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Sabrina Dubroca authored
[ Upstream commit e6ac0758 ] Like all other virtual devices (macvlan, vlan), the operstate of a macsec device should match the state of its lower device. This is done by calling netif_stacked_transfer_operstate from its netdevice notifier. We also need to call netif_stacked_transfer_operstate when a new macsec device is created, so that its operstate is set properly. This is only relevant when we try to bring the device up directly when we create it. Radu Rendec proposed a similar patch, inspired from the 802.1q driver, that included changing the administrative state of the macsec device, instead of just the operstate. This version is similar to what the macvlan driver does, and updates only the operstate. Fixes: c09440f7 ("macsec: introduce IEEE 802.1AE driver") Reported-by:
Patrick Talbert <ptalbert@redhat.com> Signed-off-by:
-
Andrea Arcangeli authored
[ Upstream commit d7c33934 ] Patch series "migrate_misplaced_transhuge_page race conditions". Aaron found a new instance of the THP MADV_DONTNEED race against pmdp_clear_flush* variants, that was apparently left unfixed. While looking into the race found by Aaron, I may have found two more issues in migrate_misplaced_transhuge_page. These race conditions would not cause kernel instability, but they'd corrupt userland data or leave data non zero after MADV_DONTNEED. I did only minor testing, and I don't expect to be able to reproduce this (especially the lack of ->invalidate_range before migrate_page_copy, requires the latest iommu hardware or infiniband to reproduce). The last patch is noop for x86 and it needs further review from maintainers of archs that implement flush_cache_range() (not in CC yet). To avoid confusion, it's not the first patch that introduces the bug fixed in the second patch, even before removing the pmdp_huge_clear_flush_notify, that _notify suffix was called after migrate_page_copy already run. This patch (of 3): This is a corollary of ced10803 ("thp: fix MADV_DONTNEED vs. numa balancing race"), 58ceeb6b ("thp: fix MADV_DONTNEED vs. MADV_FREE race") and 5b7abeae ("thp: fix MADV_DONTNEED vs clear soft dirty race). When the above three fixes where posted Dave asked https://lkml.kernel.org/r/929b3844-aec2-0111-fef7-8002f9d4e2b9@intel.com but apparently this was missed. The pmdp_clear_flush* in migrate_misplaced_transhuge_page() was introduced in a54a407f ("mm: Close races between THP migration and PMD numa clearing"). The important part of such commit is only the part where the page lock is not released until the first do_huge_pmd_numa_page() finished disarming the pagenuma/protnone. The addition of pmdp_clear_flush() wasn't beneficial to such commit and there's no commentary about such an addition either. I guess the pmdp_clear_flush() in such commit was added just in case for safety, but it ended up introducing the MADV_DONTNEED race condition found by Aaron. At that point in time nobody thought of such kind of MADV_DONTNEED race conditions yet (they were fixed later) so the code may have looked more robust by adding the pmdp_clear_flush(). This specific race condition won't destabilize the kernel, but it can confuse userland because after MADV_DONTNEED the memory won't be zeroed out. This also optimizes the code and removes a superfluous TLB flush. [akpm@linux-foundation.org: reflow comment to 80 cols, fix grammar and typo (beacuse)] Link: http://lkml.kernel.org/r/20181013002430.698-2-aarcange@redhat.comSigned-off-by:
Andrea Arcangeli <aarcange@redhat.com> Reported-by:
Aaron Tomlin <atomlin@redhat.com> Acked-by:
Mel Gorman <mgorman@suse.de> Acked-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Jerome Glisse <jglisse@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Keith Busch authored
[ Upstream commit 319e0bec ] If the '-w' parameter was provided, the benchmark would exit due to a mssing 'break'. Link: http://lkml.kernel.org/r/20181010195605.10689-3-keith.busch@intel.comSigned-off-by:
Keith Busch <keith.busch@intel.com> Acked-by:
-
Dave Chinner authored
[ Upstream commit 64081362 ] We've recently seen a workload on XFS filesystems with a repeatable deadlock between background writeback and a multi-process application doing concurrent writes and fsyncs to a small range of a file. range_cyclic writeback Process 1 Process 2 xfs_vm_writepages write_cache_pages writeback_index = 2 cycled = 0 .... find page 2 dirty lock Page 2 ->writepage page 2 writeback page 2 clean page 2 added to bio no more pages write() locks page 1 dirties page 1 locks page 2 dirties page 1 fsync() .... xfs_vm_writepages write_cache_pages start index 0 find page 1 towrite lock Page 1 ->writepage page 1 writeback page 1 clean page 1 added to bio find page 2 towrite lock Page 2 page 2 is writeback <blocks> write() locks page 1 dirties page 1 fsync() .... xfs_vm_writepages write_cache_pages start index 0 !done && !cycled sets index to 0, restarts lookup find page 1 dirty find page 1 towrite lock Page 1 page 1 is writeback <blocks> lock Page 1 <blocks> DEADLOCK because: - process 1 needs page 2 writeback to complete to make enough progress to issue IO pending for page 1 - writeback needs page 1 writeback to complete so process 2 can progress and unlock the page it is blocked on, then it can issue the IO pending for page 2 - process 2 can't make progress until process 1 issues IO for page 1 The underlying cause of the problem here is that range_cyclic writeback is processing pages in descending index order as we hold higher index pages in a structure controlled from above write_cache_pages(). The write_cache_pages() caller needs to be able to submit these pages for IO before write_cache_pages restarts writeback at mapping index 0 to avoid wcp inverting the page lock/writeback wait order. generic_writepages() is not susceptible to this bug as it has no private context held across write_cache_pages() - filesystems using this infrastructure always submit pages in ->writepage immediately and so there is no problem with range_cyclic going back to mapping index 0. However: mpage_writepages() has a private bio context, exofs_writepages() has page_collect fuse_writepages() has fuse_fill_wb_data nfs_writepages() has nfs_pageio_descriptor xfs_vm_writepages() has xfs_writepage_ctx All of these ->writepages implementations can hold pages under writeback in their private structures until write_cache_pages() returns, and hence they are all susceptible to this deadlock. Also worth noting is that ext4 has it's own bastardised version of write_cache_pages() and so it /may/ have an equivalent deadlock. I looked at the code long enough to understand that it has a similar retry loop for range_cyclic writeback reaching the end of the file and then promptly ran away before my eyes bled too much. I'll leave it for the ext4 developers to determine if their code is actually has this deadlock and how to fix it if it has. There's a few ways I can see avoid this deadlock. There's probably more, but these are the first I've though of: 1. get rid of range_cyclic altogether 2. range_cyclic always stops at EOF, and we start again from writeback index 0 on the next call into write_cache_pages() 2a. wcp also returns EAGAIN to ->writepages implementations to indicate range cyclic has hit EOF. writepages implementations can then flush the current context and call wpc again to continue. i.e. lift the retry into the ->writepages implementation 3. range_cyclic uses trylock_page() rather than lock_page(), and it skips pages it can't lock without blocking. It will already do this for pages under writeback, so this seems like a no-brainer 3a. all non-WB_SYNC_ALL writeback uses trylock_page() to avoid blocking as per pages under writeback. I don't think #1 is an option - range_cyclic prevents frequently dirtied lower file offset from starving background writeback of rarely touched higher file offsets. #2 is simple, and I don't think it will have any impact on performance as going back to the start of the file implies an immediate seek. We'll have exactly the same number of seeks if we switch writeback to another inode, and then come back to this one later and restart from index 0. #2a is pretty much "status quo without the deadlock". Moving the retry loop up into the wcp caller means we can issue IO on the pending pages before calling wcp again, and so avoid locking or waiting on pages in the wrong order. I'm not convinced we need to do this given that we get the same thing from #2 on the next writeback call from the writeback infrastructure. #3 is really just a band-aid - it doesn't fix the access/wait inversion problem, just prevents it from becoming a deadlock situation. I'd prefer we fix the inversion, not sweep it under the carpet like this. #3a is really an optimisation that just so happens to include the band-aid fix of #3. So it seems that the simplest way to fix this issue is to implement solution #2 Link: http://lkml.kernel.org/r/20181005054526.21507-1-david@fromorbit.comSigned-off-by:
Dave Chinner <dchinner@redhat.com> Reviewed-by:
Jan Kara <jack@suse.de> Cc: Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
-
Jia-Ju Bai authored
[ Upstream commit 99986576 ] The kernel module may sleep with holding a spinlock. The function call paths (from bottom to top) in Linux-4.16 are: [FUNC] get_zeroed_page(GFP_NOFS) fs/ocfs2/dlm/dlmdebug.c, 332: get_zeroed_page in dlm_print_one_mle fs/ocfs2/dlm/dlmmaster.c, 240: dlm_print_one_mle in __dlm_put_mle fs/ocfs2/dlm/dlmmaster.c, 255: __dlm_put_mle in dlm_put_mle fs/ocfs2/dlm/dlmmaster.c, 254: spin_lock in dlm_put_ml [FUNC] get_zeroed_page(GFP_NOFS) fs/ocfs2/dlm/dlmdebug.c, 332: get_zeroed_page in dlm_print_one_mle fs/ocfs2/dlm/dlmmaster.c, 240: dlm_print_one_mle in __dlm_put_mle fs/ocfs2/dlm/dlmmaster.c, 222: __dlm_put_mle in dlm_put_mle_inuse fs/ocfs2/dlm/dlmmaster.c, 219: spin_lock in dlm_put_mle_inuse To fix this bug, GFP_NOFS is replaced with GFP_ATOMIC. This bug is found by my static analysis tool DSAC. Link: http://lkml.kernel.org/r/20180901112528.27025-1-baijiaju1990@gmail.comSigned-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Reviewed-by:
-
Andrey Ryabinin authored
[ Upstream commit 19a2ca0f ] ARM64 has asm implementation of memchr(), memcmp(), str[r]chr(), str[n]cmp(), str[n]len(). KASAN don't see memory accesses in asm code, thus it can potentially miss many bugs. Ifdef out __HAVE_ARCH_* defines of these functions when KASAN is enabled, so the generic implementations from lib/string.c will be used. We can't just remove the asm functions because efistub uses them. And we can't have two non-weak functions either, so declare the asm functions as weak. Link: http://lkml.kernel.org/r/20180920135631.23833-2-aryabinin@virtuozzo.comSigned-off-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Reported-by:
Kyeongdon Kim <kyeongdon.kim@lge.com> Cc: Alexander Potapenko <glider@google.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 6c2fc9cd ] Such as: fs/ocfs2/file.c: In function ‘ocfs2_file_write_iter’: ./arch/sparc/include/asm/cmpxchg_64.h:55:22: warning: value computed is not used [-Wunused-value] #define xchg(ptr,x) ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr)))) and drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c: In function ‘ixgbevf_xdp_setup’: ./arch/sparc/include/asm/cmpxchg_64.h:55:22: warning: value computed is not used [-Wunused-value] #define xchg(ptr,x) ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr)))) Signed-off-by:
-
Felipe Rechia authored
[ Upstream commit e9013785 ] Fix a bug introduced by the creation of flush_all_to_thread() for processors that have SPE (Signal Processing Engine) and use it to compute floating-point operations. >From userspace perspective, the problem was seen in attempts of computing floating-point operations which should generate exceptions. For example: fork(); float x = 0.0 / 0.0; isnan(x); // forked process returns False (should be True) The operation above also should always cause the SPEFSCR FINV bit to be set. However, the SPE floating-point exceptions were turned off after a fork(). Kernel versions prior to the bug used flush_spe_to_thread(), which first saves SPEFSCR register values in tsk->thread and then calls giveup_spe(tsk). After commit 579e633e, the save_all() function was called first to giveup_spe(), and then the SPEFSCR register values were saved in tsk->thread. This would save the SPEFSCR register values after disabling SPE for that thread, causing the bug described above. Fixes 579e633e ("powerpc: create flush_all_to_thread()") Signed-off-by:
Felipe Rechia <felipe.rechia@datacom.com.br> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Martin Lau authored
[ Upstream commit 4a6998af ] Wenwen Wang reported: In btf_parse(), the header of the user-space btf data 'btf_data' is firstly parsed and verified through btf_parse_hdr(). In btf_parse_hdr(), the header is copied from user-space 'btf_data' to kernel-space 'btf->hdr' and then verified. If no error happens during the verification process, the whole data of 'btf_data', including the header, is then copied to 'data' in btf_parse(). It is obvious that the header is copied twice here. More importantly, no check is enforced after the second copy to make sure the headers obtained in these two copies are same. Given that 'btf_data' resides in the user space, a malicious user can race to modify the header between these two copies. By doing so, the user can inject inconsistent data, which can cause undefined behavior of the kernel and introduce potential security risk. This issue is similar to the one fixed in commit 8af03d1a ("bpf: btf: Fix a missing check bug"). To fix it, this patch copies the user 'btf_data' *before* parsing / verifying the BTF header. Fixes: 69b693f0 ("bpf: btf: Introduce BPF Type Format (BTF)") Signed-off-by:
Martin KaFai Lau <kafai@fb.com> Co-developed-by:
Wenwen Wang <wang6495@umn.edu> Acked-by:
Song Liu <songliubraving@fb.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Taehee Yoo authored
[ Upstream commit f592f804 ] The dev_map_notification() removes interface in devmap if unregistering interface's ifindex is same. But only checking ifindex is not enough because other netns can have same ifindex. so that wrong interface selection could occurred. Hence netdev pointer comparison code is added. v2: compare netdev pointer instead of using net_eq() (Daniel Borkmann) v1: Initial patch Fixes: 2ddf71e2 ("net: add notifier hooks for devmap bpf map") Signed-off-by:
Taehee Yoo <ap420073@gmail.com> Acked-by:
-
Tristram Ha authored
[ Upstream commit 899ecaed ] Socket buffer is not re-created when headroom is 2 and tailroom is 1. Signed-off-by:
Tristram Ha <Tristram.Ha@microchip.com> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 3a313862 ] On r8a7791/koelsch, sometimes the following message is printed during system suspend: rcar_thermal e61f0000.thermal: thermal sensor was broken This happens if the workqueue runs while the device is already suspended. Fix this by using the freezable system workqueue instead, cfr. commit 51e20d0e ("thermal: Prevent polling from happening during system suspend"). Fixes: e0a5172e ("thermal: rcar: add interrupt support") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
Eduardo Valentin <edubezval@gmail.com> Signed-off-by:
-
Sergei Shtylyov authored
[ Upstream commit df016bbb ] The driver on R8A77995 requests the same IRQ twice since platform_get_resource() is always called for the 1st IRQ resource. Fixes: 1969d9dc ("thermal: rcar_thermal: add r8a77995 support") Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by:
Simon Horman <horms+renesas@verge.net.au> Reviewed-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
-
Peng Hao authored
[ Upstream commit 0387662d ] Makefile contains -D_GNU_SOURCE. remove define "_GNU_SOURCE" in c files. Signed-off-by:
Peng Hao <peng.hao2@zte.com.cn> Signed-off-by:
Shuah Khan (Samsung OSG) <shuah@kernel.org> Signed-off-by:
-
Andrea Parri authored
[ Upstream commit fb363e2d ] Fixes the following warnings: dirty_log_test.c: In function ‘help’: dirty_log_test.c:216:9: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘int’ [-Wformat=] printf(" -i: specify iteration counts (default: %"PRIu64")\n", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/test_util.h:18:0, from dirty_log_test.c:16: /usr/include/inttypes.h:105:34: note: format string is defined here # define PRIu64 __PRI64_PREFIX "u" dirty_log_test.c:218:9: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘int’ [-Wformat=] printf(" -I: specify interval in ms (default: %"PRIu64" ms)\n", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/test_util.h:18:0, from dirty_log_test.c:16: /usr/include/inttypes.h:105:34: note: format string is defined here # define PRIu64 __PRI64_PREFIX "u" Signed-off-by:
Andrea Parri <andrea.parri@amarulasolutions.com> Signed-off-by:
-
Jerry Hoemann authored
[ Upstream commit 04d5e4bd ] Printf's say errno but print the string version of error. Make consistent. Signed-off-by:
Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by:
-
Shuah Khan (Samsung OSG) authored
[ Upstream commit 9a244229 ] When /dev/watchdog open fails, watchdog exits with "watchdog not enabled" message. This is incorrect when open fails due to insufficient privilege. Fix message to clearly state the reason when open fails with EACCESS when a non-root user runs it. Signed-off-by:
-
Masami Hiramatsu authored
[ Upstream commit 2452c96e ] Test $comm in kprobe-event argument syntax testcase only if it is supported on the kernel because $comm has been introduced 4.8 kernel. So on older stable kernel, it should be skipped. Signed-off-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
-
Keiji Hayashibara authored
[ Upstream commit 3511ba7d ] This commit fixes incorrect property because it was different from the actual. The parameters of '#address-cells' and '#size-cells' were removed, and 'interrupts', 'pinctrl-names' and 'pinctrl-0' were added. Fixes: 4dcd5c27 ("spi: add DT bindings for UniPhier SPI controller") Signed-off-by:
Keiji Hayashibara <hayashibara.keiji@socionext.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Garry McNulty authored
[ Upstream commit ef2298a0 ] In some error conditions, resp_buftype can be passed uninitialised to free_rsp_buf(), potentially resulting in a spurious debug message. If resp_buftype randomly had the value 1 (CIFS_SMALL_BUFFER) then this would log a debug message. The rsp pointer is initialised to NULL so there is no other side-effect. Detected by CoverityScan, CID 1438585 ("Uninitialized scalar variable") Detected by CoverityScan, CID 1438667 ("Uninitialized scalar variable") Detected by CoverityScan, CID 1438764 ("Uninitialized scalar variable") Signed-off-by:
Garry McNulty <garrmcnu@gmail.com> Signed-off-by:
Steve French <stfrench@microsoft.com> Reviewed-by:
Aurelien Aptel <aaptel@suse.com> Signed-off-by:
-
Masahisa Kojima authored
[ Upstream commit 8e850f25 ] In ndo_stop, driver resets the netsec ethernet controller IP. When the netsec IP is reset, HW running mode turns to NRM mode and driver has to wait until this mode transition completes. But mode transition to NRM will not complete if the PHY is in normal operation state. Netsec IP requires PHY is in power down state when it is reset. This modification stops the PHY before resetting netsec. Together with this modification, phy_addr is stored in netsec_priv structure because ndev->phydev is not yet ready in ndo_init. Fixes: 533dd11a ("net: socionext: Add Synquacer NetSec driver") Signed-off-by:
Masahisa Kojima <masahisa.kojima@linaro.org> Signed-off-by:
Yoshitoyo Osaki <osaki.yoshitoyo@socionext.com> Signed-off-by:
-
Marek Szyprowski authored
[ Upstream commit efddff27 ] IRQ wake up support for MAX8997 driver was initially configured by respective property in pdata. However, after the driver conversion to device-tree, setting it was left as 'todo'. Nowadays most of other PMIC MFD drivers initialized from device-tree assume that they can be an irq wakeup source, so enable it also for MAX8997. This fixes support for wakeup from MAX8997 RTC alarm. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit 9f8ddee1 ] Power button IRQ actually has a second level of interrupts to distinguish between UI and POWER buttons. Moreover, current implementation looks awkward in approach to handle second level IRQs by first level related IRQ chip. To address above issues, split power button IRQ to be chained as well. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Fabio Estevam authored
[ Upstream commit 55143439 ] When trying to read any MC13892 ADC channel on a imx51-babbage board: The MC13892 PMIC shutdowns completely. After debugging this issue and comparing the MC13892 and MC13783 initializations done in the vendor kernel, it was noticed that the CHRGRAWDIV bit of the ADC0 register was not being set. This bit is set by default after power on, but the driver was clearing it. After setting this bit it is possible to read the ADC values correctly. Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Tested-by:
Chris Healy <cphealy@gmail.com> Signed-off-by:
-
Sapthagiri Baratam authored
[ Upstream commit 6b269a41 ] Don't call runtime_put_sync when clk32k_ref is ARIZONA_32KZ_MCLK2 as there is no corresponding runtime_get_sync call. MCLK1 is not in the AoD power domain so if it is used as 32kHz clock source we need to hold a runtime PM reference to keep the device from going into low power mode. Fixes: cdd8da8c ("mfd: arizona: Add gating of external MCLKn clocks") Signed-off-by:
Sapthagiri Baratam <sapthagiri.baratam@cirrus.com> Acked-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by:
-
Ivan Khoronzhuk authored
[ Upstream commit 9737cc99 ] After flushing all mcast entries from the table, the ones contained in mc list of ndev are not restored when promisc mode is toggled off, because they are considered as synched with ALE, thus, in order to restore them after promisc mode - reset syncing info. This fix touches only switch mode devices, including single port boards like Beagle Bone. Fixes: commit 5da19489 ("net: ethernet: ti: cpsw: fix lost of mcast packets while rx_mode update") Signed-off-by:
Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Reviewed-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit c94f026f ] These functions are supposed to return one on failure and zero on success. Returning a zero here could cause uninitialized variable bugs in several of the callers. For example: drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:1660 get_iscsi_dcb_priority() error: uninitialized symbol 'caps'. Fixes: 48365e48 ("qlcnic: dcb: Add support for CEE Netlink interface.") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit aeb5e02a ] Clang warns (trimmed for brevity): drivers/isdn/mISDN/tei.c:1193:7: warning: overflow converting case value to switch condition type (2147764552 to 18446744071562348872) [-Wswitch] case IMHOLD_L1: ^ drivers/isdn/mISDN/tei.c:1187:7: warning: overflow converting case value to switch condition type (2147764550 to 18446744071562348870) [-Wswitch] case IMCLEAR_L2: ^ 2 warnings generated. The root cause is that the _IOC macro can generate really large numbers, which don't find into type int. My research into how GCC and Clang are handling this at a low level didn't prove fruitful and surveying the kernel tree shows that aside from here and a few places in the scsi subsystem, everything that uses _IOC is at least of type 'unsigned int'. Make that change here because as nothing in this function cares about the signedness of the variable and it removes ambiguity, which is never good when dealing with compilers. While we're here, remove the unnecessary local variable ret (just return -EINVAL and 0 directly). Link: https://github.com/ClangBuiltLinux/linux/issues/67Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Chao Yu authored
[ Upstream commit 9149a5eb ] This patch changes codes as below: - use f2fs_set_inode_flags() to update i_flags atomically to avoid potential race. - synchronize F2FS_I(inode)->i_flags to inode->i_flags in f2fs_new_inode(). - use f2fs_set_inode_flags() to simply codes in f2fs_quota_{on,off}. Signed-off-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Chao Yu authored
[ Upstream commit 2baf0781 ] We need to drop PG_checked flag on page as well when we clear PG_uptodate flag, in order to avoid treating the page as GCing one later. Signed-off-by:
Weichao Guo <guoweichao@huawei.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit d1d2c290 ] The platform_get_resource() function doesn't return error pointers, it returns NULL on error. Fixes: 3d4e5184 ("thermal: armada: convert driver to syscon register accesses") Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by:
-
Vincent Chen authored
[ Upstream commit 827a4381 ] For 32bit, the upper 32-bit of phys_addr_t will be flushed to zero after AND with PAGE_MASK because the data type of PAGE_MASK is unsigned long. To fix this problem, the page alignment is done by subtracting the page offset instead of AND with PAGE_MASK. Signed-off-by:
Vincent Chen <vincentc@andestech.com> Reviewed-by:
Palmer Dabbelt <palmer@sifive.com> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit ef0f02fd ] Clang warns: drivers/rtc/rtc-s35390a.c:124:27: warning: implicit conversion from 'int' to 'char' changes value from 192 to -64 [-Wconstant-conversion] buf = S35390A_FLAG_RESET | S35390A_FLAG_24H; ~ ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~ 1 warning generated. Update buf to be an unsigned 8-bit integer, which matches the buf member in struct i2c_msg. https://github.com/ClangBuiltLinux/linux/issues/145Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Luis Henriques authored
[ Upstream commit bddff633 ] Current implementation of cephfs fallocate isn't correct as it doesn't really reserve the space in the cluster, which means that a subsequent call to a write may actually fail due to lack of space. In fact, it is currently possible to fallocate an amount space that is larger than the free space in the cluster. It has behaved this way since the initial commit ad7a60de ("ceph: punch hole support"). Since there's no easy solution to fix this at the moment, this patch simply removes support for all fallocate operations but FALLOC_FL_PUNCH_HOLE (which implies FALLOC_FL_KEEP_SIZE). Link: https://tracker.ceph.com/issues/36317Signed-off-by:
Luis Henriques <lhenriques@suse.com> Reviewed-by:
"Yan, Zheng" <zyan@redhat.com> Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Yan, Zheng authored
[ Upstream commit c58f450b ] Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
-
Quentin Monnet authored
[ Upstream commit fe8ecccc ] When trying to complete "bpftool map update" commands, the call to printf would print an error message that would show on the command line if no map is found to complete the command line. Fix it by making sure we have map ids to complete the line with, before we try to print something. Signed-off-by:
Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
