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

Patch "of: fix of_device_get_modalias returned length when truncating buffers" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled of: fix of_device_get_modalias returned length when truncating buffers to the 3.18-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: of-fix-of_device_get_modalias-returned-length-when-truncating-buffers.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Rob Herring <robh(a)kernel.org> Date: Mon, 16 Jan 2017 14:28:39 -0600 Subject: of: fix of_device_get_modalias returned length when truncating buffers From: Rob Herring <robh(a)kernel.org> [ Upstream commit bcf54d5385abaea9c8026aae6f4eeb348671a52d ] If the length of the modalias is greater than the buffer size, then the modalias is truncated. However the untruncated length is returned which will cause an error. Fix this to return the truncated length. If an error in the case was desired, then then we should just return -ENOMEM. The reality is no device will ever have 4KB of compatible strings to hit this case. Signed-off-by: Rob Herring <robh(a)kernel.org> Cc: Frank Rowand <frowand.list(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/of/device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/of/device.c +++ b/drivers/of/device.c @@ -126,7 +126,7 @@ ssize_t of_device_get_modalias(struct de str[i] = '_'; } - return tsize; + return repend; } EXPORT_SYMBOL_GPL(of_device_get_modalias); Patches currently in stable-queue which might be from robh(a)kernel.org are queue-3.18/of-fix-of_device_get_modalias-returned-length-when-truncating-buffers.patch

7 years, 9 months

1
0
0 0

Patch "net: mvpp2: set dma mask and coherent dma mask on PPv2.2" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: mvpp2: set dma mask and coherent dma mask on PPv2.2 to the 3.18-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: net-mvpp2-set-dma-mask-and-coherent-dma-mask-on-ppv2.2.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com> Date: Tue, 7 Mar 2017 16:53:19 +0100 Subject: net: mvpp2: set dma mask and coherent dma mask on PPv2.2 From: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com> [ Upstream commit 2067e0a13cfe0b1bdca7b91bc5e4f2740b07d478 ] On PPv2.2, the streaming mappings can be anywhere in the first 40 bits of the physical address space. However, for the coherent mappings, we still need them to be in the first 32 bits of the address space, because all BM pools share a single register to store the high 32 bits of the BM pool address, which means all BM pools must be allocated in the same 4GB memory area. Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/marvell/mvpp2.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/drivers/net/ethernet/marvell/mvpp2.c +++ b/drivers/net/ethernet/marvell/mvpp2.c @@ -6339,6 +6339,20 @@ static int mvpp2_probe(struct platform_d /* Get system's tclk rate */ priv->tclk = clk_get_rate(priv->pp_clk); + if (priv->hw_version == MVPP22) { + err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(40)); + if (err) + goto err_mg_clk; + /* Sadly, the BM pools all share the same register to + * store the high 32 bits of their address. So they + * must all have the same high 32 bits, which forces + * us to restrict coherent memory to DMA_BIT_MASK(32). + */ + err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)); + if (err) + goto err_mg_clk; + } + /* Initialize network controller */ err = mvpp2_init(pdev, priv); if (err < 0) { Patches currently in stable-queue which might be from thomas.petazzoni(a)free-electrons.com are queue-3.18/net-mvpp2-set-dma-mask-and-coherent-dma-mask-on-ppv2.2.patch

7 years, 9 months

1
0
0 0

Patch "net: xfrm: allow clearing socket xfrm policies." has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: xfrm: allow clearing socket xfrm policies. to the 3.18-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: net-xfrm-allow-clearing-socket-xfrm-policies.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Lorenzo Colitti <lorenzo(a)google.com> Date: Mon, 20 Nov 2017 19:26:02 +0900 Subject: net: xfrm: allow clearing socket xfrm policies. From: Lorenzo Colitti <lorenzo(a)google.com> [ Upstream commit be8f8284cd897af2482d4e54fbc2bdfc15557259 ] Currently it is possible to add or update socket policies, but not clear them. Therefore, once a socket policy has been applied, the socket cannot be used for unencrypted traffic. This patch allows (privileged) users to clear socket policies by passing in a NULL pointer and zero length argument to the {IP,IPV6}_{IPSEC,XFRM}_POLICY setsockopts. This results in both the incoming and outgoing policies being cleared. The simple approach taken in this patch cannot clear socket policies in only one direction. If desired this could be added in the future, for example by continuing to pass in a length of zero (which currently is guaranteed to return EMSGSIZE) and making the policy be a pointer to an integer that contains one of the XFRM_POLICY_{IN,OUT} enum values. An alternative would have been to interpret the length as a signed integer and use XFRM_POLICY_IN (i.e., 0) to clear the input policy and -XFRM_POLICY_OUT (i.e., -1) to clear the output policy. Tested: https://android-review.googlesource.com/539816 Signed-off-by: Lorenzo Colitti <lorenzo(a)google.com> Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/xfrm/xfrm_policy.c | 2 +- net/xfrm/xfrm_state.c | 7 +++++++ 2 files changed, 8 insertions(+), 1 deletion(-) --- a/net/xfrm/xfrm_policy.c +++ b/net/xfrm/xfrm_policy.c @@ -1292,7 +1292,7 @@ EXPORT_SYMBOL(xfrm_policy_delete); int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol) { - struct net *net = xp_net(pol); + struct net *net = sock_net(sk); struct xfrm_policy *old_pol; #ifdef CONFIG_XFRM_SUB_POLICY --- a/net/xfrm/xfrm_state.c +++ b/net/xfrm/xfrm_state.c @@ -1845,6 +1845,13 @@ int xfrm_user_policy(struct sock *sk, in struct xfrm_mgr *km; struct xfrm_policy *pol = NULL; + if (!optval && !optlen) { + xfrm_sk_policy_insert(sk, XFRM_POLICY_IN, NULL); + xfrm_sk_policy_insert(sk, XFRM_POLICY_OUT, NULL); + __sk_dst_reset(sk); + return 0; + } + if (optlen <= 0 || optlen > PAGE_SIZE) return -EMSGSIZE; Patches currently in stable-queue which might be from lorenzo(a)google.com are queue-3.18/net-xfrm-allow-clearing-socket-xfrm-policies.patch

7 years, 9 months

1
0
0 0

Patch "net/faraday: Add missing include of of.h" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net/faraday: Add missing include of of.h to the 3.18-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: net-faraday-add-missing-include-of-of.h.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Andrew Lunn <andrew(a)lunn.ch> Date: Sun, 2 Apr 2017 20:20:47 +0200 Subject: net/faraday: Add missing include of of.h From: Andrew Lunn <andrew(a)lunn.ch> [ Upstream commit d39004ab136ebb6949a7dda9d24376f3d6209295 ] Breaking the include loop netdevice.h, dsa.h, devlink.h broke this driver, it depends on includes brought in by these headers. Adding linux/of.h fixes it. Fixes: ed0e39e97d34 ("net: break include loop netdevice.h, dsa.h, devlink.h") Signed-off-by: Andrew Lunn <andrew(a)lunn.ch> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/faraday/ftgmac100.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/ethernet/faraday/ftgmac100.c +++ b/drivers/net/ethernet/faraday/ftgmac100.c @@ -28,6 +28,7 @@ #include <linux/io.h> #include <linux/module.h> #include <linux/netdevice.h> +#include <linux/of.h> #include <linux/phy.h> #include <linux/platform_device.h> #include <net/ip.h> Patches currently in stable-queue which might be from andrew(a)lunn.ch are queue-3.18/net-faraday-add-missing-include-of-of.h.patch

7 years, 9 months

1
0
0 0

Patch "mtd: nand: ifc: update bufnum mask for ver >= 2.0.0" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mtd: nand: ifc: update bufnum mask for ver >= 2.0.0 to the 3.18-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: mtd-nand-ifc-update-bufnum-mask-for-ver-2.0.0.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Jagdish Gediya <jagdish.gediya(a)nxp.com> Date: Thu, 23 Nov 2017 17:04:31 +0530 Subject: mtd: nand: ifc: update bufnum mask for ver >= 2.0.0 From: Jagdish Gediya <jagdish.gediya(a)nxp.com> [ Upstream commit bccb06c353af3764ca86d9da47652458e6c2eb41 ] Bufnum mask is used to calculate page position in the internal SRAM. As IFC version 2.0.0 has 16KB of internal SRAM as compared to older versions which had 8KB. Hence bufnum mask needs to be updated. Signed-off-by: Jagdish Gediya <jagdish.gediya(a)nxp.com> Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha(a)nxp.com> Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mtd/nand/fsl_ifc_nand.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/mtd/nand/fsl_ifc_nand.c +++ b/drivers/mtd/nand/fsl_ifc_nand.c @@ -988,6 +988,13 @@ static int fsl_ifc_chip_init(struct fsl_ if (ver == FSL_IFC_V1_1_0) fsl_ifc_sram_init(priv); + /* + * As IFC version 2.0.0 has 16KB of internal SRAM as compared to older + * versions which had 8KB. Hence bufnum mask needs to be updated. + */ + if (ctrl->version >= FSL_IFC_VERSION_2_0_0) + priv->bufnum_mask = (priv->bufnum_mask * 2) + 1; + return 0; } Patches currently in stable-queue which might be from jagdish.gediya(a)nxp.com are queue-3.18/mtd-nand-ifc-update-bufnum-mask-for-ver-2.0.0.patch

7 years, 9 months

1
0
0 0

Patch "mtd: nand: fix interpretation of NAND_CMD_NONE in nand_command[_lp]()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mtd: nand: fix interpretation of NAND_CMD_NONE in nand_command[_lp]() to the 3.18-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: mtd-nand-fix-interpretation-of-nand_cmd_none-in-nand_command.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Miquel Raynal <miquel.raynal(a)free-electrons.com> Date: Wed, 8 Nov 2017 17:00:27 +0100 Subject: mtd: nand: fix interpretation of NAND_CMD_NONE in nand_command[_lp]() From: Miquel Raynal <miquel.raynal(a)free-electrons.com> [ Upstream commit df467899da0b71465760b4e35127bce837244eee ] Some drivers (like nand_hynix.c) call ->cmdfunc() with NAND_CMD_NONE and a column address and expect the controller to only send address cycles. Right now, the default ->cmdfunc() implementations provided by the core do not filter out the command cycle in this case and forwards the request to the controller driver through the ->cmd_ctrl() method. The thing is, NAND controller drivers can get this wrong and send a command cycle with a NAND_CMD_NONE opcode and since NAND_CMD_NONE is -1, and the command field is usually casted to an u8, we end up sending the 0xFF command which is actually a RESET operation. Add conditions in nand_command[_lp]() functions to sending the initial command cycle when command == NAND_CMD_NONE. Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com> Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mtd/nand/nand_base.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -600,7 +600,8 @@ static void nand_command(struct mtd_info chip->cmd_ctrl(mtd, readcmd, ctrl); ctrl &= ~NAND_CTRL_CHANGE; } - chip->cmd_ctrl(mtd, command, ctrl); + if (command != NAND_CMD_NONE) + chip->cmd_ctrl(mtd, command, ctrl); /* Address cycle, when necessary */ ctrl = NAND_CTRL_ALE | NAND_CTRL_CHANGE; @@ -629,6 +630,7 @@ static void nand_command(struct mtd_info */ switch (command) { + case NAND_CMD_NONE: case NAND_CMD_PAGEPROG: case NAND_CMD_ERASE1: case NAND_CMD_ERASE2: @@ -691,7 +693,9 @@ static void nand_command_lp(struct mtd_i } /* Command latch cycle */ - chip->cmd_ctrl(mtd, command, NAND_NCE | NAND_CLE | NAND_CTRL_CHANGE); + if (command != NAND_CMD_NONE) + chip->cmd_ctrl(mtd, command, + NAND_NCE | NAND_CLE | NAND_CTRL_CHANGE); if (column != -1 || page_addr != -1) { int ctrl = NAND_CTRL_CHANGE | NAND_NCE | NAND_ALE; @@ -724,6 +728,7 @@ static void nand_command_lp(struct mtd_i */ switch (command) { + case NAND_CMD_NONE: case NAND_CMD_CACHEDPROG: case NAND_CMD_PAGEPROG: case NAND_CMD_ERASE1: Patches currently in stable-queue which might be from miquel.raynal(a)free-electrons.com are queue-3.18/mtd-nand-fix-interpretation-of-nand_cmd_none-in-nand_command.patch

7 years, 9 months

1
0
0 0

Patch "mm: Fix false-positive VM_BUG_ON() in page_cache_{get, add}_speculative()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm: Fix false-positive VM_BUG_ON() in page_cache_{get,add}_speculative() to the 3.18-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: mm-fix-false-positive-vm_bug_on-in-page_cache_-get-add-_speculative.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Date: Fri, 24 Mar 2017 14:13:05 +0300 Subject: mm: Fix false-positive VM_BUG_ON() in page_cache_{get,add}_speculative() From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> [ Upstream commit 591a3d7c09fa08baff48ad86c2347dbd28a52753 ] 0day testing by Fengguang Wu triggered this crash while running Trinity: kernel BUG at include/linux/pagemap.h:151! ... CPU: 0 PID: 458 Comm: trinity-c0 Not tainted 4.11.0-rc2-00251-g2947ba0 #1 ... Call Trace: __get_user_pages_fast() get_user_pages_fast() get_futex_key() futex_requeue() do_futex() SyS_futex() do_syscall_64() entry_SYSCALL64_slow_path() It' VM_BUG_ON() due to false-negative in_atomic(). We call page_cache_get_speculative() with disabled local interrupts. It should be atomic enough. So let's check for disabled interrupts in the VM_BUG_ON() condition too, to resolve this. ( This got triggered by the conversion of the x86 GUP code to the generic GUP code. ) Reported-by: Fengguang Wu <fengguang.wu(a)intel.com> Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Aneesh Kumar K.V <aneesh.kumar(a)linux.vnet.ibm.com> Cc: Kirill A. Shutemov <kirill(a)shutemov.name> Cc: LKP <lkp(a)01.org> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: linux-mm(a)kvack.org Link: http://lkml.kernel.org/r/20170324114709.pcytvyb3d6ajux33@black.fi.intel.com Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/pagemap.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/include/linux/pagemap.h +++ b/include/linux/pagemap.h @@ -146,7 +146,7 @@ static inline int page_cache_get_specula #ifdef CONFIG_TINY_RCU # ifdef CONFIG_PREEMPT_COUNT - VM_BUG_ON(!in_atomic()); + VM_BUG_ON(!in_atomic() && !irqs_disabled()); # endif /* * Preempt must be disabled here - we rely on rcu_read_lock doing @@ -184,7 +184,7 @@ static inline int page_cache_add_specula #if !defined(CONFIG_SMP) && defined(CONFIG_TREE_RCU) # ifdef CONFIG_PREEMPT_COUNT - VM_BUG_ON(!in_atomic()); + VM_BUG_ON(!in_atomic() && !irqs_disabled()); # endif VM_BUG_ON_PAGE(page_count(page) == 0, page); atomic_add(count, &page->_count); Patches currently in stable-queue which might be from kirill.shutemov(a)linux.intel.com are queue-3.18/mm-fix-false-positive-vm_bug_on-in-page_cache_-get-add-_speculative.patch

7 years, 9 months

1
0
0 0

Patch "[media] media: i2c/soc_camera: fix ov6650 sensor getting wrong clock" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled [media] media: i2c/soc_camera: fix ov6650 sensor getting wrong clock to the 3.18-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: media-i2c-soc_camera-fix-ov6650-sensor-getting-wrong-clock.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Janusz Krzysztofik <jmkrzyszt(a)gmail.com> Date: Wed, 15 Jun 2016 19:29:50 -0300 Subject: [media] media: i2c/soc_camera: fix ov6650 sensor getting wrong clock From: Janusz Krzysztofik <jmkrzyszt(a)gmail.com> [ Upstream commit 54449af0e0b2ea43a8166611c95b730c850c3184 ] After changes to v4l2_clk API introduced in v4.1 by commits a37462b919 '[media] V4L: remove clock name from v4l2_clk API' and 4f528afcfb '[media] V4L: add CCF support to the v4l2_clk API', ov6650 sensor stopped responding because v4l2_clk_get(), still called with depreciated V4L2 clock name "mclk", started to return respective CCF clock instead of the V4l2 one registered by soc_camera. Fix it by calling v4l2_clk_get() with NULL clock name. Created and tested on Amstrad Delta against Linux-4.7-rc3 with omap1_camera fixes. Signed-off-by: Janusz Krzysztofik <jmkrzyszt(a)gmail.com> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski(a)gmx.de> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/i2c/soc_camera/ov6650.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/media/i2c/soc_camera/ov6650.c +++ b/drivers/media/i2c/soc_camera/ov6650.c @@ -1016,7 +1016,7 @@ static int ov6650_probe(struct i2c_clien priv->code = V4L2_MBUS_FMT_YUYV8_2X8; priv->colorspace = V4L2_COLORSPACE_JPEG; - priv->clk = v4l2_clk_get(&client->dev, "mclk"); + priv->clk = v4l2_clk_get(&client->dev, NULL); if (IS_ERR(priv->clk)) { ret = PTR_ERR(priv->clk); goto eclkget; Patches currently in stable-queue which might be from jmkrzyszt(a)gmail.com are queue-3.18/media-i2c-soc_camera-fix-ov6650-sensor-getting-wrong-clock.patch

7 years, 9 months

1
0
0 0

Patch "MIPS: BPF: Quit clobbering callee saved registers in JIT code." has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: BPF: Quit clobbering callee saved registers in JIT code. to the 3.18-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: mips-bpf-quit-clobbering-callee-saved-registers-in-jit-code.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: David Daney <david.daney(a)cavium.com> Date: Tue, 14 Mar 2017 14:21:43 -0700 Subject: MIPS: BPF: Quit clobbering callee saved registers in JIT code. From: David Daney <david.daney(a)cavium.com> [ Upstream commit 1ef0910cfd681f0bd0b81f8809935b2006e9cfb9 ] If bpf_needs_clear_a() returns true, only actually clear it if it is ever used. If it is not used, we don't save and restore it, so the clearing has the nasty side effect of clobbering caller state. Also, don't emit stack pointer adjustment instructions if the adjustment amount is zero. Signed-off-by: David Daney <david.daney(a)cavium.com> Cc: James Hogan <james.hogan(a)imgtec.com> Cc: Alexei Starovoitov <ast(a)kernel.org> Cc: Steven J. Hill <steven.hill(a)cavium.com> Cc: linux-mips(a)linux-mips.org Cc: netdev(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/15745/ Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/net/bpf_jit.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) --- a/arch/mips/net/bpf_jit.c +++ b/arch/mips/net/bpf_jit.c @@ -562,7 +562,8 @@ static void save_bpf_jit_regs(struct jit u32 sflags, tmp_flags; /* Adjust the stack pointer */ - emit_stack_offset(-align_sp(offset), ctx); + if (offset) + emit_stack_offset(-align_sp(offset), ctx); if (ctx->flags & SEEN_CALL) { /* Argument save area */ @@ -641,7 +642,8 @@ static void restore_bpf_jit_regs(struct emit_load_stack_reg(r_ra, r_sp, real_off, ctx); /* Restore the sp and discard the scrach memory */ - emit_stack_offset(align_sp(offset), ctx); + if (offset) + emit_stack_offset(align_sp(offset), ctx); } static unsigned int get_stack_depth(struct jit_ctx *ctx) @@ -689,8 +691,14 @@ static void build_prologue(struct jit_ct if (ctx->flags & SEEN_X) emit_jit_reg_move(r_X, r_zero, ctx); - /* Do not leak kernel data to userspace */ - if (bpf_needs_clear_a(&ctx->skf->insns[0])) + /* + * Do not leak kernel data to userspace, we only need to clear + * r_A if it is ever used. In fact if it is never used, we + * will not save/restore it, so clearing it in this case would + * corrupt the state of the caller. + */ + if (bpf_needs_clear_a(&ctx->skf->insns[0]) && + (ctx->flags & SEEN_A)) emit_jit_reg_move(r_A, r_zero, ctx); } Patches currently in stable-queue which might be from david.daney(a)cavium.com are queue-3.18/mips-bpf-quit-clobbering-callee-saved-registers-in-jit-code.patch

7 years, 9 months

1
0
0 0

Patch "media: cpia2: Fix a couple off by one bugs" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: cpia2: Fix a couple off by one bugs to the 3.18-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: media-cpia2-fix-a-couple-off-by-one-bugs.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Thu, 9 Nov 2017 16:28:14 -0500 Subject: media: cpia2: Fix a couple off by one bugs From: Dan Carpenter <dan.carpenter(a)oracle.com> [ Upstream commit d5ac225c7d64c9c3ef821239edc035634e594ec9 ] The cam->buffers[] array has cam->num_frames elements so the > needs to be changed to >= to avoid going beyond the end of the array. The ->buffers[] array is allocated in cpia2_allocate_buffers() if you want to confirm. Fixes: ab33d5071de7 ("V4L/DVB (3376): Add cpia2 camera support") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/usb/cpia2/cpia2_v4l.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/media/usb/cpia2/cpia2_v4l.c +++ b/drivers/media/usb/cpia2/cpia2_v4l.c @@ -812,7 +812,7 @@ static int cpia2_querybuf(struct file *f struct camera_data *cam = video_drvdata(file); if(buf->type != V4L2_BUF_TYPE_VIDEO_CAPTURE || - buf->index > cam->num_frames) + buf->index >= cam->num_frames) return -EINVAL; buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer; @@ -863,7 +863,7 @@ static int cpia2_qbuf(struct file *file, if(buf->type != V4L2_BUF_TYPE_VIDEO_CAPTURE || buf->memory != V4L2_MEMORY_MMAP || - buf->index > cam->num_frames) + buf->index >= cam->num_frames) return -EINVAL; DBG("QBUF #%d\n", buf->index); Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are queue-3.18/media-cpia2-fix-a-couple-off-by-one-bugs.patch queue-3.18/asoc-nuc900-fix-a-loop-timeout-test.patch

7 years, 9 months

1
0
0 0

Patch "mac80211: remove BUG() when interface type is invalid" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mac80211: remove BUG() when interface type is invalid to the 3.18-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: mac80211-remove-bug-when-interface-type-is-invalid.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Luca Coelho <luciano.coelho(a)intel.com> Date: Sun, 29 Oct 2017 11:51:10 +0200 Subject: mac80211: remove BUG() when interface type is invalid From: Luca Coelho <luciano.coelho(a)intel.com> [ Upstream commit c7976f5272486e4ff406014c4b43e2fa3b70b052 ] In the ieee80211_setup_sdata() we check if the interface type is valid and, if not, call BUG(). This should never happen, but if there is something wrong with the code, it will not be caught until the bug happens when an interface is being set up. Calling BUG() is too extreme for this and a WARN_ON() would be better used instead. Change that. Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mac80211/iface.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/mac80211/iface.c +++ b/net/mac80211/iface.c @@ -1379,7 +1379,7 @@ static void ieee80211_setup_sdata(struct break; case NL80211_IFTYPE_UNSPECIFIED: case NUM_NL80211_IFTYPES: - BUG(); + WARN_ON(1); break; } Patches currently in stable-queue which might be from luciano.coelho(a)intel.com are queue-3.18/mac80211-remove-bug-when-interface-type-is-invalid.patch

7 years, 9 months

1
0
0 0

Patch "kprobes/x86: Set kprobes pages read-only" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kprobes/x86: Set kprobes pages read-only to the 3.18-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: kprobes-x86-set-kprobes-pages-read-only.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Masami Hiramatsu <mhiramat(a)kernel.org> Date: Wed, 29 Mar 2017 14:02:46 +0900 Subject: kprobes/x86: Set kprobes pages read-only From: Masami Hiramatsu <mhiramat(a)kernel.org> [ Upstream commit d0381c81c2f782fa2131178d11e0cfb23d50d631 ] Set the pages which is used for kprobes' singlestep buffer and optprobe's trampoline instruction buffer to readonly. This can prevent unexpected (or unintended) instruction modification. This also passes rodata_test as below. Without this patch, rodata_test shows a warning: WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:235 note_page+0x7a9/0xa20 x86/mm: Found insecure W+X mapping at address ffffffffa0000000/0xffffffffa0000000 With this fix, no W+X pages are found: x86/mm: Checked W+X mappings: passed, no W+X pages found. rodata_test: all tests were successful Reported-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Ananth N Mavinakayanahalli <ananth(a)linux.vnet.ibm.com> Cc: Anil S Keshavamurthy <anil.s.keshavamurthy(a)intel.com> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: David S . Miller <davem(a)davemloft.net> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Ye Xiaolong <xiaolong.ye(a)intel.com> Link: http://lkml.kernel.org/r/149076375592.22469.14174394514338612247.stgit@devb… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/kprobes/core.c | 4 ++++ arch/x86/kernel/kprobes/opt.c | 3 +++ 2 files changed, 7 insertions(+) --- a/arch/x86/kernel/kprobes/core.c +++ b/arch/x86/kernel/kprobes/core.c @@ -378,6 +378,8 @@ static int arch_copy_kprobe(struct kprob { int ret; + set_memory_rw((unsigned long)p->ainsn.insn & PAGE_MASK, 1); + /* Copy an instruction with recovering if other optprobe modifies it.*/ ret = __copy_instruction(p->ainsn.insn, p->addr); if (!ret) @@ -392,6 +394,8 @@ static int arch_copy_kprobe(struct kprob else p->ainsn.boostable = -1; + set_memory_ro((unsigned long)p->ainsn.insn & PAGE_MASK, 1); + /* Check whether the instruction modifies Interrupt Flag or not */ p->ainsn.if_modifier = is_IF_modifier(p->ainsn.insn); --- a/arch/x86/kernel/kprobes/opt.c +++ b/arch/x86/kernel/kprobes/opt.c @@ -344,6 +344,7 @@ int arch_prepare_optimized_kprobe(struct } buf = (u8 *)op->optinsn.insn; + set_memory_rw((unsigned long)buf & PAGE_MASK, 1); /* Copy instructions into the out-of-line buffer */ ret = copy_optimized_instructions(buf + TMPL_END_IDX, op->kp.addr); @@ -366,6 +367,8 @@ int arch_prepare_optimized_kprobe(struct synthesize_reljump(buf + TMPL_END_IDX + op->optinsn.size, (u8 *)op->kp.addr + op->optinsn.size); + set_memory_ro((unsigned long)buf & PAGE_MASK, 1); + flush_icache_range((unsigned long) buf, (unsigned long) buf + TMPL_END_IDX + op->optinsn.size + RELATIVEJUMP_SIZE); Patches currently in stable-queue which might be from mhiramat(a)kernel.org are queue-3.18/perf-session-don-t-rely-on-evlist-in-pipe-mode.patch queue-3.18/kprobes-x86-set-kprobes-pages-read-only.patch queue-3.18/kprobes-x86-fix-kprobe-booster-not-to-boost-far-call-instructions.patch queue-3.18/perf-inject-copy-events-when-reordering-events-in-pipe-mode.patch

7 years, 9 months

1
0
0 0

Patch "iommu/iova: Fix underflow bug in __alloc_and_insert_iova_range" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iommu/iova: Fix underflow bug in __alloc_and_insert_iova_range to the 3.18-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: iommu-iova-fix-underflow-bug-in-__alloc_and_insert_iova_range.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Nate Watterson <nwatters(a)codeaurora.org> Date: Fri, 7 Apr 2017 01:36:20 -0400 Subject: iommu/iova: Fix underflow bug in __alloc_and_insert_iova_range From: Nate Watterson <nwatters(a)codeaurora.org> [ Upstream commit 5016bdb796b3726eec043ca0ce3be981f712c756 ] Normally, calling alloc_iova() using an iova_domain with insufficient pfns remaining between start_pfn and dma_limit will fail and return a NULL pointer. Unexpectedly, if such a "full" iova_domain contains an iova with pfn_lo == 0, the alloc_iova() call will instead succeed and return an iova containing invalid pfns. This is caused by an underflow bug in __alloc_and_insert_iova_range() that occurs after walking the "full" iova tree when the search ends at the iova with pfn_lo == 0 and limit_pfn is then adjusted to be just below that (-1). This (now huge) limit_pfn gives the impression that a vast amount of space is available between it and start_pfn and thus a new iova is allocated with the invalid pfn_hi value, 0xFFF.... . To rememdy this, a check is introduced to ensure that adjustments to limit_pfn will not underflow. This issue has been observed in the wild, and is easily reproduced with the following sample code. struct iova_domain *iovad = kzalloc(sizeof(*iovad), GFP_KERNEL); struct iova *rsvd_iova, *good_iova, *bad_iova; unsigned long limit_pfn = 3; unsigned long start_pfn = 1; unsigned long va_size = 2; init_iova_domain(iovad, SZ_4K, start_pfn, limit_pfn); rsvd_iova = reserve_iova(iovad, 0, 0); good_iova = alloc_iova(iovad, va_size, limit_pfn, true); bad_iova = alloc_iova(iovad, va_size, limit_pfn, true); Prior to the patch, this yielded: *rsvd_iova == {0, 0} /* Expected */ *good_iova == {2, 3} /* Expected */ *bad_iova == {-2, -1} /* Oh no... */ After the patch, bad_iova is NULL as expected since inadequate space remains between limit_pfn and start_pfn after allocating good_iova. Signed-off-by: Nate Watterson <nwatters(a)codeaurora.org> Signed-off-by: Joerg Roedel <jroedel(a)suse.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iommu/iova.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/iommu/iova.c +++ b/drivers/iommu/iova.c @@ -118,7 +118,7 @@ static int __alloc_and_insert_iova_range break; /* found a free slot */ } adjust_limit_pfn: - limit_pfn = curr_iova->pfn_lo - 1; + limit_pfn = curr_iova->pfn_lo ? (curr_iova->pfn_lo - 1) : 0; move_left: prev = curr; curr = rb_prev(curr); Patches currently in stable-queue which might be from nwatters(a)codeaurora.org are queue-3.18/iommu-iova-fix-underflow-bug-in-__alloc_and_insert_iova_range.patch

7 years, 9 months

1
0
0 0

Patch "kprobes/x86: Fix kprobe-booster not to boost far call instructions" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kprobes/x86: Fix kprobe-booster not to boost far call instructions to the 3.18-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: kprobes-x86-fix-kprobe-booster-not-to-boost-far-call-instructions.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Masami Hiramatsu <mhiramat(a)kernel.org> Date: Wed, 29 Mar 2017 13:56:56 +0900 Subject: kprobes/x86: Fix kprobe-booster not to boost far call instructions From: Masami Hiramatsu <mhiramat(a)kernel.org> [ Upstream commit bd0b90676c30fe640e7ead919b3e38846ac88ab7 ] Fix the kprobe-booster not to boost far call instruction, because a call may store the address in the single-step execution buffer to the stack, which should be modified after single stepping. Currently, this instruction will be filtered as not boostable in resume_execution(), so this is not a critical issue. Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Ananth N Mavinakayanahalli <ananth(a)linux.vnet.ibm.com> Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Cc: Anil S Keshavamurthy <anil.s.keshavamurthy(a)intel.com> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: David S . Miller <davem(a)davemloft.net> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Ye Xiaolong <xiaolong.ye(a)intel.com> Link: http://lkml.kernel.org/r/149076340615.22469.14066273186134229909.stgit@devb… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/kprobes/core.c | 2 ++ 1 file changed, 2 insertions(+) --- a/arch/x86/kernel/kprobes/core.c +++ b/arch/x86/kernel/kprobes/core.c @@ -196,6 +196,8 @@ retry: return (opcode != 0x62 && opcode != 0x67); case 0x70: return 0; /* can't boost conditional jump */ + case 0x90: + return opcode != 0x9a; /* can't boost call far */ case 0xc0: /* can't boost software-interruptions */ return (0xc1 < opcode && opcode < 0xcc) || opcode == 0xcf; Patches currently in stable-queue which might be from mhiramat(a)kernel.org are queue-3.18/perf-session-don-t-rely-on-evlist-in-pipe-mode.patch queue-3.18/kprobes-x86-set-kprobes-pages-read-only.patch queue-3.18/kprobes-x86-fix-kprobe-booster-not-to-boost-far-call-instructions.patch queue-3.18/perf-inject-copy-events-when-reordering-events-in-pipe-mode.patch

7 years, 9 months

1
0
0 0

Patch "ima: relax requiring a file signature for new files with zero length" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ima: relax requiring a file signature for new files with zero length to the 3.18-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: ima-relax-requiring-a-file-signature-for-new-files-with-zero-length.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Date: Wed, 8 Nov 2017 07:38:28 -0500 Subject: ima: relax requiring a file signature for new files with zero length From: Mimi Zohar <zohar(a)linux.vnet.ibm.com> [ Upstream commit b7e27bc1d42e8e0cc58b602b529c25cd0071b336 ] Custom policies can require file signatures based on LSM labels. These files are normally created and only afterwards labeled, requiring them to be signed. Instead of requiring file signatures based on LSM labels, entire filesystems could require file signatures. In this case, we need the ability of writing new files without requiring file signatures. The definition of a "new" file was originally defined as any file with a length of zero. Subsequent patches redefined a "new" file to be based on the FILE_CREATE open flag. By combining the open flag with a file size of zero, this patch relaxes the file signature requirement. Fixes: 1ac202e978e1 ima: accept previously set IMA_NEW_FILE Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/integrity/ima/ima_appraise.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/security/integrity/ima/ima_appraise.c +++ b/security/integrity/ima/ima_appraise.c @@ -206,7 +206,8 @@ int ima_appraise_measurement(int func, s if (opened & FILE_CREATED) iint->flags |= IMA_NEW_FILE; if ((iint->flags & IMA_NEW_FILE) && - !(iint->flags & IMA_DIGSIG_REQUIRED)) + (!(iint->flags & IMA_DIGSIG_REQUIRED) || + (inode->i_size == 0))) status = INTEGRITY_PASS; goto out; } Patches currently in stable-queue which might be from zohar(a)linux.vnet.ibm.com are queue-3.18/ima-relax-requiring-a-file-signature-for-new-files-with-zero-length.patch

7 years, 9 months

1
0
0 0

Patch "Input: tsc2007 - check for presence and power down tsc2007 during probe" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Input: tsc2007 - check for presence and power down tsc2007 during probe to the 3.18-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-tsc2007-check-for-presence-and-power-down-tsc2007-during-probe.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: "H. Nikolaus Schaller" <hns(a)goldelico.com> Date: Fri, 17 Feb 2017 12:51:19 -0800 Subject: Input: tsc2007 - check for presence and power down tsc2007 during probe From: "H. Nikolaus Schaller" <hns(a)goldelico.com> [ Upstream commit 934df23171e7c5b71d937104d4957891c39748ff ] 1. check if chip is really present and don't succeed if it isn't. 2. if it succeeds, power down the chip until accessed Signed-off-by: H. Nikolaus Schaller <hns(a)goldelico.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/input/touchscreen/tsc2007.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/drivers/input/touchscreen/tsc2007.c +++ b/drivers/input/touchscreen/tsc2007.c @@ -456,6 +456,14 @@ static int tsc2007_probe(struct i2c_clie tsc2007_stop(ts); + /* power down the chip (TSC2007_SETUP does not ACK on I2C) */ + err = tsc2007_xfer(ts, PWRDOWN); + if (err < 0) { + dev_err(&client->dev, + "Failed to setup chip: %d\n", err); + return err; /* usually, chip does not respond */ + } + err = input_register_device(input_dev); if (err) { dev_err(&client->dev, Patches currently in stable-queue which might be from hns(a)goldelico.com are queue-3.18/input-tsc2007-check-for-presence-and-power-down-tsc2007-during-probe.patch

7 years, 9 months

1
0
0 0

Patch "HID: elo: clear BTN_LEFT mapping" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled HID: elo: clear BTN_LEFT mapping to the 3.18-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-elo-clear-btn_left-mapping.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Jiri Kosina <jkosina(a)suse.cz> Date: Wed, 22 Nov 2017 11:19:51 +0100 Subject: HID: elo: clear BTN_LEFT mapping From: Jiri Kosina <jkosina(a)suse.cz> [ Upstream commit 9abd04af951e5734c9d5cfee9b49790844b734cf ] ELO devices have one Button usage in GenDesk field, which makes hid-input map it to BTN_LEFT; that confuses userspace, which then considers the device to be a mouse/touchpad instead of touchscreen. Fix that by unmapping BTN_LEFT and keeping only BTN_TOUCH in place. Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hid/hid-elo.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/hid/hid-elo.c +++ b/drivers/hid/hid-elo.c @@ -42,6 +42,12 @@ static void elo_input_configured(struct { struct input_dev *input = hidinput->input; + /* + * ELO devices have one Button usage in GenDesk field, which makes + * hid-input map it to BTN_LEFT; that confuses userspace, which then + * considers the device to be a mouse/touchpad instead of touchscreen. + */ + clear_bit(BTN_LEFT, input->keybit); set_bit(BTN_TOUCH, input->keybit); set_bit(ABS_PRESSURE, input->absbit); input_set_abs_params(input, ABS_PRESSURE, 0, 256, 0, 0); Patches currently in stable-queue which might be from jkosina(a)suse.cz are queue-3.18/hid-elo-clear-btn_left-mapping.patch queue-3.18/hid-clamp-input-to-logical-range-if-no-null-state.patch queue-3.18/hid-reject-input-outside-logical-range-only-if-null-state-is-set.patch

7 years, 9 months

1
0
0 0

Patch "HID: reject input outside logical range only if null state is set" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled HID: reject input outside logical range only if null state is set to the 3.18-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-reject-input-outside-logical-range-only-if-null-state-is-set.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: "Valtteri Heikkilä" <rnd(a)nic.fi> Date: Tue, 14 Feb 2017 23:14:32 +0000 Subject: HID: reject input outside logical range only if null state is set From: "Valtteri Heikkilä" <rnd(a)nic.fi> [ Upstream commit 3f3752705dbd50b66b66ad7b4d54fe33d2f746ed ] This patch fixes an issue in drivers/hid/hid-input.c where USB HID control null state flag is not checked upon rejecting inputs outside logical minimum-maximum range. The check should be made according to USB HID specification 1.11, section 6.2.2.5, p.31. The fix will resolve issues with some game controllers, such as: https://bugzilla.kernel.org/show_bug.cgi?id=68621 [tk(a)the-tk.com: shortened and fixed spelling in commit message] Signed-off-by: Valtteri HeikkilÃ¤ <rnd(a)nic.fi> Signed-off-by: Tomasz Kramkowski <tk(a)the-tk.com> Acked-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)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hid/hid-input.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/hid/hid-input.c +++ b/drivers/hid/hid-input.c @@ -1097,6 +1097,7 @@ void hidinput_hid_event(struct hid_devic * don't specify logical min and max. */ if ((field->flags & HID_MAIN_ITEM_VARIABLE) && + (field->flags & HID_MAIN_ITEM_NULL_STATE) && (field->logical_minimum < field->logical_maximum) && (value < field->logical_minimum || value > field->logical_maximum)) { Patches currently in stable-queue which might be from rnd(a)nic.fi are queue-3.18/hid-reject-input-outside-logical-range-only-if-null-state-is-set.patch

7 years, 9 months

1
0
0 0

Patch "HID: clamp input to logical range if no null state" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled HID: clamp input to logical range if no null state to the 3.18-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-clamp-input-to-logical-range-if-no-null-state.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Tomasz Kramkowski <tk(a)the-tk.com> Date: Tue, 14 Mar 2017 13:29:13 +0000 Subject: HID: clamp input to logical range if no null state From: Tomasz Kramkowski <tk(a)the-tk.com> [ Upstream commit c3883fe06488a483658ba5d849b70e49bee15e7c ] This patch fixes an issue in drivers/hid/hid-input.c where values outside of the logical range are not clamped when "null state" bit of the input control is not set. This was discussed on the lists [1] and this change stems from the fact due to the ambiguity of the HID specification it might be appropriate to follow Microsoft's own interpretation of the specification. As noted in Microsoft's documentation [2] in the section titled "Required HID usages for digitizers" it is noted that values reported outside the logical range "will be considered as invalid data and the value will be changed to the nearest boundary value (logical min/max)." This patch fixes an issue where the (1292:4745) Innomedia INNEX GENESIS/ATARI reports out of range values for its X and Y axis of the DPad which, due to the null state bit being unset, are forwarded to userspace as is. Now these values will get clamped to the logical range before being forwarded to userspace. This device was also used to test this patch. This patch expands on commit 3f3752705dbd ("HID: reject input outside logical range only if null state is set"). [1]: http://lkml.kernel.org/r/20170307131036.GA853@gaia.local [2]: https://msdn.microsoft.com/en-us/library/windows/hardware/dn672278(v=vs.85)… Signed-off-by: Tomasz Kramkowski <tk(a)the-tk.com> Acked-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)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hid/hid-input.c | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) --- a/drivers/hid/hid-input.c +++ b/drivers/hid/hid-input.c @@ -1090,19 +1090,26 @@ void hidinput_hid_event(struct hid_devic /* * Ignore out-of-range values as per HID specification, - * section 5.10 and 6.2.25. + * section 5.10 and 6.2.25, when NULL state bit is present. + * When it's not, clamp the value to match Microsoft's input + * driver as mentioned in "Required HID usages for digitizers": + * https://msdn.microsoft.com/en-us/library/windows/hardware/dn672278(v=vs.85)… * * The logical_minimum < logical_maximum check is done so that we * don't unintentionally discard values sent by devices which * don't specify logical min and max. */ if ((field->flags & HID_MAIN_ITEM_VARIABLE) && - (field->flags & HID_MAIN_ITEM_NULL_STATE) && - (field->logical_minimum < field->logical_maximum) && - (value < field->logical_minimum || - value > field->logical_maximum)) { - dbg_hid("Ignoring out-of-range value %x\n", value); - return; + (field->logical_minimum < field->logical_maximum)) { + if (field->flags & HID_MAIN_ITEM_NULL_STATE && + (value < field->logical_minimum || + value > field->logical_maximum)) { + dbg_hid("Ignoring out-of-range value %x\n", value); + return; + } + value = clamp(value, + field->logical_minimum, + field->logical_maximum); } /* Patches currently in stable-queue which might be from tk(a)the-tk.com are queue-3.18/hid-clamp-input-to-logical-range-if-no-null-state.patch queue-3.18/hid-reject-input-outside-logical-range-only-if-null-state-is-set.patch

7 years, 9 months

1
0
0 0

Patch "drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) to the 3.18-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-defer-disabling-the-vblank-irq-until-the-next-interrupt-for-instant-off.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Wed, 15 Mar 2017 20:40:25 +0000 Subject: drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) From: Chris Wilson <chris(a)chris-wilson.co.uk> [ Upstream commit 608b20506941969ea30d8c08dc9ae02bb87dbf7d ] On vblank instant-off systems, we can get into a situation where the cost of enabling and disabling the vblank IRQ around a drmWaitVblank query dominates. And with the advent of even deeper hardware sleep state, touching registers becomes ever more expensive. However, we know that if the user wants the current vblank counter, they are also very likely to immediately queue a vblank wait and so we can keep the interrupt around and only turn it off if we have no further vblank requests queued within the interrupt interval. After vblank event delivery, this patch adds a shadow of one vblank where the interrupt is kept alive for the user to query and queue another vblank event. Similarly, if the user is using blocking drmWaitVblanks, the interrupt will be disabled on the IRQ following the wait completion. However, if the user is simply querying the current vblank counter and timestamp, the interrupt will be disabled after every IRQ and the user will enabled it again on the first query following the IRQ. v2: Mario Kleiner - After testing this, one more thing that would make sense is to move the disable block at the end of drm_handle_vblank() instead of at the top. Turns out that if high precision timestaming is disabled or doesn't work for some reason (as can be simulated by echo 0 > /sys/module/drm/parameters/timestamp_precision_usec), then with your delayed disable code at its current place, the vblank counter won't increment anymore at all for instant queries, ie. with your other "instant query" patches. Clients which repeatedly query the counter and wait for it to progress will simply hang, spinning in an endless query loop. There's that comment in vblank_disable_and_save: "* Skip this step if there isn't any high precision timestamp * available. In that case we can't account for this and just * hope for the best. */ With the disable happening after leading edge of vblank (== hw counter increment already happened) but before the vblank counter/timestamp handling in drm_handle_vblank, that step is needed to keep the counter progressing, so skipping it is bad. Now without high precision timestamping support, a kms driver must not set dev->vblank_disable_immediate = true, as this would cause problems for clients, so this shouldn't matter, but it would be good to still make this robust against a future kms driver which might have unreliable high precision timestamping, e.g., high precision timestamping that intermittently doesn't work. v3: Patch before coffee needs extra coffee. Testcase: igt/kms_vblank Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Michel Dänzer <michel(a)daenzer.net> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: Dave Airlie <airlied(a)redhat.com>, Cc: Mario Kleiner <mario.kleiner.de(a)gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170315204027.20160-1-chris@c… Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/drm_irq.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -1038,9 +1038,9 @@ void drm_vblank_put(struct drm_device *d if (atomic_dec_and_test(&vblank->refcount)) { if (drm_vblank_offdelay == 0) return; - else if (dev->vblank_disable_immediate || drm_vblank_offdelay < 0) + else if (drm_vblank_offdelay < 0) vblank_disable_fn((unsigned long)vblank); - else + else if (!dev->vblank_disable_immediate) mod_timer(&vblank->disable_timer, jiffies + ((drm_vblank_offdelay * HZ)/1000)); } @@ -1664,6 +1664,16 @@ bool drm_handle_vblank(struct drm_device wake_up(&vblank->queue); drm_handle_vblank_events(dev, crtc); + /* With instant-off, we defer disabling the interrupt until after + * we finish processing the following vblank. The disable has to + * be last (after drm_handle_vblank_events) so that the timestamp + * is always accurate. + */ + if (dev->vblank_disable_immediate && + drm_vblank_offdelay > 0 && + !atomic_read(&vblank->refcount)) + vblank_disable_fn((unsigned long)vblank); + spin_unlock_irqrestore(&dev->event_lock, irqflags); return true; Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are queue-3.18/drm-defer-disabling-the-vblank-irq-until-the-next-interrupt-for-instant-off.patch

7 years, 9 months

1
0
0 0

Patch "fm10k: correctly check if interface is removed" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fm10k: correctly check if interface is removed to the 3.18-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: fm10k-correctly-check-if-interface-is-removed.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Phil Turnbull <phil.turnbull(a)oracle.com> Date: Wed, 23 Nov 2016 13:33:58 -0500 Subject: fm10k: correctly check if interface is removed From: Phil Turnbull <phil.turnbull(a)oracle.com> [ Upstream commit 540fca35e38d15777b310f450f63f056e63039f5 ] FM10K_REMOVED expects a hardware address, not a 'struct fm10k_hw'. Fixes: 5cb8db4a4cbc ("fm10k: Add support for VF") Signed-off-by: Phil Turnbull <phil.turnbull(a)oracle.com> Tested-by: Krishneil Singh <krishneil.k.singh(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c +++ b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c @@ -840,7 +840,7 @@ static void fm10k_self_test(struct net_d memset(data, 0, sizeof(*data) * FM10K_TEST_LEN); - if (FM10K_REMOVED(hw)) { + if (FM10K_REMOVED(hw->hw_addr)) { netif_err(interface, drv, dev, "Interface removed - test blocked\n"); eth_test->flags |= ETH_TEST_FL_FAILED; Patches currently in stable-queue which might be from phil.turnbull(a)oracle.com are queue-3.18/fm10k-correctly-check-if-interface-is-removed.patch

7 years, 9 months

1
0
0 0

Patch "drm/radeon: Fail fb creation from imported dma-bufs." has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/radeon: Fail fb creation from imported dma-bufs. to the 3.18-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-fail-fb-creation-from-imported-dma-bufs.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com> Date: Wed, 29 Mar 2017 15:00:54 +1100 Subject: drm/radeon: Fail fb creation from imported dma-bufs. From: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com> [ Upstream commit a294043b2fbd8de69d161457ed0c7a4026bbfa5a ] Any use of the framebuffer will migrate it to VRAM, which is not sensible for an imported dma-buf. v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg. Reviewed-by: Michel Dänzer <michel.daenzer(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com> CC: amd-gfx(a)lists.freedesktop.org Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/radeon/radeon_display.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -1320,6 +1320,12 @@ radeon_user_framebuffer_create(struct dr return ERR_PTR(-ENOENT); } + /* Handle is imported dma-buf, so cannot be migrated to VRAM for scanout */ + if (obj->import_attach) { + DRM_DEBUG_KMS("Cannot create framebuffer from imported dma_buf\n"); + return ERR_PTR(-EINVAL); + } + radeon_fb = kzalloc(sizeof(*radeon_fb), GFP_KERNEL); if (radeon_fb == NULL) { drm_gem_object_unreference_unlocked(obj); Patches currently in stable-queue which might be from christopher.halse.rogers(a)canonical.com are queue-3.18/drm-radeon-fail-fb-creation-from-imported-dma-bufs.patch

7 years, 9 months

1
0
0 0

Patch "drivers: net: xgene: Fix hardware checksum setting" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drivers: net: xgene: Fix hardware checksum setting to the 3.18-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-net-xgene-fix-hardware-checksum-setting.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Quan Nguyen <qnguyen(a)apm.com> Date: Wed, 15 Mar 2017 13:27:16 -0700 Subject: drivers: net: xgene: Fix hardware checksum setting From: Quan Nguyen <qnguyen(a)apm.com> [ Upstream commit e026e700d940a1ea3d3bc84d92ac668b1f015462 ] This patch fixes the hardware checksum settings by properly program the classifier. Otherwise, packet may be received with checksum error on X-Gene1 SoC. Signed-off-by: Quan Nguyen <qnguyen(a)apm.com> Signed-off-by: Iyappan Subramanian <isubramanian(a)apm.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 1 + drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 1 + 2 files changed, 2 insertions(+) --- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c @@ -535,6 +535,7 @@ static void xgene_enet_cle_bypass(struct xgene_enet_rd_csr(pdata, CLE_BYPASS_REG0_0_ADDR, &cb); cb |= CFG_CLE_BYPASS_EN0; CFG_CLE_IP_PROTOCOL0_SET(&cb, 3); + CFG_CLE_IP_HDR_LEN_SET(&cb, 0); xgene_enet_wr_csr(pdata, CLE_BYPASS_REG0_0_ADDR, cb); xgene_enet_rd_csr(pdata, CLE_BYPASS_REG1_0_ADDR, &cb); --- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h @@ -143,6 +143,7 @@ enum xgene_enet_rm { #define CFG_TXCLK_MUXSEL0_SET(dst, val) xgene_set_bits(dst, val, 29, 3) #define CFG_CLE_IP_PROTOCOL0_SET(dst, val) xgene_set_bits(dst, val, 16, 2) +#define CFG_CLE_IP_HDR_LEN_SET(dst, val) xgene_set_bits(dst, val, 8, 5) #define CFG_CLE_DSTQID0_SET(dst, val) xgene_set_bits(dst, val, 0, 12) #define CFG_CLE_FPSEL0_SET(dst, val) xgene_set_bits(dst, val, 16, 4) #define CFG_MACMODE_SET(dst, val) xgene_set_bits(dst, val, 18, 2) Patches currently in stable-queue which might be from qnguyen(a)apm.com are queue-3.18/drivers-net-xgene-fix-hardware-checksum-setting.patch

7 years, 9 months

1
0
0 0

Patch "blk-throttle: make sure expire time isn't too big" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled blk-throttle: make sure expire time isn't too big to the 3.18-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: blk-throttle-make-sure-expire-time-isn-t-too-big.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Shaohua Li <shli(a)fb.com> Date: Mon, 27 Mar 2017 10:51:36 -0700 Subject: blk-throttle: make sure expire time isn't too big From: Shaohua Li <shli(a)fb.com> [ Upstream commit 06cceedcca67a93ac7f7aa93bbd9980c7496d14e ] cgroup could be throttled to a limit but when all cgroups cross high limit, queue enters a higher state and so the group should be throttled to a higher limit. It's possible the cgroup is sleeping because of throttle and other cgroups don't dispatch IO any more. In this case, nobody can trigger current downgrade/upgrade logic. To fix this issue, we could either set up a timer to wakeup the cgroup if other cgroups are idle or make sure this cgroup doesn't sleep too long. Setting up a timer means we must change the timer very frequently. This patch chooses the latter. Making cgroup sleep time not too big wouldn't change cgroup bps/iops, but could make it wakeup more frequently, which isn't a big issue because throtl_slice * 8 is already quite big. Signed-off-by: Shaohua Li <shli(a)fb.com> Signed-off-by: Jens Axboe <axboe(a)fb.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/blk-throttle.c | 11 +++++++++++ 1 file changed, 11 insertions(+) --- a/block/blk-throttle.c +++ b/block/blk-throttle.c @@ -648,6 +648,17 @@ static void throtl_dequeue_tg(struct thr static void throtl_schedule_pending_timer(struct throtl_service_queue *sq, unsigned long expires) { + unsigned long max_expire = jiffies + 8 * throtl_slice; + + /* + * Since we are adjusting the throttle limit dynamically, the sleep + * time calculated according to previous limit might be invalid. It's + * possible the cgroup sleep time is very long and no other cgroups + * have IO running so notify the limit changes. Make sure the cgroup + * doesn't sleep too long to avoid the missed notification. + */ + if (time_after(expires, max_expire)) + expires = max_expire; mod_timer(&sq->pending_timer, expires); throtl_log(sq, "schedule timer. delay=%lu jiffies=%lu", expires - jiffies, jiffies); Patches currently in stable-queue which might be from shli(a)fb.com are queue-3.18/blk-throttle-make-sure-expire-time-isn-t-too-big.patch

7 years, 9 months

1
0
0 0

Patch "braille-console: Fix value returned by _braille_console_setup" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled braille-console: Fix value returned by _braille_console_setup to the 3.18-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: braille-console-fix-value-returned-by-_braille_console_setup.patch and it can be found in the queue-3.18 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 Mar 19 10:11:52 CET 2018 From: Samuel Thibault <samuel.thibault(a)ens-lyon.org> Date: Sun, 26 Mar 2017 22:47:36 +0200 Subject: braille-console: Fix value returned by _braille_console_setup From: Samuel Thibault <samuel.thibault(a)ens-lyon.org> [ Upstream commit 2ed2b8621be2708c0f6d61fe9841e9ad8b9753f0 ] commit bbeddf52adc1 ("printk: move braille console support into separate braille.[ch] files") introduced _braille_console_setup() to outline the braille initialization code. There was however some confusion over the value it was supposed to return. commit 2cfe6c4ac7ee ("printk: Fix return of braille_register_console()") tried to fix it but failed to. This fixes and documents the returned value according to the use in printk.c: non-zero return means a parsing error, and thus this console configuration should be ignored. Signed-off-by: Samuel Thibault <samuel.thibault(a)ens-lyon.org> Cc: Aleksey Makarov <aleksey.makarov(a)linaro.org> Cc: Joe Perches <joe(a)perches.com> Cc: Ming Lei <ming.lei(a)canonical.com> Cc: Steven Rostedt <rostedt(a)goodmis.org> Acked-by: Petr Mladek <pmladek(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/printk/braille.c | 15 ++++++++------- kernel/printk/braille.h | 13 ++++++++++--- 2 files changed, 18 insertions(+), 10 deletions(-) --- a/kernel/printk/braille.c +++ b/kernel/printk/braille.c @@ -2,12 +2,13 @@ #include <linux/kernel.h> #include <linux/console.h> +#include <linux/errno.h> #include <linux/string.h> #include "console_cmdline.h" #include "braille.h" -char *_braille_console_setup(char **str, char **brl_options) +int _braille_console_setup(char **str, char **brl_options) { if (!memcmp(*str, "brl,", 4)) { *brl_options = ""; @@ -15,14 +16,14 @@ char *_braille_console_setup(char **str, } else if (!memcmp(str, "brl=", 4)) { *brl_options = *str + 4; *str = strchr(*brl_options, ','); - if (!*str) + if (!*str) { pr_err("need port name after brl=\n"); - else - *((*str)++) = 0; - } else - return NULL; + return -EINVAL; + } + *((*str)++) = 0; + } - return *str; + return 0; } int --- a/kernel/printk/braille.h +++ b/kernel/printk/braille.h @@ -9,7 +9,14 @@ braille_set_options(struct console_cmdli c->brl_options = brl_options; } -char * +/* + * Setup console according to braille options. + * Return -EINVAL on syntax error, 0 on success (or no braille option was + * actually given). + * Modifies str to point to the serial options + * Sets brl_options to the parsed braille options. + */ +int _braille_console_setup(char **str, char **brl_options); int @@ -25,10 +32,10 @@ braille_set_options(struct console_cmdli { } -static inline char * +static inline int _braille_console_setup(char **str, char **brl_options) { - return NULL; + return 0; } static inline int Patches currently in stable-queue which might be from samuel.thibault(a)ens-lyon.org are queue-3.18/braille-console-fix-value-returned-by-_braille_console_setup.patch

7 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror