- 27 Jan, 2020 40 commits
-
-
Yangtao Li authored
[ Upstream commit 56717702 ] The of_find_compatible_node() returns a node pointer with refcount incremented, but there is the lack of use of the of_node_put() when done. Add the missing of_node_put() to release the refcount. Signed-off-by:
Yangtao Li <tiny.windzz@gmail.com> Fixes: 1f2c5fd5 ("ARM: imx: add VF610 clock support") Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Yangtao Li authored
[ Upstream commit 5f8c183a ] The of_find_compatible_node() returns a node pointer with refcount incremented, but there is the lack of use of the of_node_put() when done. Add the missing of_node_put() to release the refcount. Signed-off-by:
-
Yangtao Li authored
[ Upstream commit 1731e14f ] The of_find_compatible_node() returns a node pointer with refcount incremented, but there is the lack of use of the of_node_put() when done. Add the missing of_node_put() to release the refcount. Signed-off-by:
-
Yangtao Li authored
[ Upstream commit c9ec1d8f ] The of_find_compatible_node() returns a node pointer with refcount incremented, but there is the lack of use of the of_node_put() when done. Add the missing of_node_put() to release the refcount. Signed-off-by:
-
Yangtao Li authored
[ Upstream commit cee82eb9 ] The of_find_compatible_node() returns a node pointer with refcount incremented, but there is the lack of use of the of_node_put() when done. Add the missing of_node_put() to release the refcount. Signed-off-by:
-
Yangtao Li authored
[ Upstream commit 7f9705be ] The of_find_compatible_node() returns a node pointer with refcount incremented, but there is the lack of use of the of_node_put() when done. Add the missing of_node_put() to release the refcount. Signed-off-by:
-
Yangtao Li authored
[ Upstream commit 2274d800 ] The of_find_compatible_node() returns a node pointer with refcount incremented, but there is the lack of use of the of_node_put() when done. Add the missing of_node_put() to release the refcount. Signed-off-by:
-
Yangtao Li authored
[ Upstream commit 70af6c5b ] The of_find_compatible_node() returns a node pointer with refcount incremented, but there is the lack of use of the of_node_put() when done. Add the missing of_node_put() to release the refcount. Signed-off-by:
-
Yangtao Li authored
[ Upstream commit 5eb8ba90 ] The of_find_compatible_node() returns a node pointer with refcount incremented, but there is the lack of use of the of_node_put() when done. Add the missing of_node_put() to release the refcount. Signed-off-by:
-
Rik van Riel authored
[ Upstream commit 5eed6f1d ] Commit 9b6f7e16 ("mm: rework memcg kernel stack accounting") will result in fork failing if allocating a kernel stack for a task in dup_task_struct exceeds the kernel memory allowance for that cgroup. Unfortunately, it also results in a crash. This is due to the code jumping to free_stack and calling free_thread_stack when the memcg kernel stack charge fails, but without tsk->stack pointing at the freshly allocated stack. This in turn results in the vfree_atomic in free_thread_stack oopsing with a backtrace like this: #5 [ffffc900244efc88] die at ffffffff8101f0ab #6 [ffffc900244efcb8] do_general_protection at ffffffff8101cb86 #7 [ffffc900244efce0] general_protection at ffffffff818ff082 [exception RIP: llist_add_batch+7] RIP: ffffffff8150d487 RSP: ffffc900244efd98 RFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff88085ef55980 RCX: 0000000000000000 RDX: ffff88085ef55980 RSI: 343834343531203a RDI: 343834343531203a RBP: ffffc900244efd98 R8: 0000000000000001 R9: ffff8808578c3600 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88029f6c21c0 R13: 0000000000000286 R14: ffff880147759b00 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #8 [ffffc900244efda0] vfree_atomic at ffffffff811df2c7 #9 [ffffc900244efdb8] copy_process at ffffffff81086e37 #10 [ffffc900244efe98] _do_fork at ffffffff810884e0 #11 [ffffc900244eff10] sys_vfork at ffffffff810887ff #12 [ffffc900244eff20] do_syscall_64 at ffffffff81002a43 RIP: 000000000049b948 RSP: 00007ffcdb307830 RFLAGS: 00000246 RAX: ffffffffffffffda RBX: 0000000000896030 RCX: 000000000049b948 RDX: 0000000000000000 RSI: 00007ffcdb307790 RDI: 00000000005d7421 RBP: 000000000067370f R8: 00007ffcdb3077b0 R9: 000000000001ed00 R10: 0000000000000008 R11: 0000000000000246 R12: 0000000000000040 R13: 000000000000000f R14: 0000000000000000 R15: 000000000088d018 ORIG_RAX: 000000000000003a CS: 0033 SS: 002b The simplest fix is to assign tsk->stack right where it is allocated. Link: http://lkml.kernel.org/r/20181214231726.7ee4843c@imladris.surriel.com Fixes: 9b6f7e16 ("mm: rework memcg kernel stack accounting") Signed-off-by:
Rik van Riel <riel@surriel.com> Acked-by:
Roman Gushchin <guro@fb.com> Acked-by:
Michal Hocko <mhocko@suse.com> Cc: Shakeel Butt <shakeelb@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Tejun Heo <tj@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 4d8f727b ] The loop exits with "timeout" set to -1 not to 0. Fixes: 1158f0f1 ("Input: add support for Nomadik SKE keypad controller") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Petr Machata authored
[ Upstream commit ce5e098f ] Default remotes are stored as FDB entries with an Ethernet address of 00:00:00:00:00:00. When a request is made to change a remote address of a VXLAN device, vxlan_changelink() first deletes the existing default remote, and then creates a new FDB entry. This works well as long as the list of default remotes matches exactly the configuration of a VXLAN remote address. Thus when the VXLAN device has a remote of X, there should be exactly one default remote FDB entry X. If the VXLAN device has no remote address, there should be no such entry. Besides using "ip link set", it is possible to manipulate the list of default remotes by using the "bridge fdb". It is therefore easy to break the above condition. Under such circumstances, the __vxlan_fdb_delete() call doesn't delete the FDB entry itself, but just one remote. The following vxlan_fdb_create() then creates a new FDB entry, leading to a situation where two entries exist for the address 00:00:00:00:00:00, each with a different subset of default remotes. An even more obvious breakage rooted in the same cause can be observed when a remote address is configured for a VXLAN device that did not have one before. In that case vxlan_changelink() doesn't remove any remote, and just creates a new FDB entry for the new address: $ ip link add name vx up type vxlan id 2000 dstport 4789 $ bridge fdb ap dev vx 00:00:00:00:00:00 dst 192.0.2.20 self permanent $ bridge fdb ap dev vx 00:00:00:00:00:00 dst 192.0.2.30 self permanent $ ip link set dev vx type vxlan remote 192.0.2.30 $ bridge fdb sh dev vx | grep 00:00:00:00:00:00 00:00:00:00:00:00 dst 192.0.2.30 self permanent <- new entry, 1 rdst 00:00:00:00:00:00 dst 192.0.2.20 self permanent <- orig. entry, 2 rdsts 00:00:00:00:00:00 dst 192.0.2.30 self permanent To fix this, instead of calling vxlan_fdb_create() directly, defer to vxlan_fdb_update(). That has logic to handle the duplicates properly. Additionally, it also handles notifications, so drop that call from changelink as well. Fixes: 0241b836 ("vxlan: fix default fdb entry netlink notify ordering during netdev create") Signed-off-by:
Petr Machata <petrm@mellanox.com> Acked-by:
Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Huazhong Tan authored
[ Upstream commit cda69d24 ] When hns3_get_vector_ring_chain() failed in the hns3_nic_init_vector_data(), it should do the error handling instead of return directly. Also, cur_chain should be freed instead of chain and head->next should be set to NULL in error handling of hns3_get_vector_ring_chain. This patch fixes them. Fixes: 73b907a0 ("net: hns3: bugfix for buffer not free problem during resetting") Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 4d374bac ] The IP10[5:3] field in Peripheral Function Select Register 10 has a width of 3 bits, i.e. it allows programming one out of 8 different configurations. However, 9 values are provided instead of 8, overflowing into the subsequent field in the register, and thus breaking the configuration of the latter. Fix this by dropping a bogus zero value. Fixes: ac1ebc21 ("sh-pfc: Add sh7734 pinmux support") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 9540cbdf ] The Port C I/O Register 0 contains 7 reserved bits, but the descriptor contains only dummy configuration values for 6 reserved bits, thus breaking the configuration of all subsequent fields in the register. Fix this by adding the two missing configuration values. Fixes: f5e811f2 ("sh-pfc: Add sh7269 pinmux support") Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit e28dc3f0 ] While the SEL_PWM[0-3] fields in the Module Select Register 0 support 4 possible configurations per PWM pin, only the first 3 are valid. Replace the invalid and unused configurations for SEL_PWM[0-3]_3 by dummies. Fixes: 794a6711 ("pinctrl: sh-pfc: Initial R8A77995 PFC support") Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 94482af7 ] The Peripheral Function Select Register 11 contains 3 reserved bits and 15 variable-width fields, but the variable field descriptor does not contain the 3-bit field IP11[25:23]. Fixes: 856cb4bb ("sh: Add support pinmux for SH7734") Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit b0f77269 ] The Module Select Register 0 contains 20 (= 5 x 4) reserved bits, and 12 single-bit fields, but the variable field descriptor lacks a field of 4 reserved bits. Fixes: f5912524 ("pinctrl: sh-pfc: Add R8A77980 PFC support") Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 67d7745b ] The Module Select Register 0 contains 20 (= 5 x 4) reserved bits, and 12 single-bit fields, but the variable field descriptor lacks a field of 4 reserved bits. Fixes: b92ac66a ("pinctrl: sh-pfc: Add R8A77970 PFC support") Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 6a6c195d ] The Peripheral Function Select Register 9 contains 12 fields, but the variable field descriptor contains a 13th bogus field of 3 bits. Fixes: 43c4436e ("pinctrl: sh-pfc: add R8A7794 PFC support") Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 124cde98 ] The tpu4_to3_mux[] array contains the TPU4TO3 pin mark, but the tpu4_to3_pins[] array lacks the corresponding pin number. Add the missing pin number, for non-GPIO pin F26. Fixes: 5da4eb04 ("sh-pfc: sh73a0: Add TPU pin groups and functions") Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 0d6256cb ] The vin1_b_data18_mux[] arrays contains pin marks for the 2 LSB bits of the color components. The vin1_b_data18_pins[] array rightfully does not include the corresponding pin numbers, as RGB18 is subset of RGB24, containing only the 6 MSB bits of each component. Fixes: 8e32c967 ("pinctrl: sh-pfc: r8a7791: Add VIN pins") Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 884fa25f ] The qspi_data4_b_mux[] array contains pin marks for the clock and chip select pins. The qspi_data4_b_pins[] array rightfully does not contain the corresponding pin numbers, as the control pins are provided by a separate group (qspi_ctrl_b). Fixes: 2d0c386f ("pinctrl: sh-pfc: r8a7791: Add QSPI pin groups") Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 96bb2a6a ] The lcd0_data24_1_pins[] array contains the LCD0 D1[2-5] pin numbers, but the lcd0_data24_1_mux[] array lacks the corresponding pin marks. Fixes: 06c7dd86 ("sh-pfc: r8a7740: Add LCDC0 and LCDC1 pin groups and functions") Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 1ebc589a ] The gether_gmii_mux[] array contains the REF125CK pin mark, but the gether_gmii_pins[] array lacks the corresponding pin number. Fixes: bae11d30 ("sh-pfc: r8a7740: Add GETHER pin groups and functions") Signed-off-by:
-
Willem de Bruijn authored
[ Upstream commit fbfb2321 ] Raw sockets support tx timestamping, but one case is missing. IPPROTO_RAW takes a separate packet construction path. raw_send_hdrinc has an explicit call to sock_tx_timestamp, but rawv6_send_hdrinc does not. Add it. Fixes: 11878b40 ("net-timestamp: SOCK_RAW and PING timestamping") Signed-off-by:
Willem de Bruijn <willemb@google.com> Acked-by:
Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by:
-
Kelvin Cao authored
[ Upstream commit 52618040 ] After submitting a Firmware Download MRPC command, Switchtec firmware will delay Management EP BAR MemRd TLP responses by more than 10ms. This is a firmware limitation. Delayed MemRd completions are a problem for systems with a low Completion Timeout (CTO). The current driver checks the MRPC status immediately after submitting an MRPC command, which results in a delayed MemRd completion that may cause a Completion Timeout. Remove the immediate status check and rely on the check after receiving an interrupt or timing out. This is only a software workaround to the READ issue and a proper fix of this should be done in firmware. Fixes: 080b47de ("MicroSemi Switchtec management interface driver") Signed-off-by:
Kelvin Cao <kelvin.cao@microchip.com> Signed-off-by:
Wesley Sheng <wesley.sheng@microchip.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Logan Gunthorpe <logang@deltatee.com> Signed-off-by:
-
Stefan Wahren authored
[ Upstream commit 3a2c2002 ] In order to make the module bcm2835-camera load automatically, we need to add a module alias. Fixes: 4bebb031 ("staging/bcm2835-camera: Set ourselves up as a platform driver.") Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by:
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Stefan Wahren authored
[ Upstream commit 7566f39d ] Abort the probing of the camera driver in case there isn't a camera actually connected to the Raspberry Pi. This solution also avoids a NULL ptr dereference of mmal instance on driver unload. Fixes: 7b3ad5ab ("staging: Import the BCM2835 MMAL-based V4L2 camera driver.") Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 78f3ff52 ] The > comparison should be >= or we access one element beyond the end of the array. (The inst->qinsts[] array is allocated in the ti_msgmgr_probe() function and it has ->num_valid_queues elements.) Fixes: a2b79838 ("mailbox: ti-msgmgr: Add support for Secure Proxy") Signed-off-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by:
-
Yuval Shaia authored
[ Upstream commit 6db21d89 ] Array iterator stays at the same slot, fix it. Fixes: 8700e3e7 ("Soft RoCE driver") Signed-off-by:
Yuval Shaia <yuval.shaia@oracle.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
Zhu Yanjun <yanjun.zhu@oracle.com> Reviewed-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Viresh Kumar authored
[ Upstream commit 46f48aca ] There is one case where we may end up with no "supply" directory for the OPPs in debugfs. That happens when the OPP core isn't managing the regulators for the device and the device's OPP do have microvolt property. It happens because the opp_table->regulator_count remains set to 0 and the debugfs routines don't add any supply directory in such a case. This commit fixes that by setting opp_table->regulator_count to 1 in that particular case. But to make everything work nicely and not break other parts of the core, regulator_count is defined as "int" now instead of "unsigned int" and it can have different special values now. It is set to -1 initially to mark it "uninitialized" and later only we set it to 0 or positive values after checking how many supplies are there. This also helps in finding the bugs where only few of the OPPs have the "opp-microvolt" property set and not all. Fixes: 1fae788e ("PM / OPP: Don't create debugfs "supply-0" directory unnecessarily") Reported-by:
Quentin Perret <quentin.perret@arm.com> Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Mitko Haralanov authored
[ Upstream commit fe4dd423 ] A CA is supposed to ignore FECN bits in multicast, ACK, and CNP packets. This patch corrects the behavior of the HFI1 driver in this regard by ignoring FECNs in those packet types. While fixing the above behavior, fix the extraction of the FECN and BECN bits from the packet headers for both 9B and 16B packets. Furthermore, this patch corrects the driver's response to a FECN in RDMA READ RESPONSE packets. Instead of sending an "empty" ACK, the driver now sends a CNP packet. While editing that code path, add the missing trace for CNP packets. Fixes: 88733e3b ("IB/hfi1: Add 16B UD support") Fixes: f59fb9e0 ("IB/hfi1: Fix handling of FECN marked multicast packet") Reviewed-by:
Kaike Wan <kaike.wan@intel.com> Reviewed-by:
Mike Marciniszyn <mike.marciniszyn@intel.com> Reviewed-by:
Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by:
Mitko Haralanov <mitko.haralanov@intel.com> Signed-off-by:
-
Yoshihiro Shimoda authored
[ Upstream commit ef1b5bf5 ] This patch fixes an issue that mdio_bus_phy_resume() doesn't call phy_resume() if the PHY is not attached. Fixes: 803dd9c7 ("net: phy: avoid suspending twice a PHY") Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 41e30b51 ] While commit 3b7e7848 ("arm64: dts: renesas: r8a7795: Add IPMMU device nodes") for R-Car H3 ES2.0 did include power-domains properties, they were forgotten in the counterpart for older R-Car H3 ES1.x SoCs. Fixes: e4b9a493 ("arm64: dts: renesas: r8a7795-es1: Add IPMMU device nodes") Signed-off-by:
-
Neil Armstrong authored
[ Upstream commit e1f2163d ] The hdmi_5v regulator must be enabled to provide power to the physical HDMI PHY and enables the HDMI 5V presence loopback for the monitor. Fixes: b409f625 ("ARM64: dts: meson-gx: Add HDMI_5V regulator on selected boards") Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
-
Lyude Paul authored
[ Upstream commit c54c7374 ] Jerry Zuo pointed out a rather obscure hotplugging issue that it seems I accidentally introduced into DRM two years ago. Pretend we have a topology like this: |- DP-1: mst_primary |- DP-4: active display |- DP-5: disconnected |- DP-6: active hub |- DP-7: active display |- DP-8: disconnected |- DP-9: disconnected If we unplug DP-6, the topology starting at DP-7 will be destroyed but it's payloads will live on in DP-1's VCPI allocations and thus require removal. However, this removal currently fails because drm_dp_update_payload_part1() will (rightly so) try to validate the port before accessing it, fail then abort. If we keep going, eventually we run the MST hub out of bandwidth and all new allocations will start to fail (or in my case; all new displays just start flickering a ton). We could just teach drm_dp_update_payload_part1() not to drop the port ref in this case, but then we also need to teach drm_dp_destroy_payload_step1() to do the same thing, then hope no one ever adds anything to the that requires a validated port reference in drm_dp_destroy_connector_work(). Kind of sketchy. So let's go with a more clever solution: any port that drm_dp_destroy_connector_work() interacts with is guaranteed to still exist in memory until we say so. While said port might not be valid we don't really care: that's the whole reason we're destroying it in the first place! So, teach drm_dp_get_validated_port_ref() to use the all mighty current_work() function to avoid attempting to validate ports from the context of mgr->destroy_connector_work. I can't see any situation where this wouldn't be safe, and this avoids having to play whack-a-mole in the future of trying to work around port validation. Signed-off-by:
Lyude Paul <lyude@redhat.com> Fixes: 263efde3 ("drm/dp/mst: Get validated port ref in drm_dp_update_payload_part1()") Reported-by:
Jerry Zuo <Jerry.Zuo@amd.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: Harry Wentland <Harry.Wentland@amd.com> Cc: <stable@vger.kernel.org> # v4.6+ Reviewed-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181113224613.28809-1-lyude@redhat.comSigned-off-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
Willem de Bruijn authored
[ Upstream commit aba36930 ] In ip packet generation, pagedlen is initialized for each skb at the start of the loop in __ip(6)_append_data, before label alloc_new_skb. Depending on compiler options, code can be generated that jumps to this label, triggering use of an an uninitialized variable. In practice, at -O2, the generated code moves the initialization below the label. But the code should not rely on that for correctness. Fixes: 15e36f5b ("udp: paged allocation with gso") Signed-off-by:
-
Laurent Pinchart authored
[ Upstream commit 3d61fe5f ] The drm_vblank_init() takes the total number of CRTCs as an argument, but the rcar-du driver passes a bitmask of the CRTC indices. Fix it. Fixes: 4bf8e196 ("drm: Renesas R-Car Display Unit DRM driver") Reported-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 4d486f18 ] We return 0 unconditionally in 'rcar_du_crtc_set_crc_source()'. However, 'ret' is set to some error codes if some function calls fail. Return 'ret' instead to propagate the error code. Fixes: 47a52d02 ("media: drm: rcar-du: Add support for CRC computation") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
-
