[PATCH AUTOSEL 5.2 12/44] nvmet-file: fix nvmet_file_flush() always returning an error

2019-08-20 Thread Sasha Levin
From: Logan Gunthorpe 

[ Upstream commit cfc1a1af56200362d1508b82b9a3cc3acb2eae0c ]

Presently, nvmet_file_flush() always returns a call to
errno_to_nvme_status() but that helper doesn't take into account the
case when errno=0. So nvmet_file_flush() always returns an error code.

All other callers of errno_to_nvme_status() check for success before
calling it.

To fix this, ensure errno_to_nvme_status() returns success if the
errno is zero. This should prevent future mistakes like this from
happening.

Fixes: c6aa3542e010 ("nvmet: add error log support for file backend")
Signed-off-by: Logan Gunthorpe 
Reviewed-by: Sagi Grimberg 
Reviewed-by: Chaitanya Kulkarni 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Sasha Levin 
---
 drivers/nvme/target/core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/nvme/target/core.c b/drivers/nvme/target/core.c
index e4db9a4411681..396cbc7ea3532 100644
--- a/drivers/nvme/target/core.c
+++ b/drivers/nvme/target/core.c
@@ -43,6 +43,9 @@ inline u16 errno_to_nvme_status(struct nvmet_req *req, int 
errno)
u16 status;
 
switch (errno) {
+   case 0:
+   status = NVME_SC_SUCCESS;
+   break;
case -ENOSPC:
req->error_loc = offsetof(struct nvme_rw_command, length);
status = NVME_SC_CAP_EXCEEDED | NVME_SC_DNR;
-- 
2.20.1



[PATCH AUTOSEL 5.2 10/44] nvmet: Fix use-after-free bug when a port is removed

2019-08-20 Thread Sasha Levin
From: Logan Gunthorpe 

[ Upstream commit 3aed86731ee2b23e4dc4d2c6d943d33992cd551b ]

When a port is removed through configfs, any connected controllers
are still active and can still send commands. This causes a
use-after-free bug which is detected by KASAN for any admin command
that dereferences req->port (like in nvmet_execute_identify_ctrl).

To fix this, disconnect all active controllers when a subsystem is
removed from a port. This ensures there are no active controllers
when the port is eventually removed.

Signed-off-by: Logan Gunthorpe 
Reviewed-by: Sagi Grimberg 
Reviewed-by: Max Gurtovoy 
Reviewed-by : Chaitanya Kulkarni 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Sasha Levin 
---
 drivers/nvme/target/configfs.c |  1 +
 drivers/nvme/target/core.c | 12 
 drivers/nvme/target/nvmet.h|  3 +++
 3 files changed, 16 insertions(+)

diff --git a/drivers/nvme/target/configfs.c b/drivers/nvme/target/configfs.c
index 08dd5af357f7c..3854363118ccf 100644
--- a/drivers/nvme/target/configfs.c
+++ b/drivers/nvme/target/configfs.c
@@ -673,6 +673,7 @@ static void nvmet_port_subsys_drop_link(struct config_item 
*parent,
 
 found:
list_del(&p->entry);
+   nvmet_port_del_ctrls(port, subsys);
nvmet_port_disc_changed(port, subsys);
 
if (list_empty(&port->subsystems))
diff --git a/drivers/nvme/target/core.c b/drivers/nvme/target/core.c
index 7734a6acff851..e4db9a4411681 100644
--- a/drivers/nvme/target/core.c
+++ b/drivers/nvme/target/core.c
@@ -277,6 +277,18 @@ void nvmet_unregister_transport(const struct 
nvmet_fabrics_ops *ops)
 }
 EXPORT_SYMBOL_GPL(nvmet_unregister_transport);
 
+void nvmet_port_del_ctrls(struct nvmet_port *port, struct nvmet_subsys *subsys)
+{
+   struct nvmet_ctrl *ctrl;
+
+   mutex_lock(&subsys->lock);
+   list_for_each_entry(ctrl, &subsys->ctrls, subsys_entry) {
+   if (ctrl->port == port)
+   ctrl->ops->delete_ctrl(ctrl);
+   }
+   mutex_unlock(&subsys->lock);
+}
+
 int nvmet_enable_port(struct nvmet_port *port)
 {
const struct nvmet_fabrics_ops *ops;
diff --git a/drivers/nvme/target/nvmet.h b/drivers/nvme/target/nvmet.h
index c25d88fc9dec8..b6b0d483e0c50 100644
--- a/drivers/nvme/target/nvmet.h
+++ b/drivers/nvme/target/nvmet.h
@@ -415,6 +415,9 @@ void nvmet_port_send_ana_event(struct nvmet_port *port);
 int nvmet_register_transport(const struct nvmet_fabrics_ops *ops);
 void nvmet_unregister_transport(const struct nvmet_fabrics_ops *ops);
 
+void nvmet_port_del_ctrls(struct nvmet_port *port,
+ struct nvmet_subsys *subsys);
+
 int nvmet_enable_port(struct nvmet_port *port);
 void nvmet_disable_port(struct nvmet_port *port);
 
-- 
2.20.1



[PATCH AUTOSEL 5.2 09/44] intel_th: Use the correct style for SPDX License Identifier

2019-08-20 Thread Sasha Levin
From: Nishad Kamdar 

[ Upstream commit fac7b714c514fcc41e1d6450c694b0a5f8d3 ]

This patch corrects the SPDX License Identifier style
in header files related to Drivers for Intel(R) Trace Hub
controller.
For C header files Documentation/process/license-rules.rst
mandates C-like comments (opposed to C source files where
C++ style should be used)

Changes made by using a script provided by Joe Perches here:
https://lkml.org/lkml/2019/2/7/46

Suggested-by: Joe Perches 
Signed-off-by: Nishad Kamdar 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/hwtracing/intel_th/msu.h | 2 +-
 drivers/hwtracing/intel_th/pti.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hwtracing/intel_th/msu.h b/drivers/hwtracing/intel_th/msu.h
index 574c16004cb2e..13d9b141d 100644
--- a/drivers/hwtracing/intel_th/msu.h
+++ b/drivers/hwtracing/intel_th/msu.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * Intel(R) Trace Hub Memory Storage Unit (MSU) data structures
  *
diff --git a/drivers/hwtracing/intel_th/pti.h b/drivers/hwtracing/intel_th/pti.h
index e9381babc84c3..7dfc0431333b7 100644
--- a/drivers/hwtracing/intel_th/pti.h
+++ b/drivers/hwtracing/intel_th/pti.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * Intel(R) Trace Hub PTI output data structures
  *
-- 
2.20.1



[PATCH AUTOSEL 5.2 16/44] nvme: fix controller removal race with scan work

2019-08-20 Thread Sasha Levin
From: Sagi Grimberg 

[ Upstream commit 0157ec8dad3c8fc9bc9790f76e0831ffdaf2e7f0 ]

With multipath enabled, nvme_scan_work() can read from the device
(through nvme_mpath_add_disk()) and hang [1]. However, with fabrics,
once ctrl->state is set to NVME_CTRL_DELETING, the reads will hang
(see nvmf_check_ready()) and the mpath stack device make_request
will block if head->list is not empty. However, when the head->list
consistst of only DELETING/DEAD controllers, we should actually not
block, but rather fail immediately.

In addition, before we go ahead and remove the namespaces, make sure
to clear the current path and kick the requeue list so that the
request will fast fail upon requeuing.

[1]:
--
  INFO: task kworker/u4:3:166 blocked for more than 120 seconds.
Not tainted 5.2.0-rc6-vmlocalyes-5-g808c8c2dc0cf #316
  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
  kworker/u4:3D0   166  2 0x80004000
  Workqueue: nvme-wq nvme_scan_work
  Call Trace:
   __schedule+0x851/0x1400
   schedule+0x99/0x210
   io_schedule+0x21/0x70
   do_read_cache_page+0xa57/0x1330
   read_cache_page+0x4a/0x70
   read_dev_sector+0xbf/0x380
   amiga_partition+0xc4/0x1230
   check_partition+0x30f/0x630
   rescan_partitions+0x19a/0x980
   __blkdev_get+0x85a/0x12f0
   blkdev_get+0x2a5/0x790
   __device_add_disk+0xe25/0x1250
   device_add_disk+0x13/0x20
   nvme_mpath_set_live+0x172/0x2b0
   nvme_update_ns_ana_state+0x130/0x180
   nvme_set_ns_ana_state+0x9a/0xb0
   nvme_parse_ana_log+0x1c3/0x4a0
   nvme_mpath_add_disk+0x157/0x290
   nvme_validate_ns+0x1017/0x1bd0
   nvme_scan_work+0x44d/0x6a0
   process_one_work+0x7d7/0x1240
   worker_thread+0x8e/0xff0
   kthread+0x2c3/0x3b0
   ret_from_fork+0x35/0x40

   INFO: task kworker/u4:1:1034 blocked for more than 120 seconds.
Not tainted 5.2.0-rc6-vmlocalyes-5-g808c8c2dc0cf #316
  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
  kworker/u4:1D0  1034  2 0x80004000
  Workqueue: nvme-delete-wq nvme_delete_ctrl_work
  Call Trace:
   __schedule+0x851/0x1400
   schedule+0x99/0x210
   schedule_timeout+0x390/0x830
   wait_for_completion+0x1a7/0x310
   __flush_work+0x241/0x5d0
   flush_work+0x10/0x20
   nvme_remove_namespaces+0x85/0x3d0
   nvme_do_delete_ctrl+0xb4/0x1e0
   nvme_delete_ctrl_work+0x15/0x20
   process_one_work+0x7d7/0x1240
   worker_thread+0x8e/0xff0
   kthread+0x2c3/0x3b0
   ret_from_fork+0x35/0x40
--

Reported-by: Logan Gunthorpe 
Tested-by: Logan Gunthorpe 
Reviewed-by: Logan Gunthorpe 
Reviewed-by: Ming Lei 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Sasha Levin 
---
 drivers/nvme/host/core.c  |  7 ++
 drivers/nvme/host/multipath.c | 46 ++-
 drivers/nvme/host/nvme.h  |  9 +--
 3 files changed, 54 insertions(+), 8 deletions(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 05301b94e2fa0..601509b3251ae 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -3529,6 +3529,13 @@ void nvme_remove_namespaces(struct nvme_ctrl *ctrl)
struct nvme_ns *ns, *next;
LIST_HEAD(ns_list);
 
+   /*
+* make sure to requeue I/O to all namespaces as these
+* might result from the scan itself and must complete
+* for the scan_work to make progress
+*/
+   nvme_mpath_clear_ctrl_paths(ctrl);
+
/* prevent racing with ns scanning */
flush_work(&ctrl->scan_work);
 
diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c
index dafb9e4aa1237..747c0d4f9ff5b 100644
--- a/drivers/nvme/host/multipath.c
+++ b/drivers/nvme/host/multipath.c
@@ -134,18 +134,34 @@ static const char *nvme_ana_state_names[] = {
[NVME_ANA_CHANGE]   = "change",
 };
 
-void nvme_mpath_clear_current_path(struct nvme_ns *ns)
+bool nvme_mpath_clear_current_path(struct nvme_ns *ns)
 {
struct nvme_ns_head *head = ns->head;
+   bool changed = false;
int node;
 
if (!head)
-   return;
+   goto out;
 
for_each_node(node) {
-   if (ns == rcu_access_pointer(head->current_path[node]))
+   if (ns == rcu_access_pointer(head->current_path[node])) {
rcu_assign_pointer(head->current_path[node], NULL);
+   changed = true;
+   }
}
+out:
+   return changed;
+}
+
+void nvme_mpath_clear_ctrl_paths(struct nvme_ctrl *ctrl)
+{
+   struct nvme_ns *ns;
+
+   mutex_lock(&ctrl->scan_lock);
+   list_for_each_entry(ns, &ctrl->namespaces, list)
+   if (nvme_mpath_clear_current_path(ns))
+   kblockd_schedule_work(&ns->head->requeue_work);
+   mutex_unlock(&ctrl->scan_lock);
 }
 
 static struct nvme_ns *__nvme_find_path(struct nvme_ns_head *head, int node)
@@ -248,6 +264,24 @@ inline struct nvme_ns *nvme_find_path(struct nvme_ns_head 
*head)
return ns;
 }
 
+static bool nvme_ava

[PATCH AUTOSEL 5.2 20/44] iio: adc: max9611: Fix temperature reading in probe

2019-08-20 Thread Sasha Levin
From: Jacopo Mondi 

[ Upstream commit b9ddd5091160793ee9fac10da765cf3f53d2aaf0 ]

The max9611 driver reads the die temperature at probe time to validate
the communication channel. Use the actual read value to perform the test
instead of the read function return value, which was mistakenly used so
far.

The temperature reading test was only successful because the 0 return
value is in the range of supported temperatures.

Fixes: 69780a3bbc0b ("iio: adc: Add Maxim max9611 ADC driver")
Signed-off-by: Jacopo Mondi 
Cc: 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin 
---
 drivers/iio/adc/max9611.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/adc/max9611.c b/drivers/iio/adc/max9611.c
index 0e3c6529fc4c9..da073d72f649f 100644
--- a/drivers/iio/adc/max9611.c
+++ b/drivers/iio/adc/max9611.c
@@ -480,7 +480,7 @@ static int max9611_init(struct max9611_dev *max9611)
if (ret)
return ret;
 
-   regval = ret & MAX9611_TEMP_MASK;
+   regval &= MAX9611_TEMP_MASK;
 
if ((regval > MAX9611_TEMP_MAX_POS &&
 regval < MAX9611_TEMP_MIN_NEG) ||
-- 
2.20.1



[PATCH AUTOSEL 5.2 17/44] nvme-pci: Fix async probe remove race

2019-08-20 Thread Sasha Levin
From: Keith Busch 

[ Upstream commit bd46a90634302bfe791e93ad5496f98f165f7ae0 ]

Ensure the controller is not in the NEW state when nvme_probe() exits.
This will always allow a subsequent nvme_remove() to set the state to
DELETING, fixing a potential race between the initial asynchronous probe
and device removal.

Reported-by: Li Zhong 
Reviewed-by: Sagi Grimberg 
Signed-off-by: Keith Busch 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Sasha Levin 
---
 drivers/nvme/host/pci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index f9959eaaa185e..09ffd21d18096 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2712,7 +2712,7 @@ static void nvme_async_probe(void *data, async_cookie_t 
cookie)
 {
struct nvme_dev *dev = data;
 
-   nvme_reset_ctrl_sync(&dev->ctrl);
+   flush_work(&dev->ctrl.reset_work);
flush_work(&dev->ctrl.scan_work);
nvme_put_ctrl(&dev->ctrl);
 }
@@ -2778,6 +2778,7 @@ static int nvme_probe(struct pci_dev *pdev, const struct 
pci_device_id *id)
 
dev_info(dev->ctrl.device, "pci function %s\n", dev_name(&pdev->dev));
 
+   nvme_reset_ctrl(&dev->ctrl);
nvme_get_ctrl(&dev->ctrl);
async_schedule(nvme_async_probe, dev);
 
-- 
2.20.1



[PATCH AUTOSEL 5.2 11/44] nvmet-loop: Flush nvme_delete_wq when removing the port

2019-08-20 Thread Sasha Levin
From: Logan Gunthorpe 

[ Upstream commit 86b9a63e595ff03f9d0a7b92b6acc231fecefc29 ]

After calling nvme_loop_delete_ctrl(), the controllers will not
yet be deleted because nvme_delete_ctrl() only schedules work
to do the delete.

This means a race can occur if a port is removed but there
are still active controllers trying to access that memory.

To fix this, flush the nvme_delete_wq before returning from
nvme_loop_remove_port() so that any controllers that might
be in the process of being deleted won't access a freed port.

Signed-off-by: Logan Gunthorpe 
Reviewed-by: Sagi Grimberg 
Reviewed-by: Max Gurtovoy 
Reviewed-by : Chaitanya Kulkarni 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Sasha Levin 
---
 drivers/nvme/target/loop.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/nvme/target/loop.c b/drivers/nvme/target/loop.c
index 9e211ad6bdd3d..da9cd07461fbb 100644
--- a/drivers/nvme/target/loop.c
+++ b/drivers/nvme/target/loop.c
@@ -654,6 +654,14 @@ static void nvme_loop_remove_port(struct nvmet_port *port)
mutex_lock(&nvme_loop_ports_mutex);
list_del_init(&port->entry);
mutex_unlock(&nvme_loop_ports_mutex);
+
+   /*
+* Ensure any ctrls that are in the process of being
+* deleted are in fact deleted before we return
+* and free the port. This is to prevent active
+* ctrls from using a port after it's freed.
+*/
+   flush_workqueue(nvme_delete_wq);
 }
 
 static const struct nvmet_fabrics_ops nvme_loop_ops = {
-- 
2.20.1



[PATCH AUTOSEL 5.2 14/44] nvme: fix a possible deadlock when passthru commands sent to a multipath device

2019-08-20 Thread Sasha Levin
From: Sagi Grimberg 

[ Upstream commit b9156daeb1601d69007b7e50efcf89d69d72ec1d ]

When the user issues a command with side effects, we will end up freezing
the namespace request queue when updating disk info (and the same for
the corresponding mpath disk node).

However, we are not freezing the mpath node request queue,
which means that mpath I/O can still come in and block on blk_queue_enter
(called from nvme_ns_head_make_request -> direct_make_request).

This is a deadlock, because blk_queue_enter will block until the inner
namespace request queue is unfroze, but that process is blocked because
the namespace revalidation is trying to update the mpath disk info
and freeze its request queue (which will never complete because
of the I/O that is blocked on blk_queue_enter).

Fix this by freezing all the subsystem nsheads request queues before
executing the passthru command. Given that these commands are infrequent
we should not worry about this temporary I/O freeze to keep things sane.

Here is the matching hang traces:
--
[ 374.465002] INFO: task systemd-udevd:17994 blocked for more than 122 seconds.
[ 374.472975] Not tainted 5.2.0-rc3-mpdebug+ #42
[ 374.478522] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 374.487274] systemd-udevd D 0 17994 1 0x
[ 374.493407] Call Trace:
[ 374.496145] __schedule+0x2ef/0x620
[ 374.500047] schedule+0x38/0xa0
[ 374.503569] blk_queue_enter+0x139/0x220
[ 374.507959] ? remove_wait_queue+0x60/0x60
[ 374.512540] direct_make_request+0x60/0x130
[ 374.517219] nvme_ns_head_make_request+0x11d/0x420 [nvme_core]
[ 374.523740] ? generic_make_request_checks+0x307/0x6f0
[ 374.529484] generic_make_request+0x10d/0x2e0
[ 374.534356] submit_bio+0x75/0x140
[ 374.538163] ? guard_bio_eod+0x32/0xe0
[ 374.542361] submit_bh_wbc+0x171/0x1b0
[ 374.546553] block_read_full_page+0x1ed/0x330
[ 374.551426] ? check_disk_change+0x70/0x70
[ 374.556008] ? scan_shadow_nodes+0x30/0x30
[ 374.560588] blkdev_readpage+0x18/0x20
[ 374.564783] do_read_cache_page+0x301/0x860
[ 374.569463] ? blkdev_writepages+0x10/0x10
[ 374.574037] ? prep_new_page+0x88/0x130
[ 374.578329] ? get_page_from_freelist+0xa2f/0x1280
[ 374.583688] ? __alloc_pages_nodemask+0x179/0x320
[ 374.588947] read_cache_page+0x12/0x20
[ 374.593142] read_dev_sector+0x2d/0xd0
[ 374.597337] read_lba+0x104/0x1f0
[ 374.601046] find_valid_gpt+0xfa/0x720
[ 374.605243] ? string_nocheck+0x58/0x70
[ 374.609534] ? find_valid_gpt+0x720/0x720
[ 374.614016] efi_partition+0x89/0x430
[ 374.618113] ? string+0x48/0x60
[ 374.621632] ? snprintf+0x49/0x70
[ 374.625339] ? find_valid_gpt+0x720/0x720
[ 374.629828] check_partition+0x116/0x210
[ 374.634214] rescan_partitions+0xb6/0x360
[ 374.638699] __blkdev_reread_part+0x64/0x70
[ 374.643377] blkdev_reread_part+0x23/0x40
[ 374.647860] blkdev_ioctl+0x48c/0x990
[ 374.651956] block_ioctl+0x41/0x50
[ 374.655766] do_vfs_ioctl+0xa7/0x600
[ 374.659766] ? locks_lock_inode_wait+0xb1/0x150
[ 374.664832] ksys_ioctl+0x67/0x90
[ 374.668539] __x64_sys_ioctl+0x1a/0x20
[ 374.672732] do_syscall_64+0x5a/0x1c0
[ 374.676828] entry_SYSCALL_64_after_hwframe+0x44/0xa9

[ 374.738474] INFO: task nvmeadm:49141 blocked for more than 123 seconds.
[ 374.745871] Not tainted 5.2.0-rc3-mpdebug+ #42
[ 374.751419] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 374.760170] nvmeadm D 0 49141 36333 0x4080
[ 374.766301] Call Trace:
[ 374.769038] __schedule+0x2ef/0x620
[ 374.772939] schedule+0x38/0xa0
[ 374.776452] blk_mq_freeze_queue_wait+0x59/0x100
[ 374.781614] ? remove_wait_queue+0x60/0x60
[ 374.786192] blk_mq_freeze_queue+0x1a/0x20
[ 374.790773] nvme_update_disk_info.isra.57+0x5f/0x350 [nvme_core]
[ 374.797582] ? nvme_identify_ns.isra.50+0x71/0xc0 [nvme_core]
[ 374.804006] __nvme_revalidate_disk+0xe5/0x110 [nvme_core]
[ 374.810139] nvme_revalidate_disk+0xa6/0x120 [nvme_core]
[ 374.816078] ? nvme_submit_user_cmd+0x11e/0x320 [nvme_core]
[ 374.822299] nvme_user_cmd+0x264/0x370 [nvme_core]
[ 374.827661] nvme_dev_ioctl+0x112/0x1d0 [nvme_core]
[ 374.833114] do_vfs_ioctl+0xa7/0x600
[ 374.837117] ? __audit_syscall_entry+0xdd/0x130
[ 374.842184] ksys_ioctl+0x67/0x90
[ 374.845891] __x64_sys_ioctl+0x1a/0x20
[ 374.850082] do_syscall_64+0x5a/0x1c0
[ 374.854178] entry_SYSCALL_64_after_hwframe+0x44/0xa9
--

Reported-by: James Puthukattukaran 
Tested-by: James Puthukattukaran 
Reviewed-by: Keith Busch 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Sasha Levin 
---
 drivers/nvme/host/core.c  |  5 +
 drivers/nvme/host/multipath.c | 30 ++
 drivers/nvme/host/nvme.h  | 12 
 3 files changed, 47 insertions(+)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index dfbd5872f4422..05301b94e2fa0 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1268,6 +1268,9 @@ static u32 nvme_passthru_start(struct nvme_ctrl *ctrl, 
struct nvme_ns *ns,
 */
if (effects & (NVME_CMD_EFFECTS_LBCC | NVME_CMD_EFFECTS_CSE_MASK)) {
  

[PATCH AUTOSEL 5.2 18/44] soundwire: cadence_master: fix register definition for SLAVE_STATE

2019-08-20 Thread Sasha Levin
From: Pierre-Louis Bossart 

[ Upstream commit b07dd9b400981f487940a4d84292d3a0e7cd9362 ]

wrong prefix and wrong macro.

Signed-off-by: Pierre-Louis Bossart 
Link: 
https://lore.kernel.org/r/20190725234032.21152-14-pierre-louis.boss...@linux.intel.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
---
 drivers/soundwire/cadence_master.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/soundwire/cadence_master.c 
b/drivers/soundwire/cadence_master.c
index 682789bb8ab30..18afb2e21dc9a 100644
--- a/drivers/soundwire/cadence_master.c
+++ b/drivers/soundwire/cadence_master.c
@@ -80,8 +80,8 @@
 
 #define CDNS_MCP_INTSET0x4C
 
-#define CDNS_SDW_SLAVE_STAT0x50
-#define CDNS_MCP_SLAVE_STAT_MASK   BIT(1, 0)
+#define CDNS_MCP_SLAVE_STAT0x50
+#define CDNS_MCP_SLAVE_STAT_MASK   GENMASK(1, 0)
 
 #define CDNS_MCP_SLAVE_INTSTAT00x54
 #define CDNS_MCP_SLAVE_INTSTAT10x58
-- 
2.20.1



[PATCH AUTOSEL 4.19 06/27] afs: Only update d_fsdata if different in afs_d_revalidate()

2019-08-20 Thread Sasha Levin
From: David Howells 

[ Upstream commit 5dc84855b0fc7e1db182b55c5564fd539d6eff92 ]

In the in-kernel afs filesystem, d_fsdata is set with the data version of
the parent directory.  afs_d_revalidate() will update this to the current
directory version, but it shouldn't do this if it the value it read from
d_fsdata is the same as no lock is held and cmpxchg() is not used.

Fix the code to only change the value if it is different from the current
directory version.

Fixes: 260a980317da ("[AFS]: Add "directory write" support.")
Signed-off-by: David Howells 
Signed-off-by: Sasha Levin 
---
 fs/afs/dir.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/afs/dir.c b/fs/afs/dir.c
index 855bf2b79fed4..54e7f6f1405e2 100644
--- a/fs/afs/dir.c
+++ b/fs/afs/dir.c
@@ -937,7 +937,7 @@ static int afs_d_revalidate(struct dentry *dentry, unsigned 
int flags)
dir_version = (long)dir->status.data_version;
de_version = (long)dentry->d_fsdata;
if (de_version == dir_version)
-   goto out_valid;
+   goto out_valid_noupdate;
 
dir_version = (long)dir->invalid_before;
if (de_version - dir_version >= 0)
@@ -1001,6 +1001,7 @@ static int afs_d_revalidate(struct dentry *dentry, 
unsigned int flags)
 
 out_valid:
dentry->d_fsdata = (void *)dir_version;
+out_valid_noupdate:
dput(parent);
key_put(key);
_leave(" = 1 [valid]");
-- 
2.20.1



[PATCH AUTOSEL 5.2 36/44] arm64: cpufeature: Don't treat granule sizes as strict

2019-08-20 Thread Sasha Levin
From: Will Deacon 

[ Upstream commit 5717fe5ab38f9ccb32718bcb03bea68409c9cce4 ]

If a CPU doesn't support the page size for which the kernel is
configured, then we will complain and refuse to bring it online. For
secondary CPUs (and the boot CPU on a system booting with EFI), we will
also print an error identifying the mismatch.

Consequently, the only time that the cpufeature code can detect a
granule size mismatch is for a granule other than the one that is
currently being used. Although we would rather such systems didn't
exist, we've unfortunately lost that battle and Kevin reports that
on his amlogic S922X (odroid-n2 board) we end up warning and taining
with defconfig because 16k pages are not supported by all of the CPUs.

In such a situation, we don't actually care about the feature mismatch,
particularly now that KVM only exposes the sanitised view of the CPU
registers (commit 93390c0a1b20 - "arm64: KVM: Hide unsupported AArch64
CPU features from guests"). Treat the granule fields as non-strict and
let Kevin run without a tainted kernel.

Cc: Marc Zyngier 
Reported-by: Kevin Hilman 
Tested-by: Kevin Hilman 
Acked-by: Mark Rutland 
Acked-by: Suzuki K Poulose 
Signed-off-by: Will Deacon 
[catalin.mari...@arm.com: changelog updated with KVM sanitised regs commit]
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin 
---
 arch/arm64/kernel/cpufeature.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index ae63eedea1c12..68faf535f40a3 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -184,9 +184,17 @@ static const struct arm64_ftr_bits ftr_id_aa64zfr0[] = {
 };
 
 static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
-   S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_TGRAN4_SHIFT, 4, ID_AA64MMFR0_TGRAN4_NI),
-   S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_TGRAN64_SHIFT, 4, ID_AA64MMFR0_TGRAN64_NI),
-   ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_TGRAN16_SHIFT, 4, ID_AA64MMFR0_TGRAN16_NI),
+   /*
+* We already refuse to boot CPUs that don't support our configured
+* page size, so we can only detect mismatches for a page size other
+* than the one we're currently using. Unfortunately, SoCs like this
+* exist in the wild so, even though we don't like it, we'll have to go
+* along with it and treat them as non-strict.
+*/
+   S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_TGRAN4_SHIFT, 4, ID_AA64MMFR0_TGRAN4_NI),
+   S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_TGRAN64_SHIFT, 4, ID_AA64MMFR0_TGRAN64_NI),
+   ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_TGRAN16_SHIFT, 4, ID_AA64MMFR0_TGRAN16_NI),
+
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_BIGENDEL0_SHIFT, 4, 0),
/* Linux shouldn't care about secure memory */
ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_SNSMEM_SHIFT, 4, 0),
-- 
2.20.1



[PATCH AUTOSEL 4.19 07/27] intel_th: Use the correct style for SPDX License Identifier

2019-08-20 Thread Sasha Levin
From: Nishad Kamdar 

[ Upstream commit fac7b714c514fcc41e1d6450c694b0a5f8d3 ]

This patch corrects the SPDX License Identifier style
in header files related to Drivers for Intel(R) Trace Hub
controller.
For C header files Documentation/process/license-rules.rst
mandates C-like comments (opposed to C source files where
C++ style should be used)

Changes made by using a script provided by Joe Perches here:
https://lkml.org/lkml/2019/2/7/46

Suggested-by: Joe Perches 
Signed-off-by: Nishad Kamdar 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/hwtracing/intel_th/msu.h | 2 +-
 drivers/hwtracing/intel_th/pti.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hwtracing/intel_th/msu.h b/drivers/hwtracing/intel_th/msu.h
index 9cc8aced6116a..979548791b7db 100644
--- a/drivers/hwtracing/intel_th/msu.h
+++ b/drivers/hwtracing/intel_th/msu.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * Intel(R) Trace Hub Memory Storage Unit (MSU) data structures
  *
diff --git a/drivers/hwtracing/intel_th/pti.h b/drivers/hwtracing/intel_th/pti.h
index e9381babc84c3..7dfc0431333b7 100644
--- a/drivers/hwtracing/intel_th/pti.h
+++ b/drivers/hwtracing/intel_th/pti.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * Intel(R) Trace Hub PTI output data structures
  *
-- 
2.20.1



[PATCH AUTOSEL 5.2 44/44] tools: hv: fix KVP and VSS daemons exit code

2019-08-20 Thread Sasha Levin
From: Adrian Vladu 

[ Upstream commit b0995156071b0ff29a5902964a9dc8cfad6f81c0 ]

HyperV KVP and VSS daemons should exit with 0 when the '--help'
or '-h' flags are used.

Signed-off-by: Adrian Vladu 

Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Sasha Levin 
Cc: Alessandro Pilotti 
Signed-off-by: Sasha Levin 
---
 tools/hv/hv_kvp_daemon.c | 2 ++
 tools/hv/hv_vss_daemon.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index d7e06fe0270ee..0ce50c319cfd6 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -1386,6 +1386,8 @@ int main(int argc, char *argv[])
daemonize = 0;
break;
case 'h':
+   print_usage(argv);
+   exit(0);
default:
print_usage(argv);
exit(EXIT_FAILURE);
diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_daemon.c
index efe1e34dd91b4..8f813f5233d48 100644
--- a/tools/hv/hv_vss_daemon.c
+++ b/tools/hv/hv_vss_daemon.c
@@ -218,6 +218,8 @@ int main(int argc, char *argv[])
daemonize = 0;
break;
case 'h':
+   print_usage(argv);
+   exit(0);
default:
print_usage(argv);
exit(EXIT_FAILURE);
-- 
2.20.1



[PATCH AUTOSEL 5.2 42/44] usb: host: fotg2: restart hcd after port reset

2019-08-20 Thread Sasha Levin
From: Hans Ulli Kroll 

[ Upstream commit 5ffe59ef754cc39ab2f275dc277732f4 ]

On the Gemini SoC the FOTG2 stalls after port reset
so restart the HCD after each port reset.

Signed-off-by: Hans Ulli Kroll 
Signed-off-by: Linus Walleij 
Link: https://lore.kernel.org/r/20190810150458.817-1-linus.wall...@linaro.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/usb/host/fotg210-hcd.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
index 0da68df259c86..7bf621d40c5ae 100644
--- a/drivers/usb/host/fotg210-hcd.c
+++ b/drivers/usb/host/fotg210-hcd.c
@@ -1628,6 +1628,10 @@ static int fotg210_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
/* see what we found out */
temp = check_reset_complete(fotg210, wIndex, status_reg,
fotg210_readl(fotg210, status_reg));
+
+   /* restart schedule */
+   fotg210->command |= CMD_RUN;
+   fotg210_writel(fotg210, fotg210->command, 
&fotg210->regs->command);
}
 
if (!(temp & (PORT_RESUME|PORT_RESET))) {
-- 
2.20.1



[PATCH AUTOSEL 4.19 04/27] afs: Fix loop index mixup in afs_deliver_vl_get_entry_by_name_u()

2019-08-20 Thread Sasha Levin
From: Marc Dionne 

[ Upstream commit 4a46fdba449a5cd890271df5a9e23927d519ed00 ]

afs_deliver_vl_get_entry_by_name_u() scans through the vl entry
received from the volume location server and builds a return list
containing the sites that are currently valid.  When assigning
values for the return list, the index into the vl entry (i) is used
rather than the one for the new list (entry->nr_server).  If all
sites are usable, this works out fine as the indices will match.
If some sites are not valid, for example if AFS_VLSF_DONTUSE is
set, fs_mask and the uuid will be set for the wrong return site.

Fix this by using entry->nr_server as the index into the arrays
being filled in rather than i.

This can lead to EDESTADDRREQ errors if none of the returned sites
have a valid fs_mask.

Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and 
fileserver rotation")
Signed-off-by: Marc Dionne 
Signed-off-by: David Howells 
Reviewed-by: Jeffrey Altman 
Signed-off-by: Sasha Levin 
---
 fs/afs/vlclient.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/fs/afs/vlclient.c b/fs/afs/vlclient.c
index c3b740813fc71..c7dd47eaff29d 100644
--- a/fs/afs/vlclient.c
+++ b/fs/afs/vlclient.c
@@ -60,23 +60,24 @@ static int afs_deliver_vl_get_entry_by_name_u(struct 
afs_call *call)
struct afs_uuid__xdr *xdr;
struct afs_uuid *uuid;
int j;
+   int n = entry->nr_servers;
 
tmp = ntohl(uvldb->serverFlags[i]);
if (tmp & AFS_VLSF_DONTUSE ||
(new_only && !(tmp & AFS_VLSF_NEWREPSITE)))
continue;
if (tmp & AFS_VLSF_RWVOL) {
-   entry->fs_mask[i] |= AFS_VOL_VTM_RW;
+   entry->fs_mask[n] |= AFS_VOL_VTM_RW;
if (vlflags & AFS_VLF_BACKEXISTS)
-   entry->fs_mask[i] |= AFS_VOL_VTM_BAK;
+   entry->fs_mask[n] |= AFS_VOL_VTM_BAK;
}
if (tmp & AFS_VLSF_ROVOL)
-   entry->fs_mask[i] |= AFS_VOL_VTM_RO;
-   if (!entry->fs_mask[i])
+   entry->fs_mask[n] |= AFS_VOL_VTM_RO;
+   if (!entry->fs_mask[n])
continue;
 
xdr = &uvldb->serverNumber[i];
-   uuid = (struct afs_uuid *)&entry->fs_server[i];
+   uuid = (struct afs_uuid *)&entry->fs_server[n];
uuid->time_low  = xdr->time_low;
uuid->time_mid  = htons(ntohl(xdr->time_mid));
uuid->time_hi_and_version   = 
htons(ntohl(xdr->time_hi_and_version));
-- 
2.20.1



[PATCH AUTOSEL 4.19 02/27] nvme-multipath: revalidate nvme_ns_head gendisk in nvme_validate_ns

2019-08-20 Thread Sasha Levin
From: Anthony Iliopoulos 

[ Upstream commit fab7772bfbcfe8fb8e3e352a6a8fcaf044cded17 ]

When CONFIG_NVME_MULTIPATH is set, only the hidden gendisk associated
with the per-controller ns is run through revalidate_disk when a
rescan is triggered, while the visible blockdev never gets its size
(bdev->bd_inode->i_size) updated to reflect any capacity changes that
may have occurred.

This prevents online resizing of nvme block devices and in extension of
any filesystems atop that will are unable to expand while mounted, as
userspace relies on the blockdev size for obtaining the disk capacity
(via BLKGETSIZE/64 ioctls).

Fix this by explicitly revalidating the actual namespace gendisk in
addition to the per-controller gendisk, when multipath is enabled.

Signed-off-by: Anthony Iliopoulos 
Reviewed-by: Sagi Grimberg 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin 
---
 drivers/nvme/host/core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index e26d1191c5ad6..d838a300ae770 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1557,6 +1557,7 @@ static void __nvme_revalidate_disk(struct gendisk *disk, 
struct nvme_id_ns *id)
if (ns->head->disk) {
nvme_update_disk_info(ns->head->disk, ns, id);
blk_queue_stack_limits(ns->head->disk->queue, ns->queue);
+   revalidate_disk(ns->head->disk);
}
 #endif
 }
-- 
2.20.1



[PATCH AUTOSEL 5.2 27/44] dma-direct: don't truncate dma_required_mask to bus addressing capabilities

2019-08-20 Thread Sasha Levin
From: Lucas Stach 

[ Upstream commit d8ad55538abe443919e20e0bb996561bca9cad84 ]

The dma required_mask needs to reflect the actual addressing capabilities
needed to handle the whole system RAM. When truncated down to the bus
addressing capabilities dma_addressing_limited() will incorrectly signal
no limitations for devices which are restricted by the bus_dma_mask.

Fixes: b4ebe6063204 (dma-direct: implement complete bus_dma_mask handling)
Signed-off-by: Lucas Stach 
Tested-by: Atish Patra 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin 
---
 kernel/dma/direct.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 2c2772e9702ab..9912be7a970de 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -55,9 +55,6 @@ u64 dma_direct_get_required_mask(struct device *dev)
 {
u64 max_dma = phys_to_dma_direct(dev, (max_pfn - 1) << PAGE_SHIFT);
 
-   if (dev->bus_dma_mask && dev->bus_dma_mask < max_dma)
-   max_dma = dev->bus_dma_mask;
-
return (1ULL << (fls64(max_dma) - 1)) * 2 - 1;
 }
 
-- 
2.20.1



[PATCH AUTOSEL 5.2 35/44] xen/blkback: fix memory leaks

2019-08-20 Thread Sasha Levin
From: Wenwen Wang 

[ Upstream commit ae78ca3cf3d9e9f914bfcd0bc5c389ff18b9c2e0 ]

In read_per_ring_refs(), after 'req' and related memory regions are
allocated, xen_blkif_map() is invoked to map the shared frame, irq, and
etc. However, if this mapping process fails, no cleanup is performed,
leading to memory leaks. To fix this issue, invoke the cleanup before
returning the error.

Acked-by: Roger Pau Monné 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: Wenwen Wang 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 drivers/block/xen-blkback/xenbus.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index 3ac6a5d180717..b90dbcd99c03e 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -965,6 +965,7 @@ static int read_per_ring_refs(struct xen_blkif_ring *ring, 
const char *dir)
}
}
 
+   err = -ENOMEM;
for (i = 0; i < nr_grefs * XEN_BLKIF_REQS_PER_PAGE; i++) {
req = kzalloc(sizeof(*req), GFP_KERNEL);
if (!req)
@@ -987,7 +988,7 @@ static int read_per_ring_refs(struct xen_blkif_ring *ring, 
const char *dir)
err = xen_blkif_map(ring, ring_ref, nr_grefs, evtchn);
if (err) {
xenbus_dev_fatal(dev, err, "mapping ring-ref port %u", evtchn);
-   return err;
+   goto fail;
}
 
return 0;
@@ -1007,8 +1008,7 @@ static int read_per_ring_refs(struct xen_blkif_ring 
*ring, const char *dir)
}
kfree(req);
}
-   return -ENOMEM;
-
+   return err;
 }
 
 static int connect_ring(struct backend_info *be)
-- 
2.20.1



[PATCH AUTOSEL 5.2 38/44] i2c: rcar: avoid race when unregistering slave client

2019-08-20 Thread Sasha Levin
From: Wolfram Sang 

[ Upstream commit 7b814d852af6944657c2961039f404c4490771c0 ]

After we disabled interrupts, there might still be an active one
running. Sync before clearing the pointer to the slave device.

Fixes: de20d1857dd6 ("i2c: rcar: add slave support")
Reported-by: Krzysztof Adamski 
Signed-off-by: Wolfram Sang 
Reviewed-by: Krzysztof Adamski 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
---
 drivers/i2c/busses/i2c-rcar.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index d39a4606f72d3..531c01100b560 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -139,6 +139,7 @@ struct rcar_i2c_priv {
enum dma_data_direction dma_direction;
 
struct reset_control *rstc;
+   int irq;
 };
 
 #define rcar_i2c_priv_to_dev(p)((p)->adap.dev.parent)
@@ -861,9 +862,11 @@ static int rcar_unreg_slave(struct i2c_client *slave)
 
WARN_ON(!priv->slave);
 
+   /* disable irqs and ensure none is running before clearing ptr */
rcar_i2c_write(priv, ICSIER, 0);
rcar_i2c_write(priv, ICSCR, 0);
 
+   synchronize_irq(priv->irq);
priv->slave = NULL;
 
pm_runtime_put(rcar_i2c_priv_to_dev(priv));
@@ -918,7 +921,7 @@ static int rcar_i2c_probe(struct platform_device *pdev)
struct i2c_adapter *adap;
struct device *dev = &pdev->dev;
struct i2c_timings i2c_t;
-   int irq, ret;
+   int ret;
 
/* Otherwise logic will break because some bytes must always use PIO */
BUILD_BUG_ON_MSG(RCAR_MIN_DMA_LEN < 3, "Invalid min DMA length");
@@ -984,10 +987,10 @@ static int rcar_i2c_probe(struct platform_device *pdev)
pm_runtime_put(dev);
 
 
-   irq = platform_get_irq(pdev, 0);
-   ret = devm_request_irq(dev, irq, rcar_i2c_irq, 0, dev_name(dev), priv);
+   priv->irq = platform_get_irq(pdev, 0);
+   ret = devm_request_irq(dev, priv->irq, rcar_i2c_irq, 0, dev_name(dev), 
priv);
if (ret < 0) {
-   dev_err(dev, "cannot get irq %d\n", irq);
+   dev_err(dev, "cannot get irq %d\n", priv->irq);
goto out_pm_disable;
}
 
-- 
2.20.1



[PATCH AUTOSEL 4.19 11/27] soundwire: cadence_master: fix register definition for SLAVE_STATE

2019-08-20 Thread Sasha Levin
From: Pierre-Louis Bossart 

[ Upstream commit b07dd9b400981f487940a4d84292d3a0e7cd9362 ]

wrong prefix and wrong macro.

Signed-off-by: Pierre-Louis Bossart 
Link: 
https://lore.kernel.org/r/20190725234032.21152-14-pierre-louis.boss...@linux.intel.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
---
 drivers/soundwire/cadence_master.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/soundwire/cadence_master.c 
b/drivers/soundwire/cadence_master.c
index cb6a331f448ab..d3d7de5a319c5 100644
--- a/drivers/soundwire/cadence_master.c
+++ b/drivers/soundwire/cadence_master.c
@@ -81,8 +81,8 @@
 
 #define CDNS_MCP_INTSET0x4C
 
-#define CDNS_SDW_SLAVE_STAT0x50
-#define CDNS_MCP_SLAVE_STAT_MASK   BIT(1, 0)
+#define CDNS_MCP_SLAVE_STAT0x50
+#define CDNS_MCP_SLAVE_STAT_MASK   GENMASK(1, 0)
 
 #define CDNS_MCP_SLAVE_INTSTAT00x54
 #define CDNS_MCP_SLAVE_INTSTAT10x58
-- 
2.20.1



[PATCH AUTOSEL 4.19 09/27] nvme: fix a possible deadlock when passthru commands sent to a multipath device

2019-08-20 Thread Sasha Levin
From: Sagi Grimberg 

[ Upstream commit b9156daeb1601d69007b7e50efcf89d69d72ec1d ]

When the user issues a command with side effects, we will end up freezing
the namespace request queue when updating disk info (and the same for
the corresponding mpath disk node).

However, we are not freezing the mpath node request queue,
which means that mpath I/O can still come in and block on blk_queue_enter
(called from nvme_ns_head_make_request -> direct_make_request).

This is a deadlock, because blk_queue_enter will block until the inner
namespace request queue is unfroze, but that process is blocked because
the namespace revalidation is trying to update the mpath disk info
and freeze its request queue (which will never complete because
of the I/O that is blocked on blk_queue_enter).

Fix this by freezing all the subsystem nsheads request queues before
executing the passthru command. Given that these commands are infrequent
we should not worry about this temporary I/O freeze to keep things sane.

Here is the matching hang traces:
--
[ 374.465002] INFO: task systemd-udevd:17994 blocked for more than 122 seconds.
[ 374.472975] Not tainted 5.2.0-rc3-mpdebug+ #42
[ 374.478522] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 374.487274] systemd-udevd D 0 17994 1 0x
[ 374.493407] Call Trace:
[ 374.496145] __schedule+0x2ef/0x620
[ 374.500047] schedule+0x38/0xa0
[ 374.503569] blk_queue_enter+0x139/0x220
[ 374.507959] ? remove_wait_queue+0x60/0x60
[ 374.512540] direct_make_request+0x60/0x130
[ 374.517219] nvme_ns_head_make_request+0x11d/0x420 [nvme_core]
[ 374.523740] ? generic_make_request_checks+0x307/0x6f0
[ 374.529484] generic_make_request+0x10d/0x2e0
[ 374.534356] submit_bio+0x75/0x140
[ 374.538163] ? guard_bio_eod+0x32/0xe0
[ 374.542361] submit_bh_wbc+0x171/0x1b0
[ 374.546553] block_read_full_page+0x1ed/0x330
[ 374.551426] ? check_disk_change+0x70/0x70
[ 374.556008] ? scan_shadow_nodes+0x30/0x30
[ 374.560588] blkdev_readpage+0x18/0x20
[ 374.564783] do_read_cache_page+0x301/0x860
[ 374.569463] ? blkdev_writepages+0x10/0x10
[ 374.574037] ? prep_new_page+0x88/0x130
[ 374.578329] ? get_page_from_freelist+0xa2f/0x1280
[ 374.583688] ? __alloc_pages_nodemask+0x179/0x320
[ 374.588947] read_cache_page+0x12/0x20
[ 374.593142] read_dev_sector+0x2d/0xd0
[ 374.597337] read_lba+0x104/0x1f0
[ 374.601046] find_valid_gpt+0xfa/0x720
[ 374.605243] ? string_nocheck+0x58/0x70
[ 374.609534] ? find_valid_gpt+0x720/0x720
[ 374.614016] efi_partition+0x89/0x430
[ 374.618113] ? string+0x48/0x60
[ 374.621632] ? snprintf+0x49/0x70
[ 374.625339] ? find_valid_gpt+0x720/0x720
[ 374.629828] check_partition+0x116/0x210
[ 374.634214] rescan_partitions+0xb6/0x360
[ 374.638699] __blkdev_reread_part+0x64/0x70
[ 374.643377] blkdev_reread_part+0x23/0x40
[ 374.647860] blkdev_ioctl+0x48c/0x990
[ 374.651956] block_ioctl+0x41/0x50
[ 374.655766] do_vfs_ioctl+0xa7/0x600
[ 374.659766] ? locks_lock_inode_wait+0xb1/0x150
[ 374.664832] ksys_ioctl+0x67/0x90
[ 374.668539] __x64_sys_ioctl+0x1a/0x20
[ 374.672732] do_syscall_64+0x5a/0x1c0
[ 374.676828] entry_SYSCALL_64_after_hwframe+0x44/0xa9

[ 374.738474] INFO: task nvmeadm:49141 blocked for more than 123 seconds.
[ 374.745871] Not tainted 5.2.0-rc3-mpdebug+ #42
[ 374.751419] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 374.760170] nvmeadm D 0 49141 36333 0x4080
[ 374.766301] Call Trace:
[ 374.769038] __schedule+0x2ef/0x620
[ 374.772939] schedule+0x38/0xa0
[ 374.776452] blk_mq_freeze_queue_wait+0x59/0x100
[ 374.781614] ? remove_wait_queue+0x60/0x60
[ 374.786192] blk_mq_freeze_queue+0x1a/0x20
[ 374.790773] nvme_update_disk_info.isra.57+0x5f/0x350 [nvme_core]
[ 374.797582] ? nvme_identify_ns.isra.50+0x71/0xc0 [nvme_core]
[ 374.804006] __nvme_revalidate_disk+0xe5/0x110 [nvme_core]
[ 374.810139] nvme_revalidate_disk+0xa6/0x120 [nvme_core]
[ 374.816078] ? nvme_submit_user_cmd+0x11e/0x320 [nvme_core]
[ 374.822299] nvme_user_cmd+0x264/0x370 [nvme_core]
[ 374.827661] nvme_dev_ioctl+0x112/0x1d0 [nvme_core]
[ 374.833114] do_vfs_ioctl+0xa7/0x600
[ 374.837117] ? __audit_syscall_entry+0xdd/0x130
[ 374.842184] ksys_ioctl+0x67/0x90
[ 374.845891] __x64_sys_ioctl+0x1a/0x20
[ 374.850082] do_syscall_64+0x5a/0x1c0
[ 374.854178] entry_SYSCALL_64_after_hwframe+0x44/0xa9
--

Reported-by: James Puthukattukaran 
Tested-by: James Puthukattukaran 
Reviewed-by: Keith Busch 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Sasha Levin 
---
 drivers/nvme/host/core.c  |  5 +
 drivers/nvme/host/multipath.c | 30 ++
 drivers/nvme/host/nvme.h  | 12 
 3 files changed, 47 insertions(+)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index d838a300ae770..ae0b01059fc6d 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1183,6 +1183,9 @@ static u32 nvme_passthru_start(struct nvme_ctrl *ctrl, 
struct nvme_ns *ns,
 */
if (effects & (NVME_CMD_EFFECTS_LBCC | NVME_CMD_EFFECTS_CSE_MASK)) {
  

[PATCH AUTOSEL 4.19 05/27] fs: afs: Fix a possible null-pointer dereference in afs_put_read()

2019-08-20 Thread Sasha Levin
From: Jia-Ju Bai 

[ Upstream commit a6eed4ab5dd4bfb696c1a3f49742b8d1846a66a0 ]

In afs_read_dir(), there is an if statement on line 255 to check whether
req->pages is NULL:
if (!req->pages)
goto error;

If req->pages is NULL, afs_put_read() on line 337 is executed.
In afs_put_read(), req->pages[i] is used on line 195.
Thus, a possible null-pointer dereference may occur in this case.

To fix this possible bug, an if statement is added in afs_put_read() to
check req->pages.

This bug is found by a static analysis tool STCheck written by us.

Fixes: f3ddee8dc4e2 ("afs: Fix directory handling")
Signed-off-by: Jia-Ju Bai 
Signed-off-by: David Howells 
Signed-off-by: Sasha Levin 
---
 fs/afs/file.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/fs/afs/file.c b/fs/afs/file.c
index 7d4f26198573d..843d3b970b845 100644
--- a/fs/afs/file.c
+++ b/fs/afs/file.c
@@ -193,11 +193,13 @@ void afs_put_read(struct afs_read *req)
int i;
 
if (refcount_dec_and_test(&req->usage)) {
-   for (i = 0; i < req->nr_pages; i++)
-   if (req->pages[i])
-   put_page(req->pages[i]);
-   if (req->pages != req->array)
-   kfree(req->pages);
+   if (req->pages) {
+   for (i = 0; i < req->nr_pages; i++)
+   if (req->pages[i])
+   put_page(req->pages[i]);
+   if (req->pages != req->array)
+   kfree(req->pages);
+   }
kfree(req);
}
 }
-- 
2.20.1



[PATCH AUTOSEL 4.19 13/27] iio: adc: max9611: Fix temperature reading in probe

2019-08-20 Thread Sasha Levin
From: Jacopo Mondi 

[ Upstream commit b9ddd5091160793ee9fac10da765cf3f53d2aaf0 ]

The max9611 driver reads the die temperature at probe time to validate
the communication channel. Use the actual read value to perform the test
instead of the read function return value, which was mistakenly used so
far.

The temperature reading test was only successful because the 0 return
value is in the range of supported temperatures.

Fixes: 69780a3bbc0b ("iio: adc: Add Maxim max9611 ADC driver")
Signed-off-by: Jacopo Mondi 
Cc: 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin 
---
 drivers/iio/adc/max9611.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/adc/max9611.c b/drivers/iio/adc/max9611.c
index ce9af43fa2de7..49c1956e6a674 100644
--- a/drivers/iio/adc/max9611.c
+++ b/drivers/iio/adc/max9611.c
@@ -483,7 +483,7 @@ static int max9611_init(struct max9611_dev *max9611)
if (ret)
return ret;
 
-   regval = ret & MAX9611_TEMP_MASK;
+   regval &= MAX9611_TEMP_MASK;
 
if ((regval > MAX9611_TEMP_MAX_POS &&
 regval < MAX9611_TEMP_MIN_NEG) ||
-- 
2.20.1



[PATCH AUTOSEL 4.19 19/27] usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt

2019-08-20 Thread Sasha Levin
From: Benjamin Herrenschmidt 

[ Upstream commit 4a56a478a525d6427be90753451c40e1327caa1a ]

If fsg_disable() and fsg_set_alt() are called too closely to each
other (for example due to a quick reset/reconnect), what can happen
is that fsg_set_alt sets common->new_fsg from an interrupt while
handle_exception is trying to process the config change caused by
fsg_disable():

fsg_disable()
...
handle_exception()
sets state back to FSG_STATE_NORMAL
hasn't yet called do_set_interface()
or is inside it.

 ---> interrupt
fsg_set_alt
sets common->new_fsg
queues a new FSG_STATE_CONFIG_CHANGE
 <---

Now, the first handle_exception can "see" the updated
new_fsg, treats it as if it was a fsg_set_alt() response,
call usb_composite_setup_continue() etc...

But then, the thread sees the second FSG_STATE_CONFIG_CHANGE,
and goes back down the same path, wipes and reattaches a now
active fsg, and .. calls usb_composite_setup_continue() which
at this point is wrong.

Not only we get a backtrace, but I suspect the second set_interface
wrecks some state causing the host to get upset in my case.

This fixes it by replacing "new_fsg" by a "state argument" (same
principle) which is set in the same lock section as the state
update, and retrieved similarly.

That way, there is never any discrepancy between the dequeued
state and the observed value of it. We keep the ability to have
the latest reconfig operation take precedence, but we guarantee
that once "dequeued" the argument (new_fsg) will not be clobbered
by any new event.

Signed-off-by: Benjamin Herrenschmidt 
Acked-by: Alan Stern 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
---
 drivers/usb/gadget/function/f_mass_storage.c | 28 +---
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/gadget/function/f_mass_storage.c 
b/drivers/usb/gadget/function/f_mass_storage.c
index 1074cb82ec172..0b7b4d09785b6 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -261,7 +261,7 @@ struct fsg_common;
 struct fsg_common {
struct usb_gadget   *gadget;
struct usb_composite_dev *cdev;
-   struct fsg_dev  *fsg, *new_fsg;
+   struct fsg_dev  *fsg;
wait_queue_head_t   io_wait;
wait_queue_head_t   fsg_wait;
 
@@ -290,6 +290,7 @@ struct fsg_common {
unsigned intbulk_out_maxpacket;
enum fsg_state  state;  /* For exception handling */
unsigned intexception_req_tag;
+   void*exception_arg;
 
enum data_direction data_dir;
u32 data_size;
@@ -391,7 +392,8 @@ static int fsg_set_halt(struct fsg_dev *fsg, struct usb_ep 
*ep)
 
 /* These routines may be called in process context or in_irq */
 
-static void raise_exception(struct fsg_common *common, enum fsg_state 
new_state)
+static void __raise_exception(struct fsg_common *common, enum fsg_state 
new_state,
+ void *arg)
 {
unsigned long   flags;
 
@@ -404,6 +406,7 @@ static void raise_exception(struct fsg_common *common, enum 
fsg_state new_state)
if (common->state <= new_state) {
common->exception_req_tag = common->ep0_req_tag;
common->state = new_state;
+   common->exception_arg = arg;
if (common->thread_task)
send_sig_info(SIGUSR1, SEND_SIG_FORCED,
  common->thread_task);
@@ -411,6 +414,10 @@ static void raise_exception(struct fsg_common *common, 
enum fsg_state new_state)
spin_unlock_irqrestore(&common->lock, flags);
 }
 
+static void raise_exception(struct fsg_common *common, enum fsg_state 
new_state)
+{
+   __raise_exception(common, new_state, NULL);
+}
 
 /*-*/
 
@@ -2285,16 +2292,16 @@ static int do_set_interface(struct fsg_common *common, 
struct fsg_dev *new_fsg)
 static int fsg_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
 {
struct fsg_dev *fsg = fsg_from_func(f);
-   fsg->common->new_fsg = fsg;
-   raise_exception(fsg->common, FSG_STATE_CONFIG_CHANGE);
+
+   __raise_exception(fsg->common, FSG_STATE_CONFIG_CHANGE, fsg);
return USB_GADGET_DELAYED_STATUS;
 }
 
 static void fsg_disable(struct usb_function *f)
 {
struct fsg_dev *fsg = fsg_from_func(f);
-   fsg->common->new_fsg = NULL;
-   raise_exception(fsg->common, FSG_STATE_CONFIG_CHANGE);
+
+   __raise_exception(fsg->common, FSG_STATE_CONFIG_CHANGE, NULL);
 }
 
 
@@ -2307,6 +2314,7 @@ static void handle_exception(struct fsg_common *common)
enum fsg_state  old_state;
struct fsg_lun  *curlun;
unsigned intexception_req_tag;

Re: [PATCH 4/9] drivers: ata: ahci_xgene: use devm_platform_ioremap_resource()

2019-08-20 Thread Bartlomiej Zolnierkiewicz


On 8/20/19 2:35 PM, Enrico Weigelt, metux IT consult wrote:
> Use the new helper that wraps the calls to platform_get_resource()
> and devm_ioremap_resource() together.
> 
> Signed-off-by: Enrico Weigelt, metux IT consult 
> ---
>  drivers/ata/ahci_xgene.c | 21 +++--
>  1 file changed, 7 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
> index 16246c8..5391f5d 100644
> --- a/drivers/ata/ahci_xgene.c
> +++ b/drivers/ata/ahci_xgene.c
> @@ -739,7 +739,6 @@ static int xgene_ahci_probe(struct platform_device *pdev)
>   struct device *dev = &pdev->dev;
>   struct ahci_host_priv *hpriv;
>   struct xgene_ahci_context *ctx;
> - struct resource *res;
>   const struct of_device_id *of_devid;
>   enum xgene_ahci_version version = XGENE_AHCI_V1;
>   const struct ata_port_info *ppi[] = { &xgene_ahci_v1_port_info,
> @@ -759,31 +758,25 @@ static int xgene_ahci_probe(struct platform_device 
> *pdev)
>   ctx->dev = dev;
>  
>   /* Retrieve the IP core resource */
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> - ctx->csr_core = devm_ioremap_resource(dev, res);
> + ctx->csr_core = devm_platform_ioremap_resource(pdev, 1);
>   if (IS_ERR(ctx->csr_core))
>   return PTR_ERR(ctx->csr_core);
>  
>   /* Retrieve the IP diagnostic resource */
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
> - ctx->csr_diag = devm_ioremap_resource(dev, res);
> + ctx->csr_diag = devm_platform_ioremap_resource(pdev, 2);
>   if (IS_ERR(ctx->csr_diag))
>   return PTR_ERR(ctx->csr_diag);
>  
>   /* Retrieve the IP AXI resource */
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 3);
> - ctx->csr_axi = devm_ioremap_resource(dev, res);
> + ctx->csr_axi = devm_platform_ioremap_resource(pdev, 3);
>   if (IS_ERR(ctx->csr_axi))
>   return PTR_ERR(ctx->csr_axi);
>  
>   /* Retrieve the optional IP mux resource */
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 4);
> - if (res) {
> - void __iomem *csr = devm_ioremap_resource(dev, res);
> - if (IS_ERR(csr))
> - return PTR_ERR(csr);
> -
> - ctx->csr_mux = csr;
> + ctx->csr_mux = csr = devm_platform_ioremap_resource(pdev, 4);

This conversion is incorrect - despite the resource being optional
we will get error message from devm_[platform_]ioremap_resource()
(it always prints an error on !res condition).

> + if (IS_ERR(ctx->csr_mux)) {
> + dev_info(&pdev->dev, "cant get ip mux resource (optional)");

No need for this message.

> + ctx->csr_mux = NULL;
>   }
>  
>   of_devid = of_match_device(xgene_ahci_of_match, dev);

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics


[PATCH AUTOSEL 4.19 17/27] iommu/dma: Handle SG length overflow better

2019-08-20 Thread Sasha Levin
From: Robin Murphy 

[ Upstream commit ab2cbeb0ed301a9f0460078e91b09f39958212ef ]

Since scatterlist dimensions are all unsigned ints, in the relatively
rare cases where a device's max_segment_size is set to UINT_MAX, then
the "cur_len + s_length <= max_len" check in __finalise_sg() will always
return true. As a result, the corner case of such a device mapping an
excessively large scatterlist which is mergeable to or beyond a total
length of 4GB can lead to overflow and a bogus truncated dma_length in
the resulting segment.

As we already assume that any single segment must be no longer than
max_len to begin with, this can easily be addressed by reshuffling the
comparison.

Fixes: 809eac54cdd6 ("iommu/dma: Implement scatterlist segment merging")
Reported-by: Nicolin Chen 
Tested-by: Nicolin Chen 
Signed-off-by: Robin Murphy 
Signed-off-by: Joerg Roedel 
Signed-off-by: Sasha Levin 
---
 drivers/iommu/dma-iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 511ff9a1d6d94..f9dbb064f9571 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -675,7 +675,7 @@ static int __finalise_sg(struct device *dev, struct 
scatterlist *sg, int nents,
 * - and wouldn't make the resulting output segment too long
 */
if (cur_len && !s_iova_off && (dma_addr & seg_mask) &&
-   (cur_len + s_length <= max_len)) {
+   (max_len - cur_len >= s_length)) {
/* ...then concatenate it with the previous one */
cur_len += s_length;
} else {
-- 
2.20.1



[PATCH AUTOSEL 4.19 10/27] nvme-pci: Fix async probe remove race

2019-08-20 Thread Sasha Levin
From: Keith Busch 

[ Upstream commit bd46a90634302bfe791e93ad5496f98f165f7ae0 ]

Ensure the controller is not in the NEW state when nvme_probe() exits.
This will always allow a subsequent nvme_remove() to set the state to
DELETING, fixing a potential race between the initial asynchronous probe
and device removal.

Reported-by: Li Zhong 
Reviewed-by: Sagi Grimberg 
Signed-off-by: Keith Busch 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Sasha Levin 
---
 drivers/nvme/host/pci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 0a5d064f82ca3..a64a8bca0d5b9 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2468,7 +2468,7 @@ static void nvme_async_probe(void *data, async_cookie_t 
cookie)
 {
struct nvme_dev *dev = data;
 
-   nvme_reset_ctrl_sync(&dev->ctrl);
+   flush_work(&dev->ctrl.reset_work);
flush_work(&dev->ctrl.scan_work);
nvme_put_ctrl(&dev->ctrl);
 }
@@ -2535,6 +2535,7 @@ static int nvme_probe(struct pci_dev *pdev, const struct 
pci_device_id *id)
 
dev_info(dev->ctrl.device, "pci function %s\n", dev_name(&pdev->dev));
 
+   nvme_reset_ctrl(&dev->ctrl);
nvme_get_ctrl(&dev->ctrl);
async_schedule(nvme_async_probe, dev);
 
-- 
2.20.1



[PATCH AUTOSEL 4.19 14/27] auxdisplay: panel: need to delete scan_timer when misc_register fails in panel_attach

2019-08-20 Thread Sasha Levin
From: zhengbin 

[ Upstream commit b33d567560c1aadf3033290d74d4fd67af47aa61 ]

In panel_attach, if misc_register fails, we need to delete scan_timer,
which was setup in keypad_init->init_scan_timer.

Reported-by: Hulk Robot 
Signed-off-by: zhengbin 
Signed-off-by: Miguel Ojeda 
Signed-off-by: Sasha Levin 
---
 drivers/auxdisplay/panel.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/auxdisplay/panel.c b/drivers/auxdisplay/panel.c
index 3b25a643058c9..0b8e2a7d6e934 100644
--- a/drivers/auxdisplay/panel.c
+++ b/drivers/auxdisplay/panel.c
@@ -1618,6 +1618,8 @@ static void panel_attach(struct parport *port)
return;
 
 err_lcd_unreg:
+   if (scan_timer.function)
+   del_timer_sync(&scan_timer);
if (lcd.enabled)
charlcd_unregister(lcd.charlcd);
 err_unreg_device:
-- 
2.20.1



[PATCH AUTOSEL 4.19 27/27] tools: hv: fix KVP and VSS daemons exit code

2019-08-20 Thread Sasha Levin
From: Adrian Vladu 

[ Upstream commit b0995156071b0ff29a5902964a9dc8cfad6f81c0 ]

HyperV KVP and VSS daemons should exit with 0 when the '--help'
or '-h' flags are used.

Signed-off-by: Adrian Vladu 

Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Sasha Levin 
Cc: Alessandro Pilotti 
Signed-off-by: Sasha Levin 
---
 tools/hv/hv_kvp_daemon.c | 2 ++
 tools/hv/hv_vss_daemon.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index d7e06fe0270ee..0ce50c319cfd6 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -1386,6 +1386,8 @@ int main(int argc, char *argv[])
daemonize = 0;
break;
case 'h':
+   print_usage(argv);
+   exit(0);
default:
print_usage(argv);
exit(EXIT_FAILURE);
diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_daemon.c
index b133001727623..c2bb8a3601777 100644
--- a/tools/hv/hv_vss_daemon.c
+++ b/tools/hv/hv_vss_daemon.c
@@ -229,6 +229,8 @@ int main(int argc, char *argv[])
daemonize = 0;
break;
case 'h':
+   print_usage(argv);
+   exit(0);
default:
print_usage(argv);
exit(EXIT_FAILURE);
-- 
2.20.1



[PATCH AUTOSEL 4.19 26/27] tools: hv: fixed Python pep8/flake8 warnings for lsvmbus

2019-08-20 Thread Sasha Levin
From: Adrian Vladu 

[ Upstream commit 5912e791f3018de0a007c8cfa9cb38c97d3e5f5c ]

Fixed pep8/flake8 python style code for lsvmbus tool.

The TAB indentation was on purpose ignored (pep8 rule W191) to make
sure the code is complying with the Linux code guideline.
The following command doe not show any warnings now:
pep8 --ignore=W191 lsvmbus
flake8 --ignore=W191 lsvmbus

Signed-off-by: Adrian Vladu 

Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Sasha Levin 
Cc: Dexuan Cui 
Cc: Alessandro Pilotti 
Signed-off-by: Sasha Levin 
---
 tools/hv/lsvmbus | 75 +++-
 1 file changed, 42 insertions(+), 33 deletions(-)

diff --git a/tools/hv/lsvmbus b/tools/hv/lsvmbus
index 55e7374bade0d..099f2c44dbed2 100644
--- a/tools/hv/lsvmbus
+++ b/tools/hv/lsvmbus
@@ -4,10 +4,10 @@
 import os
 from optparse import OptionParser
 
+help_msg = "print verbose messages. Try -vv, -vvv for  more verbose messages"
 parser = OptionParser()
-parser.add_option("-v", "--verbose", dest="verbose",
-  help="print verbose messages. Try -vv, -vvv for \
-   more verbose messages", action="count")
+parser.add_option(
+   "-v", "--verbose", dest="verbose", help=help_msg, action="count")
 
 (options, args) = parser.parse_args()
 
@@ -21,27 +21,28 @@ if not os.path.isdir(vmbus_sys_path):
exit(-1)
 
 vmbus_dev_dict = {
-   '{0e0b6031-5213-4934-818b-38d90ced39db}' : '[Operating system 
shutdown]',
-   '{9527e630-d0ae-497b-adce-e80ab0175caf}' : '[Time Synchronization]',
-   '{57164f39-9115-4e78-ab55-382f3bd5422d}' : '[Heartbeat]',
-   '{a9a0f4e7-5a45-4d96-b827-8a841e8c03e6}' : '[Data Exchange]',
-   '{35fa2e29-ea23-4236-96ae-3a6ebacba440}' : '[Backup (volume 
checkpoint)]',
-   '{34d14be3-dee4-41c8-9ae7-6b174977c192}' : '[Guest services]',
-   '{525074dc-8985-46e2-8057-a307dc18a502}' : '[Dynamic Memory]',
-   '{cfa8b69e-5b4a-4cc0-b98b-8ba1a1f3f95a}' : 'Synthetic mouse',
-   '{f912ad6d-2b17-48ea-bd65-f927a61c7684}' : 'Synthetic keyboard',
-   '{da0a7802-e377-4aac-8e77-0558eb1073f8}' : 'Synthetic framebuffer 
adapter',
-   '{f8615163-df3e-46c5-913f-f2d2f965ed0e}' : 'Synthetic network adapter',
-   '{32412632-86cb-44a2-9b5c-50d1417354f5}' : 'Synthetic IDE Controller',
-   '{ba6163d9-04a1-4d29-b605-72e2ffb1dc7f}' : 'Synthetic SCSI Controller',
-   '{2f9bcc4a-0069-4af3-b76b-6fd0be528cda}' : 'Synthetic fiber channel 
adapter',
-   '{8c2eaf3d-32a7-4b09-ab99-bd1f1c86b501}' : 'Synthetic RDMA adapter',
-   '{44c4f61d--4400-9d52-802e27ede19f}' : 'PCI Express pass-through',
-   '{276aacf4-ac15-426c-98dd-7521ad3f01fe}' : '[Reserved system device]',
-   '{f8e65716-3cb3-4a06-9a60-1889c5cccab5}' : '[Reserved system device]',
-   '{3375baf4-9e15-4b30-b765-67acb10d607b}' : '[Reserved system device]',
+   '{0e0b6031-5213-4934-818b-38d90ced39db}': '[Operating system shutdown]',
+   '{9527e630-d0ae-497b-adce-e80ab0175caf}': '[Time Synchronization]',
+   '{57164f39-9115-4e78-ab55-382f3bd5422d}': '[Heartbeat]',
+   '{a9a0f4e7-5a45-4d96-b827-8a841e8c03e6}': '[Data Exchange]',
+   '{35fa2e29-ea23-4236-96ae-3a6ebacba440}': '[Backup (volume 
checkpoint)]',
+   '{34d14be3-dee4-41c8-9ae7-6b174977c192}': '[Guest services]',
+   '{525074dc-8985-46e2-8057-a307dc18a502}': '[Dynamic Memory]',
+   '{cfa8b69e-5b4a-4cc0-b98b-8ba1a1f3f95a}': 'Synthetic mouse',
+   '{f912ad6d-2b17-48ea-bd65-f927a61c7684}': 'Synthetic keyboard',
+   '{da0a7802-e377-4aac-8e77-0558eb1073f8}': 'Synthetic framebuffer 
adapter',
+   '{f8615163-df3e-46c5-913f-f2d2f965ed0e}': 'Synthetic network adapter',
+   '{32412632-86cb-44a2-9b5c-50d1417354f5}': 'Synthetic IDE Controller',
+   '{ba6163d9-04a1-4d29-b605-72e2ffb1dc7f}': 'Synthetic SCSI Controller',
+   '{2f9bcc4a-0069-4af3-b76b-6fd0be528cda}': 'Synthetic fiber channel 
adapter',
+   '{8c2eaf3d-32a7-4b09-ab99-bd1f1c86b501}': 'Synthetic RDMA adapter',
+   '{44c4f61d--4400-9d52-802e27ede19f}': 'PCI Express pass-through',
+   '{276aacf4-ac15-426c-98dd-7521ad3f01fe}': '[Reserved system device]',
+   '{f8e65716-3cb3-4a06-9a60-1889c5cccab5}': '[Reserved system device]',
+   '{3375baf4-9e15-4b30-b765-67acb10d607b}': '[Reserved system device]',
 }
 
+
 def get_vmbus_dev_attr(dev_name, attr):
try:
f = open('%s/%s/%s' % (vmbus_sys_path, dev_name, attr), 'r')
@@ -52,6 +53,7 @@ def get_vmbus_dev_attr(dev_name, attr):
 
return lines
 
+
 class VMBus_Dev:
pass
 
@@ -66,12 +68,13 @@ for f in os.listdir(vmbus_sys_path):
 
chn_vp_mapping = get_vmbus_dev_attr(f, 'channel_vp_mapping')
chn_vp_mapping = [c.strip() for c in chn_vp_mapping]
-   chn_vp_mapping = sorted(chn_vp_mapping,
-   key = lambda c : int(c.split(':')[0]))
+   chn_vp_mapping = sorted(
+   chn_vp_mapping, key=lambda c: int(c.split(':')[0]))
 
-   chn_vp_mapp

[PATCH AUTOSEL 4.14 03/12] auxdisplay: panel: need to delete scan_timer when misc_register fails in panel_attach

2019-08-20 Thread Sasha Levin
From: zhengbin 

[ Upstream commit b33d567560c1aadf3033290d74d4fd67af47aa61 ]

In panel_attach, if misc_register fails, we need to delete scan_timer,
which was setup in keypad_init->init_scan_timer.

Reported-by: Hulk Robot 
Signed-off-by: zhengbin 
Signed-off-by: Miguel Ojeda 
Signed-off-by: Sasha Levin 
---
 drivers/auxdisplay/panel.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/auxdisplay/panel.c b/drivers/auxdisplay/panel.c
index 6911acd896d93..e30953ceb7dfd 100644
--- a/drivers/auxdisplay/panel.c
+++ b/drivers/auxdisplay/panel.c
@@ -1622,6 +1622,8 @@ static void panel_attach(struct parport *port)
return;
 
 err_lcd_unreg:
+   if (scan_timer.function)
+   del_timer_sync(&scan_timer);
if (lcd.enabled)
charlcd_unregister(lcd.charlcd);
 err_unreg_device:
-- 
2.20.1



[PATCH AUTOSEL 4.19 21/27] arm64: cpufeature: Don't treat granule sizes as strict

2019-08-20 Thread Sasha Levin
From: Will Deacon 

[ Upstream commit 5717fe5ab38f9ccb32718bcb03bea68409c9cce4 ]

If a CPU doesn't support the page size for which the kernel is
configured, then we will complain and refuse to bring it online. For
secondary CPUs (and the boot CPU on a system booting with EFI), we will
also print an error identifying the mismatch.

Consequently, the only time that the cpufeature code can detect a
granule size mismatch is for a granule other than the one that is
currently being used. Although we would rather such systems didn't
exist, we've unfortunately lost that battle and Kevin reports that
on his amlogic S922X (odroid-n2 board) we end up warning and taining
with defconfig because 16k pages are not supported by all of the CPUs.

In such a situation, we don't actually care about the feature mismatch,
particularly now that KVM only exposes the sanitised view of the CPU
registers (commit 93390c0a1b20 - "arm64: KVM: Hide unsupported AArch64
CPU features from guests"). Treat the granule fields as non-strict and
let Kevin run without a tainted kernel.

Cc: Marc Zyngier 
Reported-by: Kevin Hilman 
Tested-by: Kevin Hilman 
Acked-by: Mark Rutland 
Acked-by: Suzuki K Poulose 
Signed-off-by: Will Deacon 
[catalin.mari...@arm.com: changelog updated with KVM sanitised regs commit]
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin 
---
 arch/arm64/kernel/cpufeature.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index bce06083685dc..94babc3d0ec2c 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -165,9 +165,17 @@ static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
 };
 
 static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
-   S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_TGRAN4_SHIFT, 4, ID_AA64MMFR0_TGRAN4_NI),
-   S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_TGRAN64_SHIFT, 4, ID_AA64MMFR0_TGRAN64_NI),
-   ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_TGRAN16_SHIFT, 4, ID_AA64MMFR0_TGRAN16_NI),
+   /*
+* We already refuse to boot CPUs that don't support our configured
+* page size, so we can only detect mismatches for a page size other
+* than the one we're currently using. Unfortunately, SoCs like this
+* exist in the wild so, even though we don't like it, we'll have to go
+* along with it and treat them as non-strict.
+*/
+   S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_TGRAN4_SHIFT, 4, ID_AA64MMFR0_TGRAN4_NI),
+   S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_TGRAN64_SHIFT, 4, ID_AA64MMFR0_TGRAN64_NI),
+   ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_TGRAN16_SHIFT, 4, ID_AA64MMFR0_TGRAN16_NI),
+
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_BIGENDEL0_SHIFT, 4, 0),
/* Linux shouldn't care about secure memory */
ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 
ID_AA64MMFR0_SNSMEM_SHIFT, 4, 0),
-- 
2.20.1



Re: [PATCH 3/9] drivers: ata: ahci_tegra: use devm_platform_ioremap_resource()

2019-08-20 Thread Bartlomiej Zolnierkiewicz


On 8/20/19 2:35 PM, Enrico Weigelt, metux IT consult wrote:
> Use the new helper that wraps the calls to platform_get_resource()
> and devm_ioremap_resource() together.
> 
> Signed-off-by: Enrico Weigelt, metux IT consult 
> ---
>  drivers/ata/ahci_tegra.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/ata/ahci_tegra.c b/drivers/ata/ahci_tegra.c
> index e3163da..3845c23 100644
> --- a/drivers/ata/ahci_tegra.c
> +++ b/drivers/ata/ahci_tegra.c
> @@ -481,7 +481,6 @@ static int tegra_ahci_probe(struct platform_device *pdev)
>  {
>   struct ahci_host_priv *hpriv;
>   struct tegra_ahci_priv *tegra;
> - struct resource *res;
>   int ret;
>   unsigned int i;
>  
> @@ -498,19 +497,17 @@ static int tegra_ahci_probe(struct platform_device 
> *pdev)
>   tegra->pdev = pdev;
>   tegra->soc = of_device_get_match_data(&pdev->dev);
>  
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> - tegra->sata_regs = devm_ioremap_resource(&pdev->dev, res);
> + tegra->sata_regs = devm_platform_ioremap_resource(pdev, 1);
>   if (IS_ERR(tegra->sata_regs))
>   return PTR_ERR(tegra->sata_regs);
>  
>   /*
>* AUX registers is optional.
>*/
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
> - if (res) {
> - tegra->sata_aux_regs = devm_ioremap_resource(&pdev->dev, res);
> - if (IS_ERR(tegra->sata_aux_regs))
> - return PTR_ERR(tegra->sata_aux_regs);
> + tegra->sata_aux_regs = devm_platform_ioremap_resource(pdev, 2);

This conversion is incorrect - despite the resource being optional
we will get error message from devm_[platform_]ioremap_resource()
(it always prints an error on !res condition).

> + if (IS_ERR(tegra->sata_aux_regs)) {
> + dev_info(&pdev->dev, "Cant get aux registers (optional)");

No need for this message.

> + tegra->sata_aux_regs = NULL;
>   }
>  
>   tegra->sata_rst = devm_reset_control_get(&pdev->dev, "sata");
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics


[PATCH AUTOSEL 4.9 1/7] dmaengine: ste_dma40: fix unneeded variable warning

2019-08-20 Thread Sasha Levin
From: Arnd Bergmann 

[ Upstream commit 5d6fb560729a5d5554e23db8d00eb57cd0021083 ]

clang-9 points out that there are two variables that depending on the
configuration may only be used in an ARRAY_SIZE() expression but not
referenced:

drivers/dma/ste_dma40.c:145:12: error: variable 'd40_backup_regs' is not needed 
and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static u32 d40_backup_regs[] = {
   ^
drivers/dma/ste_dma40.c:214:12: error: variable 'd40_backup_regs_chan' is not 
needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static u32 d40_backup_regs_chan[] = {

Mark these __maybe_unused to shut up the warning.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Nathan Chancellor 
Reviewed-by: Linus Walleij 
Link: https://lore.kernel.org/r/20190712091357.744515-1-a...@arndb.de
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
---
 drivers/dma/ste_dma40.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 8684d11b29bba..68b41daab3a8f 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -142,7 +142,7 @@ enum d40_events {
  * when the DMA hw is powered off.
  * TODO: Add save/restore of D40_DREG_GCC on dma40 v3 or later, if that works.
  */
-static u32 d40_backup_regs[] = {
+static __maybe_unused u32 d40_backup_regs[] = {
D40_DREG_LCPA,
D40_DREG_LCLA,
D40_DREG_PRMSE,
@@ -211,7 +211,7 @@ static u32 d40_backup_regs_v4b[] = {
 
 #define BACKUP_REGS_SZ_V4B ARRAY_SIZE(d40_backup_regs_v4b)
 
-static u32 d40_backup_regs_chan[] = {
+static __maybe_unused u32 d40_backup_regs_chan[] = {
D40_CHAN_REG_SSCFG,
D40_CHAN_REG_SSELT,
D40_CHAN_REG_SSPTR,
-- 
2.20.1



Re: [PATCH 2/4] x86/vmware: Add a header file for hypercall definitions

2019-08-20 Thread Thomas Gleixner
On Tue, 20 Aug 2019, Thomas Hellström (VMware) wrote:

> On 8/20/19 1:32 PM, Peter Zijlstra wrote:
> > On Sun, Aug 18, 2019 at 04:33:14PM +0200, Thomas Hellström (VMware) wrote:
> > 
> > > +#define VMWARE_HYPERCALL \
> > > + ALTERNATIVE_2(".byte 0xed", \
> > > +   ".byte 0x0f, 0x01, 0xc1", X86_FEATURE_VMW_VMCALL, \
> > > +   ".byte 0x0f, 0x01, 0xd9", X86_FEATURE_VMW_VMMCALL)
> > For sanity, could we either add comments, or macros for those
> > instrucions?
> 
> Hmm. Here I followed and slightly extended what was done in asm/kvm_para.h.
> 
> What confuses me a bit is, if it's clarity we're after, why don't people use
> 
> #define VMWARE_HYPERCALL  \
>   ALTERNATIVE_2("inl (%%dx)", \
> "vmcall", X86_FEATURE_VMW_VMCALL, \   
> "vmmcall", X86_FEATURE_VMW_VMMCALL)
> 
> Seems to build fine here. Is it fear of old assemblers not supporting, for
> example vmmcall

The requirement for binutils is version >= 2.21. If 2.21 supports vmcall and
vmmcall all good.

Thanks,

tglx

[PATCH AUTOSEL 4.14 10/12] drm/ast: Fixed reboot test may cause system hanged

2019-08-20 Thread Sasha Levin
From: "Y.C. Chen" 

[ Upstream commit 05b439711f6ff8700e8660f97a1179650778b9cb ]

There is another thread still access standard VGA I/O while loading drm driver.
Disable standard VGA I/O decode to avoid this issue.

Signed-off-by: Y.C. Chen 
Reviewed-by: Benjamin Herrenschmidt 
Signed-off-by: Dave Airlie 
Link: 
https://patchwork.freedesktop.org/patch/msgid/1523410059-18415-1-git-send-email-yc_c...@aspeedtech.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/ast/ast_main.c | 5 -
 drivers/gpu/drm/ast/ast_mode.c | 2 +-
 drivers/gpu/drm/ast/ast_post.c | 2 +-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 373700c05a00f..224fa1ef87ff9 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -131,8 +131,8 @@ static int ast_detect_chip(struct drm_device *dev, bool 
*need_post)
 
 
/* Enable extended register access */
-   ast_enable_mmio(dev);
ast_open_key(ast);
+   ast_enable_mmio(dev);
 
/* Find out whether P2A works or whether to use device-tree */
ast_detect_config_mode(dev, &scu_rev);
@@ -576,6 +576,9 @@ void ast_driver_unload(struct drm_device *dev)
 {
struct ast_private *ast = dev->dev_private;
 
+   /* enable standard VGA decode */
+   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa1, 0x04);
+
ast_release_firmware(dev);
kfree(ast->dp501_fw_addr);
ast_mode_fini(dev);
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 343867b182dd8..a09fafa270822 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -600,7 +600,7 @@ static int ast_crtc_mode_set(struct drm_crtc *crtc,
return -EINVAL;
ast_open_key(ast);
 
-   ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xa1, 0xff, 0x04);
+   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa1, 0x06);
 
ast_set_std_reg(crtc, adjusted_mode, &vbios_mode);
ast_set_crtc_reg(crtc, adjusted_mode, &vbios_mode);
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index f7d421359d564..c1d1ac51d1c20 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -46,7 +46,7 @@ void ast_enable_mmio(struct drm_device *dev)
 {
struct ast_private *ast = dev->dev_private;
 
-   ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xa1, 0xff, 0x04);
+   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa1, 0x06);
 }
 
 
-- 
2.20.1



[PATCH AUTOSEL 4.14 08/12] i2c: rcar: avoid race when unregistering slave client

2019-08-20 Thread Sasha Levin
From: Wolfram Sang 

[ Upstream commit 7b814d852af6944657c2961039f404c4490771c0 ]

After we disabled interrupts, there might still be an active one
running. Sync before clearing the pointer to the slave device.

Fixes: de20d1857dd6 ("i2c: rcar: add slave support")
Reported-by: Krzysztof Adamski 
Signed-off-by: Wolfram Sang 
Reviewed-by: Krzysztof Adamski 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
---
 drivers/i2c/busses/i2c-rcar.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 3415733a93645..132c4a405bf83 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -144,6 +144,7 @@ struct rcar_i2c_priv {
enum dma_data_direction dma_direction;
 
struct reset_control *rstc;
+   int irq;
 };
 
 #define rcar_i2c_priv_to_dev(p)((p)->adap.dev.parent)
@@ -813,9 +814,11 @@ static int rcar_unreg_slave(struct i2c_client *slave)
 
WARN_ON(!priv->slave);
 
+   /* disable irqs and ensure none is running before clearing ptr */
rcar_i2c_write(priv, ICSIER, 0);
rcar_i2c_write(priv, ICSCR, 0);
 
+   synchronize_irq(priv->irq);
priv->slave = NULL;
 
pm_runtime_put(rcar_i2c_priv_to_dev(priv));
@@ -866,7 +869,7 @@ static int rcar_i2c_probe(struct platform_device *pdev)
struct i2c_adapter *adap;
struct device *dev = &pdev->dev;
struct i2c_timings i2c_t;
-   int irq, ret;
+   int ret;
 
priv = devm_kzalloc(dev, sizeof(struct rcar_i2c_priv), GFP_KERNEL);
if (!priv)
@@ -927,10 +930,10 @@ static int rcar_i2c_probe(struct platform_device *pdev)
pm_runtime_put(dev);
 
 
-   irq = platform_get_irq(pdev, 0);
-   ret = devm_request_irq(dev, irq, rcar_i2c_irq, 0, dev_name(dev), priv);
+   priv->irq = platform_get_irq(pdev, 0);
+   ret = devm_request_irq(dev, priv->irq, rcar_i2c_irq, 0, dev_name(dev), 
priv);
if (ret < 0) {
-   dev_err(dev, "cannot get irq %d\n", irq);
+   dev_err(dev, "cannot get irq %d\n", priv->irq);
goto out_pm_disable;
}
 
-- 
2.20.1



[PATCH AUTOSEL 4.14 09/12] i2c: emev2: avoid race when unregistering slave client

2019-08-20 Thread Sasha Levin
From: Wolfram Sang 

[ Upstream commit d7437fc0d8291181debe032671a289b6bd93f46f ]

After we disabled interrupts, there might still be an active one
running. Sync before clearing the pointer to the slave device.

Fixes: c31d0a00021d ("i2c: emev2: add slave support")
Reported-by: Krzysztof Adamski 
Signed-off-by: Wolfram Sang 
Reviewed-by: Krzysztof Adamski 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
---
 drivers/i2c/busses/i2c-emev2.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-emev2.c b/drivers/i2c/busses/i2c-emev2.c
index d2e84480fbe96..dd97e5d9f49a2 100644
--- a/drivers/i2c/busses/i2c-emev2.c
+++ b/drivers/i2c/busses/i2c-emev2.c
@@ -72,6 +72,7 @@ struct em_i2c_device {
struct completion msg_done;
struct clk *sclk;
struct i2c_client *slave;
+   int irq;
 };
 
 static inline void em_clear_set_bit(struct em_i2c_device *priv, u8 clear, u8 
set, u8 reg)
@@ -342,6 +343,12 @@ static int em_i2c_unreg_slave(struct i2c_client *slave)
 
writeb(0, priv->base + I2C_OFS_SVA0);
 
+   /*
+* Wait for interrupt to finish. New slave irqs cannot happen because we
+* cleared the slave address and, thus, only extension codes will be
+* detected which do not use the slave ptr.
+*/
+   synchronize_irq(priv->irq);
priv->slave = NULL;
 
return 0;
@@ -358,7 +365,7 @@ static int em_i2c_probe(struct platform_device *pdev)
 {
struct em_i2c_device *priv;
struct resource *r;
-   int irq, ret;
+   int ret;
 
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -393,8 +400,8 @@ static int em_i2c_probe(struct platform_device *pdev)
 
em_i2c_reset(&priv->adap);
 
-   irq = platform_get_irq(pdev, 0);
-   ret = devm_request_irq(&pdev->dev, irq, em_i2c_irq_handler, 0,
+   priv->irq = platform_get_irq(pdev, 0);
+   ret = devm_request_irq(&pdev->dev, priv->irq, em_i2c_irq_handler, 0,
"em_i2c", priv);
if (ret)
goto err_clk;
@@ -404,7 +411,8 @@ static int em_i2c_probe(struct platform_device *pdev)
if (ret)
goto err_clk;
 
-   dev_info(&pdev->dev, "Added i2c controller %d, irq %d\n", 
priv->adap.nr, irq);
+   dev_info(&pdev->dev, "Added i2c controller %d, irq %d\n", priv->adap.nr,
+priv->irq);
 
return 0;
 
-- 
2.20.1



Re: [PATCH v2 2/3] dt-bindings: PCI: intel: Add YAML schemas for the PCIe RC controller

2019-08-20 Thread Rob Herring
On Tue, Aug 20, 2019 at 4:40 AM Dilip Kota  wrote:
>
> The Intel PCIe RC controller is Synopsys Designware
> based PCIe core. Add YAML schemas for PCIe in RC mode
> present in Intel Universal Gateway soc.

Run 'make dt_binding_check' and fix all the warnings.

>
> Signed-off-by: Dilip Kota 
> ---
>  .../devicetree/bindings/pci/intel-pcie.yaml| 133 
> +
>  1 file changed, 133 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/intel-pcie.yaml
>
> diff --git a/Documentation/devicetree/bindings/pci/intel-pcie.yaml 
> b/Documentation/devicetree/bindings/pci/intel-pcie.yaml
> new file mode 100644
> index ..80caaaba5e2c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/intel-pcie.yaml
> @@ -0,0 +1,133 @@
> +# SPDX-License-Identifier: GPL-2.0

(GPL-2.0-only OR BSD-2-Clause) is preferred for new bindings.

> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/intel-pcie.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Intel AXI bus based PCI express root complex
> +
> +maintainers:
> +  - Dilip Kota 
> +
> +properties:
> +  compatible:
> +const: intel,lgm-pcie
> +
> +  device_type:
> +const: pci
> +
> +  "#address-cells":
> +const: 3
> +
> +  "#size-cells":
> +const: 2
> +
> +  reg:
> +items:
> +  - description: Controller control and status registers.
> +  - description: PCIe configuration registers.
> +  - description: Controller application registers.
> +
> +  reg-names:
> +items:
> +  - const: dbi
> +  - const: config
> +  - const: app
> +
> +  ranges:
> +description: Ranges for the PCI memory and I/O regions.
> +
> +  resets:
> +maxItems: 1
> +
> +  clocks:
> +description: PCIe registers interface clock.
> +
> +  phys:
> +maxItems: 1
> +
> +  phy-names:
> +const: phy
> +
> +  reset-gpios:
> +maxItems: 1
> +
> +  num-lanes:
> +description: Number of lanes to use for this port.
> +
> +  linux,pci-domain:
> +description: PCI domain ID.
> +
> +  interrupts:
> +description: PCIe core integrated miscellaneous interrupt.
> +
> +  interrupt-map-mask:
> +description: Standard PCI IRQ mapping properties.
> +
> +  interrupt-map:
> +description: Standard PCI IRQ mapping properties.
> +
> +  max-link-speed:
> +description: Specify PCI Gen for link capability.
> +
> +  bus-range:
> +description: Range of bus numbers associated with this controller.
> +
> +  intel,rst-interval:

Use 'reset-assert-us'

> +description: |
> +  Device reset interval in ms. Some devices need an interval upto 500ms.
> +  By default it is 100ms.
> +
> +required:
> +  - compatible
> +  - device_type
> +  - reg
> +  - reg-names
> +  - ranges
> +  - resets
> +  - clocks
> +  - phys
> +  - phy-names
> +  - reset-gpios
> +  - num-lanes
> +  - linux,pci-domain
> +  - interrupts
> +  - interrupt-map
> +  - interrupt-map-mask
> +
> +examples:
> +  - |
> +pcie10:pcie@d0e0 {
> +  compatible = "intel,lgm-pcie";
> +  device_type = "pci";
> +  #address-cells = <3>;
> +  #size-cells = <2>;
> +  reg = <
> +0xd0e0 0x1000
> +0xd200 0x80
> +0xd0a41000 0x1000
> +>;
> +  reg-names = "dbi", "config", "app";
> +  linux,pci-domain = <0>;
> +  max-link-speed = <4>;
> +  bus-range = <0x00 0x08>;
> +  interrupt-parent = <&ioapic1>;
> +  interrupts = <67 1>;
> +  interrupt-map-mask = <0 0 0 0x7>;
> +  interrupt-map = <0 0 0 1 &ioapic1 27 1>,
> +  <0 0 0 2 &ioapic1 28 1>,
> +  <0 0 0 3 &ioapic1 29 1>,
> +  <0 0 0 4 &ioapic1 30 1>;
> +  ranges = <0x0200 0 0xd400 0xd400 0 0x0400>;
> +  resets = <&rcu0 0x50 0>;
> +  clocks = <&cgu0 LGM_GCLK_PCIE10>;
> +  phys = <&cb0phy0>;
> +  phy-names = "phy";
> +};
> +
> +&pcie10 {

Don't show this soc/board split in examples. Just combine to one node.

> +  status = "okay";
> +  intel,rst-interval = <100>;
> +  reset-gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
> +  num-lanes = <2>;
> +};
> --
> 2.11.0
>


Re: [PATCH RESEND v4 7/9] KVM: VMX: Handle SPP induced vmexit and page fault

2019-08-20 Thread Yang Weijiang
On Mon, Aug 19, 2019 at 05:04:23PM +0200, Paolo Bonzini wrote:
> On 19/08/19 16:43, Paolo Bonzini wrote:
> >> +  /*
> >> +   * Record write protect fault caused by
> >> +   * Sub-page Protection, let VMI decide
> >> +   * the next step.
> >> +   */
> >> +  if (spte & PT_SPP_MASK) {
> > Should this be "if (spte & PT_WRITABLE_MASK)" instead?  That is, if the
> > page is already writable, the fault must be an SPP fault.
> 
> Hmm, no I forgot how SPP works; still, this is *not* correct.  For
> example, if SPP marks part of a page as read-write, but KVM wants to
> write-protect the whole page for access or dirty tracking, that should
> not cause an SPP exit.
> 
> So I think that when KVM wants to write-protect the whole page
> (wrprot_ad_disabled_spte) it must also clear PT_SPP_MASK; for example it
> could save it in bit 53 (PT64_SECOND_AVAIL_BITS_SHIFT + 1).  If the
> saved bit is set, fast_page_fault must then set PT_SPP_MASK instead of
> PT_WRITABLE_MASK.
Sure, will change the processing flow.

> On re-entry this will cause an SPP vmexit;
> fast_page_fault should never trigger an SPP userspace exit on its own,
> all the SPP handling should go through handle_spp.
> 
> Paolo


[PATCH AUTOSEL 4.14 06/12] usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt

2019-08-20 Thread Sasha Levin
From: Benjamin Herrenschmidt 

[ Upstream commit 4a56a478a525d6427be90753451c40e1327caa1a ]

If fsg_disable() and fsg_set_alt() are called too closely to each
other (for example due to a quick reset/reconnect), what can happen
is that fsg_set_alt sets common->new_fsg from an interrupt while
handle_exception is trying to process the config change caused by
fsg_disable():

fsg_disable()
...
handle_exception()
sets state back to FSG_STATE_NORMAL
hasn't yet called do_set_interface()
or is inside it.

 ---> interrupt
fsg_set_alt
sets common->new_fsg
queues a new FSG_STATE_CONFIG_CHANGE
 <---

Now, the first handle_exception can "see" the updated
new_fsg, treats it as if it was a fsg_set_alt() response,
call usb_composite_setup_continue() etc...

But then, the thread sees the second FSG_STATE_CONFIG_CHANGE,
and goes back down the same path, wipes and reattaches a now
active fsg, and .. calls usb_composite_setup_continue() which
at this point is wrong.

Not only we get a backtrace, but I suspect the second set_interface
wrecks some state causing the host to get upset in my case.

This fixes it by replacing "new_fsg" by a "state argument" (same
principle) which is set in the same lock section as the state
update, and retrieved similarly.

That way, there is never any discrepancy between the dequeued
state and the observed value of it. We keep the ability to have
the latest reconfig operation take precedence, but we guarantee
that once "dequeued" the argument (new_fsg) will not be clobbered
by any new event.

Signed-off-by: Benjamin Herrenschmidt 
Acked-by: Alan Stern 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
---
 drivers/usb/gadget/function/f_mass_storage.c | 28 +---
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/gadget/function/f_mass_storage.c 
b/drivers/usb/gadget/function/f_mass_storage.c
index 25ba303295332..41b5baa1f43b7 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -261,7 +261,7 @@ struct fsg_common;
 struct fsg_common {
struct usb_gadget   *gadget;
struct usb_composite_dev *cdev;
-   struct fsg_dev  *fsg, *new_fsg;
+   struct fsg_dev  *fsg;
wait_queue_head_t   io_wait;
wait_queue_head_t   fsg_wait;
 
@@ -290,6 +290,7 @@ struct fsg_common {
unsigned intbulk_out_maxpacket;
enum fsg_state  state;  /* For exception handling */
unsigned intexception_req_tag;
+   void*exception_arg;
 
enum data_direction data_dir;
u32 data_size;
@@ -393,7 +394,8 @@ static int fsg_set_halt(struct fsg_dev *fsg, struct usb_ep 
*ep)
 
 /* These routines may be called in process context or in_irq */
 
-static void raise_exception(struct fsg_common *common, enum fsg_state 
new_state)
+static void __raise_exception(struct fsg_common *common, enum fsg_state 
new_state,
+ void *arg)
 {
unsigned long   flags;
 
@@ -406,6 +408,7 @@ static void raise_exception(struct fsg_common *common, enum 
fsg_state new_state)
if (common->state <= new_state) {
common->exception_req_tag = common->ep0_req_tag;
common->state = new_state;
+   common->exception_arg = arg;
if (common->thread_task)
send_sig_info(SIGUSR1, SEND_SIG_FORCED,
  common->thread_task);
@@ -413,6 +416,10 @@ static void raise_exception(struct fsg_common *common, 
enum fsg_state new_state)
spin_unlock_irqrestore(&common->lock, flags);
 }
 
+static void raise_exception(struct fsg_common *common, enum fsg_state 
new_state)
+{
+   __raise_exception(common, new_state, NULL);
+}
 
 /*-*/
 
@@ -2287,16 +2294,16 @@ static int do_set_interface(struct fsg_common *common, 
struct fsg_dev *new_fsg)
 static int fsg_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
 {
struct fsg_dev *fsg = fsg_from_func(f);
-   fsg->common->new_fsg = fsg;
-   raise_exception(fsg->common, FSG_STATE_CONFIG_CHANGE);
+
+   __raise_exception(fsg->common, FSG_STATE_CONFIG_CHANGE, fsg);
return USB_GADGET_DELAYED_STATUS;
 }
 
 static void fsg_disable(struct usb_function *f)
 {
struct fsg_dev *fsg = fsg_from_func(f);
-   fsg->common->new_fsg = NULL;
-   raise_exception(fsg->common, FSG_STATE_CONFIG_CHANGE);
+
+   __raise_exception(fsg->common, FSG_STATE_CONFIG_CHANGE, NULL);
 }
 
 
@@ -2309,6 +2316,7 @@ static void handle_exception(struct fsg_common *common)
enum fsg_state  old_state;
struct fsg_lun  *curlun;
unsigned intexception_req_tag;

[PATCH AUTOSEL 4.14 12/12] tools: hv: fix KVP and VSS daemons exit code

2019-08-20 Thread Sasha Levin
From: Adrian Vladu 

[ Upstream commit b0995156071b0ff29a5902964a9dc8cfad6f81c0 ]

HyperV KVP and VSS daemons should exit with 0 when the '--help'
or '-h' flags are used.

Signed-off-by: Adrian Vladu 

Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Sasha Levin 
Cc: Alessandro Pilotti 
Signed-off-by: Sasha Levin 
---
 tools/hv/hv_kvp_daemon.c | 2 ++
 tools/hv/hv_vss_daemon.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 62c9a503ae052..0ef215061fb50 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -1380,6 +1380,8 @@ int main(int argc, char *argv[])
daemonize = 0;
break;
case 'h':
+   print_usage(argv);
+   exit(0);
default:
print_usage(argv);
exit(EXIT_FAILURE);
diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_daemon.c
index 34031a297f024..514d29966ac67 100644
--- a/tools/hv/hv_vss_daemon.c
+++ b/tools/hv/hv_vss_daemon.c
@@ -172,6 +172,8 @@ int main(int argc, char *argv[])
daemonize = 0;
break;
case 'h':
+   print_usage(argv);
+   exit(0);
default:
print_usage(argv);
exit(EXIT_FAILURE);
-- 
2.20.1



[PATCH AUTOSEL 4.9 5/7] i2c: emev2: avoid race when unregistering slave client

2019-08-20 Thread Sasha Levin
From: Wolfram Sang 

[ Upstream commit d7437fc0d8291181debe032671a289b6bd93f46f ]

After we disabled interrupts, there might still be an active one
running. Sync before clearing the pointer to the slave device.

Fixes: c31d0a00021d ("i2c: emev2: add slave support")
Reported-by: Krzysztof Adamski 
Signed-off-by: Wolfram Sang 
Reviewed-by: Krzysztof Adamski 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
---
 drivers/i2c/busses/i2c-emev2.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-emev2.c b/drivers/i2c/busses/i2c-emev2.c
index 96bb4e7490128..0218ba6eb26ab 100644
--- a/drivers/i2c/busses/i2c-emev2.c
+++ b/drivers/i2c/busses/i2c-emev2.c
@@ -72,6 +72,7 @@ struct em_i2c_device {
struct completion msg_done;
struct clk *sclk;
struct i2c_client *slave;
+   int irq;
 };
 
 static inline void em_clear_set_bit(struct em_i2c_device *priv, u8 clear, u8 
set, u8 reg)
@@ -342,6 +343,12 @@ static int em_i2c_unreg_slave(struct i2c_client *slave)
 
writeb(0, priv->base + I2C_OFS_SVA0);
 
+   /*
+* Wait for interrupt to finish. New slave irqs cannot happen because we
+* cleared the slave address and, thus, only extension codes will be
+* detected which do not use the slave ptr.
+*/
+   synchronize_irq(priv->irq);
priv->slave = NULL;
 
return 0;
@@ -358,7 +365,7 @@ static int em_i2c_probe(struct platform_device *pdev)
 {
struct em_i2c_device *priv;
struct resource *r;
-   int irq, ret;
+   int ret;
 
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -391,8 +398,8 @@ static int em_i2c_probe(struct platform_device *pdev)
 
em_i2c_reset(&priv->adap);
 
-   irq = platform_get_irq(pdev, 0);
-   ret = devm_request_irq(&pdev->dev, irq, em_i2c_irq_handler, 0,
+   priv->irq = platform_get_irq(pdev, 0);
+   ret = devm_request_irq(&pdev->dev, priv->irq, em_i2c_irq_handler, 0,
"em_i2c", priv);
if (ret)
goto err_clk;
@@ -402,7 +409,8 @@ static int em_i2c_probe(struct platform_device *pdev)
if (ret)
goto err_clk;
 
-   dev_info(&pdev->dev, "Added i2c controller %d, irq %d\n", 
priv->adap.nr, irq);
+   dev_info(&pdev->dev, "Added i2c controller %d, irq %d\n", priv->adap.nr,
+priv->irq);
 
return 0;
 
-- 
2.20.1



[PATCH AUTOSEL 4.9 6/7] usb: host: fotg2: restart hcd after port reset

2019-08-20 Thread Sasha Levin
From: Hans Ulli Kroll 

[ Upstream commit 5ffe59ef754cc39ab2f275dc277732f4 ]

On the Gemini SoC the FOTG2 stalls after port reset
so restart the HCD after each port reset.

Signed-off-by: Hans Ulli Kroll 
Signed-off-by: Linus Walleij 
Link: https://lore.kernel.org/r/20190810150458.817-1-linus.wall...@linaro.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/usb/host/fotg210-hcd.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
index 66efa9a676877..72853020a5426 100644
--- a/drivers/usb/host/fotg210-hcd.c
+++ b/drivers/usb/host/fotg210-hcd.c
@@ -1653,6 +1653,10 @@ static int fotg210_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
/* see what we found out */
temp = check_reset_complete(fotg210, wIndex, status_reg,
fotg210_readl(fotg210, status_reg));
+
+   /* restart schedule */
+   fotg210->command |= CMD_RUN;
+   fotg210_writel(fotg210, fotg210->command, 
&fotg210->regs->command);
}
 
if (!(temp & (PORT_RESUME|PORT_RESET))) {
-- 
2.20.1



[PATCH AUTOSEL 4.4 1/4] dmaengine: ste_dma40: fix unneeded variable warning

2019-08-20 Thread Sasha Levin
From: Arnd Bergmann 

[ Upstream commit 5d6fb560729a5d5554e23db8d00eb57cd0021083 ]

clang-9 points out that there are two variables that depending on the
configuration may only be used in an ARRAY_SIZE() expression but not
referenced:

drivers/dma/ste_dma40.c:145:12: error: variable 'd40_backup_regs' is not needed 
and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static u32 d40_backup_regs[] = {
   ^
drivers/dma/ste_dma40.c:214:12: error: variable 'd40_backup_regs_chan' is not 
needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static u32 d40_backup_regs_chan[] = {

Mark these __maybe_unused to shut up the warning.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Nathan Chancellor 
Reviewed-by: Linus Walleij 
Link: https://lore.kernel.org/r/20190712091357.744515-1-a...@arndb.de
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
---
 drivers/dma/ste_dma40.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index dd3e7ba273ad0..0fede051f4e1c 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -142,7 +142,7 @@ enum d40_events {
  * when the DMA hw is powered off.
  * TODO: Add save/restore of D40_DREG_GCC on dma40 v3 or later, if that works.
  */
-static u32 d40_backup_regs[] = {
+static __maybe_unused u32 d40_backup_regs[] = {
D40_DREG_LCPA,
D40_DREG_LCLA,
D40_DREG_PRMSE,
@@ -211,7 +211,7 @@ static u32 d40_backup_regs_v4b[] = {
 
 #define BACKUP_REGS_SZ_V4B ARRAY_SIZE(d40_backup_regs_v4b)
 
-static u32 d40_backup_regs_chan[] = {
+static __maybe_unused u32 d40_backup_regs_chan[] = {
D40_CHAN_REG_SSCFG,
D40_CHAN_REG_SSELT,
D40_CHAN_REG_SSPTR,
-- 
2.20.1



[PATCH AUTOSEL 4.4 4/4] tools: hv: fix KVP and VSS daemons exit code

2019-08-20 Thread Sasha Levin
From: Adrian Vladu 

[ Upstream commit b0995156071b0ff29a5902964a9dc8cfad6f81c0 ]

HyperV KVP and VSS daemons should exit with 0 when the '--help'
or '-h' flags are used.

Signed-off-by: Adrian Vladu 

Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Sasha Levin 
Cc: Alessandro Pilotti 
Signed-off-by: Sasha Levin 
---
 tools/hv/hv_kvp_daemon.c | 2 ++
 tools/hv/hv_vss_daemon.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 1774800668168..fffc7c4184599 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -1379,6 +1379,8 @@ int main(int argc, char *argv[])
daemonize = 0;
break;
case 'h':
+   print_usage(argv);
+   exit(0);
default:
print_usage(argv);
exit(EXIT_FAILURE);
diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_daemon.c
index 5d51d6ff08e6a..b5465f92ed50e 100644
--- a/tools/hv/hv_vss_daemon.c
+++ b/tools/hv/hv_vss_daemon.c
@@ -164,6 +164,8 @@ int main(int argc, char *argv[])
daemonize = 0;
break;
case 'h':
+   print_usage(argv);
+   exit(0);
default:
print_usage(argv);
exit(EXIT_FAILURE);
-- 
2.20.1



[PATCH AUTOSEL 4.9 7/7] tools: hv: fix KVP and VSS daemons exit code

2019-08-20 Thread Sasha Levin
From: Adrian Vladu 

[ Upstream commit b0995156071b0ff29a5902964a9dc8cfad6f81c0 ]

HyperV KVP and VSS daemons should exit with 0 when the '--help'
or '-h' flags are used.

Signed-off-by: Adrian Vladu 

Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Sasha Levin 
Cc: Alessandro Pilotti 
Signed-off-by: Sasha Levin 
---
 tools/hv/hv_kvp_daemon.c | 2 ++
 tools/hv/hv_vss_daemon.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 1774800668168..fffc7c4184599 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -1379,6 +1379,8 @@ int main(int argc, char *argv[])
daemonize = 0;
break;
case 'h':
+   print_usage(argv);
+   exit(0);
default:
print_usage(argv);
exit(EXIT_FAILURE);
diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_daemon.c
index e0829809c8970..bdc1891e0a9a3 100644
--- a/tools/hv/hv_vss_daemon.c
+++ b/tools/hv/hv_vss_daemon.c
@@ -164,6 +164,8 @@ int main(int argc, char *argv[])
daemonize = 0;
break;
case 'h':
+   print_usage(argv);
+   exit(0);
default:
print_usage(argv);
exit(EXIT_FAILURE);
-- 
2.20.1



[PATCH AUTOSEL 4.9 3/7] usb: gadget: composite: Clear "suspended" on reset/disconnect

2019-08-20 Thread Sasha Levin
From: Benjamin Herrenschmidt 

[ Upstream commit 602fda17c7356bb7ae98467d93549057481d11dd ]

In some cases, one can get out of suspend with a reset or
a disconnect followed by a reconnect. Previously we would
leave a stale suspended flag set.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
---
 drivers/usb/gadget/composite.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 2c022a08f1638..9fa168af847b5 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -2000,6 +2000,7 @@ void composite_disconnect(struct usb_gadget *gadget)
 * disconnect callbacks?
 */
spin_lock_irqsave(&cdev->lock, flags);
+   cdev->suspended = 0;
if (cdev->config)
reset_config(cdev);
if (cdev->driver->disconnect)
-- 
2.20.1



[PATCH AUTOSEL 4.19 22/27] i2c: rcar: avoid race when unregistering slave client

2019-08-20 Thread Sasha Levin
From: Wolfram Sang 

[ Upstream commit 7b814d852af6944657c2961039f404c4490771c0 ]

After we disabled interrupts, there might still be an active one
running. Sync before clearing the pointer to the slave device.

Fixes: de20d1857dd6 ("i2c: rcar: add slave support")
Reported-by: Krzysztof Adamski 
Signed-off-by: Wolfram Sang 
Reviewed-by: Krzysztof Adamski 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
---
 drivers/i2c/busses/i2c-rcar.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 254e6219e5389..2c29f901d3090 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -139,6 +139,7 @@ struct rcar_i2c_priv {
enum dma_data_direction dma_direction;
 
struct reset_control *rstc;
+   int irq;
 };
 
 #define rcar_i2c_priv_to_dev(p)((p)->adap.dev.parent)
@@ -859,9 +860,11 @@ static int rcar_unreg_slave(struct i2c_client *slave)
 
WARN_ON(!priv->slave);
 
+   /* disable irqs and ensure none is running before clearing ptr */
rcar_i2c_write(priv, ICSIER, 0);
rcar_i2c_write(priv, ICSCR, 0);
 
+   synchronize_irq(priv->irq);
priv->slave = NULL;
 
pm_runtime_put(rcar_i2c_priv_to_dev(priv));
@@ -916,7 +919,7 @@ static int rcar_i2c_probe(struct platform_device *pdev)
struct i2c_adapter *adap;
struct device *dev = &pdev->dev;
struct i2c_timings i2c_t;
-   int irq, ret;
+   int ret;
 
priv = devm_kzalloc(dev, sizeof(struct rcar_i2c_priv), GFP_KERNEL);
if (!priv)
@@ -979,10 +982,10 @@ static int rcar_i2c_probe(struct platform_device *pdev)
pm_runtime_put(dev);
 
 
-   irq = platform_get_irq(pdev, 0);
-   ret = devm_request_irq(dev, irq, rcar_i2c_irq, 0, dev_name(dev), priv);
+   priv->irq = platform_get_irq(pdev, 0);
+   ret = devm_request_irq(dev, priv->irq, rcar_i2c_irq, 0, dev_name(dev), 
priv);
if (ret < 0) {
-   dev_err(dev, "cannot get irq %d\n", irq);
+   dev_err(dev, "cannot get irq %d\n", priv->irq);
goto out_pm_disable;
}
 
-- 
2.20.1



[PATCH AUTOSEL 4.19 20/27] xen/blkback: fix memory leaks

2019-08-20 Thread Sasha Levin
From: Wenwen Wang 

[ Upstream commit ae78ca3cf3d9e9f914bfcd0bc5c389ff18b9c2e0 ]

In read_per_ring_refs(), after 'req' and related memory regions are
allocated, xen_blkif_map() is invoked to map the shared frame, irq, and
etc. However, if this mapping process fails, no cleanup is performed,
leading to memory leaks. To fix this issue, invoke the cleanup before
returning the error.

Acked-by: Roger Pau Monné 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: Wenwen Wang 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
---
 drivers/block/xen-blkback/xenbus.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index a4bc74e72c394..55869b362fdfb 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -974,6 +974,7 @@ static int read_per_ring_refs(struct xen_blkif_ring *ring, 
const char *dir)
}
blkif->nr_ring_pages = nr_grefs;
 
+   err = -ENOMEM;
for (i = 0; i < nr_grefs * XEN_BLKIF_REQS_PER_PAGE; i++) {
req = kzalloc(sizeof(*req), GFP_KERNEL);
if (!req)
@@ -996,7 +997,7 @@ static int read_per_ring_refs(struct xen_blkif_ring *ring, 
const char *dir)
err = xen_blkif_map(ring, ring_ref, nr_grefs, evtchn);
if (err) {
xenbus_dev_fatal(dev, err, "mapping ring-ref port %u", evtchn);
-   return err;
+   goto fail;
}
 
return 0;
@@ -1016,8 +1017,7 @@ static int read_per_ring_refs(struct xen_blkif_ring 
*ring, const char *dir)
}
kfree(req);
}
-   return -ENOMEM;
-
+   return err;
 }
 
 static int connect_ring(struct backend_info *be)
-- 
2.20.1



[PATCH AUTOSEL 4.19 23/27] i2c: emev2: avoid race when unregistering slave client

2019-08-20 Thread Sasha Levin
From: Wolfram Sang 

[ Upstream commit d7437fc0d8291181debe032671a289b6bd93f46f ]

After we disabled interrupts, there might still be an active one
running. Sync before clearing the pointer to the slave device.

Fixes: c31d0a00021d ("i2c: emev2: add slave support")
Reported-by: Krzysztof Adamski 
Signed-off-by: Wolfram Sang 
Reviewed-by: Krzysztof Adamski 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
---
 drivers/i2c/busses/i2c-emev2.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-emev2.c b/drivers/i2c/busses/i2c-emev2.c
index 35b302d983e0d..959d4912ec0d5 100644
--- a/drivers/i2c/busses/i2c-emev2.c
+++ b/drivers/i2c/busses/i2c-emev2.c
@@ -69,6 +69,7 @@ struct em_i2c_device {
struct completion msg_done;
struct clk *sclk;
struct i2c_client *slave;
+   int irq;
 };
 
 static inline void em_clear_set_bit(struct em_i2c_device *priv, u8 clear, u8 
set, u8 reg)
@@ -339,6 +340,12 @@ static int em_i2c_unreg_slave(struct i2c_client *slave)
 
writeb(0, priv->base + I2C_OFS_SVA0);
 
+   /*
+* Wait for interrupt to finish. New slave irqs cannot happen because we
+* cleared the slave address and, thus, only extension codes will be
+* detected which do not use the slave ptr.
+*/
+   synchronize_irq(priv->irq);
priv->slave = NULL;
 
return 0;
@@ -355,7 +362,7 @@ static int em_i2c_probe(struct platform_device *pdev)
 {
struct em_i2c_device *priv;
struct resource *r;
-   int irq, ret;
+   int ret;
 
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -390,8 +397,8 @@ static int em_i2c_probe(struct platform_device *pdev)
 
em_i2c_reset(&priv->adap);
 
-   irq = platform_get_irq(pdev, 0);
-   ret = devm_request_irq(&pdev->dev, irq, em_i2c_irq_handler, 0,
+   priv->irq = platform_get_irq(pdev, 0);
+   ret = devm_request_irq(&pdev->dev, priv->irq, em_i2c_irq_handler, 0,
"em_i2c", priv);
if (ret)
goto err_clk;
@@ -401,7 +408,8 @@ static int em_i2c_probe(struct platform_device *pdev)
if (ret)
goto err_clk;
 
-   dev_info(&pdev->dev, "Added i2c controller %d, irq %d\n", 
priv->adap.nr, irq);
+   dev_info(&pdev->dev, "Added i2c controller %d, irq %d\n", priv->adap.nr,
+priv->irq);
 
return 0;
 
-- 
2.20.1



[PATCH AUTOSEL 4.9 2/7] iommu/dma: Handle SG length overflow better

2019-08-20 Thread Sasha Levin
From: Robin Murphy 

[ Upstream commit ab2cbeb0ed301a9f0460078e91b09f39958212ef ]

Since scatterlist dimensions are all unsigned ints, in the relatively
rare cases where a device's max_segment_size is set to UINT_MAX, then
the "cur_len + s_length <= max_len" check in __finalise_sg() will always
return true. As a result, the corner case of such a device mapping an
excessively large scatterlist which is mergeable to or beyond a total
length of 4GB can lead to overflow and a bogus truncated dma_length in
the resulting segment.

As we already assume that any single segment must be no longer than
max_len to begin with, this can easily be addressed by reshuffling the
comparison.

Fixes: 809eac54cdd6 ("iommu/dma: Implement scatterlist segment merging")
Reported-by: Nicolin Chen 
Tested-by: Nicolin Chen 
Signed-off-by: Robin Murphy 
Signed-off-by: Joerg Roedel 
Signed-off-by: Sasha Levin 
---
 drivers/iommu/dma-iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 1520e7f02c2f1..89d191b6a0e0f 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -493,7 +493,7 @@ static int __finalise_sg(struct device *dev, struct 
scatterlist *sg, int nents,
 * - and wouldn't make the resulting output segment too long
 */
if (cur_len && !s_iova_off && (dma_addr & seg_mask) &&
-   (cur_len + s_length <= max_len)) {
+   (max_len - cur_len >= s_length)) {
/* ...then concatenate it with the previous one */
cur_len += s_length;
} else {
-- 
2.20.1



[PATCH AUTOSEL 4.19 25/27] usb: host: fotg2: restart hcd after port reset

2019-08-20 Thread Sasha Levin
From: Hans Ulli Kroll 

[ Upstream commit 5ffe59ef754cc39ab2f275dc277732f4 ]

On the Gemini SoC the FOTG2 stalls after port reset
so restart the HCD after each port reset.

Signed-off-by: Hans Ulli Kroll 
Signed-off-by: Linus Walleij 
Link: https://lore.kernel.org/r/20190810150458.817-1-linus.wall...@linaro.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/usb/host/fotg210-hcd.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
index e64eb47770c8b..2d5a72c15069e 100644
--- a/drivers/usb/host/fotg210-hcd.c
+++ b/drivers/usb/host/fotg210-hcd.c
@@ -1627,6 +1627,10 @@ static int fotg210_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
/* see what we found out */
temp = check_reset_complete(fotg210, wIndex, status_reg,
fotg210_readl(fotg210, status_reg));
+
+   /* restart schedule */
+   fotg210->command |= CMD_RUN;
+   fotg210_writel(fotg210, fotg210->command, 
&fotg210->regs->command);
}
 
if (!(temp & (PORT_RESUME|PORT_RESET))) {
-- 
2.20.1



[PATCH AUTOSEL 4.14 02/12] iio: adc: max9611: Fix temperature reading in probe

2019-08-20 Thread Sasha Levin
From: Jacopo Mondi 

[ Upstream commit b9ddd5091160793ee9fac10da765cf3f53d2aaf0 ]

The max9611 driver reads the die temperature at probe time to validate
the communication channel. Use the actual read value to perform the test
instead of the read function return value, which was mistakenly used so
far.

The temperature reading test was only successful because the 0 return
value is in the range of supported temperatures.

Fixes: 69780a3bbc0b ("iio: adc: Add Maxim max9611 ADC driver")
Signed-off-by: Jacopo Mondi 
Cc: 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin 
---
 drivers/iio/adc/max9611.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/adc/max9611.c b/drivers/iio/adc/max9611.c
index f8f298c33b287..c61fbf5602718 100644
--- a/drivers/iio/adc/max9611.c
+++ b/drivers/iio/adc/max9611.c
@@ -484,7 +484,7 @@ static int max9611_init(struct max9611_dev *max9611)
if (ret)
return ret;
 
-   regval = ret & MAX9611_TEMP_MASK;
+   regval &= MAX9611_TEMP_MASK;
 
if ((regval > MAX9611_TEMP_MAX_POS &&
 regval < MAX9611_TEMP_MIN_NEG) ||
-- 
2.20.1



[PATCH AUTOSEL 4.19 24/27] drm/ast: Fixed reboot test may cause system hanged

2019-08-20 Thread Sasha Levin
From: "Y.C. Chen" 

[ Upstream commit 05b439711f6ff8700e8660f97a1179650778b9cb ]

There is another thread still access standard VGA I/O while loading drm driver.
Disable standard VGA I/O decode to avoid this issue.

Signed-off-by: Y.C. Chen 
Reviewed-by: Benjamin Herrenschmidt 
Signed-off-by: Dave Airlie 
Link: 
https://patchwork.freedesktop.org/patch/msgid/1523410059-18415-1-git-send-email-yc_c...@aspeedtech.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/ast/ast_main.c | 5 -
 drivers/gpu/drm/ast/ast_mode.c | 2 +-
 drivers/gpu/drm/ast/ast_post.c | 2 +-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 373700c05a00f..224fa1ef87ff9 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -131,8 +131,8 @@ static int ast_detect_chip(struct drm_device *dev, bool 
*need_post)
 
 
/* Enable extended register access */
-   ast_enable_mmio(dev);
ast_open_key(ast);
+   ast_enable_mmio(dev);
 
/* Find out whether P2A works or whether to use device-tree */
ast_detect_config_mode(dev, &scu_rev);
@@ -576,6 +576,9 @@ void ast_driver_unload(struct drm_device *dev)
 {
struct ast_private *ast = dev->dev_private;
 
+   /* enable standard VGA decode */
+   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa1, 0x04);
+
ast_release_firmware(dev);
kfree(ast->dp501_fw_addr);
ast_mode_fini(dev);
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 8bb355d5d43d8..9d92d2d2fcfc7 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -600,7 +600,7 @@ static int ast_crtc_mode_set(struct drm_crtc *crtc,
return -EINVAL;
ast_open_key(ast);
 
-   ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xa1, 0xff, 0x04);
+   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa1, 0x06);
 
ast_set_std_reg(crtc, adjusted_mode, &vbios_mode);
ast_set_crtc_reg(crtc, adjusted_mode, &vbios_mode);
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index f7d421359d564..c1d1ac51d1c20 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -46,7 +46,7 @@ void ast_enable_mmio(struct drm_device *dev)
 {
struct ast_private *ast = dev->dev_private;
 
-   ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xa1, 0xff, 0x04);
+   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa1, 0x06);
 }
 
 
-- 
2.20.1



[PATCH AUTOSEL 4.14 01/12] dmaengine: ste_dma40: fix unneeded variable warning

2019-08-20 Thread Sasha Levin
From: Arnd Bergmann 

[ Upstream commit 5d6fb560729a5d5554e23db8d00eb57cd0021083 ]

clang-9 points out that there are two variables that depending on the
configuration may only be used in an ARRAY_SIZE() expression but not
referenced:

drivers/dma/ste_dma40.c:145:12: error: variable 'd40_backup_regs' is not needed 
and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static u32 d40_backup_regs[] = {
   ^
drivers/dma/ste_dma40.c:214:12: error: variable 'd40_backup_regs_chan' is not 
needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static u32 d40_backup_regs_chan[] = {

Mark these __maybe_unused to shut up the warning.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Nathan Chancellor 
Reviewed-by: Linus Walleij 
Link: https://lore.kernel.org/r/20190712091357.744515-1-a...@arndb.de
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
---
 drivers/dma/ste_dma40.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index c2b089af04208..90feb6a05e59b 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -142,7 +142,7 @@ enum d40_events {
  * when the DMA hw is powered off.
  * TODO: Add save/restore of D40_DREG_GCC on dma40 v3 or later, if that works.
  */
-static u32 d40_backup_regs[] = {
+static __maybe_unused u32 d40_backup_regs[] = {
D40_DREG_LCPA,
D40_DREG_LCLA,
D40_DREG_PRMSE,
@@ -211,7 +211,7 @@ static u32 d40_backup_regs_v4b[] = {
 
 #define BACKUP_REGS_SZ_V4B ARRAY_SIZE(d40_backup_regs_v4b)
 
-static u32 d40_backup_regs_chan[] = {
+static __maybe_unused u32 d40_backup_regs_chan[] = {
D40_CHAN_REG_SSCFG,
D40_CHAN_REG_SSELT,
D40_CHAN_REG_SSPTR,
-- 
2.20.1



[PATCH AUTOSEL 4.19 16/27] omap-dma/omap_vout_vrfb: fix off-by-one fi value

2019-08-20 Thread Sasha Levin
From: Hans Verkuil 

[ Upstream commit d555c34338cae844b207564c482e5a3fb089d25e ]

The OMAP 4 TRM specifies that when using double-index addressing
the address increases by the ES plus the EI value minus 1 within
a frame. When a full frame is transferred, the address increases
by the ES plus the frame index (FI) value minus 1.

The omap-dma code didn't account for the 'minus 1' in the FI register.
To get correct addressing, add 1 to the src_icg value.

This was found when testing a hacked version of the media m2m-deinterlace.c
driver on a Pandaboard.

The only other source that uses this feature is omap_vout_vrfb.c,
and that adds a + 1 when setting the dst_icg. This is a workaround
for the broken omap-dma.c behavior. So remove the workaround at the
same time that we fix omap-dma.c.

I tested the omap_vout driver with a Beagle XM board to check that
the '+ 1' in omap_vout_vrfb.c was indeed a workaround for the omap-dma
bug.

Signed-off-by: Hans Verkuil 
Reviewed-by: Laurent Pinchart 
Acked-by: Peter Ujfalusi 
Acked-by: Mauro Carvalho Chehab 
Link: https://lore.kernel.org/r/952e7f51-f208-9333-6f58-b7ed20d2e...@xs4all.nl
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
---
 drivers/dma/ti/omap-dma.c| 4 ++--
 drivers/media/platform/omap/omap_vout_vrfb.c | 3 +--
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/ti/omap-dma.c b/drivers/dma/ti/omap-dma.c
index a4a931ddf6f69..aeb9c29e52554 100644
--- a/drivers/dma/ti/omap-dma.c
+++ b/drivers/dma/ti/omap-dma.c
@@ -1237,7 +1237,7 @@ static struct dma_async_tx_descriptor 
*omap_dma_prep_dma_interleaved(
if (src_icg) {
d->ccr |= CCR_SRC_AMODE_DBLIDX;
d->ei = 1;
-   d->fi = src_icg;
+   d->fi = src_icg + 1;
} else if (xt->src_inc) {
d->ccr |= CCR_SRC_AMODE_POSTINC;
d->fi = 0;
@@ -1252,7 +1252,7 @@ static struct dma_async_tx_descriptor 
*omap_dma_prep_dma_interleaved(
if (dst_icg) {
d->ccr |= CCR_DST_AMODE_DBLIDX;
sg->ei = 1;
-   sg->fi = dst_icg;
+   sg->fi = dst_icg + 1;
} else if (xt->dst_inc) {
d->ccr |= CCR_DST_AMODE_POSTINC;
sg->fi = 0;
diff --git a/drivers/media/platform/omap/omap_vout_vrfb.c 
b/drivers/media/platform/omap/omap_vout_vrfb.c
index 29e3f5da59c1f..11ec048929e80 100644
--- a/drivers/media/platform/omap/omap_vout_vrfb.c
+++ b/drivers/media/platform/omap/omap_vout_vrfb.c
@@ -253,8 +253,7 @@ int omap_vout_prepare_vrfb(struct omap_vout_device *vout,
 */
 
pixsize = vout->bpp * vout->vrfb_bpp;
-   dst_icg = ((MAX_PIXELS_PER_LINE * pixsize) -
- (vout->pix.width * vout->bpp)) + 1;
+   dst_icg = MAX_PIXELS_PER_LINE * pixsize - vout->pix.width * vout->bpp;
 
xt->src_start = vout->buf_phy_addr[vb->i];
xt->dst_start = vout->vrfb_context[vb->i].paddr[0];
-- 
2.20.1



[PATCH AUTOSEL 4.19 15/27] dmaengine: stm32-mdma: Fix a possible null-pointer dereference in stm32_mdma_irq_handler()

2019-08-20 Thread Sasha Levin
From: Jia-Ju Bai 

[ Upstream commit 39c71a5b8212f4b502d9a630c6706ac723abd422 ]

In stm32_mdma_irq_handler(), chan is checked on line 1368.
When chan is NULL, it is still used on line 1369:
dev_err(chan2dev(chan), "MDMA channel not initialized\n");

Thus, a possible null-pointer dereference may occur.

To fix this bug, "dev_dbg(mdma2dev(dmadev), ...)" is used instead.

Signed-off-by: Jia-Ju Bai 
Fixes: a4ffb13c8946 ("dmaengine: Add STM32 MDMA driver")
Link: https://lore.kernel.org/r/20190729020849.17971-1-baijiaju1...@gmail.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
---
 drivers/dma/stm32-mdma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/stm32-mdma.c b/drivers/dma/stm32-mdma.c
index 06dd1725375e5..8c3c3e5b812a8 100644
--- a/drivers/dma/stm32-mdma.c
+++ b/drivers/dma/stm32-mdma.c
@@ -1376,7 +1376,7 @@ static irqreturn_t stm32_mdma_irq_handler(int irq, void 
*devid)
 
chan = &dmadev->chan[id];
if (!chan) {
-   dev_err(chan2dev(chan), "MDMA channel not initialized\n");
+   dev_dbg(mdma2dev(dmadev), "MDMA channel not initialized\n");
goto exit;
}
 
-- 
2.20.1



[PATCH AUTOSEL 5.2 43/44] tools: hv: fixed Python pep8/flake8 warnings for lsvmbus

2019-08-20 Thread Sasha Levin
From: Adrian Vladu 

[ Upstream commit 5912e791f3018de0a007c8cfa9cb38c97d3e5f5c ]

Fixed pep8/flake8 python style code for lsvmbus tool.

The TAB indentation was on purpose ignored (pep8 rule W191) to make
sure the code is complying with the Linux code guideline.
The following command doe not show any warnings now:
pep8 --ignore=W191 lsvmbus
flake8 --ignore=W191 lsvmbus

Signed-off-by: Adrian Vladu 

Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Sasha Levin 
Cc: Dexuan Cui 
Cc: Alessandro Pilotti 
Signed-off-by: Sasha Levin 
---
 tools/hv/lsvmbus | 75 +++-
 1 file changed, 42 insertions(+), 33 deletions(-)

diff --git a/tools/hv/lsvmbus b/tools/hv/lsvmbus
index 55e7374bade0d..099f2c44dbed2 100644
--- a/tools/hv/lsvmbus
+++ b/tools/hv/lsvmbus
@@ -4,10 +4,10 @@
 import os
 from optparse import OptionParser
 
+help_msg = "print verbose messages. Try -vv, -vvv for  more verbose messages"
 parser = OptionParser()
-parser.add_option("-v", "--verbose", dest="verbose",
-  help="print verbose messages. Try -vv, -vvv for \
-   more verbose messages", action="count")
+parser.add_option(
+   "-v", "--verbose", dest="verbose", help=help_msg, action="count")
 
 (options, args) = parser.parse_args()
 
@@ -21,27 +21,28 @@ if not os.path.isdir(vmbus_sys_path):
exit(-1)
 
 vmbus_dev_dict = {
-   '{0e0b6031-5213-4934-818b-38d90ced39db}' : '[Operating system 
shutdown]',
-   '{9527e630-d0ae-497b-adce-e80ab0175caf}' : '[Time Synchronization]',
-   '{57164f39-9115-4e78-ab55-382f3bd5422d}' : '[Heartbeat]',
-   '{a9a0f4e7-5a45-4d96-b827-8a841e8c03e6}' : '[Data Exchange]',
-   '{35fa2e29-ea23-4236-96ae-3a6ebacba440}' : '[Backup (volume 
checkpoint)]',
-   '{34d14be3-dee4-41c8-9ae7-6b174977c192}' : '[Guest services]',
-   '{525074dc-8985-46e2-8057-a307dc18a502}' : '[Dynamic Memory]',
-   '{cfa8b69e-5b4a-4cc0-b98b-8ba1a1f3f95a}' : 'Synthetic mouse',
-   '{f912ad6d-2b17-48ea-bd65-f927a61c7684}' : 'Synthetic keyboard',
-   '{da0a7802-e377-4aac-8e77-0558eb1073f8}' : 'Synthetic framebuffer 
adapter',
-   '{f8615163-df3e-46c5-913f-f2d2f965ed0e}' : 'Synthetic network adapter',
-   '{32412632-86cb-44a2-9b5c-50d1417354f5}' : 'Synthetic IDE Controller',
-   '{ba6163d9-04a1-4d29-b605-72e2ffb1dc7f}' : 'Synthetic SCSI Controller',
-   '{2f9bcc4a-0069-4af3-b76b-6fd0be528cda}' : 'Synthetic fiber channel 
adapter',
-   '{8c2eaf3d-32a7-4b09-ab99-bd1f1c86b501}' : 'Synthetic RDMA adapter',
-   '{44c4f61d--4400-9d52-802e27ede19f}' : 'PCI Express pass-through',
-   '{276aacf4-ac15-426c-98dd-7521ad3f01fe}' : '[Reserved system device]',
-   '{f8e65716-3cb3-4a06-9a60-1889c5cccab5}' : '[Reserved system device]',
-   '{3375baf4-9e15-4b30-b765-67acb10d607b}' : '[Reserved system device]',
+   '{0e0b6031-5213-4934-818b-38d90ced39db}': '[Operating system shutdown]',
+   '{9527e630-d0ae-497b-adce-e80ab0175caf}': '[Time Synchronization]',
+   '{57164f39-9115-4e78-ab55-382f3bd5422d}': '[Heartbeat]',
+   '{a9a0f4e7-5a45-4d96-b827-8a841e8c03e6}': '[Data Exchange]',
+   '{35fa2e29-ea23-4236-96ae-3a6ebacba440}': '[Backup (volume 
checkpoint)]',
+   '{34d14be3-dee4-41c8-9ae7-6b174977c192}': '[Guest services]',
+   '{525074dc-8985-46e2-8057-a307dc18a502}': '[Dynamic Memory]',
+   '{cfa8b69e-5b4a-4cc0-b98b-8ba1a1f3f95a}': 'Synthetic mouse',
+   '{f912ad6d-2b17-48ea-bd65-f927a61c7684}': 'Synthetic keyboard',
+   '{da0a7802-e377-4aac-8e77-0558eb1073f8}': 'Synthetic framebuffer 
adapter',
+   '{f8615163-df3e-46c5-913f-f2d2f965ed0e}': 'Synthetic network adapter',
+   '{32412632-86cb-44a2-9b5c-50d1417354f5}': 'Synthetic IDE Controller',
+   '{ba6163d9-04a1-4d29-b605-72e2ffb1dc7f}': 'Synthetic SCSI Controller',
+   '{2f9bcc4a-0069-4af3-b76b-6fd0be528cda}': 'Synthetic fiber channel 
adapter',
+   '{8c2eaf3d-32a7-4b09-ab99-bd1f1c86b501}': 'Synthetic RDMA adapter',
+   '{44c4f61d--4400-9d52-802e27ede19f}': 'PCI Express pass-through',
+   '{276aacf4-ac15-426c-98dd-7521ad3f01fe}': '[Reserved system device]',
+   '{f8e65716-3cb3-4a06-9a60-1889c5cccab5}': '[Reserved system device]',
+   '{3375baf4-9e15-4b30-b765-67acb10d607b}': '[Reserved system device]',
 }
 
+
 def get_vmbus_dev_attr(dev_name, attr):
try:
f = open('%s/%s/%s' % (vmbus_sys_path, dev_name, attr), 'r')
@@ -52,6 +53,7 @@ def get_vmbus_dev_attr(dev_name, attr):
 
return lines
 
+
 class VMBus_Dev:
pass
 
@@ -66,12 +68,13 @@ for f in os.listdir(vmbus_sys_path):
 
chn_vp_mapping = get_vmbus_dev_attr(f, 'channel_vp_mapping')
chn_vp_mapping = [c.strip() for c in chn_vp_mapping]
-   chn_vp_mapping = sorted(chn_vp_mapping,
-   key = lambda c : int(c.split(':')[0]))
+   chn_vp_mapping = sorted(
+   chn_vp_mapping, key=lambda c: int(c.split(':')[0]))
 
-   chn_vp_mapp

[PATCH AUTOSEL 4.19 01/27] dmaengine: ste_dma40: fix unneeded variable warning

2019-08-20 Thread Sasha Levin
From: Arnd Bergmann 

[ Upstream commit 5d6fb560729a5d5554e23db8d00eb57cd0021083 ]

clang-9 points out that there are two variables that depending on the
configuration may only be used in an ARRAY_SIZE() expression but not
referenced:

drivers/dma/ste_dma40.c:145:12: error: variable 'd40_backup_regs' is not needed 
and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static u32 d40_backup_regs[] = {
   ^
drivers/dma/ste_dma40.c:214:12: error: variable 'd40_backup_regs_chan' is not 
needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static u32 d40_backup_regs_chan[] = {

Mark these __maybe_unused to shut up the warning.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Nathan Chancellor 
Reviewed-by: Linus Walleij 
Link: https://lore.kernel.org/r/20190712091357.744515-1-a...@arndb.de
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
---
 drivers/dma/ste_dma40.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index f4edfc56f34ef..3d55405c49cac 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -142,7 +142,7 @@ enum d40_events {
  * when the DMA hw is powered off.
  * TODO: Add save/restore of D40_DREG_GCC on dma40 v3 or later, if that works.
  */
-static u32 d40_backup_regs[] = {
+static __maybe_unused u32 d40_backup_regs[] = {
D40_DREG_LCPA,
D40_DREG_LCLA,
D40_DREG_PRMSE,
@@ -211,7 +211,7 @@ static u32 d40_backup_regs_v4b[] = {
 
 #define BACKUP_REGS_SZ_V4B ARRAY_SIZE(d40_backup_regs_v4b)
 
-static u32 d40_backup_regs_chan[] = {
+static __maybe_unused u32 d40_backup_regs_chan[] = {
D40_CHAN_REG_SSCFG,
D40_CHAN_REG_SSELT,
D40_CHAN_REG_SSPTR,
-- 
2.20.1



[PATCH AUTOSEL 4.19 08/27] nvmet-loop: Flush nvme_delete_wq when removing the port

2019-08-20 Thread Sasha Levin
From: Logan Gunthorpe 

[ Upstream commit 86b9a63e595ff03f9d0a7b92b6acc231fecefc29 ]

After calling nvme_loop_delete_ctrl(), the controllers will not
yet be deleted because nvme_delete_ctrl() only schedules work
to do the delete.

This means a race can occur if a port is removed but there
are still active controllers trying to access that memory.

To fix this, flush the nvme_delete_wq before returning from
nvme_loop_remove_port() so that any controllers that might
be in the process of being deleted won't access a freed port.

Signed-off-by: Logan Gunthorpe 
Reviewed-by: Sagi Grimberg 
Reviewed-by: Max Gurtovoy 
Reviewed-by : Chaitanya Kulkarni 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Sasha Levin 
---
 drivers/nvme/target/loop.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/nvme/target/loop.c b/drivers/nvme/target/loop.c
index 9908082b32c4b..137a27fa369cb 100644
--- a/drivers/nvme/target/loop.c
+++ b/drivers/nvme/target/loop.c
@@ -678,6 +678,14 @@ static void nvme_loop_remove_port(struct nvmet_port *port)
mutex_lock(&nvme_loop_ports_mutex);
list_del_init(&port->entry);
mutex_unlock(&nvme_loop_ports_mutex);
+
+   /*
+* Ensure any ctrls that are in the process of being
+* deleted are in fact deleted before we return
+* and free the port. This is to prevent active
+* ctrls from using a port after it's freed.
+*/
+   flush_workqueue(nvme_delete_wq);
 }
 
 static const struct nvmet_fabrics_ops nvme_loop_ops = {
-- 
2.20.1



[PATCH AUTOSEL 4.19 12/27] soundwire: cadence_master: fix definitions for INTSTAT0/1

2019-08-20 Thread Sasha Levin
From: Pierre-Louis Bossart 

[ Upstream commit 664b16589f882202b8fa8149d0074f3159bade76 ]

Two off-by-one errors: INTSTAT0 missed BIT(31) and INTSTAT1 is only
defined on first 16 bits.

Signed-off-by: Pierre-Louis Bossart 
Link: 
https://lore.kernel.org/r/20190725234032.21152-15-pierre-louis.boss...@linux.intel.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
---
 drivers/soundwire/cadence_master.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/soundwire/cadence_master.c 
b/drivers/soundwire/cadence_master.c
index d3d7de5a319c5..70f78eda037e8 100644
--- a/drivers/soundwire/cadence_master.c
+++ b/drivers/soundwire/cadence_master.c
@@ -96,8 +96,8 @@
 #define CDNS_MCP_SLAVE_INTMASK00x5C
 #define CDNS_MCP_SLAVE_INTMASK10x60
 
-#define CDNS_MCP_SLAVE_INTMASK0_MASK   GENMASK(30, 0)
-#define CDNS_MCP_SLAVE_INTMASK1_MASK   GENMASK(16, 0)
+#define CDNS_MCP_SLAVE_INTMASK0_MASK   GENMASK(31, 0)
+#define CDNS_MCP_SLAVE_INTMASK1_MASK   GENMASK(15, 0)
 
 #define CDNS_MCP_PORT_INTSTAT  0x64
 #define CDNS_MCP_PDI_STAT  0x6C
-- 
2.20.1



[PATCH AUTOSEL 4.19 03/27] afs: Fix the CB.ProbeUuid service handler to reply correctly

2019-08-20 Thread Sasha Levin
From: David Howells 

[ Upstream commit 2067b2b3f4846402a040286135f98f46f8919939 ]

Fix the service handler function for the CB.ProbeUuid RPC call so that it
replies in the correct manner - that is an empty reply for success and an
abort of 1 for failure.

Putting 0 or 1 in an integer in the body of the reply should result in the
fileserver throwing an RX_PROTOCOL_ERROR abort and discarding its record of
the client; older servers, however, don't necessarily check that all the
data got consumed, and so might incorrectly think that they got a positive
response and associate the client with the wrong host record.

If the client is incorrectly associated, this will result in callbacks
intended for a different client being delivered to this one and then, when
the other client connects and responds positively, all of the callback
promises meant for the client that issued the improper response will be
lost and it won't receive any further change notifications.

Fixes: 9396d496d745 ("afs: support the CB.ProbeUuid RPC op")
Signed-off-by: David Howells 
Reviewed-by: Jeffrey Altman 
Signed-off-by: Sasha Levin 
---
 fs/afs/cmservice.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/fs/afs/cmservice.c b/fs/afs/cmservice.c
index 9e51d6fe7e8f9..40c6860d4c632 100644
--- a/fs/afs/cmservice.c
+++ b/fs/afs/cmservice.c
@@ -423,18 +423,14 @@ static void SRXAFSCB_ProbeUuid(struct work_struct *work)
struct afs_call *call = container_of(work, struct afs_call, work);
struct afs_uuid *r = call->request;
 
-   struct {
-   __be32  match;
-   } reply;
-
_enter("");
 
if (memcmp(r, &call->net->uuid, sizeof(call->net->uuid)) == 0)
-   reply.match = htonl(0);
+   afs_send_empty_reply(call);
else
-   reply.match = htonl(1);
+   rxrpc_kernel_abort_call(call->net->socket, call->rxcall,
+   1, 1, "K-1");
 
-   afs_send_simple_reply(call, &reply, sizeof(reply));
afs_put_call(call);
_leave("");
 }
-- 
2.20.1



Re: [PATCH] NFSv4: Fix a memory leak bug

2019-08-20 Thread Schumaker, Anna
Hi Wenwen,

On Tue, 2019-08-20 at 02:54 -0500, Wenwen Wang wrote:
> In nfs4_try_migration(), if nfs4_begin_drain_session() fails, the
> previously allocated 'page' and 'locations' are not deallocated,
> leading to
> memory leaks. To fix this issue, free 'page' and 'locations' before
> returning the error.
> 
> Signed-off-by: Wenwen Wang 
> ---
>  fs/nfs/nfs4state.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
> index cad4e06..37823dc 100644
> --- a/fs/nfs/nfs4state.c
> +++ b/fs/nfs/nfs4state.c
> @@ -2095,8 +2095,12 @@ static int nfs4_try_migration(struct
> nfs_server *server, const struct cred *cred
> }
> 
> status = nfs4_begin_drain_session(clp);
> -   if (status != 0)
> +   if (status != 0) {
> +   if (page != NULL)
> +   __free_page(page);
> +   kfree(locations);
> return status;

Thanks for the suggestion! I think a better option would be to switch
the "return status" into a "goto out" so we can keep all our cleanup
code in a single place in case we ever need to change it in the future.

What do you think?
Anna

> +   }
> 
> status = nfs4_replace_transport(server, locations);
> if (status != 0) {
> --
> 2.7.4
> 


[PATCH AUTOSEL 5.2 37/44] riscv: fix flush_tlb_range() end address for flush_tlb_page()

2019-08-20 Thread Sasha Levin
From: Paul Walmsley 

[ Upstream commit eb93685847a9055283d05951c1b205e737f38533 ]

The RISC-V kernel implementation of flush_tlb_page() when CONFIG_SMP
is set is wrong.  It passes zero to flush_tlb_range() as the final
address to flush, but it should be at least 'addr'.

Some other Linux architecture ports use the beginning address to
flush, plus PAGE_SIZE, as the final address to flush.  This might
flush slightly more than what's needed, but it seems unlikely that
being more clever would improve anything.  So let's just take that
implementation for now.

While here, convert the macro into a static inline function, primarily
to avoid unintentional multiple evaluations of 'addr'.

This second version of the patch fixes a coding style issue found by
Christoph Hellwig .

Reported-by: Andreas Schwab 
Signed-off-by: Paul Walmsley 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Sasha Levin 
---
 arch/riscv/include/asm/tlbflush.h | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/include/asm/tlbflush.h 
b/arch/riscv/include/asm/tlbflush.h
index 687dd19735a7e..4d9bbe8438bf6 100644
--- a/arch/riscv/include/asm/tlbflush.h
+++ b/arch/riscv/include/asm/tlbflush.h
@@ -53,10 +53,17 @@ static inline void remote_sfence_vma(struct cpumask *cmask, 
unsigned long start,
 }
 
 #define flush_tlb_all() sbi_remote_sfence_vma(NULL, 0, -1)
-#define flush_tlb_page(vma, addr) flush_tlb_range(vma, addr, 0)
+
 #define flush_tlb_range(vma, start, end) \
remote_sfence_vma(mm_cpumask((vma)->vm_mm), start, (end) - (start))
-#define flush_tlb_mm(mm) \
+
+static inline void flush_tlb_page(struct vm_area_struct *vma,
+ unsigned long addr)
+{
+   flush_tlb_range(vma, addr, addr + PAGE_SIZE);
+}
+
+#define flush_tlb_mm(mm)   \
remote_sfence_vma(mm_cpumask(mm), 0, -1)
 
 #endif /* CONFIG_SMP */
-- 
2.20.1



[PATCH] selftests: bpf: add config fragment BPF_JIT

2019-08-20 Thread Anders Roxell
When running test_kmod.sh the following shows up

 # sysctl cannot stat /proc/sys/net/core/bpf_jit_enable No such file or 
directory
 cannot: stat_/proc/sys/net/core/bpf_jit_enable #
 # sysctl cannot stat /proc/sys/net/core/bpf_jit_harden No such file or 
directory
 cannot: stat_/proc/sys/net/core/bpf_jit_harden #

Rework to enable CONFIG_BPF_JIT to solve "No such file or directory"

Signed-off-by: Anders Roxell 
---
 tools/testing/selftests/bpf/config | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/testing/selftests/bpf/config 
b/tools/testing/selftests/bpf/config
index f7a0744db31e..5dc109f4c097 100644
--- a/tools/testing/selftests/bpf/config
+++ b/tools/testing/selftests/bpf/config
@@ -34,3 +34,4 @@ CONFIG_NET_MPLS_GSO=m
 CONFIG_MPLS_ROUTING=m
 CONFIG_MPLS_IPTUNNEL=m
 CONFIG_IPV6_SIT=m
+CONFIG_BPF_JIT=y
-- 
2.20.1



[PATCH AUTOSEL 5.2 39/44] i2c: emev2: avoid race when unregistering slave client

2019-08-20 Thread Sasha Levin
From: Wolfram Sang 

[ Upstream commit d7437fc0d8291181debe032671a289b6bd93f46f ]

After we disabled interrupts, there might still be an active one
running. Sync before clearing the pointer to the slave device.

Fixes: c31d0a00021d ("i2c: emev2: add slave support")
Reported-by: Krzysztof Adamski 
Signed-off-by: Wolfram Sang 
Reviewed-by: Krzysztof Adamski 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
---
 drivers/i2c/busses/i2c-emev2.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-emev2.c b/drivers/i2c/busses/i2c-emev2.c
index 35b302d983e0d..959d4912ec0d5 100644
--- a/drivers/i2c/busses/i2c-emev2.c
+++ b/drivers/i2c/busses/i2c-emev2.c
@@ -69,6 +69,7 @@ struct em_i2c_device {
struct completion msg_done;
struct clk *sclk;
struct i2c_client *slave;
+   int irq;
 };
 
 static inline void em_clear_set_bit(struct em_i2c_device *priv, u8 clear, u8 
set, u8 reg)
@@ -339,6 +340,12 @@ static int em_i2c_unreg_slave(struct i2c_client *slave)
 
writeb(0, priv->base + I2C_OFS_SVA0);
 
+   /*
+* Wait for interrupt to finish. New slave irqs cannot happen because we
+* cleared the slave address and, thus, only extension codes will be
+* detected which do not use the slave ptr.
+*/
+   synchronize_irq(priv->irq);
priv->slave = NULL;
 
return 0;
@@ -355,7 +362,7 @@ static int em_i2c_probe(struct platform_device *pdev)
 {
struct em_i2c_device *priv;
struct resource *r;
-   int irq, ret;
+   int ret;
 
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -390,8 +397,8 @@ static int em_i2c_probe(struct platform_device *pdev)
 
em_i2c_reset(&priv->adap);
 
-   irq = platform_get_irq(pdev, 0);
-   ret = devm_request_irq(&pdev->dev, irq, em_i2c_irq_handler, 0,
+   priv->irq = platform_get_irq(pdev, 0);
+   ret = devm_request_irq(&pdev->dev, priv->irq, em_i2c_irq_handler, 0,
"em_i2c", priv);
if (ret)
goto err_clk;
@@ -401,7 +408,8 @@ static int em_i2c_probe(struct platform_device *pdev)
if (ret)
goto err_clk;
 
-   dev_info(&pdev->dev, "Added i2c controller %d, irq %d\n", 
priv->adap.nr, irq);
+   dev_info(&pdev->dev, "Added i2c controller %d, irq %d\n", priv->adap.nr,
+priv->irq);
 
return 0;
 
-- 
2.20.1



[PATCH AUTOSEL 5.2 41/44] drm/ast: Fixed reboot test may cause system hanged

2019-08-20 Thread Sasha Levin
From: "Y.C. Chen" 

[ Upstream commit 05b439711f6ff8700e8660f97a1179650778b9cb ]

There is another thread still access standard VGA I/O while loading drm driver.
Disable standard VGA I/O decode to avoid this issue.

Signed-off-by: Y.C. Chen 
Reviewed-by: Benjamin Herrenschmidt 
Signed-off-by: Dave Airlie 
Link: 
https://patchwork.freedesktop.org/patch/msgid/1523410059-18415-1-git-send-email-yc_c...@aspeedtech.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/ast/ast_main.c | 5 -
 drivers/gpu/drm/ast/ast_mode.c | 2 +-
 drivers/gpu/drm/ast/ast_post.c | 2 +-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 2854399856ba0..4aebe21e6ad9f 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -131,8 +131,8 @@ static int ast_detect_chip(struct drm_device *dev, bool 
*need_post)
 
 
/* Enable extended register access */
-   ast_enable_mmio(dev);
ast_open_key(ast);
+   ast_enable_mmio(dev);
 
/* Find out whether P2A works or whether to use device-tree */
ast_detect_config_mode(dev, &scu_rev);
@@ -576,6 +576,9 @@ void ast_driver_unload(struct drm_device *dev)
 {
struct ast_private *ast = dev->dev_private;
 
+   /* enable standard VGA decode */
+   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa1, 0x04);
+
ast_release_firmware(dev);
kfree(ast->dp501_fw_addr);
ast_mode_fini(dev);
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 97fed0627d1c8..74da15a3341a8 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -601,7 +601,7 @@ static int ast_crtc_mode_set(struct drm_crtc *crtc,
return -EINVAL;
ast_open_key(ast);
 
-   ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xa1, 0xff, 0x04);
+   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa1, 0x06);
 
ast_set_std_reg(crtc, adjusted_mode, &vbios_mode);
ast_set_crtc_reg(crtc, adjusted_mode, &vbios_mode);
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index f7d421359d564..c1d1ac51d1c20 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -46,7 +46,7 @@ void ast_enable_mmio(struct drm_device *dev)
 {
struct ast_private *ast = dev->dev_private;
 
-   ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xa1, 0xff, 0x04);
+   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa1, 0x06);
 }
 
 
-- 
2.20.1



[PATCH AUTOSEL 5.2 40/44] drm/scheduler: use job count instead of peek

2019-08-20 Thread Sasha Levin
From: Christian König 

[ Upstream commit e1b4ce25dbc93ab0cb8ed0f236a3b9ff7b03802c ]

The spsc_queue_peek function is accessing queue->head which belongs to
the consumer thread and shouldn't be accessed by the producer

This is fixing a rare race condition when destroying entities.

Signed-off-by: Christian König 
Acked-by: Andrey Grodzovsky 
Reviewed-by: monk@amd.com
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/scheduler/sched_entity.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_entity.c 
b/drivers/gpu/drm/scheduler/sched_entity.c
index 35ddbec1375ae..671c90f34ede6 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -95,7 +95,7 @@ static bool drm_sched_entity_is_idle(struct drm_sched_entity 
*entity)
rmb(); /* for list_empty to work without lock */
 
if (list_empty(&entity->list) ||
-   spsc_queue_peek(&entity->job_queue) == NULL)
+   spsc_queue_count(&entity->job_queue) == 0)
return true;
 
return false;
@@ -281,7 +281,7 @@ void drm_sched_entity_fini(struct drm_sched_entity *entity)
/* Consumption of existing IBs wasn't completed. Forcefully
 * remove them here.
 */
-   if (spsc_queue_peek(&entity->job_queue)) {
+   if (spsc_queue_count(&entity->job_queue)) {
if (sched) {
/* Park the kernel for a moment to make sure it isn't 
processing
 * our enity.
-- 
2.20.1



[PATCH AUTOSEL 5.2 34/44] habanalabs: fix device IRQ unmasking for BE host

2019-08-20 Thread Sasha Levin
From: Ben Segal 

[ Upstream commit b421d83a3947369fd5718824aecfaebe1efbf7ed ]

When unmasking IRQs inside the ASIC, the driver passes an array of all the
IRQ to unmask. The ASIC's CPU is working in LE so when running in a BE
host, the driver needs to do the proper endianness swapping when preparing
this array.

In addition, this patch also fixes the endianness of a couple of kernel log
debug messages that print values of packets

Signed-off-by: Ben Segal 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
Signed-off-by: Sasha Levin 
---
 drivers/misc/habanalabs/goya/goya.c | 33 +
 1 file changed, 24 insertions(+), 9 deletions(-)

diff --git a/drivers/misc/habanalabs/goya/goya.c 
b/drivers/misc/habanalabs/goya/goya.c
index 9216cc3599178..ac6b252a1ddcb 100644
--- a/drivers/misc/habanalabs/goya/goya.c
+++ b/drivers/misc/habanalabs/goya/goya.c
@@ -3311,9 +3311,11 @@ static int goya_validate_dma_pkt_no_mmu(struct hl_device 
*hdev,
int rc;
 
dev_dbg(hdev->dev, "DMA packet details:\n");
-   dev_dbg(hdev->dev, "source == 0x%llx\n", user_dma_pkt->src_addr);
-   dev_dbg(hdev->dev, "destination == 0x%llx\n", user_dma_pkt->dst_addr);
-   dev_dbg(hdev->dev, "size == %u\n", user_dma_pkt->tsize);
+   dev_dbg(hdev->dev, "source == 0x%llx\n",
+   le64_to_cpu(user_dma_pkt->src_addr));
+   dev_dbg(hdev->dev, "destination == 0x%llx\n",
+   le64_to_cpu(user_dma_pkt->dst_addr));
+   dev_dbg(hdev->dev, "size == %u\n", le32_to_cpu(user_dma_pkt->tsize));
 
ctl = le32_to_cpu(user_dma_pkt->ctl);
user_dir = (ctl & GOYA_PKT_LIN_DMA_CTL_DMA_DIR_MASK) >>
@@ -3342,9 +3344,11 @@ static int goya_validate_dma_pkt_mmu(struct hl_device 
*hdev,
struct packet_lin_dma *user_dma_pkt)
 {
dev_dbg(hdev->dev, "DMA packet details:\n");
-   dev_dbg(hdev->dev, "source == 0x%llx\n", user_dma_pkt->src_addr);
-   dev_dbg(hdev->dev, "destination == 0x%llx\n", user_dma_pkt->dst_addr);
-   dev_dbg(hdev->dev, "size == %u\n", user_dma_pkt->tsize);
+   dev_dbg(hdev->dev, "source == 0x%llx\n",
+   le64_to_cpu(user_dma_pkt->src_addr));
+   dev_dbg(hdev->dev, "destination == 0x%llx\n",
+   le64_to_cpu(user_dma_pkt->dst_addr));
+   dev_dbg(hdev->dev, "size == %u\n", le32_to_cpu(user_dma_pkt->tsize));
 
/*
 * WA for HW-23.
@@ -3384,7 +3388,8 @@ static int goya_validate_wreg32(struct hl_device *hdev,
 
dev_dbg(hdev->dev, "WREG32 packet details:\n");
dev_dbg(hdev->dev, "reg_offset == 0x%x\n", reg_offset);
-   dev_dbg(hdev->dev, "value  == 0x%x\n", wreg_pkt->value);
+   dev_dbg(hdev->dev, "value  == 0x%x\n",
+   le32_to_cpu(wreg_pkt->value));
 
if (reg_offset != (mmDMA_CH_0_WR_COMP_ADDR_LO & 0x1FFF)) {
dev_err(hdev->dev, "WREG32 packet with illegal address 0x%x\n",
@@ -4252,6 +4257,8 @@ static int goya_unmask_irq_arr(struct hl_device *hdev, 
u32 *irq_arr,
size_t total_pkt_size;
long result;
int rc;
+   int irq_num_entries, irq_arr_index;
+   __le32 *goya_irq_arr;
 
total_pkt_size = sizeof(struct armcp_unmask_irq_arr_packet) +
irq_arr_size;
@@ -4269,8 +4276,16 @@ static int goya_unmask_irq_arr(struct hl_device *hdev, 
u32 *irq_arr,
if (!pkt)
return -ENOMEM;
 
-   pkt->length = cpu_to_le32(irq_arr_size / sizeof(irq_arr[0]));
-   memcpy(&pkt->irqs, irq_arr, irq_arr_size);
+   irq_num_entries = irq_arr_size / sizeof(irq_arr[0]);
+   pkt->length = cpu_to_le32(irq_num_entries);
+
+   /* We must perform any necessary endianness conversation on the irq
+* array being passed to the goya hardware
+*/
+   for (irq_arr_index = 0, goya_irq_arr = (__le32 *) &pkt->irqs;
+   irq_arr_index < irq_num_entries ; irq_arr_index++)
+   goya_irq_arr[irq_arr_index] =
+   cpu_to_le32(irq_arr[irq_arr_index]);
 
pkt->armcp_pkt.ctl = cpu_to_le32(ARMCP_PACKET_UNMASK_RAZWI_IRQ_ARRAY <<
ARMCP_PKT_CTL_OPCODE_SHIFT);
-- 
2.20.1



[PATCH AUTOSEL 5.2 33/44] habanalabs: fix endianness handling for internal QMAN submission

2019-08-20 Thread Sasha Levin
From: Oded Gabbay 

[ Upstream commit b9040c99414ba5b85090595a61abc686a5dbb388 ]

The PQs of internal H/W queues (QMANs) can be located in different memory
areas for different ASICs. Therefore, when writing PQEs, we need to use
the correct function according to the location of the PQ. e.g. if the PQ
is located in the device's memory (SRAM or DRAM), we need to use
memcpy_toio() so it would work in architectures that have separate
address ranges for IO memory.

This patch makes the code that writes the PQE to be ASIC-specific so we
can handle this properly per ASIC.

Signed-off-by: Oded Gabbay 
Tested-by: Ben Segal 
Signed-off-by: Sasha Levin 
---
 drivers/misc/habanalabs/goya/goya.c  |  7 ---
 drivers/misc/habanalabs/goya/goyaP.h |  2 +-
 drivers/misc/habanalabs/habanalabs.h |  9 +++--
 drivers/misc/habanalabs/hw_queue.c   | 14 +-
 4 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/misc/habanalabs/goya/goya.c 
b/drivers/misc/habanalabs/goya/goya.c
index 0644fd7742057..9216cc3599178 100644
--- a/drivers/misc/habanalabs/goya/goya.c
+++ b/drivers/misc/habanalabs/goya/goya.c
@@ -2716,9 +2716,10 @@ void goya_ring_doorbell(struct hl_device *hdev, u32 
hw_queue_id, u32 pi)
GOYA_ASYNC_EVENT_ID_PI_UPDATE);
 }
 
-void goya_flush_pq_write(struct hl_device *hdev, u64 *pq, u64 exp_val)
+void goya_pqe_write(struct hl_device *hdev, __le64 *pqe, struct hl_bd *bd)
 {
-   /* Not needed in Goya */
+   /* The QMANs are on the SRAM so need to copy to IO space */
+   memcpy_toio((void __iomem *) pqe, bd, sizeof(struct hl_bd));
 }
 
 static void *goya_dma_alloc_coherent(struct hl_device *hdev, size_t size,
@@ -4784,7 +4785,7 @@ static const struct hl_asic_funcs goya_funcs = {
.resume = goya_resume,
.cb_mmap = goya_cb_mmap,
.ring_doorbell = goya_ring_doorbell,
-   .flush_pq_write = goya_flush_pq_write,
+   .pqe_write = goya_pqe_write,
.asic_dma_alloc_coherent = goya_dma_alloc_coherent,
.asic_dma_free_coherent = goya_dma_free_coherent,
.get_int_queue_base = goya_get_int_queue_base,
diff --git a/drivers/misc/habanalabs/goya/goyaP.h 
b/drivers/misc/habanalabs/goya/goyaP.h
index c83cab0d641e2..e2040fd331ca1 100644
--- a/drivers/misc/habanalabs/goya/goyaP.h
+++ b/drivers/misc/habanalabs/goya/goyaP.h
@@ -170,7 +170,7 @@ int goya_late_init(struct hl_device *hdev);
 void goya_late_fini(struct hl_device *hdev);
 
 void goya_ring_doorbell(struct hl_device *hdev, u32 hw_queue_id, u32 pi);
-void goya_flush_pq_write(struct hl_device *hdev, u64 *pq, u64 exp_val);
+void goya_pqe_write(struct hl_device *hdev, __le64 *pqe, struct hl_bd *bd);
 void goya_update_eq_ci(struct hl_device *hdev, u32 val);
 void goya_restore_phase_topology(struct hl_device *hdev);
 int goya_context_switch(struct hl_device *hdev, u32 asid);
diff --git a/drivers/misc/habanalabs/habanalabs.h 
b/drivers/misc/habanalabs/habanalabs.h
index adef7d9d7488a..d56ab65d5b2a4 100644
--- a/drivers/misc/habanalabs/habanalabs.h
+++ b/drivers/misc/habanalabs/habanalabs.h
@@ -449,7 +449,11 @@ enum hl_pll_frequency {
  * @resume: handles IP specific H/W or SW changes for resume.
  * @cb_mmap: maps a CB.
  * @ring_doorbell: increment PI on a given QMAN.
- * @flush_pq_write: flush PQ entry write if necessary, WARN if flushing failed.
+ * @pqe_write: Write the PQ entry to the PQ. This is ASIC-specific
+ * function because the PQs are located in different memory areas
+ * per ASIC (SRAM, DRAM, Host memory) and therefore, the method of
+ * writing the PQE must match the destination memory area
+ * properties.
  * @asic_dma_alloc_coherent: Allocate coherent DMA memory by calling
  *   dma_alloc_coherent(). This is ASIC function 
because
  *   its implementation is not trivial when the driver
@@ -518,7 +522,8 @@ struct hl_asic_funcs {
int (*cb_mmap)(struct hl_device *hdev, struct vm_area_struct *vma,
u64 kaddress, phys_addr_t paddress, u32 size);
void (*ring_doorbell)(struct hl_device *hdev, u32 hw_queue_id, u32 pi);
-   void (*flush_pq_write)(struct hl_device *hdev, u64 *pq, u64 exp_val);
+   void (*pqe_write)(struct hl_device *hdev, __le64 *pqe,
+   struct hl_bd *bd);
void* (*asic_dma_alloc_coherent)(struct hl_device *hdev, size_t size,
dma_addr_t *dma_handle, gfp_t flag);
void (*asic_dma_free_coherent)(struct hl_device *hdev, size_t size,
diff --git a/drivers/misc/habanalabs/hw_queue.c 
b/drivers/misc/habanalabs/hw_queue.c
index 2894d89759334..bb76794747279 100644
--- a/drivers/misc/habanalabs/hw_queue.c
+++ b/drivers/misc/habanalabs/hw_queue.c
@@ -290,23 +290,19 @@ static void int_hw_queue_schedule_job(struct hl_cs_job 
*job)
struct hl_device *hdev = job->cs->ctx->hdev;
struct hl_hw_queue *q = &hdev->kernel_queues[job->hw_q

[PATCH AUTOSEL 5.2 32/44] habanalabs: fix completion queue handling when host is BE

2019-08-20 Thread Sasha Levin
From: Ben Segal 

[ Upstream commit 4e87334a0ef43663019dbaf3638ad10fd8c3320c ]

This patch fix the CQ irq handler to work in hosts with BE architecture.
It adds the correct endian-swapping macros around the relevant memory
accesses.

Signed-off-by: Ben Segal 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
Signed-off-by: Sasha Levin 
---
 drivers/misc/habanalabs/irq.c | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/misc/habanalabs/irq.c b/drivers/misc/habanalabs/irq.c
index ea9f72ff456cf..199791b57caf2 100644
--- a/drivers/misc/habanalabs/irq.c
+++ b/drivers/misc/habanalabs/irq.c
@@ -80,8 +80,7 @@ irqreturn_t hl_irq_handler_cq(int irq, void *arg)
struct hl_cs_job *job;
bool shadow_index_valid;
u16 shadow_index;
-   u32 *cq_entry;
-   u32 *cq_base;
+   struct hl_cq_entry *cq_entry, *cq_base;
 
if (hdev->disabled) {
dev_dbg(hdev->dev,
@@ -90,29 +89,29 @@ irqreturn_t hl_irq_handler_cq(int irq, void *arg)
return IRQ_HANDLED;
}
 
-   cq_base = (u32 *) (uintptr_t) cq->kernel_address;
+   cq_base = (struct hl_cq_entry *) (uintptr_t) cq->kernel_address;
 
while (1) {
-   bool entry_ready = ((cq_base[cq->ci] & CQ_ENTRY_READY_MASK)
+   bool entry_ready = ((le32_to_cpu(cq_base[cq->ci].data) &
+   CQ_ENTRY_READY_MASK)
>> CQ_ENTRY_READY_SHIFT);
 
if (!entry_ready)
break;
 
-   cq_entry = (u32 *) &cq_base[cq->ci];
+   cq_entry = (struct hl_cq_entry *) &cq_base[cq->ci];
 
-   /*
-* Make sure we read CQ entry contents after we've
+   /* Make sure we read CQ entry contents after we've
 * checked the ownership bit.
 */
dma_rmb();
 
-   shadow_index_valid =
-   ((*cq_entry & CQ_ENTRY_SHADOW_INDEX_VALID_MASK)
+   shadow_index_valid = ((le32_to_cpu(cq_entry->data) &
+   CQ_ENTRY_SHADOW_INDEX_VALID_MASK)
>> CQ_ENTRY_SHADOW_INDEX_VALID_SHIFT);
 
-   shadow_index = (u16)
-   ((*cq_entry & CQ_ENTRY_SHADOW_INDEX_MASK)
+   shadow_index = (u16) ((le32_to_cpu(cq_entry->data) &
+   CQ_ENTRY_SHADOW_INDEX_MASK)
>> CQ_ENTRY_SHADOW_INDEX_SHIFT);
 
queue = &hdev->kernel_queues[cq->hw_queue_id];
@@ -122,8 +121,7 @@ irqreturn_t hl_irq_handler_cq(int irq, void *arg)
queue_work(hdev->cq_wq, &job->finish_work);
}
 
-   /*
-* Update ci of the context's queue. There is no
+   /* Update ci of the context's queue. There is no
 * need to protect it with spinlock because this update is
 * done only inside IRQ and there is a different IRQ per
 * queue
@@ -131,7 +129,8 @@ irqreturn_t hl_irq_handler_cq(int irq, void *arg)
queue->ci = hl_queue_inc_ptr(queue->ci);
 
/* Clear CQ entry ready bit */
-   cq_base[cq->ci] &= ~CQ_ENTRY_READY_MASK;
+   cq_entry->data = cpu_to_le32(le32_to_cpu(cq_entry->data) &
+   ~CQ_ENTRY_READY_MASK);
 
cq->ci = hl_cq_inc_ptr(cq->ci);
 
-- 
2.20.1



[PATCH] selftests: bpf: install files test_xdp_vlan.sh

2019-08-20 Thread Anders Roxell
When ./test_xdp_vlan_mode_generic.sh runs it complains that it can't
find file test_xdp_vlan.sh.

 # selftests: bpf: test_xdp_vlan_mode_generic.sh
 # ./test_xdp_vlan_mode_generic.sh: line 9: ./test_xdp_vlan.sh: No such
 file or directory

Rework so that test_xdp_vlan.sh gets installed, added to the variable
TEST_PROGS_EXTENDED.

Fixes: d35661fcf95d ("selftests/bpf: add wrapper scripts for test_xdp_vlan.sh")
Signed-off-by: Anders Roxell 
---
 tools/testing/selftests/bpf/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/bpf/Makefile 
b/tools/testing/selftests/bpf/Makefile
index 1faad0c3c3c9..d7968e20463c 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -68,7 +68,8 @@ TEST_PROGS := test_kmod.sh \
 TEST_PROGS_EXTENDED := with_addr.sh \
with_tunnels.sh \
tcp_client.py \
-   tcp_server.py
+   tcp_server.py \
+   test_xdp_vlan.sh
 
 # Compile but not part of 'make run_tests'
 TEST_GEN_PROGS_EXTENDED = test_libbpf_open test_sock_addr 
test_skb_cgroup_id_user \
-- 
2.20.1



[PATCH AUTOSEL 5.2 31/44] habanalabs: fix endianness handling for packets from user

2019-08-20 Thread Sasha Levin
From: Ben Segal 

[ Upstream commit 213ad5ad016a0da975b35f54e8cd236c3b04724b ]

Packets that arrive from the user and need to be parsed by the driver are
assumed to be in LE format.

This patch fix all the places where the code handles these packets and use
the correct endianness macros to handle them, as the driver handles the
packets in CPU format (LE or BE depending on the arch).

Signed-off-by: Ben Segal 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
Signed-off-by: Sasha Levin 
---
 drivers/misc/habanalabs/goya/goya.c   | 32 +++
 .../habanalabs/include/goya/goya_packets.h| 13 
 2 files changed, 32 insertions(+), 13 deletions(-)

diff --git a/drivers/misc/habanalabs/goya/goya.c 
b/drivers/misc/habanalabs/goya/goya.c
index 02d116b01a1a2..0644fd7742057 100644
--- a/drivers/misc/habanalabs/goya/goya.c
+++ b/drivers/misc/habanalabs/goya/goya.c
@@ -3425,12 +3425,13 @@ static int goya_validate_cb(struct hl_device *hdev,
while (cb_parsed_length < parser->user_cb_size) {
enum packet_id pkt_id;
u16 pkt_size;
-   void *user_pkt;
+   struct goya_packet *user_pkt;
 
-   user_pkt = (void *) (uintptr_t)
+   user_pkt = (struct goya_packet *) (uintptr_t)
(parser->user_cb->kernel_address + cb_parsed_length);
 
-   pkt_id = (enum packet_id) (((*(u64 *) user_pkt) &
+   pkt_id = (enum packet_id) (
+   (le64_to_cpu(user_pkt->header) &
PACKET_HEADER_PACKET_ID_MASK) >>
PACKET_HEADER_PACKET_ID_SHIFT);
 
@@ -3450,7 +3451,8 @@ static int goya_validate_cb(struct hl_device *hdev,
 * need to validate here as well because patch_cb() is
 * not called in MMU path while this function is called
 */
-   rc = goya_validate_wreg32(hdev, parser, user_pkt);
+   rc = goya_validate_wreg32(hdev,
+   parser, (struct packet_wreg32 *) user_pkt);
break;
 
case PACKET_WREG_BULK:
@@ -3478,10 +3480,10 @@ static int goya_validate_cb(struct hl_device *hdev,
case PACKET_LIN_DMA:
if (is_mmu)
rc = goya_validate_dma_pkt_mmu(hdev, parser,
-   user_pkt);
+   (struct packet_lin_dma *) user_pkt);
else
rc = goya_validate_dma_pkt_no_mmu(hdev, parser,
-   user_pkt);
+   (struct packet_lin_dma *) user_pkt);
break;
 
case PACKET_MSG_LONG:
@@ -3654,15 +3656,16 @@ static int goya_patch_cb(struct hl_device *hdev,
enum packet_id pkt_id;
u16 pkt_size;
u32 new_pkt_size = 0;
-   void *user_pkt, *kernel_pkt;
+   struct goya_packet *user_pkt, *kernel_pkt;
 
-   user_pkt = (void *) (uintptr_t)
+   user_pkt = (struct goya_packet *) (uintptr_t)
(parser->user_cb->kernel_address + cb_parsed_length);
-   kernel_pkt = (void *) (uintptr_t)
+   kernel_pkt = (struct goya_packet *) (uintptr_t)
(parser->patched_cb->kernel_address +
cb_patched_cur_length);
 
-   pkt_id = (enum packet_id) (((*(u64 *) user_pkt) &
+   pkt_id = (enum packet_id) (
+   (le64_to_cpu(user_pkt->header) &
PACKET_HEADER_PACKET_ID_MASK) >>
PACKET_HEADER_PACKET_ID_SHIFT);
 
@@ -3677,15 +3680,18 @@ static int goya_patch_cb(struct hl_device *hdev,
 
switch (pkt_id) {
case PACKET_LIN_DMA:
-   rc = goya_patch_dma_packet(hdev, parser, user_pkt,
-   kernel_pkt, &new_pkt_size);
+   rc = goya_patch_dma_packet(hdev, parser,
+   (struct packet_lin_dma *) user_pkt,
+   (struct packet_lin_dma *) kernel_pkt,
+   &new_pkt_size);
cb_patched_cur_length += new_pkt_size;
break;
 
case PACKET_WREG_32:
memcpy(kernel_pkt, user_pkt, pkt_size);
cb_patched_cur_length += pkt_size;
-   rc = goya_validate_wreg32(hdev, parser, kernel_pkt);
+   rc = goya_validate_wreg32(hdev, parser,
+   (struct packet_wreg32 *) kernel_pkt);
  

[PATCH AUTOSEL 5.2 30/44] habanalabs: fix DRAM usage accounting on context tear down

2019-08-20 Thread Sasha Levin
From: Tomer Tayar 

[ Upstream commit c8113756ba27298d6e95403c087dc5881b419a99 ]

The patch fix the DRAM usage accounting by adding a missing update of
the DRAM memory consumption, when a context is being torn down without an
organized release of the allocated memory.

Signed-off-by: Tomer Tayar 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
Signed-off-by: Sasha Levin 
---
 drivers/misc/habanalabs/memory.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/misc/habanalabs/memory.c b/drivers/misc/habanalabs/memory.c
index 693877e37fd87..924a438ba9736 100644
--- a/drivers/misc/habanalabs/memory.c
+++ b/drivers/misc/habanalabs/memory.c
@@ -1629,6 +1629,8 @@ void hl_vm_ctx_fini(struct hl_ctx *ctx)
dev_dbg(hdev->dev,
"page list 0x%p of asid %d is still alive\n",
phys_pg_list, ctx->asid);
+   atomic64_sub(phys_pg_list->total_size,
+   &hdev->dram_used_mem);
free_phys_pg_pack(hdev, phys_pg_list);
idr_remove(&vm->phys_pg_pack_handles, i);
}
-- 
2.20.1



[PATCH AUTOSEL 5.2 29/44] usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt

2019-08-20 Thread Sasha Levin
From: Benjamin Herrenschmidt 

[ Upstream commit 4a56a478a525d6427be90753451c40e1327caa1a ]

If fsg_disable() and fsg_set_alt() are called too closely to each
other (for example due to a quick reset/reconnect), what can happen
is that fsg_set_alt sets common->new_fsg from an interrupt while
handle_exception is trying to process the config change caused by
fsg_disable():

fsg_disable()
...
handle_exception()
sets state back to FSG_STATE_NORMAL
hasn't yet called do_set_interface()
or is inside it.

 ---> interrupt
fsg_set_alt
sets common->new_fsg
queues a new FSG_STATE_CONFIG_CHANGE
 <---

Now, the first handle_exception can "see" the updated
new_fsg, treats it as if it was a fsg_set_alt() response,
call usb_composite_setup_continue() etc...

But then, the thread sees the second FSG_STATE_CONFIG_CHANGE,
and goes back down the same path, wipes and reattaches a now
active fsg, and .. calls usb_composite_setup_continue() which
at this point is wrong.

Not only we get a backtrace, but I suspect the second set_interface
wrecks some state causing the host to get upset in my case.

This fixes it by replacing "new_fsg" by a "state argument" (same
principle) which is set in the same lock section as the state
update, and retrieved similarly.

That way, there is never any discrepancy between the dequeued
state and the observed value of it. We keep the ability to have
the latest reconfig operation take precedence, but we guarantee
that once "dequeued" the argument (new_fsg) will not be clobbered
by any new event.

Signed-off-by: Benjamin Herrenschmidt 
Acked-by: Alan Stern 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
---
 drivers/usb/gadget/function/f_mass_storage.c | 28 +---
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/gadget/function/f_mass_storage.c 
b/drivers/usb/gadget/function/f_mass_storage.c
index 043f97ad8f226..f2bc8d0370676 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -261,7 +261,7 @@ struct fsg_common;
 struct fsg_common {
struct usb_gadget   *gadget;
struct usb_composite_dev *cdev;
-   struct fsg_dev  *fsg, *new_fsg;
+   struct fsg_dev  *fsg;
wait_queue_head_t   io_wait;
wait_queue_head_t   fsg_wait;
 
@@ -290,6 +290,7 @@ struct fsg_common {
unsigned intbulk_out_maxpacket;
enum fsg_state  state;  /* For exception handling */
unsigned intexception_req_tag;
+   void*exception_arg;
 
enum data_direction data_dir;
u32 data_size;
@@ -391,7 +392,8 @@ static int fsg_set_halt(struct fsg_dev *fsg, struct usb_ep 
*ep)
 
 /* These routines may be called in process context or in_irq */
 
-static void raise_exception(struct fsg_common *common, enum fsg_state 
new_state)
+static void __raise_exception(struct fsg_common *common, enum fsg_state 
new_state,
+ void *arg)
 {
unsigned long   flags;
 
@@ -404,6 +406,7 @@ static void raise_exception(struct fsg_common *common, enum 
fsg_state new_state)
if (common->state <= new_state) {
common->exception_req_tag = common->ep0_req_tag;
common->state = new_state;
+   common->exception_arg = arg;
if (common->thread_task)
send_sig_info(SIGUSR1, SEND_SIG_PRIV,
  common->thread_task);
@@ -411,6 +414,10 @@ static void raise_exception(struct fsg_common *common, 
enum fsg_state new_state)
spin_unlock_irqrestore(&common->lock, flags);
 }
 
+static void raise_exception(struct fsg_common *common, enum fsg_state 
new_state)
+{
+   __raise_exception(common, new_state, NULL);
+}
 
 /*-*/
 
@@ -2285,16 +2292,16 @@ static int do_set_interface(struct fsg_common *common, 
struct fsg_dev *new_fsg)
 static int fsg_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
 {
struct fsg_dev *fsg = fsg_from_func(f);
-   fsg->common->new_fsg = fsg;
-   raise_exception(fsg->common, FSG_STATE_CONFIG_CHANGE);
+
+   __raise_exception(fsg->common, FSG_STATE_CONFIG_CHANGE, fsg);
return USB_GADGET_DELAYED_STATUS;
 }
 
 static void fsg_disable(struct usb_function *f)
 {
struct fsg_dev *fsg = fsg_from_func(f);
-   fsg->common->new_fsg = NULL;
-   raise_exception(fsg->common, FSG_STATE_CONFIG_CHANGE);
+
+   __raise_exception(fsg->common, FSG_STATE_CONFIG_CHANGE, NULL);
 }
 
 
@@ -2307,6 +2314,7 @@ static void handle_exception(struct fsg_common *common)
enum fsg_state  old_state;
struct fsg_lun  *curlun;
unsigned intexception_req_tag;
+

[PATCH AUTOSEL 5.2 23/44] IB/mlx5: Fix implicit MR release flow

2019-08-20 Thread Sasha Levin
From: Yishai Hadas 

[ Upstream commit f591822c3cf314442819486f45ff7dc1f690e0c0 ]

Once implicit MR is being called to be released by
ib_umem_notifier_release() its leaves were marked as "dying".

However, when dereg_mr()->mlx5_ib_free_implicit_mr()->mr_leaf_free() is
called, it skips running the mr_leaf_free_action (i.e. umem_odp->work)
when those leaves were marked as "dying".

As such ib_umem_release() for the leaves won't be called and their MRs
will be leaked as well.

When an application exits/killed without calling dereg_mr we might hit the
above flow.

This fatal scenario is reported by WARN_ON() upon
mlx5_ib_dealloc_ucontext() as ibcontext->per_mm_list is not empty, the
call trace can be seen below.

Originally the "dying" mark as part of ib_umem_notifier_release() was
introduced to prevent pagefault_mr() from returning a success response
once this happened. However, we already have today the completion
mechanism so no need for that in those flows any more.  Even in case a
success response will be returned the firmware will not find the pages and
an error will be returned in the following call as a released mm will
cause ib_umem_odp_map_dma_pages() to permanently fail mmget_not_zero().

Fix the above issue by dropping the "dying" from the above flows.  The
other flows that are using "dying" are still needed it for their
synchronization purposes.

   WARNING: CPU: 1 PID: 7218 at
   drivers/infiniband/hw/mlx5/main.c:2004
  mlx5_ib_dealloc_ucontext+0x84/0x90 [mlx5_ib]
   CPU: 1 PID: 7218 Comm: ibv_rc_pingpong Tainted: G E
   5.2.0-rc6+ #13
   Call Trace:
   uverbs_destroy_ufile_hw+0xb5/0x120 [ib_uverbs]
   ib_uverbs_close+0x1f/0x80 [ib_uverbs]
   __fput+0xbe/0x250
   task_work_run+0x88/0xa0
   do_exit+0x2cb/0xc30
   ? __fput+0x14b/0x250
   do_group_exit+0x39/0xb0
   get_signal+0x191/0x920
   ? _raw_spin_unlock_bh+0xa/0x20
   ? inet_csk_accept+0x229/0x2f0
   do_signal+0x36/0x5e0
   ? put_unused_fd+0x5b/0x70
   ? __sys_accept4+0x1a6/0x1e0
   ? inet_hash+0x35/0x40
   ? release_sock+0x43/0x90
   ? _raw_spin_unlock_bh+0xa/0x20
   ? inet_listen+0x9f/0x120
   exit_to_usermode_loop+0x5c/0xc6
   do_syscall_64+0x182/0x1b0
   entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: 81713d3788d2 ("IB/mlx5: Add implicit MR support")
Link: https://lore.kernel.org/r/20190805083010.21777-1-l...@kernel.org
Signed-off-by: Yishai Hadas 
Reviewed-by: Artemy Kovalyov 
Signed-off-by: Leon Romanovsky 
Reviewed-by: Jason Gunthorpe 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/core/umem_odp.c |  4 
 drivers/infiniband/hw/mlx5/odp.c   | 24 +---
 2 files changed, 9 insertions(+), 19 deletions(-)

diff --git a/drivers/infiniband/core/umem_odp.c 
b/drivers/infiniband/core/umem_odp.c
index e4b13a32692a9..5e5f7dd82c50d 100644
--- a/drivers/infiniband/core/umem_odp.c
+++ b/drivers/infiniband/core/umem_odp.c
@@ -114,10 +114,6 @@ static int ib_umem_notifier_release_trampoline(struct 
ib_umem_odp *umem_odp,
 * prevent any further fault handling on this MR.
 */
ib_umem_notifier_start_account(umem_odp);
-   umem_odp->dying = 1;
-   /* Make sure that the fact the umem is dying is out before we release
-* all pending page faults. */
-   smp_wmb();
complete_all(&umem_odp->notifier_completion);
umem->context->invalidate_range(umem_odp, ib_umem_start(umem),
ib_umem_end(umem));
diff --git a/drivers/infiniband/hw/mlx5/odp.c b/drivers/infiniband/hw/mlx5/odp.c
index 91507a2e92900..d711f3e31fa74 100644
--- a/drivers/infiniband/hw/mlx5/odp.c
+++ b/drivers/infiniband/hw/mlx5/odp.c
@@ -581,7 +581,6 @@ static int pagefault_mr(struct mlx5_ib_dev *dev, struct 
mlx5_ib_mr *mr,
u32 flags)
 {
int npages = 0, current_seq, page_shift, ret, np;
-   bool implicit = false;
struct ib_umem_odp *odp_mr = to_ib_umem_odp(mr->umem);
bool downgrade = flags & MLX5_PF_FLAGS_DOWNGRADE;
bool prefetch = flags & MLX5_PF_FLAGS_PREFETCH;
@@ -596,7 +595,6 @@ static int pagefault_mr(struct mlx5_ib_dev *dev, struct 
mlx5_ib_mr *mr,
if (IS_ERR(odp))
return PTR_ERR(odp);
mr = odp->private;
-   implicit = true;
} else {
odp = odp_mr;
}
@@ -684,19 +682,15 @@ static int pagefault_mr(struct mlx5_ib_dev *dev, struct 
mlx5_ib_mr *mr,
 
 out:
if (ret == -EAGAIN) {
-   if (implicit || !odp->dying) {
-   unsigned long timeout =
-   msecs_to_jiffies(MMU_NOTIFIER_TIMEOUT);
-
-   if (!wait_for_completion_timeout(
-   &odp->notifier_completion,
-   timeout)) {
-   mlx5_ib_warn(dev, "timeout waiting for mmu 
notifier. seq %d against %d. notifiers_count=%d\n",
-

[PATCH AUTOSEL 5.2 22/44] btrfs: trim: Check the range passed into to prevent overflow

2019-08-20 Thread Sasha Levin
From: Qu Wenruo 

[ Upstream commit 07301df7d2fc220d3de5f7ad804dcb941400cb00 ]

Normally the range->len is set to default value (U64_MAX), but when it's
not default value, we should check if the range overflows.

And if it overflows, return -EINVAL before doing anything.

Reviewed-by: Nikolay Borisov 
Reviewed-by: Anand Jain 
Signed-off-by: Qu Wenruo 
Signed-off-by: David Sterba 
Signed-off-by: Sasha Levin 
---
 fs/btrfs/extent-tree.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 5faf057f6f37f..b8f4720879021 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -11226,6 +11226,7 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info, struct 
fstrim_range *range)
struct btrfs_device *device;
struct list_head *devices;
u64 group_trimmed;
+   u64 range_end = U64_MAX;
u64 start;
u64 end;
u64 trimmed = 0;
@@ -11235,16 +11236,23 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info, 
struct fstrim_range *range)
int dev_ret = 0;
int ret = 0;
 
+   /*
+* Check range overflow if range->len is set.
+* The default range->len is U64_MAX.
+*/
+   if (range->len != U64_MAX &&
+   check_add_overflow(range->start, range->len, &range_end))
+   return -EINVAL;
+
cache = btrfs_lookup_first_block_group(fs_info, range->start);
for (; cache; cache = next_block_group(cache)) {
-   if (cache->key.objectid >= (range->start + range->len)) {
+   if (cache->key.objectid >= range_end) {
btrfs_put_block_group(cache);
break;
}
 
start = max(range->start, cache->key.objectid);
-   end = min(range->start + range->len,
-   cache->key.objectid + cache->key.offset);
+   end = min(range_end, cache->key.objectid + cache->key.offset);
 
if (end - start >= range->minlen) {
if (!block_group_cache_done(cache)) {
-- 
2.20.1



[PATCH AUTOSEL 5.2 25/44] omap-dma/omap_vout_vrfb: fix off-by-one fi value

2019-08-20 Thread Sasha Levin
From: Hans Verkuil 

[ Upstream commit d555c34338cae844b207564c482e5a3fb089d25e ]

The OMAP 4 TRM specifies that when using double-index addressing
the address increases by the ES plus the EI value minus 1 within
a frame. When a full frame is transferred, the address increases
by the ES plus the frame index (FI) value minus 1.

The omap-dma code didn't account for the 'minus 1' in the FI register.
To get correct addressing, add 1 to the src_icg value.

This was found when testing a hacked version of the media m2m-deinterlace.c
driver on a Pandaboard.

The only other source that uses this feature is omap_vout_vrfb.c,
and that adds a + 1 when setting the dst_icg. This is a workaround
for the broken omap-dma.c behavior. So remove the workaround at the
same time that we fix omap-dma.c.

I tested the omap_vout driver with a Beagle XM board to check that
the '+ 1' in omap_vout_vrfb.c was indeed a workaround for the omap-dma
bug.

Signed-off-by: Hans Verkuil 
Reviewed-by: Laurent Pinchart 
Acked-by: Peter Ujfalusi 
Acked-by: Mauro Carvalho Chehab 
Link: https://lore.kernel.org/r/952e7f51-f208-9333-6f58-b7ed20d2e...@xs4all.nl
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
---
 drivers/dma/ti/omap-dma.c| 4 ++--
 drivers/media/platform/omap/omap_vout_vrfb.c | 3 +--
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/ti/omap-dma.c b/drivers/dma/ti/omap-dma.c
index ba2489d4ea246..ba27802efcd0a 100644
--- a/drivers/dma/ti/omap-dma.c
+++ b/drivers/dma/ti/omap-dma.c
@@ -1234,7 +1234,7 @@ static struct dma_async_tx_descriptor 
*omap_dma_prep_dma_interleaved(
if (src_icg) {
d->ccr |= CCR_SRC_AMODE_DBLIDX;
d->ei = 1;
-   d->fi = src_icg;
+   d->fi = src_icg + 1;
} else if (xt->src_inc) {
d->ccr |= CCR_SRC_AMODE_POSTINC;
d->fi = 0;
@@ -1249,7 +1249,7 @@ static struct dma_async_tx_descriptor 
*omap_dma_prep_dma_interleaved(
if (dst_icg) {
d->ccr |= CCR_DST_AMODE_DBLIDX;
sg->ei = 1;
-   sg->fi = dst_icg;
+   sg->fi = dst_icg + 1;
} else if (xt->dst_inc) {
d->ccr |= CCR_DST_AMODE_POSTINC;
sg->fi = 0;
diff --git a/drivers/media/platform/omap/omap_vout_vrfb.c 
b/drivers/media/platform/omap/omap_vout_vrfb.c
index 29e3f5da59c1f..11ec048929e80 100644
--- a/drivers/media/platform/omap/omap_vout_vrfb.c
+++ b/drivers/media/platform/omap/omap_vout_vrfb.c
@@ -253,8 +253,7 @@ int omap_vout_prepare_vrfb(struct omap_vout_device *vout,
 */
 
pixsize = vout->bpp * vout->vrfb_bpp;
-   dst_icg = ((MAX_PIXELS_PER_LINE * pixsize) -
- (vout->pix.width * vout->bpp)) + 1;
+   dst_icg = MAX_PIXELS_PER_LINE * pixsize - vout->pix.width * vout->bpp;
 
xt->src_start = vout->buf_phy_addr[vb->i];
xt->dst_start = vout->vrfb_context[vb->i].paddr[0];
-- 
2.20.1



[PATCH] selftests: net: add missing NFT_FWD_NETDEV to config

2019-08-20 Thread Anders Roxell
When running xfrm_policy.sh we see the following

 # sysctl cannot stat /proc/sys/net/ipv4/conf/eth1/forwarding No such file or 
directory
 cannot: stat_/proc/sys/net/ipv4/conf/eth1/forwarding #
 # sysctl cannot stat /proc/sys/net/ipv4/conf/veth0/forwarding No such file or 
directory
 cannot: stat_/proc/sys/net/ipv4/conf/veth0/forwarding #
 # sysctl cannot stat /proc/sys/net/ipv4/conf/eth1/forwarding No such file or 
directory
 cannot: stat_/proc/sys/net/ipv4/conf/eth1/forwarding #
 # sysctl cannot stat /proc/sys/net/ipv4/conf/veth0/forwarding No such file or 
directory
 cannot: stat_/proc/sys/net/ipv4/conf/veth0/forwarding #
 # sysctl cannot stat /proc/sys/net/ipv6/conf/eth1/forwarding No such file or 
directory
 cannot: stat_/proc/sys/net/ipv6/conf/eth1/forwarding #
 # sysctl cannot stat /proc/sys/net/ipv6/conf/veth0/forwarding No such file or 
directory
 cannot: stat_/proc/sys/net/ipv6/conf/veth0/forwarding #
 # sysctl cannot stat /proc/sys/net/ipv6/conf/eth1/forwarding No such file or 
directory
 cannot: stat_/proc/sys/net/ipv6/conf/eth1/forwarding #
 # sysctl cannot stat /proc/sys/net/ipv6/conf/veth0/forwarding No such file or 
directory
 cannot: stat_/proc/sys/net/ipv6/conf/veth0/forwarding #
 # modprobe FATAL Module ip_tables not found in directory 
/lib/modules/5.3.0-rc5-next-20190820+
 FATAL: Module_ip_tables #
 # iptables v1.6.2 can't initialize iptables table `filter' Table does not 
exist (do you need to insmod?)
 v1.6.2: can't_initialize #

Rework to enable CONFIG_NF_TABLES_NETDEV and CONFIG_NFT_FWD_NETDEV.

Signed-off-by: Anders Roxell 
---
 tools/testing/selftests/net/config | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/testing/selftests/net/config 
b/tools/testing/selftests/net/config
index b8503a8119b0..e30b0ae5d474 100644
--- a/tools/testing/selftests/net/config
+++ b/tools/testing/selftests/net/config
@@ -29,3 +29,5 @@ CONFIG_NET_SCH_FQ=m
 CONFIG_NET_SCH_ETF=m
 CONFIG_TEST_BLACKHOLE_DEV=m
 CONFIG_KALLSYMS=y
+CONFIG_NF_TABLES_NETDEV=y
+CONFIG_NFT_FWD_NETDEV=m
-- 
2.20.1



[PATCH AUTOSEL 5.2 24/44] dmaengine: stm32-mdma: Fix a possible null-pointer dereference in stm32_mdma_irq_handler()

2019-08-20 Thread Sasha Levin
From: Jia-Ju Bai 

[ Upstream commit 39c71a5b8212f4b502d9a630c6706ac723abd422 ]

In stm32_mdma_irq_handler(), chan is checked on line 1368.
When chan is NULL, it is still used on line 1369:
dev_err(chan2dev(chan), "MDMA channel not initialized\n");

Thus, a possible null-pointer dereference may occur.

To fix this bug, "dev_dbg(mdma2dev(dmadev), ...)" is used instead.

Signed-off-by: Jia-Ju Bai 
Fixes: a4ffb13c8946 ("dmaengine: Add STM32 MDMA driver")
Link: https://lore.kernel.org/r/20190729020849.17971-1-baijiaju1...@gmail.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
---
 drivers/dma/stm32-mdma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/stm32-mdma.c b/drivers/dma/stm32-mdma.c
index d6e919d3936a2..1311de74bfdde 100644
--- a/drivers/dma/stm32-mdma.c
+++ b/drivers/dma/stm32-mdma.c
@@ -1366,7 +1366,7 @@ static irqreturn_t stm32_mdma_irq_handler(int irq, void 
*devid)
 
chan = &dmadev->chan[id];
if (!chan) {
-   dev_err(chan2dev(chan), "MDMA channel not initialized\n");
+   dev_dbg(mdma2dev(dmadev), "MDMA channel not initialized\n");
goto exit;
}
 
-- 
2.20.1



[PATCH AUTOSEL 5.2 13/44] nvme-core: Fix extra device_put() call on error path

2019-08-20 Thread Sasha Levin
From: Logan Gunthorpe 

[ Upstream commit 8c36e66fb407ce076535a7db98ab9f6d720b866a ]

In the error path for nvme_init_subsystem(), nvme_put_subsystem()
will call device_put(), but it will get called again after the
mutex_unlock().

The device_put() only needs to be called if device_add() fails.

This bug caused a KASAN use-after-free error when adding and
removing subsytems in a loop:

  BUG: KASAN: use-after-free in device_del+0x8d9/0x9a0
  Read of size 8 at addr 8883cdaf7120 by task multipathd/329

  CPU: 0 PID: 329 Comm: multipathd Not tainted 
5.2.0-rc6-vmlocalyes-00019-g70a2b39005fd-dirty #314
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 
04/01/2014
  Call Trace:
   dump_stack+0x7b/0xb5
   print_address_description+0x6f/0x280
   ? device_del+0x8d9/0x9a0
   __kasan_report+0x148/0x199
   ? device_del+0x8d9/0x9a0
   ? class_release+0x100/0x130
   ? device_del+0x8d9/0x9a0
   kasan_report+0x12/0x20
   __asan_report_load8_noabort+0x14/0x20
   device_del+0x8d9/0x9a0
   ? device_platform_notify+0x70/0x70
   nvme_destroy_subsystem+0xf9/0x150
   nvme_free_ctrl+0x280/0x3a0
   device_release+0x72/0x1d0
   kobject_put+0x144/0x410
   put_device+0x13/0x20
   nvme_free_ns+0xc4/0x100
   nvme_release+0xb3/0xe0
   __blkdev_put+0x549/0x6e0
   ? kasan_check_write+0x14/0x20
   ? bd_set_size+0xb0/0xb0
   ? kasan_check_write+0x14/0x20
   ? mutex_lock+0x8f/0xe0
   ? __mutex_lock_slowpath+0x20/0x20
   ? locks_remove_file+0x239/0x370
   blkdev_put+0x72/0x2c0
   blkdev_close+0x8d/0xd0
   __fput+0x256/0x770
   ? _raw_read_lock_irq+0x40/0x40
   fput+0xe/0x10
   task_work_run+0x10c/0x180
   ? filp_close+0xf7/0x140
   exit_to_usermode_loop+0x151/0x170
   do_syscall_64+0x240/0x2e0
   ? prepare_exit_to_usermode+0xd5/0x190
   entry_SYSCALL_64_after_hwframe+0x44/0xa9
  RIP: 0033:0x7f5a79af05d7
  Code: 00 00 0f 05 48 3d 00 f0 ff ff 77 3f c3 66 0f 1f 44 00 00 53 89 fb 48 83 
ec 10 e8 c4 fb ff ff 89 df 89 c2 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 2b 
89 d7 89 44 24 0c e8 06 fc ff ff 8b 44 24
  RSP: 002b:7f5a7799c810 EFLAGS: 0293 ORIG_RAX: 0003
  RAX:  RBX: 0008 RCX: 7f5a79af05d7
  RDX:  RSI: 0001 RDI: 0008
  RBP: 7f5a58000f98 R08: 0002 R09: 7f5a7935ee80
  R10:  R11: 0293 R12: 55e432447240
  R13:  R14: 0001 R15: 55e4324a9cf0

  Allocated by task 1236:
   save_stack+0x21/0x80
   __kasan_kmalloc.constprop.6+0xab/0xe0
   kasan_kmalloc+0x9/0x10
   kmem_cache_alloc_trace+0x102/0x210
   nvme_init_identify+0x13c3/0x3820
   nvme_loop_configure_admin_queue+0x4fa/0x5e0
   nvme_loop_create_ctrl+0x469/0xf40
   nvmf_dev_write+0x19a3/0x21ab
   __vfs_write+0x66/0x120
   vfs_write+0x154/0x490
   ksys_write+0x104/0x240
   __x64_sys_write+0x73/0xb0
   do_syscall_64+0xa5/0x2e0
   entry_SYSCALL_64_after_hwframe+0x44/0xa9

  Freed by task 329:
   save_stack+0x21/0x80
   __kasan_slab_free+0x129/0x190
   kasan_slab_free+0xe/0x10
   kfree+0xa7/0x200
   nvme_release_subsystem+0x49/0x60
   device_release+0x72/0x1d0
   kobject_put+0x144/0x410
   put_device+0x13/0x20
   klist_class_dev_put+0x31/0x40
   klist_put+0x8f/0xf0
   klist_del+0xe/0x10
   device_del+0x3a7/0x9a0
   nvme_destroy_subsystem+0xf9/0x150
   nvme_free_ctrl+0x280/0x3a0
   device_release+0x72/0x1d0
   kobject_put+0x144/0x410
   put_device+0x13/0x20
   nvme_free_ns+0xc4/0x100
   nvme_release+0xb3/0xe0
   __blkdev_put+0x549/0x6e0
   blkdev_put+0x72/0x2c0
   blkdev_close+0x8d/0xd0
   __fput+0x256/0x770
   fput+0xe/0x10
   task_work_run+0x10c/0x180
   exit_to_usermode_loop+0x151/0x170
   do_syscall_64+0x240/0x2e0
   entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: 32fd90c40768 ("nvme: change locking for the per-subsystem controller 
list")
Signed-off-by: Logan Gunthorpe 
Reviewed-by: Sagi Grimberg 
Reviewed-by : Chaitanya Kulkarni 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Sasha Levin 
---
 drivers/nvme/host/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index ab1a2b1ec3637..dfbd5872f4422 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2440,6 +2440,7 @@ static int nvme_init_subsystem(struct nvme_ctrl *ctrl, 
struct nvme_id_ctrl *id)
if (ret) {
dev_err(ctrl->device,
"failed to register subsystem device.\n");
+   put_device(&subsys->dev);
goto out_unlock;
}
ida_init(&subsys->ns_ida);
@@ -2462,7 +2463,6 @@ static int nvme_init_subsystem(struct nvme_ctrl *ctrl, 
struct nvme_id_ctrl *id)
nvme_put_subsystem(subsys);
 out_unlock:
mutex_unlock(&nvme_subsystems_lock);
-   put_device(&subsys->dev);
return ret;
 }
 
-- 
2.20.1



[PATCH AUTOSEL 5.2 21/44] auxdisplay: panel: need to delete scan_timer when misc_register fails in panel_attach

2019-08-20 Thread Sasha Levin
From: zhengbin 

[ Upstream commit b33d567560c1aadf3033290d74d4fd67af47aa61 ]

In panel_attach, if misc_register fails, we need to delete scan_timer,
which was setup in keypad_init->init_scan_timer.

Reported-by: Hulk Robot 
Signed-off-by: zhengbin 
Signed-off-by: Miguel Ojeda 
Signed-off-by: Sasha Levin 
---
 drivers/auxdisplay/panel.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/auxdisplay/panel.c b/drivers/auxdisplay/panel.c
index e06de63497cf8..e6bd727da503a 100644
--- a/drivers/auxdisplay/panel.c
+++ b/drivers/auxdisplay/panel.c
@@ -1617,6 +1617,8 @@ static void panel_attach(struct parport *port)
return;
 
 err_lcd_unreg:
+   if (scan_timer.function)
+   del_timer_sync(&scan_timer);
if (lcd.enabled)
charlcd_unregister(lcd.charlcd);
 err_unreg_device:
-- 
2.20.1



[PATCH AUTOSEL 5.2 19/44] soundwire: cadence_master: fix definitions for INTSTAT0/1

2019-08-20 Thread Sasha Levin
From: Pierre-Louis Bossart 

[ Upstream commit 664b16589f882202b8fa8149d0074f3159bade76 ]

Two off-by-one errors: INTSTAT0 missed BIT(31) and INTSTAT1 is only
defined on first 16 bits.

Signed-off-by: Pierre-Louis Bossart 
Link: 
https://lore.kernel.org/r/20190725234032.21152-15-pierre-louis.boss...@linux.intel.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
---
 drivers/soundwire/cadence_master.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/soundwire/cadence_master.c 
b/drivers/soundwire/cadence_master.c
index 18afb2e21dc9a..57ed2e2024bf4 100644
--- a/drivers/soundwire/cadence_master.c
+++ b/drivers/soundwire/cadence_master.c
@@ -95,8 +95,8 @@
 #define CDNS_MCP_SLAVE_INTMASK00x5C
 #define CDNS_MCP_SLAVE_INTMASK10x60
 
-#define CDNS_MCP_SLAVE_INTMASK0_MASK   GENMASK(30, 0)
-#define CDNS_MCP_SLAVE_INTMASK1_MASK   GENMASK(16, 0)
+#define CDNS_MCP_SLAVE_INTMASK0_MASK   GENMASK(31, 0)
+#define CDNS_MCP_SLAVE_INTMASK1_MASK   GENMASK(15, 0)
 
 #define CDNS_MCP_PORT_INTSTAT  0x64
 #define CDNS_MCP_PDI_STAT  0x6C
-- 
2.20.1



[PATCH AUTOSEL 5.2 01/44] dmaengine: ste_dma40: fix unneeded variable warning

2019-08-20 Thread Sasha Levin
From: Arnd Bergmann 

[ Upstream commit 5d6fb560729a5d5554e23db8d00eb57cd0021083 ]

clang-9 points out that there are two variables that depending on the
configuration may only be used in an ARRAY_SIZE() expression but not
referenced:

drivers/dma/ste_dma40.c:145:12: error: variable 'd40_backup_regs' is not needed 
and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static u32 d40_backup_regs[] = {
   ^
drivers/dma/ste_dma40.c:214:12: error: variable 'd40_backup_regs_chan' is not 
needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static u32 d40_backup_regs_chan[] = {

Mark these __maybe_unused to shut up the warning.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Nathan Chancellor 
Reviewed-by: Linus Walleij 
Link: https://lore.kernel.org/r/20190712091357.744515-1-a...@arndb.de
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
---
 drivers/dma/ste_dma40.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index 89d710899010d..de8bfd9a76e9e 100644
--- a/drivers/dma/ste_dma40.c
+++ b/drivers/dma/ste_dma40.c
@@ -142,7 +142,7 @@ enum d40_events {
  * when the DMA hw is powered off.
  * TODO: Add save/restore of D40_DREG_GCC on dma40 v3 or later, if that works.
  */
-static u32 d40_backup_regs[] = {
+static __maybe_unused u32 d40_backup_regs[] = {
D40_DREG_LCPA,
D40_DREG_LCLA,
D40_DREG_PRMSE,
@@ -211,7 +211,7 @@ static u32 d40_backup_regs_v4b[] = {
 
 #define BACKUP_REGS_SZ_V4B ARRAY_SIZE(d40_backup_regs_v4b)
 
-static u32 d40_backup_regs_chan[] = {
+static __maybe_unused u32 d40_backup_regs_chan[] = {
D40_CHAN_REG_SSCFG,
D40_CHAN_REG_SSELT,
D40_CHAN_REG_SSPTR,
-- 
2.20.1



[PATCH AUTOSEL 5.2 15/44] nvme-rdma: fix possible use-after-free in connect error flow

2019-08-20 Thread Sasha Levin
From: Sagi Grimberg 

[ Upstream commit d94211b8bad3787e0655a67284105f57db728cb1 ]

When start_queue fails, we need to make sure to drain the
queue cq before freeing the rdma resources because we might
still race with the completion path. Have start_queue() error
path safely stop the queue.

--
[30371.808111] nvme nvme1: Failed reconnect attempt 11
[30371.808113] nvme nvme1: Reconnecting in 10 seconds...
[...]
[30382.069315] nvme nvme1: creating 4 I/O queues.
[30382.257058] nvme nvme1: Connect Invalid SQE Parameter, qid 4
[30382.257061] nvme nvme1: failed to connect queue: 4 ret=386
[30382.305001] BUG: unable to handle kernel NULL pointer dereference at 
0018
[30382.305022] IP: qedr_poll_cq+0x8a3/0x1170 [qedr]
[30382.305028] PGD 0 P4D 0
[30382.305037] Oops:  [#1] SMP PTI
[...]
[30382.305153] Call Trace:
[30382.305166]  ? __switch_to_asm+0x34/0x70
[30382.305187]  __ib_process_cq+0x56/0xd0 [ib_core]
[30382.305201]  ib_poll_handler+0x26/0x70 [ib_core]
[30382.305213]  irq_poll_softirq+0x88/0x110
[30382.305223]  ? sort_range+0x20/0x20
[30382.305232]  __do_softirq+0xde/0x2c6
[30382.305241]  ? sort_range+0x20/0x20
[30382.305249]  run_ksoftirqd+0x1c/0x60
[30382.305258]  smpboot_thread_fn+0xef/0x160
[30382.305265]  kthread+0x113/0x130
[30382.305273]  ? kthread_create_worker_on_cpu+0x50/0x50
[30382.305281]  ret_from_fork+0x35/0x40
--

Reported-by: Nicolas Morey-Chaisemartin 
Reviewed-by: Max Gurtovoy 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Sasha Levin 
---
 drivers/nvme/host/rdma.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
index 97f668a39ae1c..7b074323bcdf2 100644
--- a/drivers/nvme/host/rdma.c
+++ b/drivers/nvme/host/rdma.c
@@ -562,13 +562,17 @@ static int nvme_rdma_alloc_queue(struct nvme_rdma_ctrl 
*ctrl,
return ret;
 }
 
+static void __nvme_rdma_stop_queue(struct nvme_rdma_queue *queue)
+{
+   rdma_disconnect(queue->cm_id);
+   ib_drain_qp(queue->qp);
+}
+
 static void nvme_rdma_stop_queue(struct nvme_rdma_queue *queue)
 {
if (!test_and_clear_bit(NVME_RDMA_Q_LIVE, &queue->flags))
return;
-
-   rdma_disconnect(queue->cm_id);
-   ib_drain_qp(queue->qp);
+   __nvme_rdma_stop_queue(queue);
 }
 
 static void nvme_rdma_free_queue(struct nvme_rdma_queue *queue)
@@ -607,11 +611,13 @@ static int nvme_rdma_start_queue(struct nvme_rdma_ctrl 
*ctrl, int idx)
else
ret = nvmf_connect_admin_queue(&ctrl->ctrl);
 
-   if (!ret)
+   if (!ret) {
set_bit(NVME_RDMA_Q_LIVE, &queue->flags);
-   else
+   } else {
+   __nvme_rdma_stop_queue(queue);
dev_info(ctrl->ctrl.device,
"failed to connect queue: %d ret=%d\n", idx, ret);
+   }
return ret;
 }
 
-- 
2.20.1



[PATCH AUTOSEL 5.2 06/44] afs: Fix off-by-one in afs_rename() expected data version calculation

2019-08-20 Thread Sasha Levin
From: David Howells 

[ Upstream commit 37c0bbb3326674940e657118306ac52364314523 ]

When afs_rename() calculates the expected data version of the target
directory in a cross-directory rename, it doesn't increment it as it
should, so it always thinks that the target inode is unexpectedly modified
on the server.

Fixes: a58823ac4589 ("afs: Fix application of status and callback to be under 
same lock")
Signed-off-by: David Howells 
Signed-off-by: Sasha Levin 
---
 fs/afs/dir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/afs/dir.c b/fs/afs/dir.c
index da9563d62b327..9750ac70f8ffb 100644
--- a/fs/afs/dir.c
+++ b/fs/afs/dir.c
@@ -1807,7 +1807,7 @@ static int afs_rename(struct inode *old_dir, struct 
dentry *old_dentry,
afs_end_vnode_operation(&fc);
goto error_rehash;
}
-   new_data_version = new_dvnode->status.data_version;
+   new_data_version = new_dvnode->status.data_version + 1;
} else {
new_data_version = orig_data_version;
new_scb = &scb[0];
-- 
2.20.1



Re: WARNING in kmem_cache_alloc_trace

2019-08-20 Thread syzbot

Hello,

syzbot has tested the proposed patch but the reproducer still triggered  
crash:

WARNING in yurex_write/usb_submit_urb

[ cut here ]
URB 52a92140 submitted while active
WARNING: CPU: 1 PID: 3052 at drivers/usb/core/urb.c:362  
usb_submit_urb+0x10c1/0x13b0 drivers/usb/core/urb.c:362

Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 3052 Comm: syz-executor.5 Not tainted 5.3.0-rc4+ #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xca/0x13e lib/dump_stack.c:113
 panic+0x2a3/0x6da kernel/panic.c:219
 __warn.cold+0x20/0x4a kernel/panic.c:576
 report_bug+0x262/0x2a0 lib/bug.c:186
 fixup_bug arch/x86/kernel/traps.c:179 [inline]
 fixup_bug arch/x86/kernel/traps.c:174 [inline]
 do_error_trap+0x12b/0x1e0 arch/x86/kernel/traps.c:272
 do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:291
 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1028
RIP: 0010:usb_submit_urb+0x10c1/0x13b0 drivers/usb/core/urb.c:362
Code: 89 de e8 62 b7 ef fd 84 db 0f 85 42 f6 ff ff e8 25 b6 ef fd 4c 89 fe  
48 c7 c7 c0 67 18 86 c6 05 87 29 3a 04 01 e8 14 9b c5 fd <0f> 0b e9 20 f6  
ff ff c7 44 24 14 01 00 00 00 e9 d7 f6 ff ff 41 bd

RSP: 0018:8881d4037c68 EFLAGS: 00010286
RAX:  RBX:  RCX: 
RDX:  RSI: 81288cfd RDI: ed103a806f7f
RBP: 11103a806f9f R08: 8881cfdc8000 R09: fbfff11ad3a4
R10: fbfff11ad3a3 R11: 88d69d1f R12: 8881d2352f00
R13: fff0 R14: 8881d2352f48 R15: 8881d1feef00
 yurex_write+0x395/0x6e0 drivers/usb/misc/yurex.c:493
 __vfs_write+0x76/0x100 fs/read_write.c:494
 vfs_write+0x262/0x5c0 fs/read_write.c:558
 ksys_write+0x127/0x250 fs/read_write.c:611
 do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7fe53dbeec78 EFLAGS: 0246 ORIG_RAX: 0001
RAX: ffda RBX: 0003 RCX: 00459829
RDX: 008d RSI: 2040 RDI: 0004
RBP: 0075bfc8 R08:  R09: 
R10:  R11: 0246 R12: 7fe53dbef6d4
R13: 004c99b9 R14: 004e1038 R15: 
Kernel Offset: disabled
Rebooting in 86400 seconds..


Tested on:

commit: d0847550 usb-fuzzer: main usb gadget fuzzer driver
git tree:   https://github.com/google/kasan.git
console output: https://syzkaller.appspot.com/x/log.txt?x=154528bc60
kernel config:  https://syzkaller.appspot.com/x/.config?x=dbc9c80cc095da19
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
patch:  https://syzkaller.appspot.com/x/patch.diff?x=14dedf6a60



[PATCH AUTOSEL 5.2 05/44] fs: afs: Fix a possible null-pointer dereference in afs_put_read()

2019-08-20 Thread Sasha Levin
From: Jia-Ju Bai 

[ Upstream commit a6eed4ab5dd4bfb696c1a3f49742b8d1846a66a0 ]

In afs_read_dir(), there is an if statement on line 255 to check whether
req->pages is NULL:
if (!req->pages)
goto error;

If req->pages is NULL, afs_put_read() on line 337 is executed.
In afs_put_read(), req->pages[i] is used on line 195.
Thus, a possible null-pointer dereference may occur in this case.

To fix this possible bug, an if statement is added in afs_put_read() to
check req->pages.

This bug is found by a static analysis tool STCheck written by us.

Fixes: f3ddee8dc4e2 ("afs: Fix directory handling")
Signed-off-by: Jia-Ju Bai 
Signed-off-by: David Howells 
Signed-off-by: Sasha Levin 
---
 fs/afs/file.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/fs/afs/file.c b/fs/afs/file.c
index 8fd7d3b9a1b1f..87beabc7114ee 100644
--- a/fs/afs/file.c
+++ b/fs/afs/file.c
@@ -191,11 +191,13 @@ void afs_put_read(struct afs_read *req)
int i;
 
if (refcount_dec_and_test(&req->usage)) {
-   for (i = 0; i < req->nr_pages; i++)
-   if (req->pages[i])
-   put_page(req->pages[i]);
-   if (req->pages != req->array)
-   kfree(req->pages);
+   if (req->pages) {
+   for (i = 0; i < req->nr_pages; i++)
+   if (req->pages[i])
+   put_page(req->pages[i]);
+   if (req->pages != req->array)
+   kfree(req->pages);
+   }
kfree(req);
}
 }
-- 
2.20.1



Re: [PATCH] x86/mm/pti: in pti_clone_pgtable() don't increase addr by PUD_SIZE

2019-08-20 Thread Thomas Gleixner
On Tue, 20 Aug 2019, Song Liu wrote:
> > On Aug 20, 2019, at 4:16 AM, Thomas Gleixner  wrote:
> > 
> > On Tue, 20 Aug 2019, Peter Zijlstra wrote:
> >> What that code wants to do is skip to the end of the pud, a pmd_size
> >> increase will not do that. And right below this, there's a second
> >> instance of this exact pattern.
> >> 
> >> Did I get the below right?
> >> 
> >> ---
> >> diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
> >> index b196524759ec..32b20b3cb227 100644
> >> --- a/arch/x86/mm/pti.c
> >> +++ b/arch/x86/mm/pti.c
> >> @@ -330,12 +330,14 @@ pti_clone_pgtable(unsigned long start, unsigned long 
> >> end,
> >> 
> >>pud = pud_offset(p4d, addr);
> >>if (pud_none(*pud)) {
> >> +  addr &= PUD_MASK;
> >>addr += PUD_SIZE;
> > 
> > round_up(addr, PUD_SIZE);
> 
> I guess we need "round_up(addr + PMD_SIZE, PUD_SIZE)". 

Right you are.


[PATCH] bonding: force enable lacp port after link state recovery for 802.3ad

2019-08-20 Thread zhangsha.zhang
From: Sha Zhang 

After the commit 334031219a84 ("bonding/802.3ad: fix slave link
initialization transition states") merged,
the slave's link status will be changed to BOND_LINK_FAIL
from BOND_LINK_DOWN in the following scenario:
- Driver reports loss of carrier and
  bonding driver receives NETDEV_CHANGE notifier
- slave's duplex and speed is zerod and
  its port->is_enabled is cleard to 'false';
- Driver reports link recovery and
  bonding driver receives NETDEV_UP notifier;
- If speed/duplex getting failed here, the link status
  will be changed to BOND_LINK_FAIL;
- The MII monotor later recover the slave's speed/duplex
  and set link status to BOND_LINK_UP, but remains
  the 'port->is_enabled' to 'false'.

In this scenario, the lacp port will not be enabled even its speed
and duplex are valid. The bond will not send LACPDU's, and its
state is 'AD_STATE_DEFAULTED' forever. The simplest fix I think
is to force enable lacp after port slave speed check in
bond_miimon_commit. As enabled, the lacp port can run its state machine
normally after link recovery.

Signed-off-by: Sha Zhang 
---
 drivers/net/bonding/bond_main.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 931d9d9..379253a 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2194,6 +2194,7 @@ static void bond_miimon_commit(struct bonding *bond)
 {
struct list_head *iter;
struct slave *slave, *primary;
+   struct port *port;
 
bond_for_each_slave(bond, slave, iter) {
switch (slave->new_link) {
@@ -2205,8 +2206,13 @@ static void bond_miimon_commit(struct bonding *bond)
 * link status
 */
if (BOND_MODE(bond) == BOND_MODE_8023AD &&
-   slave->link == BOND_LINK_UP)
+   slave->link == BOND_LINK_UP) {
bond_3ad_adapter_speed_duplex_changed(slave);
+   if (slave->duplex == DUPLEX_FULL) {
+   port = &(SLAVE_AD_INFO(slave)->port);
+   port->is_enabled = true;
+   }
+   }
continue;
 
case BOND_LINK_UP:
-- 
1.8.3.1



Re: [PATCH 9/9] drivers: ata: sata_rcar: use devm_platform_ioremap_resource()

2019-08-20 Thread Bartlomiej Zolnierkiewicz


On 8/20/19 2:35 PM, Enrico Weigelt, metux IT consult wrote:
> Use the new helper that wraps the calls to platform_get_resource()
> and devm_ioremap_resource() together.
> 
> Signed-off-by: Enrico Weigelt, metux IT consult 

Acked-by: Bartlomiej Zolnierkiewicz 

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
>  drivers/ata/sata_rcar.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/ata/sata_rcar.c b/drivers/ata/sata_rcar.c
> index 3495e17..14ea1d6 100644
> --- a/drivers/ata/sata_rcar.c
> +++ b/drivers/ata/sata_rcar.c
> @@ -886,7 +886,6 @@ static int sata_rcar_probe(struct platform_device *pdev)
>   struct device *dev = &pdev->dev;
>   struct ata_host *host;
>   struct sata_rcar_priv *priv;
> - struct resource *mem;
>   int irq;
>   int ret = 0;
>  
> @@ -915,8 +914,7 @@ static int sata_rcar_probe(struct platform_device *pdev)
>  
>   host->private_data = priv;
>  
> - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - priv->base = devm_ioremap_resource(dev, mem);
> + priv->base = devm_platform_ioremap_resource(pdev, 0);
>   if (IS_ERR(priv->base)) {
>   ret = PTR_ERR(priv->base);
>   goto err_pm_put;


Re: [PATCH 8/9] drivers: ata: sata_gemini: use devm_platform_ioremap_resource()

2019-08-20 Thread Bartlomiej Zolnierkiewicz


On 8/20/19 2:35 PM, Enrico Weigelt, metux IT consult wrote:
> Use the new helper that wraps the calls to platform_get_resource()
> and devm_ioremap_resource() together.

It would also be worth to mention in the patch description that
on !res condition the driver will now return -EINVAL (instead of
-ENODEV) and print an error.

> Signed-off-by: Enrico Weigelt, metux IT consult 

Acked-by: Bartlomiej Zolnierkiewicz 

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
>  drivers/ata/sata_gemini.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/drivers/ata/sata_gemini.c b/drivers/ata/sata_gemini.c
> index f793564..55e2689 100644
> --- a/drivers/ata/sata_gemini.c
> +++ b/drivers/ata/sata_gemini.c
> @@ -318,7 +318,6 @@ static int gemini_sata_probe(struct platform_device *pdev)
>   struct device_node *np = dev->of_node;
>   struct sata_gemini *sg;
>   struct regmap *map;
> - struct resource *res;
>   enum gemini_muxmode muxmode;
>   u32 gmode;
>   u32 gmask;
> @@ -329,11 +328,7 @@ static int gemini_sata_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>   sg->dev = dev;
>  
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res)
> - return -ENODEV;
> -
> - sg->base = devm_ioremap_resource(dev, res);
> + sg->base = devm_platform_ioremap_resource(pdev, 0);
>   if (IS_ERR(sg->base))
>   return PTR_ERR(sg->base);


Re: [EXT] Re: [PATCH net-next 0/1] Add BASE-T1 PHY support

2019-08-20 Thread Christian Herber
On 19.08.2019 21:07, Heiner Kallweit wrote:
> Caution: EXT Email
> 
> On 19.08.2019 08:32, Christian Herber wrote:
>> On 16.08.2019 22:59, Heiner Kallweit wrote:
>>> On 15.08.2019 17:32, Christian Herber wrote:
 This patch adds basic support for BASE-T1 PHYs in the framework.
 BASE-T1 PHYs main area of application are automotive and industrial.
 BASE-T1 is standardized in IEEE 802.3, namely
 - IEEE 802.3bw: 100BASE-T1
 - IEEE 802.3bp 1000BASE-T1
 - IEEE 802.3cg: 10BASE-T1L and 10BASE-T1S

 There are no products which contain BASE-T1 and consumer type PHYs like
 1000BASE-T. However, devices exist which combine 100BASE-T1 and 1000BASE-T1
 PHYs with auto-negotiation.
>>>
>>> Is this meant in a way that *currently* there are no PHY's combining Base-T1
>>> with normal Base-T modes? Or are there reasons why this isn't possible in
>>> general? I'm asking because we have PHY's combining copper and fiber, and 
>>> e.g.
>>> the mentioned Aquantia PHY that combines NBase-T with 1000Base-T2.
>>>

 The intention of this patch is to make use of the existing Clause 45 
 functions.
 BASE-T1 adds some additional registers e.g. for aneg control, which follow 
 a
 similiar register layout as the existing devices. The bits which are used 
 in
 BASE-T1 specific registers are the same as in basic registers, thus the
 existing functions can be resued, with get_aneg_ctrl() selecting the 
 correct
 register address.

>>> If Base-T1 can't be combined with other modes then at a first glance I see 
>>> no
>>> benefit in defining new registers e.g. for aneg control, and the standard 
>>> ones
>>> are unused. Why not using the standard registers? Can you shed some light 
>>> on that?
>>>
>>> Are the new registers internally shadowed to the standard location?
>>> That's something I've seen on other PHY's: one register appears in different
>>> places in different devices.
>>>
 The current version of ethtool has been prepared for 100/1000BASE-T1 and 
 works
 with this patch. 10BASE-T1 needs to be added to ethtool.

 Christian Herber (1):
 Added BASE-T1 PHY support to PHY Subsystem

drivers/net/phy/phy-c45.c| 113 +++
drivers/net/phy/phy-core.c   |   4 +-
include/uapi/linux/ethtool.h |   2 +
include/uapi/linux/mdio.h|  21 +++
4 files changed, 129 insertions(+), 11 deletions(-)

>>>
>>> Heiner
>>>
>>
>> Hi Heiner,
>>
>> I do not think the Aquantia part you are describing is publicly
>> documented, so i cannot comment on that part.
> Right, datasheet isn't publicly available. All I wanted to say with
> mentioning this PHY: It's not a rare exception that a PHY combines
> standard BaseT modes with "non-consumer" modes for special purposes.
> One practical use case of this proprietary 1000Base-T2 mode is
> re-using existing 2-pair cabling in aircrafts.
> 
>> There are multiple reasons why e.g. xBASE-T1 plus 1000BASE-T is
>> unlikely. First, the is no use-case known to me, where this would be
>> required. Second, there is no way that you can do an auto-negotiation
>> between the two, as these both have their own auto-neg defined (Clause
>> 28/73 vs. Clause 98). Thirdly, if you would ever have a product with
>> both, I believe it would just include two full PHYs and a way to select
>> which flavor you want. Of course, this is the theory until proven
>> otherwise, but to me it is sufficient to use a single driver.
>>
> I'm with you if you say it's unlikely. However your statement in the
> commit message leaves the impression that there can't be such a device.
> And that's a difference.
> 
> Regarding "including two full PHYs":
> This case we have already, there are PHYs combining different IP blocks,
> each one supporting a specific mode (e.g. copper and fiber). There you
> also have the case of different autoneg methods, clause 28 vs. clause 37.
> 
>> The registers are different in the fields they include. It is just that
>> the flags which are used by the Linux driver, like restarting auto-neg,
>> are at the same position.
>>
> Good to know. Your commit description doesn't mention any specific PHY.
> I suppose you have PHYs you'd like to operate with the genphy_c45 driver.
> Could you give an example? And ideally, is a public datasheet available?
> 
>> Christian
>>
>>
> Heiner
> 

There are no public BASE-T1 devices on the market right now that use 
Clause 45 standard registers. The first such products were developed 
before the IEEE standard (BroadR-Reach) and used Clause 22 access (see 
e.g. the support in the Kernel for TJA110x).

The most convenient way to test with a BASE-T1 device would be to use an 
SFP (e.g. 
https://technica-engineering.de/produkt/1000base-t1-sfp-module/). 
Alternative source could be Goepel.

There are also a number of media-converters around where one could break 
out the MDIO and connect to a processor. Of course,

Re: [PATCH v4 04/10] mailbox: sunxi-msgbox: Add a new mailbox driver

2019-08-20 Thread Ondřej Jirman
Hi,

On Tue, Aug 20, 2019 at 08:07:53AM -0500, Samuel Holland wrote:
> On 8/20/19 6:18 AM, Ondřej Jirman wrote:
> > Hi Samuel,
> > 
> > On Mon, Aug 19, 2019 at 10:23:05PM -0500, Samuel Holland wrote:
> >> Allwinner sun8i, sun9i, and sun50i SoCs contain a hardware message box
> >> used for communication between the ARM CPUs and the ARISC management
> >> coprocessor. The hardware contains 8 unidirectional 4-message FIFOs.
> >>
> >> Add a driver for it, so it can be used for SCPI or other communication
> >> protocols.
> >>
> >> Signed-off-by: Samuel Holland 
> >> ---
> >>  drivers/mailbox/Kconfig|  10 +
> >>  drivers/mailbox/Makefile   |   2 +
> >>  drivers/mailbox/sunxi-msgbox.c | 323 +
> >>  3 files changed, 335 insertions(+)
> >>  create mode 100644 drivers/mailbox/sunxi-msgbox.c
> >>
> >> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> >> index ab4eb750bbdd..57d12936175e 100644
> >> --- a/drivers/mailbox/Kconfig
> >> +++ b/drivers/mailbox/Kconfig
> >> @@ -227,4 +227,14 @@ config ZYNQMP_IPI_MBOX
> >>  message to the IPI buffer and will access the IPI control
> >>  registers to kick the other processor or enquire status.
> >>  
> >> +config SUNXI_MSGBOX
> >> +  tristate "Allwinner sunxi Message Box"
> >> +  depends on ARCH_SUNXI || COMPILE_TEST
> >> +  default ARCH_SUNXI
> >> +  help
> >> +Mailbox implementation for the hardware message box present in
> >> +Allwinner sun8i, sun9i, and sun50i SoCs. The hardware message box is
> >> +used for communication between the application CPUs and the power
> >> +management coprocessor.
> >> +
> >>  endif
> >> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> >> index c22fad6f696b..bec2d50b0976 100644
> >> --- a/drivers/mailbox/Makefile
> >> +++ b/drivers/mailbox/Makefile
> >> @@ -48,3 +48,5 @@ obj-$(CONFIG_STM32_IPCC) += stm32-ipcc.o
> >>  obj-$(CONFIG_MTK_CMDQ_MBOX)   += mtk-cmdq-mailbox.o
> >>  
> >>  obj-$(CONFIG_ZYNQMP_IPI_MBOX) += zynqmp-ipi-mailbox.o
> >> +
> >> +obj-$(CONFIG_SUNXI_MSGBOX)+= sunxi-msgbox.o
> >> diff --git a/drivers/mailbox/sunxi-msgbox.c 
> >> b/drivers/mailbox/sunxi-msgbox.c
> >> new file mode 100644
> >> index ..29a5101a5390
> >> --- /dev/null
> >> +++ b/drivers/mailbox/sunxi-msgbox.c
> >> @@ -0,0 +1,323 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +//
> >> +// Copyright (c) 2017-2019 Samuel Holland 
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#define NUM_CHANS 8
> >> +
> >> +#define CTRL_REG(n)   (0x + 0x4 * ((n) / 4))
> >> +#define CTRL_RX(n)BIT(0 + 8 * ((n) % 4))
> >> +#define CTRL_TX(n)BIT(4 + 8 * ((n) % 4))
> >> +
> >> +#define REMOTE_IRQ_EN_REG 0x0040
> >> +#define REMOTE_IRQ_STAT_REG   0x0050
> >> +#define LOCAL_IRQ_EN_REG  0x0060
> >> +#define LOCAL_IRQ_STAT_REG0x0070
> >> +
> >> +#define RX_IRQ(n) BIT(0 + 2 * (n))
> >> +#define RX_IRQ_MASK   0x
> >> +#define TX_IRQ(n) BIT(1 + 2 * (n))
> >> +#define TX_IRQ_MASK   0x
> >> +
> >> +#define FIFO_STAT_REG(n)  (0x0100 + 0x4 * (n))
> >> +#define FIFO_STAT_MASKGENMASK(0, 0)
> >> +
> >> +#define MSG_STAT_REG(n)   (0x0140 + 0x4 * (n))
> >> +#define MSG_STAT_MASK GENMASK(2, 0)
> >> +
> >> +#define MSG_DATA_REG(n)   (0x0180 + 0x4 * (n))
> >> +
> >> +#define mbox_dbg(mbox, ...)   dev_dbg((mbox)->controller.dev, 
> >> __VA_ARGS__)
> >> +
> >> +struct sunxi_msgbox {
> >> +  struct mbox_controller controller;
> >> +  struct clk *clk;
> >> +  spinlock_t lock;
> >> +  void __iomem *regs;
> >> +};
> >> +
> >> +static bool sunxi_msgbox_last_tx_done(struct mbox_chan *chan);
> >> +static bool sunxi_msgbox_peek_data(struct mbox_chan *chan);
> >> +
> >> +static inline int channel_number(struct mbox_chan *chan)
> >> +{
> >> +  return chan - chan->mbox->chans;
> >> +}
> >> +
> >> +static inline struct sunxi_msgbox *channel_to_msgbox(struct mbox_chan 
> >> *chan)
> >> +{
> >> +  return chan->con_priv;
> >> +}
> >> +
> >> +static irqreturn_t sunxi_msgbox_irq(int irq, void *dev_id)
> >> +{
> >> +  struct sunxi_msgbox *mbox = dev_id;
> >> +  uint32_t status;
> >> +  int n;
> >> +
> >> +  /* Only examine channels that are currently enabled. */
> >> +  status = readl(mbox->regs + LOCAL_IRQ_EN_REG) &
> >> +   readl(mbox->regs + LOCAL_IRQ_STAT_REG);
> >> +
> >> +  if (!(status & RX_IRQ_MASK))
> >> +  return IRQ_NONE;
> >> +
> >> +  for (n = 0; n < NUM_CHANS; ++n) {
> >> +  struct mbox_chan *chan = &mbox->controller.chans[n];
> >> +
> >> +  if (!(status & RX_IRQ(n)))
> >> +  continue;
> >> +
> >> +  while (sunxi_msgbox_peek_data(chan)) {
> >> +  uint32_t m

Re: [PATCH 4/4] mm, notifier: Catch sleeping/blocking for !blockable

2019-08-20 Thread Jason Gunthorpe
On Tue, Aug 20, 2019 at 10:19:02AM +0200, Daniel Vetter wrote:
> We need to make sure implementations don't cheat and don't have a
> possible schedule/blocking point deeply burried where review can't
> catch it.
> 
> I'm not sure whether this is the best way to make sure all the
> might_sleep() callsites trigger, and it's a bit ugly in the code flow.
> But it gets the job done.
> 
> Inspired by an i915 patch series which did exactly that, because the
> rules haven't been entirely clear to us.
> 
> v2: Use the shiny new non_block_start/end annotations instead of
> abusing preempt_disable/enable.
> 
> v3: Rebase on top of Glisse's arg rework.
> 
> v4: Rebase on top of more Glisse rework.
> 
> Cc: Jason Gunthorpe 
> Cc: Andrew Morton 
> Cc: Michal Hocko 
> Cc: David Rientjes 
> Cc: "Christian König" 
> Cc: Daniel Vetter 
> Cc: "Jérôme Glisse" 
> Cc: linux...@kvack.org
> Reviewed-by: Christian König 
> Reviewed-by: Jérôme Glisse 
> Signed-off-by: Daniel Vetter 
>  mm/mmu_notifier.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> index 538d3bb87f9b..856636d06ee0 100644
> +++ b/mm/mmu_notifier.c
> @@ -181,7 +181,13 @@ int __mmu_notifier_invalidate_range_start(struct 
> mmu_notifier_range *range)
>   id = srcu_read_lock(&srcu);
>   hlist_for_each_entry_rcu(mn, &range->mm->mmu_notifier_mm->list, hlist) {
>   if (mn->ops->invalidate_range_start) {
> - int _ret = mn->ops->invalidate_range_start(mn, range);
> + int _ret;
> +
> + if (!mmu_notifier_range_blockable(range))
> + non_block_start();
> + _ret = mn->ops->invalidate_range_start(mn, range);
> + if (!mmu_notifier_range_blockable(range))
> + non_block_end();

If someone Acks all the sched changes then I can pick this for
hmm.git, but I still think the existing pre-emption debugging is fine
for this use case.

Also, same comment as for the lockdep map, this needs to apply to the
non-blocking range_end also.

Anyhow, since this series has conflicts with hmm.git it would be best
to flow through the whole thing through that tree. If there are no
remarks on the first two patches I'll grab them in a few days.

Regards,
Jason


Re: [PATCH 2/4] x86/vmware: Add a header file for hypercall definitions

2019-08-20 Thread VMware

On 8/20/19 1:32 PM, Peter Zijlstra wrote:

On Sun, Aug 18, 2019 at 04:33:14PM +0200, Thomas Hellström (VMware) wrote:


+#define VMWARE_HYPERCALL \
+   ALTERNATIVE_2(".byte 0xed", \
+ ".byte 0x0f, 0x01, 0xc1", X86_FEATURE_VMW_VMCALL,   \
+ ".byte 0x0f, 0x01, 0xd9", X86_FEATURE_VMW_VMMCALL)

For sanity, could we either add comments, or macros for those
instrucions?


Hmm. Here I followed and slightly extended what was done in asm/kvm_para.h.

What confuses me a bit is, if it's clarity we're after, why don't people use

#define VMWARE_HYPERCALL\
ALTERNATIVE_2("inl (%%dx)",   \
  "vmcall", X86_FEATURE_VMW_VMCALL,   \   
  "vmmcall", X86_FEATURE_VMW_VMMCALL)

Seems to build fine here. Is it fear of old assemblers not supporting, for 
example vmmcall

Thanks,
/Thomas
 


Something like:

#define INSN_INL0xed
#define INSN_VMCALL 0x0f,0x01,0xc1
#define INSN_VMMCALL0x0f,0x01,0xd9

#define VMWARE_HYPERCALL \
ALTERNATIVE_2(_ASM_MK_NOP(INSN_INL),
  _ASM_MK_NOP(INSN_VMCALL), X86_FEATURE_VMCALL,
  _ASM_MK_NOP(INSN_VMMCALL), X86_FEATURE_VMMCALL)

With possibly a patch that does 's/_ASM_MK_NOP/_ASM_MK_INSN/' on
arch/x86/ for further sanity :-)





Re: [PATCH] MAINTAINERS: Extend patterns for Samsung SoC, Security Subsystem and clock drivers

2019-08-20 Thread Sylwester Nawrocki
On 8/18/19 19:27, Krzysztof Kozlowski wrote:
> Extend the patterns to cover all related files in respective
> categories:
> 1. Samsung Exynos ARM architecture: add soc drivers headers and make
>directory matches consistent,
> 2. Samsung Security SubSystem driver (crypto): add bindings,
> 3. Samsung SoC clock drivers: add S3C24xx, S3C64xx and S5Pv210 bindings.

Acked-by: Sylwester Nawrocki 


Re: [PATCH v2 1/8] arm64: dts: qcom: sm8150: add base dts file

2019-08-20 Thread Amit Kucheria
On Tue, Aug 20, 2019 at 12:14 PM Vinod Koul  wrote:
>
> This add base DTS file with cpu, psci, firmware, clock, tlmm and
> spmi nodes which enables boot to console
>
> Signed-off-by: Vinod Koul 
> ---
>  arch/arm64/boot/dts/qcom/sm8150.dtsi | 305 +++
>  1 file changed, 305 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/sm8150.dtsi
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi 
> b/arch/arm64/boot/dts/qcom/sm8150.dtsi
> new file mode 100644
> index ..d9dc95f851b7
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
> @@ -0,0 +1,305 @@
> +// SPDX-License-Identifier: BSD-3-Clause

This is fine.

> +// Copyright (c) 2017-2019, The Linux Foundation. All rights reserved.
> +// Copyright (c) 2019, Linaro Limited

These two lines should be in /* */


> +
> +#include 
> +#include 
> +#include 
> +
> +/ {
> +   interrupt-parent = <&intc>;
> +
> +   #address-cells = <2>;
> +   #size-cells = <2>;
> +
> +   chosen { };
> +
> +   clocks {
> +   xo_board: xo-board {
> +   compatible = "fixed-clock";
> +   #clock-cells = <0>;
> +   clock-frequency = <3840>;
> +   clock-output-names = "xo_board";
> +   };
> +
> +   sleep_clk: sleep-clk {
> +   compatible = "fixed-clock";
> +   #clock-cells = <0>;
> +   clock-frequency = <32764>;
> +   clock-output-names = "sleep_clk";
> +   };
> +   };
> +
> +   cpus {
> +   #address-cells = <2>;
> +   #size-cells = <0>;
> +
> +   CPU0: cpu@0 {
> +   device_type = "cpu";
> +   compatible = "qcom,kryo485";
> +   reg = <0x0 0x0>;
> +   enable-method = "psci";
> +   next-level-cache = <&L2_0>;
> +   L2_0: l2-cache {
> +   compatible = "cache";
> +   next-level-cache = <&L3_0>;
> +   L3_0: l3-cache {
> + compatible = "cache";
> +   };
> +   };
> +   };
> +
> +   CPU1: cpu@100 {
> +   device_type = "cpu";
> +   compatible = "qcom,kryo485";
> +   reg = <0x0 0x100>;
> +   enable-method = "psci";
> +   next-level-cache = <&L2_100>;
> +   L2_100: l2-cache {
> +   compatible = "cache";
> +   next-level-cache = <&L3_0>;
> +   };
> +
> +   };
> +
> +   CPU2: cpu@200 {
> +   device_type = "cpu";
> +   compatible = "qcom,kryo485";
> +   reg = <0x0 0x200>;
> +   enable-method = "psci";
> +   next-level-cache = <&L2_200>;
> +   L2_200: l2-cache {
> +   compatible = "cache";
> +   next-level-cache = <&L3_0>;
> +   };
> +   };
> +
> +   CPU3: cpu@300 {
> +   device_type = "cpu";
> +   compatible = "qcom,kryo485";
> +   reg = <0x0 0x300>;
> +   enable-method = "psci";
> +   next-level-cache = <&L2_300>;
> +   L2_300: l2-cache {
> +   compatible = "cache";
> +   next-level-cache = <&L3_0>;
> +   };
> +   };
> +
> +   CPU4: cpu@400 {
> +   device_type = "cpu";
> +   compatible = "qcom,kryo485";
> +   reg = <0x0 0x400>;
> +   enable-method = "psci";
> +   next-level-cache = <&L2_400>;
> +   L2_400: l2-cache {
> +   compatible = "cache";
> +   next-level-cache = <&L3_0>;
> +   };
> +   };
> +
> +   CPU5: cpu@500 {
> +   device_type = "cpu";
> +   compatible = "qcom,kryo485";
> +   reg = <0x0 0x500>;
> +   enable-method = "psci";
> +   next-level-cache = <&L2_500>;
> +   L2_500: l2-cache {
> +   compatible = "cache";
> +   next-level-cache = <&L3_0>;
> +   };
> +   };
> +
> +   CPU6: cpu@600 {
> +   device_type = "cpu";
> +   compatible = "qcom,kryo485";

Re: [PATCH 7/9] drivers: ata: sata_dwc_460ex: use devm_platform_ioremap_resource()

2019-08-20 Thread Bartlomiej Zolnierkiewicz


On 8/20/19 2:35 PM, Enrico Weigelt, metux IT consult wrote:
> Use the new helper that wraps the calls to platform_get_resource()
> and devm_ioremap_resource() together.
> 
> Signed-off-by: Enrico Weigelt, metux IT consult 

Acked-by: Bartlomiej Zolnierkiewicz 

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
>  drivers/ata/sata_dwc_460ex.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
> index 9dcef6a..de248fa 100644
> --- a/drivers/ata/sata_dwc_460ex.c
> +++ b/drivers/ata/sata_dwc_460ex.c
> @@ -237,7 +237,6 @@ static int sata_dwc_dma_init_old(struct platform_device 
> *pdev,
>struct sata_dwc_device *hsdev)
>  {
>   struct device_node *np = pdev->dev.of_node;
> - struct resource *res;
>  
>   hsdev->dma = devm_kzalloc(&pdev->dev, sizeof(*hsdev->dma), GFP_KERNEL);
>   if (!hsdev->dma)
> @@ -254,8 +253,7 @@ static int sata_dwc_dma_init_old(struct platform_device 
> *pdev,
>   }
>  
>   /* Get physical SATA DMA register base address */
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> - hsdev->dma->regs = devm_ioremap_resource(&pdev->dev, res);
> + hsdev->dma->regs = devm_platform_ioremap_resource(pdev, 1);
>   if (IS_ERR(hsdev->dma->regs))
>   return PTR_ERR(hsdev->dma->regs);



<    3   4   5   6   7   8   9   10   11   12   >