[Linux-stable-mirror] [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid resource if buffer length too long
From: Bob Moore robert.moore@intel.com
[ Upstream commit 57707a9a7780fab426b8ae9b4c7b65b912a748b3 ]
ACPICA commit 9f76de2d249b18804e35fb55d14b1c2604d627a1 ACPICA commit b2e89d72ef1e9deefd63c3fd1dee90f893575b3a ACPICA commit 23b5bbe6d78afd3c5abf3adb91a1b098a3000b2e
The declared buffer length must be the same as the length of the byte initializer list, otherwise not a valid resource descriptor.
Link: https://github.com/acpica/acpica/commit/9f76de2d Link: https://github.com/acpica/acpica/commit/b2e89d72 Link: https://github.com/acpica/acpica/commit/23b5bbe6 Signed-off-by: Bob Moore robert.moore@intel.com Signed-off-by: Lv Zheng lv.zheng@intel.com Signed-off-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/acpi/acpica/utresrc.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/acpica/utresrc.c b/drivers/acpi/acpica/utresrc.c index 1de3376da66a..2ad99ea3d496 100644 --- a/drivers/acpi/acpica/utresrc.c +++ b/drivers/acpi/acpica/utresrc.c @@ -421,8 +421,10 @@ acpi_ut_walk_aml_resources(struct acpi_walk_state *walk_state,
ACPI_FUNCTION_TRACE(ut_walk_aml_resources);
- /* The absolute minimum resource template is one end_tag descriptor */ - + /* + * The absolute minimum resource template is one end_tag descriptor. + * However, we will treat a lone end_tag as just a simple buffer. + */ if (aml_length < sizeof(struct aml_resource_end_tag)) { return_ACPI_STATUS(AE_AML_NO_RESOURCE_END_TAG); } @@ -454,9 +456,8 @@ acpi_ut_walk_aml_resources(struct acpi_walk_state *walk_state, /* Invoke the user function */
if (user_function) { - status = - user_function(aml, length, offset, resource_index, - context); + status = user_function(aml, length, offset, + resource_index, context); if (ACPI_FAILURE(status)) { return_ACPI_STATUS(status); } @@ -480,6 +481,12 @@ acpi_ut_walk_aml_resources(struct acpi_walk_state *walk_state, *context = aml; }
+ /* Check if buffer is defined to be longer than the resource length */ + + if (aml_length > (offset + length)) { + return_ACPI_STATUS(AE_AML_NO_RESOURCE_END_TAG); + } + /* Normal exit */
return_ACPI_STATUS(AE_OK);
From: Santosh Shilimkar santosh.shilimkar@oracle.com
[ Upstream commit 584a8279a44a800dea5a5c1e9d53a002e03016b4 ]
The first message to a remote node should prompt a new connection even if it is RDMA operation. For RDMA operation the MR mapping can fail because connections is not yet up.
Since the connection establishment is asynchronous, we make sure the map failure because of unavailable connection reach to the user by appropriate error code. Before returning to the user, lets trigger the connection so that its ready for the next retry.
Signed-off-by: Santosh Shilimkar santosh.shilimkar@oracle.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- net/rds/send.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/net/rds/send.c b/net/rds/send.c index 310d57928405..ad247dc71ebb 100644 --- a/net/rds/send.c +++ b/net/rds/send.c @@ -946,6 +946,11 @@ static int rds_cmsg_send(struct rds_sock *rs, struct rds_message *rm, ret = rds_cmsg_rdma_map(rs, rm, cmsg); if (!ret) *allocated_mr = 1; + else if (ret == -ENODEV) + /* Accommodate the get_mr() case which can fail + * if connection isn't established yet. + */ + ret = -EAGAIN; break; case RDS_CMSG_ATOMIC_CSWP: case RDS_CMSG_ATOMIC_FADD: @@ -1114,8 +1119,12 @@ int rds_sendmsg(struct socket *sock, struct msghdr *msg, size_t payload_len)
/* Parse any control messages the user may have included. */ ret = rds_cmsg_send(rs, rm, msg, &allocated_mr); - if (ret) + if (ret) { + /* Trigger connection so that its ready for the next retry */ + if (ret == -EAGAIN) + rds_conn_connect_if_down(conn); goto out; + }
if (rm->rdma.op_active && !conn->c_trans->xmit_rdma) { printk_ratelimited(KERN_NOTICE "rdma_op %p conn xmit_rdma %p\n",
From: Santosh Shilimkar santosh.shilimkar@oracle.com
[ Upstream commit 3e56c2f856d7aba6a03feea834d68f9c05f7d0b6 ]
Fixes warning: Using plain integer as NULL pointer
Signed-off-by: Santosh Shilimkar santosh.shilimkar@oracle.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- net/rds/ib_frmr.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/rds/ib_frmr.c b/net/rds/ib_frmr.c index d921adc62765..66b3d6228a15 100644 --- a/net/rds/ib_frmr.c +++ b/net/rds/ib_frmr.c @@ -104,14 +104,15 @@ static int rds_ib_post_reg_frmr(struct rds_ib_mr *ibmr) struct rds_ib_frmr *frmr = &ibmr->u.frmr; struct ib_send_wr *failed_wr; struct ib_reg_wr reg_wr; - int ret; + int ret, off = 0;
while (atomic_dec_return(&ibmr->ic->i_fastreg_wrs) <= 0) { atomic_inc(&ibmr->ic->i_fastreg_wrs); cpu_relax(); }
- ret = ib_map_mr_sg_zbva(frmr->mr, ibmr->sg, ibmr->sg_len, 0, PAGE_SIZE); + ret = ib_map_mr_sg_zbva(frmr->mr, ibmr->sg, ibmr->sg_len, + &off, PAGE_SIZE); if (unlikely(ret != ibmr->sg_len)) return ret < 0 ? ret : -EINVAL;
From: Avinash Repaka avinash.repaka@oracle.com
[ Upstream commit f9fb69adb6c7acca60977a4db5a5f95b8e66c041 ]
RDS support max message size as 1M but the code doesn't check this in all cases. Patch fixes it for RDMA & non-RDMA and RDS MR size and its enforced irrespective of underlying transport.
Signed-off-by: Avinash Repaka avinash.repaka@oracle.com Signed-off-by: Santosh Shilimkar santosh.shilimkar@oracle.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- net/rds/rdma.c | 9 ++++++++- net/rds/rds.h | 3 +++ net/rds/send.c | 31 +++++++++++++++++++++++++++++++ 3 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/net/rds/rdma.c b/net/rds/rdma.c index 8d3a851a3476..60e90f761838 100644 --- a/net/rds/rdma.c +++ b/net/rds/rdma.c @@ -40,7 +40,6 @@ /* * XXX * - build with sparse - * - should we limit the size of a mr region? let transport return failure? * - should we detect duplicate keys on a socket? hmm. * - an rdma is an mlock, apply rlimit? */ @@ -200,6 +199,14 @@ static int __rds_rdma_map(struct rds_sock *rs, struct rds_get_mr_args *args, goto out; }
+ /* Restrict the size of mr irrespective of underlying transport + * To account for unaligned mr regions, subtract one from nr_pages + */ + if ((nr_pages - 1) > (RDS_MAX_MSG_SIZE >> PAGE_SHIFT)) { + ret = -EMSGSIZE; + goto out; + } + rdsdebug("RDS: get_mr addr %llx len %llu nr_pages %u\n", args->vec.addr, args->vec.bytes, nr_pages);
diff --git a/net/rds/rds.h b/net/rds/rds.h index f107a968ddff..30a51fec0f63 100644 --- a/net/rds/rds.h +++ b/net/rds/rds.h @@ -50,6 +50,9 @@ void rdsdebug(char *fmt, ...) #define RDS_FRAG_SHIFT 12 #define RDS_FRAG_SIZE ((unsigned int)(1 << RDS_FRAG_SHIFT))
+/* Used to limit both RDMA and non-RDMA RDS message to 1MB */ +#define RDS_MAX_MSG_SIZE ((unsigned int)(1 << 20)) + #define RDS_CONG_MAP_BYTES (65536 / 8) #define RDS_CONG_MAP_PAGES (PAGE_ALIGN(RDS_CONG_MAP_BYTES) / PAGE_SIZE) #define RDS_CONG_MAP_PAGE_BITS (PAGE_SIZE * 8) diff --git a/net/rds/send.c b/net/rds/send.c index f28651b6ae83..310d57928405 100644 --- a/net/rds/send.c +++ b/net/rds/send.c @@ -988,6 +988,26 @@ static int rds_send_mprds_hash(struct rds_sock *rs, struct rds_connection *conn) return hash; }
+static int rds_rdma_bytes(struct msghdr *msg, size_t *rdma_bytes) +{ + struct rds_rdma_args *args; + struct cmsghdr *cmsg; + + for_each_cmsghdr(cmsg, msg) { + if (!CMSG_OK(msg, cmsg)) + return -EINVAL; + + if (cmsg->cmsg_level != SOL_RDS) + continue; + + if (cmsg->cmsg_type == RDS_CMSG_RDMA_ARGS) { + args = CMSG_DATA(cmsg); + *rdma_bytes += args->remote_vec.bytes; + } + } + return 0; +} + int rds_sendmsg(struct socket *sock, struct msghdr *msg, size_t payload_len) { struct sock *sk = sock->sk; @@ -1002,6 +1022,7 @@ int rds_sendmsg(struct socket *sock, struct msghdr *msg, size_t payload_len) int nonblock = msg->msg_flags & MSG_DONTWAIT; long timeo = sock_sndtimeo(sk, nonblock); struct rds_conn_path *cpath; + size_t total_payload_len = payload_len, rdma_payload_len = 0;
/* Mirror Linux UDP mirror of BSD error message compatibility */ /* XXX: Perhaps MSG_MORE someday */ @@ -1034,6 +1055,16 @@ int rds_sendmsg(struct socket *sock, struct msghdr *msg, size_t payload_len) } release_sock(sk);
+ ret = rds_rdma_bytes(msg, &rdma_payload_len); + if (ret) + goto out; + + total_payload_len += rdma_payload_len; + if (max_t(size_t, payload_len, rdma_payload_len) > RDS_MAX_MSG_SIZE) { + ret = -EMSGSIZE; + goto out; + } + if (payload_len > rds_sk_sndbuf(rs)) { ret = -EMSGSIZE; goto out;
From: Bjorn Helgaas bhelgaas@google.com
[ Upstream commit 977509f7c5c6fb992ffcdf4291051af343b91645 ]
Previously we didn't check the type of device before trying to apply Type 1 (PCI-X) or Type 2 (PCIe) Setting Records from _HPX.
We don't support PCI-X Setting Records, so this was harmless, but the warning was useless.
We do support PCIe Setting Records, and we didn't check whether a device was PCIe before applying settings. I don't think anything bad happened on non-PCIe devices because pcie_capability_clear_and_set_word(), pcie_cap_has_lnkctl(), etc., would fail before doing any harm. But it's ugly to depend on those internals.
Check the device type before attempting to apply Type 1 and Type 2 Setting Records (Type 0 records are applicable to PCI, PCI-X, and PCIe devices).
A side benefit is that this prevents useless "not supported" warnings when a BIOS supplies a Type 1 (PCI-X) Setting Record and we try to apply it to every single device:
pci 0000:00:00.0: PCI-X settings not supported
After this patch, we'll get the warning only when a BIOS supplies a Type 1 record and we have a PCI-X device to which it should be applied.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=187731 Signed-off-by: Bjorn Helgaas bhelgaas@google.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/pci/probe.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index d266d800f246..60bada90cd75 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1438,8 +1438,16 @@ static void program_hpp_type0(struct pci_dev *dev, struct hpp_type0 *hpp)
static void program_hpp_type1(struct pci_dev *dev, struct hpp_type1 *hpp) { - if (hpp) - dev_warn(&dev->dev, "PCI-X settings not supported\n"); + int pos; + + if (!hpp) + return; + + pos = pci_find_capability(dev, PCI_CAP_ID_PCIX); + if (!pos) + return; + + dev_warn(&dev->dev, "PCI-X settings not supported\n"); }
static bool pcie_root_rcb_set(struct pci_dev *dev) @@ -1465,6 +1473,9 @@ static void program_hpp_type2(struct pci_dev *dev, struct hpp_type2 *hpp) if (!hpp) return;
+ if (!pci_is_pcie(dev)) + return; + if (hpp->revision > 1) { dev_warn(&dev->dev, "PCIe settings rev %d not supported\n", hpp->revision);
From: Christophe JAILLET christophe.jaillet@wanadoo.fr
[ Upstream commit 0f0861e31e3c59ca4bc1ec59d99260cfca79740e ]
If 'sun4i_backend_drm_format_to_layer()' does not return 0, then 'val' is left unmodified. As it is not initialized either, the return value can be anything.
It is likely that returning the error code was expected here.
As the only caller of 'sun4i_backend_update_layer_formats()' does not check the return value, this fix is purely theorical.
Signed-off-by: Christophe JAILLET christophe.jaillet@wanadoo.fr Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c index 6e6c59a661b6..223944a3ba18 100644 --- a/drivers/gpu/drm/sun4i/sun4i_backend.c +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c @@ -172,7 +172,7 @@ int sun4i_backend_update_layer_formats(struct sun4i_backend *backend, ret = sun4i_backend_drm_format_to_layer(plane, fb->pixel_format, &val); if (ret) { DRM_DEBUG_DRIVER("Invalid format\n"); - return val; + return ret; }
regmap_update_bits(backend->regs, SUN4I_BACKEND_ATTCTL_REG1(layer),
From: Icenowy Zheng icenowy@aosc.xyz
[ Upstream commit 790d929b540661945d1c70652ffb602c5c06ad85 ]
When adjusting PLL_CPUX on A33, the PLL is temporarily driven too high, and the system hangs.
Add a notifier to avoid this situation by temporarily switching to a known stable 24 MHz oscillator.
Signed-off-by: Icenowy Zheng icenowy@aosc.xyz Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c index 9bd1f78a0547..e1dc4e5b34e1 100644 --- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c @@ -752,6 +752,13 @@ static const struct sunxi_ccu_desc sun8i_a33_ccu_desc = { .num_resets = ARRAY_SIZE(sun8i_a33_ccu_resets), };
+static struct ccu_mux_nb sun8i_a33_cpu_nb = { + .common = &cpux_clk.common, + .cm = &cpux_clk.mux, + .delay_us = 1, /* > 8 clock cycles at 24 MHz */ + .bypass_index = 1, /* index of 24 MHz oscillator */ +}; + static void __init sun8i_a33_ccu_setup(struct device_node *node) { void __iomem *reg; @@ -775,6 +782,9 @@ static void __init sun8i_a33_ccu_setup(struct device_node *node) writel(val, reg + SUN8I_A33_PLL_MIPI_REG);
sunxi_ccu_probe(node, reg, &sun8i_a33_ccu_desc); + + ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk, + &sun8i_a33_cpu_nb); } CLK_OF_DECLARE(sun8i_a33_ccu, "allwinner,sun8i-a33-ccu", sun8i_a33_ccu_setup);
From: Marcus Cooper codekipper@gmail.com
[ Upstream commit 70421257c068b91476e70cade15fca68045d0693 ]
As the SPDIF was rarely documented on the earlier Allwinner SoCs it was assumed that it had a similar clock register to the one described in the H3 User Manual.
However this is not the case and it looks to shares the same setup as the I2S clock registers.
Signed-off-by: Marcus Cooper codekipper@gmail.com Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c index 0cca3601d99e..df97e25aec76 100644 --- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c +++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c @@ -468,8 +468,8 @@ static SUNXI_CCU_MUX_WITH_GATE(daudio0_clk, "daudio0", daudio_parents, static SUNXI_CCU_MUX_WITH_GATE(daudio1_clk, "daudio1", daudio_parents, 0x0b4, 16, 2, BIT(31), CLK_SET_RATE_PARENT);
-static SUNXI_CCU_M_WITH_GATE(spdif_clk, "spdif", "pll-audio", - 0x0c0, 0, 4, BIT(31), CLK_SET_RATE_PARENT); +static SUNXI_CCU_MUX_WITH_GATE(spdif_clk, "spdif", daudio_parents, + 0x0c0, 16, 2, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_GATE(usb_phy0_clk, "usb-phy0", "osc24M", 0x0cc, BIT(8), 0);
From: Eric Biggers ebiggers@google.com
[ Upstream commit dffd0cfa06d4ed83bb3ae8eb067989ceec5d18e1 ]
As part of an effort to clean up fscrypt-related error codes, make FS_IOC_SET_ENCRYPTION_POLICY fail with ENOTDIR when the file descriptor does not refer to a directory. This is more descriptive than EINVAL, which was ambiguous with some of the other error cases.
I am not aware of any users who might be relying on the previous error code of EINVAL, which was never documented anywhere, and in some buggy kernels did not exist at all as the S_ISDIR() check was missing.
This failure case will be exercised by an xfstest.
Signed-off-by: Eric Biggers ebiggers@google.com Signed-off-by: Theodore Ts'o tytso@mit.edu Signed-off-by: Sasha Levin alexander.levin@verizon.com --- fs/crypto/policy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/crypto/policy.c b/fs/crypto/policy.c index bb4e209bd809..c160d2d0e18d 100644 --- a/fs/crypto/policy.c +++ b/fs/crypto/policy.c @@ -113,7 +113,7 @@ int fscrypt_process_policy(struct file *filp,
if (!inode_has_encryption_context(inode)) { if (!S_ISDIR(inode->i_mode)) - ret = -EINVAL; + ret = -ENOTDIR; else if (!inode->i_sb->s_cop->empty_dir) ret = -EOPNOTSUPP; else if (!inode->i_sb->s_cop->empty_dir(inode))
From: Shawn Guo shawn.guo@linaro.org
[ Upstream commit fc318d64f3d91e15babac00e08354b1beb650b57 ]
The zx_dma driver supports cyclic transfer mode. Let's set DMA_CYCLIC cap_mask bit to make that clear, and avoid unnecessary failure when clients request channel via dma_request_chan_by_mask() with DMA_CYCLIC bit set in mask.
Signed-off-by: Shawn Guo shawn.guo@linaro.org Reviewed-by: Jun Nie jun.nie@linaro.org Signed-off-by: Vinod Koul vinod.koul@intel.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/dma/zx296702_dma.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/dma/zx296702_dma.c b/drivers/dma/zx296702_dma.c index 245d759d5ffc..6059d81e701a 100644 --- a/drivers/dma/zx296702_dma.c +++ b/drivers/dma/zx296702_dma.c @@ -813,6 +813,7 @@ static int zx_dma_probe(struct platform_device *op) INIT_LIST_HEAD(&d->slave.channels); dma_cap_set(DMA_SLAVE, d->slave.cap_mask); dma_cap_set(DMA_MEMCPY, d->slave.cap_mask); + dma_cap_set(DMA_CYCLIC, d->slave.cap_mask); dma_cap_set(DMA_PRIVATE, d->slave.cap_mask); d->slave.dev = &op->dev; d->slave.device_free_chan_resources = zx_dma_free_chan_resources;
From: Eric Biggers ebiggers@google.com
[ Upstream commit 54475f531bb8d7078f63c159e5e0615d486c498c ]
As part of an effort to clean up fscrypt-related error codes, make attempting to create a file in an encrypted directory that hasn't been "unlocked" fail with ENOKEY. Previously, several error codes were used for this case, including ENOENT, EACCES, and EPERM, and they were not consistent between and within filesystems. ENOKEY is a better choice because it expresses that the failure is due to lacking the encryption key. It also matches the error code returned when trying to open an encrypted regular file without the key.
I am not aware of any users who might be relying on the previous inconsistent error codes, which were never documented anywhere.
This failure case will be exercised by an xfstest.
Signed-off-by: Eric Biggers ebiggers@google.com Signed-off-by: Theodore Ts'o tytso@mit.edu Signed-off-by: Sasha Levin alexander.levin@verizon.com --- fs/crypto/fname.c | 4 ++-- fs/ext4/ialloc.c | 2 +- fs/ext4/namei.c | 4 +++- fs/f2fs/dir.c | 5 ++++- fs/f2fs/namei.c | 4 ++-- 5 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/fs/crypto/fname.c b/fs/crypto/fname.c index d1bbdc9dda76..e14bb7b67e9c 100644 --- a/fs/crypto/fname.c +++ b/fs/crypto/fname.c @@ -332,7 +332,7 @@ int fscrypt_fname_usr_to_disk(struct inode *inode, * in a directory. Consequently, a user space name cannot be mapped to * a disk-space name */ - return -EACCES; + return -ENOKEY; } EXPORT_SYMBOL(fscrypt_fname_usr_to_disk);
@@ -367,7 +367,7 @@ int fscrypt_setup_filename(struct inode *dir, const struct qstr *iname, return 0; } if (!lookup) - return -EACCES; + return -ENOKEY;
/* * We don't have the key and we are doing a lookup; decode the diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c index 170421edfdfe..2d94e8524839 100644 --- a/fs/ext4/ialloc.c +++ b/fs/ext4/ialloc.c @@ -771,7 +771,7 @@ struct inode *__ext4_new_inode(handle_t *handle, struct inode *dir, if (err) return ERR_PTR(err); if (!fscrypt_has_encryption_key(dir)) - return ERR_PTR(-EPERM); + return ERR_PTR(-ENOKEY); if (!handle) nblocks += EXT4_DATA_TRANS_BLOCKS(dir->i_sb); encrypt = 1; diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index 00b8a5a66961..4438b93f6fd6 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -1378,6 +1378,8 @@ static struct buffer_head * ext4_find_entry (struct inode *dir, return NULL;
retval = ext4_fname_setup_filename(dir, d_name, 1, &fname); + if (retval == -ENOENT) + return NULL; if (retval) return ERR_PTR(retval);
@@ -3090,7 +3092,7 @@ static int ext4_symlink(struct inode *dir, if (err) return err; if (!fscrypt_has_encryption_key(dir)) - return -EPERM; + return -ENOKEY; disk_link.len = (fscrypt_fname_encrypted_size(dir, len) + sizeof(struct fscrypt_symlink_data)); sd = kzalloc(disk_link.len, GFP_KERNEL); diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c index 11f3717ce481..8add4e8bab99 100644 --- a/fs/f2fs/dir.c +++ b/fs/f2fs/dir.c @@ -277,7 +277,10 @@ struct f2fs_dir_entry *f2fs_find_entry(struct inode *dir,
err = fscrypt_setup_filename(dir, child, 1, &fname); if (err) { - *res_page = ERR_PTR(err); + if (err == -ENOENT) + *res_page = NULL; + else + *res_page = ERR_PTR(err); return NULL; }
diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c index 08d7dc99042e..8556fe1ccb8a 100644 --- a/fs/f2fs/namei.c +++ b/fs/f2fs/namei.c @@ -403,7 +403,7 @@ static int f2fs_symlink(struct inode *dir, struct dentry *dentry, return err;
if (!fscrypt_has_encryption_key(dir)) - return -EPERM; + return -ENOKEY;
disk_link.len = (fscrypt_fname_encrypted_size(dir, len) + sizeof(struct fscrypt_symlink_data)); @@ -447,7 +447,7 @@ static int f2fs_symlink(struct inode *dir, struct dentry *dentry, goto err_out;
if (!fscrypt_has_encryption_key(inode)) { - err = -EPERM; + err = -ENOKEY; goto err_out; }
From: David Ahern dsa@cumulusnetworks.com
[ Upstream commit 7bb387c5ab12aeac3d5eea28686489ff46b53ca9 ]
IP_MULTICAST_IF fails if sk_bound_dev_if is already set and the new index does not match it. e.g.,
ntpd[15381]: setsockopt IP_MULTICAST_IF 192.168.1.23 fails: Invalid argument
Relax the check in setsockopt to allow setting mc_index to an L3 slave if sk_bound_dev_if points to an L3 master.
Make a similar change for IPv6. In this case change the device lookup to take the rcu_read_lock avoiding a refcnt. The rcu lock is also needed for the lookup of a potential L3 master device.
This really only silences a setsockopt failure since uses of mc_index are secondary to sk_bound_dev_if if it is set. In both cases, if either index is an L3 slave or master, lookups are directed to the same FIB table so relaxing the check at setsockopt time causes no harm.
Patch is based on a suggested change by Darwin for a problem noted in their code base.
Suggested-by: Darwin Dingel darwin.dingel@alliedtelesis.co.nz Signed-off-by: David Ahern dsa@cumulusnetworks.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Sasha Levin alexander.levin@verizon.com --- net/ipv4/ip_sockglue.c | 7 ++++++- net/ipv6/ipv6_sockglue.c | 16 ++++++++++++---- 2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c index 4d37bdcbc2d5..551dd393ceec 100644 --- a/net/ipv4/ip_sockglue.c +++ b/net/ipv4/ip_sockglue.c @@ -819,6 +819,7 @@ static int do_ip_setsockopt(struct sock *sk, int level, { struct ip_mreqn mreq; struct net_device *dev = NULL; + int midx;
if (sk->sk_type == SOCK_STREAM) goto e_inval; @@ -863,11 +864,15 @@ static int do_ip_setsockopt(struct sock *sk, int level, err = -EADDRNOTAVAIL; if (!dev) break; + + midx = l3mdev_master_ifindex(dev); + dev_put(dev);
err = -EINVAL; if (sk->sk_bound_dev_if && - mreq.imr_ifindex != sk->sk_bound_dev_if) + mreq.imr_ifindex != sk->sk_bound_dev_if && + (!midx || midx != sk->sk_bound_dev_if)) break;
inet->mc_index = mreq.imr_ifindex; diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c index 636ec56f5f50..38bee173dc2b 100644 --- a/net/ipv6/ipv6_sockglue.c +++ b/net/ipv6/ipv6_sockglue.c @@ -585,16 +585,24 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
if (val) { struct net_device *dev; + int midx;
- if (sk->sk_bound_dev_if && sk->sk_bound_dev_if != val) - goto e_inval; + rcu_read_lock();
- dev = dev_get_by_index(net, val); + dev = dev_get_by_index_rcu(net, val); if (!dev) { + rcu_read_unlock(); retv = -ENODEV; break; } - dev_put(dev); + midx = l3mdev_master_ifindex_rcu(dev); + + rcu_read_unlock(); + + if (sk->sk_bound_dev_if && + sk->sk_bound_dev_if != val && + (!midx || midx != sk->sk_bound_dev_if)) + goto e_inval; } np->mcast_oif = val; retv = 0;
From: Daniel Vetter daniel.vetter@ffwll.ch
[ Upstream commit 7357f89954b6d005df6ab8929759e78d7d9a80f9 ]
I reported the include issue for tracepoints a while ago, but nothing seems to have happened. Now it bit us, since the drm_mm_print conversion was broken for armada. Fix it, so I can re-enable armada in the drm-misc build configs.
v2: Rebase just the compile fix on top of Chris' build fix.
Cc: Russell King rmk+kernel@armlinux.org.uk Cc: Chris Wilson chris@chris-wilson.co.uk Acked: Chris Wilson chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vetter@intel.com Link: http://patchwork.freedesktop.org/patch/msgid/1483115932-19584-1-git-send-ema... Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/gpu/drm/armada/Makefile | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/armada/Makefile b/drivers/gpu/drm/armada/Makefile index ffd673615772..26412d2f8c98 100644 --- a/drivers/gpu/drm/armada/Makefile +++ b/drivers/gpu/drm/armada/Makefile @@ -4,3 +4,5 @@ armada-y += armada_510.o armada-$(CONFIG_DEBUG_FS) += armada_debugfs.o
obj-$(CONFIG_DRM_ARMADA) := armada.o + +CFLAGS_armada_trace.o := -I$(src)
From: Thomas Preisner thomas.preisner+linux@fau.de
[ Upstream commit 107fded7bf616ad6f46823d98b8ed6405d7adf2d ]
In a few cases the err-variable is not set to a negative error code if a function call in typhoon_init_one() fails and thus 0 is returned instead. It may be better to set err to the appropriate negative error code before returning.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188841
Reported-by: Pan Bian bianpan2016@163.com Signed-off-by: Thomas Preisner thomas.preisner+linux@fau.de Signed-off-by: Milan Stephan milan.stephan+linux@fau.de Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/net/ethernet/3com/typhoon.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/3com/typhoon.c b/drivers/net/ethernet/3com/typhoon.c index 6d0f0eb2ee2f..a0012c3cb4f6 100644 --- a/drivers/net/ethernet/3com/typhoon.c +++ b/drivers/net/ethernet/3com/typhoon.c @@ -2398,8 +2398,9 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) *(__be16 *)&dev->dev_addr[0] = htons(le16_to_cpu(xp_resp[0].parm1)); *(__be32 *)&dev->dev_addr[2] = htonl(le32_to_cpu(xp_resp[0].parm2));
- if(!is_valid_ether_addr(dev->dev_addr)) { + if (!is_valid_ether_addr(dev->dev_addr)) { err_msg = "Could not obtain valid ethernet address, aborting"; + err = -EIO; goto error_out_reset; }
@@ -2407,7 +2408,8 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) * later when we print out the version reported. */ INIT_COMMAND_WITH_RESPONSE(&xp_cmd, TYPHOON_CMD_READ_VERSIONS); - if(typhoon_issue_command(tp, 1, &xp_cmd, 3, xp_resp) < 0) { + err = typhoon_issue_command(tp, 1, &xp_cmd, 3, xp_resp); + if (err < 0) { err_msg = "Could not get Sleep Image version"; goto error_out_reset; } @@ -2449,7 +2451,8 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) dev->features = dev->hw_features | NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_RXCSUM;
- if(register_netdev(dev) < 0) { + err = register_netdev(dev); + if (err < 0) { err_msg = "unable to register netdev"; goto error_out_reset; }
From: Stanislaw Gruszka sgruszka@redhat.com
[ Upstream commit a51b89698ccc93c7e274eb71377fae49c4593ab2 ]
Signed-off-by: Stanislaw Gruszka sgruszka@redhat.com Signed-off-by: Kalle Valo kvalo@codeaurora.org Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c index bf3f0a39908c..9fc6f1615343 100644 --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c @@ -4707,8 +4707,8 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev) rt2x00_set_field32(®, MAX_LEN_CFG_MAX_PSDU, 2); else rt2x00_set_field32(®, MAX_LEN_CFG_MAX_PSDU, 1); - rt2x00_set_field32(®, MAX_LEN_CFG_MIN_PSDU, 0); - rt2x00_set_field32(®, MAX_LEN_CFG_MIN_MPDU, 0); + rt2x00_set_field32(®, MAX_LEN_CFG_MIN_PSDU, 10); + rt2x00_set_field32(®, MAX_LEN_CFG_MIN_MPDU, 10); rt2800_register_write(rt2x00dev, MAX_LEN_CFG, reg);
rt2800_register_read(rt2x00dev, LED_CFG, ®);
From: Thomas Preisner thomas.preisner+linux@fau.de
[ Upstream commit 6b6bbb5922a4b1d4b58125a572da91010295fba3 ]
In some cases the return value of a failing function is not being used and the function typhoon_init_one() returns another negative error code instead.
Signed-off-by: Thomas Preisner thomas.preisner+linux@fau.de Signed-off-by: Milan Stephan milan.stephan+linux@fau.de Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/net/ethernet/3com/typhoon.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/3com/typhoon.c b/drivers/net/ethernet/3com/typhoon.c index 8f8418d2ac4a..6d0f0eb2ee2f 100644 --- a/drivers/net/ethernet/3com/typhoon.c +++ b/drivers/net/ethernet/3com/typhoon.c @@ -2366,9 +2366,9 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) * 4) Get the hardware address. * 5) Put the card to sleep. */ - if (typhoon_reset(ioaddr, WaitSleep) < 0) { + err = typhoon_reset(ioaddr, WaitSleep); + if (err < 0) { err_msg = "could not reset 3XP"; - err = -EIO; goto error_out_dma; }
@@ -2382,16 +2382,16 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) typhoon_init_interface(tp); typhoon_init_rings(tp);
- if(typhoon_boot_3XP(tp, TYPHOON_STATUS_WAITING_FOR_HOST) < 0) { + err = typhoon_boot_3XP(tp, TYPHOON_STATUS_WAITING_FOR_HOST); + if (err < 0) { err_msg = "cannot boot 3XP sleep image"; - err = -EIO; goto error_out_reset; }
INIT_COMMAND_WITH_RESPONSE(&xp_cmd, TYPHOON_CMD_READ_MAC_ADDRESS); - if(typhoon_issue_command(tp, 1, &xp_cmd, 1, xp_resp) < 0) { + err = typhoon_issue_command(tp, 1, &xp_cmd, 1, xp_resp); + if (err < 0) { err_msg = "cannot read MAC address"; - err = -EIO; goto error_out_reset; }
@@ -2424,9 +2424,9 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) if(xp_resp[0].numDesc != 0) tp->capabilities |= TYPHOON_WAKEUP_NEEDS_RESET;
- if(typhoon_sleep(tp, PCI_D3hot, 0) < 0) { + err = typhoon_sleep(tp, PCI_D3hot, 0); + if (err < 0) { err_msg = "cannot put adapter to sleep"; - err = -EIO; goto error_out_reset; }
From: Dan Carpenter dan.carpenter@oracle.com
[ Upstream commit c705a6b3aa7804d7bc6660183f51e510c61dc807 ]
We accidentally return success when adm8211_alloc_rings() fails but we should preserve the error code.
Fixes: cc0b88cf5ecf ("[PATCH] Add adm8211 802.11b wireless driver") Signed-off-by: Dan Carpenter dan.carpenter@oracle.com Signed-off-by: Kalle Valo kvalo@codeaurora.org Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/net/wireless/admtek/adm8211.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/admtek/adm8211.c b/drivers/net/wireless/admtek/adm8211.c index 70ecd82d674d..0321f85c388c 100644 --- a/drivers/net/wireless/admtek/adm8211.c +++ b/drivers/net/wireless/admtek/adm8211.c @@ -1843,7 +1843,8 @@ static int adm8211_probe(struct pci_dev *pdev, priv->rx_ring_size = rx_ring_size; priv->tx_ring_size = tx_ring_size;
- if (adm8211_alloc_rings(dev)) { + err = adm8211_alloc_rings(dev); + if (err) { printk(KERN_ERR "%s (adm8211): Cannot allocate TX/RX ring\n", pci_name(pdev)); goto err_iounmap;
From: Ryan Hsu ryanhsu@qca.qualcomm.com
[ Upstream commit 88407beb1b1462f706a1950a355fd086e1c450b6 ]
Ath10k reports the phy capability that supports P2P_DEVICE interface.
When we use the P2P supported wpa_supplicant to start connection, it'll create two interfaces, one is wlan0 (vdev_id=0) and one is P2P_DEVICE p2p-dev-wlan0 which is for p2p control channel (vdev_id=1).
ath10k_pci mac vdev create 0 (add interface) type 2 subtype 0 ath10k_add_interface: vdev_id: 0, txpower: 0, bss_power: 0 ... ath10k_pci mac vdev create 1 (add interface) type 2 subtype 1 ath10k_add_interface: vdev_id: 1, txpower: 0, bss_power: 0
And the txpower in per vif bss_conf will only be set to valid tx power when the interface is assigned with channel_ctx.
But this P2P_DEVICE interface will never be used for any connection, so that the uninitialized bss_conf.txpower=0 is assinged to the arvif->txpower when interface created.
Since the txpower configuration is firmware per physical interface. So the smallest txpower of all vifs will be the one limit the tx power of the physical device, that causing the low txpower issue on other active interfaces.
wlan0: Limiting TX power to 21 (24 - 3) dBm ath10k_pci mac vdev_id 0 txpower 21 ath10k_mac_txpower_recalc: vdev_id: 1, txpower: 0 ath10k_mac_txpower_recalc: vdev_id: 0, txpower: 21 ath10k_pci mac txpower 0
This issue only happens when we use the wpa_supplicant that supports P2P or if we use the iw tool to create the control P2P_DEVICE interface.
Signed-off-by: Ryan Hsu ryanhsu@qca.qualcomm.com Signed-off-by: Kalle Valo kvalo@qca.qualcomm.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/net/wireless/ath/ath10k/mac.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 30e98afa2e68..d3ac7e0745e2 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -4668,7 +4668,8 @@ static int ath10k_mac_txpower_recalc(struct ath10k *ar) lockdep_assert_held(&ar->conf_mutex);
list_for_each_entry(arvif, &ar->arvifs, list) { - WARN_ON(arvif->txpower < 0); + if (arvif->txpower <= 0) + continue;
if (txpower == -1) txpower = arvif->txpower; @@ -4676,8 +4677,8 @@ static int ath10k_mac_txpower_recalc(struct ath10k *ar) txpower = min(txpower, arvif->txpower); }
- if (WARN_ON(txpower == -1)) - return -EINVAL; + if (txpower == -1) + return 0;
ret = ath10k_mac_txpower_setup(ar, txpower); if (ret) {
From: Amitkumar Karwar akarwar@marvell.com
[ Upstream commit 74c8719b8ee0922593a5cbec0bd6127d86d8a2f4 ]
If we have sdio work requests received when sdio card reset is happening, we may end up accessing older save_adapter pointer later which is already freed during card reset. This patch solves the problem by cancelling those pending requests.
Signed-off-by: Amitkumar Karwar akarwar@marvell.com Signed-off-by: Kalle Valo kvalo@codeaurora.org Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/net/wireless/marvell/mwifiex/sdio.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c index 8718950004f3..8d601dcf2948 100644 --- a/drivers/net/wireless/marvell/mwifiex/sdio.c +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c @@ -2296,6 +2296,12 @@ static void mwifiex_recreate_adapter(struct sdio_mmc_card *card) mmc_hw_reset(func->card->host); sdio_release_host(func);
+ /* Previous save_adapter won't be valid after this. We will cancel + * pending work requests. + */ + clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &iface_work_flags); + clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET, &iface_work_flags); + mwifiex_sdio_probe(func, device_id); }
From: Christian Lamparter chunkeey@googlemail.com
[ Upstream commit 097e46d2ae90265d1afe141ba6208ba598b79e01 ]
ath10k_wmi_tlv_op_pull_fw_stats() uses tb = ath10k_wmi_tlv_parse_alloc(...) function, which allocates memory. If any of the three error-paths are taken, this tb needs to be freed.
Signed-off-by: Christian Lamparter chunkeey@googlemail.com Signed-off-by: Kalle Valo kvalo@qca.qualcomm.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/net/wireless/ath/ath10k/wmi-tlv.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c index e64f59300a7c..0e4d49adddd0 100644 --- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c +++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c @@ -1105,8 +1105,10 @@ static int ath10k_wmi_tlv_op_pull_fw_stats(struct ath10k *ar, struct ath10k_fw_stats_pdev *dst;
src = data; - if (data_len < sizeof(*src)) + if (data_len < sizeof(*src)) { + kfree(tb); return -EPROTO; + }
data += sizeof(*src); data_len -= sizeof(*src); @@ -1126,8 +1128,10 @@ static int ath10k_wmi_tlv_op_pull_fw_stats(struct ath10k *ar, struct ath10k_fw_stats_vdev *dst;
src = data; - if (data_len < sizeof(*src)) + if (data_len < sizeof(*src)) { + kfree(tb); return -EPROTO; + }
data += sizeof(*src); data_len -= sizeof(*src); @@ -1145,8 +1149,10 @@ static int ath10k_wmi_tlv_op_pull_fw_stats(struct ath10k *ar, struct ath10k_fw_stats_peer *dst;
src = data; - if (data_len < sizeof(*src)) + if (data_len < sizeof(*src)) { + kfree(tb); return -EPROTO; + }
data += sizeof(*src); data_len -= sizeof(*src);
From: Ryan Hsu ryanhsu@qca.qualcomm.com
[ Upstream commit d2e202c06ca42d353d95df12437740921a6d05b5 ]
With command to get board_id from otp, in the case of following
boot get otp board id result 0x00000000 board_id 0 chip_id 0 boot using board name 'bus=pci,bmi-chip-id=0,bmi-board-id=0" ... failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-board-id=0 from ath10k/QCA6174/hw3.0/board-2.bin
The invalid board_id=0 will be used as index to search in the board-2.bin.
Ignore the case with board_id=0, as it means the otp is not carrying the board id information.
Signed-off-by: Ryan Hsu ryanhsu@qca.qualcomm.com Signed-off-by: Kalle Valo kvalo@qca.qualcomm.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/net/wireless/ath/ath10k/core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c index 366d3dcb8e9d..7b3017f55e3d 100644 --- a/drivers/net/wireless/ath/ath10k/core.c +++ b/drivers/net/wireless/ath/ath10k/core.c @@ -691,8 +691,11 @@ static int ath10k_core_get_board_id_from_otp(struct ath10k *ar) "boot get otp board id result 0x%08x board_id %d chip_id %d\n", result, board_id, chip_id);
- if ((result & ATH10K_BMI_BOARD_ID_STATUS_MASK) != 0) + if ((result & ATH10K_BMI_BOARD_ID_STATUS_MASK) != 0 || + (board_id == 0)) { + ath10k_warn(ar, "board id is not exist in otp, ignore it\n"); return -EOPNOTSUPP; + }
ar->id.bmi_ids_valid = true; ar->id.bmi_board_id = board_id;
From: Michael Chan michael.chan@broadcom.com
[ Upstream commit 486b5c22ea1d35e00e90dd79a32a9ee530b18915 ]
With the added support for the bnxt_re RDMA driver, both drivers can be allocating completion rings in any order. The firmware does not know which completion ring should be receiving async events. Add an extra step to tell firmware the completion ring number for receiving async events after bnxt_en allocates the completion rings.
Signed-off-by: Michael Chan michael.chan@broadcom.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c index 333df540b375..5d2cf56aed0e 100644 --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c @@ -3800,6 +3800,30 @@ static int hwrm_ring_alloc_send_msg(struct bnxt *bp, return rc; }
+static int bnxt_hwrm_set_async_event_cr(struct bnxt *bp, int idx) +{ + int rc; + + if (BNXT_PF(bp)) { + struct hwrm_func_cfg_input req = {0}; + + bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_FUNC_CFG, -1, -1); + req.fid = cpu_to_le16(0xffff); + req.enables = cpu_to_le32(FUNC_CFG_REQ_ENABLES_ASYNC_EVENT_CR); + req.async_event_cr = cpu_to_le16(idx); + rc = hwrm_send_message(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT); + } else { + struct hwrm_func_vf_cfg_input req = {0}; + + bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_FUNC_VF_CFG, -1, -1); + req.enables = + cpu_to_le32(FUNC_VF_CFG_REQ_ENABLES_ASYNC_EVENT_CR); + req.async_event_cr = cpu_to_le16(idx); + rc = hwrm_send_message(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT); + } + return rc; +} + static int bnxt_hwrm_ring_alloc(struct bnxt *bp) { int i, rc = 0; @@ -3816,6 +3840,12 @@ static int bnxt_hwrm_ring_alloc(struct bnxt *bp) goto err_out; BNXT_CP_DB(cpr->cp_doorbell, cpr->cp_raw_cons); bp->grp_info[i].cp_fw_ring_id = ring->fw_ring_id; + + if (!i) { + rc = bnxt_hwrm_set_async_event_cr(bp, ring->fw_ring_id); + if (rc) + netdev_warn(bp->dev, "Failed to set async event completion ring.\n"); + } }
for (i = 0; i < bp->tx_nr_rings; i++) {
From: Bartosz Markowski bartosz.markowski@tieto.com
[ Upstream commit 7cfe0455ee1218add152e986b89b4bb8dbeafcdd ]
The cts protection vdev parameter, in new QCA9377 TF2.0 firmware, requires bss peer to be created for the STATION vdev type. bss peer is being allocated by the firmware after vdev_start/_up commands. mac80211 may call the cts protection setup at any time, so the we needs to track the situation and defer the cts configuration to prevent firmware asserts, like below:
[00]: 0x05020001 0x000015B3 0x0099ACE2 0x00955B31 [04]: 0x0099ACE2 0x00060730 0x00000004 0x00000000 [08]: 0x0044C754 0x00412C10 0x00000000 0x00409C54 [12]: 0x00000009 0x00000000 0x00952F6C 0x00952F77 [16]: 0x00952CC4 0x00910712 0x00000000 0x00000000 [20]: 0x4099ACE2 0x0040E858 0x00421254 0x004127F4 [24]: 0x8099B9B2 0x0040E8B8 0x00000000 0xC099ACE2 [28]: 0x800B75CB 0x0040E8F8 0x00000007 0x00005008 [32]: 0x809B048A 0x0040E958 0x00000010 0x00433B10 [36]: 0x809AFBBC 0x0040E9A8 0x0042BB74 0x0042BBBC [40]: 0x8091D252 0x0040E9C8 0x0042BBBC 0x00000001 [44]: 0x809FFA45 0x0040EA78 0x0043D3E4 0x0042C2C8 [48]: 0x809FCEF4 0x0040EA98 0x0043D3E4 0x00000001 [52]: 0x80911210 0x0040EAE8 0x00000010 0x004041D0 [56]: 0x80911154 0x0040EB28 0x00400000 0x00000000
Signed-off-by: Bartosz Markowski bartosz.markowski@tieto.com Signed-off-by: Kalle Valo kvalo@qca.qualcomm.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/net/wireless/ath/ath10k/mac.c | 51 +++++++++++++++++++++++++++++------ 1 file changed, 43 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index d3ac7e0745e2..17ab8efdac35 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -1224,6 +1224,36 @@ static int ath10k_monitor_recalc(struct ath10k *ar) return ath10k_monitor_stop(ar); }
+static bool ath10k_mac_can_set_cts_prot(struct ath10k_vif *arvif) +{ + struct ath10k *ar = arvif->ar; + + lockdep_assert_held(&ar->conf_mutex); + + if (!arvif->is_started) { + ath10k_dbg(ar, ATH10K_DBG_MAC, "defer cts setup, vdev is not ready yet\n"); + return false; + } + + return true; +} + +static int ath10k_mac_set_cts_prot(struct ath10k_vif *arvif) +{ + struct ath10k *ar = arvif->ar; + u32 vdev_param; + + lockdep_assert_held(&ar->conf_mutex); + + vdev_param = ar->wmi.vdev_param->protection_mode; + + ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vdev %d cts_protection %d\n", + arvif->vdev_id, arvif->use_cts_prot); + + return ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param, + arvif->use_cts_prot ? 1 : 0); +} + static int ath10k_recalc_rtscts_prot(struct ath10k_vif *arvif) { struct ath10k *ar = arvif->ar; @@ -5322,20 +5352,18 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw,
if (changed & BSS_CHANGED_ERP_CTS_PROT) { arvif->use_cts_prot = info->use_cts_prot; - ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vdev %d cts_prot %d\n", - arvif->vdev_id, info->use_cts_prot);
ret = ath10k_recalc_rtscts_prot(arvif); if (ret) ath10k_warn(ar, "failed to recalculate rts/cts prot for vdev %d: %d\n", arvif->vdev_id, ret);
- vdev_param = ar->wmi.vdev_param->protection_mode; - ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param, - info->use_cts_prot ? 1 : 0); - if (ret) - ath10k_warn(ar, "failed to set protection mode %d on vdev %i: %d\n", - info->use_cts_prot, arvif->vdev_id, ret); + if (ath10k_mac_can_set_cts_prot(arvif)) { + ret = ath10k_mac_set_cts_prot(arvif); + if (ret) + ath10k_warn(ar, "failed to set cts protection for vdev %d: %d\n", + arvif->vdev_id, ret); + } }
if (changed & BSS_CHANGED_ERP_SLOT) { @@ -7356,6 +7384,13 @@ ath10k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw, arvif->is_up = true; }
+ if (ath10k_mac_can_set_cts_prot(arvif)) { + ret = ath10k_mac_set_cts_prot(arvif); + if (ret) + ath10k_warn(ar, "failed to set cts protection for vdev %d: %d\n", + arvif->vdev_id, ret); + } + mutex_unlock(&ar->conf_mutex); return 0;
From: Christophe JAILLET christophe.jaillet@wanadoo.fr
[ Upstream commit 7af355e6715b325d8af29822f4c3dbecd7eeebec ]
Reference to 'sys2pci_np' should be dropped in all cases here, not only in error handling path.
Signed-off-by: Christophe JAILLET christophe.jaillet@wanadoo.fr Signed-off-by: Linus Walleij linus.walleij@linaro.org Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/pinctrl/sirf/pinctrl-atlas7.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/sirf/pinctrl-atlas7.c b/drivers/pinctrl/sirf/pinctrl-atlas7.c index 7f3041697813..f714f67c4b64 100644 --- a/drivers/pinctrl/sirf/pinctrl-atlas7.c +++ b/drivers/pinctrl/sirf/pinctrl-atlas7.c @@ -5420,14 +5420,15 @@ static int atlas7_pinmux_probe(struct platform_device *pdev) sys2pci_np = of_find_node_by_name(NULL, "sys2pci"); if (!sys2pci_np) return -EINVAL; + ret = of_address_to_resource(sys2pci_np, 0, &res); + of_node_put(sys2pci_np); if (ret) return ret; + pmx->sys2pci_base = devm_ioremap_resource(&pdev->dev, &res); - if (IS_ERR(pmx->sys2pci_base)) { - of_node_put(sys2pci_np); + if (IS_ERR(pmx->sys2pci_base)) return -ENOMEM; - }
pmx->dev = &pdev->dev;
From: Gabriele Mazzotta gabriele.mzt@gmail.com
[ Upstream commit 972aa2c708703c21f14eb958b37e82aae2530e44 ]
Setting shutup when the action is HDA_FIXUP_ACT_PRE_PROBE might not have the desired effect since it could be overridden by another more generic shutup function. Prevent this by setting the more specific shutup function on HDA_FIXUP_ACT_PROBE.
Signed-off-by: Gabriele Mazzotta gabriele.mzt@gmail.com Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Sasha Levin alexander.levin@verizon.com --- sound/pci/hda/patch_realtek.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index fe1d06d50392..ceb2df62cab5 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4411,7 +4411,7 @@ static void alc_no_shutup(struct hda_codec *codec) static void alc_fixup_no_shutup(struct hda_codec *codec, const struct hda_fixup *fix, int action) { - if (action == HDA_FIXUP_ACT_PRE_PROBE) { + if (action == HDA_FIXUP_ACT_PROBE) { struct alc_spec *spec = codec->spec; spec->shutup = alc_no_shutup; }
From: Chris Wilson chris@chris-wilson.co.uk
[ Upstream commit 3db93756b501e5f0a3951c79cfa9ed43c26d3455 ]
mm->color_adjust() compares the hole with its neighbouring nodes. They only abutt before we restrict the hole, so we have to apply color_adjust before we apply the range restriction.
Signed-off-by: Chris Wilson chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen joonas.lahtinen@linux.intel.com Signed-off-by: Daniel Vetter daniel.vetter@ffwll.ch Link: http://patchwork.freedesktop.org/patch/msgid/20161222083641.2691-36-chris@ch... Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/gpu/drm/drm_mm.c | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c index ee07bb4a57b7..11f54df0c19b 100644 --- a/drivers/gpu/drm/drm_mm.c +++ b/drivers/gpu/drm/drm_mm.c @@ -348,14 +348,12 @@ static void drm_mm_insert_helper_range(struct drm_mm_node *hole_node,
BUG_ON(!hole_node->hole_follows || node->allocated);
- if (adj_start < start) - adj_start = start; - if (adj_end > end) - adj_end = end; - if (mm->color_adjust) mm->color_adjust(hole_node, color, &adj_start, &adj_end);
+ adj_start = max(adj_start, start); + adj_end = min(adj_end, end); + if (flags & DRM_MM_CREATE_TOP) adj_start = adj_end - size;
@@ -566,17 +564,15 @@ static struct drm_mm_node *drm_mm_search_free_in_range_generic(const struct drm_ flags & DRM_MM_SEARCH_BELOW) { u64 hole_size = adj_end - adj_start;
- if (adj_start < start) - adj_start = start; - if (adj_end > end) - adj_end = end; - if (mm->color_adjust) { mm->color_adjust(entry, color, &adj_start, &adj_end); if (adj_end <= adj_start) continue; }
+ adj_start = max(adj_start, start); + adj_end = min(adj_end, end); + if (!check_free_hole(adj_start, adj_end, size, alignment)) continue;
From: Bartosz Golaszewski bgolaszewski@baylibre.com
[ Upstream commit ad6d8004fa29a8958381b60215e32d1e903b0492 ]
Currently the chip name buffer is allocated on the stack and the address of the buffer is passed to the gpio framework. It's invalid after probe() returns, so the sysfs label attribute displays garbage.
Use devm_kasprintf() for each string instead.
Signed-off-by: Bartosz Golaszewski bgolaszewski@baylibre.com Signed-off-by: Linus Walleij linus.walleij@linaro.org Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/gpio/gpio-mockup.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-mockup.c b/drivers/gpio/gpio-mockup.c index 1ef85b0c2b1f..d27e9361e236 100644 --- a/drivers/gpio/gpio-mockup.c +++ b/drivers/gpio/gpio-mockup.c @@ -126,7 +126,7 @@ static int mockup_gpio_probe(struct platform_device *pdev) int i; int base; int ngpio; - char chip_name[sizeof(GPIO_NAME) + 3]; + char *chip_name;
if (gpio_mockup_params_nr < 2) return -EINVAL; @@ -146,8 +146,12 @@ static int mockup_gpio_probe(struct platform_device *pdev) ngpio = gpio_mockup_ranges[i * 2 + 1] - base;
if (ngpio >= 0) { - sprintf(chip_name, "%s-%c", GPIO_NAME, - pins_name_start + i); + chip_name = devm_kasprintf(dev, GFP_KERNEL, + "%s-%c", GPIO_NAME, + pins_name_start + i); + if (!chip_name) + return -ENOMEM; + ret = mockup_gpio_add(dev, &cntr[i], chip_name, base, ngpio); } else {
From: Abhishek Sahu absahu@codeaurora.org
[ Upstream commit 86c654d41a52e3d17e9bc2c2ba37f3c963e66a4a ]
The APSS CPU clock does not contain all the frequencies in its frequency table so this patch adds the same.
Signed-off-by: Abhishek Sahu absahu@codeaurora.org Signed-off-by: Stephen Boyd sboyd@codeaurora.org Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/clk/qcom/gcc-ipq4019.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c index b593065de8db..8ab6ce4d976f 100644 --- a/drivers/clk/qcom/gcc-ipq4019.c +++ b/drivers/clk/qcom/gcc-ipq4019.c @@ -525,10 +525,20 @@ static struct clk_rcg2 sdcc1_apps_clk_src = { };
static const struct freq_tbl ftbl_gcc_apps_clk[] = { - F(48000000, P_XO, 1, 0, 0), + F(48000000, P_XO, 1, 0, 0), F(200000000, P_FEPLL200, 1, 0, 0), + F(384000000, P_DDRPLLAPSS, 1, 0, 0), + F(413000000, P_DDRPLLAPSS, 1, 0, 0), + F(448000000, P_DDRPLLAPSS, 1, 0, 0), + F(488000000, P_DDRPLLAPSS, 1, 0, 0), F(500000000, P_FEPLL500, 1, 0, 0), - F(626000000, P_DDRPLLAPSS, 1, 0, 0), + F(512000000, P_DDRPLLAPSS, 1, 0, 0), + F(537000000, P_DDRPLLAPSS, 1, 0, 0), + F(565000000, P_DDRPLLAPSS, 1, 0, 0), + F(597000000, P_DDRPLLAPSS, 1, 0, 0), + F(632000000, P_DDRPLLAPSS, 1, 0, 0), + F(672000000, P_DDRPLLAPSS, 1, 0, 0), + F(716000000, P_DDRPLLAPSS, 1, 0, 0), { } };
From: Vincente Tsou vincente.tsou@intel.com
[ Upstream commit ce2e87b4ce9a6c14b3f60756b58a6b5c77e083bd ]
The upper bits of the vsync width, vsync offset and hsync width were not parsed from the VBT. Parse these fields in this patch.
V2: Renamed lvds dvo timing structure members and code identation fix (Jani's review comments) V3: Corrected commit message, used "from the VBT"
Signed-off-by: Vincente Tsou vincente.tsou@intel.com Signed-off-by: Madhav Chauhan madhav.chauhan@intel.com Reviewed-by: Jani Nikula jani.nikula@intel.com Signed-off-by: Jani Nikula jani.nikula@intel.com Link: http://patchwork.freedesktop.org/patch/msgid/1482430993-3265-1-git-send-emai... Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/gpu/drm/i915/intel_bios.c | 8 +++++--- drivers/gpu/drm/i915/intel_vbt_defs.h | 12 +++++++----- 2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c index 80c5cc5640c1..c450938c1852 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -114,16 +114,18 @@ fill_detail_timing_data(struct drm_display_mode *panel_fixed_mode, panel_fixed_mode->hsync_start = panel_fixed_mode->hdisplay + ((dvo_timing->hsync_off_hi << 8) | dvo_timing->hsync_off_lo); panel_fixed_mode->hsync_end = panel_fixed_mode->hsync_start + - dvo_timing->hsync_pulse_width; + ((dvo_timing->hsync_pulse_width_hi << 8) | + dvo_timing->hsync_pulse_width_lo); panel_fixed_mode->htotal = panel_fixed_mode->hdisplay + ((dvo_timing->hblank_hi << 8) | dvo_timing->hblank_lo);
panel_fixed_mode->vdisplay = (dvo_timing->vactive_hi << 8) | dvo_timing->vactive_lo; panel_fixed_mode->vsync_start = panel_fixed_mode->vdisplay + - dvo_timing->vsync_off; + ((dvo_timing->vsync_off_hi << 4) | dvo_timing->vsync_off_lo); panel_fixed_mode->vsync_end = panel_fixed_mode->vsync_start + - dvo_timing->vsync_pulse_width; + ((dvo_timing->vsync_pulse_width_hi << 4) | + dvo_timing->vsync_pulse_width_lo); panel_fixed_mode->vtotal = panel_fixed_mode->vdisplay + ((dvo_timing->vblank_hi << 8) | dvo_timing->vblank_lo); panel_fixed_mode->clock = dvo_timing->clock * 10; diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h b/drivers/gpu/drm/i915/intel_vbt_defs.h index 8886cab19f98..a92e7762f596 100644 --- a/drivers/gpu/drm/i915/intel_vbt_defs.h +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h @@ -399,10 +399,12 @@ struct lvds_dvo_timing { u8 vblank_hi:4; u8 vactive_hi:4; u8 hsync_off_lo; - u8 hsync_pulse_width; - u8 vsync_pulse_width:4; - u8 vsync_off:4; - u8 rsvd0:6; + u8 hsync_pulse_width_lo; + u8 vsync_pulse_width_lo:4; + u8 vsync_off_lo:4; + u8 vsync_pulse_width_hi:2; + u8 vsync_off_hi:2; + u8 hsync_pulse_width_hi:2; u8 hsync_off_hi:2; u8 himage_lo; u8 vimage_lo; @@ -414,7 +416,7 @@ struct lvds_dvo_timing { u8 digital:2; u8 vsync_positive:1; u8 hsync_positive:1; - u8 rsvd2:1; + u8 non_interlaced:1; } __packed;
struct lvds_pnp_id {
From: Daniel Vetter daniel.vetter@ffwll.ch
[ Upstream commit ae9d2daecf086958a41ad216152ec208d70ba325 ]
fsl is already fully demidlayered in the probe function, but for convenience stuck with drm_put_dev. Call the unregister/unref parts separately, to make sure this driver works correct.
Cc: Philipp Zabel p.zabel@pengutronix.de Cc: CK Hu ck.hu@mediatek.com Reviewed-by: Lucas Stach l.stach@pengutronix.de Signed-off-by: Daniel Vetter daniel.vetter@intel.com Link: http://patchwork.freedesktop.org/patch/msgid/20161208110739.24417-3-daniel.v... Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c index cf83f6507ec8..48dfc163233e 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c @@ -321,7 +321,8 @@ static void mtk_drm_unbind(struct device *dev) { struct mtk_drm_private *private = dev_get_drvdata(dev);
- drm_put_dev(private->drm); + drm_dev_unregister(private->drm); + drm_dev_unref(private->drm); private->drm = NULL; }
From: Maarten Lankhorst maarten.lankhorst@linux.intel.com
[ Upstream commit 0532be078a207d7dd6ad26ebd0834e258acc4ee7 ]
Atomic drivers may set properties like rotation on the same fb, which may require a call to prepare_fb even when framebuffer stays identical.
Instead of handling all the special cases in the core, let the driver decide when prepare_fb and cleanup_fb are noops.
This is a revert of:
commit fcc60b413d14dd06ddbd79ec50e83c4fb2a097ba Author: Keith Packard keithp@keithp.com Date: Sat Jun 4 01:16:22 2016 -0700
drm: Don't prepare or cleanup unchanging frame buffers [v3]
The original commit mentions that this prevents waiting in i915 on all previous rendering during cursor updates, but there are better ways to fix this.
Signed-off-by: Maarten Lankhorst maarten.lankhorst@linux.intel.com Acked-by: Laurent Pinchart laurent.pinchart@ideasonboard.com Signed-off-by: Daniel Vetter daniel.vetter@ffwll.ch Link: http://patchwork.freedesktop.org/patch/msgid/6d82f9b6-9d16-91d1-d176-4a37b09... Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/gpu/drm/drm_atomic_helper.c | 9 --------- 1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 50acd799babe..462783c39878 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -1670,9 +1670,6 @@ int drm_atomic_helper_prepare_planes(struct drm_device *dev,
funcs = plane->helper_private;
- if (!drm_atomic_helper_framebuffer_changed(dev, state, plane_state->crtc)) - continue; - if (funcs->prepare_fb) { ret = funcs->prepare_fb(plane, plane_state); if (ret) @@ -1689,9 +1686,6 @@ int drm_atomic_helper_prepare_planes(struct drm_device *dev, if (j >= i) continue;
- if (!drm_atomic_helper_framebuffer_changed(dev, state, plane_state->crtc)) - continue; - funcs = plane->helper_private;
if (funcs->cleanup_fb) @@ -1958,9 +1952,6 @@ void drm_atomic_helper_cleanup_planes(struct drm_device *dev, for_each_plane_in_state(old_state, plane, plane_state, i) { const struct drm_plane_helper_funcs *funcs;
- if (!drm_atomic_helper_framebuffer_changed(dev, old_state, plane_state->crtc)) - continue; - funcs = plane->helper_private;
if (funcs->cleanup_fb)
From: Masashi Honma masashi.honma@gmail.com
[ Upstream commit 76f43b4c0a9337af22827d78de4f2b8fd5328489 ]
mesh_sync_offset_adjust_tbtt() implements Extensible synchronization framework ([1] 13.13.2 Extensible synchronization framework). It shall not operate the flag "TBTT Adjusting subfield" ([1] 8.4.2.100.8 Mesh Capability), since it is used only for MBCA ([1] 13.13.4 Mesh beacon collision avoidance, see 13.13.4.4.3 TBTT scanning and adjustment procedures for detail). So this patch remove the flag operations.
[1] IEEE Std 802.11 2012
Signed-off-by: Masashi Honma masashi.honma@gmail.com [remove adjusting_tbtt entirely, since it's now unused] Signed-off-by: Johannes Berg johannes.berg@intel.com
Signed-off-by: Sasha Levin alexander.levin@verizon.com --- net/mac80211/ieee80211_i.h | 1 - net/mac80211/mesh.c | 3 --- net/mac80211/mesh_sync.c | 11 ----------- 3 files changed, 15 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h index 34c2add2c455..03dbc6bd8598 100644 --- a/net/mac80211/ieee80211_i.h +++ b/net/mac80211/ieee80211_i.h @@ -681,7 +681,6 @@ struct ieee80211_if_mesh { const struct ieee80211_mesh_sync_ops *sync_ops; s64 sync_offset_clockdrift_max; spinlock_t sync_offset_lock; - bool adjusting_tbtt; /* mesh power save */ enum nl80211_mesh_power_mode nonpeer_pm; int ps_peers_light_sleep; diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c index 50e1b7f78bd4..5c67a696e046 100644 --- a/net/mac80211/mesh.c +++ b/net/mac80211/mesh.c @@ -279,8 +279,6 @@ int mesh_add_meshconf_ie(struct ieee80211_sub_if_data *sdata, /* Mesh PS mode. See IEEE802.11-2012 8.4.2.100.8 */ *pos |= ifmsh->ps_peers_deep_sleep ? IEEE80211_MESHCONF_CAPAB_POWER_SAVE_LEVEL : 0x00; - *pos++ |= ifmsh->adjusting_tbtt ? - IEEE80211_MESHCONF_CAPAB_TBTT_ADJUSTING : 0x00; *pos++ = 0x00;
return 0; @@ -850,7 +848,6 @@ int ieee80211_start_mesh(struct ieee80211_sub_if_data *sdata) ifmsh->mesh_cc_id = 0; /* Disabled */ /* register sync ops from extensible synchronization framework */ ifmsh->sync_ops = ieee80211_mesh_sync_ops_get(ifmsh->mesh_sp_id); - ifmsh->adjusting_tbtt = false; ifmsh->sync_offset_clockdrift_max = 0; set_bit(MESH_WORK_HOUSEKEEPING, &ifmsh->wrkq_flags); ieee80211_mesh_root_setup(ifmsh); diff --git a/net/mac80211/mesh_sync.c b/net/mac80211/mesh_sync.c index faca22cd02b5..75608c07dc7b 100644 --- a/net/mac80211/mesh_sync.c +++ b/net/mac80211/mesh_sync.c @@ -123,7 +123,6 @@ static void mesh_sync_offset_rx_bcn_presp(struct ieee80211_sub_if_data *sdata, */
if (elems->mesh_config && mesh_peer_tbtt_adjusting(elems)) { - clear_sta_flag(sta, WLAN_STA_TOFFSET_KNOWN); msync_dbg(sdata, "STA %pM : is adjusting TBTT\n", sta->sta.addr); goto no_sync; @@ -172,11 +171,9 @@ static void mesh_sync_offset_adjust_tbtt(struct ieee80211_sub_if_data *sdata, struct beacon_data *beacon) { struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh; - u8 cap;
WARN_ON(ifmsh->mesh_sp_id != IEEE80211_SYNC_METHOD_NEIGHBOR_OFFSET); WARN_ON(!rcu_read_lock_held()); - cap = beacon->meshconf->meshconf_cap;
spin_lock_bh(&ifmsh->sync_offset_lock);
@@ -190,21 +187,13 @@ static void mesh_sync_offset_adjust_tbtt(struct ieee80211_sub_if_data *sdata, "TBTT : kicking off TBTT adjustment with clockdrift_max=%lld\n", ifmsh->sync_offset_clockdrift_max); set_bit(MESH_WORK_DRIFT_ADJUST, &ifmsh->wrkq_flags); - - ifmsh->adjusting_tbtt = true; } else { msync_dbg(sdata, "TBTT : max clockdrift=%lld; too small to adjust\n", (long long)ifmsh->sync_offset_clockdrift_max); ifmsh->sync_offset_clockdrift_max = 0; - - ifmsh->adjusting_tbtt = false; } spin_unlock_bh(&ifmsh->sync_offset_lock); - - beacon->meshconf->meshconf_cap = ifmsh->adjusting_tbtt ? - IEEE80211_MESHCONF_CAPAB_TBTT_ADJUSTING | cap : - ~IEEE80211_MESHCONF_CAPAB_TBTT_ADJUSTING & cap; }
static const struct sync_method sync_methods[] = {
From: Adam Thomson Adam.Thomson.Opensource@diasemi.com
[ Upstream commit ac29a8f41740186aee601de99c729530e37ca77c ]
For TDM mode, the I2S data out line can be shared between mutliple codecs. In this scenario, only the active codec should be using the line, and all others should be high impedance. However, currently in the driver this configuration isn't set when capture is inactive, and the line remains driven.
This patch updates the AIF_OUT widget to set the DAI output pin of the device as high impedance when not in use.
Signed-off-by: Adam Thomson Adam.Thomson.Opensource@diasemi.com Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin alexander.levin@verizon.com --- sound/soc/codecs/da7218.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/da7218.c b/sound/soc/codecs/da7218.c index c69e97654fc6..d256ebf9e309 100644 --- a/sound/soc/codecs/da7218.c +++ b/sound/soc/codecs/da7218.c @@ -1634,7 +1634,8 @@ static const struct snd_soc_dapm_widget da7218_dapm_widgets[] = { SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD),
/* DAI */ - SND_SOC_DAPM_AIF_OUT("DAIOUT", "Capture", 0, SND_SOC_NOPM, 0, 0), + SND_SOC_DAPM_AIF_OUT("DAIOUT", "Capture", 0, DA7218_DAI_TDM_CTRL, + DA7218_DAI_OE_SHIFT, DA7218_NO_INVERT), SND_SOC_DAPM_AIF_IN("DAIIN", "Playback", 0, SND_SOC_NOPM, 0, 0),
/* Output Mixers */
From: Ville Syrjälä ville.syrjala@linux.intel.com
[ Upstream commit 1be4d3793d5a93daddcd9be657c429b38ad750a3 ]
The watermark should never exceed the FIFO size, so we need to check against the current FIFO size instead of the theoretical maximum when we clamp the level 0 watermark.
Signed-off-by: Ville Syrjälä ville.syrjala@linux.intel.com Link: http://patchwork.freedesktop.org/patch/msgid/1480354637-14209-4-git-send-ema... Reviewed-by: Maarten Lankhorst maarten.lankhorst@linux.intel.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/gpu/drm/i915/intel_pm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index ad5649259e6a..12bc608833cf 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -1129,13 +1129,13 @@ static void vlv_compute_wm(struct intel_crtc *crtc) /* normal watermarks */ for (level = 0; level < wm_state->num_levels; level++) { int wm = vlv_compute_wm_level(plane, crtc, state, level); - int max_wm = plane->base.type == DRM_PLANE_TYPE_CURSOR ? 63 : 511; + int max_wm = plane->wm.fifo_size;
/* hack */ if (WARN_ON(level == 0 && wm > max_wm)) wm = max_wm;
- if (wm > plane->wm.fifo_size) + if (wm > max_wm) break;
switch (plane->base.type) {
On Wed, Nov 15, 2017 at 02:45:43AM +0000, alexander.levin@verizon.com wrote:
From: Ville Syrjälä ville.syrjala@linux.intel.com
[ Upstream commit 1be4d3793d5a93daddcd9be657c429b38ad750a3 ]
The watermark should never exceed the FIFO size, so we need to check against the current FIFO size instead of the theoretical maximum when we clamp the level 0 watermark.
Signed-off-by: Ville Syrjälä ville.syrjala@linux.intel.com Link: http://patchwork.freedesktop.org/patch/msgid/1480354637-14209-4-git-send-ema... Reviewed-by: Maarten Lankhorst maarten.lankhorst@linux.intel.com Signed-off-by: Sasha Levin alexander.levin@verizon.com
Why are these patches being proposed for stable? They're not straight up fixes for known issues, and there's always a chance that something will break. Who is doing the qa on this?
drivers/gpu/drm/i915/intel_pm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index ad5649259e6a..12bc608833cf 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -1129,13 +1129,13 @@ static void vlv_compute_wm(struct intel_crtc *crtc) /* normal watermarks */ for (level = 0; level < wm_state->num_levels; level++) { int wm = vlv_compute_wm_level(plane, crtc, state, level);
int max_wm = plane->base.type == DRM_PLANE_TYPE_CURSOR ? 63 : 511;
int max_wm = plane->wm.fifo_size;/* hack */ if (WARN_ON(level == 0 && wm > max_wm)) wm = max_wm;
if (wm > plane->wm.fifo_size)
if (wm > max_wm) break;switch (plane->base.type) { -- 2.11.0
On Wed, Nov 15, 2017 at 01:08:05PM +0200, Ville Syrjälä wrote:
On Wed, Nov 15, 2017 at 02:45:43AM +0000, alexander.levin@verizon.com wrote:
From: Ville Syrjälä ville.syrjala@linux.intel.com
[ Upstream commit 1be4d3793d5a93daddcd9be657c429b38ad750a3 ]
The watermark should never exceed the FIFO size, so we need to check against the current FIFO size instead of the theoretical maximum when we clamp the level 0 watermark.
Signed-off-by: Ville Syrjälä ville.syrjala@linux.intel.com Link: https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.freedesktop.or... Reviewed-by: Maarten Lankhorst maarten.lankhorst@linux.intel.com Signed-off-by: Sasha Levin alexander.levin@verizon.com
Why are these patches being proposed for stable? They're not straight up fixes for known issues, and there's always a chance that something will break. Who is doing the qa on this?
Hi Ville,
They were selected automatically as part of a new process we're trying out. If you disagree with the selection I'd be happy to drop it.
On Wed, Nov 15, 2017 at 04:44:54PM +0000, alexander.levin@verizon.com wrote:
On Wed, Nov 15, 2017 at 01:08:05PM +0200, Ville Syrjälä wrote:
On Wed, Nov 15, 2017 at 02:45:43AM +0000, alexander.levin@verizon.com wrote:
From: Ville Syrjälä ville.syrjala@linux.intel.com
[ Upstream commit 1be4d3793d5a93daddcd9be657c429b38ad750a3 ]
The watermark should never exceed the FIFO size, so we need to check against the current FIFO size instead of the theoretical maximum when we clamp the level 0 watermark.
Signed-off-by: Ville Syrjälä ville.syrjala@linux.intel.com Link: https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.freedesktop.or... Reviewed-by: Maarten Lankhorst maarten.lankhorst@linux.intel.com Signed-off-by: Sasha Levin alexander.levin@verizon.com
Why are these patches being proposed for stable? They're not straight up fixes for known issues, and there's always a chance that something will break. Who is doing the qa on this?
Hi Ville,
They were selected automatically as part of a new process we're trying out. If you disagree with the selection I'd be happy to drop it.
How does that automatic process decide that a patch should be backported?
drm and i915 are very fast moving targets so unintended side effects from backported patches is a real possibility. So I would recommend against backporting anything that isn't fixing a real issue affecting users. We do try to add the cc:stable to such patches.
Cc: Greg
On Wed, 15 Nov 2017, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Wed, Nov 15, 2017 at 04:44:54PM +0000, alexander.levin@verizon.com wrote:
On Wed, Nov 15, 2017 at 01:08:05PM +0200, Ville Syrjälä wrote:
On Wed, Nov 15, 2017 at 02:45:43AM +0000, alexander.levin@verizon.com wrote:
From: Ville Syrjälä ville.syrjala@linux.intel.com
[ Upstream commit 1be4d3793d5a93daddcd9be657c429b38ad750a3 ]
The watermark should never exceed the FIFO size, so we need to check against the current FIFO size instead of the theoretical maximum when we clamp the level 0 watermark.
Signed-off-by: Ville Syrjälä ville.syrjala@linux.intel.com Link: https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.freedesktop.or... Reviewed-by: Maarten Lankhorst maarten.lankhorst@linux.intel.com Signed-off-by: Sasha Levin alexander.levin@verizon.com
Why are these patches being proposed for stable? They're not straight up fixes for known issues, and there's always a chance that something will break. Who is doing the qa on this?
Hi Ville,
They were selected automatically as part of a new process we're trying out. If you disagree with the selection I'd be happy to drop it.
How does that automatic process decide that a patch should be backported?
drm and i915 are very fast moving targets so unintended side effects from backported patches is a real possibility. So I would recommend against backporting anything that isn't fixing a real issue affecting users. We do try to add the cc:stable to such patches.
Agreed.
First, I think an automatic backport process is against the stable kernel rules (e.g. "It must fix a real bug that bothers people").
Second, we can't and won't take any responsibility for backports we didn't indicate with Cc: stable, a Fixes: tag, or a specific backport request.
If you think there's a commit that should be backported and is known to fix a user visible issue (as per the stable rules!), please check with us first.
BR, Jani.
On Fri, Nov 17, 2017 at 01:28:05PM +0200, Jani Nikula wrote:
Cc: Greg
On Wed, 15 Nov 2017, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Wed, Nov 15, 2017 at 04:44:54PM +0000, alexander.levin@verizon.com wrote:
On Wed, Nov 15, 2017 at 01:08:05PM +0200, Ville Syrjälä wrote:
On Wed, Nov 15, 2017 at 02:45:43AM +0000, alexander.levin@verizon.com wrote:
From: Ville Syrjälä ville.syrjala@linux.intel.com
[ Upstream commit 1be4d3793d5a93daddcd9be657c429b38ad750a3 ]
The watermark should never exceed the FIFO size, so we need to check against the current FIFO size instead of the theoretical maximum when we clamp the level 0 watermark.
Signed-off-by: Ville Syrjälä ville.syrjala@linux.intel.com Link: https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.freedesktop.or... Reviewed-by: Maarten Lankhorst maarten.lankhorst@linux.intel.com Signed-off-by: Sasha Levin alexander.levin@verizon.com
Why are these patches being proposed for stable? They're not straight up fixes for known issues, and there's always a chance that something will break. Who is doing the qa on this?
Hi Ville,
They were selected automatically as part of a new process we're trying out. If you disagree with the selection I'd be happy to drop it.
How does that automatic process decide that a patch should be backported?
drm and i915 are very fast moving targets so unintended side effects from backported patches is a real possibility. So I would recommend against backporting anything that isn't fixing a real issue affecting users. We do try to add the cc:stable to such patches.
Agreed.
First, I think an automatic backport process is against the stable kernel rules (e.g. "It must fix a real bug that bothers people").
It's finding lots of fixes that did bother people enough to submit a fix for.
Second, we can't and won't take any responsibility for backports we didn't indicate with Cc: stable, a Fixes: tag, or a specific backport request.
Ok, you all are already totally messing with my normal stable workflow, so might as well just trust you all completely. So let's just only take patches that you all do send me in the normal way. It's easy for Sasha to filter out the drm/i915 patches from his results.
Is that ok?
If you think there's a commit that should be backported and is known to fix a user visible issue (as per the stable rules!), please check with us first.
Um, that is what he was doing with the cc: of you all on the patch itself that started this whole conversation...
{sigh}
greg k-h
On Fri, Nov 17, 2017 at 01:41:23PM +0100, Greg KH wrote:
On Fri, Nov 17, 2017 at 01:28:05PM +0200, Jani Nikula wrote:
Cc: Greg
On Wed, 15 Nov 2017, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Wed, Nov 15, 2017 at 04:44:54PM +0000, alexander.levin@verizon.com wrote:
On Wed, Nov 15, 2017 at 01:08:05PM +0200, Ville Syrjälä wrote:
On Wed, Nov 15, 2017 at 02:45:43AM +0000, alexander.levin@verizon.com wrote:
From: Ville Syrjälä ville.syrjala@linux.intel.com
[ Upstream commit 1be4d3793d5a93daddcd9be657c429b38ad750a3 ]
The watermark should never exceed the FIFO size, so we need to check against the current FIFO size instead of the theoretical maximum when we clamp the level 0 watermark.
Signed-off-by: Ville Syrjälä ville.syrjala@linux.intel.com Link: https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.freedesktop.or... Reviewed-by: Maarten Lankhorst maarten.lankhorst@linux.intel.com Signed-off-by: Sasha Levin alexander.levin@verizon.com
Why are these patches being proposed for stable? They're not straight up fixes for known issues, and there's always a chance that something will break. Who is doing the qa on this?
Hi Ville,
They were selected automatically as part of a new process we're trying out. If you disagree with the selection I'd be happy to drop it.
How does that automatic process decide that a patch should be backported?
drm and i915 are very fast moving targets so unintended side effects from backported patches is a real possibility. So I would recommend against backporting anything that isn't fixing a real issue affecting users. We do try to add the cc:stable to such patches.
Agreed.
First, I think an automatic backport process is against the stable kernel rules (e.g. "It must fix a real bug that bothers people").
It's finding lots of fixes that did bother people enough to submit a fix for.
Second, we can't and won't take any responsibility for backports we didn't indicate with Cc: stable, a Fixes: tag, or a specific backport request.
Ok, you all are already totally messing with my normal stable workflow, so might as well just trust you all completely. So let's just only take patches that you all do send me in the normal way. It's easy for Sasha to filter out the drm/i915 patches from his results.
Is that ok?
If you think there's a commit that should be backported and is known to fix a user visible issue (as per the stable rules!), please check with us first.
Um, that is what he was doing with the cc: of you all on the patch itself that started this whole conversation...
And what were the user visible issues fixed by those backports? We can't judge the risk/benefit ratio of a backport without knowing what is supposedly being fixed.
On Fri, Nov 17, 2017 at 02:53:43PM +0200, Ville Syrjälä wrote:
On Fri, Nov 17, 2017 at 01:41:23PM +0100, Greg KH wrote:
On Fri, Nov 17, 2017 at 01:28:05PM +0200, Jani Nikula wrote:
Cc: Greg
On Wed, 15 Nov 2017, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Wed, Nov 15, 2017 at 04:44:54PM +0000, alexander.levin@verizon.com wrote:
On Wed, Nov 15, 2017 at 01:08:05PM +0200, Ville Syrjälä wrote:
On Wed, Nov 15, 2017 at 02:45:43AM +0000, alexander.levin@verizon.com wrote: > From: Ville Syrjälä ville.syrjala@linux.intel.com > > [ Upstream commit 1be4d3793d5a93daddcd9be657c429b38ad750a3 ] > > The watermark should never exceed the FIFO size, so we need to > check against the current FIFO size instead of the theoretical > maximum when we clamp the level 0 watermark. > > Signed-off-by: Ville Syrjälä ville.syrjala@linux.intel.com > Link: https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.freedesktop.or... > Reviewed-by: Maarten Lankhorst maarten.lankhorst@linux.intel.com > Signed-off-by: Sasha Levin alexander.levin@verizon.com
Why are these patches being proposed for stable? They're not straight up fixes for known issues, and there's always a chance that something will break. Who is doing the qa on this?
Hi Ville,
They were selected automatically as part of a new process we're trying out. If you disagree with the selection I'd be happy to drop it.
How does that automatic process decide that a patch should be backported?
drm and i915 are very fast moving targets so unintended side effects from backported patches is a real possibility. So I would recommend against backporting anything that isn't fixing a real issue affecting users. We do try to add the cc:stable to such patches.
Agreed.
First, I think an automatic backport process is against the stable kernel rules (e.g. "It must fix a real bug that bothers people").
It's finding lots of fixes that did bother people enough to submit a fix for.
Second, we can't and won't take any responsibility for backports we didn't indicate with Cc: stable, a Fixes: tag, or a specific backport request.
Ok, you all are already totally messing with my normal stable workflow, so might as well just trust you all completely. So let's just only take patches that you all do send me in the normal way. It's easy for Sasha to filter out the drm/i915 patches from his results.
Is that ok?
If you think there's a commit that should be backported and is known to fix a user visible issue (as per the stable rules!), please check with us first.
Um, that is what he was doing with the cc: of you all on the patch itself that started this whole conversation...
And what were the user visible issues fixed by those backports? We can't judge the risk/benefit ratio of a backport without knowing what is supposedly being fixed.
Ok fine, if you all don't want any patches automatically picked up and backported, that's your choice, just let us know and we will add it to a blacklist or something to prevent it. Your development process must be so perfect that nothing falls through the cracks and forgets to get marked for stable...
greg k-h
Hi Greg, all,
Pardon for the silly question, but I'm struggling to find documentation about this new 'autoselection' process? Where can one read up on it - be that about the tooling or the heuristics used?
I think the above may be the core reason behind the discussion here.
Thanks Emil
On Fri, Nov 17, 2017 at 01:13:27PM +0000, Emil Velikov wrote:
Hi Greg, all,
Pardon for the silly question, but I'm struggling to find documentation about this new 'autoselection' process? Where can one read up on it - be that about the tooling or the heuristics used?
I think the above may be the core reason behind the discussion here.
See my other email on this topic already (hint, it shouldn't matter how the patch is selected if at least one experienced developer feels it might be a valid stable patch...)
thanks,
greg k-h
On Fri, 17 Nov 2017, Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Nov 17, 2017 at 01:28:05PM +0200, Jani Nikula wrote:
Cc: Greg
On Wed, 15 Nov 2017, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Wed, Nov 15, 2017 at 04:44:54PM +0000, alexander.levin@verizon.com wrote:
On Wed, Nov 15, 2017 at 01:08:05PM +0200, Ville Syrjälä wrote:
On Wed, Nov 15, 2017 at 02:45:43AM +0000, alexander.levin@verizon.com wrote:
From: Ville Syrjälä ville.syrjala@linux.intel.com
[ Upstream commit 1be4d3793d5a93daddcd9be657c429b38ad750a3 ]
The watermark should never exceed the FIFO size, so we need to check against the current FIFO size instead of the theoretical maximum when we clamp the level 0 watermark.
Signed-off-by: Ville Syrjälä ville.syrjala@linux.intel.com Link: https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.freedesktop.or... Reviewed-by: Maarten Lankhorst maarten.lankhorst@linux.intel.com Signed-off-by: Sasha Levin alexander.levin@verizon.com
Why are these patches being proposed for stable? They're not straight up fixes for known issues, and there's always a chance that something will break. Who is doing the qa on this?
Hi Ville,
They were selected automatically as part of a new process we're trying out. If you disagree with the selection I'd be happy to drop it.
How does that automatic process decide that a patch should be backported?
drm and i915 are very fast moving targets so unintended side effects from backported patches is a real possibility. So I would recommend against backporting anything that isn't fixing a real issue affecting users. We do try to add the cc:stable to such patches.
Agreed.
First, I think an automatic backport process is against the stable kernel rules (e.g. "It must fix a real bug that bothers people").
It's finding lots of fixes that did bother people enough to submit a fix for.
I still have no idea how this autoselect picks up patches that do *not* have cc: stable nor Fixes: from us. What information do you have that we don't for making that call?
BR, Jani.
Second, we can't and won't take any responsibility for backports we didn't indicate with Cc: stable, a Fixes: tag, or a specific backport request.
Ok, you all are already totally messing with my normal stable workflow, so might as well just trust you all completely. So let's just only take patches that you all do send me in the normal way. It's easy for Sasha to filter out the drm/i915 patches from his results.
Is that ok?
If you think there's a commit that should be backported and is known to fix a user visible issue (as per the stable rules!), please check with us first.
Um, that is what he was doing with the cc: of you all on the patch itself that started this whole conversation...
{sigh}
greg k-h
On Fri, Nov 17, 2017 at 03:01:08PM +0200, Jani Nikula wrote:
On Fri, 17 Nov 2017, Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Nov 17, 2017 at 01:28:05PM +0200, Jani Nikula wrote:
Cc: Greg
On Wed, 15 Nov 2017, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Wed, Nov 15, 2017 at 04:44:54PM +0000, alexander.levin@verizon.com wrote:
On Wed, Nov 15, 2017 at 01:08:05PM +0200, Ville Syrjälä wrote:
On Wed, Nov 15, 2017 at 02:45:43AM +0000, alexander.levin@verizon.com wrote: > From: Ville Syrjälä ville.syrjala@linux.intel.com > > [ Upstream commit 1be4d3793d5a93daddcd9be657c429b38ad750a3 ] > > The watermark should never exceed the FIFO size, so we need to > check against the current FIFO size instead of the theoretical > maximum when we clamp the level 0 watermark. > > Signed-off-by: Ville Syrjälä ville.syrjala@linux.intel.com > Link: https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.freedesktop.or... > Reviewed-by: Maarten Lankhorst maarten.lankhorst@linux.intel.com > Signed-off-by: Sasha Levin alexander.levin@verizon.com
Why are these patches being proposed for stable? They're not straight up fixes for known issues, and there's always a chance that something will break. Who is doing the qa on this?
Hi Ville,
They were selected automatically as part of a new process we're trying out. If you disagree with the selection I'd be happy to drop it.
How does that automatic process decide that a patch should be backported?
drm and i915 are very fast moving targets so unintended side effects from backported patches is a real possibility. So I would recommend against backporting anything that isn't fixing a real issue affecting users. We do try to add the cc:stable to such patches.
Agreed.
First, I think an automatic backport process is against the stable kernel rules (e.g. "It must fix a real bug that bothers people").
It's finding lots of fixes that did bother people enough to submit a fix for.
I still have no idea how this autoselect picks up patches that do *not* have cc: stable nor Fixes: from us. What information do you have that we don't for making that call?
I'll let Sasha describe how he's doing this, but in the end, does it really matter _how_ it is done, vs. the fact that it seems to at least one human reviewer that this is a patch that _should_ be included based on the changelog text and the code patch?
By having this review process that Sasha is providing, he's saying "Here's a patch that I think might be good for stable, do you object?"
If you do, great, no harm done, all is fine, the patch is dropped. If you don't object, just ignore the email and the patch gets merged.
If you don't want any of this to happen for your subsystem at all, then also fine, just let us know and we will ignore it entirely.
thanks,
greg k-h
On Fri, Nov 17, 2017 at 03:01:08PM +0200, Jani Nikula wrote:
I still have no idea how this autoselect picks up patches that do *not* have cc: stable nor Fixes: from us. What information do you have that we don't for making that call?
I think there's a difference in views about the stable tag here. I suspect that the way you see it, if you guys choose not to add a stable tag to a commit this means that you, on purpose do *not* want this commit to go into stable tree.
However, the stable tag is really just a sign for us saying "hey this might need to go into stable trees", and in the same way that having this tag doesn't guarantee that the commit will go into stable, not adding this tag in no way guarantees that it won't.
In reality, authors and maintainers forget to tag, miss fixes, newer authors aren't even aware of the stable process and so on, so we end up with a good chunk of fixes that affect users but don't end up getting fixed in stable trees just because someone forgot a simple tag in his commit message.
The autoselection code tries to determine what a "fix" is based on information from the commit message (so, for example, if "fix", "panic" and "oops" appear in a commit message it's quite likely that this commit is a fix), and various code metrics (for example, commits that add a single condition statement and <5 lines of code are likely to be fixes".
Past that point, it's all a judgement call on my end of whether some commit, based on it's code, commit message, context, etc would be something that we'd want in stable trees or not. I also accept the fact that I may be wrong, but in those cases I'll do my best to learn from it, fix the issue, and improve my process to prevent similar issues in the future.
Also, if we would have strictly followed the "fix a real bug that bothers people" rule, stable trees would mostly likely die since you'd force users (who are usually clueless about the kernel) to do basic triaging and report bugs on LKML, which would never happen. Instead, we try to proactively fix bugs before users have to complain.
Consider fuzzers as an example of the above; syzkaller/trinity find a considerable amount of bugs that don't really affect anyone, but they still should get fixed, right?
From: Masashi Honma masashi.honma@gmail.com
[ Upstream commit 11197d006bcfabf0173a7820a163fcaac420d10e ]
Previously, kernel sends NEW_PEER_CANDIDATE event to user land even if the found peer does not have any room to accept other peer. This causes continuous connection trials.
Signed-off-by: Masashi Honma masashi.honma@gmail.com Signed-off-by: Johannes Berg johannes.berg@intel.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- net/mac80211/mesh_plink.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c index 7fcdcf622655..fcba70e57073 100644 --- a/net/mac80211/mesh_plink.c +++ b/net/mac80211/mesh_plink.c @@ -505,12 +505,14 @@ mesh_sta_info_alloc(struct ieee80211_sub_if_data *sdata, u8 *addr,
/* Userspace handles station allocation */ if (sdata->u.mesh.user_mpm || - sdata->u.mesh.security & IEEE80211_MESH_SEC_AUTHED) - cfg80211_notify_new_peer_candidate(sdata->dev, addr, - elems->ie_start, - elems->total_len, - GFP_KERNEL); - else + sdata->u.mesh.security & IEEE80211_MESH_SEC_AUTHED) { + if (mesh_peer_accepts_plinks(elems) && + mesh_plink_availables(sdata)) + cfg80211_notify_new_peer_candidate(sdata->dev, addr, + elems->ie_start, + elems->total_len, + GFP_KERNEL); + } else sta = __mesh_sta_info_alloc(sdata, addr);
return sta;
From: Ville Syrjälä ville.syrjala@linux.intel.com
[ Upstream commit 467a14d935c6d95b94e4197bf63e264eab4c5d06 ]
Each DSPARB register can house bits for two separate pipes, hence we must protect the registers during reprogramming so that parallel FIFO reconfigurations happening simultaneosly on multiple pipes won't corrupt each others values.
We'll use a new spinlock for this instead of the wm_mutex since we'll have to move the DSPARB programming to happen from the vblank evade critical section, and we can't use mutexes in there.
v2: Document why we use a spinlock instead of a mutex (Maarten)
Cc: Maarten Lankhorst maarten.lankhorst@linux.intel.com Signed-off-by: Ville Syrjälä ville.syrjala@linux.intel.com Link: http://patchwork.freedesktop.org/patch/msgid/1480947208-18468-1-git-send-ema... Reviewed-by: Maarten Lankhorst maarten.lankhorst@linux.intel.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/gpu/drm/i915/i915_drv.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 3 +++ drivers/gpu/drm/i915/intel_pm.c | 6 ++++++ 3 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 7513e7678263..df338e738d47 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -802,6 +802,7 @@ static int i915_driver_init_early(struct drm_i915_private *dev_priv, spin_lock_init(&dev_priv->uncore.lock); spin_lock_init(&dev_priv->mm.object_stat_lock); spin_lock_init(&dev_priv->mmio_flip_lock); + spin_lock_init(&dev_priv->wm.dsparb_lock); mutex_init(&dev_priv->sb_lock); mutex_init(&dev_priv->modeset_restore_lock); mutex_init(&dev_priv->av_mutex); diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 36a665f0e5c9..d120797aec17 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1989,6 +1989,9 @@ struct drm_i915_private { } sagv_status;
struct { + /* protects DSPARB registers on pre-g4x/vlv/chv */ + spinlock_t dsparb_lock; + /* * Raw watermark latency values: * in 0.1us units for WM0, diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 49de4760cc16..ad5649259e6a 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -1221,6 +1221,8 @@ static void vlv_pipe_set_fifo_size(struct intel_crtc *crtc) pipe_name(crtc->pipe), sprite0_start, sprite1_start, fifo_size);
+ spin_lock(&dev_priv->wm.dsparb_lock); + switch (crtc->pipe) { uint32_t dsparb, dsparb2, dsparb3; case PIPE_A: @@ -1277,6 +1279,10 @@ static void vlv_pipe_set_fifo_size(struct intel_crtc *crtc) default: break; } + + POSTING_READ(DSPARB); + + spin_unlock(&dev_priv->wm.dsparb_lock); }
#undef VLV_FIFO
From: Alexey Khoroshilov khoroshilov@ispras.ru
[ Upstream commit d15697de60db5570532fdedb8e13b2251d65b8e3 ]
The driver does not check if mapping dma memory succeed. The patch adds the checks and failure handling.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov khoroshilov@ispras.ru Signed-off-by: Kalle Valo kvalo@codeaurora.org Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/net/wireless/admtek/adm8211.c | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/admtek/adm8211.c b/drivers/net/wireless/admtek/adm8211.c index 0321f85c388c..098c814e22c8 100644 --- a/drivers/net/wireless/admtek/adm8211.c +++ b/drivers/net/wireless/admtek/adm8211.c @@ -413,6 +413,13 @@ static void adm8211_interrupt_rci(struct ieee80211_hw *dev) skb_tail_pointer(newskb), RX_PKT_SIZE, PCI_DMA_FROMDEVICE); + if (pci_dma_mapping_error(priv->pdev, + priv->rx_buffers[entry].mapping)) { + priv->rx_buffers[entry].skb = NULL; + dev_kfree_skb(newskb); + skb = NULL; + /* TODO: update rx dropped stats */ + } } else { skb = NULL; /* TODO: update rx dropped stats */ @@ -1450,6 +1457,12 @@ static int adm8211_init_rings(struct ieee80211_hw *dev) skb_tail_pointer(rx_info->skb), RX_PKT_SIZE, PCI_DMA_FROMDEVICE); + if (pci_dma_mapping_error(priv->pdev, rx_info->mapping)) { + dev_kfree_skb(rx_info->skb); + rx_info->skb = NULL; + break; + } + desc->buffer1 = cpu_to_le32(rx_info->mapping); desc->status = cpu_to_le32(RDES0_STATUS_OWN | RDES0_STATUS_SQL); } @@ -1613,7 +1626,7 @@ static void adm8211_calc_durations(int *dur, int *plcp, size_t payload_len, int }
/* Transmit skb w/adm8211_tx_hdr (802.11 header created by hardware) */ -static void adm8211_tx_raw(struct ieee80211_hw *dev, struct sk_buff *skb, +static int adm8211_tx_raw(struct ieee80211_hw *dev, struct sk_buff *skb, u16 plcp_signal, size_t hdrlen) { @@ -1625,6 +1638,8 @@ static void adm8211_tx_raw(struct ieee80211_hw *dev, struct sk_buff *skb,
mapping = pci_map_single(priv->pdev, skb->data, skb->len, PCI_DMA_TODEVICE); + if (pci_dma_mapping_error(priv->pdev, mapping)) + return -ENOMEM;
spin_lock_irqsave(&priv->lock, flags);
@@ -1657,6 +1672,8 @@ static void adm8211_tx_raw(struct ieee80211_hw *dev, struct sk_buff *skb,
/* Trigger transmit poll */ ADM8211_CSR_WRITE(TDR, 0); + + return 0; }
/* Put adm8211_tx_hdr on skb and transmit */ @@ -1710,7 +1727,10 @@ static void adm8211_tx(struct ieee80211_hw *dev,
txhdr->retry_limit = info->control.rates[0].count;
- adm8211_tx_raw(dev, skb, plcp_signal, hdrlen); + if (adm8211_tx_raw(dev, skb, plcp_signal, hdrlen)) { + /* Drop packet */ + ieee80211_free_txskb(dev, skb); + } }
static int adm8211_alloc_rings(struct ieee80211_hw *dev)
From: Chris Wilson chris@chris-wilson.co.uk
[ Upstream commit 1618bdb89b5d8b47edf42d9c6ea96ecf001ad625 ]
Before we return the request back to the kmem_cache after a failed i915_gem_request_alloc(), we should assert that it has not been added to any global state tracking.
Signed-off-by: Chris Wilson chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen joonas.lahtinen@linux.intel.com Link: http://patchwork.freedesktop.org/patch/msgid/20161125131718.20978-2-chris@ch... Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/gpu/drm/i915/i915_gem_request.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c b/drivers/gpu/drm/i915/i915_gem_request.c index 8832f8ec1583..71e284d7c640 100644 --- a/drivers/gpu/drm/i915/i915_gem_request.c +++ b/drivers/gpu/drm/i915/i915_gem_request.c @@ -455,6 +455,11 @@ i915_gem_request_alloc(struct intel_engine_cs *engine, return req;
err_ctx: + /* Make sure we didn't add ourselves to external state before freeing */ + GEM_BUG_ON(!list_empty(&req->active_list)); + GEM_BUG_ON(!list_empty(&req->priotree.signalers_list)); + GEM_BUG_ON(!list_empty(&req->priotree.waiters_list)); + i915_gem_context_put(ctx); err: kmem_cache_free(dev_priv->requests, req);
From: Pan Bian bianpan2016@163.com
[ Upstream commit 91ca1a8c584f55857b1f6ab20a1d3a1ce7a559bb ]
At the end of function ad7150_write_event_config(), directly returns 0. As a result, the errors will be ignored by the callers. It may be better to return variable "ret".
Signed-off-by: Pan Bian bianpan2016@163.com Signed-off-by: Jonathan Cameron jic23@kernel.org Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/staging/iio/cdc/ad7150.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/iio/cdc/ad7150.c b/drivers/staging/iio/cdc/ad7150.c index 5578a077fcfb..50a5b0c2cc7b 100644 --- a/drivers/staging/iio/cdc/ad7150.c +++ b/drivers/staging/iio/cdc/ad7150.c @@ -274,7 +274,7 @@ static int ad7150_write_event_config(struct iio_dev *indio_dev, error_ret: mutex_unlock(&chip->state_lock);
- return 0; + return ret; }
static int ad7150_read_event_value(struct iio_dev *indio_dev,
From: Pan Bian bianpan2016@163.com
[ Upstream commit db4e5376d058af8924fafd0520a0942d92538d0e ]
In function cm3232_reg_init(), it returns 0 even if the last call to i2c_smbus_write_byte_data() returns a negative value (indicates error). As a result, the return value may be inconsistent with the execution status, and the caller of cm3232_reg_init() will not be able to detect the error. This patch fixes the bug.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188641
Signed-off-by: Pan Bian bianpan2016@163.com Signed-off-by: Jonathan Cameron jic23@kernel.org Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/iio/light/cm3232.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/light/cm3232.c b/drivers/iio/light/cm3232.c index fe89b6823217..263e97235ea0 100644 --- a/drivers/iio/light/cm3232.c +++ b/drivers/iio/light/cm3232.c @@ -119,7 +119,7 @@ static int cm3232_reg_init(struct cm3232_chip *chip) if (ret < 0) dev_err(&chip->client->dev, "Error writing reg_cmd\n");
- return 0; + return ret; }
/**
From: Ville Syrjälä ville.syrjala@linux.intel.com
[ Upstream commit 8d96561a0a31974fec33bd3f3853d6211b7ab738 ]
A modeset on one pipe can update dev_priv->atomic_cdclk_freq without actually touching the hardware, in which case we won't force a modeset on all the pipes, and thus won't lock any of the other pipes either. That means a parallel plane update on another pipe could be looking at a stale dev_priv->atomic_cdcdlk_freq and thus fail to notice when the plane configuration is invalid, or potentially reject a valid update.
To overcome this we must protect writes to atomic_cdclk_freq with all the crtc locks, and thus for reads any single crtc lock will be sufficient protection.
Cc: Maarten Lankhorst maarten.lankhorst@linux.intel.com Signed-off-by: Ville Syrjälä ville.syrjala@linux.intel.com Link: http://patchwork.freedesktop.org/patch/msgid/1479141311-11904-3-git-send-ema... Reviewed-by: Daniel Vetter daniel.vetter@ffwll.ch Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/gpu/drm/i915/i915_drv.h | 9 +++++++- drivers/gpu/drm/i915/intel_display.c | 41 +++++++++++++++++++++++++++++++----- 2 files changed, 44 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index d120797aec17..b9e759ba16c2 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1841,7 +1841,14 @@ struct drm_i915_private {
unsigned int fsb_freq, mem_freq, is_ddr3; unsigned int skl_preferred_vco_freq; - unsigned int cdclk_freq, max_cdclk_freq, atomic_cdclk_freq; + unsigned int cdclk_freq, max_cdclk_freq; + + /* + * For reading holding any crtc lock is sufficient, + * for writing must hold all of them. + */ + unsigned int atomic_cdclk_freq; + unsigned int max_dotclk_freq; unsigned int rawclk_freq; unsigned int hpll_freq; diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index ce32303b3013..bd560a8792ba 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -13894,13 +13894,32 @@ static int haswell_mode_set_planes_workaround(struct drm_atomic_state *state) return 0; }
+static int intel_lock_all_pipes(struct drm_atomic_state *state) +{ + struct drm_crtc *crtc; + + /* Add all pipes to the state */ + for_each_crtc(state->dev, crtc) { + struct drm_crtc_state *crtc_state; + + crtc_state = drm_atomic_get_crtc_state(state, crtc); + if (IS_ERR(crtc_state)) + return PTR_ERR(crtc_state); + } + + return 0; +} + static int intel_modeset_all_pipes(struct drm_atomic_state *state) { struct drm_crtc *crtc; struct drm_crtc_state *crtc_state; int ret = 0;
- /* add all active pipes to the state */ + /* + * Add all pipes to the state, and force + * a modeset on all the active ones. + */ for_each_crtc(state->dev, crtc) { crtc_state = drm_atomic_get_crtc_state(state, crtc); if (IS_ERR(crtc_state)) @@ -13966,12 +13985,24 @@ static int intel_modeset_checks(struct drm_atomic_state *state) if (ret < 0) return ret;
+ /* + * Writes to dev_priv->atomic_cdclk_freq must protected by + * holding all the crtc locks, even if we don't end up + * touching the hardware + */ + if (intel_state->cdclk != dev_priv->atomic_cdclk_freq) { + ret = intel_lock_all_pipes(state); + if (ret < 0) + return ret; + } + + /* All pipes must be switched off while we change the cdclk. */ if (intel_state->dev_cdclk != dev_priv->cdclk_freq || - intel_state->cdclk_pll_vco != dev_priv->cdclk_pll.vco) + intel_state->cdclk_pll_vco != dev_priv->cdclk_pll.vco) { ret = intel_modeset_all_pipes(state); - - if (ret < 0) - return ret; + if (ret < 0) + return ret; + }
DRM_DEBUG_KMS("New cdclk calculated to be atomic %u, actual %u\n", intel_state->cdclk, intel_state->dev_cdclk);
From: Pablo Neira Ayuso pablo@netfilter.org
[ Upstream commit c2e756ff9e699865d294cdc112acfc36419cf5cc ]
Using smp_processor_id() causes splats with PREEMPT_RCU:
[19379.552780] BUG: using smp_processor_id() in preemptible [00000000] code: ping/32389 [19379.552793] caller is debug_smp_processor_id+0x17/0x19 [...] [19379.552823] Call Trace: [19379.552832] [<ffffffff81274e9e>] dump_stack+0x67/0x90 [19379.552837] [<ffffffff8129a4d4>] check_preemption_disabled+0xe5/0xf5 [19379.552842] [<ffffffff8129a4fb>] debug_smp_processor_id+0x17/0x19 [19379.552849] [<ffffffffa07c42dd>] nft_queue_eval+0x35/0x20c [nft_queue]
No need to disable preemption since we only fetch the numeric value, so let's use raw_smp_processor_id() instead.
Signed-off-by: Pablo Neira Ayuso pablo@netfilter.org Signed-off-by: Sasha Levin alexander.levin@verizon.com --- net/netfilter/nft_queue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nft_queue.c b/net/netfilter/nft_queue.c index 393d359a1889..ef4768a451f4 100644 --- a/net/netfilter/nft_queue.c +++ b/net/netfilter/nft_queue.c @@ -38,7 +38,7 @@ static void nft_queue_eval(const struct nft_expr *expr,
if (priv->queues_total > 1) { if (priv->flags & NFT_QUEUE_FLAG_CPU_FANOUT) { - int cpu = smp_processor_id(); + int cpu = raw_smp_processor_id();
queue = priv->queuenum + cpu % priv->queues_total; } else {
From: Geert Uytterhoeven geert@linux-m68k.org
[ Upstream commit dadab2d4e3cf708ceba22ecddd94aedfecb39199 ]
If NO_DMA=y:
ERROR: "bad_dma_ops" [drivers/spi/spi-fsl-dspi.ko] undefined!
Add a dependency on HAS_DMA to fix this.
Signed-off-by: Geert Uytterhoeven geert@linux-m68k.org Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/spi/Kconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index b7995474148c..8e281e47afec 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -365,6 +365,7 @@ config SPI_FSL_SPI config SPI_FSL_DSPI tristate "Freescale DSPI controller" select REGMAP_MMIO + depends on HAS_DMA depends on SOC_VF610 || SOC_LS1021A || ARCH_LAYERSCAPE || COMPILE_TEST help This enables support for the Freescale DSPI controller in master
From: Bob Paauwe bob.j.paauwe@intel.com
[ Upstream commit 812b1d2fe527c3c68d04f379aef850dd02db5945 ]
For BXT, there is only one bit that enables/disables dual-link mode and not different bits depending on which pipe is being used.
Signed-off-by: Bob Paauwe bob.j.paauwe@intel.com Link: http://patchwork.freedesktop.org/patch/msgid/1479767046-3964-1-git-send-emai... Signed-off-by: Ville Syrjälä ville.syrjala@linux.intel.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/gpu/drm/i915/intel_dsi.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index b2e3d3a334f7..a37ce07ba5ad 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -476,7 +476,10 @@ static void intel_dsi_port_enable(struct intel_encoder *encoder) if (intel_dsi->ports == (BIT(PORT_A) | BIT(PORT_C))) { temp |= (intel_dsi->dual_link - 1) << DUAL_LINK_MODE_SHIFT; - temp |= intel_crtc->pipe ? + if (IS_BROXTON(dev_priv)) + temp |= LANE_CONFIGURATION_DUAL_LINK_A; + else + temp |= intel_crtc->pipe ? LANE_CONFIGURATION_DUAL_LINK_B : LANE_CONFIGURATION_DUAL_LINK_A; }
From: Jose Abreu Jose.Abreu@synopsys.com
[ Upstream commit 6fce983f9b3ef51d47e647b2cff15049ef803781 ]
We can no longer rely on the return value of devm_snd_dmaengine_pcm_register(...) to check if the DMA handle is declared in the DT.
Previously this check activated PIO mode but currently dma_request_chan returns either a valid channel or -EPROBE_DEFER.
In order to activate PIO mode check instead if the interrupt line is declared. This reflects better what is documented in the DT bindings (see Documentation/devicetree/bindings/sound/ designware-i2s.txt).
Also, initialize use_pio variable which was never being set causing PIO mode to never work.
Signed-off-by: Jose Abreu joabreu@synopsys.com Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin alexander.levin@verizon.com --- sound/soc/dwc/designware_i2s.c | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c index 2998954a1c74..bdf8398cbc81 100644 --- a/sound/soc/dwc/designware_i2s.c +++ b/sound/soc/dwc/designware_i2s.c @@ -681,22 +681,19 @@ static int dw_i2s_probe(struct platform_device *pdev) }
if (!pdata) { - ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, 0); - if (ret == -EPROBE_DEFER) { - dev_err(&pdev->dev, - "failed to register PCM, deferring probe\n"); - return ret; - } else if (ret) { - dev_err(&pdev->dev, - "Could not register DMA PCM: %d\n" - "falling back to PIO mode\n", ret); + if (irq >= 0) { ret = dw_pcm_register(pdev); - if (ret) { - dev_err(&pdev->dev, - "Could not register PIO PCM: %d\n", + dev->use_pio = true; + } else { + ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, + 0); + dev->use_pio = false; + } + + if (ret) { + dev_err(&pdev->dev, "could not register pcm: %d\n", ret); - goto err_clk_disable; - } + goto err_clk_disable; } }
From: Colin Ian King colin.king@canonical.com
[ Upstream commit 0ea617a298dcdc2251b4e10f83ac3f3e627b66e3 ]
On an error, snd_ctl_add already free's kctrl, so calling snd_ctl_free_one to free it again leads to a double free error. Fix this by removing the extraneous snd_ctl_free_one call.
Issue found using static analysis with CoverityScan, CID 1372908
Signed-off-by: Colin Ian King colin.king@canonical.com Acked-by: Kuninori Morimoto kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin alexander.levin@verizon.com --- sound/soc/sh/rcar/core.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c index f18141098b50..91b444db575e 100644 --- a/sound/soc/sh/rcar/core.c +++ b/sound/soc/sh/rcar/core.c @@ -978,10 +978,8 @@ static int __rsnd_kctrl_new(struct rsnd_mod *mod, return -ENOMEM;
ret = snd_ctl_add(card, kctrl); - if (ret < 0) { - snd_ctl_free_one(kctrl); + if (ret < 0) return ret; - }
cfg->update = update; cfg->card = card;
From: Romain Perier romain.perier@free-electrons.com
[ Upstream commit 8759fec4af222f338d08f8f1a7ad6a77ca6cb301 ]
Currently, inner IV/DIGEST data are only copied once into the hash engines and not set explicitly before launching a request that is not a first frag. This is an issue especially when multiple ahash reqs are computed in parallel or chained with cipher request, as the state of the request being computed is not updated into the hash engine. It leads to non-deterministic corrupted digest results.
Fixes: commit 2786cee8e50b ("crypto: marvell - Move SRAM I/O operations to step functions") Signed-off-by: Romain Perier romain.perier@free-electrons.com Acked-by: Boris Brezillon boris.brezillon@free-electrons.com Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu herbert@gondor.apana.org.au Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/crypto/marvell/cesa.h | 3 ++- drivers/crypto/marvell/hash.c | 34 +++++++++++++++++++++++++++++++++- drivers/crypto/marvell/tdma.c | 9 ++++++++- 3 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h index e423d33decd4..36291840a12c 100644 --- a/drivers/crypto/marvell/cesa.h +++ b/drivers/crypto/marvell/cesa.h @@ -273,7 +273,8 @@ struct mv_cesa_op_ctx { #define CESA_TDMA_SRC_IN_SRAM BIT(30) #define CESA_TDMA_END_OF_REQ BIT(29) #define CESA_TDMA_BREAK_CHAIN BIT(28) -#define CESA_TDMA_TYPE_MSK GENMASK(27, 0) +#define CESA_TDMA_SET_STATE BIT(27) +#define CESA_TDMA_TYPE_MSK GENMASK(26, 0) #define CESA_TDMA_DUMMY 0 #define CESA_TDMA_DATA 1 #define CESA_TDMA_OP 2 diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c index 77712b375b84..662cf4ddb04b 100644 --- a/drivers/crypto/marvell/hash.c +++ b/drivers/crypto/marvell/hash.c @@ -280,13 +280,32 @@ static void mv_cesa_ahash_std_prepare(struct ahash_request *req) sreq->offset = 0; }
+static void mv_cesa_ahash_dma_step(struct ahash_request *req) +{ + struct mv_cesa_ahash_req *creq = ahash_request_ctx(req); + struct mv_cesa_req *base = &creq->base; + + /* We must explicitly set the digest state. */ + if (base->chain.first->flags & CESA_TDMA_SET_STATE) { + struct mv_cesa_engine *engine = base->engine; + int i; + + /* Set the hash state in the IVDIG regs. */ + for (i = 0; i < ARRAY_SIZE(creq->state); i++) + writel_relaxed(creq->state[i], engine->regs + + CESA_IVDIG(i)); + } + + mv_cesa_dma_step(base); +} + static void mv_cesa_ahash_step(struct crypto_async_request *req) { struct ahash_request *ahashreq = ahash_request_cast(req); struct mv_cesa_ahash_req *creq = ahash_request_ctx(ahashreq);
if (mv_cesa_req_get_type(&creq->base) == CESA_DMA_REQ) - mv_cesa_dma_step(&creq->base); + mv_cesa_ahash_dma_step(ahashreq); else mv_cesa_ahash_std_step(ahashreq); } @@ -562,11 +581,15 @@ static int mv_cesa_ahash_dma_req_init(struct ahash_request *req) struct mv_cesa_ahash_dma_iter iter; struct mv_cesa_op_ctx *op = NULL; unsigned int frag_len; + bool set_state = false; int ret;
basereq->chain.first = NULL; basereq->chain.last = NULL;
+ if (!mv_cesa_mac_op_is_first_frag(&creq->op_tmpl)) + set_state = true; + if (creq->src_nents) { ret = dma_map_sg(cesa_dev->dev, req->src, creq->src_nents, DMA_TO_DEVICE); @@ -650,6 +673,15 @@ static int mv_cesa_ahash_dma_req_init(struct ahash_request *req) basereq->chain.last->flags |= (CESA_TDMA_END_OF_REQ | CESA_TDMA_BREAK_CHAIN);
+ if (set_state) { + /* + * Put the CESA_TDMA_SET_STATE flag on the first tdma desc to + * let the step logic know that the IVDIG registers should be + * explicitly set before launching a TDMA chain. + */ + basereq->chain.first->flags |= CESA_TDMA_SET_STATE; + } + return 0;
err_free_tdma: diff --git a/drivers/crypto/marvell/tdma.c b/drivers/crypto/marvell/tdma.c index 9fd7a5fbaa1b..0cda6e3f2b4b 100644 --- a/drivers/crypto/marvell/tdma.c +++ b/drivers/crypto/marvell/tdma.c @@ -112,7 +112,14 @@ void mv_cesa_tdma_chain(struct mv_cesa_engine *engine, last->next = dreq->chain.first; engine->chain.last = dreq->chain.last;
- if (!(last->flags & CESA_TDMA_BREAK_CHAIN)) + /* + * Break the DMA chain if the CESA_TDMA_BREAK_CHAIN is set on + * the last element of the current chain, or if the request + * being queued needs the IV regs to be set before lauching + * the request. + */ + if (!(last->flags & CESA_TDMA_BREAK_CHAIN) && + !(dreq->chain.first->flags & CESA_TDMA_SET_STATE)) last->next_dma = dreq->chain.first->cur_dma; } }
From: Pan Bian bianpan2016@163.com
[ Upstream commit 73ba39ab9307340dc98ec3622891314bbc09cc2e ]
In function btrfs_uuid_tree_iterate(), errno is assigned to variable ret on errors. However, it directly returns 0. It may be better to return ret. This patch also removes the warning, because the caller already prints a warning.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188731 Signed-off-by: Pan Bian bianpan2016@163.com Reviewed-by: Omar Sandoval osandov@fb.com [ edited subject ] Signed-off-by: David Sterba dsterba@suse.com
Signed-off-by: Sasha Levin alexander.levin@verizon.com --- fs/btrfs/uuid-tree.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/btrfs/uuid-tree.c b/fs/btrfs/uuid-tree.c index 7fc89e4adb41..83bb2f2aa83c 100644 --- a/fs/btrfs/uuid-tree.c +++ b/fs/btrfs/uuid-tree.c @@ -351,7 +351,5 @@ int btrfs_uuid_tree_iterate(struct btrfs_fs_info *fs_info,
out: btrfs_free_path(path); - if (ret) - btrfs_warn(fs_info, "btrfs_uuid_tree_iterate failed %d", ret); - return 0; + return ret; }
From: Florian Westphal fw@strlen.de
[ Upstream commit 3e38df136e453aa69eb4472108ebce2fb00b1ba6 ]
BUG: KASAN: slab-out-of-bounds in nf_tables_rule_destroy+0xf1/0x130 at addr ffff88006a4c35c8 Read of size 8 by task nft/1607
When we've destroyed last valid expr, nft_expr_next() returns an invalid expr. We must not dereference it unless it passes != nft_expr_last() check.
Signed-off-by: Florian Westphal fw@strlen.de Signed-off-by: Pablo Neira Ayuso pablo@netfilter.org Signed-off-by: Sasha Levin alexander.levin@verizon.com --- net/netfilter/nf_tables_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c index 778fcdb83225..fa3ef25441e5 100644 --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -2068,7 +2068,7 @@ static void nf_tables_rule_destroy(const struct nft_ctx *ctx, * is called on error from nf_tables_newrule(). */ expr = nft_expr_first(rule); - while (expr->ops && expr != nft_expr_last(rule)) { + while (expr != nft_expr_last(rule) && expr->ops) { nf_tables_expr_destroy(ctx, expr); expr = nft_expr_next(expr); }
From: Richard Fitzgerald rf@opensource.wolfsonmicro.com
[ Upstream commit 1cab2a84f470e15ecc8e5143bfe9398c6e888032 ]
Protect against corrupt firmware files by ensuring that the length we get for the data in a region actually lies within the available firmware file data buffer.
Signed-off-by: Richard Fitzgerald rf@opensource.wolfsonmicro.com Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin alexander.levin@verizon.com --- sound/soc/codecs/wm_adsp.c | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c index 3bdd81930486..757af795cebd 100644 --- a/sound/soc/codecs/wm_adsp.c +++ b/sound/soc/codecs/wm_adsp.c @@ -1365,7 +1365,7 @@ static int wm_adsp_load(struct wm_adsp *dsp) const struct wmfw_region *region; const struct wm_adsp_region *mem; const char *region_name; - char *file, *text; + char *file, *text = NULL; struct wm_adsp_buf *buf; unsigned int reg; int regions = 0; @@ -1526,10 +1526,21 @@ static int wm_adsp_load(struct wm_adsp *dsp) regions, le32_to_cpu(region->len), offset, region_name);
+ if ((pos + le32_to_cpu(region->len) + sizeof(*region)) > + firmware->size) { + adsp_err(dsp, + "%s.%d: %s region len %d bytes exceeds file length %zu\n", + file, regions, region_name, + le32_to_cpu(region->len), firmware->size); + ret = -EINVAL; + goto out_fw; + } + if (text) { memcpy(text, region->data, le32_to_cpu(region->len)); adsp_info(dsp, "%s: %s\n", file, text); kfree(text); + text = NULL; }
if (reg) { @@ -1574,6 +1585,7 @@ static int wm_adsp_load(struct wm_adsp *dsp) regmap_async_complete(regmap); wm_adsp_buf_free(&buf_list); release_firmware(firmware); + kfree(text); out: kfree(file);
@@ -2054,6 +2066,17 @@ static int wm_adsp_load_coeff(struct wm_adsp *dsp) }
if (reg) { + if ((pos + le32_to_cpu(blk->len) + sizeof(*blk)) > + firmware->size) { + adsp_err(dsp, + "%s.%d: %s region len %d bytes exceeds file length %zu\n", + file, blocks, region_name, + le32_to_cpu(blk->len), + firmware->size); + ret = -EINVAL; + goto out_fw; + } + buf = wm_adsp_buf_alloc(blk->data, le32_to_cpu(blk->len), &buf_list);
From: Heiko Carstens heiko.carstens@de.ibm.com
[ Upstream commit cabab3f9f5ca077535080b3252e6168935b914af ]
s390 version of commit 334bb7738764 ("x86/kbuild: enable modversions for symbols exported from asm") so we get also rid of all these warnings:
WARNING: EXPORT symbol "_mcount" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "memcpy" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "memmove" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "memset" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "save_fpu_regs" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "sie64a" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "sie_exit" [vmlinux] version generation failed, symbol will not be versioned.
Signed-off-by: Heiko Carstens heiko.carstens@de.ibm.com Signed-off-by: Martin Schwidefsky schwidefsky@de.ibm.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- arch/s390/include/asm/asm-prototypes.h | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 arch/s390/include/asm/asm-prototypes.h
diff --git a/arch/s390/include/asm/asm-prototypes.h b/arch/s390/include/asm/asm-prototypes.h new file mode 100644 index 000000000000..2c3413b0ca52 --- /dev/null +++ b/arch/s390/include/asm/asm-prototypes.h @@ -0,0 +1,8 @@ +#ifndef _ASM_S390_PROTOTYPES_H + +#include <linux/kvm_host.h> +#include <linux/ftrace.h> +#include <asm/fpu/api.h> +#include <asm-generic/asm-prototypes.h> + +#endif /* _ASM_S390_PROTOTYPES_H */
From: Hans Verkuil hansverk@cisco.com
[ Upstream commit a24f56d47930492c94ef6875bf45adf7607ca1a4 ]
This is a 2.0 only message, so it should return Feature Abort if the adapter is configured for CEC version 1.4.
Right now it does nothing, which means that the sender will time out.
Signed-off-by: Hans Verkuil hansverk@cisco.com Signed-off-by: Mauro Carvalho Chehab mchehab@s-opensource.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/staging/media/cec/cec-adap.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/cec/cec-adap.c b/drivers/staging/media/cec/cec-adap.c index d1f186745ff9..9bdc04a2aa6c 100644 --- a/drivers/staging/media/cec/cec-adap.c +++ b/drivers/staging/media/cec/cec-adap.c @@ -1557,9 +1557,9 @@ static int cec_receive_notify(struct cec_adapter *adap, struct cec_msg *msg, }
case CEC_MSG_GIVE_FEATURES: - if (adap->log_addrs.cec_version >= CEC_OP_CEC_VERSION_2_0) - return cec_report_features(adap, la_idx); - return 0; + if (adap->log_addrs.cec_version < CEC_OP_CEC_VERSION_2_0) + return cec_feature_abort(adap, msg); + return cec_report_features(adap, la_idx);
default: /*
From: Hans Verkuil hansverk@cisco.com
[ Upstream commit 120476123646ba3619c90db7bcbc6f8eea53c990 ]
When a pending message was canceled (e.g. due to a timeout), then the old tx_status info was overwritten instead of ORed. The same happened with the tx_error_cnt field. So just modify them instead of overwriting them.
Signed-off-by: Hans Verkuil hans.verkuil@cisco.com Signed-off-by: Mauro Carvalho Chehab mchehab@s-opensource.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/staging/media/cec/cec-adap.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/cec/cec-adap.c b/drivers/staging/media/cec/cec-adap.c index 057c9b5ab1e5..d1f186745ff9 100644 --- a/drivers/staging/media/cec/cec-adap.c +++ b/drivers/staging/media/cec/cec-adap.c @@ -288,10 +288,10 @@ static void cec_data_cancel(struct cec_data *data)
/* Mark it as an error */ data->msg.tx_ts = ktime_get_ns(); - data->msg.tx_status = CEC_TX_STATUS_ERROR | - CEC_TX_STATUS_MAX_RETRIES; + data->msg.tx_status |= CEC_TX_STATUS_ERROR | + CEC_TX_STATUS_MAX_RETRIES; + data->msg.tx_error_cnt++; data->attempts = 0; - data->msg.tx_error_cnt = 1; /* Queue transmitted message for monitoring purposes */ cec_queue_msg_monitor(data->adap, &data->msg, 1);
From: Hans Verkuil hansverk@cisco.com
[ Upstream commit 7af26f889eb67db272021a939f7d4a57e96dd961 ]
The loop that sets the unused logical addresses to INVALID should be done before 'configured' is set to true. This ensures that cec_log_addrs is consistent before it will be used.
Signed-off-by: Hans Verkuil hansverk@cisco.com Signed-off-by: Mauro Carvalho Chehab mchehab@s-opensource.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/staging/media/cec/cec-adap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/cec/cec-adap.c b/drivers/staging/media/cec/cec-adap.c index 9bdc04a2aa6c..499d7bfe7147 100644 --- a/drivers/staging/media/cec/cec-adap.c +++ b/drivers/staging/media/cec/cec-adap.c @@ -1062,6 +1062,8 @@ static int cec_config_thread_func(void *arg) for (i = 1; i < las->num_log_addrs; i++) las->log_addr[i] = CEC_LOG_ADDR_INVALID; } + for (i = las->num_log_addrs; i < CEC_MAX_LOG_ADDRS; i++) + las->log_addr[i] = CEC_LOG_ADDR_INVALID; adap->is_configured = true; adap->is_configuring = false; cec_post_state_event(adap); @@ -1079,8 +1081,6 @@ static int cec_config_thread_func(void *arg) cec_report_features(adap, i); cec_report_phys_addr(adap, i); } - for (i = las->num_log_addrs; i < CEC_MAX_LOG_ADDRS; i++) - las->log_addr[i] = CEC_LOG_ADDR_INVALID; mutex_lock(&adap->lock); adap->kthread_config = NULL; mutex_unlock(&adap->lock);
From: Daniel Verkamp daniel.verkamp@intel.com
[ Upstream commit 6c73f949300f17851f53fa80c9d1611ccd6909d3 ]
The Set Features implementation for Keep Alive Timer was using the wrong structure when retrieving the KATO value; it was treating the Set Features command as a Property Set command.
The NVMe spec defines the Keep Alive Timer feature as having one input in CDW11 (4 bytes at offset 44 in the command) whereas the code was reading 8 bytes at offset 48.
Since the Linux NVMe over Fabrics host never sets this feature, this code has presumably never been tested.
Signed-off-by: Daniel Verkamp daniel.verkamp@intel.com Signed-off-by: Christoph Hellwig hch@lst.de Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/nvme/target/admin-cmd.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/nvme/target/admin-cmd.c b/drivers/nvme/target/admin-cmd.c index 6fe4c48a21e4..f791d46fe50f 100644 --- a/drivers/nvme/target/admin-cmd.c +++ b/drivers/nvme/target/admin-cmd.c @@ -381,7 +381,6 @@ static void nvmet_execute_set_features(struct nvmet_req *req) { struct nvmet_subsys *subsys = req->sq->ctrl->subsys; u32 cdw10 = le32_to_cpu(req->cmd->common.cdw10[0]); - u64 val; u32 val32; u16 status = 0;
@@ -391,8 +390,7 @@ static void nvmet_execute_set_features(struct nvmet_req *req) (subsys->max_qid - 1) | ((subsys->max_qid - 1) << 16)); break; case NVME_FEAT_KATO: - val = le64_to_cpu(req->cmd->prop_set.value); - val32 = val & 0xffff; + val32 = le32_to_cpu(req->cmd->common.cdw10[1]); req->sq->ctrl->kato = DIV_ROUND_UP(val32, 1000); nvmet_set_result(req, req->sq->ctrl->kato); break;
From: Juergen Gross jgross@suse.com
[ Upstream commit 639b08810d6ad74ded2c5f6e233c4fcb9d147168 ]
When accessing Xenstore in a transaction the user is specifying a transaction id which he normally obtained from Xenstore when starting the transaction. Xenstore is validating a transaction id against all known transaction ids of the connection the request came in. As all requests of a domain not being the one where Xenstore lives share one connection, validation of transaction ids of different users of Xenstore in that domain should be done by the kernel of that domain being the multiplexer between the Xenstore users in that domain and Xenstore.
In order to prohibit one Xenstore user "hijacking" a transaction from another user the xenbus driver has to verify a given transaction id against all known transaction ids of the user before forwarding it to Xenstore.
Signed-off-by: Juergen Gross jgross@suse.com Reviewed-by: Boris Ostrovsky boris.ostrovsky@oracle.com Signed-off-by: Juergen Gross jgross@suse.com Signed-off-by: Sasha Levin alexander.levin@verizon.com --- drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c index 1e8be12ebb55..0a3c6762df1b 100644 --- a/drivers/xen/xenbus/xenbus_dev_frontend.c +++ b/drivers/xen/xenbus/xenbus_dev_frontend.c @@ -316,7 +316,7 @@ static int xenbus_write_transaction(unsigned msg_type, rc = -ENOMEM; goto out; } - } else if (msg_type == XS_TRANSACTION_END) { + } else if (u->u.msg.tx_id != 0) { list_for_each_entry(trans, &u->transactions, list) if (trans->handle.id == u->u.msg.tx_id) break;
linux-stable-mirror@lists.linaro.org
-
alexander.levin＠verizon.com -
Emil Velikov -
Greg KH -
Jani Nikula -
Ville Syrjälä