- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] Patch "intel_th: pci: Add Gemini Lake support" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled intel_th: pci: Add Gemini Lake support to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: intel_th-pci-add-gemini-lake-support.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Date: Thu, 30 Jun 2016 16:10:51 +0300 Subject: intel_th: pci: Add Gemini Lake support From: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> [ Upstream commit 340837f985c2cb87ca0868d4aa9ce42b0fab3a21 ] This adds Intel(R) Trace Hub PCI ID for Gemini Lake SOC. Signed-off-by: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hwtracing/intel_th/pci.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/hwtracing/intel_th/pci.c +++ b/drivers/hwtracing/intel_th/pci.c @@ -95,6 +95,11 @@ static const struct pci_device_id intel_ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x9da6), .driver_data = (kernel_ulong_t)0, }, + { + /* Gemini Lake */ + PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x318e), + .driver_data = (kernel_ulong_t)0, + }, { 0 }, }; Patches currently in stable-queue which might be from alexander.shishkin(a)linux.intel.com are queue-4.9/intel_th-pci-add-gemini-lake-support.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "Input: i8042 - add TUXEDO BU1406 (N24_25BU) to the nomux list" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Input: i8042 - add TUXEDO BU1406 (N24_25BU) to the nomux list to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: input-i8042-add-tuxedo-bu1406-n24_25bu-to-the-nomux-list.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Date: Tue, 28 Feb 2017 17:14:41 -0800 Subject: Input: i8042 - add TUXEDO BU1406 (N24_25BU) to the nomux list From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> [ Upstream commit a4c2a13129f7c5bcf81704c06851601593303fd5 ] TUXEDO BU1406 does not implement active multiplexing mode properly, and takes around 550 ms in i8042_set_mux_mode(). Given that the device does not have external AUX port, there is no downside in disabling the MUX mode. Reported-by: Paul Menzel <pmenzel(a)molgen.mpg.de> Suggested-by: Vojtech Pavlik <vojtech(a)suse.cz> Reviewed-by: Marcos Paulo de Souza <marcos.souza.org(a)gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/input/serio/i8042-x86ia64io.h | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/input/serio/i8042-x86ia64io.h +++ b/drivers/input/serio/i8042-x86ia64io.h @@ -520,6 +520,13 @@ static const struct dmi_system_id __init DMI_MATCH(DMI_PRODUCT_NAME, "IC4I"), }, }, + { + /* TUXEDO BU1406 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Notebook"), + DMI_MATCH(DMI_PRODUCT_NAME, "N24_25BU"), + }, + }, { } }; Patches currently in stable-queue which might be from dmitry.torokhov(a)gmail.com are queue-4.9/input-i8042-add-tuxedo-bu1406-n24_25bu-to-the-nomux-list.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "icmp: don't fail on fragment reassembly time exceeded" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled icmp: don't fail on fragment reassembly time exceeded to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: icmp-don-t-fail-on-fragment-reassembly-time-exceeded.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:35 CET 2017 From: Matteo Croce <mcroce(a)redhat.com> Date: Thu, 12 Oct 2017 16:12:37 +0200 Subject: icmp: don't fail on fragment reassembly time exceeded From: Matteo Croce <mcroce(a)redhat.com> [ Upstream commit 258bbb1b0e594ad5f5652cb526b3c63e6a7fad3d ] The ICMP implementation currently replies to an ICMP time exceeded message (type 11) with an ICMP host unreachable message (type 3, code 1). However, time exceeded messages can either represent "time to live exceeded in transit" (code 0) or "fragment reassembly time exceeded" (code 1). Unconditionally replying to "fragment reassembly time exceeded" with host unreachable messages might cause unjustified connection resets which are now easily triggered as UFO has been removed, because, in turn, sending large buffers triggers IP fragmentation. The issue can be easily reproduced by running a lot of UDP streams which is likely to trigger IP fragmentation: # start netserver in the test namespace ip netns add test ip netns exec test netserver # create a VETH pair ip link add name veth0 type veth peer name veth0 netns test ip link set veth0 up ip -n test link set veth0 up for i in $(seq 20 29); do # assign addresses to both ends ip addr add dev veth0 192.168.$i.1/24 ip -n test addr add dev veth0 192.168.$i.2/24 # start the traffic netperf -L 192.168.$i.1 -H 192.168.$i.2 -t UDP_STREAM -l 0 & done # wait send_data: data send error: No route to host (errno 113) netperf: send_omni: send_data failed: No route to host We need to differentiate instead: if fragment reassembly time exceeded is reported, we need to silently drop the packet, if time to live exceeded is reported, maintain the current behaviour. In both cases increment the related error count "icmpInTimeExcds". While at it, fix a typo in a comment, and convert the if statement into a switch to mate it more readable. Signed-off-by: Matteo Croce <mcroce(a)redhat.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv4/icmp.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) --- a/net/ipv4/icmp.c +++ b/net/ipv4/icmp.c @@ -766,7 +766,7 @@ static bool icmp_tag_validation(int prot } /* - * Handle ICMP_DEST_UNREACH, ICMP_TIME_EXCEED, ICMP_QUENCH, and + * Handle ICMP_DEST_UNREACH, ICMP_TIME_EXCEEDED, ICMP_QUENCH, and * ICMP_PARAMETERPROB. */ @@ -794,7 +794,8 @@ static bool icmp_unreach(struct sk_buff if (iph->ihl < 5) /* Mangled header, drop. */ goto out_err; - if (icmph->type == ICMP_DEST_UNREACH) { + switch (icmph->type) { + case ICMP_DEST_UNREACH: switch (icmph->code & 15) { case ICMP_NET_UNREACH: case ICMP_HOST_UNREACH: @@ -830,8 +831,16 @@ static bool icmp_unreach(struct sk_buff } if (icmph->code > NR_ICMP_UNREACH) goto out; - } else if (icmph->type == ICMP_PARAMETERPROB) + break; + case ICMP_PARAMETERPROB: info = ntohl(icmph->un.gateway) >> 24; + break; + case ICMP_TIME_EXCEEDED: + __ICMP_INC_STATS(net, ICMP_MIB_INTIMEEXCDS); + if (icmph->code == ICMP_EXC_FRAGTIME) + goto out; + break; + } /* * Throw it at our lower layers Patches currently in stable-queue which might be from mcroce(a)redhat.com are queue-4.9/icmp-don-t-fail-on-fragment-reassembly-time-exceeded.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "IB/ipoib: Grab rtnl lock on heavy flush when calling ndo_open/stop" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/ipoib: Grab rtnl lock on heavy flush when calling ndo_open/stop to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-ipoib-grab-rtnl-lock-on-heavy-flush-when-calling-ndo_open-stop.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:35 CET 2017 From: Alex Vesker <valex(a)mellanox.com> Date: Tue, 10 Oct 2017 10:36:41 +0300 Subject: IB/ipoib: Grab rtnl lock on heavy flush when calling ndo_open/stop From: Alex Vesker <valex(a)mellanox.com> [ Upstream commit b4b678b06f6eef18bff44a338c01870234db0bc9 ] When ndo_open and ndo_stop are called RTNL lock should be held. In this specific case ipoib_ib_dev_open calls the offloaded ndo_open which re-sets the number of TX queue assuming RTNL lock is held. Since RTNL lock is not held, RTNL assert will fail. Signed-off-by: Alex Vesker <valex(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/ulp/ipoib/ipoib_ib.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c @@ -1177,10 +1177,15 @@ static void __ipoib_ib_dev_flush(struct ipoib_ib_dev_down(dev); if (level == IPOIB_FLUSH_HEAVY) { + rtnl_lock(); if (test_bit(IPOIB_FLAG_INITIALIZED, &priv->flags)) ipoib_ib_dev_stop(dev); - if (ipoib_ib_dev_open(dev) != 0) + + result = ipoib_ib_dev_open(dev); + rtnl_unlock(); + if (result) return; + if (netif_queue_stopped(dev)) netif_start_queue(dev); } Patches currently in stable-queue which might be from valex(a)mellanox.com are queue-4.9/ib-ipoib-grab-rtnl-lock-on-heavy-flush-when-calling-ndo_open-stop.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "Ib/hfi1: Return actual operational VLs in port info query" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Ib/hfi1: Return actual operational VLs in port info query to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-hfi1-return-actual-operational-vls-in-port-info-query.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:35 CET 2017 From: Patel Jay P <jay.p.patel(a)intel.com> Date: Mon, 23 Oct 2017 06:05:53 -0700 Subject: Ib/hfi1: Return actual operational VLs in port info query From: Patel Jay P <jay.p.patel(a)intel.com> [ Upstream commit 00f9203119dd2774564407c7a67b17d81916298b ] __subn_get_opa_portinfo stores value returned by hfi1_get_ib_cfg() as operational vls. hfi1_get_ib_cfg() returns vls_operational field in hfi1_pportdata. The problem with this is that the value is always equal to vls_supported field in hfi1_pportdata. The logic to calculate operational_vls is to set value passed by FM (in __subn_set_opa_portinfo routine). If no value is passed then default value is stored in operational_vls. Field actual_vls_operational is calculated on the basis of buffer control table. Hence, modifying hfi1_get_ib_cfg() to return actual_operational_vls when used with HFI1_IB_CFG_OP_VLS parameter Reviewed-by: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Reviewed-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Signed-off-by: Patel Jay P <jay.p.patel(a)intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/hfi1/chip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/infiniband/hw/hfi1/chip.c +++ b/drivers/infiniband/hw/hfi1/chip.c @@ -9769,7 +9769,7 @@ int hfi1_get_ib_cfg(struct hfi1_pportdat goto unimplemented; case HFI1_IB_CFG_OP_VLS: - val = ppd->vls_operational; + val = ppd->actual_vls_operational; break; case HFI1_IB_CFG_VL_HIGH_CAP: /* VL arb high priority table size */ val = VL_ARB_HIGH_PRIO_TABLE_SIZE; Patches currently in stable-queue which might be from jay.p.patel(a)intel.com are queue-4.9/ib-hfi1-return-actual-operational-vls-in-port-info-query.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "IB/core: Fix calculation of maximum RoCE MTU" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/core: Fix calculation of maximum RoCE MTU to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-core-fix-calculation-of-maximum-roce-mtu.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:35 CET 2017 From: Parav Pandit <parav(a)mellanox.com> Date: Mon, 16 Oct 2017 08:45:16 +0300 Subject: IB/core: Fix calculation of maximum RoCE MTU From: Parav Pandit <parav(a)mellanox.com> [ Upstream commit 99260132fde7bddc6e0132ce53da94d1c9ccabcb ] The original code only took into consideration the largest header possible after the IB_BTH_BYTES. This was incorrect, as the largest possible header size is the largest possible combination of headers we might run into. The new code accounts for all possible headers in the largest possible combination and subtracts that from the MTU to make sure that all packets will fit on the wire. Link: https://www.spinics.net/lists/linux-rdma/msg54558.html Fixes: 3c86aa70bf67 ("RDMA/cm: Add RDMA CM support for IBoE devices") Signed-off-by: Parav Pandit <parav(a)mellanox.com> Reviewed-by: Daniel Jurgens <danielj(a)mellanox.com> Reported-by: Roland Dreier <roland(a)purestorage.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/rdma/ib_addr.h | 7 ++++--- include/rdma/ib_pack.h | 19 +++++++++++-------- 2 files changed, 15 insertions(+), 11 deletions(-) --- a/include/rdma/ib_addr.h +++ b/include/rdma/ib_addr.h @@ -243,10 +243,11 @@ static inline void rdma_addr_set_dgid(st static inline enum ib_mtu iboe_get_mtu(int mtu) { /* - * reduce IB headers from effective IBoE MTU. 28 stands for - * atomic header which is the biggest possible header after BTH + * Reduce IB headers from effective IBoE MTU. */ - mtu = mtu - IB_GRH_BYTES - IB_BTH_BYTES - 28; + mtu = mtu - (IB_GRH_BYTES + IB_UDP_BYTES + IB_BTH_BYTES + + IB_EXT_XRC_BYTES + IB_EXT_ATOMICETH_BYTES + + IB_ICRC_BYTES); if (mtu >= ib_mtu_enum_to_int(IB_MTU_4096)) return IB_MTU_4096; --- a/include/rdma/ib_pack.h +++ b/include/rdma/ib_pack.h @@ -37,14 +37,17 @@ #include <uapi/linux/if_ether.h> enum { - IB_LRH_BYTES = 8, - IB_ETH_BYTES = 14, - IB_VLAN_BYTES = 4, - IB_GRH_BYTES = 40, - IB_IP4_BYTES = 20, - IB_UDP_BYTES = 8, - IB_BTH_BYTES = 12, - IB_DETH_BYTES = 8 + IB_LRH_BYTES = 8, + IB_ETH_BYTES = 14, + IB_VLAN_BYTES = 4, + IB_GRH_BYTES = 40, + IB_IP4_BYTES = 20, + IB_UDP_BYTES = 8, + IB_BTH_BYTES = 12, + IB_DETH_BYTES = 8, + IB_EXT_ATOMICETH_BYTES = 28, + IB_EXT_XRC_BYTES = 4, + IB_ICRC_BYTES = 4 }; struct ib_field { Patches currently in stable-queue which might be from parav(a)mellanox.com are queue-4.9/ib-core-fix-calculation-of-maximum-roce-mtu.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "HID: cp2112: fix broken gpio_direction_input callback" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled HID: cp2112: fix broken gpio_direction_input callback to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: hid-cp2112-fix-broken-gpio_direction_input-callback.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Sébastien Szymanski <sebastien.szymanski(a)armadeus.com> Date: Fri, 10 Nov 2017 10:01:43 +0100 Subject: HID: cp2112: fix broken gpio_direction_input callback From: Sébastien Szymanski <sebastien.szymanski(a)armadeus.com> [ Upstream commit 7da85fbf1c87d4f73621e0e7666a3387497075a9 ] When everything goes smoothly, ret is set to 0 which makes the function to return EIO error. Fixes: 8e9faa15469e ("HID: cp2112: fix gpio-callback error handling") Signed-off-by: SÃ©bastien Szymanski <sebastien.szymanski(a)armadeus.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hid/hid-cp2112.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/drivers/hid/hid-cp2112.c +++ b/drivers/hid/hid-cp2112.c @@ -188,6 +188,8 @@ static int cp2112_gpio_direction_input(s HID_REQ_GET_REPORT); if (ret != CP2112_GPIO_CONFIG_LENGTH) { hid_err(hdev, "error requesting GPIO config: %d\n", ret); + if (ret >= 0) + ret = -EIO; goto exit; } @@ -197,8 +199,10 @@ static int cp2112_gpio_direction_input(s ret = hid_hw_raw_request(hdev, CP2112_GPIO_CONFIG, buf, CP2112_GPIO_CONFIG_LENGTH, HID_FEATURE_REPORT, HID_REQ_SET_REPORT); - if (ret < 0) { + if (ret != CP2112_GPIO_CONFIG_LENGTH) { hid_err(hdev, "error setting GPIO config: %d\n", ret); + if (ret >= 0) + ret = -EIO; goto exit; } @@ -206,7 +210,7 @@ static int cp2112_gpio_direction_input(s exit: mutex_unlock(&dev->lock); - return ret < 0 ? ret : -EIO; + return ret; } static void cp2112_gpio_set(struct gpio_chip *chip, unsigned offset, int value) Patches currently in stable-queue which might be from sebastien.szymanski(a)armadeus.com are queue-4.9/clk-imx6-refine-hdmi_isfr-s-parent-to-make-hdmi-work-on-i.mx6-socs-w-o-vpu.patch queue-4.9/hid-cp2112-fix-broken-gpio_direction_input-callback.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "GFS2: Take inode off order_write list when setting jdata flag" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled GFS2: Take inode off order_write list when setting jdata flag to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: gfs2-take-inode-off-order_write-list-when-setting-jdata-flag.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:35 CET 2017 From: Bob Peterson <rpeterso(a)redhat.com> Date: Wed, 20 Sep 2017 08:30:04 -0500 Subject: GFS2: Take inode off order_write list when setting jdata flag From: Bob Peterson <rpeterso(a)redhat.com> [ Upstream commit cc555b09d8c3817aeebda43a14ab67049a5653f7 ] This patch fixes a deadlock caused when the jdata flag is set for inodes that are already on the ordered write list. Since it is on the ordered write list, log_flush calls gfs2_ordered_write which calls filemap_fdatawrite. But since the inode had the jdata flag set, that calls gfs2_jdata_writepages, which tries to start a new transaction. A new transaction cannot be started because it tries to acquire the log_flush rwsem which is already locked by the log flush operation. The bottom line is: We cannot switch an inode from ordered to jdata until we eliminate any ordered data pages (via log flush) or any log_flush operation afterward will create the circular dependency above. So we need to flush the log before setting the diskflags to switch the file mode, then we need to remove the inode from the ordered writes list. Before this patch, the log flush was done for jdata->ordered, but that's wrong. If we're going from jdata to ordered, we don't need to call gfs2_log_flush because the call to filemap_fdatawrite will do it for us: filemap_fdatawrite() -> __filemap_fdatawrite_range() __filemap_fdatawrite_range() -> do_writepages() do_writepages() -> gfs2_jdata_writepages() gfs2_jdata_writepages() -> gfs2_log_flush() This patch modifies function do_gfs2_set_flags so that if a file has its jdata flag set, and it's already on the ordered write list, the log will be flushed and it will be removed from the list before setting the flag. Signed-off-by: Bob Peterson <rpeterso(a)redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com> Acked-by: Abhijith Das <adas(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/gfs2/file.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/fs/gfs2/file.c +++ b/fs/gfs2/file.c @@ -256,7 +256,7 @@ static int do_gfs2_set_flags(struct file goto out; } if ((flags ^ new_flags) & GFS2_DIF_JDATA) { - if (flags & GFS2_DIF_JDATA) + if (new_flags & GFS2_DIF_JDATA) gfs2_log_flush(sdp, ip->i_gl, NORMAL_FLUSH); error = filemap_fdatawrite(inode->i_mapping); if (error) @@ -264,6 +264,8 @@ static int do_gfs2_set_flags(struct file error = filemap_fdatawait(inode->i_mapping); if (error) goto out; + if (new_flags & GFS2_DIF_JDATA) + gfs2_ordered_del_inode(ip); } error = gfs2_trans_begin(sdp, RES_DINODE, 0); if (error) Patches currently in stable-queue which might be from rpeterso(a)redhat.com are queue-4.9/gfs2-take-inode-off-order_write-list-when-setting-jdata-flag.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "fjes: Fix wrong netdevice feature flags" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fjes: Fix wrong netdevice feature flags to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: fjes-fix-wrong-netdevice-feature-flags.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Taku Izumi <izumi.taku(a)jp.fujitsu.com> Date: Wed, 15 Mar 2017 13:47:50 +0900 Subject: fjes: Fix wrong netdevice feature flags From: Taku Izumi <izumi.taku(a)jp.fujitsu.com> [ Upstream commit fe8daf5fa715f7214952f06a387e4b7de818c5be ] This patch fixes netdev->features for Extended Socket network device. Currently Extended Socket network device's netdev->feature claims NETIF_F_HW_CSUM, however this is completely wrong. There's no feature of checksum offloading. That causes invalid TCP/UDP checksum and packet rejection when IP forwarding from Extended Socket network device to other network device. NETIF_F_HW_CSUM should be omitted. Signed-off-by: Taku Izumi <izumi.taku(a)jp.fujitsu.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/fjes/fjes_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/fjes/fjes_main.c +++ b/drivers/net/fjes/fjes_main.c @@ -1277,7 +1277,7 @@ static void fjes_netdev_setup(struct net fjes_set_ethtool_ops(netdev); netdev->mtu = fjes_support_mtu[3]; netdev->flags |= IFF_BROADCAST; - netdev->features |= NETIF_F_HW_CSUM | NETIF_F_HW_VLAN_CTAG_FILTER; + netdev->features |= NETIF_F_HW_VLAN_CTAG_FILTER; } static void fjes_irq_watch_task(struct work_struct *work) Patches currently in stable-queue which might be from izumi.taku(a)jp.fujitsu.com are queue-4.9/fjes-fix-wrong-netdevice-feature-flags.patch queue-4.9/revert-x86-acpi-set-persistent-cpuid-nodeid-mapping-when-booting.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "fbdev: controlfb: Add missing modes to fix out of bounds access" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fbdev: controlfb: Add missing modes to fix out of bounds access to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Geert Uytterhoeven <geert(a)linux-m68k.org> Date: Thu, 9 Nov 2017 18:09:33 +0100 Subject: fbdev: controlfb: Add missing modes to fix out of bounds access From: Geert Uytterhoeven <geert(a)linux-m68k.org> [ Upstream commit ac831a379d34109451b3c41a44a20ee10ecb615f ] Dan's static analysis says: drivers/video/fbdev/controlfb.c:560 control_setup() error: buffer overflow 'control_mac_modes' 20 <= 21 Indeed, control_mac_modes[] has only 20 elements, while VMODE_MAX is 22, which may lead to an out of bounds read when parsing vmode commandline options. The bug was introduced in v2.4.5.6, when 2 new modes were added to macmodes.h, but control_mac_modes[] wasn't updated: https://kernel.opensuse.org/cgit/kernel/diff/include/video/macmodes.h?h=v2.… Augment control_mac_modes[] with the two new video modes to fix this. Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Cc: Dan Carpenter <dan.carpenter(a)oracle.com> Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/controlfb.h | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/video/fbdev/controlfb.h +++ b/drivers/video/fbdev/controlfb.h @@ -141,5 +141,7 @@ static struct max_cmodes control_mac_mod {{ 1, 2}}, /* 1152x870, 75Hz */ {{ 0, 1}}, /* 1280x960, 75Hz */ {{ 0, 1}}, /* 1280x1024, 75Hz */ + {{ 1, 2}}, /* 1152x768, 60Hz */ + {{ 0, 1}}, /* 1600x1024, 60Hz */ }; Patches currently in stable-queue which might be from geert(a)linux-m68k.org are queue-4.9/fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "efi/esrt: Cleanup bad memory map log messages" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled efi/esrt: Cleanup bad memory map log messages to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: efi-esrt-cleanup-bad-memory-map-log-messages.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Daniel Drake <drake(a)endlessm.com> Date: Tue, 7 Feb 2017 13:08:23 -0600 Subject: efi/esrt: Cleanup bad memory map log messages From: Daniel Drake <drake(a)endlessm.com> [ Upstream commit 822f5845f710e57d7e2df1fd1ee00d6e19d334fe ] The Intel Compute Stick STCK1A8LFC and Weibu F3C platforms both log 2 error messages during boot: efi: requested map not found. esrt: ESRT header is not in the memory map. Searching the web, this seems to affect many other platforms too. Since these messages are logged as errors, they appear on-screen during the boot process even when using the "quiet" boot parameter used by distros. Demote the ESRT error to a warning so that it does not appear on-screen, and delete the error logging from efi_mem_desc_lookup; both callsites of that function log more specific messages upon failure. Out of curiosity I looked closer at the Weibu F3C. There is no entry in the UEFI-provided memory map which corresponds to the ESRT pointer, but hacking the code to map it anyway, the ESRT does appear to be valid with 2 entries. Signed-off-by: Daniel Drake <drake(a)endlessm.com> Cc: Matt Fleming <matt(a)codeblueprint.co.uk> Acked-by: Peter Jones <pjones(a)redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/firmware/efi/efi.c | 1 - drivers/firmware/efi/esrt.c | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -384,7 +384,6 @@ int __init efi_mem_desc_lookup(u64 phys_ return 0; } } - pr_err_once("requested map not found.\n"); return -ENOENT; } --- a/drivers/firmware/efi/esrt.c +++ b/drivers/firmware/efi/esrt.c @@ -251,7 +251,7 @@ void __init efi_esrt_init(void) rc = efi_mem_desc_lookup(efi.esrt, &md); if (rc < 0) { - pr_err("ESRT header is not in the memory map.\n"); + pr_warn("ESRT header is not in the memory map.\n"); return; } Patches currently in stable-queue which might be from drake(a)endlessm.com are queue-4.9/efi-esrt-cleanup-bad-memory-map-log-messages.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/radeon/si: add dpm quirk for Oland" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/radeon/si: add dpm quirk for Oland to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-radeon-si-add-dpm-quirk-for-oland.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Alex Deucher <alexander.deucher(a)amd.com> Date: Tue, 14 Mar 2017 14:42:03 -0400 Subject: drm/radeon/si: add dpm quirk for Oland From: Alex Deucher <alexander.deucher(a)amd.com> [ Upstream commit 0f424de1fd9bc4ab24bd1fe5430ab5618e803e31 ] OLAND 0x1002:0x6604 0x1028:0x066F 0x00 seems to have problems with higher sclks. Acked-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/radeon/si_dpm.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/gpu/drm/radeon/si_dpm.c +++ b/drivers/gpu/drm/radeon/si_dpm.c @@ -3029,6 +3029,12 @@ static void si_apply_state_adjust_rules( max_sclk = 75000; max_mclk = 80000; } + } else if (rdev->family == CHIP_OLAND) { + if ((rdev->pdev->device == 0x6604) && + (rdev->pdev->subsystem_vendor == 0x1028) && + (rdev->pdev->subsystem_device == 0x066F)) { + max_sclk = 75000; + } } /* Apply dpm quirks */ while (p && p->chip_device != 0) { Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are queue-4.9/drm-radeon-reinstate-oland-workaround-for-sclk.patch queue-4.9/drm-amdgpu-fix-parser-init-error-path-to-avoid-crash-in-parser-fini.patch queue-4.9/drm-radeon-si-add-dpm-quirk-for-oland.patch queue-4.9/drm-amd-remove-broken-include-path.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/radeon: reinstate oland workaround for sclk" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/radeon: reinstate oland workaround for sclk to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-radeon-reinstate-oland-workaround-for-sclk.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Alex Deucher <alexander.deucher(a)amd.com> Date: Wed, 15 Mar 2017 21:11:46 -0400 Subject: drm/radeon: reinstate oland workaround for sclk From: Alex Deucher <alexander.deucher(a)amd.com> [ Upstream commit 66822d815ae61ecb2d9dba9031517e8a8476969d ] Higher sclks seem to be unstable on some boards. bug: https://bugs.freedesktop.org/show_bug.cgi?id=100222 Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/radeon/si_dpm.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/drivers/gpu/drm/radeon/si_dpm.c +++ b/drivers/gpu/drm/radeon/si_dpm.c @@ -3030,9 +3030,13 @@ static void si_apply_state_adjust_rules( max_mclk = 80000; } } else if (rdev->family == CHIP_OLAND) { - if ((rdev->pdev->device == 0x6604) && - (rdev->pdev->subsystem_vendor == 0x1028) && - (rdev->pdev->subsystem_device == 0x066F)) { + if ((rdev->pdev->revision == 0xC7) || + (rdev->pdev->revision == 0x80) || + (rdev->pdev->revision == 0x81) || + (rdev->pdev->revision == 0x83) || + (rdev->pdev->revision == 0x87) || + (rdev->pdev->device == 0x6604) || + (rdev->pdev->device == 0x6605)) { max_sclk = 75000; } } Patches currently in stable-queue which might be from alexander.deucher(a)amd.com are queue-4.9/drm-radeon-reinstate-oland-workaround-for-sclk.patch queue-4.9/drm-amdgpu-fix-parser-init-error-path-to-avoid-crash-in-parser-fini.patch queue-4.9/drm-radeon-si-add-dpm-quirk-for-oland.patch queue-4.9/drm-amd-remove-broken-include-path.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/omap: fix dmabuf mmap for dma_alloc'ed buffers" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/omap: fix dmabuf mmap for dma_alloc'ed buffers to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-omap-fix-dmabuf-mmap-for-dma_alloc-ed-buffers.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Date: Tue, 28 Feb 2017 10:11:45 +0200 Subject: drm/omap: fix dmabuf mmap for dma_alloc'ed buffers From: Tomi Valkeinen <tomi.valkeinen(a)ti.com> [ Upstream commit 9fa1d7537242bd580ffa99c4725a0407096aad26 ] omap_gem_dmabuf_mmap() returns an error (with a WARN) when called for a buffer which is allocated with dma_alloc_*(). This prevents dmabuf mmap from working on SoCs without DMM, e.g. AM4 and OMAP3. I could not find any reason for omap_gem_dmabuf_mmap() rejecting such buffers, and just removing the if() fixes the limitation. Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 3 --- 1 file changed, 3 deletions(-) --- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c +++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c @@ -147,9 +147,6 @@ static int omap_gem_dmabuf_mmap(struct d struct drm_gem_object *obj = buffer->priv; int ret = 0; - if (WARN_ON(!obj->filp)) - return -EINVAL; - ret = drm_gem_mmap_obj(obj, omap_gem_mmap_size(obj), vma); if (ret < 0) return ret; Patches currently in stable-queue which might be from tomi.valkeinen(a)ti.com are queue-4.9/drm-omap-fix-dmabuf-mmap-for-dma_alloc-ed-buffers.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/amdgpu: fix parser init error path to avoid crash in parser fini" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/amdgpu: fix parser init error path to avoid crash in parser fini to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-amdgpu-fix-parser-init-error-path-to-avoid-crash-in-parser-fini.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Dave Airlie <airlied(a)redhat.com> Date: Fri, 10 Mar 2017 12:13:04 +1000 Subject: drm/amdgpu: fix parser init error path to avoid crash in parser fini From: Dave Airlie <airlied(a)redhat.com> [ Upstream commit 607523d19c9d67ba4cf7bdaced644f11ed04992c ] If we don't reset the chunk info in the error path, the subsequent fini path will double free. Reviewed-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Dave Airlie <airlied(a)redhat.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -240,6 +240,8 @@ free_partial_kdata: for (; i >= 0; i--) drm_free_large(p->chunks[i].kdata); kfree(p->chunks); + p->chunks = NULL; + p->nchunks = 0; put_ctx: amdgpu_ctx_put(p->ctx); free_chunk: Patches currently in stable-queue which might be from airlied(a)redhat.com are queue-4.9/drm-amdgpu-fix-parser-init-error-path-to-avoid-crash-in-parser-fini.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "drm: amd: remove broken include path" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm: amd: remove broken include path to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-amd-remove-broken-include-path.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Arnd Bergmann <arnd(a)arndb.de> Date: Tue, 14 Mar 2017 22:27:11 +0100 Subject: drm: amd: remove broken include path From: Arnd Bergmann <arnd(a)arndb.de> [ Upstream commit 655d9ca9ac075da1ef2a45012ba48a39f6eb1f58 ] The AMD ACP driver adds "-I../acp -I../acp/include" to the gcc command line, which makes no sense, since these are evaluated relative to the build directory. When we build with "make W=1", they instead cause a warning: cc1: error: ../acp/: No such file or directory [-Werror=missing-include-dirs] cc1: error: ../acp/include: No such file or directory [-Werror=missing-include-dirs] cc1: all warnings being treated as errors ../scripts/Makefile.build:289: recipe for target 'drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o' failed ../scripts/Makefile.build:289: recipe for target 'drivers/gpu/drm/amd/amdgpu/amdgpu_device.o' failed ../scripts/Makefile.build:289: recipe for target 'drivers/gpu/drm/amd/amdgpu/amdgpu_kms.o' failed This removes the subdir-ccflags variable that evidently did not serve any purpose here. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/amd/acp/Makefile | 2 -- 1 file changed, 2 deletions(-) --- a/drivers/gpu/drm/amd/acp/Makefile +++ b/drivers/gpu/drm/amd/acp/Makefile @@ -3,6 +3,4 @@ # of AMDSOC/AMDGPU drm driver. # It provides the HW control for ACP related functionalities. -subdir-ccflags-y += -I$(AMDACPPATH)/ -I$(AMDACPPATH)/include - AMD_ACP_FILES := $(AMDACPPATH)/acp_hw.o Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.9/irqchip-mvebu-odmi-select-generic_msi_irq_domain.patch queue-4.9/drm-amd-remove-broken-include-path.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "Drivers: hv: util: move waiting for release to hv_utils_transport itself" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Drivers: hv: util: move waiting for release to hv_utils_transport itself to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drivers-hv-util-move-waiting-for-release-to-hv_utils_transport-itself.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Vitaly Kuznetsov <vkuznets(a)redhat.com> Date: Sat, 4 Mar 2017 18:13:59 -0700 Subject: Drivers: hv: util: move waiting for release to hv_utils_transport itself From: Vitaly Kuznetsov <vkuznets(a)redhat.com> [ Upstream commit e9c18ae6eb2b312f16c63e34b43ea23926daa398 ] Waiting for release_event in all three drivers introduced issues on release as on_reset() hook is not always called. E.g. if the device was never opened we will never get the completion. Move the waiting code to hvutil_transport_destroy() and make sure it is only called when the device is open. hvt->lock serialization should guarantee the absence of races. Fixes: 5a66fecbf6aa ("Drivers: hv: util: kvp: Fix a rescind processing issue") Fixes: 20951c7535b5 ("Drivers: hv: util: Fcopy: Fix a rescind processing issue") Fixes: d77044d142e9 ("Drivers: hv: util: Backup: Fix a rescind processing issue") Reported-by: Dexuan Cui <decui(a)microsoft.com> Tested-by: Dexuan Cui <decui(a)microsoft.com> Signed-off-by: Vitaly Kuznetsov <vkuznets(a)redhat.com> Signed-off-by: K. Y. Srinivasan <kys(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hv/hv_fcopy.c | 4 ---- drivers/hv/hv_kvp.c | 4 ---- drivers/hv/hv_snapshot.c | 4 ---- drivers/hv/hv_utils_transport.c | 12 ++++++++---- drivers/hv/hv_utils_transport.h | 1 + 5 files changed, 9 insertions(+), 16 deletions(-) --- a/drivers/hv/hv_fcopy.c +++ b/drivers/hv/hv_fcopy.c @@ -61,7 +61,6 @@ static DECLARE_WORK(fcopy_send_work, fco static const char fcopy_devname[] = "vmbus/hv_fcopy"; static u8 *recv_buffer; static struct hvutil_transport *hvt; -static struct completion release_event; /* * This state maintains the version number registered by the daemon. */ @@ -322,7 +321,6 @@ static void fcopy_on_reset(void) if (cancel_delayed_work_sync(&fcopy_timeout_work)) fcopy_respond_to_host(HV_E_FAIL); - complete(&release_event); } int hv_fcopy_init(struct hv_util_service *srv) @@ -330,7 +328,6 @@ int hv_fcopy_init(struct hv_util_service recv_buffer = srv->recv_buffer; fcopy_transaction.recv_channel = srv->channel; - init_completion(&release_event); /* * When this driver loads, the user level daemon that * processes the host requests may not yet be running. @@ -352,5 +349,4 @@ void hv_fcopy_deinit(void) fcopy_transaction.state = HVUTIL_DEVICE_DYING; cancel_delayed_work_sync(&fcopy_timeout_work); hvutil_transport_destroy(hvt); - wait_for_completion(&release_event); } --- a/drivers/hv/hv_kvp.c +++ b/drivers/hv/hv_kvp.c @@ -88,7 +88,6 @@ static DECLARE_WORK(kvp_sendkey_work, kv static const char kvp_devname[] = "vmbus/hv_kvp"; static u8 *recv_buffer; static struct hvutil_transport *hvt; -static struct completion release_event; /* * Register the kernel component with the user-level daemon. * As part of this registration, pass the LIC version number. @@ -717,7 +716,6 @@ static void kvp_on_reset(void) if (cancel_delayed_work_sync(&kvp_timeout_work)) kvp_respond_to_host(NULL, HV_E_FAIL); kvp_transaction.state = HVUTIL_DEVICE_INIT; - complete(&release_event); } int @@ -726,7 +724,6 @@ hv_kvp_init(struct hv_util_service *srv) recv_buffer = srv->recv_buffer; kvp_transaction.recv_channel = srv->channel; - init_completion(&release_event); /* * When this driver loads, the user level daemon that * processes the host requests may not yet be running. @@ -750,5 +747,4 @@ void hv_kvp_deinit(void) cancel_delayed_work_sync(&kvp_timeout_work); cancel_work_sync(&kvp_sendkey_work); hvutil_transport_destroy(hvt); - wait_for_completion(&release_event); } --- a/drivers/hv/hv_snapshot.c +++ b/drivers/hv/hv_snapshot.c @@ -66,7 +66,6 @@ static int dm_reg_value; static const char vss_devname[] = "vmbus/hv_vss"; static __u8 *recv_buffer; static struct hvutil_transport *hvt; -static struct completion release_event; static void vss_timeout_func(struct work_struct *dummy); static void vss_handle_request(struct work_struct *dummy); @@ -331,13 +330,11 @@ static void vss_on_reset(void) if (cancel_delayed_work_sync(&vss_timeout_work)) vss_respond_to_host(HV_E_FAIL); vss_transaction.state = HVUTIL_DEVICE_INIT; - complete(&release_event); } int hv_vss_init(struct hv_util_service *srv) { - init_completion(&release_event); if (vmbus_proto_version < VERSION_WIN8_1) { pr_warn("Integration service 'Backup (volume snapshot)'" " not supported on this host version.\n"); @@ -368,5 +365,4 @@ void hv_vss_deinit(void) cancel_delayed_work_sync(&vss_timeout_work); cancel_work_sync(&vss_handle_request_work); hvutil_transport_destroy(hvt); - wait_for_completion(&release_event); } --- a/drivers/hv/hv_utils_transport.c +++ b/drivers/hv/hv_utils_transport.c @@ -182,10 +182,11 @@ static int hvt_op_release(struct inode * * connects back. */ hvt_reset(hvt); - mutex_unlock(&hvt->lock); if (mode_old == HVUTIL_TRANSPORT_DESTROY) - hvt_transport_free(hvt); + complete(&hvt->release); + + mutex_unlock(&hvt->lock); return 0; } @@ -304,6 +305,7 @@ struct hvutil_transport *hvutil_transpor init_waitqueue_head(&hvt->outmsg_q); mutex_init(&hvt->lock); + init_completion(&hvt->release); spin_lock(&hvt_list_lock); list_add(&hvt->list, &hvt_list); @@ -351,6 +353,8 @@ void hvutil_transport_destroy(struct hvu if (hvt->cn_id.idx > 0 && hvt->cn_id.val > 0) cn_del_callback(&hvt->cn_id); - if (mode_old != HVUTIL_TRANSPORT_CHARDEV) - hvt_transport_free(hvt); + if (mode_old == HVUTIL_TRANSPORT_CHARDEV) + wait_for_completion(&hvt->release); + + hvt_transport_free(hvt); } --- a/drivers/hv/hv_utils_transport.h +++ b/drivers/hv/hv_utils_transport.h @@ -41,6 +41,7 @@ struct hvutil_transport { int outmsg_len; /* its length */ wait_queue_head_t outmsg_q; /* poll/read wait queue */ struct mutex lock; /* protects struct members */ + struct completion release; /* synchronize with fd release */ }; struct hvutil_transport *hvutil_transport_init(const char *name, Patches currently in stable-queue which might be from vkuznets(a)redhat.com are queue-4.9/drivers-hv-util-move-waiting-for-release-to-hv_utils_transport-itself.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "dmaengine: ti-dma-crossbar: Correct am335x/am43xx mux value type" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dmaengine: ti-dma-crossbar: Correct am335x/am43xx mux value type to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dmaengine-ti-dma-crossbar-correct-am335x-am43xx-mux-value-type.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Peter Ujfalusi <peter.ujfalusi(a)ti.com> Date: Wed, 8 Nov 2017 12:02:25 +0200 Subject: dmaengine: ti-dma-crossbar: Correct am335x/am43xx mux value type From: Peter Ujfalusi <peter.ujfalusi(a)ti.com> [ Upstream commit 288e7560e4d3e259aa28f8f58a8dfe63627a1bf6 ] The used 0x1f mask is only valid for am335x family of SoC, different family using this type of crossbar might have different number of electable events. In case of am43xx family 0x3f mask should have been used for example. Instead of trying to handle each family's mask, just use u8 type to store the mux value since the event offsets are aligned to byte offset. Fixes: 42dbdcc6bf965 ("dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx") Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma/ti-dma-crossbar.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/drivers/dma/ti-dma-crossbar.c +++ b/drivers/dma/ti-dma-crossbar.c @@ -49,12 +49,12 @@ struct ti_am335x_xbar_data { struct ti_am335x_xbar_map { u16 dma_line; - u16 mux_val; + u8 mux_val; }; -static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u16 val) +static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u8 val) { - writeb_relaxed(val & 0x1f, iomem + event); + writeb_relaxed(val, iomem + event); } static void ti_am335x_xbar_free(struct device *dev, void *route_data) @@ -105,7 +105,7 @@ static void *ti_am335x_xbar_route_alloca } map->dma_line = (u16)dma_spec->args[0]; - map->mux_val = (u16)dma_spec->args[2]; + map->mux_val = (u8)dma_spec->args[2]; dma_spec->args[2] = 0; dma_spec->args_count = 2; Patches currently in stable-queue which might be from peter.ujfalusi(a)ti.com are queue-4.9/dmaengine-ti-dma-crossbar-correct-am335x-am43xx-mux-value-type.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "dmaengine: rcar-dmac: use TCRB instead of TCR for residue" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dmaengine: rcar-dmac: use TCRB instead of TCR for residue to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:35 CET 2017 From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com> Date: Thu, 19 Oct 2017 01:15:13 +0000 Subject: dmaengine: rcar-dmac: use TCRB instead of TCR for residue From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com> [ Upstream commit 847449f23dcbff68234525f90dd53c7c7db18cad ] SYS/RT/Audio DMAC includes independent data buffers for reading and writing. Therefore, the read transfer counter and write transfer counter have different values. TCR indicates read counter, and TCRB indicates write counter. The relationship is like below. TCR TCRB [SOURCE] -> [DMAC] -> [SINK] In the MEM_TO_DEV direction, what really matters is how much data has been written to the device. If the DMA is interrupted between read and write, then, the data doesn't end up in the destination, so shouldn't be counted. TCRB is thus the register we should use in this cases. In the DEV_TO_MEM direction, the situation is more complex. Both the read and write side are important. What matters from a data consumer point of view is how much data has been written to memory. On the other hand, if the transfer is interrupted between read and write, we'll end up losing data. It can also be important to report. In the MEM_TO_MEM direction, what matters is of course how much data has been written to memory from data consumer point of view. Here, because read and write have independent data buffers, it will take a while for TCR and TCRB to become equal. Thus we should check TCRB in this case, too. Thus, all cases we should check TCRB instead of TCR. Without this patch, Sound Capture has noise after PluseAudio support (= 07b7acb51d2 ("ASoC: rsnd: update pointer more accurate")), because the recorder will use wrong residue counter which indicates transferred from sound device, but in reality the data was not yet put to memory and recorder will record it. Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com> [Kuninori: added detail information in log] Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma/sh/rcar-dmac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/dma/sh/rcar-dmac.c +++ b/drivers/dma/sh/rcar-dmac.c @@ -1289,7 +1289,7 @@ static unsigned int rcar_dmac_chan_get_r } /* Add the residue for the current chunk. */ - residue += rcar_dmac_chan_read(chan, RCAR_DMATCR) << desc->xfer_shift; + residue += rcar_dmac_chan_read(chan, RCAR_DMATCRB) << desc->xfer_shift; return residue; } Patches currently in stable-queue which might be from hiroyuki.yokoyama.vx(a)renesas.com are queue-4.9/dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch queue-4.9/asoc-rcar-clear-de-bit-only-in-pdmachcr-when-it-stops.patch queue-4.9/asoc-rsnd-fix-sound-route-path-when-using-src6-src9.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "dmaengine: Fix array index out of bounds warning in __get_unmap_pool()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dmaengine: Fix array index out of bounds warning in __get_unmap_pool() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dmaengine-fix-array-index-out-of-bounds-warning-in-__get_unmap_pool.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:34 CET 2017 From: Matthias Kaehlcke <mka(a)chromium.org> Date: Mon, 13 Mar 2017 14:30:29 -0700 Subject: dmaengine: Fix array index out of bounds warning in __get_unmap_pool() From: Matthias Kaehlcke <mka(a)chromium.org> [ Upstream commit 23f963e91fd81f44f6b316b1c24db563354c6be8 ] This fixes the following warning when building with clang and CONFIG_DMA_ENGINE_RAID=n : drivers/dma/dmaengine.c:1102:11: error: array index 2 is past the end of the array (which contains 1 element) [-Werror,-Warray-bounds] return &unmap_pool[2]; ^ ~ drivers/dma/dmaengine.c:1083:1: note: array 'unmap_pool' declared here static struct dmaengine_unmap_pool unmap_pool[] = { ^ drivers/dma/dmaengine.c:1104:11: error: array index 3 is past the end of the array (which contains 1 element) [-Werror,-Warray-bounds] return &unmap_pool[3]; ^ ~ drivers/dma/dmaengine.c:1083:1: note: array 'unmap_pool' declared here static struct dmaengine_unmap_pool unmap_pool[] = { Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org> Reviewed-by: Dan Williams <dan.j.williams(a)intel.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma/dmaengine.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/dma/dmaengine.c +++ b/drivers/dma/dmaengine.c @@ -1107,12 +1107,14 @@ static struct dmaengine_unmap_pool *__ge switch (order) { case 0 ... 1: return &unmap_pool[0]; +#if IS_ENABLED(CONFIG_DMA_ENGINE_RAID) case 2 ... 4: return &unmap_pool[1]; case 5 ... 7: return &unmap_pool[2]; case 8: return &unmap_pool[3]; +#endif default: BUG(); return NULL; Patches currently in stable-queue which might be from mka(a)chromium.org are queue-4.9/bluetooth-btusb-driver-to-enable-the-usb-wakeup-feature.patch queue-4.9/dmaengine-fix-array-index-out-of-bounds-warning-in-__get_unmap_pool.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: tcrypt - fix buffer lengths in test_aead_speed()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: tcrypt - fix buffer lengths in test_aead_speed() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-tcrypt-fix-buffer-lengths-in-test_aead_speed.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:35 CET 2017 From: Robert Baronescu <robert.baronescu(a)nxp.com> Date: Tue, 10 Oct 2017 13:22:00 +0300 Subject: crypto: tcrypt - fix buffer lengths in test_aead_speed() From: Robert Baronescu <robert.baronescu(a)nxp.com> [ Upstream commit 7aacbfcb331ceff3ac43096d563a1f93ed46e35e ] Fix the way the length of the buffers used for encryption / decryption are computed. For e.g. in case of encryption, input buffer does not contain an authentication tag. Signed-off-by: Robert Baronescu <robert.baronescu(a)nxp.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/tcrypt.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/crypto/tcrypt.c +++ b/crypto/tcrypt.c @@ -342,7 +342,7 @@ static void test_aead_speed(const char * } sg_init_aead(sg, xbuf, - *b_size + (enc ? authsize : 0)); + *b_size + (enc ? 0 : authsize)); sg_init_aead(sgout, xoutbuf, *b_size + (enc ? authsize : 0)); @@ -350,7 +350,9 @@ static void test_aead_speed(const char * sg_set_buf(&sg[0], assoc, aad_size); sg_set_buf(&sgout[0], assoc, aad_size); - aead_request_set_crypt(req, sg, sgout, *b_size, iv); + aead_request_set_crypt(req, sg, sgout, + *b_size + (enc ? 0 : authsize), + iv); aead_request_set_ad(req, aad_size); if (secs) Patches currently in stable-queue which might be from robert.baronescu(a)nxp.com are queue-4.9/crypto-tcrypt-fix-buffer-lengths-in-test_aead_speed.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: tegra: Fix cclk_lp divisor register" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: tegra: Fix cclk_lp divisor register to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-tegra-fix-cclk_lp-divisor-register.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:35 CET 2017 From: Michał Mirosław <mirq-linux(a)rere.qmqm.pl> Date: Tue, 19 Sep 2017 04:48:10 +0200 Subject: clk: tegra: Fix cclk_lp divisor register From: Michał Mirosław <mirq-linux(a)rere.qmqm.pl> [ Upstream commit 54eff2264d3e9fd7e3987de1d7eba1d3581c631e ] According to comments in code and common sense, cclk_lp uses its own divisor, not cclk_g's. Fixes: b08e8c0ecc42 ("clk: tegra: add clock support for Tegra30") Signed-off-by: Michał Mirosław <mirq-linux(a)rere.qmqm.pl> Acked-By: Peter De Schrijver <pdeschrijver(a)nvidia.com> Signed-off-by: Thierry Reding <treding(a)nvidia.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/tegra/clk-tegra30.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/clk/tegra/clk-tegra30.c +++ b/drivers/clk/tegra/clk-tegra30.c @@ -963,7 +963,7 @@ static void __init tegra30_super_clk_ini * U71 divider of cclk_lp. */ clk = tegra_clk_register_divider("pll_p_out3_cclklp", "pll_p_out3", - clk_base + SUPER_CCLKG_DIVIDER, 0, + clk_base + SUPER_CCLKLP_DIVIDER, 0, TEGRA_DIVIDER_INT, 16, 8, 1, NULL); clk_register_clkdev(clk, "pll_p_out3_cclklp", NULL); Patches currently in stable-queue which might be from mirq-linux(a)rere.qmqm.pl are queue-4.9/clk-tegra-fix-cclk_lp-divisor-register.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: mediatek: add the option for determining PLL source clock" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: mediatek: add the option for determining PLL source clock to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-mediatek-add-the-option-for-determining-pll-source-clock.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:35 CET 2017 From: Chen Zhong <chen.zhong(a)mediatek.com> Date: Thu, 5 Oct 2017 11:50:23 +0800 Subject: clk: mediatek: add the option for determining PLL source clock From: Chen Zhong <chen.zhong(a)mediatek.com> [ Upstream commit c955bf3998efa3355790a4d8c82874582f1bc727 ] Since the previous setup always sets the PLL using crystal 26MHz, this doesn't always happen in every MediaTek platform. So the patch added flexibility for assigning extra member for determining the PLL source clock. Signed-off-by: Chen Zhong <chen.zhong(a)mediatek.com> Signed-off-by: Sean Wang <sean.wang(a)mediatek.com> Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/mediatek/clk-mtk.h | 1 + drivers/clk/mediatek/clk-pll.c | 5 ++++- 2 files changed, 5 insertions(+), 1 deletion(-) --- a/drivers/clk/mediatek/clk-mtk.h +++ b/drivers/clk/mediatek/clk-mtk.h @@ -185,6 +185,7 @@ struct mtk_pll_data { uint32_t pcw_reg; int pcw_shift; const struct mtk_pll_div_table *div_table; + const char *parent_name; }; void mtk_clk_register_plls(struct device_node *node, --- a/drivers/clk/mediatek/clk-pll.c +++ b/drivers/clk/mediatek/clk-pll.c @@ -302,7 +302,10 @@ static struct clk *mtk_clk_register_pll( init.name = data->name; init.ops = &mtk_pll_ops; - init.parent_names = &parent_name; + if (data->parent_name) + init.parent_names = &data->parent_name; + else + init.parent_names = &parent_name; init.num_parents = 1; clk = clk_register(NULL, &pll->hw); Patches currently in stable-queue which might be from chen.zhong(a)mediatek.com are queue-4.9/clk-mediatek-add-the-option-for-determining-pll-source-clock.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: imx6: refine hdmi_isfr's parent to make HDMI work on i.MX6 SoCs w/o VPU" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: imx6: refine hdmi_isfr's parent to make HDMI work on i.MX6 SoCs w/o VPU to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-imx6-refine-hdmi_isfr-s-parent-to-make-hdmi-work-on-i.mx6-socs-w-o-vpu.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:35 CET 2017 From: Sébastien Szymanski <sebastien.szymanski(a)armadeus.com> Date: Tue, 1 Aug 2017 12:40:07 +0200 Subject: clk: imx6: refine hdmi_isfr's parent to make HDMI work on i.MX6 SoCs w/o VPU From: Sébastien Szymanski <sebastien.szymanski(a)armadeus.com> [ Upstream commit c68ee58d9ee7b856ac722f18f4f26579c8fbd2b4 ] On i.MX6 SoCs without VPU (in my case MCIMX6D4AVT10AC), the hdmi driver fails to probe: [ 2.540030] dwhdmi-imx 120000.hdmi: Unsupported HDMI controller (0000:00:00) [ 2.548199] imx-drm display-subsystem: failed to bind 120000.hdmi (ops dw_hdmi_imx_ops): -19 [ 2.557403] imx-drm display-subsystem: master bind failed: -19 That's because hdmi_isfr's parent, video_27m, is not correctly ungated. As explained in commit 5ccc248cc537 ("ARM: imx6q: clk: Add support for mipi_core_cfg clock as a shared clock gate"), video_27m is gated by CCM_CCGR3[CG8]. On i.MX6 SoCs with VPU, the hdmi is working thanks to the CCM_CMEOR[mod_en_ov_vpu] bit which makes the video_27m ungated whatever is in CCM_CCGR3[CG8]. The issue can be reproduced by setting CCMEOR[mod_en_ov_vpu] to 0. Make the HDMI work in every case by setting hdmi_isfr's parent to mipi_core_cfg. Signed-off-by: SÃ©bastien Szymanski <sebastien.szymanski(a)armadeus.com> Reviewed-by: Fabio Estevam <fabio.estevam(a)nxp.com> Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/imx/clk-imx6q.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/clk/imx/clk-imx6q.c +++ b/drivers/clk/imx/clk-imx6q.c @@ -487,7 +487,7 @@ static void __init imx6q_clocks_init(str clk[IMX6QDL_CLK_GPU2D_CORE] = imx_clk_gate2("gpu2d_core", "gpu2d_core_podf", base + 0x6c, 24); clk[IMX6QDL_CLK_GPU3D_CORE] = imx_clk_gate2("gpu3d_core", "gpu3d_core_podf", base + 0x6c, 26); clk[IMX6QDL_CLK_HDMI_IAHB] = imx_clk_gate2("hdmi_iahb", "ahb", base + 0x70, 0); - clk[IMX6QDL_CLK_HDMI_ISFR] = imx_clk_gate2("hdmi_isfr", "video_27m", base + 0x70, 4); + clk[IMX6QDL_CLK_HDMI_ISFR] = imx_clk_gate2("hdmi_isfr", "mipi_core_cfg", base + 0x70, 4); clk[IMX6QDL_CLK_I2C1] = imx_clk_gate2("i2c1", "ipg_per", base + 0x70, 6); clk[IMX6QDL_CLK_I2C2] = imx_clk_gate2("i2c2", "ipg_per", base + 0x70, 8); clk[IMX6QDL_CLK_I2C3] = imx_clk_gate2("i2c3", "ipg_per", base + 0x70, 10); Patches currently in stable-queue which might be from sebastien.szymanski(a)armadeus.com are queue-4.9/clk-imx6-refine-hdmi_isfr-s-parent-to-make-hdmi-work-on-i.mx6-socs-w-o-vpu.patch queue-4.9/hid-cp2112-fix-broken-gpio_direction_input-callback.patch

7 years, 8 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: hi6220: mark clock cs_atb_syspll as critical" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: hi6220: mark clock cs_atb_syspll as critical to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: clk-hi6220-mark-clock-cs_atb_syspll-as-critical.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Dec 18 14:12:35 CET 2017 From: Leo Yan <leo.yan(a)linaro.org> Date: Fri, 1 Sep 2017 08:47:14 +0800 Subject: clk: hi6220: mark clock cs_atb_syspll as critical From: Leo Yan <leo.yan(a)linaro.org> [ Upstream commit d2a3671ebe6479483a12f94fcca63c058d95ad64 ] Clock cs_atb_syspll is pll used for coresight trace bus; when clock cs_atb_syspll is disabled and operates its child clock node cs_atb results in system hang. So mark clock cs_atb_syspll as critical to keep it enabled. Cc: Guodong Xu <guodong.xu(a)linaro.org> Cc: Zhangfei Gao <zhangfei.gao(a)linaro.org> Cc: Haojian Zhuang <haojian.zhuang(a)linaro.org> Signed-off-by: Leo Yan <leo.yan(a)linaro.org> Signed-off-by: Michael Turquette <mturquette(a)baylibre.com> Link: lkml.kernel.org/r/1504226835-2115-2-git-send-email-leo.yan@linaro.org Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/hisilicon/clk-hi6220.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/clk/hisilicon/clk-hi6220.c +++ b/drivers/clk/hisilicon/clk-hi6220.c @@ -144,7 +144,7 @@ static struct hisi_gate_clock hi6220_sep { HI6220_BBPPLL_SEL, "bbppll_sel", "pll0_bbp_gate", CLK_SET_RATE_PARENT|CLK_IGNORE_UNUSED, 0x270, 9, 0, }, { HI6220_MEDIA_PLL_SRC, "media_pll_src", "pll_media_gate", CLK_SET_RATE_PARENT|CLK_IGNORE_UNUSED, 0x270, 10, 0, }, { HI6220_MMC2_SEL, "mmc2_sel", "mmc2_mux1", CLK_SET_RATE_PARENT|CLK_IGNORE_UNUSED, 0x270, 11, 0, }, - { HI6220_CS_ATB_SYSPLL, "cs_atb_syspll", "syspll", CLK_SET_RATE_PARENT|CLK_IGNORE_UNUSED, 0x270, 12, 0, }, + { HI6220_CS_ATB_SYSPLL, "cs_atb_syspll", "syspll", CLK_SET_RATE_PARENT|CLK_IS_CRITICAL, 0x270, 12, 0, }, }; static struct hisi_mux_clock hi6220_mux_clks_sys[] __initdata = { Patches currently in stable-queue which might be from leo.yan(a)linaro.org are queue-4.9/thermal-drivers-step_wise-fix-temperature-regulation-misbehavior.patch queue-4.9/clk-hi6220-mark-clock-cs_atb_syspll-as-critical.patch

7 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror