Re: [PATCH V4 1/5] nvme: do atomically bit operations on nvme_request.flags

2018-03-07 Thread Christoph Hellwig
On Thu, Mar 08, 2018 at 02:19:27PM +0800, Jianchao Wang wrote:
> Do atomically bit operations on nvme_request.flags instead of
> regular read/write, then we could add other flags and set/clear
> them safely.
> 
> Signed-off-by: Jianchao Wang 

Looks good, assuming an actual need for this shows up in the next
patches :)

Reviewed-by: Christoph Hellwig 

> diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
> index e80fd74..02097e8 100644
> --- a/drivers/nvme/host/nvme.h
> +++ b/drivers/nvme/host/nvme.h
> @@ -93,8 +93,8 @@ struct nvme_request {
>   struct nvme_command *cmd;
>   union nvme_result   result;
>   u8  retries;
> - u8  flags;
>   u16 status;
> + unsigned long flags;

Please align the field name like the others, though.


Re: [PATCH V4 1/5] nvme: do atomically bit operations on nvme_request.flags

2018-03-07 Thread Christoph Hellwig
On Thu, Mar 08, 2018 at 02:19:27PM +0800, Jianchao Wang wrote:
> Do atomically bit operations on nvme_request.flags instead of
> regular read/write, then we could add other flags and set/clear
> them safely.
> 
> Signed-off-by: Jianchao Wang 

Looks good, assuming an actual need for this shows up in the next
patches :)

Reviewed-by: Christoph Hellwig 

> diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
> index e80fd74..02097e8 100644
> --- a/drivers/nvme/host/nvme.h
> +++ b/drivers/nvme/host/nvme.h
> @@ -93,8 +93,8 @@ struct nvme_request {
>   struct nvme_command *cmd;
>   union nvme_result   result;
>   u8  retries;
> - u8  flags;
>   u16 status;
> + unsigned long flags;

Please align the field name like the others, though.


Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

2018-03-07 Thread Mikko Perttunen



On 07.03.2018 16:20, Guenter Roeck wrote:

On 03/07/2018 01:47 AM, Rajkumar Rampelli wrote:



On Wednesday 28 February 2018 07:59 PM, Guenter Roeck wrote:

On 02/27/2018 11:03 PM, Mikko Perttunen wrote:

On 02/28/2018 08:12 AM, Rajkumar Rampelli wrote:


On Wednesday 28 February 2018 11:28 AM, Guenter Roeck wrote:

On 02/27/2018 09:38 PM, Rajkumar Rampelli wrote:


On Wednesday 21 February 2018 08:20 PM, Guenter Roeck wrote:

On 02/20/2018 10:58 PM, Rajkumar Rampelli wrote:

Add generic PWM based tachometer driver via HWMON interface
to report the RPM of motor. This drivers get the period/duty
cycle from PWM IP which captures the motor PWM output.

This driver implements a simple interface for monitoring the
speed of
a fan and exposes it in roatations per minute (RPM) to the user
space
by using the hwmon's sysfs interface

Signed-off-by: Rajkumar Rampelli 
---
  Documentation/hwmon/generic-pwm-tachometer |  17 +
  drivers/hwmon/Kconfig  |  10 +++
  drivers/hwmon/Makefile |   1 +
  drivers/hwmon/generic-pwm-tachometer.c | 112
+
  4 files changed, 140 insertions(+)
  create mode 100644 Documentation/hwmon/generic-pwm-tachometer
  create mode 100644 drivers/hwmon/generic-pwm-tachometer.c

diff --git a/Documentation/hwmon/generic-pwm-tachometer
b/Documentation/hwmon/generic-pwm-tachometer
new file mode 100644
index 000..e0713ee
--- /dev/null
+++ b/Documentation/hwmon/generic-pwm-tachometer
@@ -0,0 +1,17 @@
+Kernel driver generic-pwm-tachometer
+
+
+This driver enables the use of a PWM module to monitor a fan.
It uses the
+generic PWM interface and can be used on SoCs as along as the
SoC supports
+Tachometer controller that moniors the Fan speed in periods.
+
+Author: Rajkumar Rampelli 
+
+Description
+---
+
+The driver implements a simple interface for monitoring the
Fan speed using
+PWM module and Tachometer controller. It requests period value
through PWM
+capture interface to Tachometer and measures the Rotations per
minute using
+received period value. It exposes the Fan speed in RPM to the
user space by
+using the hwmon's sysfs interface.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ef23553..8912dcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1878,6 +1878,16 @@ config SENSORS_XGENE
If you say yes here you get support for the temperature
and power sensors for APM X-Gene SoC.
  +config GENERIC_PWM_TACHOMETER
+tristate "Generic PWM based tachometer driver"
+depends on PWM
+help
+  Enables a driver to use PWM signal from motor to use
+  for measuring the motor speed. The RPM is captured by
+  PWM modules which has PWM capture capability and this
+  drivers reads the captured data from PWM IP to convert
+  it to speed in RPM.
+
  if ACPI
comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index f814b4a..9dcc374 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_SENSORS_WM8350)+=
wm8350-hwmon.o
  obj-$(CONFIG_SENSORS_XGENE)+= xgene-hwmon.o
obj-$(CONFIG_PMBUS)+= pmbus/
+obj-$(CONFIG_GENERIC_PWM_TACHOMETER) += generic-pwm-tachometer.o
ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
  diff --git a/drivers/hwmon/generic-pwm-tachometer.c
b/drivers/hwmon/generic-pwm-tachometer.c
new file mode 100644
index 000..9354d43
--- /dev/null
+++ b/drivers/hwmon/generic-pwm-tachometer.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (c) 2017-2018, NVIDIA CORPORATION.  All rights
reserved.
+ *
+ * This program is free software; you can redistribute it
and/or modify it
+ * under the terms and conditions of the GNU General Public
License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful,
but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General
Public License for
+ * more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct pwm_hwmon_tach {
+struct device*dev;
+struct pwm_device*pwm;
+struct device*hwmon;
+};
+
+static ssize_t show_rpm(struct device *dev, struct
device_attribute *attr,
+char *buf)
+{
+struct pwm_hwmon_tach *ptt = dev_get_drvdata(dev);
+struct pwm_device *pwm = ptt->pwm;
+struct pwm_capture result;
+int err;
+unsigned int rpm = 0;
+
+err = pwm_capture(pwm, , 0);
+if (err < 0) {
+dev_err(ptt->dev, "Failed to capture PWM: %d\n", err);
+return err;
+}
+
+if (result.period)
+rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
+result.period);
+
+return sprintf(buf, "%u\n", rpm);
+}
+
+static SENSOR_DEVICE_ATTR(rpm, 0444, show_rpm, NULL, 0);

Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

2018-03-07 Thread Mikko Perttunen



On 07.03.2018 16:20, Guenter Roeck wrote:

On 03/07/2018 01:47 AM, Rajkumar Rampelli wrote:



On Wednesday 28 February 2018 07:59 PM, Guenter Roeck wrote:

On 02/27/2018 11:03 PM, Mikko Perttunen wrote:

On 02/28/2018 08:12 AM, Rajkumar Rampelli wrote:


On Wednesday 28 February 2018 11:28 AM, Guenter Roeck wrote:

On 02/27/2018 09:38 PM, Rajkumar Rampelli wrote:


On Wednesday 21 February 2018 08:20 PM, Guenter Roeck wrote:

On 02/20/2018 10:58 PM, Rajkumar Rampelli wrote:

Add generic PWM based tachometer driver via HWMON interface
to report the RPM of motor. This drivers get the period/duty
cycle from PWM IP which captures the motor PWM output.

This driver implements a simple interface for monitoring the
speed of
a fan and exposes it in roatations per minute (RPM) to the user
space
by using the hwmon's sysfs interface

Signed-off-by: Rajkumar Rampelli 
---
  Documentation/hwmon/generic-pwm-tachometer |  17 +
  drivers/hwmon/Kconfig  |  10 +++
  drivers/hwmon/Makefile |   1 +
  drivers/hwmon/generic-pwm-tachometer.c | 112
+
  4 files changed, 140 insertions(+)
  create mode 100644 Documentation/hwmon/generic-pwm-tachometer
  create mode 100644 drivers/hwmon/generic-pwm-tachometer.c

diff --git a/Documentation/hwmon/generic-pwm-tachometer
b/Documentation/hwmon/generic-pwm-tachometer
new file mode 100644
index 000..e0713ee
--- /dev/null
+++ b/Documentation/hwmon/generic-pwm-tachometer
@@ -0,0 +1,17 @@
+Kernel driver generic-pwm-tachometer
+
+
+This driver enables the use of a PWM module to monitor a fan.
It uses the
+generic PWM interface and can be used on SoCs as along as the
SoC supports
+Tachometer controller that moniors the Fan speed in periods.
+
+Author: Rajkumar Rampelli 
+
+Description
+---
+
+The driver implements a simple interface for monitoring the
Fan speed using
+PWM module and Tachometer controller. It requests period value
through PWM
+capture interface to Tachometer and measures the Rotations per
minute using
+received period value. It exposes the Fan speed in RPM to the
user space by
+using the hwmon's sysfs interface.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ef23553..8912dcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1878,6 +1878,16 @@ config SENSORS_XGENE
If you say yes here you get support for the temperature
and power sensors for APM X-Gene SoC.
  +config GENERIC_PWM_TACHOMETER
+tristate "Generic PWM based tachometer driver"
+depends on PWM
+help
+  Enables a driver to use PWM signal from motor to use
+  for measuring the motor speed. The RPM is captured by
+  PWM modules which has PWM capture capability and this
+  drivers reads the captured data from PWM IP to convert
+  it to speed in RPM.
+
  if ACPI
comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index f814b4a..9dcc374 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_SENSORS_WM8350)+=
wm8350-hwmon.o
  obj-$(CONFIG_SENSORS_XGENE)+= xgene-hwmon.o
obj-$(CONFIG_PMBUS)+= pmbus/
+obj-$(CONFIG_GENERIC_PWM_TACHOMETER) += generic-pwm-tachometer.o
ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
  diff --git a/drivers/hwmon/generic-pwm-tachometer.c
b/drivers/hwmon/generic-pwm-tachometer.c
new file mode 100644
index 000..9354d43
--- /dev/null
+++ b/drivers/hwmon/generic-pwm-tachometer.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (c) 2017-2018, NVIDIA CORPORATION.  All rights
reserved.
+ *
+ * This program is free software; you can redistribute it
and/or modify it
+ * under the terms and conditions of the GNU General Public
License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful,
but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General
Public License for
+ * more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct pwm_hwmon_tach {
+struct device*dev;
+struct pwm_device*pwm;
+struct device*hwmon;
+};
+
+static ssize_t show_rpm(struct device *dev, struct
device_attribute *attr,
+char *buf)
+{
+struct pwm_hwmon_tach *ptt = dev_get_drvdata(dev);
+struct pwm_device *pwm = ptt->pwm;
+struct pwm_capture result;
+int err;
+unsigned int rpm = 0;
+
+err = pwm_capture(pwm, , 0);
+if (err < 0) {
+dev_err(ptt->dev, "Failed to capture PWM: %d\n", err);
+return err;
+}
+
+if (result.period)
+rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
+result.period);
+
+return sprintf(buf, "%u\n", rpm);
+}
+
+static SENSOR_DEVICE_ATTR(rpm, 0444, show_rpm, NULL, 0);
+
+static struct attribute 

Re: [PATCH v12 3/6] PCI/PORTDRV: Implement generic find service

2018-03-07 Thread poza

On 2018-03-06 19:32, Sinan Kaya wrote:

On 2/28/2018 12:04 PM, Oza Pawandeep wrote:
+struct pcie_port_service_driver *pcie_port_find_service(struct 
pci_dev *dev,

+   u32 service)
+{
+   struct pcie_port_service_driver *drv = NULL;


Remove initialization


+   struct portdrv_service_data pdrvs;
+
+   pdrvs.service = service;


initialize pdrvs.drv = NULL here.


good point, will take care of this. [along with other comments if any]


+   device_for_each_child(>dev, , find_service_iter);
+
+   drv = pdrvs.drv;
+   return drv;
+}


Re: [PATCH v12 3/6] PCI/PORTDRV: Implement generic find service

2018-03-07 Thread poza

On 2018-03-06 19:32, Sinan Kaya wrote:

On 2/28/2018 12:04 PM, Oza Pawandeep wrote:
+struct pcie_port_service_driver *pcie_port_find_service(struct 
pci_dev *dev,

+   u32 service)
+{
+   struct pcie_port_service_driver *drv = NULL;


Remove initialization


+   struct portdrv_service_data pdrvs;
+
+   pdrvs.service = service;


initialize pdrvs.drv = NULL here.


good point, will take care of this. [along with other comments if any]


+   device_for_each_child(>dev, , find_service_iter);
+
+   drv = pdrvs.drv;
+   return drv;
+}


[tip:x86/pti] x86/vsyscall/64: Drop "native" vsyscalls

2018-03-07 Thread tip-bot for Andy Lutomirski
Commit-ID:  076ca272a14cea558b1092ec85cea08510283f2a
Gitweb: https://git.kernel.org/tip/076ca272a14cea558b1092ec85cea08510283f2a
Author: Andy Lutomirski 
AuthorDate: Wed, 7 Mar 2018 11:12:27 -0800
Committer:  Ingo Molnar 
CommitDate: Thu, 8 Mar 2018 06:48:15 +0100

x86/vsyscall/64: Drop "native" vsyscalls

Since Linux v3.2, vsyscalls have been deprecated and slow.  From v3.2
on, Linux had three vsyscall modes: "native", "emulate", and "none".

"emulate" is the default.  All known user programs work correctly in
emulate mode, but vsyscalls turn into page faults and are emulated.
This is very slow.  In "native" mode, the vsyscall page is easily
usable as an exploit gadget, but vsyscalls are a bit faster -- they
turn into normal syscalls.  (This is in contrast to vDSO functions,
which can be much faster than syscalls.)  In "none" mode, there are
no vsyscalls.

For all practical purposes, "native" was really just a chicken bit
in case something went wrong with the emulation.  It's been over six
years, and nothing has gone wrong.  Delete it.

Signed-off-by: Andy Lutomirski 
Acked-by: Kees Cook 
Acked-by: Linus Torvalds 
Cc: Borislav Petkov 
Cc: Dominik Brodowski 
Cc: Kernel Hardening 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/519fee5268faea09ae550776ce969fa6e88668b0.1520449896.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/Kconfig| 11 +--
 arch/x86/entry/vsyscall/vsyscall_64.c   | 16 +++-
 arch/x86/include/asm/pgtable_types.h|  2 --
 tools/testing/selftests/x86/test_vsyscall.c | 11 ++-
 4 files changed, 10 insertions(+), 30 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c1aed6c0e413..09c599e0900d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2266,7 +2266,7 @@ choice
  it can be used to assist security vulnerability exploitation.
 
  This setting can be changed at boot time via the kernel command
- line parameter vsyscall=[native|emulate|none].
+ line parameter vsyscall=[emulate|none].
 
  On a system with recent enough glibc (2.14 or newer) and no
  static binaries, you can say None without a performance penalty
@@ -2274,15 +2274,6 @@ choice
 
  If unsure, select "Emulate".
 
-   config LEGACY_VSYSCALL_NATIVE
-   bool "Native"
-   help
- Actual executable code is located in the fixed vsyscall
- address mapping, implementing time() efficiently. Since
- this makes the mapping executable, it can be used during
- security vulnerability exploitation (traditionally as
- ROP gadgets). This configuration is not recommended.
-
config LEGACY_VSYSCALL_EMULATE
bool "Emulate"
help
diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c 
b/arch/x86/entry/vsyscall/vsyscall_64.c
index 577fa8adb785..8560ef68a9d6 100644
--- a/arch/x86/entry/vsyscall/vsyscall_64.c
+++ b/arch/x86/entry/vsyscall/vsyscall_64.c
@@ -42,10 +42,8 @@
 #define CREATE_TRACE_POINTS
 #include "vsyscall_trace.h"
 
-static enum { EMULATE, NATIVE, NONE } vsyscall_mode =
-#if defined(CONFIG_LEGACY_VSYSCALL_NATIVE)
-   NATIVE;
-#elif defined(CONFIG_LEGACY_VSYSCALL_NONE)
+static enum { EMULATE, NONE } vsyscall_mode =
+#ifdef CONFIG_LEGACY_VSYSCALL_NONE
NONE;
 #else
EMULATE;
@@ -56,8 +54,6 @@ static int __init vsyscall_setup(char *str)
if (str) {
if (!strcmp("emulate", str))
vsyscall_mode = EMULATE;
-   else if (!strcmp("native", str))
-   vsyscall_mode = NATIVE;
else if (!strcmp("none", str))
vsyscall_mode = NONE;
else
@@ -139,10 +135,6 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned long 
address)
 
WARN_ON_ONCE(address != regs->ip);
 
-   /* This should be unreachable in NATIVE mode. */
-   if (WARN_ON(vsyscall_mode == NATIVE))
-   return false;
-
if (vsyscall_mode == NONE) {
warn_bad_vsyscall(KERN_INFO, regs,
  "vsyscall attempted with vsyscall=none");
@@ -370,9 +362,7 @@ void __init map_vsyscall(void)
 
if (vsyscall_mode != NONE) {
__set_fixmap(VSYSCALL_PAGE, physaddr_vsyscall,
-vsyscall_mode == NATIVE
-? PAGE_KERNEL_VSYSCALL
-: PAGE_KERNEL_VVAR);
+PAGE_KERNEL_VVAR);
set_vsyscall_pgtable_user_bits(swapper_pg_dir);
}
 
diff --git a/arch/x86/include/asm/pgtable_types.h 

[tip:x86/pti] x86/vsyscall/64: Drop "native" vsyscalls

2018-03-07 Thread tip-bot for Andy Lutomirski
Commit-ID:  076ca272a14cea558b1092ec85cea08510283f2a
Gitweb: https://git.kernel.org/tip/076ca272a14cea558b1092ec85cea08510283f2a
Author: Andy Lutomirski 
AuthorDate: Wed, 7 Mar 2018 11:12:27 -0800
Committer:  Ingo Molnar 
CommitDate: Thu, 8 Mar 2018 06:48:15 +0100

x86/vsyscall/64: Drop "native" vsyscalls

Since Linux v3.2, vsyscalls have been deprecated and slow.  From v3.2
on, Linux had three vsyscall modes: "native", "emulate", and "none".

"emulate" is the default.  All known user programs work correctly in
emulate mode, but vsyscalls turn into page faults and are emulated.
This is very slow.  In "native" mode, the vsyscall page is easily
usable as an exploit gadget, but vsyscalls are a bit faster -- they
turn into normal syscalls.  (This is in contrast to vDSO functions,
which can be much faster than syscalls.)  In "none" mode, there are
no vsyscalls.

For all practical purposes, "native" was really just a chicken bit
in case something went wrong with the emulation.  It's been over six
years, and nothing has gone wrong.  Delete it.

Signed-off-by: Andy Lutomirski 
Acked-by: Kees Cook 
Acked-by: Linus Torvalds 
Cc: Borislav Petkov 
Cc: Dominik Brodowski 
Cc: Kernel Hardening 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/519fee5268faea09ae550776ce969fa6e88668b0.1520449896.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/Kconfig| 11 +--
 arch/x86/entry/vsyscall/vsyscall_64.c   | 16 +++-
 arch/x86/include/asm/pgtable_types.h|  2 --
 tools/testing/selftests/x86/test_vsyscall.c | 11 ++-
 4 files changed, 10 insertions(+), 30 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c1aed6c0e413..09c599e0900d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2266,7 +2266,7 @@ choice
  it can be used to assist security vulnerability exploitation.
 
  This setting can be changed at boot time via the kernel command
- line parameter vsyscall=[native|emulate|none].
+ line parameter vsyscall=[emulate|none].
 
  On a system with recent enough glibc (2.14 or newer) and no
  static binaries, you can say None without a performance penalty
@@ -2274,15 +2274,6 @@ choice
 
  If unsure, select "Emulate".
 
-   config LEGACY_VSYSCALL_NATIVE
-   bool "Native"
-   help
- Actual executable code is located in the fixed vsyscall
- address mapping, implementing time() efficiently. Since
- this makes the mapping executable, it can be used during
- security vulnerability exploitation (traditionally as
- ROP gadgets). This configuration is not recommended.
-
config LEGACY_VSYSCALL_EMULATE
bool "Emulate"
help
diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c 
b/arch/x86/entry/vsyscall/vsyscall_64.c
index 577fa8adb785..8560ef68a9d6 100644
--- a/arch/x86/entry/vsyscall/vsyscall_64.c
+++ b/arch/x86/entry/vsyscall/vsyscall_64.c
@@ -42,10 +42,8 @@
 #define CREATE_TRACE_POINTS
 #include "vsyscall_trace.h"
 
-static enum { EMULATE, NATIVE, NONE } vsyscall_mode =
-#if defined(CONFIG_LEGACY_VSYSCALL_NATIVE)
-   NATIVE;
-#elif defined(CONFIG_LEGACY_VSYSCALL_NONE)
+static enum { EMULATE, NONE } vsyscall_mode =
+#ifdef CONFIG_LEGACY_VSYSCALL_NONE
NONE;
 #else
EMULATE;
@@ -56,8 +54,6 @@ static int __init vsyscall_setup(char *str)
if (str) {
if (!strcmp("emulate", str))
vsyscall_mode = EMULATE;
-   else if (!strcmp("native", str))
-   vsyscall_mode = NATIVE;
else if (!strcmp("none", str))
vsyscall_mode = NONE;
else
@@ -139,10 +135,6 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned long 
address)
 
WARN_ON_ONCE(address != regs->ip);
 
-   /* This should be unreachable in NATIVE mode. */
-   if (WARN_ON(vsyscall_mode == NATIVE))
-   return false;
-
if (vsyscall_mode == NONE) {
warn_bad_vsyscall(KERN_INFO, regs,
  "vsyscall attempted with vsyscall=none");
@@ -370,9 +362,7 @@ void __init map_vsyscall(void)
 
if (vsyscall_mode != NONE) {
__set_fixmap(VSYSCALL_PAGE, physaddr_vsyscall,
-vsyscall_mode == NATIVE
-? PAGE_KERNEL_VSYSCALL
-: PAGE_KERNEL_VVAR);
+PAGE_KERNEL_VVAR);
set_vsyscall_pgtable_user_bits(swapper_pg_dir);
}
 
diff --git a/arch/x86/include/asm/pgtable_types.h 
b/arch/x86/include/asm/pgtable_types.h
index 246f15b4e64c..acfe755562a6 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -174,7 +174,6 @@ enum page_cache_mode {
 #define __PAGE_KERNEL_RO   

Re: [PATCH V2 3/5] genirq/affinity: move actual irq vector spread into one helper

2018-03-07 Thread Christoph Hellwig
Can you fix this up and resend?

On Tue, Mar 06, 2018 at 12:28:32AM +0800, kbuild test robot wrote:
> Hi Ming,
> 
> Thank you for the patch! Perhaps something to improve:
> 
> [auto build test WARNING on tip/irq/core]
> [also build test WARNING on v4.16-rc4 next-20180305]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Ming-Lei/genirq-affinity-irq-vector-spread-among-online-CPUs-as-far-as-possible/20180305-184912
> config: i386-randconfig-a1-201809 (attached as .config)
> compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All warnings (new ones prefixed by >>):
> 
>kernel/irq/affinity.c: In function 'irq_create_affinity_masks':
> >> kernel/irq/affinity.c:201:50: warning: passing argument 3 of 
> >> 'irq_build_affinity_masks' from incompatible pointer type
>  curvec += irq_build_affinity_masks(nvecs, affd, node_to_cpumask,
>  ^
>kernel/irq/affinity.c:97:12: note: expected 'const struct cpumask (*)[1]' 
> but argument is of type 'struct cpumask (*)[1]'
> static int irq_build_affinity_masks(int nvecs, const struct irq_affinity 
> *affd,
>^
> 
> vim +/irq_build_affinity_masks +201 kernel/irq/affinity.c
> 
>161
>162/**
>163 * irq_create_affinity_masks - Create affinity masks for 
> multiqueue spreading
>164 * @nvecs:  The total number of vectors
>165 * @affd:   Description of the affinity requirements
>166 *
>167 * Returns the masks pointer or NULL if allocation failed.
>168 */
>169struct cpumask *
>170irq_create_affinity_masks(int nvecs, const struct irq_affinity 
> *affd)
>171{
>172int curvec;
>173struct cpumask *masks;
>174cpumask_var_t nmsk, *node_to_cpumask;
>175
>176/*
>177 * If there aren't any vectors left after applying the 
> pre/post
>178 * vectors don't bother with assigning affinity.
>179 */
>180if (nvecs == affd->pre_vectors + affd->post_vectors)
>181return NULL;
>182
>183if (!zalloc_cpumask_var(, GFP_KERNEL))
>184return NULL;
>185
>186masks = kcalloc(nvecs, sizeof(*masks), GFP_KERNEL);
>187if (!masks)
>188goto out;
>189
>190node_to_cpumask = alloc_node_to_cpumask();
>191if (!node_to_cpumask)
>192goto out;
>193
>194/* Fill out vectors at the beginning that don't need 
> affinity */
>195for (curvec = 0; curvec < affd->pre_vectors; curvec++)
>196cpumask_copy(masks + curvec, 
> irq_default_affinity);
>197
>198/* Stabilize the cpumasks */
>199get_online_cpus();
>200build_node_to_cpumask(node_to_cpumask);
>  > 201curvec += irq_build_affinity_masks(nvecs, affd, 
> node_to_cpumask,
>202   cpu_possible_mask, 
> nmsk, masks);
>203put_online_cpus();
>204
>205/* Fill out vectors at the end that don't need affinity 
> */
>206for (; curvec < nvecs; curvec++)
>207cpumask_copy(masks + curvec, 
> irq_default_affinity);
>208free_node_to_cpumask(node_to_cpumask);
>209out:
>210free_cpumask_var(nmsk);
>211return masks;
>212}
>213
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation


---end quoted text---


Re: [PATCH V2 3/5] genirq/affinity: move actual irq vector spread into one helper

2018-03-07 Thread Christoph Hellwig
Can you fix this up and resend?

On Tue, Mar 06, 2018 at 12:28:32AM +0800, kbuild test robot wrote:
> Hi Ming,
> 
> Thank you for the patch! Perhaps something to improve:
> 
> [auto build test WARNING on tip/irq/core]
> [also build test WARNING on v4.16-rc4 next-20180305]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Ming-Lei/genirq-affinity-irq-vector-spread-among-online-CPUs-as-far-as-possible/20180305-184912
> config: i386-randconfig-a1-201809 (attached as .config)
> compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All warnings (new ones prefixed by >>):
> 
>kernel/irq/affinity.c: In function 'irq_create_affinity_masks':
> >> kernel/irq/affinity.c:201:50: warning: passing argument 3 of 
> >> 'irq_build_affinity_masks' from incompatible pointer type
>  curvec += irq_build_affinity_masks(nvecs, affd, node_to_cpumask,
>  ^
>kernel/irq/affinity.c:97:12: note: expected 'const struct cpumask (*)[1]' 
> but argument is of type 'struct cpumask (*)[1]'
> static int irq_build_affinity_masks(int nvecs, const struct irq_affinity 
> *affd,
>^
> 
> vim +/irq_build_affinity_masks +201 kernel/irq/affinity.c
> 
>161
>162/**
>163 * irq_create_affinity_masks - Create affinity masks for 
> multiqueue spreading
>164 * @nvecs:  The total number of vectors
>165 * @affd:   Description of the affinity requirements
>166 *
>167 * Returns the masks pointer or NULL if allocation failed.
>168 */
>169struct cpumask *
>170irq_create_affinity_masks(int nvecs, const struct irq_affinity 
> *affd)
>171{
>172int curvec;
>173struct cpumask *masks;
>174cpumask_var_t nmsk, *node_to_cpumask;
>175
>176/*
>177 * If there aren't any vectors left after applying the 
> pre/post
>178 * vectors don't bother with assigning affinity.
>179 */
>180if (nvecs == affd->pre_vectors + affd->post_vectors)
>181return NULL;
>182
>183if (!zalloc_cpumask_var(, GFP_KERNEL))
>184return NULL;
>185
>186masks = kcalloc(nvecs, sizeof(*masks), GFP_KERNEL);
>187if (!masks)
>188goto out;
>189
>190node_to_cpumask = alloc_node_to_cpumask();
>191if (!node_to_cpumask)
>192goto out;
>193
>194/* Fill out vectors at the beginning that don't need 
> affinity */
>195for (curvec = 0; curvec < affd->pre_vectors; curvec++)
>196cpumask_copy(masks + curvec, 
> irq_default_affinity);
>197
>198/* Stabilize the cpumasks */
>199get_online_cpus();
>200build_node_to_cpumask(node_to_cpumask);
>  > 201curvec += irq_build_affinity_masks(nvecs, affd, 
> node_to_cpumask,
>202   cpu_possible_mask, 
> nmsk, masks);
>203put_online_cpus();
>204
>205/* Fill out vectors at the end that don't need affinity 
> */
>206for (; curvec < nvecs; curvec++)
>207cpumask_copy(masks + curvec, 
> irq_default_affinity);
>208free_node_to_cpumask(node_to_cpumask);
>209out:
>210free_cpumask_var(nmsk);
>211return masks;
>212}
>213
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation


---end quoted text---


Re: [PATCH v2 1/2] dt-bindings: watchdog: Add Nuvoton NPCM description

2018-03-07 Thread Tomer Maimon
On 5 March 2018 at 13:45, Joel Stanley  wrote:
> These bindings describe the watchdog IP as used by the Nuvoton NPCM750
> (Poleg) BMC SoC.
>
> Signed-off-by: Joel Stanley 
> ---
> V2: Add optional timeout property
> ---
>  .../bindings/watchdog/nuvoton,npcm-wdt.txt | 28 
> ++
>  1 file changed, 28 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt 
> b/Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt
> new file mode 100644
> index ..615eacd0b9d6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt
> @@ -0,0 +1,28 @@
> +Nuvoton NPCM Watchdog
> +
> +Nuvoton NPCM timer module provides five 24-bit timer counters, and a 
> watchdog.
> +The watchdog supports a pre-timeout interrupt that fires 10ms before the
> +expiry.
> +
> +Required properties:
> +- compatible  : "nuvoton,npcm750-wdt" for NPCM750 (Poleg).
> +- reg : Offset and length of the register set for the device.
> +- interrupts  : Contain the timer interrupt with flags for
> +falling edge.
> +
> +Required clocking property, have to be one of:
> +- clocks  : phandle of timer reference clock.
> +- clock-frequency : The frequency in Hz of the clock that drives the NPCM7xx
> +timer (usually 2500).
> +
> +Optional properties:
> +- timeout-sec : Contains the watchdog timeout in seconds
> +
> +Example:
> +
> +timer@f00080c1 {
Little address mistake, suppose to be f000801c
> +compatible = "nuvoton,npcm750-wdt";
> +interrupts = ;
> +reg = <0xf00080c1 0x4>;
Little address mistake, suppose to be  0xf000801c
> +clocks = < NPCM7XX_CLK_TIMER>;
> +};
> --
> 2.15.1
>


Re: [PATCH v2 1/2] dt-bindings: watchdog: Add Nuvoton NPCM description

2018-03-07 Thread Tomer Maimon
On 5 March 2018 at 13:45, Joel Stanley  wrote:
> These bindings describe the watchdog IP as used by the Nuvoton NPCM750
> (Poleg) BMC SoC.
>
> Signed-off-by: Joel Stanley 
> ---
> V2: Add optional timeout property
> ---
>  .../bindings/watchdog/nuvoton,npcm-wdt.txt | 28 
> ++
>  1 file changed, 28 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt 
> b/Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt
> new file mode 100644
> index ..615eacd0b9d6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt
> @@ -0,0 +1,28 @@
> +Nuvoton NPCM Watchdog
> +
> +Nuvoton NPCM timer module provides five 24-bit timer counters, and a 
> watchdog.
> +The watchdog supports a pre-timeout interrupt that fires 10ms before the
> +expiry.
> +
> +Required properties:
> +- compatible  : "nuvoton,npcm750-wdt" for NPCM750 (Poleg).
> +- reg : Offset and length of the register set for the device.
> +- interrupts  : Contain the timer interrupt with flags for
> +falling edge.
> +
> +Required clocking property, have to be one of:
> +- clocks  : phandle of timer reference clock.
> +- clock-frequency : The frequency in Hz of the clock that drives the NPCM7xx
> +timer (usually 2500).
> +
> +Optional properties:
> +- timeout-sec : Contains the watchdog timeout in seconds
> +
> +Example:
> +
> +timer@f00080c1 {
Little address mistake, suppose to be f000801c
> +compatible = "nuvoton,npcm750-wdt";
> +interrupts = ;
> +reg = <0xf00080c1 0x4>;
Little address mistake, suppose to be  0xf000801c
> +clocks = < NPCM7XX_CLK_TIMER>;
> +};
> --
> 2.15.1
>


[PATCH v5 3/3] arm64: dts: rockchip: kevin: Avoid wakeup when inserting the pen

2018-03-07 Thread Jeffy Chen
Add wakeup event action for Pen Insert gpio key, to avoid wakeup when
inserting the pen.

Signed-off-by: Jeffy Chen 
Tested-by: Enric Balletbo i Serra 
---

Changes in v5: None
Changes in v4:
Include dt-binding gpio-keys.h

Changes in v3: None
Changes in v2:
Specify wakeup event action instead of irq trigger type as Brian
suggested.

 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
index 191a6bcb1704..89126dbe5d91 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -44,6 +44,7 @@
 
 /dts-v1/;
 #include "rk3399-gru.dtsi"
+#include 
 #include 
 
 /*
@@ -134,6 +135,8 @@
gpios = < 13 GPIO_ACTIVE_LOW>;
linux,code = ;
linux,input-type = ;
+   /* Wakeup only when ejecting */
+   wakeup-event-action = ;
wakeup-source;
};
 };
-- 
2.11.0




[PATCH v5 3/3] arm64: dts: rockchip: kevin: Avoid wakeup when inserting the pen

2018-03-07 Thread Jeffy Chen
Add wakeup event action for Pen Insert gpio key, to avoid wakeup when
inserting the pen.

Signed-off-by: Jeffy Chen 
Tested-by: Enric Balletbo i Serra 
---

Changes in v5: None
Changes in v4:
Include dt-binding gpio-keys.h

Changes in v3: None
Changes in v2:
Specify wakeup event action instead of irq trigger type as Brian
suggested.

 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
index 191a6bcb1704..89126dbe5d91 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -44,6 +44,7 @@
 
 /dts-v1/;
 #include "rk3399-gru.dtsi"
+#include 
 #include 
 
 /*
@@ -134,6 +135,8 @@
gpios = < 13 GPIO_ACTIVE_LOW>;
linux,code = ;
linux,input-type = ;
+   /* Wakeup only when ejecting */
+   wakeup-event-action = ;
wakeup-source;
};
 };
-- 
2.11.0




Re: [PATCH V2 1/3] x86/efi: Call efi_delete_dummy_variable() during efi subsystem initialization

2018-03-07 Thread Ard Biesheuvel
Hello Sai,

On 5 March 2018 at 23:23, Sai Praneeth Prakhya
 wrote:
> From: Sai Praneeth 
>
> Invoking efi_runtime_services() through efi_workqueue means all accesses
> to efi_runtime_services() should be done after efi_rts_wq has been
> created. efi_delete_dummy_variable() calls set_variable(), hence
> efi_delete_dummy_variable() should be called after efi_rts_wq has been
> created.
>
> efi_delete_dummy_variable() is called from efi_enter_virtual_mode()
> which is early in the boot phase (efi_rts_wq isn't created yet), so call
> efi_delete_dummy_variable() later in the boot phase i.e. while
> initializing efi subsystem. In the next patch, this is the place where
> we create efi_rts_wq and all the efi_runtime_services() will be called
> using efi_rts_wq.
>
> Signed-off-by: Sai Praneeth Prakhya 
> Suggested-by: Andy Lutomirski 
> Cc: Lee, Chun-Yi 
> Cc: Borislav Petkov 
> Cc: Tony Luck 
> Cc: Will Deacon 
> Cc: Dave Hansen 
> Cc: Mark Rutland 
> Cc: Bhupesh Sharma 
> Cc: Ricardo Neri 
> Cc: Ravi Shankar 
> Cc: Matt Fleming 
> Cc: Peter Zijlstra 
> Cc: Ard Biesheuvel 
> Cc: Dan Williams 
> ---
>  arch/x86/include/asm/efi.h  | 1 -
>  arch/x86/platform/efi/efi.c | 6 --
>  drivers/firmware/efi/efi.c  | 6 ++
>  include/linux/efi.h | 3 +++
>  4 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
> index a399c1ebf6f0..43009e3f821b 100644
> --- a/arch/x86/include/asm/efi.h
> +++ b/arch/x86/include/asm/efi.h
> @@ -143,7 +143,6 @@ extern void __init efi_runtime_update_mappings(void);
>  extern void __init efi_dump_pagetable(void);
>  extern void __init efi_apply_memmap_quirks(void);
>  extern int __init efi_reuse_config(u64 tables, int nr_tables);
> -extern void efi_delete_dummy_variable(void);
>
>  struct efi_setup_data {
> u64 fw_vendor;
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 9061babfbc83..a3169d14583f 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -893,9 +893,6 @@ static void __init kexec_enter_virtual_mode(void)
>
> if (efi_enabled(EFI_OLD_MEMMAP) && (__supported_pte_mask & _PAGE_NX))
> runtime_code_page_mkexec();
> -
> -   /* clean DUMMY object */
> -   efi_delete_dummy_variable();
>  #endif
>  }
>
> @@ -1015,9 +1012,6 @@ static void __init __efi_enter_virtual_mode(void)
>  * necessary relocation fixups for the new virtual addresses.
>  */
> efi_runtime_update_mappings();
> -
> -   /* clean DUMMY object */
> -   efi_delete_dummy_variable();
>  }
>
>  void __init efi_enter_virtual_mode(void)
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index cd42f66a7c85..838b8efe639c 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -328,6 +328,12 @@ static int __init efisubsys_init(void)
> if (!efi_enabled(EFI_BOOT))
> return 0;
>
> +   /*
> +* Clean DUMMY object calls EFI Runtime Service, set_variable(), so
> +* it should be invoked only after efi_rts_workqueue is ready.
> +*/
> +   efi_delete_dummy_variable();
> +

Is there any way to keep this local to arch/x86?

> /* We register the efi directory at /sys/firmware/efi */
> efi_kobj = kobject_create_and_add("efi", firmware_kobj);
> if (!efi_kobj) {
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index f5083aa72eae..c4efb3ef0dfa 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -992,6 +992,7 @@ extern efi_status_t efi_query_variable_store(u32 
> attributes,
>  unsigned long size,
>  bool nonblocking);
>  extern void efi_find_mirror(void);
> +extern void efi_delete_dummy_variable(void);
>  #else
>  static inline void efi_late_init(void) {}
>  static inline void efi_free_boot_services(void) {}
> @@ -1002,6 +1003,8 @@ static inline efi_status_t efi_query_variable_store(u32 
> attributes,
>  {
> return EFI_SUCCESS;
>  }
> +
> +static inline void efi_delete_dummy_variable(void) {}
>  #endif
>  extern void __iomem *efi_lookup_mapped_addr(u64 phys_addr);
>
> --
> 2.7.4
>


Re: [PATCH V2 1/3] x86/efi: Call efi_delete_dummy_variable() during efi subsystem initialization

2018-03-07 Thread Ard Biesheuvel
Hello Sai,

On 5 March 2018 at 23:23, Sai Praneeth Prakhya
 wrote:
> From: Sai Praneeth 
>
> Invoking efi_runtime_services() through efi_workqueue means all accesses
> to efi_runtime_services() should be done after efi_rts_wq has been
> created. efi_delete_dummy_variable() calls set_variable(), hence
> efi_delete_dummy_variable() should be called after efi_rts_wq has been
> created.
>
> efi_delete_dummy_variable() is called from efi_enter_virtual_mode()
> which is early in the boot phase (efi_rts_wq isn't created yet), so call
> efi_delete_dummy_variable() later in the boot phase i.e. while
> initializing efi subsystem. In the next patch, this is the place where
> we create efi_rts_wq and all the efi_runtime_services() will be called
> using efi_rts_wq.
>
> Signed-off-by: Sai Praneeth Prakhya 
> Suggested-by: Andy Lutomirski 
> Cc: Lee, Chun-Yi 
> Cc: Borislav Petkov 
> Cc: Tony Luck 
> Cc: Will Deacon 
> Cc: Dave Hansen 
> Cc: Mark Rutland 
> Cc: Bhupesh Sharma 
> Cc: Ricardo Neri 
> Cc: Ravi Shankar 
> Cc: Matt Fleming 
> Cc: Peter Zijlstra 
> Cc: Ard Biesheuvel 
> Cc: Dan Williams 
> ---
>  arch/x86/include/asm/efi.h  | 1 -
>  arch/x86/platform/efi/efi.c | 6 --
>  drivers/firmware/efi/efi.c  | 6 ++
>  include/linux/efi.h | 3 +++
>  4 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
> index a399c1ebf6f0..43009e3f821b 100644
> --- a/arch/x86/include/asm/efi.h
> +++ b/arch/x86/include/asm/efi.h
> @@ -143,7 +143,6 @@ extern void __init efi_runtime_update_mappings(void);
>  extern void __init efi_dump_pagetable(void);
>  extern void __init efi_apply_memmap_quirks(void);
>  extern int __init efi_reuse_config(u64 tables, int nr_tables);
> -extern void efi_delete_dummy_variable(void);
>
>  struct efi_setup_data {
> u64 fw_vendor;
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 9061babfbc83..a3169d14583f 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -893,9 +893,6 @@ static void __init kexec_enter_virtual_mode(void)
>
> if (efi_enabled(EFI_OLD_MEMMAP) && (__supported_pte_mask & _PAGE_NX))
> runtime_code_page_mkexec();
> -
> -   /* clean DUMMY object */
> -   efi_delete_dummy_variable();
>  #endif
>  }
>
> @@ -1015,9 +1012,6 @@ static void __init __efi_enter_virtual_mode(void)
>  * necessary relocation fixups for the new virtual addresses.
>  */
> efi_runtime_update_mappings();
> -
> -   /* clean DUMMY object */
> -   efi_delete_dummy_variable();
>  }
>
>  void __init efi_enter_virtual_mode(void)
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index cd42f66a7c85..838b8efe639c 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -328,6 +328,12 @@ static int __init efisubsys_init(void)
> if (!efi_enabled(EFI_BOOT))
> return 0;
>
> +   /*
> +* Clean DUMMY object calls EFI Runtime Service, set_variable(), so
> +* it should be invoked only after efi_rts_workqueue is ready.
> +*/
> +   efi_delete_dummy_variable();
> +

Is there any way to keep this local to arch/x86?

> /* We register the efi directory at /sys/firmware/efi */
> efi_kobj = kobject_create_and_add("efi", firmware_kobj);
> if (!efi_kobj) {
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index f5083aa72eae..c4efb3ef0dfa 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -992,6 +992,7 @@ extern efi_status_t efi_query_variable_store(u32 
> attributes,
>  unsigned long size,
>  bool nonblocking);
>  extern void efi_find_mirror(void);
> +extern void efi_delete_dummy_variable(void);
>  #else
>  static inline void efi_late_init(void) {}
>  static inline void efi_free_boot_services(void) {}
> @@ -1002,6 +1003,8 @@ static inline efi_status_t efi_query_variable_store(u32 
> attributes,
>  {
> return EFI_SUCCESS;
>  }
> +
> +static inline void efi_delete_dummy_variable(void) {}
>  #endif
>  extern void __iomem *efi_lookup_mapped_addr(u64 phys_addr);
>
> --
> 2.7.4
>


Re: [PATCH V2] nvme-pci: assign separate irq vectors for adminq and ioq0

2018-03-07 Thread Christoph Hellwig
On Thu, Mar 01, 2018 at 09:10:42AM -0700, Keith Busch wrote:
> On Thu, Mar 01, 2018 at 11:03:30PM +0800, Ming Lei wrote:
> > If all CPUs for the 1st IRQ vector of admin queue are offline, then I
> > guess NVMe can't work any more.
> 
> Yikes, with respect to admin commands, it appears you're right if your
> system allows offlining CPU0.
> 
> > So looks it is a good idea to make admin queue's IRQ vector assigned as
> > non-managed IRQs.
> 
> It'd still be considered managed even if it's a 'pre_vector', though
> it would get the default mask with all possible CPUs.

Which basically does the right thing.  So I suspect we'll need to
go with a patch like this, just with a way better changelog.


Re: [PATCH V2] nvme-pci: assign separate irq vectors for adminq and ioq0

2018-03-07 Thread Christoph Hellwig
On Thu, Mar 01, 2018 at 09:10:42AM -0700, Keith Busch wrote:
> On Thu, Mar 01, 2018 at 11:03:30PM +0800, Ming Lei wrote:
> > If all CPUs for the 1st IRQ vector of admin queue are offline, then I
> > guess NVMe can't work any more.
> 
> Yikes, with respect to admin commands, it appears you're right if your
> system allows offlining CPU0.
> 
> > So looks it is a good idea to make admin queue's IRQ vector assigned as
> > non-managed IRQs.
> 
> It'd still be considered managed even if it's a 'pre_vector', though
> it would get the default mask with all possible CPUs.

Which basically does the right thing.  So I suspect we'll need to
go with a patch like this, just with a way better changelog.


Re: [PATCH 5/6] dma-mapping: support fsl-mc bus

2018-03-07 Thread Christoph Hellwig
On Tue, Mar 06, 2018 at 04:41:56AM +, Nipun Gupta wrote:
> Sorry for asking a trivial question - looking into dma_configure() I see that
> PCI is used in the start and the end of the API.
> In the end part pci_put_host_bridge_device() is called.
> So are two bus callbacks something like 'dma_config_start' & 'dma_config_end'
> will be required where the former one will return "dma_dev"?

I'd just use dma_configure as the callback.

Currently the of_dma_configure and acpi_dma_configure are only used
for PCI anyway, as no one else sets a non-NULL dma dev.   For fsl-mc
I suspect only of_dma_configure is relevanet, so just call that directly.
If at some point we get enough busses with either OF or ACPI we could
create a helper called from ->dma_configure for that.


Re: [PATCH 5/6] dma-mapping: support fsl-mc bus

2018-03-07 Thread Christoph Hellwig
On Tue, Mar 06, 2018 at 04:41:56AM +, Nipun Gupta wrote:
> Sorry for asking a trivial question - looking into dma_configure() I see that
> PCI is used in the start and the end of the API.
> In the end part pci_put_host_bridge_device() is called.
> So are two bus callbacks something like 'dma_config_start' & 'dma_config_end'
> will be required where the former one will return "dma_dev"?

I'd just use dma_configure as the callback.

Currently the of_dma_configure and acpi_dma_configure are only used
for PCI anyway, as no one else sets a non-NULL dma dev.   For fsl-mc
I suspect only of_dma_configure is relevanet, so just call that directly.
If at some point we get enough busses with either OF or ACPI we could
create a helper called from ->dma_configure for that.


Re: [PATCH] fix compilation of 64-bit kernel with 32-bit compiler

2018-03-07 Thread Peter Zijlstra
On Thu, Mar 08, 2018 at 01:11:26AM -0500, Mikulas Patocka wrote:
> The patch b5bc2231b8ad4387c9641f235ca0ad8cd300b6df ("objtool: Add 
> retpoline validation") broke compiling 64-bit kernel with 32-bit compiler.
> 
> This patch fixes the following error and a large number of "can't find
> rela for retpoline_safe" errors that occur when using x32 or i386 gcc.
> 
> You shouldn't use the type 'unsigned long' in objtool at all - because its
> size depends on the compiler and not on the kernel you are compiling.

Your patch is wrong because the data field is actually a long. A correct
patch is already in merged in tip.


Re: [PATCH] fix compilation of 64-bit kernel with 32-bit compiler

2018-03-07 Thread Peter Zijlstra
On Thu, Mar 08, 2018 at 01:11:26AM -0500, Mikulas Patocka wrote:
> The patch b5bc2231b8ad4387c9641f235ca0ad8cd300b6df ("objtool: Add 
> retpoline validation") broke compiling 64-bit kernel with 32-bit compiler.
> 
> This patch fixes the following error and a large number of "can't find
> rela for retpoline_safe" errors that occur when using x32 or i386 gcc.
> 
> You shouldn't use the type 'unsigned long' in objtool at all - because its
> size depends on the compiler and not on the kernel you are compiling.

Your patch is wrong because the data field is actually a long. A correct
patch is already in merged in tip.


Re: [PATCH] net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()

2018-03-07 Thread Herbert Xu
On Wed, Mar 07, 2018 at 11:24:16AM -0800, Greg Hackmann wrote:
> f7c83bcbfaf5 ("net: xfrm: use __this_cpu_read per-cpu helper") added a
> __this_cpu_read() call inside ipcomp_alloc_tfms().  Since this call was
> introduced, the rules around per-cpu accessors have been tightened and
> __this_cpu_read() cannot be used in a preemptible context.
> 
> syzkaller reported this leading to the following kernel BUG while
> fuzzing sendmsg:

How about reverting f7c83bcbfaf5 instead?

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH] net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()

2018-03-07 Thread Herbert Xu
On Wed, Mar 07, 2018 at 11:24:16AM -0800, Greg Hackmann wrote:
> f7c83bcbfaf5 ("net: xfrm: use __this_cpu_read per-cpu helper") added a
> __this_cpu_read() call inside ipcomp_alloc_tfms().  Since this call was
> introduced, the rules around per-cpu accessors have been tightened and
> __this_cpu_read() cannot be used in a preemptible context.
> 
> syzkaller reported this leading to the following kernel BUG while
> fuzzing sendmsg:

How about reverting f7c83bcbfaf5 instead?

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


RE: [PATCH 2/2] platform/x86: dell-*: Add interface for switchable graphics status query

2018-03-07 Thread Mario.Limonciello
> -Original Message-
> From: Kai-Heng Feng [mailto:kai.heng.f...@canonical.com]
> Sent: Thursday, March 8, 2018 3:12 PM
> To: mj...@srcf.ucam.org; pali.ro...@gmail.com; dvh...@infradead.org;
> a...@infradead.org; Limonciello, Mario ;
> ti...@suse.com
> Cc: platform-driver-...@vger.kernel.org; linux-kernel@vger.kernel.org; alsa-
> de...@alsa-project.org; Kai-Heng Feng 
> Subject: [PATCH 2/2] platform/x86: dell-*: Add interface for switchable 
> graphics
> status query
> 
> On some Dell platforms, there's a BIOS option "Enable Switchable
> Graphics". This information is useful if we want to do different things
> based on this value, e.g. disable unused audio controller that comes
> with the discrete graphics.
> 

I was expecting the follow on patch that uses this interface too as part of the
series. This patch itself however looks like.

Reviewed-by: Mario Limonciello 
> Signed-off-by: Kai-Heng Feng 
> ---
>  drivers/platform/x86/dell-laptop.c | 23 +++
>  drivers/platform/x86/dell-smbios.c |  2 ++
>  drivers/platform/x86/dell-smbios.h |  2 ++
>  3 files changed, 27 insertions(+)
> 
> diff --git a/drivers/platform/x86/dell-laptop.c 
> b/drivers/platform/x86/dell-laptop.c
> index 8ba820e6c3d0..3f6fc07b8cf2 100644
> --- a/drivers/platform/x86/dell-laptop.c
> +++ b/drivers/platform/x86/dell-laptop.c
> @@ -2116,6 +2116,29 @@ int dell_micmute_led_set(int state)
>  }
>  EXPORT_SYMBOL_GPL(dell_micmute_led_set);
> 
> +int dell_switchable_gfx_enabled(bool *enabled)
> +{
> + struct calling_interface_buffer buffer;
> + struct calling_interface_token *token;
> + int ret;
> +
> + *enabled = false;
> +
> + token = dell_smbios_find_token(SWITCHABLE_GRAPHICS_ENABLE);
> + if (!token)
> + return -ENODEV;
> +
> + dell_fill_request(, token->location, 0, 0, 0);
> + ret = dell_send_request(, CLASS_TOKEN_READ,
> SELECT_TOKEN_STD);
> + if (ret)
> + return ret;
> +
> + *enabled = !!buffer.output[1];
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(dell_switchable_gfx_enabled);
> +
>  static int __init dell_init(void)
>  {
>   struct calling_interface_token *token;
> diff --git a/drivers/platform/x86/dell-smbios.c 
> b/drivers/platform/x86/dell-smbios.c
> index 8541cde4cb7d..ca38b9d9dcf4 100644
> --- a/drivers/platform/x86/dell-smbios.c
> +++ b/drivers/platform/x86/dell-smbios.c
> @@ -86,6 +86,8 @@ struct token_range {
>  static struct token_range token_whitelist[] = {
>   /* used by userspace: fwupdate */
>   {CAP_SYS_ADMIN, CAPSULE_EN_TOKEN,   CAPSULE_DIS_TOKEN},
> + /* can indicate to userspace Switchable Graphics enable status */
> + {CAP_SYS_ADMIN, SWITCHABLE_GRAPHICS_ENABLE,
>   SWITCHABLE_GRAPHICS_DISABLE},
>   /* can indicate to userspace that WMI is needed */
>   {0x,WSMT_EN_TOKEN,  WSMT_DIS_TOKEN}
>  };
> diff --git a/drivers/platform/x86/dell-smbios.h 
> b/drivers/platform/x86/dell-smbios.h
> index 138d478d9adc..b012d4abd239 100644
> --- a/drivers/platform/x86/dell-smbios.h
> +++ b/drivers/platform/x86/dell-smbios.h
> @@ -37,6 +37,8 @@
>  #define KBD_LED_AUTO_100_TOKEN   0x02F6
>  #define GLOBAL_MIC_MUTE_ENABLE   0x0364
>  #define GLOBAL_MIC_MUTE_DISABLE  0x0365
> +#define SWITCHABLE_GRAPHICS_ENABLE   0x037A
> +#define SWITCHABLE_GRAPHICS_DISABLE  0x037B
> 
>  struct notifier_block;
> 
> --
> 2.15.1



RE: [PATCH 2/2] platform/x86: dell-*: Add interface for switchable graphics status query

2018-03-07 Thread Mario.Limonciello
> -Original Message-
> From: Kai-Heng Feng [mailto:kai.heng.f...@canonical.com]
> Sent: Thursday, March 8, 2018 3:12 PM
> To: mj...@srcf.ucam.org; pali.ro...@gmail.com; dvh...@infradead.org;
> a...@infradead.org; Limonciello, Mario ;
> ti...@suse.com
> Cc: platform-driver-...@vger.kernel.org; linux-kernel@vger.kernel.org; alsa-
> de...@alsa-project.org; Kai-Heng Feng 
> Subject: [PATCH 2/2] platform/x86: dell-*: Add interface for switchable 
> graphics
> status query
> 
> On some Dell platforms, there's a BIOS option "Enable Switchable
> Graphics". This information is useful if we want to do different things
> based on this value, e.g. disable unused audio controller that comes
> with the discrete graphics.
> 

I was expecting the follow on patch that uses this interface too as part of the
series. This patch itself however looks like.

Reviewed-by: Mario Limonciello 
> Signed-off-by: Kai-Heng Feng 
> ---
>  drivers/platform/x86/dell-laptop.c | 23 +++
>  drivers/platform/x86/dell-smbios.c |  2 ++
>  drivers/platform/x86/dell-smbios.h |  2 ++
>  3 files changed, 27 insertions(+)
> 
> diff --git a/drivers/platform/x86/dell-laptop.c 
> b/drivers/platform/x86/dell-laptop.c
> index 8ba820e6c3d0..3f6fc07b8cf2 100644
> --- a/drivers/platform/x86/dell-laptop.c
> +++ b/drivers/platform/x86/dell-laptop.c
> @@ -2116,6 +2116,29 @@ int dell_micmute_led_set(int state)
>  }
>  EXPORT_SYMBOL_GPL(dell_micmute_led_set);
> 
> +int dell_switchable_gfx_enabled(bool *enabled)
> +{
> + struct calling_interface_buffer buffer;
> + struct calling_interface_token *token;
> + int ret;
> +
> + *enabled = false;
> +
> + token = dell_smbios_find_token(SWITCHABLE_GRAPHICS_ENABLE);
> + if (!token)
> + return -ENODEV;
> +
> + dell_fill_request(, token->location, 0, 0, 0);
> + ret = dell_send_request(, CLASS_TOKEN_READ,
> SELECT_TOKEN_STD);
> + if (ret)
> + return ret;
> +
> + *enabled = !!buffer.output[1];
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(dell_switchable_gfx_enabled);
> +
>  static int __init dell_init(void)
>  {
>   struct calling_interface_token *token;
> diff --git a/drivers/platform/x86/dell-smbios.c 
> b/drivers/platform/x86/dell-smbios.c
> index 8541cde4cb7d..ca38b9d9dcf4 100644
> --- a/drivers/platform/x86/dell-smbios.c
> +++ b/drivers/platform/x86/dell-smbios.c
> @@ -86,6 +86,8 @@ struct token_range {
>  static struct token_range token_whitelist[] = {
>   /* used by userspace: fwupdate */
>   {CAP_SYS_ADMIN, CAPSULE_EN_TOKEN,   CAPSULE_DIS_TOKEN},
> + /* can indicate to userspace Switchable Graphics enable status */
> + {CAP_SYS_ADMIN, SWITCHABLE_GRAPHICS_ENABLE,
>   SWITCHABLE_GRAPHICS_DISABLE},
>   /* can indicate to userspace that WMI is needed */
>   {0x,WSMT_EN_TOKEN,  WSMT_DIS_TOKEN}
>  };
> diff --git a/drivers/platform/x86/dell-smbios.h 
> b/drivers/platform/x86/dell-smbios.h
> index 138d478d9adc..b012d4abd239 100644
> --- a/drivers/platform/x86/dell-smbios.h
> +++ b/drivers/platform/x86/dell-smbios.h
> @@ -37,6 +37,8 @@
>  #define KBD_LED_AUTO_100_TOKEN   0x02F6
>  #define GLOBAL_MIC_MUTE_ENABLE   0x0364
>  #define GLOBAL_MIC_MUTE_DISABLE  0x0365
> +#define SWITCHABLE_GRAPHICS_ENABLE   0x037A
> +#define SWITCHABLE_GRAPHICS_DISABLE  0x037B
> 
>  struct notifier_block;
> 
> --
> 2.15.1



[PATCH v5 1/3] Input: gpio-keys - add support for wakeup event action

2018-03-07 Thread Jeffy Chen
Add support for specifying event actions to trigger wakeup when using
the gpio-keys input device as a wakeup source.

This would allow the device to configure when to wakeup the system. For
example a gpio-keys input device for pen insert, may only want to wakeup
the system when ejecting the pen.

Suggested-by: Brian Norris 
Signed-off-by: Jeffy Chen 
---

Changes in v5:
Remove unneeded irq_wake flag as Andy suggested.

Changes in v4:
Add dt-binding gpio-keys.h, stop saving irq trigger type, add enable/disable 
wakeup helpers as Dmitry suggested.

Changes in v3:
Adding more comments as Brian suggested.

Changes in v2:
Specify wakeup event action instead of irq trigger type as Brian
suggested.

 drivers/input/keyboard/gpio_keys.c| 63 +--
 include/dt-bindings/input/gpio-keys.h | 13 
 include/linux/gpio_keys.h |  2 ++
 3 files changed, 75 insertions(+), 3 deletions(-)
 create mode 100644 include/dt-bindings/input/gpio-keys.h

diff --git a/drivers/input/keyboard/gpio_keys.c 
b/drivers/input/keyboard/gpio_keys.c
index 87e613dc33b8..f6d5cfd44833 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct gpio_button_data {
const struct gpio_keys_button *button;
@@ -45,6 +46,7 @@ struct gpio_button_data {
unsigned int software_debounce; /* in msecs, for GPIO-driven buttons */
 
unsigned int irq;
+   unsigned int wakeup_trigger_type;
spinlock_t lock;
bool disabled;
bool key_pressed;
@@ -540,6 +542,8 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
}
 
if (bdata->gpiod) {
+   int active_low = gpiod_is_active_low(bdata->gpiod);
+
if (button->debounce_interval) {
error = gpiod_set_debounce(bdata->gpiod,
button->debounce_interval * 1000);
@@ -568,6 +572,24 @@ static int gpio_keys_setup_key(struct platform_device 
*pdev,
isr = gpio_keys_gpio_isr;
irqflags = IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING;
 
+   switch (button->wakeup_event_action) {
+   case EV_ACT_ASSERTED:
+   bdata->wakeup_trigger_type = active_low ?
+   IRQ_TYPE_EDGE_FALLING : IRQ_TYPE_EDGE_RISING;
+   break;
+   case EV_ACT_DEASSERTED:
+   bdata->wakeup_trigger_type = active_low ?
+   IRQ_TYPE_EDGE_RISING : IRQ_TYPE_EDGE_FALLING;
+   break;
+   case EV_ACT_ANY:
+   /* fall through */
+   default:
+   /*
+* For other cases, we are OK letting suspend/resume
+* not reconfigure the trigger type.
+*/
+   break;
+   }
} else {
if (!button->irq) {
dev_err(dev, "Found button without gpio or irq\n");
@@ -586,6 +608,11 @@ static int gpio_keys_setup_key(struct platform_device 
*pdev,
 
isr = gpio_keys_irq_isr;
irqflags = 0;
+
+   /*
+* For IRQ buttons, there is no interrupt for release.
+* So we don't need to reconfigure the trigger type for wakeup.
+*/
}
 
bdata->code = >keymap[idx];
@@ -718,6 +745,9 @@ gpio_keys_get_devtree_pdata(struct device *dev)
/* legacy name */
fwnode_property_read_bool(child, "gpio-key,wakeup");
 
+   fwnode_property_read_u32(child, "wakeup-event-action",
+>wakeup_event_action);
+
button->can_disable =
fwnode_property_read_bool(child, "linux,can-disable");
 
@@ -845,6 +875,31 @@ static int gpio_keys_probe(struct platform_device *pdev)
return 0;
 }
 
+static int gpio_keys_enable_wakeup(struct gpio_button_data *bdata)
+{
+   int ret;
+
+   ret = enable_irq_wake(bdata->irq);
+   if (ret)
+   return ret;
+
+   if (bdata->wakeup_trigger_type)
+   irq_set_irq_type(bdata->irq, bdata->wakeup_trigger_type);
+
+   return 0;
+}
+
+static void gpio_keys_disable_wakeup(struct gpio_button_data *bdata)
+{
+   /**
+* The trigger type is always both edges for gpio-based keys and we do
+* not support changing wakeup trigger for interrupt-based keys.
+*/
+   if (bdata->wakeup_trigger_type)
+   irq_set_irq_type(bdata->irq, IRQ_TYPE_EDGE_BOTH);
+   disable_irq_wake(bdata->irq);
+}
+
 static int __maybe_unused gpio_keys_suspend(struct device *dev)
 {
struct gpio_keys_drvdata *ddata = dev_get_drvdata(dev);
@@ -854,8 

[PATCH v5 1/3] Input: gpio-keys - add support for wakeup event action

2018-03-07 Thread Jeffy Chen
Add support for specifying event actions to trigger wakeup when using
the gpio-keys input device as a wakeup source.

This would allow the device to configure when to wakeup the system. For
example a gpio-keys input device for pen insert, may only want to wakeup
the system when ejecting the pen.

Suggested-by: Brian Norris 
Signed-off-by: Jeffy Chen 
---

Changes in v5:
Remove unneeded irq_wake flag as Andy suggested.

Changes in v4:
Add dt-binding gpio-keys.h, stop saving irq trigger type, add enable/disable 
wakeup helpers as Dmitry suggested.

Changes in v3:
Adding more comments as Brian suggested.

Changes in v2:
Specify wakeup event action instead of irq trigger type as Brian
suggested.

 drivers/input/keyboard/gpio_keys.c| 63 +--
 include/dt-bindings/input/gpio-keys.h | 13 
 include/linux/gpio_keys.h |  2 ++
 3 files changed, 75 insertions(+), 3 deletions(-)
 create mode 100644 include/dt-bindings/input/gpio-keys.h

diff --git a/drivers/input/keyboard/gpio_keys.c 
b/drivers/input/keyboard/gpio_keys.c
index 87e613dc33b8..f6d5cfd44833 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct gpio_button_data {
const struct gpio_keys_button *button;
@@ -45,6 +46,7 @@ struct gpio_button_data {
unsigned int software_debounce; /* in msecs, for GPIO-driven buttons */
 
unsigned int irq;
+   unsigned int wakeup_trigger_type;
spinlock_t lock;
bool disabled;
bool key_pressed;
@@ -540,6 +542,8 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
}
 
if (bdata->gpiod) {
+   int active_low = gpiod_is_active_low(bdata->gpiod);
+
if (button->debounce_interval) {
error = gpiod_set_debounce(bdata->gpiod,
button->debounce_interval * 1000);
@@ -568,6 +572,24 @@ static int gpio_keys_setup_key(struct platform_device 
*pdev,
isr = gpio_keys_gpio_isr;
irqflags = IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING;
 
+   switch (button->wakeup_event_action) {
+   case EV_ACT_ASSERTED:
+   bdata->wakeup_trigger_type = active_low ?
+   IRQ_TYPE_EDGE_FALLING : IRQ_TYPE_EDGE_RISING;
+   break;
+   case EV_ACT_DEASSERTED:
+   bdata->wakeup_trigger_type = active_low ?
+   IRQ_TYPE_EDGE_RISING : IRQ_TYPE_EDGE_FALLING;
+   break;
+   case EV_ACT_ANY:
+   /* fall through */
+   default:
+   /*
+* For other cases, we are OK letting suspend/resume
+* not reconfigure the trigger type.
+*/
+   break;
+   }
} else {
if (!button->irq) {
dev_err(dev, "Found button without gpio or irq\n");
@@ -586,6 +608,11 @@ static int gpio_keys_setup_key(struct platform_device 
*pdev,
 
isr = gpio_keys_irq_isr;
irqflags = 0;
+
+   /*
+* For IRQ buttons, there is no interrupt for release.
+* So we don't need to reconfigure the trigger type for wakeup.
+*/
}
 
bdata->code = >keymap[idx];
@@ -718,6 +745,9 @@ gpio_keys_get_devtree_pdata(struct device *dev)
/* legacy name */
fwnode_property_read_bool(child, "gpio-key,wakeup");
 
+   fwnode_property_read_u32(child, "wakeup-event-action",
+>wakeup_event_action);
+
button->can_disable =
fwnode_property_read_bool(child, "linux,can-disable");
 
@@ -845,6 +875,31 @@ static int gpio_keys_probe(struct platform_device *pdev)
return 0;
 }
 
+static int gpio_keys_enable_wakeup(struct gpio_button_data *bdata)
+{
+   int ret;
+
+   ret = enable_irq_wake(bdata->irq);
+   if (ret)
+   return ret;
+
+   if (bdata->wakeup_trigger_type)
+   irq_set_irq_type(bdata->irq, bdata->wakeup_trigger_type);
+
+   return 0;
+}
+
+static void gpio_keys_disable_wakeup(struct gpio_button_data *bdata)
+{
+   /**
+* The trigger type is always both edges for gpio-based keys and we do
+* not support changing wakeup trigger for interrupt-based keys.
+*/
+   if (bdata->wakeup_trigger_type)
+   irq_set_irq_type(bdata->irq, IRQ_TYPE_EDGE_BOTH);
+   disable_irq_wake(bdata->irq);
+}
+
 static int __maybe_unused gpio_keys_suspend(struct device *dev)
 {
struct gpio_keys_drvdata *ddata = dev_get_drvdata(dev);
@@ -854,8 +909,9 @@ static int __maybe_unused 

Re: [PATCH v4 1/3] Input: gpio-keys - add support for wakeup event action

2018-03-07 Thread JeffyChen

Hi Andy,

Thanks for your reply.

On 03/07/2018 07:57 PM, Andy Shevchenko wrote:

On Tue, Mar 6, 2018 at 9:44 AM, Jeffy Chen  wrote:

Add support for specifying event actions to trigger wakeup when using
the gpio-keys input device as a wakeup source.

This would allow the device to configure when to wakeup the system. For
example a gpio-keys input device for pen insert, may only want to wakeup
the system when ejecting the pen.



+   bool wakeup_enabled;



+   if (bdata->wakeup_enabled) {


This is redundant. IRQ core keeps track on this information already.

Check below as an example
aef3ad103a68 ("serial: core: remove unneeded irq_wake flag")


right, that make sense.







Re: [PATCH v4 1/3] Input: gpio-keys - add support for wakeup event action

2018-03-07 Thread JeffyChen

Hi Andy,

Thanks for your reply.

On 03/07/2018 07:57 PM, Andy Shevchenko wrote:

On Tue, Mar 6, 2018 at 9:44 AM, Jeffy Chen  wrote:

Add support for specifying event actions to trigger wakeup when using
the gpio-keys input device as a wakeup source.

This would allow the device to configure when to wakeup the system. For
example a gpio-keys input device for pen insert, may only want to wakeup
the system when ejecting the pen.



+   bool wakeup_enabled;



+   if (bdata->wakeup_enabled) {


This is redundant. IRQ core keeps track on this information already.

Check below as an example
aef3ad103a68 ("serial: core: remove unneeded irq_wake flag")


right, that make sense.







[PATCH v5 0/3] gpio-keys: Add support for specifying wakeup event action

2018-03-07 Thread Jeffy Chen

On chromebook kevin, we are using gpio-keys for pen insert event. But
we only want it to wakeup the system when ejecting the pen.

So we may need to change the interrupt trigger type during suspending.

Changes in v5:
Remove unneeded irq_wake flag as Andy suggested.

Changes in v4:
Add dt-binding gpio-keys.h, stop saving irq trigger type, add enable/disable 
wakeup helpers as Dmitry suggested.
Include dt-binding gpio-keys.h

Changes in v3:
Adding more comments as Brian suggested.

Changes in v2:
Specify wakeup event action instead of irq trigger type as Brian
suggested.
Specify wakeup event action instead of irq trigger type as Brian
suggested.
Specify wakeup event action instead of irq trigger type as Brian
suggested.

Jeffy Chen (3):
  Input: gpio-keys - add support for wakeup event action
  Input: gpio-keys - allow setting wakeup event action in DT
  arm64: dts: rockchip: kevin: Avoid wakeup when inserting the pen

 .../devicetree/bindings/input/gpio-keys.txt|  8 +++
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts  |  3 ++
 drivers/input/keyboard/gpio_keys.c | 63 --
 include/dt-bindings/input/gpio-keys.h  | 13 +
 include/linux/gpio_keys.h  |  2 +
 5 files changed, 86 insertions(+), 3 deletions(-)
 create mode 100644 include/dt-bindings/input/gpio-keys.h

-- 
2.11.0




[PATCH v5 2/3] Input: gpio-keys - allow setting wakeup event action in DT

2018-03-07 Thread Jeffy Chen
Allow specifying event actions to trigger wakeup when using the
gpio-keys input device as a wakeup source.

Reviewed-by: Rob Herring 
Signed-off-by: Jeffy Chen 
---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
Specify wakeup event action instead of irq trigger type as Brian
suggested.

 Documentation/devicetree/bindings/input/gpio-keys.txt | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/input/gpio-keys.txt 
b/Documentation/devicetree/bindings/input/gpio-keys.txt
index a94940481e55..996ce84352cb 100644
--- a/Documentation/devicetree/bindings/input/gpio-keys.txt
+++ b/Documentation/devicetree/bindings/input/gpio-keys.txt
@@ -26,6 +26,14 @@ Optional subnode-properties:
  If not specified defaults to 5.
- wakeup-source: Boolean, button can wake-up the system.
 (Legacy property supported: "gpio-key,wakeup")
+   - wakeup-event-action: Specifies whether the key should wake the
+ system when asserted, when deasserted, or both. This property is
+ only valid for keys that wake up the system (e.g., when the
+ "wakeup-source" property is also provided).
+ Supported values are defined in linux-event-codes.h:
+   EV_ACT_ASSERTED - asserted
+   EV_ACT_DEASSERTED   - deasserted
+   EV_ACT_ANY  - both asserted and deasserted
- linux,can-disable: Boolean, indicates that button is connected
  to dedicated (not shared) interrupt which can be disabled to
  suppress events from the button.
-- 
2.11.0




[PATCH v5 0/3] gpio-keys: Add support for specifying wakeup event action

2018-03-07 Thread Jeffy Chen

On chromebook kevin, we are using gpio-keys for pen insert event. But
we only want it to wakeup the system when ejecting the pen.

So we may need to change the interrupt trigger type during suspending.

Changes in v5:
Remove unneeded irq_wake flag as Andy suggested.

Changes in v4:
Add dt-binding gpio-keys.h, stop saving irq trigger type, add enable/disable 
wakeup helpers as Dmitry suggested.
Include dt-binding gpio-keys.h

Changes in v3:
Adding more comments as Brian suggested.

Changes in v2:
Specify wakeup event action instead of irq trigger type as Brian
suggested.
Specify wakeup event action instead of irq trigger type as Brian
suggested.
Specify wakeup event action instead of irq trigger type as Brian
suggested.

Jeffy Chen (3):
  Input: gpio-keys - add support for wakeup event action
  Input: gpio-keys - allow setting wakeup event action in DT
  arm64: dts: rockchip: kevin: Avoid wakeup when inserting the pen

 .../devicetree/bindings/input/gpio-keys.txt|  8 +++
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts  |  3 ++
 drivers/input/keyboard/gpio_keys.c | 63 --
 include/dt-bindings/input/gpio-keys.h  | 13 +
 include/linux/gpio_keys.h  |  2 +
 5 files changed, 86 insertions(+), 3 deletions(-)
 create mode 100644 include/dt-bindings/input/gpio-keys.h

-- 
2.11.0




[PATCH v5 2/3] Input: gpio-keys - allow setting wakeup event action in DT

2018-03-07 Thread Jeffy Chen
Allow specifying event actions to trigger wakeup when using the
gpio-keys input device as a wakeup source.

Reviewed-by: Rob Herring 
Signed-off-by: Jeffy Chen 
---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
Specify wakeup event action instead of irq trigger type as Brian
suggested.

 Documentation/devicetree/bindings/input/gpio-keys.txt | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/input/gpio-keys.txt 
b/Documentation/devicetree/bindings/input/gpio-keys.txt
index a94940481e55..996ce84352cb 100644
--- a/Documentation/devicetree/bindings/input/gpio-keys.txt
+++ b/Documentation/devicetree/bindings/input/gpio-keys.txt
@@ -26,6 +26,14 @@ Optional subnode-properties:
  If not specified defaults to 5.
- wakeup-source: Boolean, button can wake-up the system.
 (Legacy property supported: "gpio-key,wakeup")
+   - wakeup-event-action: Specifies whether the key should wake the
+ system when asserted, when deasserted, or both. This property is
+ only valid for keys that wake up the system (e.g., when the
+ "wakeup-source" property is also provided).
+ Supported values are defined in linux-event-codes.h:
+   EV_ACT_ASSERTED - asserted
+   EV_ACT_DEASSERTED   - deasserted
+   EV_ACT_ANY  - both asserted and deasserted
- linux,can-disable: Boolean, indicates that button is connected
  to dedicated (not shared) interrupt which can be disabled to
  suppress events from the button.
-- 
2.11.0




RE: [PATCH 1/2] dell-led: Change dell-led.h to dell-common.h

2018-03-07 Thread Mario.Limonciello
> -Original Message-
> From: Kai-Heng Feng [mailto:kai.heng.f...@canonical.com]
> Sent: Thursday, March 8, 2018 3:12 PM
> To: mj...@srcf.ucam.org; pali.ro...@gmail.com; dvh...@infradead.org;
> a...@infradead.org; Limonciello, Mario ;
> ti...@suse.com
> Cc: platform-driver-...@vger.kernel.org; linux-kernel@vger.kernel.org; alsa-
> de...@alsa-project.org; Kai-Heng Feng 
> Subject: [PATCH 1/2] dell-led: Change dell-led.h to dell-common.h
> 
> This header will be used for more than just led. Change it to a more
> generic name.
> 
> Signed-off-by: Kai-Heng Feng 

Reviewed-by: Mario Limonciello 

> ---
>  drivers/platform/x86/dell-laptop.c  | 2 +-
>  include/linux/{dell-led.h => dell-common.h} | 4 ++--
>  sound/pci/hda/dell_wmi_helper.c | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
>  rename include/linux/{dell-led.h => dell-common.h} (61%)
> 
> diff --git a/drivers/platform/x86/dell-laptop.c 
> b/drivers/platform/x86/dell-laptop.c
> index c52c6723374b..8ba820e6c3d0 100644
> --- a/drivers/platform/x86/dell-laptop.c
> +++ b/drivers/platform/x86/dell-laptop.c
> @@ -29,7 +29,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include "dell-rbtn.h"
> diff --git a/include/linux/dell-led.h b/include/linux/dell-common.h
> similarity index 61%
> rename from include/linux/dell-led.h
> rename to include/linux/dell-common.h
> index 92521471517f..37e4b614dd74 100644
> --- a/include/linux/dell-led.h
> +++ b/include/linux/dell-common.h
> @@ -1,6 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0 */
> -#ifndef __DELL_LED_H__
> -#define __DELL_LED_H__
> +#ifndef __DELL_COMMON_H__
> +#define __DELL_COMMON_H__
> 
>  int dell_micmute_led_set(int on);
> 
> diff --git a/sound/pci/hda/dell_wmi_helper.c b/sound/pci/hda/dell_wmi_helper.c
> index 1b48a8c19d28..56050cc3c0ee 100644
> --- a/sound/pci/hda/dell_wmi_helper.c
> +++ b/sound/pci/hda/dell_wmi_helper.c
> @@ -4,7 +4,7 @@
>   */
> 
>  #if IS_ENABLED(CONFIG_DELL_LAPTOP)
> -#include 
> +#include 
> 
>  enum {
>   MICMUTE_LED_ON,
> --
> 2.15.1



RE: [PATCH 1/2] dell-led: Change dell-led.h to dell-common.h

2018-03-07 Thread Mario.Limonciello
> -Original Message-
> From: Kai-Heng Feng [mailto:kai.heng.f...@canonical.com]
> Sent: Thursday, March 8, 2018 3:12 PM
> To: mj...@srcf.ucam.org; pali.ro...@gmail.com; dvh...@infradead.org;
> a...@infradead.org; Limonciello, Mario ;
> ti...@suse.com
> Cc: platform-driver-...@vger.kernel.org; linux-kernel@vger.kernel.org; alsa-
> de...@alsa-project.org; Kai-Heng Feng 
> Subject: [PATCH 1/2] dell-led: Change dell-led.h to dell-common.h
> 
> This header will be used for more than just led. Change it to a more
> generic name.
> 
> Signed-off-by: Kai-Heng Feng 

Reviewed-by: Mario Limonciello 

> ---
>  drivers/platform/x86/dell-laptop.c  | 2 +-
>  include/linux/{dell-led.h => dell-common.h} | 4 ++--
>  sound/pci/hda/dell_wmi_helper.c | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
>  rename include/linux/{dell-led.h => dell-common.h} (61%)
> 
> diff --git a/drivers/platform/x86/dell-laptop.c 
> b/drivers/platform/x86/dell-laptop.c
> index c52c6723374b..8ba820e6c3d0 100644
> --- a/drivers/platform/x86/dell-laptop.c
> +++ b/drivers/platform/x86/dell-laptop.c
> @@ -29,7 +29,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include "dell-rbtn.h"
> diff --git a/include/linux/dell-led.h b/include/linux/dell-common.h
> similarity index 61%
> rename from include/linux/dell-led.h
> rename to include/linux/dell-common.h
> index 92521471517f..37e4b614dd74 100644
> --- a/include/linux/dell-led.h
> +++ b/include/linux/dell-common.h
> @@ -1,6 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0 */
> -#ifndef __DELL_LED_H__
> -#define __DELL_LED_H__
> +#ifndef __DELL_COMMON_H__
> +#define __DELL_COMMON_H__
> 
>  int dell_micmute_led_set(int on);
> 
> diff --git a/sound/pci/hda/dell_wmi_helper.c b/sound/pci/hda/dell_wmi_helper.c
> index 1b48a8c19d28..56050cc3c0ee 100644
> --- a/sound/pci/hda/dell_wmi_helper.c
> +++ b/sound/pci/hda/dell_wmi_helper.c
> @@ -4,7 +4,7 @@
>   */
> 
>  #if IS_ENABLED(CONFIG_DELL_LAPTOP)
> -#include 
> +#include 
> 
>  enum {
>   MICMUTE_LED_ON,
> --
> 2.15.1



Re: [PATCH 10/11] Staging: iio: accel: Add comments about units in data read function

2018-03-07 Thread Himanshu Jha
On Wed, Mar 07, 2018 at 08:50:30PM +, Jonathan Cameron wrote:
> On Mon,  5 Mar 2018 13:19:29 +0530
> Himanshu Jha  wrote:
> 
> > Clarify the conversion and formation of resultant data in the
> > adis16201_read_raw() with sufficient comments.
> > 
> > Signed-off-by: Himanshu Jha 
> This is fine but it needs to be in the original comment changing patch
> rather than removing the comments first then a few patches later putting
> back a different version.
> 
> So good change but in the wrong place in the series.  Learning to reorder
> a series and merge down multiple patches into one is very useful when
> working with git.

I will send v2 with all the updates!

What about sign_extend32 & reverse christmas ordering patch ? Will you
pick that up or shall I send them again ?

-- 
Thanks
Himanshu Jha


Re: [PATCH 10/11] Staging: iio: accel: Add comments about units in data read function

2018-03-07 Thread Himanshu Jha
On Wed, Mar 07, 2018 at 08:50:30PM +, Jonathan Cameron wrote:
> On Mon,  5 Mar 2018 13:19:29 +0530
> Himanshu Jha  wrote:
> 
> > Clarify the conversion and formation of resultant data in the
> > adis16201_read_raw() with sufficient comments.
> > 
> > Signed-off-by: Himanshu Jha 
> This is fine but it needs to be in the original comment changing patch
> rather than removing the comments first then a few patches later putting
> back a different version.
> 
> So good change but in the wrong place in the series.  Learning to reorder
> a series and merge down multiple patches into one is very useful when
> working with git.

I will send v2 with all the updates!

What about sign_extend32 & reverse christmas ordering patch ? Will you
pick that up or shall I send them again ?

-- 
Thanks
Himanshu Jha


Re: [PATCH 1/2] dell-led: Change dell-led.h to dell-common.h

2018-03-07 Thread Takashi Iwai
On Thu, 08 Mar 2018 08:12:06 +0100,
Kai-Heng Feng wrote:
> 
> This header will be used for more than just led. Change it to a more
> generic name.
> 
> Signed-off-by: Kai-Heng Feng 

Not sure whether dell-common.h is the best name, but I have no time
for bikeshedding.

For the sound change, feel free to take my ack:
  Reviewed-by: Takashi Iwai 


thanks,

Takashi

> ---
>  drivers/platform/x86/dell-laptop.c  | 2 +-
>  include/linux/{dell-led.h => dell-common.h} | 4 ++--
>  sound/pci/hda/dell_wmi_helper.c | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
>  rename include/linux/{dell-led.h => dell-common.h} (61%)
> 
> diff --git a/drivers/platform/x86/dell-laptop.c 
> b/drivers/platform/x86/dell-laptop.c
> index c52c6723374b..8ba820e6c3d0 100644
> --- a/drivers/platform/x86/dell-laptop.c
> +++ b/drivers/platform/x86/dell-laptop.c
> @@ -29,7 +29,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include "dell-rbtn.h"
> diff --git a/include/linux/dell-led.h b/include/linux/dell-common.h
> similarity index 61%
> rename from include/linux/dell-led.h
> rename to include/linux/dell-common.h
> index 92521471517f..37e4b614dd74 100644
> --- a/include/linux/dell-led.h
> +++ b/include/linux/dell-common.h
> @@ -1,6 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0 */
> -#ifndef __DELL_LED_H__
> -#define __DELL_LED_H__
> +#ifndef __DELL_COMMON_H__
> +#define __DELL_COMMON_H__
>  
>  int dell_micmute_led_set(int on);
>  
> diff --git a/sound/pci/hda/dell_wmi_helper.c b/sound/pci/hda/dell_wmi_helper.c
> index 1b48a8c19d28..56050cc3c0ee 100644
> --- a/sound/pci/hda/dell_wmi_helper.c
> +++ b/sound/pci/hda/dell_wmi_helper.c
> @@ -4,7 +4,7 @@
>   */
>  
>  #if IS_ENABLED(CONFIG_DELL_LAPTOP)
> -#include 
> +#include 
>  
>  enum {
>   MICMUTE_LED_ON,
> -- 
> 2.15.1
> 
> 


Re: [PATCH 1/2] dell-led: Change dell-led.h to dell-common.h

2018-03-07 Thread Takashi Iwai
On Thu, 08 Mar 2018 08:12:06 +0100,
Kai-Heng Feng wrote:
> 
> This header will be used for more than just led. Change it to a more
> generic name.
> 
> Signed-off-by: Kai-Heng Feng 

Not sure whether dell-common.h is the best name, but I have no time
for bikeshedding.

For the sound change, feel free to take my ack:
  Reviewed-by: Takashi Iwai 


thanks,

Takashi

> ---
>  drivers/platform/x86/dell-laptop.c  | 2 +-
>  include/linux/{dell-led.h => dell-common.h} | 4 ++--
>  sound/pci/hda/dell_wmi_helper.c | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
>  rename include/linux/{dell-led.h => dell-common.h} (61%)
> 
> diff --git a/drivers/platform/x86/dell-laptop.c 
> b/drivers/platform/x86/dell-laptop.c
> index c52c6723374b..8ba820e6c3d0 100644
> --- a/drivers/platform/x86/dell-laptop.c
> +++ b/drivers/platform/x86/dell-laptop.c
> @@ -29,7 +29,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include "dell-rbtn.h"
> diff --git a/include/linux/dell-led.h b/include/linux/dell-common.h
> similarity index 61%
> rename from include/linux/dell-led.h
> rename to include/linux/dell-common.h
> index 92521471517f..37e4b614dd74 100644
> --- a/include/linux/dell-led.h
> +++ b/include/linux/dell-common.h
> @@ -1,6 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0 */
> -#ifndef __DELL_LED_H__
> -#define __DELL_LED_H__
> +#ifndef __DELL_COMMON_H__
> +#define __DELL_COMMON_H__
>  
>  int dell_micmute_led_set(int on);
>  
> diff --git a/sound/pci/hda/dell_wmi_helper.c b/sound/pci/hda/dell_wmi_helper.c
> index 1b48a8c19d28..56050cc3c0ee 100644
> --- a/sound/pci/hda/dell_wmi_helper.c
> +++ b/sound/pci/hda/dell_wmi_helper.c
> @@ -4,7 +4,7 @@
>   */
>  
>  #if IS_ENABLED(CONFIG_DELL_LAPTOP)
> -#include 
> +#include 
>  
>  enum {
>   MICMUTE_LED_ON,
> -- 
> 2.15.1
> 
> 


[PATCH v2] f2fs: add nowait aio support

2018-03-07 Thread Hyunchul Lee
From: Hyunchul Lee 

This patch adds nowait aio support[1].

Return EAGAIN if any of the following checks fail for direct I/O:
  - i_rwsem is not lockable
  - Blocks are not allocated at the write location

And xfstests generic/471 is passed.

 [1]: 6be96d "Introduce RWF_NOWAIT and FMODE_AIO_NOWAIT"

Signed-off-by: Hyunchul Lee 
---
Changes from v1:
 - Return EGAIN if dio_rwsem is not lockable in f2fs_direct_IO
 - Fix the wrong calculation of last_lblk in f2fs_overwrite_io 

 fs/f2fs/data.c | 47 +--
 fs/f2fs/f2fs.h |  8 
 fs/f2fs/file.c | 35 +--
 3 files changed, 74 insertions(+), 16 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 6c3c978..b27ea1e 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -839,13 +839,6 @@ static int __allocate_data_block(struct dnode_of_data *dn, 
int seg_type)
return 0;
 }
 
-static inline bool __force_buffered_io(struct inode *inode, int rw)
-{
-   return (f2fs_encrypted_file(inode) ||
-   (rw == WRITE && test_opt(F2FS_I_SB(inode), LFS)) ||
-   F2FS_I_SB(inode)->s_ndevs);
-}
-
 int f2fs_preallocate_blocks(struct kiocb *iocb, struct iov_iter *from)
 {
struct inode *inode = file_inode(iocb->ki_filp);
@@ -877,7 +870,7 @@ int f2fs_preallocate_blocks(struct kiocb *iocb, struct 
iov_iter *from)
 
if (direct_io) {
map.m_seg_type = rw_hint_to_seg_type(iocb->ki_hint);
-   flag = __force_buffered_io(inode, WRITE) ?
+   flag = f2fs_force_buffered_io(inode, WRITE) ?
F2FS_GET_BLOCK_PRE_AIO :
F2FS_GET_BLOCK_PRE_DIO;
goto map_blocks;
@@ -1121,6 +1114,31 @@ int f2fs_map_blocks(struct inode *inode, struct 
f2fs_map_blocks *map,
return err;
 }
 
+bool f2fs_overwrite_io(struct inode *inode, loff_t pos, size_t len)
+{
+   struct f2fs_map_blocks map;
+   block_t last_lblk;
+   int err;
+
+   if (pos + len > i_size_read(inode))
+   return false;
+
+   map.m_lblk = F2FS_BYTES_TO_BLK(pos);
+   map.m_next_pgofs = 0;
+   map.m_next_extent = NULL;
+   map.m_seg_type = NO_CHECK_TYPE;
+   last_lblk = F2FS_BYTES_TO_BLK(pos + len - 1) + 1;
+
+   while (map.m_lblk < last_lblk) {
+   map.m_len = last_lblk - map.m_lblk;
+   err = f2fs_map_blocks(inode, , 0, 0);
+   if (err || map.m_len == 0)
+   return false;
+   map.m_lblk += map.m_len;
+   }
+   return true;
+}
+
 static int __get_data_block(struct inode *inode, sector_t iblock,
struct buffer_head *bh, int create, int flag,
pgoff_t *next_pgofs, int seg_type)
@@ -2306,7 +2324,7 @@ static ssize_t f2fs_direct_IO(struct kiocb *iocb, struct 
iov_iter *iter)
if (err)
return err;
 
-   if (__force_buffered_io(inode, rw))
+   if (f2fs_force_buffered_io(inode, rw))
return 0;
 
trace_f2fs_direct_IO_enter(inode, offset, count, rw);
@@ -2314,7 +2332,15 @@ static ssize_t f2fs_direct_IO(struct kiocb *iocb, struct 
iov_iter *iter)
if (rw == WRITE && whint_mode == WHINT_MODE_OFF)
iocb->ki_hint = WRITE_LIFE_NOT_SET;
 
-   down_read(_I(inode)->dio_rwsem[rw]);
+   if (!down_read_trylock(_I(inode)->dio_rwsem[rw])) {
+   if (iocb->ki_flags & IOCB_NOWAIT) {
+   iocb->ki_hint = hint;
+   err = -EAGAIN;
+   goto out;
+   }
+   down_read(_I(inode)->dio_rwsem[rw]);
+   }
+
err = blockdev_direct_IO(iocb, inode, iter, get_data_block_dio);
up_read(_I(inode)->dio_rwsem[rw]);
 
@@ -2330,6 +2356,7 @@ static ssize_t f2fs_direct_IO(struct kiocb *iocb, struct 
iov_iter *iter)
}
}
 
+out:
trace_f2fs_direct_IO_exit(inode, offset, count, rw, err);
 
return err;
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index f6dc706..351226e 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2875,6 +2875,7 @@ void f2fs_invalidate_page(struct page *page, unsigned int 
offset,
 int f2fs_migrate_page(struct address_space *mapping, struct page *newpage,
struct page *page, enum migrate_mode mode);
 #endif
+bool f2fs_overwrite_io(struct inode *inode, loff_t pos, size_t len);
 
 /*
  * gc.c
@@ -3259,4 +3260,11 @@ static inline bool f2fs_may_encrypt(struct inode *inode)
 #endif
 }
 
+static inline bool f2fs_force_buffered_io(struct inode *inode, int rw)
+{
+   return (f2fs_encrypted_file(inode) ||
+   (rw == WRITE && test_opt(F2FS_I_SB(inode), LFS)) ||
+   F2FS_I_SB(inode)->s_ndevs);
+}
+
 #endif
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 6a202e5..1051edd 100644
--- a/fs/f2fs/file.c

[PATCH v2] f2fs: add nowait aio support

2018-03-07 Thread Hyunchul Lee
From: Hyunchul Lee 

This patch adds nowait aio support[1].

Return EAGAIN if any of the following checks fail for direct I/O:
  - i_rwsem is not lockable
  - Blocks are not allocated at the write location

And xfstests generic/471 is passed.

 [1]: 6be96d "Introduce RWF_NOWAIT and FMODE_AIO_NOWAIT"

Signed-off-by: Hyunchul Lee 
---
Changes from v1:
 - Return EGAIN if dio_rwsem is not lockable in f2fs_direct_IO
 - Fix the wrong calculation of last_lblk in f2fs_overwrite_io 

 fs/f2fs/data.c | 47 +--
 fs/f2fs/f2fs.h |  8 
 fs/f2fs/file.c | 35 +--
 3 files changed, 74 insertions(+), 16 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 6c3c978..b27ea1e 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -839,13 +839,6 @@ static int __allocate_data_block(struct dnode_of_data *dn, 
int seg_type)
return 0;
 }
 
-static inline bool __force_buffered_io(struct inode *inode, int rw)
-{
-   return (f2fs_encrypted_file(inode) ||
-   (rw == WRITE && test_opt(F2FS_I_SB(inode), LFS)) ||
-   F2FS_I_SB(inode)->s_ndevs);
-}
-
 int f2fs_preallocate_blocks(struct kiocb *iocb, struct iov_iter *from)
 {
struct inode *inode = file_inode(iocb->ki_filp);
@@ -877,7 +870,7 @@ int f2fs_preallocate_blocks(struct kiocb *iocb, struct 
iov_iter *from)
 
if (direct_io) {
map.m_seg_type = rw_hint_to_seg_type(iocb->ki_hint);
-   flag = __force_buffered_io(inode, WRITE) ?
+   flag = f2fs_force_buffered_io(inode, WRITE) ?
F2FS_GET_BLOCK_PRE_AIO :
F2FS_GET_BLOCK_PRE_DIO;
goto map_blocks;
@@ -1121,6 +1114,31 @@ int f2fs_map_blocks(struct inode *inode, struct 
f2fs_map_blocks *map,
return err;
 }
 
+bool f2fs_overwrite_io(struct inode *inode, loff_t pos, size_t len)
+{
+   struct f2fs_map_blocks map;
+   block_t last_lblk;
+   int err;
+
+   if (pos + len > i_size_read(inode))
+   return false;
+
+   map.m_lblk = F2FS_BYTES_TO_BLK(pos);
+   map.m_next_pgofs = 0;
+   map.m_next_extent = NULL;
+   map.m_seg_type = NO_CHECK_TYPE;
+   last_lblk = F2FS_BYTES_TO_BLK(pos + len - 1) + 1;
+
+   while (map.m_lblk < last_lblk) {
+   map.m_len = last_lblk - map.m_lblk;
+   err = f2fs_map_blocks(inode, , 0, 0);
+   if (err || map.m_len == 0)
+   return false;
+   map.m_lblk += map.m_len;
+   }
+   return true;
+}
+
 static int __get_data_block(struct inode *inode, sector_t iblock,
struct buffer_head *bh, int create, int flag,
pgoff_t *next_pgofs, int seg_type)
@@ -2306,7 +2324,7 @@ static ssize_t f2fs_direct_IO(struct kiocb *iocb, struct 
iov_iter *iter)
if (err)
return err;
 
-   if (__force_buffered_io(inode, rw))
+   if (f2fs_force_buffered_io(inode, rw))
return 0;
 
trace_f2fs_direct_IO_enter(inode, offset, count, rw);
@@ -2314,7 +2332,15 @@ static ssize_t f2fs_direct_IO(struct kiocb *iocb, struct 
iov_iter *iter)
if (rw == WRITE && whint_mode == WHINT_MODE_OFF)
iocb->ki_hint = WRITE_LIFE_NOT_SET;
 
-   down_read(_I(inode)->dio_rwsem[rw]);
+   if (!down_read_trylock(_I(inode)->dio_rwsem[rw])) {
+   if (iocb->ki_flags & IOCB_NOWAIT) {
+   iocb->ki_hint = hint;
+   err = -EAGAIN;
+   goto out;
+   }
+   down_read(_I(inode)->dio_rwsem[rw]);
+   }
+
err = blockdev_direct_IO(iocb, inode, iter, get_data_block_dio);
up_read(_I(inode)->dio_rwsem[rw]);
 
@@ -2330,6 +2356,7 @@ static ssize_t f2fs_direct_IO(struct kiocb *iocb, struct 
iov_iter *iter)
}
}
 
+out:
trace_f2fs_direct_IO_exit(inode, offset, count, rw, err);
 
return err;
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index f6dc706..351226e 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2875,6 +2875,7 @@ void f2fs_invalidate_page(struct page *page, unsigned int 
offset,
 int f2fs_migrate_page(struct address_space *mapping, struct page *newpage,
struct page *page, enum migrate_mode mode);
 #endif
+bool f2fs_overwrite_io(struct inode *inode, loff_t pos, size_t len);
 
 /*
  * gc.c
@@ -3259,4 +3260,11 @@ static inline bool f2fs_may_encrypt(struct inode *inode)
 #endif
 }
 
+static inline bool f2fs_force_buffered_io(struct inode *inode, int rw)
+{
+   return (f2fs_encrypted_file(inode) ||
+   (rw == WRITE && test_opt(F2FS_I_SB(inode), LFS)) ||
+   F2FS_I_SB(inode)->s_ndevs);
+}
+
 #endif
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 6a202e5..1051edd 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -479,6 +479,9 

[PATCH v2 4/4] clk: qcom: Add Global Clock controller (GCC) driver for SDM845

2018-03-07 Thread Amit Nischal
From: Taniya Das 

Add support for the global clock controller found on SDM845
based devices. This should allow most non-multimedia device
drivers to probe and control their clocks.

Signed-off-by: Taniya Das 
Signed-off-by: Amit Nischal 
---
 .../devicetree/bindings/clock/qcom,gcc.txt |1 +
 drivers/clk/qcom/Kconfig   |   11 +
 drivers/clk/qcom/Makefile  |1 +
 drivers/clk/qcom/gcc-sdm845.c  | 3619 
 include/dt-bindings/clock/qcom,gcc-sdm845.h|  242 ++
 5 files changed, 3874 insertions(+)
 create mode 100644 drivers/clk/qcom/gcc-sdm845.c
 create mode 100644 include/dt-bindings/clock/qcom,gcc-sdm845.h

diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt 
b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index 551d03b..bf2355d 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -18,6 +18,7 @@ Required properties :
"qcom,gcc-msm8994"
"qcom,gcc-msm8996"
"qcom,gcc-mdm9615"
+   "qcom,gcc-sdm845"
 
 - reg : shall contain base register location and length
 - #clock-cells : shall contain 1
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index fbf4532..54d0545 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -218,6 +218,16 @@ config MSM_MMCC_8996
  Say Y if you want to support multimedia devices such as display,
  graphics, video encode/decode, camera, etc.
 
+config SDM_GCC_845
+   tristate "SDM845 Global Clock Controller"
+   depends on COMMON_CLK_QCOM
+   help
+ Support for the global clock controller on Qualcomm Technologies, Inc
+ sdm845 devices.
+ Say Y if you want to use peripheral devices such as UART, SPI,
+ i2c, USB, UFS, SD/eMMC, PCIe, etc.
+
+
 config SPMI_PMIC_CLKDIV
tristate "SPMI PMIC clkdiv Support"
depends on (COMMON_CLK_QCOM && SPMI) || COMPILE_TEST
@@ -226,3 +236,4 @@ config SPMI_PMIC_CLKDIV
  Technologies, Inc. SPMI PMIC. It configures the frequency of
  clkdiv outputs of the PMIC. These clocks are typically wired
  through alternate functions on GPIO pins.
+
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 230332c..1fc934dd 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -37,4 +37,5 @@ obj-$(CONFIG_QCOM_A53PLL) += a53-pll.o
 obj-$(CONFIG_QCOM_CLK_APCS_MSM8916) += apcs-msm8916.o
 obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o
 obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
+obj-$(CONFIG_SDM_GCC_845)  += gcc-sdm845.o
 obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
new file mode 100644
index 000..3ffa098
--- /dev/null
+++ b/drivers/clk/qcom/gcc-sdm845.c
@@ -0,0 +1,3619 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "common.h"
+#include "clk-regmap.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-branch.h"
+#include "clk-alpha-pll.h"
+#include "gdsc.h"
+#include "reset.h"
+
+#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
+
+static struct freq_tbl cxo_safe_src_f = {
+   .pre_div = 1,
+};
+
+enum {
+   P_BI_TCXO,
+   P_AUD_REF_CLK,
+   P_CORE_BI_PLL_TEST_SE,
+   P_GPLL0_OUT_EVEN,
+   P_GPLL0_OUT_MAIN,
+   P_GPLL4_OUT_MAIN,
+   P_SLEEP_CLK,
+};
+
+static const struct parent_map gcc_parent_map_0[] = {
+   { P_BI_TCXO, 0 },
+   { P_GPLL0_OUT_MAIN, 1 },
+   { P_GPLL0_OUT_EVEN, 6 },
+   { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const gcc_parent_names_0[] = {
+   "bi_tcxo",
+   "gpll0",
+   "gpll0_out_even",
+   "core_bi_pll_test_se",
+};
+
+static const struct parent_map gcc_parent_map_1[] = {
+   { P_BI_TCXO, 0 },
+   { P_GPLL0_OUT_MAIN, 1 },
+   { P_SLEEP_CLK, 5 },
+   { P_GPLL0_OUT_EVEN, 6 },
+   { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const gcc_parent_names_1[] = {
+   "bi_tcxo",
+   "gpll0",
+   "core_pi_sleep_clk",
+   "gpll0_out_even",
+   "core_bi_pll_test_se",
+};
+
+static const struct parent_map gcc_parent_map_2[] = {
+   { P_BI_TCXO, 0 },
+   { P_SLEEP_CLK, 5 },
+   { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const gcc_parent_names_2[] = {
+   "bi_tcxo",
+   "core_pi_sleep_clk",
+   "core_bi_pll_test_se",
+};
+
+static const struct parent_map gcc_parent_map_3[] = {
+   { P_BI_TCXO, 0 },
+   { P_GPLL0_OUT_MAIN, 1 },
+   { P_CORE_BI_PLL_TEST_SE, 7 },

[PATCH v2 4/4] clk: qcom: Add Global Clock controller (GCC) driver for SDM845

2018-03-07 Thread Amit Nischal
From: Taniya Das 

Add support for the global clock controller found on SDM845
based devices. This should allow most non-multimedia device
drivers to probe and control their clocks.

Signed-off-by: Taniya Das 
Signed-off-by: Amit Nischal 
---
 .../devicetree/bindings/clock/qcom,gcc.txt |1 +
 drivers/clk/qcom/Kconfig   |   11 +
 drivers/clk/qcom/Makefile  |1 +
 drivers/clk/qcom/gcc-sdm845.c  | 3619 
 include/dt-bindings/clock/qcom,gcc-sdm845.h|  242 ++
 5 files changed, 3874 insertions(+)
 create mode 100644 drivers/clk/qcom/gcc-sdm845.c
 create mode 100644 include/dt-bindings/clock/qcom,gcc-sdm845.h

diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt 
b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index 551d03b..bf2355d 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -18,6 +18,7 @@ Required properties :
"qcom,gcc-msm8994"
"qcom,gcc-msm8996"
"qcom,gcc-mdm9615"
+   "qcom,gcc-sdm845"
 
 - reg : shall contain base register location and length
 - #clock-cells : shall contain 1
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index fbf4532..54d0545 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -218,6 +218,16 @@ config MSM_MMCC_8996
  Say Y if you want to support multimedia devices such as display,
  graphics, video encode/decode, camera, etc.
 
+config SDM_GCC_845
+   tristate "SDM845 Global Clock Controller"
+   depends on COMMON_CLK_QCOM
+   help
+ Support for the global clock controller on Qualcomm Technologies, Inc
+ sdm845 devices.
+ Say Y if you want to use peripheral devices such as UART, SPI,
+ i2c, USB, UFS, SD/eMMC, PCIe, etc.
+
+
 config SPMI_PMIC_CLKDIV
tristate "SPMI PMIC clkdiv Support"
depends on (COMMON_CLK_QCOM && SPMI) || COMPILE_TEST
@@ -226,3 +236,4 @@ config SPMI_PMIC_CLKDIV
  Technologies, Inc. SPMI PMIC. It configures the frequency of
  clkdiv outputs of the PMIC. These clocks are typically wired
  through alternate functions on GPIO pins.
+
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 230332c..1fc934dd 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -37,4 +37,5 @@ obj-$(CONFIG_QCOM_A53PLL) += a53-pll.o
 obj-$(CONFIG_QCOM_CLK_APCS_MSM8916) += apcs-msm8916.o
 obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o
 obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
+obj-$(CONFIG_SDM_GCC_845)  += gcc-sdm845.o
 obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
new file mode 100644
index 000..3ffa098
--- /dev/null
+++ b/drivers/clk/qcom/gcc-sdm845.c
@@ -0,0 +1,3619 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "common.h"
+#include "clk-regmap.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-branch.h"
+#include "clk-alpha-pll.h"
+#include "gdsc.h"
+#include "reset.h"
+
+#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
+
+static struct freq_tbl cxo_safe_src_f = {
+   .pre_div = 1,
+};
+
+enum {
+   P_BI_TCXO,
+   P_AUD_REF_CLK,
+   P_CORE_BI_PLL_TEST_SE,
+   P_GPLL0_OUT_EVEN,
+   P_GPLL0_OUT_MAIN,
+   P_GPLL4_OUT_MAIN,
+   P_SLEEP_CLK,
+};
+
+static const struct parent_map gcc_parent_map_0[] = {
+   { P_BI_TCXO, 0 },
+   { P_GPLL0_OUT_MAIN, 1 },
+   { P_GPLL0_OUT_EVEN, 6 },
+   { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const gcc_parent_names_0[] = {
+   "bi_tcxo",
+   "gpll0",
+   "gpll0_out_even",
+   "core_bi_pll_test_se",
+};
+
+static const struct parent_map gcc_parent_map_1[] = {
+   { P_BI_TCXO, 0 },
+   { P_GPLL0_OUT_MAIN, 1 },
+   { P_SLEEP_CLK, 5 },
+   { P_GPLL0_OUT_EVEN, 6 },
+   { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const gcc_parent_names_1[] = {
+   "bi_tcxo",
+   "gpll0",
+   "core_pi_sleep_clk",
+   "gpll0_out_even",
+   "core_bi_pll_test_se",
+};
+
+static const struct parent_map gcc_parent_map_2[] = {
+   { P_BI_TCXO, 0 },
+   { P_SLEEP_CLK, 5 },
+   { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const gcc_parent_names_2[] = {
+   "bi_tcxo",
+   "core_pi_sleep_clk",
+   "core_bi_pll_test_se",
+};
+
+static const struct parent_map gcc_parent_map_3[] = {
+   { P_BI_TCXO, 0 },
+   { P_GPLL0_OUT_MAIN, 1 },
+   { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const gcc_parent_names_3[] = {
+   

[PATCH v2 2/4] clk: qcom: Configure the RCGs to a safe source as needed

2018-03-07 Thread Amit Nischal
For some root clock generators, there could be child branches which are
controlled by an entity other than application processor subsystem. For
such RCGs, as per application processor subsystem clock driver, all of its
downstream clocks are disabled and RCG is in disabled state but in actual
downstream clocks can be left enabled before.

So in this scenario, when RCG is disabled as per clock driver's point of
view and when rate scaling request comes before downstream clock enable
request, then RCG fails to update its configuration because in actual RCG
is on and it expects its new source to alredy in enable state  but in
reality new source is in off state. In order to avoid letting the RCG to
go into an invalid state, add support to just cache the rate of RCG during
set_rate(), defer actual RCG configuration update to be done during
clk_enable() as at this point of time, both its new parent and safe source
will be already enabled and RCG can safely switch to new parent.

During clk_disable() request, configure it to safe source as both
its parents, safe source and current parent will be enabled and RCG can
safely execute a switch. Also add support to have safe configuration
frequency table structure for each shared RCG.

Signed-off-by: Taniya Das 
Signed-off-by: Amit Nischal 
---
 drivers/clk/qcom/clk-rcg.h  |   8 ++-
 drivers/clk/qcom/clk-rcg2.c | 155 
 2 files changed, 162 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/qcom/clk-rcg.h b/drivers/clk/qcom/clk-rcg.h
index 2a7489a..205fa34 100644
--- a/drivers/clk/qcom/clk-rcg.h
+++ b/drivers/clk/qcom/clk-rcg.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2013, 2018, The Linux Foundation. All rights reserved.
  *
  * This software is licensed under the terms of the GNU General Public
  * License version 2, as published by the Free Software Foundation, and
@@ -146,6 +146,9 @@ struct clk_dyn_rcg {
  * @hid_width: number of bits in half integer divider
  * @parent_map: map from software's parent index to hardware's src_sel field
  * @freq_tbl: frequency table
+ * @current_freq: last cached frequency when using branches with shared RCGs
+ * @safe_src_freq_tbl : frequency table of safe source when using branches
+ * with shared RCGs
  * @clkr: regmap clock handle
  *
  */
@@ -155,6 +158,8 @@ struct clk_rcg2 {
u8  hid_width;
const struct parent_map *parent_map;
const struct freq_tbl   *freq_tbl;
+   unsigned long   current_freq;
+   const struct freq_tbl   *safe_src_freq_tbl;
struct clk_regmap   clkr;
 };

@@ -167,5 +172,6 @@ struct clk_rcg2 {
 extern const struct clk_ops clk_byte2_ops;
 extern const struct clk_ops clk_pixel_ops;
 extern const struct clk_ops clk_gfx3d_ops;
+extern const struct clk_ops clk_rcg2_shared_ops;

 #endif
diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index e63db10..a52de54 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -790,3 +790,158 @@ static int clk_gfx3d_set_rate(struct clk_hw *hw, unsigned 
long rate,
.determine_rate = clk_gfx3d_determine_rate,
 };
 EXPORT_SYMBOL_GPL(clk_gfx3d_ops);
+
+static int clk_rcg2_set_force_enable(struct clk_hw *hw)
+{
+   struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+   const char *name = clk_hw_get_name(hw);
+   int ret, count;
+
+   /* Force enable bit */
+   ret = regmap_update_bits(rcg->clkr.regmap, rcg->cmd_rcgr + CMD_REG,
+CMD_ROOT_EN, CMD_ROOT_EN);
+   if (ret)
+   return ret;
+
+   /* wait for RCG to turn ON */
+   for (count = 500; count > 0; count--) {
+   if (clk_rcg2_is_enabled(hw))
+   return 0;
+
+   /* Delay for 1usec and retry polling the status bit */
+   udelay(1);
+   }
+   if (!count)
+   pr_err("%s: RCG did not turn on\n", name);
+
+   return -ETIMEDOUT;
+}
+
+static int clk_rcg2_clear_force_enable(struct clk_hw *hw)
+{
+   struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+
+   /* Clear force enable bit */
+   return regmap_update_bits(rcg->clkr.regmap, rcg->cmd_rcgr + CMD_REG,
+   CMD_ROOT_EN, 0);
+}
+
+static int
+clk_rcg2_shared_force_enable_clear(struct clk_hw *hw, unsigned long rate)
+{
+   int ret;
+
+   ret = clk_rcg2_set_force_enable(hw);
+   if (ret)
+   return ret;
+
+   /* set clock rate */
+   ret = __clk_rcg2_set_rate(hw, rate, CEIL);
+   if (ret)
+   return ret;
+
+   return clk_rcg2_clear_force_enable(hw);
+}
+
+static int clk_rcg2_shared_set_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long parent_rate)
+{
+   struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+   int ret;
+
+   /*

[PATCH v2 1/4] clk: qcom: Clear hardware clock control bit of RCG

2018-03-07 Thread Amit Nischal
For upcoming targets like sdm845, POR value of the hardware clock control
bit is set for most of root clocks which needs to be cleared for software
to be able to control. For older targets like MSM8996, this bit is reserved
bit and having POR value as 0 so this patch will work for the older targets
too. So update the configuration mask to take care of the same to clear
hardware clock control bit.

Signed-off-by: Amit Nischal 
---
 drivers/clk/qcom/clk-rcg2.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index bbeaf9c..e63db10 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2013, 2018, The Linux Foundation. All rights reserved.
  *
  * This software is licensed under the terms of the GNU General Public
  * License version 2, as published by the Free Software Foundation, and
@@ -42,6 +42,7 @@
 #define CFG_MODE_SHIFT 12
 #define CFG_MODE_MASK  (0x3 << CFG_MODE_SHIFT)
 #define CFG_MODE_DUAL_EDGE (0x2 << CFG_MODE_SHIFT)
+#define CFG_HW_CLK_CTRL_MASK   BIT(20)

 #define M_REG  0x8
 #define N_REG  0xc
@@ -276,7 +277,7 @@ static int clk_rcg2_configure(struct clk_rcg2 *rcg, const 
struct freq_tbl *f)
}

mask = BIT(rcg->hid_width) - 1;
-   mask |= CFG_SRC_SEL_MASK | CFG_MODE_MASK;
+   mask |= CFG_SRC_SEL_MASK | CFG_MODE_MASK | CFG_HW_CLK_CTRL_MASK;
cfg = f->pre_div << CFG_SRC_DIV_SHIFT;
cfg |= rcg->parent_map[index].cfg << CFG_SRC_SEL_SHIFT;
if (rcg->mnd_width && f->n && (f->m != f->n))
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation



[PATCH v2 2/4] clk: qcom: Configure the RCGs to a safe source as needed

2018-03-07 Thread Amit Nischal
For some root clock generators, there could be child branches which are
controlled by an entity other than application processor subsystem. For
such RCGs, as per application processor subsystem clock driver, all of its
downstream clocks are disabled and RCG is in disabled state but in actual
downstream clocks can be left enabled before.

So in this scenario, when RCG is disabled as per clock driver's point of
view and when rate scaling request comes before downstream clock enable
request, then RCG fails to update its configuration because in actual RCG
is on and it expects its new source to alredy in enable state  but in
reality new source is in off state. In order to avoid letting the RCG to
go into an invalid state, add support to just cache the rate of RCG during
set_rate(), defer actual RCG configuration update to be done during
clk_enable() as at this point of time, both its new parent and safe source
will be already enabled and RCG can safely switch to new parent.

During clk_disable() request, configure it to safe source as both
its parents, safe source and current parent will be enabled and RCG can
safely execute a switch. Also add support to have safe configuration
frequency table structure for each shared RCG.

Signed-off-by: Taniya Das 
Signed-off-by: Amit Nischal 
---
 drivers/clk/qcom/clk-rcg.h  |   8 ++-
 drivers/clk/qcom/clk-rcg2.c | 155 
 2 files changed, 162 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/qcom/clk-rcg.h b/drivers/clk/qcom/clk-rcg.h
index 2a7489a..205fa34 100644
--- a/drivers/clk/qcom/clk-rcg.h
+++ b/drivers/clk/qcom/clk-rcg.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2013, 2018, The Linux Foundation. All rights reserved.
  *
  * This software is licensed under the terms of the GNU General Public
  * License version 2, as published by the Free Software Foundation, and
@@ -146,6 +146,9 @@ struct clk_dyn_rcg {
  * @hid_width: number of bits in half integer divider
  * @parent_map: map from software's parent index to hardware's src_sel field
  * @freq_tbl: frequency table
+ * @current_freq: last cached frequency when using branches with shared RCGs
+ * @safe_src_freq_tbl : frequency table of safe source when using branches
+ * with shared RCGs
  * @clkr: regmap clock handle
  *
  */
@@ -155,6 +158,8 @@ struct clk_rcg2 {
u8  hid_width;
const struct parent_map *parent_map;
const struct freq_tbl   *freq_tbl;
+   unsigned long   current_freq;
+   const struct freq_tbl   *safe_src_freq_tbl;
struct clk_regmap   clkr;
 };

@@ -167,5 +172,6 @@ struct clk_rcg2 {
 extern const struct clk_ops clk_byte2_ops;
 extern const struct clk_ops clk_pixel_ops;
 extern const struct clk_ops clk_gfx3d_ops;
+extern const struct clk_ops clk_rcg2_shared_ops;

 #endif
diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index e63db10..a52de54 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -790,3 +790,158 @@ static int clk_gfx3d_set_rate(struct clk_hw *hw, unsigned 
long rate,
.determine_rate = clk_gfx3d_determine_rate,
 };
 EXPORT_SYMBOL_GPL(clk_gfx3d_ops);
+
+static int clk_rcg2_set_force_enable(struct clk_hw *hw)
+{
+   struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+   const char *name = clk_hw_get_name(hw);
+   int ret, count;
+
+   /* Force enable bit */
+   ret = regmap_update_bits(rcg->clkr.regmap, rcg->cmd_rcgr + CMD_REG,
+CMD_ROOT_EN, CMD_ROOT_EN);
+   if (ret)
+   return ret;
+
+   /* wait for RCG to turn ON */
+   for (count = 500; count > 0; count--) {
+   if (clk_rcg2_is_enabled(hw))
+   return 0;
+
+   /* Delay for 1usec and retry polling the status bit */
+   udelay(1);
+   }
+   if (!count)
+   pr_err("%s: RCG did not turn on\n", name);
+
+   return -ETIMEDOUT;
+}
+
+static int clk_rcg2_clear_force_enable(struct clk_hw *hw)
+{
+   struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+
+   /* Clear force enable bit */
+   return regmap_update_bits(rcg->clkr.regmap, rcg->cmd_rcgr + CMD_REG,
+   CMD_ROOT_EN, 0);
+}
+
+static int
+clk_rcg2_shared_force_enable_clear(struct clk_hw *hw, unsigned long rate)
+{
+   int ret;
+
+   ret = clk_rcg2_set_force_enable(hw);
+   if (ret)
+   return ret;
+
+   /* set clock rate */
+   ret = __clk_rcg2_set_rate(hw, rate, CEIL);
+   if (ret)
+   return ret;
+
+   return clk_rcg2_clear_force_enable(hw);
+}
+
+static int clk_rcg2_shared_set_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long parent_rate)
+{
+   struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+   int ret;
+
+   /*
+* Return if the RCG is currently 

[PATCH v2 1/4] clk: qcom: Clear hardware clock control bit of RCG

2018-03-07 Thread Amit Nischal
For upcoming targets like sdm845, POR value of the hardware clock control
bit is set for most of root clocks which needs to be cleared for software
to be able to control. For older targets like MSM8996, this bit is reserved
bit and having POR value as 0 so this patch will work for the older targets
too. So update the configuration mask to take care of the same to clear
hardware clock control bit.

Signed-off-by: Amit Nischal 
---
 drivers/clk/qcom/clk-rcg2.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index bbeaf9c..e63db10 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2013, 2018, The Linux Foundation. All rights reserved.
  *
  * This software is licensed under the terms of the GNU General Public
  * License version 2, as published by the Free Software Foundation, and
@@ -42,6 +42,7 @@
 #define CFG_MODE_SHIFT 12
 #define CFG_MODE_MASK  (0x3 << CFG_MODE_SHIFT)
 #define CFG_MODE_DUAL_EDGE (0x2 << CFG_MODE_SHIFT)
+#define CFG_HW_CLK_CTRL_MASK   BIT(20)

 #define M_REG  0x8
 #define N_REG  0xc
@@ -276,7 +277,7 @@ static int clk_rcg2_configure(struct clk_rcg2 *rcg, const 
struct freq_tbl *f)
}

mask = BIT(rcg->hid_width) - 1;
-   mask |= CFG_SRC_SEL_MASK | CFG_MODE_MASK;
+   mask |= CFG_SRC_SEL_MASK | CFG_MODE_MASK | CFG_HW_CLK_CTRL_MASK;
cfg = f->pre_div << CFG_SRC_DIV_SHIFT;
cfg |= rcg->parent_map[index].cfg << CFG_SRC_SEL_SHIFT;
if (rcg->mnd_width && f->n && (f->m != f->n))
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation



[PATCH v2 3/4] clk: qcom: Add support for controlling Fabia PLL

2018-03-07 Thread Amit Nischal
Fabia PLL is a Digital Frequency Locked Loop (DFLL) clock
generator which has a wide range of frequency output. It
supports dynamic updating of the output frequency
("frequency slewing") without need to turn off the PLL
before configuration. Add support for initial configuration
and programming sequence to control fabia PLLs.

Signed-off-by: Amit Nischal 
---
 drivers/clk/qcom/clk-alpha-pll.c | 324 ++-
 drivers/clk/qcom/clk-alpha-pll.h |  18 ++-
 2 files changed, 334 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index 6d04cd9..e6b8d62 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2015, 2018, The Linux Foundation. All rights reserved.
  *
  * This software is licensed under the terms of the GNU General Public
  * License version 2, as published by the Free Software Foundation, and
@@ -58,6 +58,8 @@
 #define PLL_TEST_CTL(p)((p)->offset + 
(p)->regs[PLL_OFF_TEST_CTL])
 #define PLL_TEST_CTL_U(p)  ((p)->offset + (p)->regs[PLL_OFF_TEST_CTL_U])
 #define PLL_STATUS(p)  ((p)->offset + (p)->regs[PLL_OFF_STATUS])
+#define PLL_OPMODE(p)  ((p)->offset + (p)->regs[PLL_OFF_OPMODE])
+#define PLL_FRAC(p)((p)->offset + (p)->regs[PLL_OFF_FRAC])

 const u8 clk_alpha_pll_regs[][PLL_OFF_MAX_REGS] = {
[CLK_ALPHA_PLL_TYPE_DEFAULT] =  {
@@ -90,6 +92,18 @@
[PLL_OFF_TEST_CTL] = 0x1c,
[PLL_OFF_STATUS] = 0x24,
},
+   [CLK_ALPHA_PLL_TYPE_FABIA] =  {
+   [PLL_OFF_L_VAL] = 0x04,
+   [PLL_OFF_USER_CTL] = 0x0c,
+   [PLL_OFF_USER_CTL_U] = 0x10,
+   [PLL_OFF_CONFIG_CTL] = 0x14,
+   [PLL_OFF_CONFIG_CTL_U] = 0x18,
+   [PLL_OFF_TEST_CTL] = 0x1c,
+   [PLL_OFF_TEST_CTL_U] = 0x20,
+   [PLL_OFF_STATUS] = 0x24,
+   [PLL_OFF_OPMODE] = 0x2c,
+   [PLL_OFF_FRAC] = 0x38,
+   },
 };
 EXPORT_SYMBOL_GPL(clk_alpha_pll_regs);

@@ -108,6 +122,12 @@
 #define PLL_HUAYRA_N_MASK  0xff
 #define PLL_HUAYRA_ALPHA_WIDTH 16

+#define FABIA_OPMODE_STANDBY   0x0
+#define FABIA_OPMODE_RUN   0x1
+
+#define FABIA_PLL_OUT_MASK 0x7
+#define FABIA_PLL_RATE_MARGIN  500
+
 #define pll_alpha_width(p) \
((PLL_ALPHA_VAL_U(p) - PLL_ALPHA_VAL(p) == 4) ? \
 ALPHA_REG_BITWIDTH : ALPHA_REG_16BIT_WIDTH)
@@ -441,16 +461,12 @@ static void clk_alpha_pll_disable(struct clk_hw *hw)
return alpha_pll_calc_rate(prate, l, a, alpha_width);
 }

-static int clk_alpha_pll_update_latch(struct clk_alpha_pll *pll,
- int (*is_enabled)(struct clk_hw *))
+
+static int __clk_alpha_pll_update_latch(struct clk_alpha_pll *pll)
 {
int ret;
u32 mode;

-   if (!is_enabled(>clkr.hw) ||
-   !(pll->flags & SUPPORTS_DYNAMIC_UPDATE))
-   return 0;
-
regmap_read(pll->clkr.regmap, PLL_MODE(pll), );

/* Latch the input to the PLL */
@@ -489,6 +505,16 @@ static int clk_alpha_pll_update_latch(struct clk_alpha_pll 
*pll,
return 0;
 }

+static int clk_alpha_pll_update_latch(struct clk_alpha_pll *pll,
+ int (*is_enabled)(struct clk_hw *))
+{
+   if (!is_enabled(>clkr.hw) ||
+   !(pll->flags & SUPPORTS_DYNAMIC_UPDATE))
+   return 0;
+
+   return __clk_alpha_pll_update_latch(pll);
+}
+
 static int __clk_alpha_pll_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long prate,
int (*is_enabled)(struct clk_hw *))
@@ -832,3 +858,287 @@ static int clk_alpha_pll_postdiv_set_rate(struct clk_hw 
*hw, unsigned long rate,
.recalc_rate = clk_alpha_pll_postdiv_recalc_rate,
 };
 EXPORT_SYMBOL_GPL(clk_alpha_pll_postdiv_ro_ops);
+
+void clk_fabia_pll_configure(struct clk_alpha_pll *pll, struct regmap *regmap,
+const struct alpha_pll_config *config)
+{
+   u32 val, mask;
+
+   if (config->l)
+   regmap_write(regmap, PLL_L_VAL(pll), config->l);
+
+   if (config->alpha)
+   regmap_write(regmap, PLL_FRAC(pll), config->alpha);
+
+   if (config->config_ctl_val)
+   regmap_write(regmap, PLL_CONFIG_CTL(pll),
+   config->config_ctl_val);
+
+   if (config->post_div_mask) {
+   mask = config->post_div_mask;
+   val = config->post_div_val;
+   regmap_update_bits(regmap, PLL_USER_CTL(pll), mask, val);
+   }
+
+   regmap_update_bits(regmap, PLL_MODE(pll), PLL_UPDATE_BYPASS,
+   

[PATCH v2 3/4] clk: qcom: Add support for controlling Fabia PLL

2018-03-07 Thread Amit Nischal
Fabia PLL is a Digital Frequency Locked Loop (DFLL) clock
generator which has a wide range of frequency output. It
supports dynamic updating of the output frequency
("frequency slewing") without need to turn off the PLL
before configuration. Add support for initial configuration
and programming sequence to control fabia PLLs.

Signed-off-by: Amit Nischal 
---
 drivers/clk/qcom/clk-alpha-pll.c | 324 ++-
 drivers/clk/qcom/clk-alpha-pll.h |  18 ++-
 2 files changed, 334 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index 6d04cd9..e6b8d62 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2015, 2018, The Linux Foundation. All rights reserved.
  *
  * This software is licensed under the terms of the GNU General Public
  * License version 2, as published by the Free Software Foundation, and
@@ -58,6 +58,8 @@
 #define PLL_TEST_CTL(p)((p)->offset + 
(p)->regs[PLL_OFF_TEST_CTL])
 #define PLL_TEST_CTL_U(p)  ((p)->offset + (p)->regs[PLL_OFF_TEST_CTL_U])
 #define PLL_STATUS(p)  ((p)->offset + (p)->regs[PLL_OFF_STATUS])
+#define PLL_OPMODE(p)  ((p)->offset + (p)->regs[PLL_OFF_OPMODE])
+#define PLL_FRAC(p)((p)->offset + (p)->regs[PLL_OFF_FRAC])

 const u8 clk_alpha_pll_regs[][PLL_OFF_MAX_REGS] = {
[CLK_ALPHA_PLL_TYPE_DEFAULT] =  {
@@ -90,6 +92,18 @@
[PLL_OFF_TEST_CTL] = 0x1c,
[PLL_OFF_STATUS] = 0x24,
},
+   [CLK_ALPHA_PLL_TYPE_FABIA] =  {
+   [PLL_OFF_L_VAL] = 0x04,
+   [PLL_OFF_USER_CTL] = 0x0c,
+   [PLL_OFF_USER_CTL_U] = 0x10,
+   [PLL_OFF_CONFIG_CTL] = 0x14,
+   [PLL_OFF_CONFIG_CTL_U] = 0x18,
+   [PLL_OFF_TEST_CTL] = 0x1c,
+   [PLL_OFF_TEST_CTL_U] = 0x20,
+   [PLL_OFF_STATUS] = 0x24,
+   [PLL_OFF_OPMODE] = 0x2c,
+   [PLL_OFF_FRAC] = 0x38,
+   },
 };
 EXPORT_SYMBOL_GPL(clk_alpha_pll_regs);

@@ -108,6 +122,12 @@
 #define PLL_HUAYRA_N_MASK  0xff
 #define PLL_HUAYRA_ALPHA_WIDTH 16

+#define FABIA_OPMODE_STANDBY   0x0
+#define FABIA_OPMODE_RUN   0x1
+
+#define FABIA_PLL_OUT_MASK 0x7
+#define FABIA_PLL_RATE_MARGIN  500
+
 #define pll_alpha_width(p) \
((PLL_ALPHA_VAL_U(p) - PLL_ALPHA_VAL(p) == 4) ? \
 ALPHA_REG_BITWIDTH : ALPHA_REG_16BIT_WIDTH)
@@ -441,16 +461,12 @@ static void clk_alpha_pll_disable(struct clk_hw *hw)
return alpha_pll_calc_rate(prate, l, a, alpha_width);
 }

-static int clk_alpha_pll_update_latch(struct clk_alpha_pll *pll,
- int (*is_enabled)(struct clk_hw *))
+
+static int __clk_alpha_pll_update_latch(struct clk_alpha_pll *pll)
 {
int ret;
u32 mode;

-   if (!is_enabled(>clkr.hw) ||
-   !(pll->flags & SUPPORTS_DYNAMIC_UPDATE))
-   return 0;
-
regmap_read(pll->clkr.regmap, PLL_MODE(pll), );

/* Latch the input to the PLL */
@@ -489,6 +505,16 @@ static int clk_alpha_pll_update_latch(struct clk_alpha_pll 
*pll,
return 0;
 }

+static int clk_alpha_pll_update_latch(struct clk_alpha_pll *pll,
+ int (*is_enabled)(struct clk_hw *))
+{
+   if (!is_enabled(>clkr.hw) ||
+   !(pll->flags & SUPPORTS_DYNAMIC_UPDATE))
+   return 0;
+
+   return __clk_alpha_pll_update_latch(pll);
+}
+
 static int __clk_alpha_pll_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long prate,
int (*is_enabled)(struct clk_hw *))
@@ -832,3 +858,287 @@ static int clk_alpha_pll_postdiv_set_rate(struct clk_hw 
*hw, unsigned long rate,
.recalc_rate = clk_alpha_pll_postdiv_recalc_rate,
 };
 EXPORT_SYMBOL_GPL(clk_alpha_pll_postdiv_ro_ops);
+
+void clk_fabia_pll_configure(struct clk_alpha_pll *pll, struct regmap *regmap,
+const struct alpha_pll_config *config)
+{
+   u32 val, mask;
+
+   if (config->l)
+   regmap_write(regmap, PLL_L_VAL(pll), config->l);
+
+   if (config->alpha)
+   regmap_write(regmap, PLL_FRAC(pll), config->alpha);
+
+   if (config->config_ctl_val)
+   regmap_write(regmap, PLL_CONFIG_CTL(pll),
+   config->config_ctl_val);
+
+   if (config->post_div_mask) {
+   mask = config->post_div_mask;
+   val = config->post_div_val;
+   regmap_update_bits(regmap, PLL_USER_CTL(pll), mask, val);
+   }
+
+   regmap_update_bits(regmap, PLL_MODE(pll), PLL_UPDATE_BYPASS,
+   PLL_UPDATE_BYPASS);
+
+   

[PATCH v2 0/4] Misc patches to support clocks for SDM845

2018-03-07 Thread Amit Nischal
Changes in v2:
Fixup for recalc_rate ops for clk_rcg2_shared_ops:
There could be few scenarios where shared clocks are configured
at rate other than CXO by boot. In those cases there would be a
mismatch between the rate calculated by the recalc shared ops
and the actual HW register configuration. Fix the same by adding
an additional check to read current src from CFG register and
make a decision based on that.

Changes in v1:
https://lkml.org/lkml/2018/1/31/209

This patch series does the miscellaneous changes to support
clock nodes for SDM845. Below are the major changes for
which the existing code does not have support.

1. Clear hardware clock control bit of RCGs where HW clock
   control bit is set by default so that software can control
   those root clocks.
2. Introduces clk_rcg2_shared_ops to support clock controller
   drivers for SDM845. With new shared ops, RCGs with shared
   branches will be configured to a safe source in disable
   path and actual RCG update configuration will be done in
   enable path instead of doing config update in set_rate.
   In set_rate(), just cache the rate instead of doing actual
   configuration update. Also each RCG in clock controller
   driver will have their own safe configuration frequency
   table to switch to safe frequency.
3. Add support for controlling Fabia PLL for which the support
   is not available in existing alpha PLL code.
4. Add Global Clock controller (GCC) driver for SDM845. This
   should allow most non-multimedia device drivers to probe
   and control their clocks.

Amit Nischal (3):
  clk: qcom: Clear hardware clock control bit of RCG
  clk: qcom: Configure the RCGs to a safe source as needed
  clk: qcom: Add support for controlling Fabia PLL

Taniya Das (1):
  clk: qcom: Add Global Clock controller (GCC) driver for SDM845

 .../devicetree/bindings/clock/qcom,gcc.txt |1 +
 drivers/clk/qcom/Kconfig   |   11 +
 drivers/clk/qcom/Makefile  |1 +
 drivers/clk/qcom/clk-alpha-pll.c   |  324 +-
 drivers/clk/qcom/clk-alpha-pll.h   |   18 +-
 drivers/clk/qcom/clk-rcg.h |8 +-
 drivers/clk/qcom/clk-rcg2.c|  160 +-
 drivers/clk/qcom/gcc-sdm845.c  | 3619 
 include/dt-bindings/clock/qcom,gcc-sdm845.h|  242 ++
 9 files changed, 4373 insertions(+), 11 deletions(-)
 create mode 100644 drivers/clk/qcom/gcc-sdm845.c
 create mode 100644 include/dt-bindings/clock/qcom,gcc-sdm845.h

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation



[PATCH v2 0/4] Misc patches to support clocks for SDM845

2018-03-07 Thread Amit Nischal
Changes in v2:
Fixup for recalc_rate ops for clk_rcg2_shared_ops:
There could be few scenarios where shared clocks are configured
at rate other than CXO by boot. In those cases there would be a
mismatch between the rate calculated by the recalc shared ops
and the actual HW register configuration. Fix the same by adding
an additional check to read current src from CFG register and
make a decision based on that.

Changes in v1:
https://lkml.org/lkml/2018/1/31/209

This patch series does the miscellaneous changes to support
clock nodes for SDM845. Below are the major changes for
which the existing code does not have support.

1. Clear hardware clock control bit of RCGs where HW clock
   control bit is set by default so that software can control
   those root clocks.
2. Introduces clk_rcg2_shared_ops to support clock controller
   drivers for SDM845. With new shared ops, RCGs with shared
   branches will be configured to a safe source in disable
   path and actual RCG update configuration will be done in
   enable path instead of doing config update in set_rate.
   In set_rate(), just cache the rate instead of doing actual
   configuration update. Also each RCG in clock controller
   driver will have their own safe configuration frequency
   table to switch to safe frequency.
3. Add support for controlling Fabia PLL for which the support
   is not available in existing alpha PLL code.
4. Add Global Clock controller (GCC) driver for SDM845. This
   should allow most non-multimedia device drivers to probe
   and control their clocks.

Amit Nischal (3):
  clk: qcom: Clear hardware clock control bit of RCG
  clk: qcom: Configure the RCGs to a safe source as needed
  clk: qcom: Add support for controlling Fabia PLL

Taniya Das (1):
  clk: qcom: Add Global Clock controller (GCC) driver for SDM845

 .../devicetree/bindings/clock/qcom,gcc.txt |1 +
 drivers/clk/qcom/Kconfig   |   11 +
 drivers/clk/qcom/Makefile  |1 +
 drivers/clk/qcom/clk-alpha-pll.c   |  324 +-
 drivers/clk/qcom/clk-alpha-pll.h   |   18 +-
 drivers/clk/qcom/clk-rcg.h |8 +-
 drivers/clk/qcom/clk-rcg2.c|  160 +-
 drivers/clk/qcom/gcc-sdm845.c  | 3619 
 include/dt-bindings/clock/qcom,gcc-sdm845.h|  242 ++
 9 files changed, 4373 insertions(+), 11 deletions(-)
 create mode 100644 drivers/clk/qcom/gcc-sdm845.c
 create mode 100644 include/dt-bindings/clock/qcom,gcc-sdm845.h

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation



[PATCH AUTOSEL for 4.15 02/78] drm/amdgpu: use polling mem to set SDMA3 wptr for VF

2018-03-07 Thread Sasha Levin
From: Pixel Ding 

[ Upstream commit 2ffe31deb27579e2f2c9444e01f4d8abf385d145 ]

On Tonga VF, there're 2 sources updating wptr registers for
sdma3: 1) polling mem and 2) doorbell. When doorbell and polling
mem are both enabled on sdma3, there will be collision hit in
occasion between those two sources when ucode and h/w are doing
the updating on wptr register in parallel. Issue doesn't happen
on CP GFX/Compute since CP drops all doorbell writes when VF is
inactive. So enable polling mem and don't use doorbell for SDMA3.

Signed-off-by: Pixel Ding 
Reviewed-by: Monk Liu 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  1 +
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c   | 27 +++
 2 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index b18c2b96691f..522a8742a60b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -187,6 +187,7 @@ struct amdgpu_ring {
uint64_teop_gpu_addr;
u32 doorbell_index;
booluse_doorbell;
+   booluse_pollmem;
unsignedwptr_offs;
unsignedfence_offs;
uint64_tcurrent_ctx;
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
index 6d06f8eb659f..cc4fc2e43b7b 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
@@ -355,7 +355,7 @@ static uint64_t sdma_v3_0_ring_get_wptr(struct amdgpu_ring 
*ring)
struct amdgpu_device *adev = ring->adev;
u32 wptr;
 
-   if (ring->use_doorbell) {
+   if (ring->use_doorbell || ring->use_pollmem) {
/* XXX check if swapping is necessary on BE */
wptr = ring->adev->wb.wb[ring->wptr_offs] >> 2;
} else {
@@ -380,10 +380,13 @@ static void sdma_v3_0_ring_set_wptr(struct amdgpu_ring 
*ring)
 
if (ring->use_doorbell) {
u32 *wb = (u32 *)>wb.wb[ring->wptr_offs];
-
/* XXX check if swapping is necessary on BE */
WRITE_ONCE(*wb, (lower_32_bits(ring->wptr) << 2));
WDOORBELL32(ring->doorbell_index, lower_32_bits(ring->wptr) << 
2);
+   } else if (ring->use_pollmem) {
+   u32 *wb = (u32 *)>wb.wb[ring->wptr_offs];
+
+   WRITE_ONCE(*wb, (lower_32_bits(ring->wptr) << 2));
} else {
int me = (ring == >adev->sdma.instance[0].ring) ? 0 : 1;
 
@@ -718,10 +721,14 @@ static int sdma_v3_0_gfx_resume(struct amdgpu_device 
*adev)
WREG32(mmSDMA0_GFX_RB_WPTR_POLL_ADDR_HI + sdma_offsets[i],
   upper_32_bits(wptr_gpu_addr));
wptr_poll_cntl = RREG32(mmSDMA0_GFX_RB_WPTR_POLL_CNTL + 
sdma_offsets[i]);
-   if (amdgpu_sriov_vf(adev))
-   wptr_poll_cntl = REG_SET_FIELD(wptr_poll_cntl, 
SDMA0_GFX_RB_WPTR_POLL_CNTL, F32_POLL_ENABLE, 1);
+   if (ring->use_pollmem)
+   wptr_poll_cntl = REG_SET_FIELD(wptr_poll_cntl,
+  
SDMA0_GFX_RB_WPTR_POLL_CNTL,
+  ENABLE, 1);
else
-   wptr_poll_cntl = REG_SET_FIELD(wptr_poll_cntl, 
SDMA0_GFX_RB_WPTR_POLL_CNTL, F32_POLL_ENABLE, 0);
+   wptr_poll_cntl = REG_SET_FIELD(wptr_poll_cntl,
+  
SDMA0_GFX_RB_WPTR_POLL_CNTL,
+  ENABLE, 0);
WREG32(mmSDMA0_GFX_RB_WPTR_POLL_CNTL + sdma_offsets[i], 
wptr_poll_cntl);
 
/* enable DMA RB */
@@ -1203,9 +1210,13 @@ static int sdma_v3_0_sw_init(void *handle)
for (i = 0; i < adev->sdma.num_instances; i++) {
ring = >sdma.instance[i].ring;
ring->ring_obj = NULL;
-   ring->use_doorbell = true;
-   ring->doorbell_index = (i == 0) ?
-   AMDGPU_DOORBELL_sDMA_ENGINE0 : 
AMDGPU_DOORBELL_sDMA_ENGINE1;
+   if (!amdgpu_sriov_vf(adev)) {
+   ring->use_doorbell = true;
+   ring->doorbell_index = (i == 0) ?
+   AMDGPU_DOORBELL_sDMA_ENGINE0 : 
AMDGPU_DOORBELL_sDMA_ENGINE1;
+   } else {
+   ring->use_pollmem = true;
+   }
 
sprintf(ring->name, "sdma%d", i);
r = amdgpu_ring_init(adev, ring, 1024,
-- 
2.14.1


[PATCH AUTOSEL for 4.15 02/78] drm/amdgpu: use polling mem to set SDMA3 wptr for VF

2018-03-07 Thread Sasha Levin
From: Pixel Ding 

[ Upstream commit 2ffe31deb27579e2f2c9444e01f4d8abf385d145 ]

On Tonga VF, there're 2 sources updating wptr registers for
sdma3: 1) polling mem and 2) doorbell. When doorbell and polling
mem are both enabled on sdma3, there will be collision hit in
occasion between those two sources when ucode and h/w are doing
the updating on wptr register in parallel. Issue doesn't happen
on CP GFX/Compute since CP drops all doorbell writes when VF is
inactive. So enable polling mem and don't use doorbell for SDMA3.

Signed-off-by: Pixel Ding 
Reviewed-by: Monk Liu 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |  1 +
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c   | 27 +++
 2 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index b18c2b96691f..522a8742a60b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -187,6 +187,7 @@ struct amdgpu_ring {
uint64_teop_gpu_addr;
u32 doorbell_index;
booluse_doorbell;
+   booluse_pollmem;
unsignedwptr_offs;
unsignedfence_offs;
uint64_tcurrent_ctx;
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
index 6d06f8eb659f..cc4fc2e43b7b 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
@@ -355,7 +355,7 @@ static uint64_t sdma_v3_0_ring_get_wptr(struct amdgpu_ring 
*ring)
struct amdgpu_device *adev = ring->adev;
u32 wptr;
 
-   if (ring->use_doorbell) {
+   if (ring->use_doorbell || ring->use_pollmem) {
/* XXX check if swapping is necessary on BE */
wptr = ring->adev->wb.wb[ring->wptr_offs] >> 2;
} else {
@@ -380,10 +380,13 @@ static void sdma_v3_0_ring_set_wptr(struct amdgpu_ring 
*ring)
 
if (ring->use_doorbell) {
u32 *wb = (u32 *)>wb.wb[ring->wptr_offs];
-
/* XXX check if swapping is necessary on BE */
WRITE_ONCE(*wb, (lower_32_bits(ring->wptr) << 2));
WDOORBELL32(ring->doorbell_index, lower_32_bits(ring->wptr) << 
2);
+   } else if (ring->use_pollmem) {
+   u32 *wb = (u32 *)>wb.wb[ring->wptr_offs];
+
+   WRITE_ONCE(*wb, (lower_32_bits(ring->wptr) << 2));
} else {
int me = (ring == >adev->sdma.instance[0].ring) ? 0 : 1;
 
@@ -718,10 +721,14 @@ static int sdma_v3_0_gfx_resume(struct amdgpu_device 
*adev)
WREG32(mmSDMA0_GFX_RB_WPTR_POLL_ADDR_HI + sdma_offsets[i],
   upper_32_bits(wptr_gpu_addr));
wptr_poll_cntl = RREG32(mmSDMA0_GFX_RB_WPTR_POLL_CNTL + 
sdma_offsets[i]);
-   if (amdgpu_sriov_vf(adev))
-   wptr_poll_cntl = REG_SET_FIELD(wptr_poll_cntl, 
SDMA0_GFX_RB_WPTR_POLL_CNTL, F32_POLL_ENABLE, 1);
+   if (ring->use_pollmem)
+   wptr_poll_cntl = REG_SET_FIELD(wptr_poll_cntl,
+  
SDMA0_GFX_RB_WPTR_POLL_CNTL,
+  ENABLE, 1);
else
-   wptr_poll_cntl = REG_SET_FIELD(wptr_poll_cntl, 
SDMA0_GFX_RB_WPTR_POLL_CNTL, F32_POLL_ENABLE, 0);
+   wptr_poll_cntl = REG_SET_FIELD(wptr_poll_cntl,
+  
SDMA0_GFX_RB_WPTR_POLL_CNTL,
+  ENABLE, 0);
WREG32(mmSDMA0_GFX_RB_WPTR_POLL_CNTL + sdma_offsets[i], 
wptr_poll_cntl);
 
/* enable DMA RB */
@@ -1203,9 +1210,13 @@ static int sdma_v3_0_sw_init(void *handle)
for (i = 0; i < adev->sdma.num_instances; i++) {
ring = >sdma.instance[i].ring;
ring->ring_obj = NULL;
-   ring->use_doorbell = true;
-   ring->doorbell_index = (i == 0) ?
-   AMDGPU_DOORBELL_sDMA_ENGINE0 : 
AMDGPU_DOORBELL_sDMA_ENGINE1;
+   if (!amdgpu_sriov_vf(adev)) {
+   ring->use_doorbell = true;
+   ring->doorbell_index = (i == 0) ?
+   AMDGPU_DOORBELL_sDMA_ENGINE0 : 
AMDGPU_DOORBELL_sDMA_ENGINE1;
+   } else {
+   ring->use_pollmem = true;
+   }
 
sprintf(ring->name, "sdma%d", i);
r = amdgpu_ring_init(adev, ring, 1024,
-- 
2.14.1


[PATCH AUTOSEL for 4.15 03/78] Bluetooth: hci_qca: Avoid setup failure on missing rampatch

2018-03-07 Thread Sasha Levin
From: Loic Poulain 

[ Upstream commit ba8f3597900291a93604643017fff66a14546015 ]

Assuming that the original code idea was to enable in-band sleeping
only if the setup_rome method returns succes and run in 'standard'
mode otherwise, we should not return setup_rome return value which
makes qca_setup fail if no rampatch/nvm file found.

This fixes BT issue on the dragonboard-820C p4 which includes the
following QCA controller:
hci0: Product:0x0008
hci0: Patch  :0x0111
hci0: ROM:0x0302
hci0: SOC:0x0044

Since there is no rampatch for this controller revision, just make
it work as is.

Signed-off-by: Loic Poulain 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 drivers/bluetooth/hci_qca.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index bbd7db7384e6..05ec530b8a3a 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -932,6 +932,9 @@ static int qca_setup(struct hci_uart *hu)
if (!ret) {
set_bit(STATE_IN_BAND_SLEEP_ENABLED, >flags);
qca_debugfs_init(hdev);
+   } else if (ret == -ENOENT) {
+   /* No patch/nvm-config found, run with original fw/config */
+   ret = 0;
}
 
/* Setup bdaddr */
-- 
2.14.1


[PATCH AUTOSEL for 4.15 03/78] Bluetooth: hci_qca: Avoid setup failure on missing rampatch

2018-03-07 Thread Sasha Levin
From: Loic Poulain 

[ Upstream commit ba8f3597900291a93604643017fff66a14546015 ]

Assuming that the original code idea was to enable in-band sleeping
only if the setup_rome method returns succes and run in 'standard'
mode otherwise, we should not return setup_rome return value which
makes qca_setup fail if no rampatch/nvm file found.

This fixes BT issue on the dragonboard-820C p4 which includes the
following QCA controller:
hci0: Product:0x0008
hci0: Patch  :0x0111
hci0: ROM:0x0302
hci0: SOC:0x0044

Since there is no rampatch for this controller revision, just make
it work as is.

Signed-off-by: Loic Poulain 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 drivers/bluetooth/hci_qca.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index bbd7db7384e6..05ec530b8a3a 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -932,6 +932,9 @@ static int qca_setup(struct hci_uart *hu)
if (!ret) {
set_bit(STATE_IN_BAND_SLEEP_ENABLED, >flags);
qca_debugfs_init(hdev);
+   } else if (ret == -ENOENT) {
+   /* No patch/nvm-config found, run with original fw/config */
+   ret = 0;
}
 
/* Setup bdaddr */
-- 
2.14.1


[PATCH AUTOSEL for 4.15 06/78] dt-bindings: net: add TI CC2560 Bluetooth chip

2018-03-07 Thread Sasha Levin
From: David Lechner 

[ Upstream commit 07c7edd0db441f83087470add5be280cc018 ]

This adds a compatible string for the Texas Instruments CC2560 Bluetooth
chip to the existing TI WiLink shared transport bindings. These chips are
similar enough that the same bindings work for both. The file is renamed
to ti-bluetooth.txt to make it more generic.

Signed-off-by: David Lechner 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 .../bindings/net/{ti,wilink-st.txt => ti-bluetooth.txt} | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)
 rename Documentation/devicetree/bindings/net/{ti,wilink-st.txt => 
ti-bluetooth.txt} (75%)

diff --git a/Documentation/devicetree/bindings/net/ti,wilink-st.txt 
b/Documentation/devicetree/bindings/net/ti-bluetooth.txt
similarity index 75%
rename from Documentation/devicetree/bindings/net/ti,wilink-st.txt
rename to Documentation/devicetree/bindings/net/ti-bluetooth.txt
index 1649c1f66b07..3690732750f0 100644
--- a/Documentation/devicetree/bindings/net/ti,wilink-st.txt
+++ b/Documentation/devicetree/bindings/net/ti-bluetooth.txt
@@ -1,10 +1,18 @@
-TI WiLink 7/8 (wl12xx/wl18xx) Shared Transport BT/FM/GPS devices
+Texas Instruments Bluetooth Chips
+-
+
+This documents the binding structure and common properties for serial
+attached TI Bluetooth devices. The following chips are included in this
+binding:
+
+* TI CC256x Bluetooth devices
+* TI WiLink 7/8 (wl12xx/wl18xx) Shared Transport BT/FM/GPS devices
 
 TI WiLink devices have a UART interface for providing Bluetooth, FM radio,
 and GPS over what's called "shared transport". The shared transport is
 standard BT HCI protocol with additional channels for the other functions.
 
-These devices also have a separate WiFi interface as described in
+TI WiLink devices also have a separate WiFi interface as described in
 wireless/ti,wlcore.txt.
 
 This bindings follows the UART slave device binding in
@@ -12,6 +20,7 @@ This bindings follows the UART slave device binding in
 
 Required properties:
  - compatible: should be one of the following:
+"ti,cc2560"
 "ti,wl1271-st"
 "ti,wl1273-st"
 "ti,wl1281-st"
-- 
2.14.1


[PATCH AUTOSEL for 4.15 06/78] dt-bindings: net: add TI CC2560 Bluetooth chip

2018-03-07 Thread Sasha Levin
From: David Lechner 

[ Upstream commit 07c7edd0db441f83087470add5be280cc018 ]

This adds a compatible string for the Texas Instruments CC2560 Bluetooth
chip to the existing TI WiLink shared transport bindings. These chips are
similar enough that the same bindings work for both. The file is renamed
to ti-bluetooth.txt to make it more generic.

Signed-off-by: David Lechner 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 .../bindings/net/{ti,wilink-st.txt => ti-bluetooth.txt} | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)
 rename Documentation/devicetree/bindings/net/{ti,wilink-st.txt => 
ti-bluetooth.txt} (75%)

diff --git a/Documentation/devicetree/bindings/net/ti,wilink-st.txt 
b/Documentation/devicetree/bindings/net/ti-bluetooth.txt
similarity index 75%
rename from Documentation/devicetree/bindings/net/ti,wilink-st.txt
rename to Documentation/devicetree/bindings/net/ti-bluetooth.txt
index 1649c1f66b07..3690732750f0 100644
--- a/Documentation/devicetree/bindings/net/ti,wilink-st.txt
+++ b/Documentation/devicetree/bindings/net/ti-bluetooth.txt
@@ -1,10 +1,18 @@
-TI WiLink 7/8 (wl12xx/wl18xx) Shared Transport BT/FM/GPS devices
+Texas Instruments Bluetooth Chips
+-
+
+This documents the binding structure and common properties for serial
+attached TI Bluetooth devices. The following chips are included in this
+binding:
+
+* TI CC256x Bluetooth devices
+* TI WiLink 7/8 (wl12xx/wl18xx) Shared Transport BT/FM/GPS devices
 
 TI WiLink devices have a UART interface for providing Bluetooth, FM radio,
 and GPS over what's called "shared transport". The shared transport is
 standard BT HCI protocol with additional channels for the other functions.
 
-These devices also have a separate WiFi interface as described in
+TI WiLink devices also have a separate WiFi interface as described in
 wireless/ti,wlcore.txt.
 
 This bindings follows the UART slave device binding in
@@ -12,6 +20,7 @@ This bindings follows the UART slave device binding in
 
 Required properties:
  - compatible: should be one of the following:
+"ti,cc2560"
 "ti,wl1271-st"
 "ti,wl1273-st"
 "ti,wl1281-st"
-- 
2.14.1


[PATCH 2/2] platform/x86: dell-*: Add interface for switchable graphics status query

2018-03-07 Thread Kai-Heng Feng
On some Dell platforms, there's a BIOS option "Enable Switchable
Graphics". This information is useful if we want to do different things
based on this value, e.g. disable unused audio controller that comes
with the discrete graphics.

Signed-off-by: Kai-Heng Feng 
---
 drivers/platform/x86/dell-laptop.c | 23 +++
 drivers/platform/x86/dell-smbios.c |  2 ++
 drivers/platform/x86/dell-smbios.h |  2 ++
 3 files changed, 27 insertions(+)

diff --git a/drivers/platform/x86/dell-laptop.c 
b/drivers/platform/x86/dell-laptop.c
index 8ba820e6c3d0..3f6fc07b8cf2 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -2116,6 +2116,29 @@ int dell_micmute_led_set(int state)
 }
 EXPORT_SYMBOL_GPL(dell_micmute_led_set);
 
+int dell_switchable_gfx_enabled(bool *enabled)
+{
+   struct calling_interface_buffer buffer;
+   struct calling_interface_token *token;
+   int ret;
+
+   *enabled = false;
+
+   token = dell_smbios_find_token(SWITCHABLE_GRAPHICS_ENABLE);
+   if (!token)
+   return -ENODEV;
+
+   dell_fill_request(, token->location, 0, 0, 0);
+   ret = dell_send_request(, CLASS_TOKEN_READ, SELECT_TOKEN_STD);
+   if (ret)
+   return ret;
+
+   *enabled = !!buffer.output[1];
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(dell_switchable_gfx_enabled);
+
 static int __init dell_init(void)
 {
struct calling_interface_token *token;
diff --git a/drivers/platform/x86/dell-smbios.c 
b/drivers/platform/x86/dell-smbios.c
index 8541cde4cb7d..ca38b9d9dcf4 100644
--- a/drivers/platform/x86/dell-smbios.c
+++ b/drivers/platform/x86/dell-smbios.c
@@ -86,6 +86,8 @@ struct token_range {
 static struct token_range token_whitelist[] = {
/* used by userspace: fwupdate */
{CAP_SYS_ADMIN, CAPSULE_EN_TOKEN,   CAPSULE_DIS_TOKEN},
+   /* can indicate to userspace Switchable Graphics enable status */
+   {CAP_SYS_ADMIN, SWITCHABLE_GRAPHICS_ENABLE, 
SWITCHABLE_GRAPHICS_DISABLE},
/* can indicate to userspace that WMI is needed */
{0x,WSMT_EN_TOKEN,  WSMT_DIS_TOKEN}
 };
diff --git a/drivers/platform/x86/dell-smbios.h 
b/drivers/platform/x86/dell-smbios.h
index 138d478d9adc..b012d4abd239 100644
--- a/drivers/platform/x86/dell-smbios.h
+++ b/drivers/platform/x86/dell-smbios.h
@@ -37,6 +37,8 @@
 #define KBD_LED_AUTO_100_TOKEN 0x02F6
 #define GLOBAL_MIC_MUTE_ENABLE 0x0364
 #define GLOBAL_MIC_MUTE_DISABLE0x0365
+#define SWITCHABLE_GRAPHICS_ENABLE 0x037A
+#define SWITCHABLE_GRAPHICS_DISABLE0x037B
 
 struct notifier_block;
 
-- 
2.15.1



[PATCH 2/2] platform/x86: dell-*: Add interface for switchable graphics status query

2018-03-07 Thread Kai-Heng Feng
On some Dell platforms, there's a BIOS option "Enable Switchable
Graphics". This information is useful if we want to do different things
based on this value, e.g. disable unused audio controller that comes
with the discrete graphics.

Signed-off-by: Kai-Heng Feng 
---
 drivers/platform/x86/dell-laptop.c | 23 +++
 drivers/platform/x86/dell-smbios.c |  2 ++
 drivers/platform/x86/dell-smbios.h |  2 ++
 3 files changed, 27 insertions(+)

diff --git a/drivers/platform/x86/dell-laptop.c 
b/drivers/platform/x86/dell-laptop.c
index 8ba820e6c3d0..3f6fc07b8cf2 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -2116,6 +2116,29 @@ int dell_micmute_led_set(int state)
 }
 EXPORT_SYMBOL_GPL(dell_micmute_led_set);
 
+int dell_switchable_gfx_enabled(bool *enabled)
+{
+   struct calling_interface_buffer buffer;
+   struct calling_interface_token *token;
+   int ret;
+
+   *enabled = false;
+
+   token = dell_smbios_find_token(SWITCHABLE_GRAPHICS_ENABLE);
+   if (!token)
+   return -ENODEV;
+
+   dell_fill_request(, token->location, 0, 0, 0);
+   ret = dell_send_request(, CLASS_TOKEN_READ, SELECT_TOKEN_STD);
+   if (ret)
+   return ret;
+
+   *enabled = !!buffer.output[1];
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(dell_switchable_gfx_enabled);
+
 static int __init dell_init(void)
 {
struct calling_interface_token *token;
diff --git a/drivers/platform/x86/dell-smbios.c 
b/drivers/platform/x86/dell-smbios.c
index 8541cde4cb7d..ca38b9d9dcf4 100644
--- a/drivers/platform/x86/dell-smbios.c
+++ b/drivers/platform/x86/dell-smbios.c
@@ -86,6 +86,8 @@ struct token_range {
 static struct token_range token_whitelist[] = {
/* used by userspace: fwupdate */
{CAP_SYS_ADMIN, CAPSULE_EN_TOKEN,   CAPSULE_DIS_TOKEN},
+   /* can indicate to userspace Switchable Graphics enable status */
+   {CAP_SYS_ADMIN, SWITCHABLE_GRAPHICS_ENABLE, 
SWITCHABLE_GRAPHICS_DISABLE},
/* can indicate to userspace that WMI is needed */
{0x,WSMT_EN_TOKEN,  WSMT_DIS_TOKEN}
 };
diff --git a/drivers/platform/x86/dell-smbios.h 
b/drivers/platform/x86/dell-smbios.h
index 138d478d9adc..b012d4abd239 100644
--- a/drivers/platform/x86/dell-smbios.h
+++ b/drivers/platform/x86/dell-smbios.h
@@ -37,6 +37,8 @@
 #define KBD_LED_AUTO_100_TOKEN 0x02F6
 #define GLOBAL_MIC_MUTE_ENABLE 0x0364
 #define GLOBAL_MIC_MUTE_DISABLE0x0365
+#define SWITCHABLE_GRAPHICS_ENABLE 0x037A
+#define SWITCHABLE_GRAPHICS_DISABLE0x037B
 
 struct notifier_block;
 
-- 
2.15.1



Re: [PATCH 4.15 000/122] 4.15.8-stable review

2018-03-07 Thread Naresh Kamboju
On 8 March 2018 at 01:06, Greg Kroah-Hartman  wrote:
> This is the start of the stable review cycle for the 4.15.8 release.
> There are 122 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri Mar  9 19:16:43 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.8-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

NOTE:
qemu_x86_64 LTP syscalls and fs tests failed (due to infrastructure issues) have
been resubmitted and updated results summary.

Summary


kernel: 4.15.8-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.15.y
git commit: 443c8ee3e9ef992816cca25f928f6870a3eb5c54
git describe: v4.15.7-123-g443c8ee3e9ef
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.15-oe/build/v4.15.7-123-g443c8ee3e9ef


No regressions (compared to build v4.15.7)

Boards, architectures and test suites:
-

dragonboard-410c
* boot - pass: 20,
* kselftest - pass: 46, skip: 19
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1002, skip: 148
* ltp-timers-tests - pass: 12, skip: 1

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 57, skip: 9
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 999, skip: 151
* ltp-timers-tests - pass: 12, skip: 1

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 56, skip: 10
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1001, skip: 149
* ltp-timers-tests - pass: 12, skip: 1

qemu_x86_64
* boot - pass: 20,
* kselftest - pass: 68, skip: 14
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 57, skip: 6
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1002, skip:  148
* ltp-timers-tests - pass: 12, skip: 1

x15 - arm
* boot - pass: 20,
* kselftest - pass: 53, skip: 12
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63, skip: 18
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 

Re: [PATCH 4.15 000/122] 4.15.8-stable review

2018-03-07 Thread Naresh Kamboju
On 8 March 2018 at 01:06, Greg Kroah-Hartman  wrote:
> This is the start of the stable review cycle for the 4.15.8 release.
> There are 122 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri Mar  9 19:16:43 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.8-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

NOTE:
qemu_x86_64 LTP syscalls and fs tests failed (due to infrastructure issues) have
been resubmitted and updated results summary.

Summary


kernel: 4.15.8-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.15.y
git commit: 443c8ee3e9ef992816cca25f928f6870a3eb5c54
git describe: v4.15.7-123-g443c8ee3e9ef
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.15-oe/build/v4.15.7-123-g443c8ee3e9ef


No regressions (compared to build v4.15.7)

Boards, architectures and test suites:
-

dragonboard-410c
* boot - pass: 20,
* kselftest - pass: 46, skip: 19
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1002, skip: 148
* ltp-timers-tests - pass: 12, skip: 1

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 57, skip: 9
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 999, skip: 151
* ltp-timers-tests - pass: 12, skip: 1

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 56, skip: 10
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1001, skip: 149
* ltp-timers-tests - pass: 12, skip: 1

qemu_x86_64
* boot - pass: 20,
* kselftest - pass: 68, skip: 14
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 57, skip: 6
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1002, skip:  148
* ltp-timers-tests - pass: 12, skip: 1

x15 - arm
* boot - pass: 20,
* kselftest - pass: 53, skip: 12
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63, skip: 18
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1053, skip: 97
* 

[PATCH 1/2] dell-led: Change dell-led.h to dell-common.h

2018-03-07 Thread Kai-Heng Feng
This header will be used for more than just led. Change it to a more
generic name.

Signed-off-by: Kai-Heng Feng 
---
 drivers/platform/x86/dell-laptop.c  | 2 +-
 include/linux/{dell-led.h => dell-common.h} | 4 ++--
 sound/pci/hda/dell_wmi_helper.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)
 rename include/linux/{dell-led.h => dell-common.h} (61%)

diff --git a/drivers/platform/x86/dell-laptop.c 
b/drivers/platform/x86/dell-laptop.c
index c52c6723374b..8ba820e6c3d0 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -29,7 +29,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include "dell-rbtn.h"
diff --git a/include/linux/dell-led.h b/include/linux/dell-common.h
similarity index 61%
rename from include/linux/dell-led.h
rename to include/linux/dell-common.h
index 92521471517f..37e4b614dd74 100644
--- a/include/linux/dell-led.h
+++ b/include/linux/dell-common.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __DELL_LED_H__
-#define __DELL_LED_H__
+#ifndef __DELL_COMMON_H__
+#define __DELL_COMMON_H__
 
 int dell_micmute_led_set(int on);
 
diff --git a/sound/pci/hda/dell_wmi_helper.c b/sound/pci/hda/dell_wmi_helper.c
index 1b48a8c19d28..56050cc3c0ee 100644
--- a/sound/pci/hda/dell_wmi_helper.c
+++ b/sound/pci/hda/dell_wmi_helper.c
@@ -4,7 +4,7 @@
  */
 
 #if IS_ENABLED(CONFIG_DELL_LAPTOP)
-#include 
+#include 
 
 enum {
MICMUTE_LED_ON,
-- 
2.15.1



[PATCH 1/2] dell-led: Change dell-led.h to dell-common.h

2018-03-07 Thread Kai-Heng Feng
This header will be used for more than just led. Change it to a more
generic name.

Signed-off-by: Kai-Heng Feng 
---
 drivers/platform/x86/dell-laptop.c  | 2 +-
 include/linux/{dell-led.h => dell-common.h} | 4 ++--
 sound/pci/hda/dell_wmi_helper.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)
 rename include/linux/{dell-led.h => dell-common.h} (61%)

diff --git a/drivers/platform/x86/dell-laptop.c 
b/drivers/platform/x86/dell-laptop.c
index c52c6723374b..8ba820e6c3d0 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -29,7 +29,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include "dell-rbtn.h"
diff --git a/include/linux/dell-led.h b/include/linux/dell-common.h
similarity index 61%
rename from include/linux/dell-led.h
rename to include/linux/dell-common.h
index 92521471517f..37e4b614dd74 100644
--- a/include/linux/dell-led.h
+++ b/include/linux/dell-common.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __DELL_LED_H__
-#define __DELL_LED_H__
+#ifndef __DELL_COMMON_H__
+#define __DELL_COMMON_H__
 
 int dell_micmute_led_set(int on);
 
diff --git a/sound/pci/hda/dell_wmi_helper.c b/sound/pci/hda/dell_wmi_helper.c
index 1b48a8c19d28..56050cc3c0ee 100644
--- a/sound/pci/hda/dell_wmi_helper.c
+++ b/sound/pci/hda/dell_wmi_helper.c
@@ -4,7 +4,7 @@
  */
 
 #if IS_ENABLED(CONFIG_DELL_LAPTOP)
-#include 
+#include 
 
 enum {
MICMUTE_LED_ON,
-- 
2.15.1



[PATCH AUTOSEL for 4.15 05/78] cpufreq: longhaul: Revert transition_delay_us to 200 ms

2018-03-07 Thread Sasha Levin
From: Viresh Kumar 

[ Upstream commit 1d0d064307cbfd8546841f6e9d94d02c55e45e1e ]

The commit e948bc8fbee0 ("cpufreq: Cap the default transition delay
value to 10 ms") caused a regression on EPIA-M min-ITX computer where
shutdown or reboot hangs occasionally with a print message like:

longhaul: Warning: Timeout while waiting for idle PCI bus
cpufreq: __target_index: Failed to change cpu frequency: -16

This probably happens because the cpufreq governor tries to change the
frequency of the CPU faster than allowed by the hardware.

Before the above commit, the default transition delay was set to 200 ms
for a transition_latency of 20 ns. Lets revert back to that
transition delay value to fix it. Note that several other transition
delay values were tested like 20 ms and 30 ms and none of them have
resolved system hang issue completely.

Fixes: e948bc8fbee0 (cpufreq: Cap the default transition delay value to 10 ms)
Reported-by: Meelis Roos 
Suggested-by: Rafael J. Wysocki 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin 
---
 drivers/cpufreq/longhaul.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c
index d5e27bc7585a..859a62ea6120 100644
--- a/drivers/cpufreq/longhaul.c
+++ b/drivers/cpufreq/longhaul.c
@@ -894,7 +894,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy)
if ((longhaul_version != TYPE_LONGHAUL_V1) && (scale_voltage != 0))
longhaul_setup_voltagescaling();
 
-   policy->cpuinfo.transition_latency = 20;/* nsec */
+   policy->transition_delay_us = 20;   /* usec */
 
return cpufreq_table_validate_and_show(policy, longhaul_table);
 }
-- 
2.14.1


[PATCH AUTOSEL for 4.15 05/78] cpufreq: longhaul: Revert transition_delay_us to 200 ms

2018-03-07 Thread Sasha Levin
From: Viresh Kumar 

[ Upstream commit 1d0d064307cbfd8546841f6e9d94d02c55e45e1e ]

The commit e948bc8fbee0 ("cpufreq: Cap the default transition delay
value to 10 ms") caused a regression on EPIA-M min-ITX computer where
shutdown or reboot hangs occasionally with a print message like:

longhaul: Warning: Timeout while waiting for idle PCI bus
cpufreq: __target_index: Failed to change cpu frequency: -16

This probably happens because the cpufreq governor tries to change the
frequency of the CPU faster than allowed by the hardware.

Before the above commit, the default transition delay was set to 200 ms
for a transition_latency of 20 ns. Lets revert back to that
transition delay value to fix it. Note that several other transition
delay values were tested like 20 ms and 30 ms and none of them have
resolved system hang issue completely.

Fixes: e948bc8fbee0 (cpufreq: Cap the default transition delay value to 10 ms)
Reported-by: Meelis Roos 
Suggested-by: Rafael J. Wysocki 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin 
---
 drivers/cpufreq/longhaul.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c
index d5e27bc7585a..859a62ea6120 100644
--- a/drivers/cpufreq/longhaul.c
+++ b/drivers/cpufreq/longhaul.c
@@ -894,7 +894,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy)
if ((longhaul_version != TYPE_LONGHAUL_V1) && (scale_voltage != 0))
longhaul_setup_voltagescaling();
 
-   policy->cpuinfo.transition_latency = 20;/* nsec */
+   policy->transition_delay_us = 20;   /* usec */
 
return cpufreq_table_validate_and_show(policy, longhaul_table);
 }
-- 
2.14.1


[PATCH AUTOSEL for 4.15 01/78] ipmi_si: Fix error handling of platform device

2018-03-07 Thread Sasha Levin
From: Corey Minyard 

[ Upstream commit 174134ac760275457bb0d1560a0dbe6cf8a12ad6 ]

Cleanup of platform devices created by the IPMI driver was not
being done correctly and could result in a memory leak.  So
create a local boolean to know how to clean up those platform
devices.

Reported-by: David Binderman 
Signed-off-by: Corey Minyard 
Signed-off-by: Sasha Levin 
---
 drivers/char/ipmi/ipmi_si_intf.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 71fad747c0c7..7499b0cd8326 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -2045,6 +2045,7 @@ static int try_smi_init(struct smi_info *new_smi)
int rv = 0;
int i;
char *init_name = NULL;
+   bool platform_device_registered = false;
 
pr_info(PFX "Trying %s-specified %s state machine at %s address 0x%lx, 
slave address 0x%x, irq %d\n",
ipmi_addr_src_to_str(new_smi->io.addr_source),
@@ -2173,6 +2174,7 @@ static int try_smi_init(struct smi_info *new_smi)
rv);
goto out_err;
}
+   platform_device_registered = true;
}
 
dev_set_drvdata(new_smi->io.dev, new_smi);
@@ -2279,10 +2281,11 @@ static int try_smi_init(struct smi_info *new_smi)
}
 
if (new_smi->pdev) {
-   platform_device_unregister(new_smi->pdev);
+   if (platform_device_registered)
+   platform_device_unregister(new_smi->pdev);
+   else
+   platform_device_put(new_smi->pdev);
new_smi->pdev = NULL;
-   } else if (new_smi->pdev) {
-   platform_device_put(new_smi->pdev);
}
 
kfree(init_name);
-- 
2.14.1


[PATCH AUTOSEL for 4.15 01/78] ipmi_si: Fix error handling of platform device

2018-03-07 Thread Sasha Levin
From: Corey Minyard 

[ Upstream commit 174134ac760275457bb0d1560a0dbe6cf8a12ad6 ]

Cleanup of platform devices created by the IPMI driver was not
being done correctly and could result in a memory leak.  So
create a local boolean to know how to clean up those platform
devices.

Reported-by: David Binderman 
Signed-off-by: Corey Minyard 
Signed-off-by: Sasha Levin 
---
 drivers/char/ipmi/ipmi_si_intf.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 71fad747c0c7..7499b0cd8326 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -2045,6 +2045,7 @@ static int try_smi_init(struct smi_info *new_smi)
int rv = 0;
int i;
char *init_name = NULL;
+   bool platform_device_registered = false;
 
pr_info(PFX "Trying %s-specified %s state machine at %s address 0x%lx, 
slave address 0x%x, irq %d\n",
ipmi_addr_src_to_str(new_smi->io.addr_source),
@@ -2173,6 +2174,7 @@ static int try_smi_init(struct smi_info *new_smi)
rv);
goto out_err;
}
+   platform_device_registered = true;
}
 
dev_set_drvdata(new_smi->io.dev, new_smi);
@@ -2279,10 +2281,11 @@ static int try_smi_init(struct smi_info *new_smi)
}
 
if (new_smi->pdev) {
-   platform_device_unregister(new_smi->pdev);
+   if (platform_device_registered)
+   platform_device_unregister(new_smi->pdev);
+   else
+   platform_device_put(new_smi->pdev);
new_smi->pdev = NULL;
-   } else if (new_smi->pdev) {
-   platform_device_put(new_smi->pdev);
}
 
kfree(init_name);
-- 
2.14.1


[PATCH AUTOSEL for 4.15 07/78] media: c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt

2018-03-07 Thread Sasha Levin
From: "Gustavo A. R. Silva" 

[ Upstream commit baed3c4bc4c13de93e0dba0a26d601411ebcb389 ]

_channel_ is being dereferenced before it is null checked, hence there is a
potential null pointer dereference. Fix this by moving the pointer dereference
after _channel_ has been null checked.

This issue was detected with the help of Coccinelle.

Fixes: c5f5d0f99794 ("[media] c8sectpfe: STiH407/10 Linux DVB demux support")

Signed-off-by: Gustavo A. R. Silva 
Acked-by: Patrice Chotard 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
---
 drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c 
b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
index a0acee7671b1..8bd19e61846d 100644
--- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
+++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
@@ -83,7 +83,7 @@ static void c8sectpfe_timer_interrupt(struct timer_list *t)
 static void channel_swdemux_tsklet(unsigned long data)
 {
struct channel_info *channel = (struct channel_info *)data;
-   struct c8sectpfei *fei = channel->fei;
+   struct c8sectpfei *fei;
unsigned long wp, rp;
int pos, num_packets, n, size;
u8 *buf;
@@ -91,6 +91,8 @@ static void channel_swdemux_tsklet(unsigned long data)
if (unlikely(!channel || !channel->irec))
return;
 
+   fei = channel->fei;
+
wp = readl(channel->irec + DMA_PRDS_BUSWP_TP(0));
rp = readl(channel->irec + DMA_PRDS_BUSRP_TP(0));
 
-- 
2.14.1


[PATCH AUTOSEL for 4.15 07/78] media: c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt

2018-03-07 Thread Sasha Levin
From: "Gustavo A. R. Silva" 

[ Upstream commit baed3c4bc4c13de93e0dba0a26d601411ebcb389 ]

_channel_ is being dereferenced before it is null checked, hence there is a
potential null pointer dereference. Fix this by moving the pointer dereference
after _channel_ has been null checked.

This issue was detected with the help of Coccinelle.

Fixes: c5f5d0f99794 ("[media] c8sectpfe: STiH407/10 Linux DVB demux support")

Signed-off-by: Gustavo A. R. Silva 
Acked-by: Patrice Chotard 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
---
 drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c 
b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
index a0acee7671b1..8bd19e61846d 100644
--- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
+++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
@@ -83,7 +83,7 @@ static void c8sectpfe_timer_interrupt(struct timer_list *t)
 static void channel_swdemux_tsklet(unsigned long data)
 {
struct channel_info *channel = (struct channel_info *)data;
-   struct c8sectpfei *fei = channel->fei;
+   struct c8sectpfei *fei;
unsigned long wp, rp;
int pos, num_packets, n, size;
u8 *buf;
@@ -91,6 +91,8 @@ static void channel_swdemux_tsklet(unsigned long data)
if (unlikely(!channel || !channel->irec))
return;
 
+   fei = channel->fei;
+
wp = readl(channel->irec + DMA_PRDS_BUSWP_TP(0));
rp = readl(channel->irec + DMA_PRDS_BUSRP_TP(0));
 
-- 
2.14.1


[PATCH AUTOSEL for 4.15 04/78] Bluetooth: btqcomsmd: Fix skb double free corruption

2018-03-07 Thread Sasha Levin
From: Loic Poulain 

[ Upstream commit 67b8fbead4685b36d290a0ef91c6ddffc4920ec9 ]

In case of hci send frame failure, skb is still owned
by the caller (hci_core) and then should not be freed.

This fixes crash on dragonboard-410c when sending SCO
packet. skb is freed by both btqcomsmd and hci_core.

Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver")
Signed-off-by: Loic Poulain 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 drivers/bluetooth/btqcomsmd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/btqcomsmd.c b/drivers/bluetooth/btqcomsmd.c
index 663bed63b871..2c9a5fc9137d 100644
--- a/drivers/bluetooth/btqcomsmd.c
+++ b/drivers/bluetooth/btqcomsmd.c
@@ -88,7 +88,8 @@ static int btqcomsmd_send(struct hci_dev *hdev, struct 
sk_buff *skb)
break;
}
 
-   kfree_skb(skb);
+   if (!ret)
+   kfree_skb(skb);
 
return ret;
 }
-- 
2.14.1


[PATCH AUTOSEL for 4.15 10/78] dm: ensure bio submission follows a depth-first tree walk

2018-03-07 Thread Sasha Levin
From: NeilBrown 

[ Upstream commit 18a25da84354c6bb655320de6072c00eda6eb602 ]

A dm device can, in general, represent a tree of targets, each of which
handles a sub-range of the range of blocks handled by the parent.

The bio sequencing managed by generic_make_request() requires that bios
are generated and handled in a depth-first manner.  Each call to a
make_request_fn() may submit bios to a single member device, and may
submit bios for a reduced region of the same device as the
make_request_fn.

In particular, any bios submitted to member devices must be expected to
be processed in order, so a later one must never wait for an earlier
one.

This ordering is usually achieved by using bio_split() to reduce a bio
to a size that can be completely handled by one target, and resubmitting
the remainder to the originating device. bio_queue_split() shows the
canonical approach.

dm doesn't follow this approach, largely because it has needed to split
bios since long before bio_split() was available.  It currently can
submit bios to separate targets within the one dm_make_request() call.
Dependencies between these targets, as can happen with dm-snap, can
cause deadlocks if either bios gets stuck behind the other in the queues
managed by generic_make_request().  This requires the 'rescue'
functionality provided by dm_offload_{start,end}.

Some of this requirement can be removed by changing the order of bio
submission to follow the canonical approach.  That is, if dm finds that
it needs to split a bio, the remainder should be sent to
generic_make_request() rather than being handled immediately.  This
delays the handling until the first part is completely processed, so the
deadlock problems do not occur.

__split_and_process_bio() can be called both from dm_make_request() and
from dm_wq_work().  When called from dm_wq_work() the current approach
is perfectly satisfactory as each bio will be processed immediately.
When called from dm_make_request(), current->bio_list will be non-NULL,
and in this case it is best to create a separate "clone" bio for the
remainder.

When we use bio_clone_bioset() to split off the front part of a bio
and chain the two together and submit the remainder to
generic_make_request(), it is important that the newly allocated
bio is used as the head to be processed immediately, and the original
bio gets "bio_advance()"d and sent to generic_make_request() as the
remainder.  Otherwise, if the newly allocated bio is used as the
remainder, and if it then needs to be split again, then the next
bio_clone_bioset() call will be made while holding a reference a bio
(result of the first clone) from the same bioset.  This can potentially
exhaust the bioset mempool and result in a memory allocation deadlock.

Note that there is no race caused by reassigning cio.io->bio after already
calling __map_bio().  This bio will only be dereferenced again after
dec_pending() has found io->io_count to be zero, and this cannot happen
before the dec_pending() call at the end of __split_and_process_bio().

To provide the clone bio when splitting, we use q->bio_split.  This
was previously being freed by bio-based dm to avoid having excess
rescuer threads.  As bio_split bio sets no longer create rescuer
threads, there is little cost and much gain from restoring the
q->bio_split bio set.

Signed-off-by: NeilBrown 
Signed-off-by: Mike Snitzer 
Signed-off-by: Sasha Levin 
---
 drivers/md/dm.c | 33 -
 1 file changed, 24 insertions(+), 9 deletions(-)

diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 1c42b00d3be2..04402d2ccb20 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -1499,8 +1499,29 @@ static void __split_and_process_bio(struct mapped_device 
*md,
} else {
ci.bio = bio;
ci.sector_count = bio_sectors(bio);
-   while (ci.sector_count && !error)
+   while (ci.sector_count && !error) {
error = __split_and_process_non_flush();
+   if (current->bio_list && ci.sector_count && !error) {
+   /*
+* Remainder must be passed to 
generic_make_request()
+* so that it gets handled *after* bios already 
submitted
+* have been completely processed.
+* We take a clone of the original to store in
+* ci.io->bio to be used by end_io_acct() and
+* for dec_pending to use for completion 
handling.
+* As this path is not used for 
REQ_OP_ZONE_REPORT,
+* the usage of io->bio in 
dm_remap_zone_report()
+* won't be affected by this reassignment.
+*/
+  

[PATCH AUTOSEL for 4.15 13/78] hv_netvsc: Fix the receive buffer size limit

2018-03-07 Thread Sasha Levin
From: Haiyang Zhang 

[ Upstream commit 11b2b653102571ac791885324371d9a1a17b900e ]

The max should be 31 MB on host with NVSP version > 2.

On legacy hosts (NVSP version <=2) only 15 MB receive buffer is allowed,
otherwise the buffer request will be rejected by the host, resulting
vNIC not coming up.

The NVSP version is only available after negotiation. So, we add the
limit checking for legacy hosts in netvsc_init_buf().

Fixes: 5023a6db73196 ("netvsc: increase default receive buffer size")
Signed-off-by: Haiyang Zhang 
Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/hyperv/hyperv_net.h | 6 --
 drivers/net/hyperv/netvsc.c | 5 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 88ddfb92122b..dab27e91b83b 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -635,9 +635,11 @@ struct nvsp_message {
 #define NETVSC_MTU 65535
 #define NETVSC_MTU_MIN ETH_MIN_MTU
 
-#define NETVSC_RECEIVE_BUFFER_SIZE (1024*1024*16)  /* 16MB */
-#define NETVSC_RECEIVE_BUFFER_SIZE_LEGACY  (1024*1024*15)  /* 15MB */
+/* Max buffer sizes allowed by a host */
+#define NETVSC_RECEIVE_BUFFER_SIZE (1024 * 1024 * 31) /* 31MB */
+#define NETVSC_RECEIVE_BUFFER_SIZE_LEGACY  (1024 * 1024 * 15) /* 15MB */
 #define NETVSC_SEND_BUFFER_SIZE(1024 * 1024 * 15)   /* 
15MB */
+
 #define NETVSC_INVALID_INDEX   -1
 
 #define NETVSC_SEND_SECTION_SIZE   6144
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index bfc79698b8f4..1e4f512fb90d 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -267,6 +267,11 @@ static int netvsc_init_buf(struct hv_device *device,
buf_size = device_info->recv_sections * device_info->recv_section_size;
buf_size = roundup(buf_size, PAGE_SIZE);
 
+   /* Legacy hosts only allow smaller receive buffer */
+   if (net_device->nvsp_version <= NVSP_PROTOCOL_VERSION_2)
+   buf_size = min_t(unsigned int, buf_size,
+NETVSC_RECEIVE_BUFFER_SIZE_LEGACY);
+
net_device->recv_buf = vzalloc(buf_size);
if (!net_device->recv_buf) {
netdev_err(ndev,
-- 
2.14.1


[PATCH AUTOSEL for 4.15 04/78] Bluetooth: btqcomsmd: Fix skb double free corruption

2018-03-07 Thread Sasha Levin
From: Loic Poulain 

[ Upstream commit 67b8fbead4685b36d290a0ef91c6ddffc4920ec9 ]

In case of hci send frame failure, skb is still owned
by the caller (hci_core) and then should not be freed.

This fixes crash on dragonboard-410c when sending SCO
packet. skb is freed by both btqcomsmd and hci_core.

Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver")
Signed-off-by: Loic Poulain 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Sasha Levin 
---
 drivers/bluetooth/btqcomsmd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/btqcomsmd.c b/drivers/bluetooth/btqcomsmd.c
index 663bed63b871..2c9a5fc9137d 100644
--- a/drivers/bluetooth/btqcomsmd.c
+++ b/drivers/bluetooth/btqcomsmd.c
@@ -88,7 +88,8 @@ static int btqcomsmd_send(struct hci_dev *hdev, struct 
sk_buff *skb)
break;
}
 
-   kfree_skb(skb);
+   if (!ret)
+   kfree_skb(skb);
 
return ret;
 }
-- 
2.14.1


[PATCH AUTOSEL for 4.15 10/78] dm: ensure bio submission follows a depth-first tree walk

2018-03-07 Thread Sasha Levin
From: NeilBrown 

[ Upstream commit 18a25da84354c6bb655320de6072c00eda6eb602 ]

A dm device can, in general, represent a tree of targets, each of which
handles a sub-range of the range of blocks handled by the parent.

The bio sequencing managed by generic_make_request() requires that bios
are generated and handled in a depth-first manner.  Each call to a
make_request_fn() may submit bios to a single member device, and may
submit bios for a reduced region of the same device as the
make_request_fn.

In particular, any bios submitted to member devices must be expected to
be processed in order, so a later one must never wait for an earlier
one.

This ordering is usually achieved by using bio_split() to reduce a bio
to a size that can be completely handled by one target, and resubmitting
the remainder to the originating device. bio_queue_split() shows the
canonical approach.

dm doesn't follow this approach, largely because it has needed to split
bios since long before bio_split() was available.  It currently can
submit bios to separate targets within the one dm_make_request() call.
Dependencies between these targets, as can happen with dm-snap, can
cause deadlocks if either bios gets stuck behind the other in the queues
managed by generic_make_request().  This requires the 'rescue'
functionality provided by dm_offload_{start,end}.

Some of this requirement can be removed by changing the order of bio
submission to follow the canonical approach.  That is, if dm finds that
it needs to split a bio, the remainder should be sent to
generic_make_request() rather than being handled immediately.  This
delays the handling until the first part is completely processed, so the
deadlock problems do not occur.

__split_and_process_bio() can be called both from dm_make_request() and
from dm_wq_work().  When called from dm_wq_work() the current approach
is perfectly satisfactory as each bio will be processed immediately.
When called from dm_make_request(), current->bio_list will be non-NULL,
and in this case it is best to create a separate "clone" bio for the
remainder.

When we use bio_clone_bioset() to split off the front part of a bio
and chain the two together and submit the remainder to
generic_make_request(), it is important that the newly allocated
bio is used as the head to be processed immediately, and the original
bio gets "bio_advance()"d and sent to generic_make_request() as the
remainder.  Otherwise, if the newly allocated bio is used as the
remainder, and if it then needs to be split again, then the next
bio_clone_bioset() call will be made while holding a reference a bio
(result of the first clone) from the same bioset.  This can potentially
exhaust the bioset mempool and result in a memory allocation deadlock.

Note that there is no race caused by reassigning cio.io->bio after already
calling __map_bio().  This bio will only be dereferenced again after
dec_pending() has found io->io_count to be zero, and this cannot happen
before the dec_pending() call at the end of __split_and_process_bio().

To provide the clone bio when splitting, we use q->bio_split.  This
was previously being freed by bio-based dm to avoid having excess
rescuer threads.  As bio_split bio sets no longer create rescuer
threads, there is little cost and much gain from restoring the
q->bio_split bio set.

Signed-off-by: NeilBrown 
Signed-off-by: Mike Snitzer 
Signed-off-by: Sasha Levin 
---
 drivers/md/dm.c | 33 -
 1 file changed, 24 insertions(+), 9 deletions(-)

diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 1c42b00d3be2..04402d2ccb20 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -1499,8 +1499,29 @@ static void __split_and_process_bio(struct mapped_device 
*md,
} else {
ci.bio = bio;
ci.sector_count = bio_sectors(bio);
-   while (ci.sector_count && !error)
+   while (ci.sector_count && !error) {
error = __split_and_process_non_flush();
+   if (current->bio_list && ci.sector_count && !error) {
+   /*
+* Remainder must be passed to 
generic_make_request()
+* so that it gets handled *after* bios already 
submitted
+* have been completely processed.
+* We take a clone of the original to store in
+* ci.io->bio to be used by end_io_acct() and
+* for dec_pending to use for completion 
handling.
+* As this path is not used for 
REQ_OP_ZONE_REPORT,
+* the usage of io->bio in 
dm_remap_zone_report()
+* won't be affected by this reassignment.
+*/
+   struct bio *b = bio_clone_bioset(bio, GFP_NOIO,
+ 

[PATCH AUTOSEL for 4.15 13/78] hv_netvsc: Fix the receive buffer size limit

2018-03-07 Thread Sasha Levin
From: Haiyang Zhang 

[ Upstream commit 11b2b653102571ac791885324371d9a1a17b900e ]

The max should be 31 MB on host with NVSP version > 2.

On legacy hosts (NVSP version <=2) only 15 MB receive buffer is allowed,
otherwise the buffer request will be rejected by the host, resulting
vNIC not coming up.

The NVSP version is only available after negotiation. So, we add the
limit checking for legacy hosts in netvsc_init_buf().

Fixes: 5023a6db73196 ("netvsc: increase default receive buffer size")
Signed-off-by: Haiyang Zhang 
Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/hyperv/hyperv_net.h | 6 --
 drivers/net/hyperv/netvsc.c | 5 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 88ddfb92122b..dab27e91b83b 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -635,9 +635,11 @@ struct nvsp_message {
 #define NETVSC_MTU 65535
 #define NETVSC_MTU_MIN ETH_MIN_MTU
 
-#define NETVSC_RECEIVE_BUFFER_SIZE (1024*1024*16)  /* 16MB */
-#define NETVSC_RECEIVE_BUFFER_SIZE_LEGACY  (1024*1024*15)  /* 15MB */
+/* Max buffer sizes allowed by a host */
+#define NETVSC_RECEIVE_BUFFER_SIZE (1024 * 1024 * 31) /* 31MB */
+#define NETVSC_RECEIVE_BUFFER_SIZE_LEGACY  (1024 * 1024 * 15) /* 15MB */
 #define NETVSC_SEND_BUFFER_SIZE(1024 * 1024 * 15)   /* 
15MB */
+
 #define NETVSC_INVALID_INDEX   -1
 
 #define NETVSC_SEND_SECTION_SIZE   6144
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index bfc79698b8f4..1e4f512fb90d 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -267,6 +267,11 @@ static int netvsc_init_buf(struct hv_device *device,
buf_size = device_info->recv_sections * device_info->recv_section_size;
buf_size = roundup(buf_size, PAGE_SIZE);
 
+   /* Legacy hosts only allow smaller receive buffer */
+   if (net_device->nvsp_version <= NVSP_PROTOCOL_VERSION_2)
+   buf_size = min_t(unsigned int, buf_size,
+NETVSC_RECEIVE_BUFFER_SIZE_LEGACY);
+
net_device->recv_buf = vzalloc(buf_size);
if (!net_device->recv_buf) {
netdev_err(ndev,
-- 
2.14.1


[PATCH AUTOSEL for 4.15 11/78] IB/ipoib: Warn when one port fails to initialize

2018-03-07 Thread Sasha Levin
From: Yuval Shaia 

[ Upstream commit ac6dbf7fa4707c75a247b540cc0b5c881f3d0ba8 ]

If one port fails to initialize an error message should indicate the
reason and driver should continue serving the working port(s) and other
HCA(s).

Fixes: e4b2d06892c7 ("IB/ipoib: Remove device when one port fails to init").
Signed-off-by: Yuval Shaia 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/ulp/ipoib/ipoib_main.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c 
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 8880351df179..c35c28015f8e 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -2207,8 +2207,10 @@ static struct net_device *ipoib_add_port(const char 
*format,
int result = -ENOMEM;
 
priv = ipoib_intf_alloc(hca, port, format);
-   if (!priv)
+   if (!priv) {
+   pr_warn("%s, %d: ipoib_intf_alloc failed\n", hca->name, port);
goto alloc_mem_failed;
+   }
 
SET_NETDEV_DEV(priv->dev, hca->dev.parent);
priv->dev->dev_id = port - 1;
@@ -2337,8 +2339,7 @@ static void ipoib_add_one(struct ib_device *device)
}
 
if (!count) {
-   pr_err("Failed to init port, removing it\n");
-   ipoib_remove_one(device, dev_list);
+   kfree(dev_list);
return;
}
 
-- 
2.14.1


[PATCH AUTOSEL for 4.15 11/78] IB/ipoib: Warn when one port fails to initialize

2018-03-07 Thread Sasha Levin
From: Yuval Shaia 

[ Upstream commit ac6dbf7fa4707c75a247b540cc0b5c881f3d0ba8 ]

If one port fails to initialize an error message should indicate the
reason and driver should continue serving the working port(s) and other
HCA(s).

Fixes: e4b2d06892c7 ("IB/ipoib: Remove device when one port fails to init").
Signed-off-by: Yuval Shaia 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/ulp/ipoib/ipoib_main.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c 
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 8880351df179..c35c28015f8e 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -2207,8 +2207,10 @@ static struct net_device *ipoib_add_port(const char 
*format,
int result = -ENOMEM;
 
priv = ipoib_intf_alloc(hca, port, format);
-   if (!priv)
+   if (!priv) {
+   pr_warn("%s, %d: ipoib_intf_alloc failed\n", hca->name, port);
goto alloc_mem_failed;
+   }
 
SET_NETDEV_DEV(priv->dev, hca->dev.parent);
priv->dev->dev_id = port - 1;
@@ -2337,8 +2339,7 @@ static void ipoib_add_one(struct ib_device *device)
}
 
if (!count) {
-   pr_err("Failed to init port, removing it\n");
-   ipoib_remove_one(device, dev_list);
+   kfree(dev_list);
return;
}
 
-- 
2.14.1


[PATCH AUTOSEL for 4.15 08/78] drm/msm: fix leak in failed get_pages

2018-03-07 Thread Sasha Levin
From: Prakash Kamliya 

[ Upstream commit 62e3a3e342af3c313ab38603811ecdb1fcc79edb ]

get_pages doesn't keep a reference of the pages allocated
when it fails later in the code path. This can lead to
a memory leak. Keep reference of the allocated pages so
that it can be freed when msm_gem_free_object gets called
later during cleanup.

Signed-off-by: Prakash Kamliya 
Signed-off-by: Sharat Masetty 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/msm_gem.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 81fe6d6740ce..07376de9ff4c 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -93,14 +93,17 @@ static struct page **get_pages(struct drm_gem_object *obj)
return p;
}
 
+   msm_obj->pages = p;
+
msm_obj->sgt = drm_prime_pages_to_sg(p, npages);
if (IS_ERR(msm_obj->sgt)) {
+   void *ptr = ERR_CAST(msm_obj->sgt);
+
dev_err(dev->dev, "failed to allocate sgt\n");
-   return ERR_CAST(msm_obj->sgt);
+   msm_obj->sgt = NULL;
+   return ptr;
}
 
-   msm_obj->pages = p;
-
/* For non-cached buffers, ensure the new pages are clean
 * because display controller, GPU, etc. are not coherent:
 */
@@ -135,7 +138,10 @@ static void put_pages(struct drm_gem_object *obj)
if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
-   sg_free_table(msm_obj->sgt);
+
+   if (msm_obj->sgt)
+   sg_free_table(msm_obj->sgt);
+
kfree(msm_obj->sgt);
 
if (use_pages(obj))
-- 
2.14.1


[PATCH AUTOSEL for 4.15 08/78] drm/msm: fix leak in failed get_pages

2018-03-07 Thread Sasha Levin
From: Prakash Kamliya 

[ Upstream commit 62e3a3e342af3c313ab38603811ecdb1fcc79edb ]

get_pages doesn't keep a reference of the pages allocated
when it fails later in the code path. This can lead to
a memory leak. Keep reference of the allocated pages so
that it can be freed when msm_gem_free_object gets called
later during cleanup.

Signed-off-by: Prakash Kamliya 
Signed-off-by: Sharat Masetty 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/msm_gem.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 81fe6d6740ce..07376de9ff4c 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -93,14 +93,17 @@ static struct page **get_pages(struct drm_gem_object *obj)
return p;
}
 
+   msm_obj->pages = p;
+
msm_obj->sgt = drm_prime_pages_to_sg(p, npages);
if (IS_ERR(msm_obj->sgt)) {
+   void *ptr = ERR_CAST(msm_obj->sgt);
+
dev_err(dev->dev, "failed to allocate sgt\n");
-   return ERR_CAST(msm_obj->sgt);
+   msm_obj->sgt = NULL;
+   return ptr;
}
 
-   msm_obj->pages = p;
-
/* For non-cached buffers, ensure the new pages are clean
 * because display controller, GPU, etc. are not coherent:
 */
@@ -135,7 +138,10 @@ static void put_pages(struct drm_gem_object *obj)
if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
-   sg_free_table(msm_obj->sgt);
+
+   if (msm_obj->sgt)
+   sg_free_table(msm_obj->sgt);
+
kfree(msm_obj->sgt);
 
if (use_pages(obj))
-- 
2.14.1


[PATCH AUTOSEL for 4.15 16/78] KVM: x86: add support for emulating UMIP

2018-03-07 Thread Sasha Levin
From: Paolo Bonzini 

[ Upstream commit 66336cab3531d3325ebde36a047250c42cb5 ]

The User-Mode Instruction Prevention feature present in recent Intel
processor prevents a group of instructions (sgdt, sidt, sldt, smsw, and
str) from being executed with CPL > 0. Otherwise, a general protection
fault is issued.

UMIP instructions in general are also able to trigger vmexits, so we can
actually emulate UMIP on older processors.  This commit sets up the
infrastructure so that kvm-intel.ko and kvm-amd.ko can set the UMIP
feature bit for CPUID even if the feature is not actually available
in hardware.

Reviewed-by: Wanpeng Li 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Sasha Levin 
---
 arch/x86/include/asm/kvm_host.h | 1 +
 arch/x86/kvm/cpuid.c| 2 ++
 arch/x86/kvm/svm.c  | 6 ++
 arch/x86/kvm/vmx.c  | 6 ++
 4 files changed, 15 insertions(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 516798431328..c02c7a47eae9 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1017,6 +1017,7 @@ struct kvm_x86_ops {
void (*handle_external_intr)(struct kvm_vcpu *vcpu);
bool (*mpx_supported)(void);
bool (*xsaves_supported)(void);
+   bool (*umip_emulated)(void);
 
int (*check_nested_events)(struct kvm_vcpu *vcpu, bool external_intr);
 
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 13f5d4217e4f..f3fc225f5ebb 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -325,6 +325,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
unsigned f_invpcid = kvm_x86_ops->invpcid_supported() ? F(INVPCID) : 0;
unsigned f_mpx = kvm_mpx_supported() ? F(MPX) : 0;
unsigned f_xsaves = kvm_x86_ops->xsaves_supported() ? F(XSAVES) : 0;
+   unsigned f_umip = kvm_x86_ops->umip_emulated() ? F(UMIP) : 0;
 
/* cpuid 1.edx */
const u32 kvm_cpuid_1_edx_x86_features =
@@ -476,6 +477,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
entry->ebx |= F(TSC_ADJUST);
entry->ecx &= kvm_cpuid_7_0_ecx_x86_features;
cpuid_mask(>ecx, CPUID_7_ECX);
+   entry->ecx |= f_umip;
/* PKU is not yet implemented for shadow paging. */
if (!tdp_enabled || !boot_cpu_has(X86_FEATURE_OSPKE))
entry->ecx &= ~F(PKU);
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 4e3c79530526..fb606ee6f93d 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5336,6 +5336,11 @@ static bool svm_xsaves_supported(void)
return false;
 }
 
+static bool svm_umip_emulated(void)
+{
+   return false;
+}
+
 static bool svm_has_wbinvd_exit(void)
 {
return true;
@@ -5729,6 +5734,7 @@ static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
.invpcid_supported = svm_invpcid_supported,
.mpx_supported = svm_mpx_supported,
.xsaves_supported = svm_xsaves_supported,
+   .umip_emulated = svm_umip_emulated,
 
.set_supported_cpuid = svm_set_supported_cpuid,
 
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 561d8937fac5..24746d0b2b8e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -9224,6 +9224,11 @@ static bool vmx_xsaves_supported(void)
SECONDARY_EXEC_XSAVES;
 }
 
+static bool vmx_umip_emulated(void)
+{
+   return false;
+}
+
 static void vmx_recover_nmi_blocking(struct vcpu_vmx *vmx)
 {
u32 exit_intr_info;
@@ -12314,6 +12319,7 @@ static struct kvm_x86_ops vmx_x86_ops __ro_after_init = 
{
.handle_external_intr = vmx_handle_external_intr,
.mpx_supported = vmx_mpx_supported,
.xsaves_supported = vmx_xsaves_supported,
+   .umip_emulated = vmx_umip_emulated,
 
.check_nested_events = vmx_check_nested_events,
 
-- 
2.14.1


[PATCH AUTOSEL for 4.15 16/78] KVM: x86: add support for emulating UMIP

2018-03-07 Thread Sasha Levin
From: Paolo Bonzini 

[ Upstream commit 66336cab3531d3325ebde36a047250c42cb5 ]

The User-Mode Instruction Prevention feature present in recent Intel
processor prevents a group of instructions (sgdt, sidt, sldt, smsw, and
str) from being executed with CPL > 0. Otherwise, a general protection
fault is issued.

UMIP instructions in general are also able to trigger vmexits, so we can
actually emulate UMIP on older processors.  This commit sets up the
infrastructure so that kvm-intel.ko and kvm-amd.ko can set the UMIP
feature bit for CPUID even if the feature is not actually available
in hardware.

Reviewed-by: Wanpeng Li 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Sasha Levin 
---
 arch/x86/include/asm/kvm_host.h | 1 +
 arch/x86/kvm/cpuid.c| 2 ++
 arch/x86/kvm/svm.c  | 6 ++
 arch/x86/kvm/vmx.c  | 6 ++
 4 files changed, 15 insertions(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 516798431328..c02c7a47eae9 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1017,6 +1017,7 @@ struct kvm_x86_ops {
void (*handle_external_intr)(struct kvm_vcpu *vcpu);
bool (*mpx_supported)(void);
bool (*xsaves_supported)(void);
+   bool (*umip_emulated)(void);
 
int (*check_nested_events)(struct kvm_vcpu *vcpu, bool external_intr);
 
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 13f5d4217e4f..f3fc225f5ebb 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -325,6 +325,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
unsigned f_invpcid = kvm_x86_ops->invpcid_supported() ? F(INVPCID) : 0;
unsigned f_mpx = kvm_mpx_supported() ? F(MPX) : 0;
unsigned f_xsaves = kvm_x86_ops->xsaves_supported() ? F(XSAVES) : 0;
+   unsigned f_umip = kvm_x86_ops->umip_emulated() ? F(UMIP) : 0;
 
/* cpuid 1.edx */
const u32 kvm_cpuid_1_edx_x86_features =
@@ -476,6 +477,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
entry->ebx |= F(TSC_ADJUST);
entry->ecx &= kvm_cpuid_7_0_ecx_x86_features;
cpuid_mask(>ecx, CPUID_7_ECX);
+   entry->ecx |= f_umip;
/* PKU is not yet implemented for shadow paging. */
if (!tdp_enabled || !boot_cpu_has(X86_FEATURE_OSPKE))
entry->ecx &= ~F(PKU);
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 4e3c79530526..fb606ee6f93d 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5336,6 +5336,11 @@ static bool svm_xsaves_supported(void)
return false;
 }
 
+static bool svm_umip_emulated(void)
+{
+   return false;
+}
+
 static bool svm_has_wbinvd_exit(void)
 {
return true;
@@ -5729,6 +5734,7 @@ static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
.invpcid_supported = svm_invpcid_supported,
.mpx_supported = svm_mpx_supported,
.xsaves_supported = svm_xsaves_supported,
+   .umip_emulated = svm_umip_emulated,
 
.set_supported_cpuid = svm_set_supported_cpuid,
 
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 561d8937fac5..24746d0b2b8e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -9224,6 +9224,11 @@ static bool vmx_xsaves_supported(void)
SECONDARY_EXEC_XSAVES;
 }
 
+static bool vmx_umip_emulated(void)
+{
+   return false;
+}
+
 static void vmx_recover_nmi_blocking(struct vcpu_vmx *vmx)
 {
u32 exit_intr_info;
@@ -12314,6 +12319,7 @@ static struct kvm_x86_ops vmx_x86_ops __ro_after_init = 
{
.handle_external_intr = vmx_handle_external_intr,
.mpx_supported = vmx_mpx_supported,
.xsaves_supported = vmx_xsaves_supported,
+   .umip_emulated = vmx_umip_emulated,
 
.check_nested_events = vmx_check_nested_events,
 
-- 
2.14.1


[PATCH AUTOSEL for 4.15 12/78] RDMA/iwpm: Fix uninitialized error code in iwpm_send_mapinfo()

2018-03-07 Thread Sasha Levin
From: Geert Uytterhoeven 

[ Upstream commit 302d6424e4a293a5761997e6c9fc3dfb1e4c355f ]

With gcc-4.1.2:

drivers/infiniband/core/iwpm_util.c: In function ‘iwpm_send_mapinfo’:
drivers/infiniband/core/iwpm_util.c:647: warning: ‘ret’ may be used 
uninitialized in this function

Indeed, if nl_client is not found in any of the scanned has buckets, ret
will be used uninitialized.

Preinitialize ret to -EINVAL to fix this.

Fixes: 30dc5e63d6a5ad24 ("RDMA/core: Add support for iWARP Port Mapper user 
space service")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Tatyana Nikolova 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/core/iwpm_util.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/infiniband/core/iwpm_util.c 
b/drivers/infiniband/core/iwpm_util.c
index 3c4faadb8cdd..81528f64061a 100644
--- a/drivers/infiniband/core/iwpm_util.c
+++ b/drivers/infiniband/core/iwpm_util.c
@@ -654,6 +654,7 @@ int iwpm_send_mapinfo(u8 nl_client, int iwpm_pid)
}
skb_num++;
spin_lock_irqsave(_mapinfo_lock, flags);
+   ret = -EINVAL;
for (i = 0; i < IWPM_MAPINFO_HASH_SIZE; i++) {
hlist_for_each_entry(map_info, _hash_bucket[i],
 hlist_node) {
-- 
2.14.1


[PATCH AUTOSEL for 4.15 12/78] RDMA/iwpm: Fix uninitialized error code in iwpm_send_mapinfo()

2018-03-07 Thread Sasha Levin
From: Geert Uytterhoeven 

[ Upstream commit 302d6424e4a293a5761997e6c9fc3dfb1e4c355f ]

With gcc-4.1.2:

drivers/infiniband/core/iwpm_util.c: In function ‘iwpm_send_mapinfo’:
drivers/infiniband/core/iwpm_util.c:647: warning: ‘ret’ may be used 
uninitialized in this function

Indeed, if nl_client is not found in any of the scanned has buckets, ret
will be used uninitialized.

Preinitialize ret to -EINVAL to fix this.

Fixes: 30dc5e63d6a5ad24 ("RDMA/core: Add support for iWARP Port Mapper user 
space service")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Tatyana Nikolova 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/core/iwpm_util.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/infiniband/core/iwpm_util.c 
b/drivers/infiniband/core/iwpm_util.c
index 3c4faadb8cdd..81528f64061a 100644
--- a/drivers/infiniband/core/iwpm_util.c
+++ b/drivers/infiniband/core/iwpm_util.c
@@ -654,6 +654,7 @@ int iwpm_send_mapinfo(u8 nl_client, int iwpm_pid)
}
skb_num++;
spin_lock_irqsave(_mapinfo_lock, flags);
+   ret = -EINVAL;
for (i = 0; i < IWPM_MAPINFO_HASH_SIZE; i++) {
hlist_for_each_entry(map_info, _hash_bucket[i],
 hlist_node) {
-- 
2.14.1


Re: [PATCH] kbuild: Handle builtin dtb files containing hyphens

2018-03-07 Thread James Hogan
On Wed, Mar 07, 2018 at 03:19:11PM -0800, Frank Rowand wrote:
> On 03/07/18 12:25, James Hogan wrote:
> > On Wed, Mar 07, 2018 at 12:11:41PM -0800, Frank Rowand wrote:
> >> On 03/07/18 06:06, James Hogan wrote:
> >>> Quite a lot of dts files have hyphens, but its only a problem on MIPS
> >>> where such files can be built into the kernel. For example when
> >>> CONFIG_DT_NETGEAR_CVG834G=y, or on BMIPS kernels when the dtbs target is
> >>> used (in the latter case it admitedly shouldn't really build all the
> >>> dtb.o files, but thats a separate issue).

> > I'll keep the paragraph about MIPS and the example configuration though,
> > as I think its important information to reproduce the problem, and to
> > justify why it wouldn't be appropriate to just rename the files (which
> > was my first reaction).
> 
> Other than the part that says "its only a problem on MIPS".  That is
> pedantically correct because no other architecture (that I am aware
> of, not that I searched) currently has a devicetree source file name
> with a hyphen in it, where that file is compiled into the kernel as
> an asm file.  But it is potentially a problem on any architecture
> to it is misleading to label it as MIPS only.

Okay I'll reword to make it clearer and do a v2.

Thanks
James


signature.asc
Description: Digital signature


Re: [PATCH] kbuild: Handle builtin dtb files containing hyphens

2018-03-07 Thread James Hogan
On Wed, Mar 07, 2018 at 03:19:11PM -0800, Frank Rowand wrote:
> On 03/07/18 12:25, James Hogan wrote:
> > On Wed, Mar 07, 2018 at 12:11:41PM -0800, Frank Rowand wrote:
> >> On 03/07/18 06:06, James Hogan wrote:
> >>> Quite a lot of dts files have hyphens, but its only a problem on MIPS
> >>> where such files can be built into the kernel. For example when
> >>> CONFIG_DT_NETGEAR_CVG834G=y, or on BMIPS kernels when the dtbs target is
> >>> used (in the latter case it admitedly shouldn't really build all the
> >>> dtb.o files, but thats a separate issue).

> > I'll keep the paragraph about MIPS and the example configuration though,
> > as I think its important information to reproduce the problem, and to
> > justify why it wouldn't be appropriate to just rename the files (which
> > was my first reaction).
> 
> Other than the part that says "its only a problem on MIPS".  That is
> pedantically correct because no other architecture (that I am aware
> of, not that I searched) currently has a devicetree source file name
> with a hyphen in it, where that file is compiled into the kernel as
> an asm file.  But it is potentially a problem on any architecture
> to it is misleading to label it as MIPS only.

Okay I'll reword to make it clearer and do a v2.

Thanks
James


signature.asc
Description: Digital signature


[PATCH AUTOSEL for 4.15 14/78] hv_netvsc: Fix the TX/RX buffer default sizes

2018-03-07 Thread Sasha Levin
From: Haiyang Zhang 

[ Upstream commit 41f61db2cd24d5ad802386719cccde1479aa82a6 ]

The values were not computed correctly. There are no significant
visible impact, though.

The intended size of RX buffer is 16 MB, and the default slot size is 1728.
So, NETVSC_DEFAULT_RX should be 16*1024*1024 / 1728 = 9709.

The intended size of TX buffer is 1 MB, and the slot size is 6144.
So, NETVSC_DEFAULT_TX should be 1024*1024 / 6144 = 170.

The patch puts the formula directly into the macro, and moves them to
hyperv_net.h, together with related macros.

Fixes: 5023a6db73196 ("netvsc: increase default receive buffer size")
Signed-off-by: Haiyang Zhang 
Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/hyperv/hyperv_net.h | 13 -
 drivers/net/hyperv/netvsc_drv.c |  4 
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index dab27e91b83b..c2653ac499e1 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -638,13 +638,24 @@ struct nvsp_message {
 /* Max buffer sizes allowed by a host */
 #define NETVSC_RECEIVE_BUFFER_SIZE (1024 * 1024 * 31) /* 31MB */
 #define NETVSC_RECEIVE_BUFFER_SIZE_LEGACY  (1024 * 1024 * 15) /* 15MB */
-#define NETVSC_SEND_BUFFER_SIZE(1024 * 1024 * 15)   /* 
15MB */
+#define NETVSC_RECEIVE_BUFFER_DEFAULT  (1024 * 1024 * 16)
+
+#define NETVSC_SEND_BUFFER_SIZE(1024 * 1024 * 15)  /* 
15MB */
+#define NETVSC_SEND_BUFFER_DEFAULT (1024 * 1024)
 
 #define NETVSC_INVALID_INDEX   -1
 
 #define NETVSC_SEND_SECTION_SIZE   6144
 #define NETVSC_RECV_SECTION_SIZE   1728
 
+/* Default size of TX buf: 1MB, RX buf: 16MB */
+#define NETVSC_MIN_TX_SECTIONS 10
+#define NETVSC_DEFAULT_TX  (NETVSC_SEND_BUFFER_DEFAULT \
+/ NETVSC_SEND_SECTION_SIZE)
+#define NETVSC_MIN_RX_SECTIONS 10
+#define NETVSC_DEFAULT_RX  (NETVSC_RECEIVE_BUFFER_DEFAULT \
+/ NETVSC_RECV_SECTION_SIZE)
+
 #define NETVSC_RECEIVE_BUFFER_ID   0xcafe
 #define NETVSC_SEND_BUFFER_ID  0
 
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 5129647d420c..dde3251da004 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -46,10 +46,6 @@
 #include "hyperv_net.h"
 
 #define RING_SIZE_MIN  64
-#define NETVSC_MIN_TX_SECTIONS 10
-#define NETVSC_DEFAULT_TX  192 /* ~1M */
-#define NETVSC_MIN_RX_SECTIONS 10  /* ~64K */
-#define NETVSC_DEFAULT_RX  10485   /* Max ~16M */
 
 #define LINKCHANGE_INT (2 * HZ)
 #define VF_TAKEOVER_INT (HZ / 10)
-- 
2.14.1


[PATCH AUTOSEL for 4.15 14/78] hv_netvsc: Fix the TX/RX buffer default sizes

2018-03-07 Thread Sasha Levin
From: Haiyang Zhang 

[ Upstream commit 41f61db2cd24d5ad802386719cccde1479aa82a6 ]

The values were not computed correctly. There are no significant
visible impact, though.

The intended size of RX buffer is 16 MB, and the default slot size is 1728.
So, NETVSC_DEFAULT_RX should be 16*1024*1024 / 1728 = 9709.

The intended size of TX buffer is 1 MB, and the slot size is 6144.
So, NETVSC_DEFAULT_TX should be 1024*1024 / 6144 = 170.

The patch puts the formula directly into the macro, and moves them to
hyperv_net.h, together with related macros.

Fixes: 5023a6db73196 ("netvsc: increase default receive buffer size")
Signed-off-by: Haiyang Zhang 
Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/hyperv/hyperv_net.h | 13 -
 drivers/net/hyperv/netvsc_drv.c |  4 
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index dab27e91b83b..c2653ac499e1 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -638,13 +638,24 @@ struct nvsp_message {
 /* Max buffer sizes allowed by a host */
 #define NETVSC_RECEIVE_BUFFER_SIZE (1024 * 1024 * 31) /* 31MB */
 #define NETVSC_RECEIVE_BUFFER_SIZE_LEGACY  (1024 * 1024 * 15) /* 15MB */
-#define NETVSC_SEND_BUFFER_SIZE(1024 * 1024 * 15)   /* 
15MB */
+#define NETVSC_RECEIVE_BUFFER_DEFAULT  (1024 * 1024 * 16)
+
+#define NETVSC_SEND_BUFFER_SIZE(1024 * 1024 * 15)  /* 
15MB */
+#define NETVSC_SEND_BUFFER_DEFAULT (1024 * 1024)
 
 #define NETVSC_INVALID_INDEX   -1
 
 #define NETVSC_SEND_SECTION_SIZE   6144
 #define NETVSC_RECV_SECTION_SIZE   1728
 
+/* Default size of TX buf: 1MB, RX buf: 16MB */
+#define NETVSC_MIN_TX_SECTIONS 10
+#define NETVSC_DEFAULT_TX  (NETVSC_SEND_BUFFER_DEFAULT \
+/ NETVSC_SEND_SECTION_SIZE)
+#define NETVSC_MIN_RX_SECTIONS 10
+#define NETVSC_DEFAULT_RX  (NETVSC_RECEIVE_BUFFER_DEFAULT \
+/ NETVSC_RECV_SECTION_SIZE)
+
 #define NETVSC_RECEIVE_BUFFER_ID   0xcafe
 #define NETVSC_SEND_BUFFER_ID  0
 
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 5129647d420c..dde3251da004 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -46,10 +46,6 @@
 #include "hyperv_net.h"
 
 #define RING_SIZE_MIN  64
-#define NETVSC_MIN_TX_SECTIONS 10
-#define NETVSC_DEFAULT_TX  192 /* ~1M */
-#define NETVSC_MIN_RX_SECTIONS 10  /* ~64K */
-#define NETVSC_DEFAULT_RX  10485   /* Max ~16M */
 
 #define LINKCHANGE_INT (2 * HZ)
 #define VF_TAKEOVER_INT (HZ / 10)
-- 
2.14.1


[PATCH AUTOSEL for 4.15 18/78] libbpf: prefer global symbols as bpf program name source

2018-03-07 Thread Sasha Levin
From: Roman Gushchin 

[ Upstream commit fe4d44b23f6b38194a92c6b8a50d921a071c4db4 ]

Libbpf picks the name of the first symbol in the corresponding
elf section to use as a program name. But without taking symbol's
scope into account it may end's up with some local label
as a program name. E.g.:

$ bpftool prog
1: type 15  name LBB0_10tag 0390a5136ba23f5c
loaded_at Dec 07/17:22  uid 0
xlated 456B  not jited  memlock 4096B

Fix this by preferring global symbols as program name.

For instance:
$ bpftool prog
1: type 15  name bpf_prog1  tag 0390a5136ba23f5c
loaded_at Dec 07/17:26  uid 0
xlated 456B  not jited  memlock 4096B

Signed-off-by: Roman Gushchin 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Jakub Kicinski 
Cc: Martin KaFai Lau 
Cc: Quentin Monnet 
Cc: David Ahern 
Signed-off-by: Daniel Borkmann 
Signed-off-by: Sasha Levin 
---
 tools/lib/bpf/libbpf.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 5aa45f89da93..cda652a12880 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -387,6 +387,8 @@ bpf_object__init_prog_names(struct bpf_object *obj)
continue;
if (sym.st_shndx != prog->idx)
continue;
+   if (GELF_ST_BIND(sym.st_info) != STB_GLOBAL)
+   continue;
 
name = elf_strptr(obj->efile.elf,
  obj->efile.strtabidx,
-- 
2.14.1


[PATCH AUTOSEL for 4.15 18/78] libbpf: prefer global symbols as bpf program name source

2018-03-07 Thread Sasha Levin
From: Roman Gushchin 

[ Upstream commit fe4d44b23f6b38194a92c6b8a50d921a071c4db4 ]

Libbpf picks the name of the first symbol in the corresponding
elf section to use as a program name. But without taking symbol's
scope into account it may end's up with some local label
as a program name. E.g.:

$ bpftool prog
1: type 15  name LBB0_10tag 0390a5136ba23f5c
loaded_at Dec 07/17:22  uid 0
xlated 456B  not jited  memlock 4096B

Fix this by preferring global symbols as program name.

For instance:
$ bpftool prog
1: type 15  name bpf_prog1  tag 0390a5136ba23f5c
loaded_at Dec 07/17:26  uid 0
xlated 456B  not jited  memlock 4096B

Signed-off-by: Roman Gushchin 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Jakub Kicinski 
Cc: Martin KaFai Lau 
Cc: Quentin Monnet 
Cc: David Ahern 
Signed-off-by: Daniel Borkmann 
Signed-off-by: Sasha Levin 
---
 tools/lib/bpf/libbpf.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 5aa45f89da93..cda652a12880 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -387,6 +387,8 @@ bpf_object__init_prog_names(struct bpf_object *obj)
continue;
if (sym.st_shndx != prog->idx)
continue;
+   if (GELF_ST_BIND(sym.st_info) != STB_GLOBAL)
+   continue;
 
name = elf_strptr(obj->efile.elf,
  obj->efile.strtabidx,
-- 
2.14.1


[PATCH] vfio-mdev/samples: change RDI interrupt condition

2018-03-07 Thread Shunyong Yang
When FIFO mode is enabled, the receive data available interrupt
(UART_IIR_RDI in code) should be triggered when the number of data
in FIFO is equal or larger than interrupt trigger level.

This patch changes the trigger level check to ensure multiple bytes
received from upper layer can trigger RDI interrupt correctly.

Cc: Joey Zheng 
Signed-off-by: Shunyong Yang 
---
 samples/vfio-mdev/mtty.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/samples/vfio-mdev/mtty.c b/samples/vfio-mdev/mtty.c
index 09f255bdf3ac..7abb79d8313d 100644
--- a/samples/vfio-mdev/mtty.c
+++ b/samples/vfio-mdev/mtty.c
@@ -534,7 +534,7 @@ static void handle_bar_read(unsigned int index, struct 
mdev_state *mdev_state,
 
/* Interrupt priority 2: Fifo trigger level reached */
if ((ier & UART_IER_RDI) &&
-   (mdev_state->s[index].rxtx.count ==
+   (mdev_state->s[index].rxtx.count >=
  mdev_state->s[index].intr_trigger_level))
*buf |= UART_IIR_RDI;
 
-- 
1.8.3.1



[PATCH AUTOSEL for 4.15 17/78] spi: sh-msiof: Avoid writing to registers from spi_master.setup()

2018-03-07 Thread Sasha Levin
From: Geert Uytterhoeven 

[ Upstream commit 7ff0b53c4051145d1cf992d2f60987e6447eed4f ]

The spi_master.setup() callback must not change configuration registers,
as that could corrupt I/O that is in progress for other SPI slaves.

The only exception is the configuration of the native chip select
polarity in SPI master mode, as a wrong chip select polarity will cause
havoc during all future transfers to any other SPI slave.

Hence stop writing to registers in sh_msiof_spi_setup(), unless it is
the first call for a controller using a native chip select, or unless
native chip select polarity has changed (note that you'll loose anyway
if I/O is in progress).  Even then, only do what is strictly necessary,
instead of calling sh_msiof_spi_set_pin_regs().

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 drivers/spi/spi-sh-msiof.c | 35 ---
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index fcd261f98b9f..bf34e9b238af 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -55,6 +55,8 @@ struct sh_msiof_spi_priv {
void *rx_dma_page;
dma_addr_t tx_dma_addr;
dma_addr_t rx_dma_addr;
+   bool native_cs_inited;
+   bool native_cs_high;
bool slave_aborted;
 };
 
@@ -528,8 +530,7 @@ static int sh_msiof_spi_setup(struct spi_device *spi)
 {
struct device_node  *np = spi->master->dev.of_node;
struct sh_msiof_spi_priv *p = spi_master_get_devdata(spi->master);
-
-   pm_runtime_get_sync(>pdev->dev);
+   u32 clr, set, tmp;
 
if (!np) {
/*
@@ -539,19 +540,31 @@ static int sh_msiof_spi_setup(struct spi_device *spi)
spi->cs_gpio = (uintptr_t)spi->controller_data;
}
 
-   /* Configure pins before deasserting CS */
-   sh_msiof_spi_set_pin_regs(p, !!(spi->mode & SPI_CPOL),
- !!(spi->mode & SPI_CPHA),
- !!(spi->mode & SPI_3WIRE),
- !!(spi->mode & SPI_LSB_FIRST),
- !!(spi->mode & SPI_CS_HIGH));
-
-   if (spi->cs_gpio >= 0)
+   if (spi->cs_gpio >= 0) {
gpio_set_value(spi->cs_gpio, !(spi->mode & SPI_CS_HIGH));
+   return 0;
+   }
 
+   if (spi_controller_is_slave(p->master))
+   return 0;
 
-   pm_runtime_put(>pdev->dev);
+   if (p->native_cs_inited &&
+   (p->native_cs_high == !!(spi->mode & SPI_CS_HIGH)))
+   return 0;
 
+   /* Configure native chip select mode/polarity early */
+   clr = MDR1_SYNCMD_MASK;
+   set = MDR1_TRMD | TMDR1_PCON | MDR1_SYNCMD_SPI;
+   if (spi->mode & SPI_CS_HIGH)
+   clr |= BIT(MDR1_SYNCAC_SHIFT);
+   else
+   set |= BIT(MDR1_SYNCAC_SHIFT);
+   pm_runtime_get_sync(>pdev->dev);
+   tmp = sh_msiof_read(p, TMDR1) & ~clr;
+   sh_msiof_write(p, TMDR1, tmp | set);
+   pm_runtime_put(>pdev->dev);
+   p->native_cs_high = spi->mode & SPI_CS_HIGH;
+   p->native_cs_inited = true;
return 0;
 }
 
-- 
2.14.1


[PATCH AUTOSEL for 4.15 17/78] spi: sh-msiof: Avoid writing to registers from spi_master.setup()

2018-03-07 Thread Sasha Levin
From: Geert Uytterhoeven 

[ Upstream commit 7ff0b53c4051145d1cf992d2f60987e6447eed4f ]

The spi_master.setup() callback must not change configuration registers,
as that could corrupt I/O that is in progress for other SPI slaves.

The only exception is the configuration of the native chip select
polarity in SPI master mode, as a wrong chip select polarity will cause
havoc during all future transfers to any other SPI slave.

Hence stop writing to registers in sh_msiof_spi_setup(), unless it is
the first call for a controller using a native chip select, or unless
native chip select polarity has changed (note that you'll loose anyway
if I/O is in progress).  Even then, only do what is strictly necessary,
instead of calling sh_msiof_spi_set_pin_regs().

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 drivers/spi/spi-sh-msiof.c | 35 ---
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index fcd261f98b9f..bf34e9b238af 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -55,6 +55,8 @@ struct sh_msiof_spi_priv {
void *rx_dma_page;
dma_addr_t tx_dma_addr;
dma_addr_t rx_dma_addr;
+   bool native_cs_inited;
+   bool native_cs_high;
bool slave_aborted;
 };
 
@@ -528,8 +530,7 @@ static int sh_msiof_spi_setup(struct spi_device *spi)
 {
struct device_node  *np = spi->master->dev.of_node;
struct sh_msiof_spi_priv *p = spi_master_get_devdata(spi->master);
-
-   pm_runtime_get_sync(>pdev->dev);
+   u32 clr, set, tmp;
 
if (!np) {
/*
@@ -539,19 +540,31 @@ static int sh_msiof_spi_setup(struct spi_device *spi)
spi->cs_gpio = (uintptr_t)spi->controller_data;
}
 
-   /* Configure pins before deasserting CS */
-   sh_msiof_spi_set_pin_regs(p, !!(spi->mode & SPI_CPOL),
- !!(spi->mode & SPI_CPHA),
- !!(spi->mode & SPI_3WIRE),
- !!(spi->mode & SPI_LSB_FIRST),
- !!(spi->mode & SPI_CS_HIGH));
-
-   if (spi->cs_gpio >= 0)
+   if (spi->cs_gpio >= 0) {
gpio_set_value(spi->cs_gpio, !(spi->mode & SPI_CS_HIGH));
+   return 0;
+   }
 
+   if (spi_controller_is_slave(p->master))
+   return 0;
 
-   pm_runtime_put(>pdev->dev);
+   if (p->native_cs_inited &&
+   (p->native_cs_high == !!(spi->mode & SPI_CS_HIGH)))
+   return 0;
 
+   /* Configure native chip select mode/polarity early */
+   clr = MDR1_SYNCMD_MASK;
+   set = MDR1_TRMD | TMDR1_PCON | MDR1_SYNCMD_SPI;
+   if (spi->mode & SPI_CS_HIGH)
+   clr |= BIT(MDR1_SYNCAC_SHIFT);
+   else
+   set |= BIT(MDR1_SYNCAC_SHIFT);
+   pm_runtime_get_sync(>pdev->dev);
+   tmp = sh_msiof_read(p, TMDR1) & ~clr;
+   sh_msiof_write(p, TMDR1, tmp | set);
+   pm_runtime_put(>pdev->dev);
+   p->native_cs_high = spi->mode & SPI_CS_HIGH;
+   p->native_cs_inited = true;
return 0;
 }
 
-- 
2.14.1


[PATCH] vfio-mdev/samples: change RDI interrupt condition

2018-03-07 Thread Shunyong Yang
When FIFO mode is enabled, the receive data available interrupt
(UART_IIR_RDI in code) should be triggered when the number of data
in FIFO is equal or larger than interrupt trigger level.

This patch changes the trigger level check to ensure multiple bytes
received from upper layer can trigger RDI interrupt correctly.

Cc: Joey Zheng 
Signed-off-by: Shunyong Yang 
---
 samples/vfio-mdev/mtty.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/samples/vfio-mdev/mtty.c b/samples/vfio-mdev/mtty.c
index 09f255bdf3ac..7abb79d8313d 100644
--- a/samples/vfio-mdev/mtty.c
+++ b/samples/vfio-mdev/mtty.c
@@ -534,7 +534,7 @@ static void handle_bar_read(unsigned int index, struct 
mdev_state *mdev_state,
 
/* Interrupt priority 2: Fifo trigger level reached */
if ((ier & UART_IER_RDI) &&
-   (mdev_state->s[index].rxtx.count ==
+   (mdev_state->s[index].rxtx.count >=
  mdev_state->s[index].intr_trigger_level))
*buf |= UART_IIR_RDI;
 
-- 
1.8.3.1



[PATCH AUTOSEL for 4.15 22/78] ath10k: handling qos at STA side based on AP WMM enable/disable

2018-03-07 Thread Sasha Levin
From: Balaji Pothunoori 

[ Upstream commit 07ffb4497360ae8789f0fec8171ee952304d ]

Data packets are not sent by STA in case of STA joined to
non QOS AP (WMM disabled AP). This is happening because of STA
is sending data packets to firmware from host with qos enabled
along with non qos queue value(TID = 16).
Due to qos enabled, firmware is discarding the packet.

This patch fixes this issue by updating the qos based on station
WME capability field if WMM is disabled in AP.

This patch is required by 10.4 family chipsets like
QCA4019/QCA9888/QCA9884/QCA99X0.
Firmware Versoin : 10.4-3.5.1-00018.

For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch
has no effect.

Signed-off-by: Balaji Pothunoori 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/ath/ath10k/mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 0a947eef348d..2616b9938077 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2563,7 +2563,7 @@ static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
}
break;
case WMI_VDEV_TYPE_STA:
-   if (vif->bss_conf.qos)
+   if (sta->wme)
arg->peer_flags |= arvif->ar->wmi.peer_flags->qos;
break;
case WMI_VDEV_TYPE_IBSS:
-- 
2.14.1


[PATCH AUTOSEL for 4.15 22/78] ath10k: handling qos at STA side based on AP WMM enable/disable

2018-03-07 Thread Sasha Levin
From: Balaji Pothunoori 

[ Upstream commit 07ffb4497360ae8789f0fec8171ee952304d ]

Data packets are not sent by STA in case of STA joined to
non QOS AP (WMM disabled AP). This is happening because of STA
is sending data packets to firmware from host with qos enabled
along with non qos queue value(TID = 16).
Due to qos enabled, firmware is discarding the packet.

This patch fixes this issue by updating the qos based on station
WME capability field if WMM is disabled in AP.

This patch is required by 10.4 family chipsets like
QCA4019/QCA9888/QCA9884/QCA99X0.
Firmware Versoin : 10.4-3.5.1-00018.

For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch
has no effect.

Signed-off-by: Balaji Pothunoori 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/ath/ath10k/mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 0a947eef348d..2616b9938077 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2563,7 +2563,7 @@ static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
}
break;
case WMI_VDEV_TYPE_STA:
-   if (vif->bss_conf.qos)
+   if (sta->wme)
arg->peer_flags |= arvif->ar->wmi.peer_flags->qos;
break;
case WMI_VDEV_TYPE_IBSS:
-- 
2.14.1


[PATCH AUTOSEL for 4.15 23/78] media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart

2018-03-07 Thread Sasha Levin
From: Ron Economos 

[ Upstream commit 380a6c86457573aa42d27ae11e025eb25941a0b7 ]

On faster CPUs a delay is required after the resume command and the restart 
command. Without the delay, the restart command often returns -EREMOTEIO and 
the Si2168 does not restart.

Note that this patch fixes the same issue as 
https://patchwork.linuxtv.org/patch/44304/, but I believe my udelay() fix 
addresses the actual problem.

Signed-off-by: Ron Economos 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
---
 drivers/media/dvb-frontends/si2168.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/dvb-frontends/si2168.c 
b/drivers/media/dvb-frontends/si2168.c
index 41d9c513b7e8..539399dac551 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -14,6 +14,8 @@
  *GNU General Public License for more details.
  */
 
+#include 
+
 #include "si2168_priv.h"
 
 static const struct dvb_frontend_ops si2168_ops;
@@ -435,6 +437,7 @@ static int si2168_init(struct dvb_frontend *fe)
if (ret)
goto err;
 
+   udelay(100);
memcpy(cmd.args, "\x85", 1);
cmd.wlen = 1;
cmd.rlen = 1;
-- 
2.14.1


[PATCH AUTOSEL for 4.15 23/78] media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart

2018-03-07 Thread Sasha Levin
From: Ron Economos 

[ Upstream commit 380a6c86457573aa42d27ae11e025eb25941a0b7 ]

On faster CPUs a delay is required after the resume command and the restart 
command. Without the delay, the restart command often returns -EREMOTEIO and 
the Si2168 does not restart.

Note that this patch fixes the same issue as 
https://patchwork.linuxtv.org/patch/44304/, but I believe my udelay() fix 
addresses the actual problem.

Signed-off-by: Ron Economos 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
---
 drivers/media/dvb-frontends/si2168.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/dvb-frontends/si2168.c 
b/drivers/media/dvb-frontends/si2168.c
index 41d9c513b7e8..539399dac551 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -14,6 +14,8 @@
  *GNU General Public License for more details.
  */
 
+#include 
+
 #include "si2168_priv.h"
 
 static const struct dvb_frontend_ops si2168_ops;
@@ -435,6 +437,7 @@ static int si2168_init(struct dvb_frontend *fe)
if (ret)
goto err;
 
+   udelay(100);
memcpy(cmd.args, "\x85", 1);
cmd.wlen = 1;
cmd.rlen = 1;
-- 
2.14.1


[PATCH AUTOSEL for 4.15 25/78] tty: goldfish: Enable 'earlycon' only if built-in

2018-03-07 Thread Sasha Levin
From: Sebastian Andrzej Siewior 

[ Upstream commit 6a28fd2bbc94bfca105632e5ef8a9dbe63ba0b39 ]

Commit 3840ed9548f7 ("tty: goldfish: Implement support for kernel
'earlycon' parameter") breaks an allmodconfig config on x86:
|  LD  vmlinux.o
|  MODPOST vmlinux.o
|drivers/tty/serial/earlycon.o: In function `parse_options':
|drivers/tty/serial/earlycon.c:97: undefined reference to `uart_parse_earlycon'
|Makefile:1005: recipe for target 'vmlinux' failed

earlycon.c::parse_options() invokes uart_parse_earlycon() from serial_core.c
which is compiled=m because GOLDFISH_TTY itself (and most others) are =m.
To avoid that, I'm adding the _CONSOLE config option which is selected if the
GOLDFISH module itself is =y since it doesn't need the early bits for the =m
case (other drivers do the same dance).
The alternative would be to move uart_parse_earlycon() from
serial_core.c to earlycon.c (we don't have that many users of that
function).

Fixes: 3840ed9548f7 ("tty: goldfish: Implement support for kernel
   'earlycon' parameter")
Signed-off-by: Sebastian Andrzej Siewior 
Reviewed-by: Miodrag Dinic 
Acked-by: Miodrag Dinic 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/tty/Kconfig| 6 +-
 drivers/tty/goldfish.c | 2 ++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index cc2b4d9433ed..b811442c5ce6 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -394,10 +394,14 @@ config GOLDFISH_TTY
depends on GOLDFISH
select SERIAL_CORE
select SERIAL_CORE_CONSOLE
-   select SERIAL_EARLYCON
help
  Console and system TTY driver for the Goldfish virtual platform.
 
+config GOLDFISH_TTY_EARLY_CONSOLE
+   bool
+   default y if GOLDFISH_TTY=y
+   select SERIAL_EARLYCON
+
 config DA_TTY
bool "DA TTY"
depends on METAG_DA
diff --git a/drivers/tty/goldfish.c b/drivers/tty/goldfish.c
index 7f657bb5113c..1c1bd0afcd48 100644
--- a/drivers/tty/goldfish.c
+++ b/drivers/tty/goldfish.c
@@ -433,6 +433,7 @@ static int goldfish_tty_remove(struct platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_GOLDFISH_TTY_EARLY_CONSOLE
 static void gf_early_console_putchar(struct uart_port *port, int ch)
 {
__raw_writel(ch, port->membase);
@@ -456,6 +457,7 @@ static int __init gf_earlycon_setup(struct earlycon_device 
*device,
 }
 
 OF_EARLYCON_DECLARE(early_gf_tty, "google,goldfish-tty", gf_earlycon_setup);
+#endif
 
 static const struct of_device_id goldfish_tty_of_match[] = {
{ .compatible = "google,goldfish-tty", },
-- 
2.14.1


[PATCH AUTOSEL for 4.15 25/78] tty: goldfish: Enable 'earlycon' only if built-in

2018-03-07 Thread Sasha Levin
From: Sebastian Andrzej Siewior 

[ Upstream commit 6a28fd2bbc94bfca105632e5ef8a9dbe63ba0b39 ]

Commit 3840ed9548f7 ("tty: goldfish: Implement support for kernel
'earlycon' parameter") breaks an allmodconfig config on x86:
|  LD  vmlinux.o
|  MODPOST vmlinux.o
|drivers/tty/serial/earlycon.o: In function `parse_options':
|drivers/tty/serial/earlycon.c:97: undefined reference to `uart_parse_earlycon'
|Makefile:1005: recipe for target 'vmlinux' failed

earlycon.c::parse_options() invokes uart_parse_earlycon() from serial_core.c
which is compiled=m because GOLDFISH_TTY itself (and most others) are =m.
To avoid that, I'm adding the _CONSOLE config option which is selected if the
GOLDFISH module itself is =y since it doesn't need the early bits for the =m
case (other drivers do the same dance).
The alternative would be to move uart_parse_earlycon() from
serial_core.c to earlycon.c (we don't have that many users of that
function).

Fixes: 3840ed9548f7 ("tty: goldfish: Implement support for kernel
   'earlycon' parameter")
Signed-off-by: Sebastian Andrzej Siewior 
Reviewed-by: Miodrag Dinic 
Acked-by: Miodrag Dinic 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/tty/Kconfig| 6 +-
 drivers/tty/goldfish.c | 2 ++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index cc2b4d9433ed..b811442c5ce6 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -394,10 +394,14 @@ config GOLDFISH_TTY
depends on GOLDFISH
select SERIAL_CORE
select SERIAL_CORE_CONSOLE
-   select SERIAL_EARLYCON
help
  Console and system TTY driver for the Goldfish virtual platform.
 
+config GOLDFISH_TTY_EARLY_CONSOLE
+   bool
+   default y if GOLDFISH_TTY=y
+   select SERIAL_EARLYCON
+
 config DA_TTY
bool "DA TTY"
depends on METAG_DA
diff --git a/drivers/tty/goldfish.c b/drivers/tty/goldfish.c
index 7f657bb5113c..1c1bd0afcd48 100644
--- a/drivers/tty/goldfish.c
+++ b/drivers/tty/goldfish.c
@@ -433,6 +433,7 @@ static int goldfish_tty_remove(struct platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_GOLDFISH_TTY_EARLY_CONSOLE
 static void gf_early_console_putchar(struct uart_port *port, int ch)
 {
__raw_writel(ch, port->membase);
@@ -456,6 +457,7 @@ static int __init gf_earlycon_setup(struct earlycon_device 
*device,
 }
 
 OF_EARLYCON_DECLARE(early_gf_tty, "google,goldfish-tty", gf_earlycon_setup);
+#endif
 
 static const struct of_device_id goldfish_tty_of_match[] = {
{ .compatible = "google,goldfish-tty", },
-- 
2.14.1


  1   2   3   4   5   6   7   8   9   10   >