- 13 Mar, 2020 40 commits
-
-
Janusz Krzysztofik authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 39034bb0 ] Commit da298c6d ("[media] v4l2: replace video op g_mbus_fmt by pad op get_fmt") converted a former ov6650_g_fmt() video operation callback to an ov6650_get_fmt() pad operation callback. However, the converted function disregards a format->which flag that pad operations should obey and always returns active frame format settings. That can be fixed by always responding to V4L2_SUBDEV_FORMAT_TRY with -EINVAL, or providing the response from a pad config argument, likely updated by a former user call to V4L2_SUBDEV_FORMAT_TRY .set_fmt(). Since implementation of the latter is trivial, go for it. Fixes: da298c6d ("[media] v4l2: replace video op g_mbus_fmt by pad op get_fmt") Signed-off-by:
Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Janusz Krzysztofik authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 1c6a2b63 ] User arguments passed to .get/set_fmt() pad operation callbacks may contain unsupported values. The driver takes control over frame size and pixel code as well as colorspace and field attributes but has never cared for remainig format attributes, i.e., ycbcr_enc, quantization and xfer_func, introduced by commit 11ff030c ("[media] v4l2-mediabus: improve colorspace support"). Fix it. Set up a static v4l2_mbus_framefmt structure with attributes initialized to reasonable defaults and use it for updating content of user provided arguments. In case of V4L2_SUBDEV_FORMAT_ACTIVE, postpone frame size update, now performed from inside ov6650_s_fmt() helper, util the user argument is first updated in ov6650_set_fmt() with default frame format content. For V4L2_SUBDEV_FORMAT_TRY, don't copy all attributes to pad config, only those handled by the driver, then fill the response with the default frame format updated with resulting pad config format code and frame size. Fixes: 11ff030c ("[media] v4l2-mediabus: improve colorspace support") Signed-off-by:
-
Janusz Krzysztofik authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 12500731 ] Since its initial submission, the driver selects V4L2_COLORSPACE_JPEG for supported formats other than V4L2_MBUS_FMT_SBGGR8_1X8. According to v4l2-compliance test program, V4L2_COLORSPACE_JPEG applies exclusively to V4L2_PIX_FMT_JPEG. Since the sensor does not support JPEG format, fix it to always select V4L2_COLORSPACE_SRGB. Fixes: 2f6e2404 ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by:
-
Stefan Wahren authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit bc19c329 ] The reset counter is specific for every QCA700x chip. So move this into the private driver struct. Otherwise we get unpredictable reset behavior in setups with multiple QCA700x chips. Fixes: 291ab06e (net: qualcomm: new Ethernet over SPI driver for QCA7000) Signed-off-by:
Stefan Wahren <stefan.wahren@in-tech.com> Signed-off-by:
Stefan Wahren <wahrenst@gmx.net> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Robin Gong authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit bd73dfab ] Illegal memory will be touch if SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3 (41) exceed the size of structure sdma_script_start_addrs(40), thus cause memory corrupt such as slob block header so that kernel trap into while() loop forever in slob_free(). Please refer to below code piece in imx-sdma.c: for (i = 0; i < sdma->script_number; i++) if (addr_arr[i] > 0) saddr_arr[i] = addr_arr[i]; /* memory corrupt here */ That issue was brought by commit a572460b ("dmaengine: imx-sdma: Add support for version 3 firmware") because SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3 (38->41 3 scripts added) not align with script number added in sdma_script_start_addrs(2 scripts). Fixes: a572460b ("dmaengine: imx-sdma: Add support for version 3 firmware") Cc: stable@vger.kernel Link: https://www.spinics.net/lists/arm-kernel/msg754895.htmlSigned-off-by:
Robin Gong <yibin.gong@nxp.com> Reported-by:
Jurgen Lambrecht <J.Lambrecht@TELEVIC.com> Link: https://lore.kernel.org/r/1569347584-3478-1-git-send-email-yibin.gong@nxp.com [vkoul: update the patch title] Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Jeffrey Hugo authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 78e31c42 ] On msm8998, vblank timeouts are observed because the DSI controller is not reset properly, which ends up stalling the MDP. This is because the reset logic is not correct per the hardware documentation. The documentation states that after asserting reset, software should wait some time (no indication of how long), or poll the status register until it returns 0 before deasserting reset. wmb() is insufficient for this purpose since it just ensures ordering, not timing between writes. Since asserting and deasserting reset occurs on the same register, ordering is already guaranteed by the architecture, making the wmb extraneous. Since we would define a timeout for polling the status register to avoid a possible infinite loop, lets just use a static delay of 20 ms, since 16.666 ms is the time available to process one frame at 60 fps. Fixes: a689554b ("drm/msm: Initial add DSI connector support") Cc: Hai Li <hali@codeaurora.org> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by:
Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Reviewed-by:
Sean Paul <sean@poorly.run> [seanpaul renamed RESET_DELAY to DSI_RESET_TOGGLE_DELAY_MS] Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191011133939.16551-1-jeffrey.l.hugo@gmail.comSigned-off-by:
-
Antonio Borneo authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 5da202c8 ] The field "name" in struct ptp_clock_info has a fixed size of 16 chars and is used as zero terminated string by clock_name_show() in drivers/ptp/ptp_sysfs.c The current initialization value requires 17 chars to fit also the null termination, and this causes overflow to the next bytes in the struct when the string is read as null terminated: hexdump -C /sys/class/ptp/ptp0/clock_name 00000000 73 74 6d 6d 61 63 5f 70 74 70 5f 63 6c 6f 63 6b |stmmac_ptp_clock| 00000010 a0 ac b9 03 0a |.....| where the extra 4 bytes (excluding the newline) after the string represent the integer 0x03b9aca0 = 62500000 assigned to the field "max_adj" that follows "name" in the same struct. There is no strict requirement for the "name" content and in the comment in ptp_clock_kernel.h it's reported it should just be 'A short "friendly name" to identify the clock'. Replace it with "stmmac ptp". Signed-off-by:
Antonio Borneo <antonio.borneo@st.com> Fixes: 92ba6888 ("stmmac: add the support for PTP hw clock driver") Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
Eric Biggers authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 36453c85 ] If llc_conn_state_process() sees that llc_conn_service() put the skb on a list, it will drop one fewer references to it. This is wrong because the current behavior is that llc_conn_service() never consumes a reference to the skb. The code also makes the number of skb references being dropped conditional on which of ind_prim and cfm_prim are nonzero, yet neither of these affects how many references are *acquired*. So there is extra code that tries to fix this up by sometimes taking another reference. Remove the unnecessary/broken refcounting logic and instead just add an skb_get() before the only two places where an extra reference is actually consumed. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Eric Biggers authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit fc8d5db1 ] All callers of llc_conn_state_process() except llc_build_and_send_pkt() (via llc_ui_sendmsg() -> llc_ui_send_data()) assume that it always consumes a reference to the skb. Fix this caller to do the same. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Johannes Berg authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 95697f99 ] We can process deauth frames and all, but we drop them very early in the RX path today - this could never have worked. Fixes: 2cc59e78 ("mac80211: reply to AUTH with DEAUTH if sta allocation fails in IBSS") Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20191004123706.15768-2-luca@coelho.fiSigned-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 23104218 ] The "gmac->phy_mode" variable is an enum and in this context GCC will treat it as an unsigned int so the error handling will never be triggered. Fixes: b1c17215 ("stmmac: add ipq806x glue layer") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 25a58495 ] The "priv->phy_interface" variable is an enum and in this context GCC will treat it as unsigned so the error handling will never be triggered. Fixes: 80105bef ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 002dfe80 ] The "priv->phy_mode" variable is an enum and in this context GCC will treat it as unsigned to the error handling will never trigger. Fixes: 57c5bc9a ("net: hisilicon: add hix5hd2 mac driver") Signed-off-by:
-
Filippo Sironi authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 0b15e02f ] To make sure the domain tlb flush completes before the function returns, explicitly wait for its completion. Signed-off-by:
Filippo Sironi <sironi@amazon.de> Fixes: 42a49f96 ("amd-iommu: flush domain tlb when attaching a new device") [joro: Added commit message and fixes tag] Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Gerd Rausch authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 05a82481 ] All entries in 'rds_ib_stat_names' are stringified versions of the corresponding "struct rds_ib_statistics" element without the "s_"-prefix. Fix entry 'ib_evt_handler_call' to do the same. Fixes: f4f943c9 ("RDS: IB: ack more receive completions to improve performance") Signed-off-by:
Gerd Rausch <gerd.rausch@oracle.com> Acked-by:
Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by:
-
Mao Wenan authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 49f6c90b ] sonic_send_packet will be processed in irq or non-irq context, so it would better use dev_kfree_skb_any instead of dev_kfree_skb. Fixes: d9fb9f38 ("*sonic/natsemi/ns83829: Move the National Semi-conductor drivers") Signed-off-by:
Mao Wenan <maowenan@huawei.com> Signed-off-by:
-
Dan Robertson authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit fdc7d8e8 ] Fix an error in the bitmaskfor the shtc1 and shtw1 bitmask used to retrieve the chip ID from the ID register. See section 5.7 of the shtw1 or shtc1 datasheet for details. Fixes: 1a539d37 ("hwmon: add support for Sensirion SHTC1 sensor") Signed-off-by:
Dan Robertson <dan@dlrobertson.com> Link: https://lore.kernel.org/r/20190905014554.21658-3-dan@dlrobertson.com [groeck: Reordered to be first in series and adjusted accordingly] Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Filipe Manana authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 7764d56b ] If we are able to load an existing inode cache off disk, we set the state of the cache to BTRFS_CACHE_FINISHED, but we don't wake up any one waiting for the cache to be available. This means that anyone waiting for the cache to be available, waiting on the condition that either its state is BTRFS_CACHE_FINISHED or its available free space is greather than zero, can hang forever. This could be observed running fstests with MOUNT_OPTIONS="-o inode_cache", in particular test case generic/161 triggered it very frequently for me, producing a trace like the following: [63795.739712] BTRFS info (device sdc): enabling inode map caching [63795.739714] BTRFS info (device sdc): disk space caching is enabled [63795.739716] BTRFS info (device sdc): has skinny extents [64036.653886] INFO: task btrfs-transacti:3917 blocked for more than 120 seconds. [64036.654079] Not tainted 5.2.0-rc4-btrfs-next-50 #1 [64036.654143] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [64036.654232] btrfs-transacti D 0 3917 2 0x80004000 [64036.654239] Call Trace: [64036.654258] ? __schedule+0x3ae/0x7b0 [64036.654271] schedule+0x3a/0xb0 [64036.654325] btrfs_commit_transaction+0x978/0xae0 [btrfs] [64036.654339] ? remove_wait_queue+0x60/0x60 [64036.654395] transaction_kthread+0x146/0x180 [btrfs] [64036.654450] ? btrfs_cleanup_transaction+0x620/0x620 [btrfs] [64036.654456] kthread+0x103/0x140 [64036.654464] ? kthread_create_worker_on_cpu+0x70/0x70 [64036.654476] ret_from_fork+0x3a/0x50 [64036.654504] INFO: task xfs_io:3919 blocked for more than 120 seconds. [64036.654568] Not tainted 5.2.0-rc4-btrfs-next-50 #1 [64036.654617] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [64036.654685] xfs_io D 0 3919 3633 0x00000000 [64036.654691] Call Trace: [64036.654703] ? __schedule+0x3ae/0x7b0 [64036.654716] schedule+0x3a/0xb0 [64036.654756] btrfs_find_free_ino+0xa9/0x120 [btrfs] [64036.654764] ? remove_wait_queue+0x60/0x60 [64036.654809] btrfs_create+0x72/0x1f0 [btrfs] [64036.654822] lookup_open+0x6bc/0x790 [64036.654849] path_openat+0x3bc/0xc00 [64036.654854] ? __lock_acquire+0x331/0x1cb0 [64036.654869] do_filp_open+0x99/0x110 [64036.654884] ? __alloc_fd+0xee/0x200 [64036.654895] ? do_raw_spin_unlock+0x49/0xc0 [64036.654909] ? do_sys_open+0x132/0x220 [64036.654913] do_sys_open+0x132/0x220 [64036.654926] do_syscall_64+0x60/0x1d0 [64036.654933] entry_SYSCALL_64_after_hwframe+0x49/0xbe Fix this by adding a wake_up() call right after setting the cache state to BTRFS_CACHE_FINISHED, at start_caching(), when we are able to load the cache from disk. Fixes: 82d5902d ("Btrfs: Support reading/writing on disk free ino cache") Reviewed-by:
Nikolay Borisov <nborisov@suse.com> Signed-off-by:
Filipe Manana <fdmanana@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Mao Wenan authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 6e1cdedc ] NETDEV_TX_BUSY really should only be used by drivers that call netif_tx_stop_queue() at the wrong moment. If dma_map_single() is failed to map tx DMA buffer, it might trigger an infinite loop. This patch use NETDEV_TX_OK instead of NETDEV_TX_BUSY, and change printk to pr_err_ratelimited. Fixes: d9fb9f38 ("*sonic/natsemi/ns83829: Move the National Semi-conductor drivers") Signed-off-by:
-
Lorenzo Bianconi authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit e1aa1a1d ] Fix following lockdep warning disabling bh in ath_dynack_node_init/ath_dynack_node_deinit [ 75.955878] -------------------------------- [ 75.955880] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. [ 75.955884] swapper/0/0 [HC0[0]:SC1[3]:HE1:SE0] takes: [ 75.955888] 00000000792a7ee0 (&(&da->qlock)->rlock){+.?.}, at: ath_dynack_sample_ack_ts+0x4d/0xa0 [ath9k_hw] [ 75.955905] {SOFTIRQ-ON-W} state was registered at: [ 75.955912] lock_acquire+0x9a/0x160 [ 75.955917] _raw_spin_lock+0x2c/0x70 [ 75.955927] ath_dynack_node_init+0x2a/0x60 [ath9k_hw] [ 75.955934] ath9k_sta_state+0xec/0x160 [ath9k] [ 75.955976] drv_sta_state+0xb2/0x740 [mac80211] [ 75.956008] sta_info_insert_finish+0x21a/0x420 [mac80211] [ 75.956039] sta_info_insert_rcu+0x12b/0x2c0 [mac80211] [ 75.956069] sta_info_insert+0x7/0x70 [mac80211] [ 75.956093] ieee80211_prep_connection+0x42e/0x730 [mac80211] [ 75.956120] ieee80211_mgd_auth.cold+0xb9/0x15c [mac80211] [ 75.956152] cfg80211_mlme_auth+0x143/0x350 [cfg80211] [ 75.956169] nl80211_authenticate+0x25e/0x2b0 [cfg80211] [ 75.956172] genl_family_rcv_msg+0x198/0x400 [ 75.956174] genl_rcv_msg+0x42/0x90 [ 75.956176] netlink_rcv_skb+0x35/0xf0 [ 75.956178] genl_rcv+0x1f/0x30 [ 75.956180] netlink_unicast+0x154/0x200 [ 75.956182] netlink_sendmsg+0x1bf/0x3d0 [ 75.956186] ___sys_sendmsg+0x2c2/0x2f0 [ 75.956187] __sys_sendmsg+0x44/0x80 [ 75.956190] do_syscall_64+0x55/0x1a0 [ 75.956192] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 75.956194] irq event stamp: 2357092 [ 75.956196] hardirqs last enabled at (2357092): [<ffffffff818c62de>] _raw_spin_unlock_irqrestore+0x3e/0x50 [ 75.956199] hardirqs last disabled at (2357091): [<ffffffff818c60b1>] _raw_spin_lock_irqsave+0x11/0x80 [ 75.956202] softirqs last enabled at (2357072): [<ffffffff8106dc09>] irq_enter+0x59/0x60 [ 75.956204] softirqs last disabled at (2357073): [<ffffffff8106dcbe>] irq_exit+0xae/0xc0 [ 75.956206] other info that might help us debug this: [ 75.956207] Possible unsafe locking scenario: [ 75.956208] CPU0 [ 75.956209] ---- [ 75.956210] lock(&(&da->qlock)->rlock); [ 75.956213] <Interrupt> [ 75.956214] lock(&(&da->qlock)->rlock); [ 75.956216] *** DEADLOCK *** [ 75.956217] 1 lock held by swapper/0/0: [ 75.956219] #0: 000000003bb5675c (&(&sc->sc_pcu_lock)->rlock){+.-.}, at: ath9k_tasklet+0x55/0x240 [ath9k] [ 75.956225] stack backtrace: [ 75.956228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.0-rc1-wdn+ #13 [ 75.956229] Hardware name: Dell Inc. Studio XPS 1340/0K183D, BIOS A11 09/08/2009 [ 75.956231] Call Trace: [ 75.956233] <IRQ> [ 75.956236] dump_stack+0x67/0x90 [ 75.956239] mark_lock+0x4c1/0x640 [ 75.956242] ? check_usage_backwards+0x130/0x130 [ 75.956245] ? sched_clock_local+0x12/0x80 [ 75.956247] __lock_acquire+0x484/0x7a0 [ 75.956250] ? __lock_acquire+0x3b9/0x7a0 [ 75.956252] lock_acquire+0x9a/0x160 [ 75.956259] ? ath_dynack_sample_ack_ts+0x4d/0xa0 [ath9k_hw] [ 75.956262] _raw_spin_lock_bh+0x34/0x80 [ 75.956268] ? ath_dynack_sample_ack_ts+0x4d/0xa0 [ath9k_hw] [ 75.956275] ath_dynack_sample_ack_ts+0x4d/0xa0 [ath9k_hw] [ 75.956280] ath_rx_tasklet+0xd09/0xe90 [ath9k] [ 75.956286] ath9k_tasklet+0x102/0x240 [ath9k] [ 75.956288] tasklet_action_common.isra.0+0x6d/0x170 [ 75.956291] __do_softirq+0xcc/0x425 [ 75.956294] irq_exit+0xae/0xc0 [ 75.956296] do_IRQ+0x8a/0x110 [ 75.956298] common_interrupt+0xf/0xf [ 75.956300] </IRQ> [ 75.956303] RIP: 0010:cpuidle_enter_state+0xb2/0x400 [ 75.956308] RSP: 0018:ffffffff82203e70 EFLAGS: 00000202 ORIG_RAX: ffffffffffffffd7 [ 75.956310] RAX: ffffffff82219800 RBX: ffffffff822bd0a0 RCX: 0000000000000000 [ 75.956312] RDX: 0000000000000046 RSI: 0000000000000006 RDI: ffffffff82219800 [ 75.956314] RBP: ffff888155a01c00 R08: 00000011af51aabe R09: 0000000000000000 [ 75.956315] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002 [ 75.956317] R13: 00000011af51aabe R14: 0000000000000003 R15: ffffffff82219800 [ 75.956321] cpuidle_enter+0x24/0x40 [ 75.956323] do_idle+0x1ac/0x220 [ 75.956326] cpu_startup_entry+0x14/0x20 [ 75.956329] start_kernel+0x482/0x489 [ 75.956332] secondary_startup_64+0xa4/0xb0 Fixes: c774d57f ("ath9k: add dynamic ACK timeout estimation") Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Tested-by:
Koen Vandeputte <koen.vandeputte@ncentric.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit b1e18768 ] Currently the pointer val is being incorrectly incremented instead of the value pointed to by val. Fix this by adding in the missing * indirection operator. Addresses-Coverity: ("Unused value") Fixes: c03f2c53 ("staging:iio:dac: Add AD5380 driver") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 420c20be ] An earlier commit re-worked the setting of the bitmask and is now assigning v with some bit flags rather than bitwise or-ing them into v, consequently the earlier bit-settings of v are being lost. Fix this by replacing an assignment with the bitwise or instead. Addresses-Coverity: ("Unused value") Fixes: 2be25cac ("bcma: add constants for PCI and use them") Signed-off-by:
-
Masami Hiramatsu authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 7720804a ] Since x86 instruction decoder is not only for kprobes, it should be tested when the insn.c is compiled. (e.g. perf is enabled but kprobes is disabled) Signed-off-by:
Masami Hiramatsu <mhiramat@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: cbe5c34c ("x86: Compile insn.c and inat.c only for KPROBES") Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Stephen Boyd authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 82880222 ] We may want to use the device pointer in device_init_wakeup() with functions that expect the device to already be added with device_add(). For example, if we were to link the device initializing wakeup to something in sysfs such as a class for wakeups we'll run into an error. It looks like this code was written with the assumption that the device would be added before initializing wakeup due to the order of operations in power_supply_unregister(). Let's change the order of operations so we don't run into problems here. Fixes: 948dcf96 ("power_supply: Prevent suspend until power supply events are processed") Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Tri Vo <trong@android.com> Cc: Kalesh Singh <kaleshsingh@google.com> Cc: Ravi Chandra Sadineni <ravisadineni@chromium.org> Cc: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
-
Linus Torvalds authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit ab9bb631 ] Commit dfe2a77f ("kfifo: fix kfifo_alloc() and kfifo_init()") made the kfifo code round the number of elements up. That was good for __kfifo_alloc(), but it's actually wrong for __kfifo_init(). The difference? __kfifo_alloc() will allocate the rounded-up number of elements, but __kfifo_init() uses an allocation done by the caller. We can't just say "use more elements than the caller allocated", and have to round down. The good news? All the normal cases will be using power-of-two arrays anyway, and most users of kfifo's don't use kfifo_init() at all, but one of the helper macros to declare a KFIFO that enforce the proper power-of-two behavior. But it looks like at least ibmvscsis might be affected. The bad news? Will Deacon refers to an old thread and points points out that the memory ordering in kfifo's is questionable. See https://lore.kernel.org/lkml/20181211034032.32338-1-yuleixzhang@tencent.com/ for more. Fixes: dfe2a77f ("kfifo: fix kfifo_alloc() and kfifo_init()") Reported-by:
laokz <laokz@foxmail.com> Cc: Stefani Seibold <stefani@seibold.net> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Greg KH <greg@kroah.com> Cc: Kees Cook <keescook@chromium.org> Cc: Will Deacon <will@kernel.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Andy Shevchenko authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 60fc35f3 ] The commit ed08d40c ("ahci: Changing two module params with static and __read_mostly") moved ahci_em_messages to be static while missing the fact of exporting it. WARNING: "ahci_em_messages" [vmlinux] is a static EXPORT_SYMBOL_GPL Drop export for the local variable ahci_em_messages. Fixes: ed08d40c ("ahci: Changing two module params with static and __read_mostly") Cc: Chuansheng Liu <chuansheng.liu@intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Nick Desaulniers authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 12051b31 ] The code in question is modifying a variable declared const through pointer manipulation. Such code is explicitly undefined behavior, and is the lone issue preventing malta_defconfig from booting when built with Clang: If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type, the behavior is undefined. LLVM is removing such assignments. A simple fix is to not declare variables const that you plan on modifying. Limiting the scope would be a better method of preventing unwanted writes to such a variable. Further, the code in question mentions "compiler bugs" without any links to bug reports, so it is difficult to know if the issue is resolved in GCC. The patch was authored in 2006, which would have been GCC 4.0.3 or 4.1.1. The minimal supported version of GCC in the Linux kernel is currently 4.6. For what its worth, there was UB before the commit in question, it just added a barrier and got lucky IRT codegen. I don't think there's any actual compiler bugs related, just runtime bugs due to UB. Link: https://github.com/ClangBuiltLinux/linux/issues/610 Fixes: 966f4406 ("[MIPS] Work around bad code generation for <asm/io.h>.") Reported-by:
Nathan Chancellor <natechancellor@gmail.com> Debugged-by:
Eli Friedman <efriedma@quicinc.com> Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Reviewed-by:
Paul Burton <paul.burton@mips.com> Cc: ralf@linux-mips.org Cc: jhogan@kernel.org Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: Hassan Naveed <hnaveed@wavecomp.com> Cc: Stephen Kitt <steve@sk2.org> Cc: Serge Semin <fancer.lancer@gmail.com> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Michal Hocko <mhocko@suse.com> Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: clang-built-linux@googlegroups.com Signed-off-by:
-
Felix Fietkau authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 56dd918f ] The group number needs to be multiplied by the number of rates per group to get the full rate index Fixes: 5935839a ("mac80211: improve minstrel_ht rate sorting by throughput & probability") Signed-off-by:
Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20190820095449.45255-1-nbd@nbd.nameSigned-off-by:
-
Andy Shevchenko authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit e7b8514e ] There is a possibility to have registered ACPI DMA controller while it has been gone already. To avoid the potential crash, move to non-managed acpi_dma_controller_register(). Fixes: 42c91ee7 ("dw_dmac: add ACPI support") Signed-off-by:
-
Eric W. Biederman authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 33da8e7c ] My recent to change to only use force_sig for a synchronous events wound up breaking signal reception cifs and drbd. I had overlooked the fact that by default kthreads start out with all signals set to SIG_IGN. So a change I thought was safe turned out to have made it impossible for those kernel thread to catch their signals. Reverting the work on force_sig is a bad idea because what the code was doing was very much a misuse of force_sig. As the way force_sig ultimately allowed the signal to happen was to change the signal handler to SIG_DFL. Which after the first signal will allow userspace to send signals to these kernel threads. At least for wake_ack_receiver in drbd that does not appear actively wrong. So correct this problem by adding allow_kernel_signal that will allow signals whose siginfo reports they were sent by the kernel through, but will not allow userspace generated signals, and update cifs and drbd to call allow_kernel_signal in an appropriate place so that their thread can receive this signal. Fixing things this way ensures that userspace won't be able to send signals and cause problems, that it is clear which signals the threads are expecting to receive, and it guarantees that nothing else in the system will be affected. This change was partly inspired by similar cifs and drbd patches that added allow_signal. Reported-by:
ronnie sahlberg <ronniesahlberg@gmail.com> Reported-by:
Christoph Böhmwalder <christoph.boehmwalder@linbit.com> Tested-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
YueHaibing authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 554b75bd ] sound/soc/codecs/wm8737.c:112:29: warning: high_3d defined but not used [-Wunused-const-variable=] 'high_3d' should be used for 3D High Cut-off. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: 2a9ae13a ("ASoC: Add initial WM8737 driver") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20190815091920.64480-1-yuehaibing@huawei.comSigned-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
YueHaibing authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 9b4275c4 ] sound/soc/codecs/cs4349.c:358:32: warning: cs4349_runtime_pm defined but not used [-Wunused-const-variable=] cs4349_runtime_pm ops already defined, it seems we should enable it. Reported-by:
-
YueHaibing authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 630742c2 ] It seems 'es8328_rline_enum' should be used in es8328_right_line_controls Fixes: 567e4f98 ("ASoC: add es8328 codec driver") Signed-off-by:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 7a14826e ] Currently when the call to ext4_htree_store_dirent fails the error return variable 'ret' is is not being set to the error code and variable count is instead, hence the error code is not being returned. Fix this by assigning ret to the error return code. Addresses-Coverity: ("Unused value") Fixes: 8af0f082 ("ext4: fix readdir error in the case of inline_data+dir_index") Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Iuliana Prodan authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit c59a1d41 ] Check the return value of the hardware registration for caam_rng and free resources in case of failure. Fixes: e24f7c9e ("crypto: caam - hwrng support") Signed-off-by:
Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by:
Horia Geanta <horia.geanta@nxp.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Steve French authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 247bc947 ] Fixes: 72abe3bc ("signal/cifs: Fix cifs_put_tcp_session to call send_sig instead of force_sig") The global change from force_sig caused module unloading of cifs.ko to fail (since the cifsd process could not be killed, "rmmod cifs" now would always fail) Signed-off-by:
Steve French <stfrench@microsoft.com> Reviewed-by:
Ronnie Sahlberg <lsahlber@redhat.com> CC: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
Johannes Berg authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit f474808a ] A lot of places in the driver use onyx_read_register() without checking the return value, and it's been working OK for ~10 years or so, so probably never fails ... Rather than trying to check the return value everywhere, which would be relatively intrusive, at least make sure we don't use an uninitialized value. Fixes: f3d9478b ("[ALSA] snd-aoa: add snd-aoa") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Thomas Gleixner authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 2591bc4e ] apic->send_IPI_allbutself() takes a vector number as argument. APIC_DM_NMI is clearly not a vector number. It's defined to 0x400 which is outside the vector space. Use NMI_VECTOR instead as that's what it is intended to be. Fixes: 82da3ff8 ("x86: kgdb support") Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20190722105218.855189979@linutronix.deSigned-off-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit bc83f79b ] Generally, declaring a platform device as a static variable is a bad idea and can cause all kinds of problems, in particular with the DMA configuration and lifetime rules. A specific problem we hit here is from a bug in clang that warns about certain (otherwise valid) macros when used in static variables: drivers/misc/mic/card/mic_x100.c:285:27: warning: shift count >= width of type [-Wshift-count-overflow] static u64 mic_dma_mask = DMA_BIT_MASK(64); ^~~~~~~~~~~~~~~~ include/linux/dma-mapping.h:141:54: note: expanded from macro 'DMA_BIT_MASK' #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) ^ ~~~ A slightly better way here is to create the platform device dynamically and set the dma mask in the probe function. This avoids the warning and some other problems, but is still not ideal because the device creation should really be separated from the driver, and the fact that the device has no parent means we have to force the dma mask rather than having it set up from the bus that the device is actually on. Fixes: dd8d8d44 ("misc: mic: MIC card driver specific changes to enable SCIF") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20190712092426.872625-1-arnd@arndb.deSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Ruslan Bilovol authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 6269e4c7 ] Don't do extra cpu_to_le32 conversion for put_unaligned_le32 because it is already implemented in this function. Fixes sparse error: xhci-hub.c:1152:44: warning: incorrect type in argument 1 (different base types) xhci-hub.c:1152:44: expected unsigned int [usertype] val xhci-hub.c:1152:44: got restricted __le32 [usertype] Fixes: 395f5409 "xhci: support new USB 3.1 hub request to get extended port status" Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Ruslan Bilovol <ruslan.bilovol@gmail.com> Link: https://lore.kernel.org/r/1562501839-26522-1-git-send-email-ruslan.bilovol@gmail.comSigned-off-by:
-
