- 04 Jun, 2019 8 commits
-
-
David Ahern authored
[ Upstream commit 31680ac2 ] IPv6 redirect is broken for VRF. __ip6_route_redirect walks the FIB entries looking for an exact match on ifindex. With VRF the flowi6_oif is updated by l3mdev_update_flow to the l3mdev index and the FLOWI_FLAG_SKIP_NH_OIF set in the flags to tell the lookup to skip the device match. For redirects the device match is requires so use that flag to know when the oif needs to be reset to the skb device index. Fixes: ca254490 ("net: Add VRF support to IPv6 stack") Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mike Manning authored
[ Upstream commit 72f7cfab ] IPv6 does not consider if the socket is bound to a device when binding to an address. The result is that a socket can be bound to eth0 and then bound to the address of eth1. If the device is a VRF, the result is that a socket can only be bound to an address in the default VRF. Resolve by considering the device if sk_bound_dev_if is set. Signed-off-by:
Mike Manning <mmanning@vyatta.att-mail.com> Reviewed-by:
-
Eric Dumazet authored
[ Upstream commit 903869bd ] ip_sf_list_clear_all() needs to be defined even if !CONFIG_IP_MULTICAST Fixes: 3580d04a ("ipv4/igmp: fix another memory leak in igmpv3_del_delrec()") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 3580d04a ] syzbot reported memory leaks [1] that I have back tracked to a missing cleanup from igmpv3_del_delrec() when (im->sfmode != MCAST_INCLUDE) Add ip_sf_list_clear_all() and kfree_pmc() helpers to explicitely handle the cleanups before freeing. [1] BUG: memory leak unreferenced object 0xffff888123e32b00 (size 64): comm "softirq", pid 0, jiffies 4294942968 (age 8.010s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 e0 00 00 01 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000006105011b>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline] [<000000006105011b>] slab_post_alloc_hook mm/slab.h:439 [inline] [<000000006105011b>] slab_alloc mm/slab.c:3326 [inline] [<000000006105011b>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 [<000000004bba8073>] kmalloc include/linux/slab.h:547 [inline] [<000000004bba8073>] kzalloc include/linux/slab.h:742 [inline] [<000000004bba8073>] ip_mc_add1_src net/ipv4/igmp.c:1961 [inline] [<000000004bba8073>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2085 [<00000000a46a65a0>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2475 [<000000005956ca89>] do_ip_setsockopt.isra.0+0x1795/0x1930 net/ipv4/ip_sockglue.c:957 [<00000000848e2d2f>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1246 [<00000000b9db185c>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616 [<000000003028e438>] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3130 [<0000000015b65589>] __sys_setsockopt+0x98/0x120 net/socket.c:2078 [<00000000ac198ef0>] __do_sys_setsockopt net/socket.c:2089 [inline] [<00000000ac198ef0>] __se_sys_setsockopt net/socket.c:2086 [inline] [<00000000ac198ef0>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086 [<000000000a770437>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301 [<00000000d3adb93b>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 9c8bb163 ("igmp, mld: Fix memory leak in igmpv3/mld_del_delrec()") Signed-off-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit df453700 ] According to Amit Klein and Benny Pinkas, IP ID generation is too weak and might be used by attackers. Even with recent net_hash_mix() fix (netns: provide pure entropy for net_hash_mix()) having 64bit key and Jenkins hash is risky. It is time to switch to siphash and its 128bit keys. Signed-off-by:
Amit Klein <aksecurity@gmail.com> Reported-by:
Benny Pinkas <benny@pinkas.net> Signed-off-by:
-
Maxime Chevallier authored
[ Upstream commit b73484b2 ] When parsing an ethtool flow spec to build a flow_rule, the code checks if both the vlan etype and the vlan tci are specified by the user to add a FLOW_DISSECTOR_KEY_VLAN match. However, when the user only specified a vlan etype or a vlan tci, this check silently ignores these parameters. For example, the following rule : ethtool -N eth0 flow-type udp4 vlan 0x0010 action -1 loc 0 will result in no error being issued, but the equivalent rule will be created and passed to the NIC driver : ethtool -N eth0 flow-type udp4 action -1 loc 0 In the end, neither the NIC driver using the rule nor the end user have a way to know that these keys were dropped along the way, or that incorrect parameters were entered. This kind of check should be left to either the driver, or the ethtool flow spec layer. This commit makes so that ethtool parameters are forwarded as-is to the NIC driver. Since none of the users of ethtool_rx_flow_rule_create are using the VLAN dissector, I don't think this qualifies as a regression. Fixes: eca4205f ("ethtool: add ethtool_rx_flow_spec to flow_rule structure translator") Signed-off-by:
Maxime Chevallier <maxime.chevallier@bootlin.com> Acked-by:
Pablo Neira Ayuso <pablo@gnumonks.org> Signed-off-by:
-
Raju Rangoju authored
[ Upstream commit b5730061 ] VLAN flows never get offloaded unless ivlan_vld is set in filter spec. It's not compulsory for vlan_ethtype to be set. So, always enable ivlan_vld bit for offloading VLAN flows regardless of vlan_ethtype is set or not. Fixes: ad9af3e0 (cxgb4: add tc flower match support for vlan) Signed-off-by:
Raju Rangoju <rajur@chelsio.com> Signed-off-by:
-
Jarod Wilson authored
[ Upstream commit 33403121 ] Once in a while, with just the right timing, 802.3ad slaves will fail to properly initialize, winding up in a weird state, with a partner system mac address of 00:00:00:00:00:00. This started happening after a fix to properly track link_failure_count tracking, where an 802.3ad slave that reported itself as link up in the miimon code, but wasn't able to get a valid speed/duplex, started getting set to BOND_LINK_FAIL instead of BOND_LINK_DOWN. That was the proper thing to do for the general "my link went down" case, but has created a link initialization race that can put the interface in this odd state. The simple fix is to instead set the slave link to BOND_LINK_DOWN again, if the link has never been up (last_link_up == 0), so the link state doesn't bounce from BOND_LINK_DOWN to BOND_LINK_FAIL -- it hasn't failed in this case, it simply hasn't been up yet, and this prevents the unnecessary state change from DOWN to FAIL and getting stuck in an init failure w/o a partner mac. Fixes: ea53abfa ("bonding/802.3ad: fix link_failure_count tracking") CC: Jay Vosburgh <j.vosburgh@gmail.com> CC: Veaceslav Falico <vfalico@gmail.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: "David S. Miller" <davem@davemloft.net> CC: netdev@vger.kernel.org Tested-by:
Heesoon Kim <Heesoon.Kim@stratus.com> Signed-off-by:
Jarod Wilson <jarod@redhat.com> Acked-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by:
-
- 31 May, 2019 32 commits
-
-
Greg Kroah-Hartman authored
-
Benjamin Coddington authored
[ Upstream commit c260121a ] Now that nfs_match_client drops the nfs_client_lock, we should be careful to always return it in the same condition: locked. Fixes: 950a578c ("NFS: make nfs_match_client killable") Reported-by: syzbot+228a82b263b5da91883d@syzkaller.appspotmail.com Signed-off-by:
Benjamin Coddington <bcodding@redhat.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Maxime Ripard authored
[ Upstream commit efa31801 ] The Allwinner BSP makes sure that we don't end up with a null start delay or with a delay larger than vtotal. The former condition is likely to happen now with the reworked start delay, so make sure we enforce the same boundaries. Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Reviewed-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/c9889cf5f7a3d101ef380905900b45a182596f56.1549896081.git-series.maxime.ripard@bootlin.comSigned-off-by:
-
Brett Creeley authored
[ Upstream commit 5abac9d7 ] Currently we check if the __ICE_PREPARED_FOR_RESET bit is set prior to calling ice_prepare_for_reset in ice_reset_subtask(), but we aren't checking that bit in ice_do_reset() before calling ice_prepare_for_reset(). This is not consistent and can cause issues if ice_prepare_for_reset() is called prior to ice_do_reset(). Fix this by checking if the __ICE_PREPARED_FOR_RESET bit is set internal to ice_prepare_for_reset(). Signed-off-by:
Brett Creeley <brett.creeley@intel.com> Signed-off-by:
Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
YueHaibing authored
[ Upstream commit fa3c098c ] As Hans de Goede pointed, using this driver without ACPI makes little sense, so add ACPI dependency to Kconfig entry to fix a build error while CONFIG_ACPI is not set. drivers/extcon/extcon-axp288.c: In function 'axp288_extcon_probe': drivers/extcon/extcon-axp288.c:363:20: error: dereferencing pointer to incomplete type put_device(&adev->dev); Fixes: 0cf064db ("extcon: axp288: Convert to use acpi_dev_get_first_match_dev()") Reported-by:
Hulk Robot <hulkci@huawei.com> Suggested-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
Mukesh Ojha <mojha@codeaurora.org> Signed-off-by:
Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by:
-
Farhan Ali authored
[ Upstream commit d1ffa760 ] The quiesce function calls cio_cancel_halt_clear() and if we get an -EBUSY we go into a loop where we: - wait for any interrupts - flush all I/O in the workqueue - retry cio_cancel_halt_clear During the period where we are waiting for interrupts or flushing all I/O, the channel subsystem could have completed a halt/clear action and turned off the corresponding activity control bits in the subchannel status word. This means the next time we call cio_cancel_halt_clear(), we will again start by calling cancel subchannel and so we can be stuck between calling cancel and halt forever. Rather than calling cio_cancel_halt_clear() immediately after waiting, let's try to disable the subchannel. If we succeed in disabling the subchannel then we know nothing else can happen with the device. Suggested-by:
Eric Farman <farman@linux.ibm.com> Signed-off-by:
Farhan Ali <alifm@linux.ibm.com> Message-Id: <4d5a4b98ab1b41ac6131b5c36de18b76c5d66898.1555449329.git.alifm@linux.ibm.com> Reviewed-by:
Halil Pasic <pasic@linux.ibm.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
-
Maxime Ripard authored
[ Upstream commit 85fb3526 ] The current code allows the TCON clock divider to have a range between 4 and 127 when feeding the DSI controller. The only display supported so far had a display clock rate that ended up using a divider of 4, but testing with other displays show that only 4 seems to be functional. This also aligns with what Allwinner is doing in their BSP, so let's just hardcode that we want a divider of 4 when using the DSI output. Reviewed-by:
-
Maxime Ripard authored
[ Upstream commit da676c6a ] The current calculation for the video start delay in the current DSI driver is that it is the total vertical size, minus the front porch and sync length, plus 1. This equals to the active vertical size plus the back porch plus 1. That 1 is coming in the Allwinner BSP from an variable that is set to 1. However, if we look at the Allwinner BSP more closely, and especially in the "legacy" code for the display (in drivers/video/sunxi/legacy/), we can see that this variable is actually computed from the porches and the sync minus 10, clamped between 8 and 100. This fixes the start delay symptom we've seen on some panels (vblank timeouts with vertical white stripes at the bottom of the panel). Reviewed-by:
-
Chris Wilson authored
[ Upstream commit 60b80199 ] After an event is sent, we try to copy it into the user buffer of the first waiter in drm_read() and if the user buffer doesn't have enough room we put it back onto the list. However, we didn't wake up any subsequent waiter, so that event may sit on the list until either a new vblank event is sent or a new waiter appears. Rare, but in the worst case may lead to a stuck process. Testcase: igt/drm_read/short-buffer-wakeup Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170804082328.17173-1-chris@chris-wilson.co.ukSigned-off-by:
-
Noralf Trønnes authored
[ Upstream commit 56be6503 ] This makes it safe to access drm_device->dev after the parent device has been removed/unplugged. Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190225144232.20761-2-noralf@tronnes.orgSigned-off-by:
-
Nicholas Kazlauskas authored
[ Upstream commit 4bc46da4 ] [Why] Seamless boot tries to reuse planes that were enabled for the first commit applied. In the case where Raven is booting with two monitors connected and the first commit contains two streams the screen corruption would occur because the second stream was trying to re-use a tg and plane that weren't previously enabled. The state on the first commit looks something like the following: TG0: enabled=1 TG1: enabled=0 TG2: enabled=0 TG3: enabled=0 New state: pipe=0, stream=0, plane=0, new_tg=0 New state: pipe=1, stream=1, plane=1, new_tg=1 New state: pipe=2, stream=NULL, plane=NULL, new_tg=NULL New state: pipe=3, stream=NULL, plane=NULL, new_tg=NULL Only one plane/tg is setup before we enter accelerated mode so we really want to disabling everything but that first plane. [How] Check if the stream is not NULL and if the tg is enabled before deciding whether to skip the plane disable. Also ensure we're also disabling on the current state's pipe_ctx so we don't overwrite the fields in the new pending state. Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
Harry Wentland <Harry.Wentland@amd.com> Acked-by:
Leo Li <sunpeng.li@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Anthony Koo authored
[ Upstream commit dcf1a988 ] [Why] AUX arbitration occurs between SW and FW components. When AUX acquire fails, it causes engine->ddc to be NULL, which leads to an exception when we try to release the AUX engine. [How] When AUX engine acquire fails, it should return from the function without trying to continue the operation. The upper level will determine if it wants to retry. i.e. dce_aux_transfer_with_retries will be used and retry. Signed-off-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
-
Eric Anholt authored
[ Upstream commit fc227715 ] Noted in review by Dave Emett for V3D 4.2 support. Signed-off-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190308174336.7866-1-eric@anholt.netReviewed-by:
Dave Emett <david.emett@broadcom.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 7d7b25d0 ] The SND_SOC_DAVINCI_MCASP driver can use either edma or sdma as a back-end, and it takes the presence of the respective dma engine drivers in the configuration as an indication to which ones should be built. However, this is flawed in multiple ways: - With CONFIG_TI_EDMA=m and CONFIG_SND_SOC_DAVINCI_MCASP=y, is enabled as =m, and we get a link error: sound/soc/ti/davinci-mcasp.o: In function `davinci_mcasp_probe': davinci-mcasp.c:(.text+0x930): undefined reference to `edma_pcm_platform_register' - When CONFIG_SND_SOC_DAVINCI_MCASP=m has already been selected by another driver, the same link error appears even if CONFIG_TI_EDMA is disabled There are possibly other issues here, but it seems that the only reasonable solution is to always build both SND_SOC_TI_EDMA_PCM and SND_SOC_TI_SDMA_PCM as a dependency here. Both are fairly small and do not have any other compile-time dependencies, so the cost is very small, and makes the configuration stage much more consistent. Fixes: f2055e14 ("ASoC: ti: Merge davinci and omap directories") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 8ca51047 ] Building with clang shows a variable that is only used by the suspend/resume functions but defined outside of their #ifdef block: sound/soc/ti/davinci-mcasp.c:48:12: error: variable 'context_regs' is not needed and will not be emitted We commonly fix these by marking the PM functions as __maybe_unused, but here that would grow the davinci_mcasp structure, so instead add another #ifdef here. Fixes: 1cc0c054 ("ASoC: davinci-mcasp: Convert the context save/restore to use array") Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Chris Lesiak authored
[ Upstream commit 5442dcaa ] This fixes a bug for messages containing both zero length and unidirectional xfers. The function spi_map_msg will allocate dummy tx and/or rx buffers for use with unidirectional transfers when the hardware can only do a bidirectional transfer. That dummy buffer will be used in place of a NULL buffer even when the xfer length is 0. Then in the function __spi_map_msg, if he hardware can dma, the zero length xfer will have spi_map_buf called on the dummy buffer. Eventually, __sg_alloc_table is called and returns -EINVAL because nents == 0. This fix prevents the error by not using the dummy buffer when the xfer length is zero. Signed-off-by:
Chris Lesiak <chris.lesiak@licor.com> Signed-off-by:
-
Steve Twiss authored
[ Upstream commit 5e6afb38 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: f6130be6 ("regulator: DA9055 regulator driver") Suggested-by:
Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by:
Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by:
-
Steve Twiss authored
[ Upstream commit 978995de ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 4068e518 ("regulator: da9062: DA9062 regulator driver") Suggested-by:
-
Steve Twiss authored
[ Upstream commit 275513b7 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: c90456e3 ("regulator: pv88090: new regulator driver") Suggested-by:
-
Steve Twiss authored
[ Upstream commit 119c4f50 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: e4ee831f ("regulator: Add WM831x DC-DC buck convertor support") Suggested-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by:
-
Steve Twiss authored
[ Upstream commit 1867af94 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 99cf3af5 ("regulator: pv88080: new regulator driver") Suggested-by:
-
Steve Twiss authored
[ Upstream commit 29d40b4a ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 69ca3e58 ("regulator: da9063: Add Dialog DA9063 voltage regulators support.") Suggested-by:
-
Steve Twiss authored
[ Upstream commit 65378de3 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 1028a37d ("regulator: da9211: new regulator driver") Suggested-by:
-
Steve Twiss authored
[ Upstream commit 89b2758c ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: b59320cc ("regulator: lp8755: new driver for LP8755") Suggested-by:
-
Trent Piepho authored
[ Upstream commit c842749e ] Commit 71abd290 ("spi: imx: Add support for SPI Slave mode") added an RX FIFO flush before start of a transfer. In slave mode, the master may have sent more data than expected and this data will still be in the RX FIFO at the start of the next transfer, and so needs to be flushed. However, the code to do the flush was accidentally saving this data into the previous transfer's RX buffer, clobbering the contents of whatever followed that buffer. Change it to empty the FIFO and throw away the data. Every one of the RX functions for the different eCSPI versions and modes reads the RX FIFO data using the same readl() call, so just use that, rather than using the spi_imx->rx function pointer and making sure all the different rx functions have a working "throw away" mode. There is another issue, which affects master mode when switching from DMA to PIO. There can be extra data in the RX FIFO which triggers this flush code, causing memory corruption in the same manner. I don't know why this data is unexpectedly in the FIFO. It's likely there is a different bug or erratum responsible for that. But regardless of that, I think this is proper fix the for bug at hand here. Fixes: 71abd290 ("spi: imx: Add support for SPI Slave mode") Cc: Jiada Wang <jiada_wang@mentor.com> Cc: Fabio Estevam <festevam@gmail.com> Cc: Stefan Agner <stefan@agner.ch> Cc: Shawn Guo <shawnguo@kernel.org> Signed-off-by:
Trent Piepho <tpiepho@impinj.com> Signed-off-by:
-
Steve Twiss authored
[ Upstream commit f5821363 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: f307a7e9 ("regulator: pv88060: new regulator driver") Suggested-by:
-
Steve Twiss authored
[ Upstream commit f132da25 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 3eb2c7ec ("regulator: Add LTC3589 support") Suggested-by:
-
Steve Twiss authored
[ Upstream commit 769fc8d4 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 37b918a0 ("regulator: Add LTC3676 support") Suggested-by:
-
Steve Twiss authored
[ Upstream commit f7a62172 ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: d4d6b722 ("regulator: Add WM831x ISINK support") Suggested-by:
-
Steve Twiss authored
[ Upstream commit 8be64b6d ] The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: d1c6b4fe ("regulator: Add WM831x LDO support") Suggested-by:
-
Geert Uytterhoeven authored
[ Upstream commit 26843bb1 ] While the sequencer is reset after each SPI message since commit 880c6d11 ("spi: rspi: Add support for Quad and Dual SPI Transfers on QSPI"), it was never reset for the first message, thus relying on reset state or bootloader settings. Fix this by initializing it explicitly during configuration. Fixes: 0b2182dd ("spi: add support for Renesas RSPI") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Laurent Pinchart authored
[ Upstream commit 27a7e3e1 ] For HDMI pipelines, when the output gets disconnected the device handling CEC needs to be notified. Instead of guessing which device that would be (and sometimes getting it wrong), notify all devices in the pipeline. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
