[PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid resource if buffer length too long

[PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid resource if buffer length too long

[alexander.levin]

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);
-- 
2.11.0

[PATCH AUTOSEL for 4.9 05/56] PCI: Apply _HPX settings only to relevant devices

[alexander.levin]

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);
-- 
2.11.0

[PATCH AUTOSEL for 4.9 04/56] RDS: RDMA: fix the ib_map_mr_sg_zbva() argument

[alexander.levin]

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;
 
-- 
2.11.0

[PATCH AUTOSEL for 4.9 02/56] RDS: make message size limit compliant with spec

[alexander.levin]

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;
-- 
2.11.0

[PATCH AUTOSEL for 4.9 03/56] RDS: RDMA: return appropriate error on rdma map failures

[alexander.levin]

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",
-- 
2.11.0

[PATCH AUTOSEL for 4.9 07/56] clk: sunxi-ng: A31: Fix spdif clock register

[alexander.levin]

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);
-- 
2.11.0

[PATCH AUTOSEL for 4.9 08/56] clk: sunxi-ng: fix PLL_CPUX adjusting on A33

[alexander.levin]

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);
-- 
2.11.0

[PATCH AUTOSEL for 4.9 06/56] drm/sun4i: Fix a return value in case of error

[alexander.levin]

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),
-- 
2.11.0

[PATCH AUTOSEL for 4.9 12/56] net: Allow IP_MULTICAST_IF to set index to L3 slave

[alexander.levin]

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;
-- 
2.11.0

[PATCH AUTOSEL for 4.9 10/56] fscrypt: use ENOKEY when file cannot be created w/o key

[alexander.levin]

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;
 		}
 
-- 
2.11.0

[PATCH AUTOSEL for 4.9 09/56] dmaengine: zx: set DMA_CYCLIC cap_mask bit

[alexander.levin]

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;
-- 
2.11.0

[PATCH AUTOSEL for 4.9 11/56] fscrypt: use ENOTDIR when setting encryption policy on nondirectory

[alexander.levin]

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))
-- 
2.11.0

[PATCH AUTOSEL for 4.9 13/56] net: 3com: typhoon: typhoon_init_one: make return values more specific

[alexander.levin]

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;
 	}
 
-- 
2.11.0

[PATCH AUTOSEL for 4.9 15/56] drm/armada: Fix compile fail

[alexander.levin]

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-email-daniel.vetter@ffwll.ch
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)
-- 
2.11.0

[PATCH AUTOSEL for 4.9 14/56] net: 3com: typhoon: typhoon_init_one: fix incorrect return values

[alexander.levin]

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;
 	}
-- 
2.11.0

[PATCH AUTOSEL for 4.9 16/56] rt2800: set minimum MPDU and PSDU lengths to sane values

[alexander.levin]

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(&reg, MAX_LEN_CFG_MAX_PSDU, 2);
 	else
 		rt2x00_set_field32(&reg, MAX_LEN_CFG_MAX_PSDU, 1);
-	rt2x00_set_field32(&reg, MAX_LEN_CFG_MIN_PSDU, 0);
-	rt2x00_set_field32(&reg, MAX_LEN_CFG_MIN_MPDU, 0);
+	rt2x00_set_field32(&reg, MAX_LEN_CFG_MIN_PSDU, 10);
+	rt2x00_set_field32(&reg, MAX_LEN_CFG_MIN_MPDU, 10);
 	rt2800_register_write(rt2x00dev, MAX_LEN_CFG, reg);
 
 	rt2800_register_read(rt2x00dev, LED_CFG, &reg);
-- 
2.11.0

[PATCH AUTOSEL for 4.9 17/56] adm80211: return an error if adm8211_alloc_rings() fails

[alexander.levin]

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;
-- 
2.11.0

[PATCH AUTOSEL for 4.9 18/56] mwifiex: sdio: fix use after free issue for save_adapter

[alexander.levin]

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);
 }
 
-- 
2.11.0

[PATCH AUTOSEL for 4.9 21/56] ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats()

[alexander.levin]

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);
-- 
2.11.0

[PATCH AUTOSEL for 4.9 20/56] ath10k: ignore configuring the incorrect board_id

[alexander.levin]

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;
-- 
2.11.0

[PATCH AUTOSEL for 4.9 19/56] ath10k: fix incorrect txpower set by P2P_DEVICE interface

[alexander.levin]

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) {
-- 
2.11.0

[PATCH AUTOSEL for 4.9 25/56] ALSA: hda - Apply ALC269_FIXUP_NO_SHUTUP on HDA_FIXUP_ACT_PROBE

[alexander.levin]

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;
 	}
-- 
2.11.0

[PATCH AUTOSEL for 4.9 23/56] bnxt_en: Set default completion ring for async events.

[alexander.levin]

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++) {
-- 
2.11.0

[PATCH AUTOSEL for 4.9 22/56] pinctrl: sirf: atlas7: Add missing 'of_node_put()'

[alexander.levin]

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;
 
-- 
2.11.0

[PATCH AUTOSEL for 4.9 24/56] ath10k: set CTS protection VDEV param only if VDEV is up

[alexander.levin]

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;
 
-- 
2.11.0

[PATCH AUTOSEL for 4.9 26/56] gpio: mockup: dynamically allocate memory for chip name

[alexander.levin]

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 {
-- 
2.11.0

[PATCH AUTOSEL for 4.9 29/56] clk: qcom: ipq4019: Add all the frequencies for apss cpu

[alexander.levin]

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),
 	{ }
 };
 
-- 
2.11.0

[PATCH AUTOSEL for 4.9 27/56] drm: Apply range restriction after color adjustment when allocation

[alexander.levin]

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@chris-wilson.co.uk
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;
 
-- 
2.11.0

[PATCH AUTOSEL for 4.9 28/56] drm/915: Parsing the missed out DTD fields from the VBT

[alexander.levin]

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-email-madhav.chauhan@intel.com
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 {
-- 
2.11.0

[PATCH AUTOSEL for 4.9 30/56] drm/atomic: Unconditionally call prepare_fb.

[alexander.levin]

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-4a37b09afc44@linux.intel.com
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)
-- 
2.11.0

[PATCH AUTOSEL for 4.9 32/56] drm/mediatek: don't use drm_put_dev

[alexander.levin]

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.vetter@ffwll.ch
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;
 }
 
-- 
2.11.0

[PATCH AUTOSEL for 4.9 31/56] ASoC: da7218: Set DAI output pin high impedance when not in use

[alexander.levin]

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 */
-- 
2.11.0

Re: [PATCH AUTOSEL for 4.9 31/56] ASoC: da7218: Set DAI output pin high impedance when not in use

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 337 bytes --]

On Wed, Nov 15, 2017 at 02:45:42AM +0000, alexander.levin@verizon.com wrote:

> This patch updates the AIF_OUT widget to set the DAI output pin of
> the device as high impedance when not in use.

This will leave the line floating which EEs don't always like.  It's
probably OK and hasn't lead to any reports in mainline yet but still...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH AUTOSEL for 4.9 31/56] ASoC: da7218: Set DAI output pin high impedance when not in use

[alexander.levin]

On Wed, Nov 15, 2017 at 12:19:18PM +0000, Mark Brown wrote:
>On Wed, Nov 15, 2017 at 02:45:42AM +0000, alexander.levin@verizon.com wrote:
>
>> This patch updates the AIF_OUT widget to set the DAI output pin of
>> the device as high impedance when not in use.
>
>This will leave the line floating which EEs don't always like.  It's
>probably OK and hasn't lead to any reports in mainline yet but still...

The idea I got from the patch is that output will not be working if
there are multiple codecs?

-- 

Thanks,
Sasha

RE: [PATCH AUTOSEL for 4.9 31/56] ASoC: da7218: Set DAI output pin high impedance when not in use

[Adam Thomson]

On 15 November 2017 16:43, alexander.levin@verizon.com wrote:

> On Wed, Nov 15, 2017 at 12:19:18PM +0000, Mark Brown wrote:
> >On Wed, Nov 15, 2017 at 02:45:42AM +0000, alexander.levin@verizon.com wrote:
> >
> >> This patch updates the AIF_OUT widget to set the DAI output pin of
> >> the device as high impedance when not in use.
> >
> >This will leave the line floating which EEs don't always like.  It's
> >probably OK and hasn't lead to any reports in mainline yet but still...
> 
> The idea I got from the patch is that output will not be working if
> there are multiple codecs?

Yes, if there are multiple codecs sharing the same DAI line for capture as
DA7217/8, and we don't set this to high impedance, then it will interfere with
the other codecs' capture data.

Re: [PATCH AUTOSEL for 4.9 31/56] ASoC: da7218: Set DAI output pin high impedance when not in use

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

On Wed, Nov 15, 2017 at 04:55:03PM +0000, Adam Thomson wrote:
> On 15 November 2017 16:43, alexander.levin@verizon.com wrote:

> > The idea I got from the patch is that output will not be working if
> > there are multiple codecs?

> Yes, if there are multiple codecs sharing the same DAI line for capture as
> DA7217/8, and we don't set this to high impedance, then it will interfere with
> the other codecs' capture data.

...which means that any existing stable users who are affected must have
their own fix, it just wouldn't have worked.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH AUTOSEL for 4.9 33/56] mac80211: Remove invalid flag operations in mesh TSF synchronization

[alexander.levin]

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[] = {
-- 
2.11.0

[PATCH AUTOSEL for 4.9 34/56] mac80211: Suppress NEW_PEER_CANDIDATE event if no room

[alexander.levin]

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;
-- 
2.11.0

[PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[alexander.levin]

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-email-ville.syrjala@linux.intel.com
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) {
-- 
2.11.0

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Ville Syrjälä]

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-email-ville.syrjala@linux.intel.com
> 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

-- 
Ville Syrjälä
Intel OTC

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Ville Syrjälä]

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-email-ville.syrjala@linux.intel.com
> 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

-- 
Ville Syrj�l�
Intel OTC

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[alexander.levin]

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.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
>> 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.

-- 

Thanks,
Sasha

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Ville Syrjälä]

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.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
> >> 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.

-- 
Ville Syrjälä
Intel OTC

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Ville Syrjälä]

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.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
> >> 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.

-- 
Ville Syrj�l�
Intel OTC

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Jani Nikula]

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.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
>> >> 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.

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Jani Nikula]

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.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
>> >> 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.

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Greg KH]

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.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
> >> >> 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

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Greg KH]

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.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
> >> >> 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Greg KH]

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.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
> >> >> 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

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Ville Syrjälä]

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.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
> > >> >> 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.

-- 
Ville Syrjälä
Intel OTC

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Ville Syrjälä]

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.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
> > >> >> 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.

-- 
Ville Syrj�l�
Intel OTC

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Greg KH]

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.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
> > > >> >> 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

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Greg KH]

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.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
> > > >> >> 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Greg KH]

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.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
> > > >> >> 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

Re: [Intel-gfx] [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Emil Velikov]

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

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Emil Velikov]

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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Greg KH]

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

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Greg KH]

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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Jani Nikula]

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.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
>> >> >> 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

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Jani Nikula]

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.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
>> >> >> 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

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Greg KH]

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.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
> >> >> >> 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

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Greg KH]

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.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com&d=DwIDAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo&m=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y&s=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is&e=
> >> >> >> 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

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[alexander.levin]

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?

-- 

Thanks,
Sasha

[PATCH AUTOSEL for 4.9 37/56] adm80211: add checks for dma mapping errors

[alexander.levin]

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)
-- 
2.11.0

[PATCH AUTOSEL for 4.9 35/56] drm/i915: Protect DSPARB registers with a spinlock

[alexander.levin]

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-email-ville.syrjala@linux.intel.com
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
-- 
2.11.0

[PATCH AUTOSEL for 4.9 38/56] iio: light: fix improper return value

[alexander.levin]

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;
 }
 
 /**
-- 
2.11.0

[PATCH AUTOSEL for 4.9 40/56] drm/i915: Assert no external observers when unwind a failed request alloc

[alexander.levin]

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@chris-wilson.co.uk
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);
-- 
2.11.0

[PATCH AUTOSEL for 4.9 41/56] drm/i915: Protect dev_priv->atomic_cdclk_freq with all the crtc locks

[alexander.levin]

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-email-ville.syrjala@linux.intel.com
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);
-- 
2.11.0

[PATCH AUTOSEL for 4.9 39/56] staging: iio: cdc: fix improper return value

[alexander.levin]

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,
-- 
2.11.0

[PATCH AUTOSEL for 4.9 45/56] netfilter: nft_queue: use raw_smp_processor_id()

[alexander.levin]

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 {
-- 
2.11.0

[PATCH AUTOSEL for 4.9 43/56] spi: SPI_FSL_DSPI should depend on HAS_DMA

[alexander.levin]

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
-- 
2.11.0

[PATCH AUTOSEL for 4.9 42/56] drm/i915/bxt: Correct dual-link MIPI port control.

[alexander.levin]

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-email-bob.j.paauwe@intel.com
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;
 		}
-- 
2.11.0

[PATCH AUTOSEL for 4.9 44/56] ASoC: dwc: Fix PIO mode initialization

[alexander.levin]

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;
 		}
 	}
 
-- 
2.11.0

Re: [PATCH AUTOSEL for 4.9 44/56] ASoC: dwc: Fix PIO mode initialization

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

On Wed, Nov 15, 2017 at 02:45:45AM +0000, alexander.levin@verizon.com wrote:

> 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.

So when did the corresponding change to the dmaengine API go in?

> 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.

Though if PIO mode never worked presumably this isn't that urgent...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH AUTOSEL for 4.9 44/56] ASoC: dwc: Fix PIO mode initialization

[Jose Abreu]

Hi Mark,

On 15-11-2017 10:54, Mark Brown wrote:
> On Wed, Nov 15, 2017 at 02:45:45AM +0000, alexander.levin@verizon.com wrote:
>
>> 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.
> So when did the corresponding change to the dmaengine API go in?

Looks like this was introduced in a8135d0d79e9 ("dmaengine: core:
Introduce new, universal API to request a channel") but looking
at soc-generic-dmaengine-pcm.c I see that this would never work
anyway because dmaengine_pcm_request_chan_of() also returns
either zero 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.
> Though if PIO mode never worked presumably this isn't that urgent...

Yeah, and we also have this. Its my fault, I was using a
different tree for testing at the time. But if we could backport
this it would be nice because we and our clients use this PIO
driver in ARC AXS101 Development Platform. (A side note is that
the DT bindings were only recently introduced but I think its
more easier to add the bindings instead of fixing this driver ...).

Best Regards,
Jose Miguel Abreu

Re: [PATCH AUTOSEL for 4.9 44/56] ASoC: dwc: Fix PIO mode initialization

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1467 bytes --]

On Wed, Nov 15, 2017 at 12:46:37PM +0000, Jose Abreu wrote:
> On 15-11-2017 10:54, Mark Brown wrote:

> > So when did the corresponding change to the dmaengine API go in?

> Looks like this was introduced in a8135d0d79e9 ("dmaengine: core:
> Introduce new, universal API to request a channel") but looking
> at soc-generic-dmaengine-pcm.c I see that this would never work
> anyway because dmaengine_pcm_request_chan_of() also returns
> either zero or -EPROBE_DEFER.

So this just never worked for two reasons.

> >> Also, initialize use_pio variable which was never being set
> >> causing PIO mode to never work.

> > Though if PIO mode never worked presumably this isn't that urgent...

> Yeah, and we also have this. Its my fault, I was using a
> different tree for testing at the time. But if we could backport
> this it would be nice because we and our clients use this PIO
> driver in ARC AXS101 Development Platform. (A side note is that
> the DT bindings were only recently introduced but I think its
> more easier to add the bindings instead of fixing this driver ...).

Why on earth would anyone use audio hardware without DMA in production
(or make it for that matter)?  Not that it really matters.  Even if
there are users on stable presumably the they're already running with
something like this and it'll just conflict with this if it gets
backported?  The whole backport to enable a thing that never worked
aspect of this seems out of scope for stable.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH AUTOSEL for 4.9 44/56] ASoC: dwc: Fix PIO mode initialization

[Jose Abreu]

On 15-11-2017 13:20, Mark Brown wrote:
>
> Why on earth would anyone use audio hardware without DMA in production
> (or make it for that matter)?  Not that it really matters. 

That was my thought while I was implementing this. I guess HW
guys had their reasons.

>  Even if
> there are users on stable presumably the they're already running with
> something like this and it'll just conflict with this if it gets
> backported?  

Probably yes. I was never contacted about this PIO driver so
either they fixed it manually and never sent a patch or they are
not using it.

> The whole backport to enable a thing that never worked
> aspect of this seems out of scope for stable.

Ah, I reminded now that ARC PGU DRM driver (which is needed for
I2S audio to work) is totally broken in 4.9 because of some DRM
core changes and was never backported because the fix was simply
too large.

Yeah, I think given all these reasons we can drop this patch.

Best Regards,
Jose Miguel Abreu

Re: [PATCH AUTOSEL for 4.9 44/56] ASoC: dwc: Fix PIO mode initialization

[alexander.levin]

On Wed, Nov 15, 2017 at 02:06:45PM +0000, Jose Abreu wrote:
>
>
>On 15-11-2017 13:20, Mark Brown wrote:
>>
>> Why on earth would anyone use audio hardware without DMA in production
>> (or make it for that matter)?  Not that it really matters.
>
>That was my thought while I was implementing this. I guess HW
>guys had their reasons.
>
>>  Even if
>> there are users on stable presumably the they're already running with
>> something like this and it'll just conflict with this if it gets
>> backported?
>
>Probably yes. I was never contacted about this PIO driver so
>either they fixed it manually and never sent a patch or they are
>not using it.
>
>> The whole backport to enable a thing that never worked
>> aspect of this seems out of scope for stable.
>
>Ah, I reminded now that ARC PGU DRM driver (which is needed for
>I2S audio to work) is totally broken in 4.9 because of some DRM
>core changes and was never backported because the fix was simply
>too large.
>
>Yeah, I think given all these reasons we can drop this patch.

Will do. Thanks!

Just to clarify this for me, would you consider the patch, on it's
own, as stable material (ignoring this particular instance where
there was simply no reason to backport it)?

-- 

Thanks,
Sasha

Re: [PATCH AUTOSEL for 4.9 44/56] ASoC: dwc: Fix PIO mode initialization

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 290 bytes --]

On Wed, Nov 15, 2017 at 04:41:13PM +0000, alexander.levin@verizon.com wrote:

> Just to clarify this for me, would you consider the patch, on it's
> own, as stable material (ignoring this particular instance where
> there was simply no reason to backport it)?

I'm really dubious about it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH AUTOSEL for 4.9 48/56] crypto: marvell - Copy IVDIG before launching partial DMA ahash requests

[alexander.levin]

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;
 	}
 }
-- 
2.11.0

[PATCH AUTOSEL for 4.9 46/56] netfilter: nf_tables: fix oob access

[alexander.levin]

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);
 	}
-- 
2.11.0

[PATCH AUTOSEL for 4.9 49/56] btrfs: return the actual error value from from btrfs_uuid_tree_iterate

[alexander.levin]

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;
 }
-- 
2.11.0

[PATCH AUTOSEL for 4.9 47/56] ASoC: rsnd: don't double free kctrl

[alexander.levin]

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;
-- 
2.11.0

[PATCH AUTOSEL for 4.9 51/56] s390/kbuild: enable modversions for symbols exported from asm

[alexander.levin]

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 */
-- 
2.11.0

[PATCH AUTOSEL for 4.9 50/56] ASoC: wm_adsp: Don't overrun firmware file buffer when reading region data

[alexander.levin]

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);
-- 
2.11.0

[PATCH AUTOSEL for 4.9 53/56] [media] cec: CEC_MSG_GIVE_FEATURES should abort for CEC version < 2

[alexander.levin]

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:
 		/*
-- 
2.11.0

[PATCH AUTOSEL for 4.9 52/56] [media] cec: when canceling a message, don't overwrite old status info

[alexander.levin]

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);
 
-- 
2.11.0

[PATCH AUTOSEL for 4.9 56/56] xen: xenbus driver must not accept invalid transaction ids

[alexander.levin]

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;
-- 
2.11.0

[PATCH AUTOSEL for 4.9 54/56] [media] cec: update log_addr[] before finishing configuration

[alexander.levin]

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);
-- 
2.11.0

[PATCH AUTOSEL for 4.9 55/56] nvmet: fix KATO offset in Set Features

[alexander.levin]

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;
-- 
2.11.0

RE: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid resource if buffer length too long

[alexander.levin]

On Wed, Nov 15, 2017 at 03:39:22PM +0000, Moore, Robert wrote:
>> -----Original Message-----
>> From: alexander.levin@verizon.com [mailto:alexander.levin@verizon.com]
>> Sent: Tuesday, November 14, 2017 6:46 PM
>> To: linux-kernel@vger.kernel.org; stable@vger.kernel.org
>> Cc: Moore, Robert <robert.moore@intel.com>; Zheng, Lv
>> <lv.zheng@intel.com>; Wysocki, Rafael J <rafael.j.wysocki@intel.com>;
>> alexander.levin@verizon.com
>> Subject: [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.
[snip]

>[Moore, Robert]
>
>Please explain what you are doing here.

Proposing this commit for the 4.9 LTS tree.

-- 

Thanks,
Sasha

RE: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid resource if buffer length too long

[Schmauss, Erik]

> -----Original Message-----
> From: alexander.levin@verizon.com [mailto:alexander.levin@verizon.com]
> Sent: Wednesday, November 15, 2017 8:39 AM
> To: Moore, Robert <robert.moore@intel.com>
> Cc: linux-kernel@vger.kernel.org; stable@vger.kernel.org; Wysocki, Rafael J
> <rafael.j.wysocki@intel.com>; Schmauss, Erik <erik.schmauss@intel.com>
> Subject: RE: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid
> resource if buffer length too long
> 
> On Wed, Nov 15, 2017 at 03:39:22PM +0000, Moore, Robert wrote:
> >> -----Original Message-----
> >> From: alexander.levin@verizon.com
> >> [mailto:alexander.levin@verizon.com]
> >> Sent: Tuesday, November 14, 2017 6:46 PM
> >> To: linux-kernel@vger.kernel.org; stable@vger.kernel.org
> >> Cc: Moore, Robert <robert.moore@intel.com>; Zheng, Lv
> >> <lv.zheng@intel.com>; Wysocki, Rafael J <rafael.j.wysocki@intel.com>;
> >> alexander.levin@verizon.com
> >> Subject: [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.
> [snip]
> 
> >[Moore, Robert]
> >
> >Please explain what you are doing here.
> 
> Proposing this commit for the 4.9 LTS tree.

What problem are you trying to solve with this change? Are you seeing ACPI errors? If so what are they?

> 
> --
> 
> Thanks,
> Sasha

RE: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid resource if buffer length too long

[alexander.levin]

On Wed, Nov 15, 2017 at 05:05:21PM +0000, Schmauss, Erik wrote:
>
>
>> -----Original Message-----
>> From: alexander.levin@verizon.com [mailto:alexander.levin@verizon.com]
>> Sent: Wednesday, November 15, 2017 8:39 AM
>> To: Moore, Robert <robert.moore@intel.com>
>> Cc: linux-kernel@vger.kernel.org; stable@vger.kernel.org; Wysocki, Rafael J
>> <rafael.j.wysocki@intel.com>; Schmauss, Erik <erik.schmauss@intel.com>
>> Subject: RE: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid
>> resource if buffer length too long
>>
>> On Wed, Nov 15, 2017 at 03:39:22PM +0000, Moore, Robert wrote:
>> >> -----Original Message-----
>> >> From: alexander.levin@verizon.com
>> >> [mailto:alexander.levin@verizon.com]
>> >> Sent: Tuesday, November 14, 2017 6:46 PM
>> >> To: linux-kernel@vger.kernel.org; stable@vger.kernel.org
>> >> Cc: Moore, Robert <robert.moore@intel.com>; Zheng, Lv
>> >> <lv.zheng@intel.com>; Wysocki, Rafael J <rafael.j.wysocki@intel.com>;
>> >> alexander.levin@verizon.com
>> >> Subject: [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.
>> [snip]
>>
>> >[Moore, Robert]
>> >
>> >Please explain what you are doing here.
>>
>> Proposing this commit for the 4.9 LTS tree.
>
>What problem are you trying to solve with this change? Are you seeing ACPI errors? If so what are they?

Not seeing an actual problem myself. Was this patch supposed to fix a
problem or just deal with a theoretical scenario?

-- 

Thanks,
Sasha

RE: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid resource if buffer length too long

[Schmauss, Erik]

> -----Original Message-----
> From: alexander.levin@verizon.com [mailto:alexander.levin@verizon.com]
> Sent: Thursday, November 16, 2017 4:56 PM
> To: Schmauss, Erik <erik.schmauss@intel.com>
> Cc: Moore, Robert <robert.moore@intel.com>; linux-kernel@vger.kernel.org;
> stable@vger.kernel.org; Wysocki, Rafael J <rafael.j.wysocki@intel.com>
> Subject: RE: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid
> resource if buffer length too long
> 
> On Wed, Nov 15, 2017 at 05:05:21PM +0000, Schmauss, Erik wrote:
> >
> >
> >> -----Original Message-----
> >> From: alexander.levin@verizon.com
> >> [mailto:alexander.levin@verizon.com]
> >> Sent: Wednesday, November 15, 2017 8:39 AM
> >> To: Moore, Robert <robert.moore@intel.com>
> >> Cc: linux-kernel@vger.kernel.org; stable@vger.kernel.org; Wysocki,
> >> Rafael J <rafael.j.wysocki@intel.com>; Schmauss, Erik
> >> <erik.schmauss@intel.com>
> >> Subject: RE: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a
> >> valid resource if buffer length too long
> >>
> >> On Wed, Nov 15, 2017 at 03:39:22PM +0000, Moore, Robert wrote:
> >> >> -----Original Message-----
> >> >> From: alexander.levin@verizon.com
> >> >> [mailto:alexander.levin@verizon.com]
> >> >> Sent: Tuesday, November 14, 2017 6:46 PM
> >> >> To: linux-kernel@vger.kernel.org; stable@vger.kernel.org
> >> >> Cc: Moore, Robert <robert.moore@intel.com>; Zheng, Lv
> >> >> <lv.zheng@intel.com>; Wysocki, Rafael J
> >> >> <rafael.j.wysocki@intel.com>; alexander.levin@verizon.com
> >> >> Subject: [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.
> >> [snip]
> >>
> >> >[Moore, Robert]
> >> >
> >> >Please explain what you are doing here.
> >>
> >> Proposing this commit for the 4.9 LTS tree.
> >
> >What problem are you trying to solve with this change? Are you seeing ACPI
> errors? If so what are they?
> 
> Not seeing an actual problem myself. Was this patch supposed to fix a problem
> or just deal with a theoretical scenario?
> 
This was supposed to fix issues with our AML disassembler to parse a strange corner in the ASL test suite. I believe this was due to the end tag contains a checksum byte that ACPICA and other ACPI implementations ignore. We thought this was useful in the test suite because we test the disassembler by comparing normally compiled AML with AML that has been compiled, disassembled, and re-compiled. Without this change, the endtag checksum would be over-written to 0 rather than the existing value.

I believe this change broke a few things such as the execution of ConcatResTemplate. We concluded to not use this solution and alter the test suite instead because this endtag byte is usually ignored anyway. To answer your question, this was to deal with a theoretical scenario.

Erik
> --
> 
> Thanks,
> Sasha

RE: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid resource if buffer length too long

[alexander.levin]

On Mon, Nov 20, 2017 at 05:22:37PM +0000, Schmauss, Erik wrote:
>> -----Original Message-----
>> From: alexander.levin@verizon.com [mailto:alexander.levin@verizon.com]
>> Sent: Thursday, November 16, 2017 4:56 PM
>> To: Schmauss, Erik <erik.schmauss@intel.com>
>> Cc: Moore, Robert <robert.moore@intel.com>; linux-kernel@vger.kernel.org;
>> stable@vger.kernel.org; Wysocki, Rafael J <rafael.j.wysocki@intel.com>
>> Subject: RE: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a valid
>> resource if buffer length too long
>>
>> On Wed, Nov 15, 2017 at 05:05:21PM +0000, Schmauss, Erik wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: alexander.levin@verizon.com
>> >> [mailto:alexander.levin@verizon.com]
>> >> Sent: Wednesday, November 15, 2017 8:39 AM
>> >> To: Moore, Robert <robert.moore@intel.com>
>> >> Cc: linux-kernel@vger.kernel.org; stable@vger.kernel.org; Wysocki,
>> >> Rafael J <rafael.j.wysocki@intel.com>; Schmauss, Erik
>> >> <erik.schmauss@intel.com>
>> >> Subject: RE: [PATCH AUTOSEL for 4.9 01/56] ACPICA: Resources: Not a
>> >> valid resource if buffer length too long
>> >>
>> >> On Wed, Nov 15, 2017 at 03:39:22PM +0000, Moore, Robert wrote:
>> >> >> -----Original Message-----
>> >> >> From: alexander.levin@verizon.com
>> >> >> [mailto:alexander.levin@verizon.com]
>> >> >> Sent: Tuesday, November 14, 2017 6:46 PM
>> >> >> To: linux-kernel@vger.kernel.org; stable@vger.kernel.org
>> >> >> Cc: Moore, Robert <robert.moore@intel.com>; Zheng, Lv
>> >> >> <lv.zheng@intel.com>; Wysocki, Rafael J
>> >> >> <rafael.j.wysocki@intel.com>; alexander.levin@verizon.com
>> >> >> Subject: [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.
>> >> [snip]
>> >>
>> >> >[Moore, Robert]
>> >> >
>> >> >Please explain what you are doing here.
>> >>
>> >> Proposing this commit for the 4.9 LTS tree.
>> >
>> >What problem are you trying to solve with this change? Are you seeing ACPI
>> errors? If so what are they?
>>
>> Not seeing an actual problem myself. Was this patch supposed to fix a problem
>> or just deal with a theoretical scenario?
>>
>This was supposed to fix issues with our AML disassembler to parse a strange corner in the ASL test suite. I believe this was due to the end tag contains a checksum byte that ACPICA and other ACPI implementations ignore. We thought this was useful in the test suite because we test the disassembler by comparing normally compiled AML with AML that has been compiled, disassembled, and re-compiled. Without this change, the endtag checksum would be over-written to 0 rather than the existing value.
>
>I believe this change broke a few things such as the execution of ConcatResTemplate. We concluded to not use this solution and alter the test suite instead because this endtag byte is usually ignored anyway. To answer your question, this was to deal with a theoretical scenario.

I'll drop it then, thanks Erik!

-- 

Thanks,
Sasha