[PATCH v4 0/6] pmbus: Expand fan support and add MAX31785 driver

2017-11-02 Thread Andrew Jeffery 
Hello,

This series introduces support for the MAX31785 intelligent fan controller, a
PMBus device providing closed-loop fan control among a number of other
features. Along the way the series adds support to control fans and create
virtual pages to the PMBus core, the latter to support some of the more
annoying design decisions found in the 'A' variant of the chip.

This is the fourth spin of the series, v3 can be found here[1].

I've been running aground with the described devicetree bindings in the
previous iterations, so in order to get *some* support upstream I've gutted the
documentation and removed the corresponding support from the driver. I'll save
posting that for a later date once Guenter and I have some input from Rob about
what direction to take with respect to describing PMBus devices.

As mentioned, adding full support for the features of the MAX31785 requires
modifications to the PMBus core, so I've split the addition of features into
separate patches, in the hope that some can be incrementally applied while we
iterate on the details of any suboptimal parts.

Please review!

Andrew

[1] https://lkml.org/lkml/2017/9/8/4

Andrew Jeffery (6):
  dt-bindings: pmbus: Add Maxim MAX31785 documentation
  pmbus: Add driver for Maxim MAX31785 Intelligent Fan Controller
  pmbus: core: Add fan control support
  pmbus: max31785: Add fan control
  pmbus: core: Add virtual page config bit
  pmbus: max31785: Add dual tachometer support

 .../devicetree/bindings/hwmon/max31785.txt |  22 ++
 Documentation/hwmon/max31785   |  57 
 drivers/hwmon/pmbus/Kconfig|  10 +
 drivers/hwmon/pmbus/Makefile   |   1 +
 drivers/hwmon/pmbus/max31785.c | 375 +
 drivers/hwmon/pmbus/pmbus.h|  31 ++
 drivers/hwmon/pmbus/pmbus_core.c   | 236 +++--
 7 files changed, 713 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hwmon/max31785.txt
 create mode 100644 Documentation/hwmon/max31785
 create mode 100644 drivers/hwmon/pmbus/max31785.c

-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/6] dt-bindings: pmbus: Add Maxim MAX31785 documentation

2017-11-02 Thread Andrew Jeffery 
Signed-off-by: Andrew Jeffery 
---
 .../devicetree/bindings/hwmon/max31785.txt | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/max31785.txt

diff --git a/Documentation/devicetree/bindings/hwmon/max31785.txt 
b/Documentation/devicetree/bindings/hwmon/max31785.txt
new file mode 100644
index ..106e08c56aaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/max31785.txt
@@ -0,0 +1,22 @@
+Bindings for the Maxim MAX31785 Intelligent Fan Controller
+==
+
+Reference:
+
+https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf
+
+The Maxim MAX31785 is a PMBus device providing closed-loop, multi-channel fan
+management with temperature and remote voltage sensing. Various fan control
+features are provided, including PWM frequency control, temperature hysteresis,
+dual tachometer measurements, and fan health monitoring.
+
+Required properties:
+- compatible : One of "maxim,max31785" or "maxim,max31785a"
+- reg: I2C address, one of 0x52, 0x53, 0x54, 0x55.
+
+Example:
+
+fans@52 {
+compatible = "maxim,max31785";
+reg = <0x52>;
+};
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/6] pmbus: Add driver for Maxim MAX31785 Intelligent Fan Controller

2017-11-02 Thread Andrew Jeffery 
The Maxim MAX31785 is a PMBus device providing closed-loop, multi-channel fan
management with temperature and remote voltage sensing. Various fan control
features are provided, including PWM frequency control, temperature hysteresis,
dual tachometer measurements, and fan health monitoring.

This patch presents a basic driver using only the existing features of the
PMBus subsystem.

Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/max31785   |  51 ++
 drivers/hwmon/pmbus/Kconfig|  10 
 drivers/hwmon/pmbus/Makefile   |   1 +
 drivers/hwmon/pmbus/max31785.c | 116 +
 4 files changed, 178 insertions(+)
 create mode 100644 Documentation/hwmon/max31785
 create mode 100644 drivers/hwmon/pmbus/max31785.c

diff --git a/Documentation/hwmon/max31785 b/Documentation/hwmon/max31785
new file mode 100644
index ..45fb6093dec2
--- /dev/null
+++ b/Documentation/hwmon/max31785
@@ -0,0 +1,51 @@
+Kernel driver max31785
+==
+
+Supported chips:
+  * Maxim MAX31785, MAX31785A
+Prefix: 'max31785' or 'max31785a'
+Addresses scanned: -
+Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf
+
+Author: Andrew Jeffery 
+
+Description
+---
+
+The Maxim MAX31785 is a PMBus device providing closed-loop, multi-channel fan
+management with temperature and remote voltage sensing. Various fan control
+features are provided, including PWM frequency control, temperature hysteresis,
+dual tachometer measurements, and fan health monitoring.
+
+For dual rotor fan configuration, the MAX31785 exposes the slowest rotor of the
+two in the fan[1-4]_input attributes.
+
+Usage Notes
+---
+
+This driver does not probe for PMBus devices. You will have to instantiate
+devices explicitly.
+
+Sysfs attributes
+
+
+fan[1-4]_alarm Fan alarm.
+fan[1-4]_fault Fan fault.
+fan[1-4]_input Fan RPM.
+
+in[1-6]_crit   Critical maximum output voltage
+in[1-6]_crit_alarm Output voltage critical high alarm
+in[1-6]_input  Measured output voltage
+in[1-6]_label  "vout[18-23]"
+in[1-6]_lcrit  Critical minimum output voltage
+in[1-6]_lcrit_alarmOutput voltage critical low alarm
+in[1-6]_maxMaximum output voltage
+in[1-6]_max_alarm  Output voltage high alarm
+in[1-6]_minMinimum output voltage
+in[1-6]_min_alarm  Output voltage low alarm
+
+temp[1-11]_critCritical high temperature
+temp[1-11]_crit_alarm  Chip temperature critical high alarm
+temp[1-11]_input   Measured temperature
+temp[1-11]_max Maximum temperature
+temp[1-11]_max_alarm   Chip temperature high alarm
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index 40019325b517..08479006c7f9 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -114,6 +114,16 @@ config SENSORS_MAX20751
  This driver can also be built as a module. If so, the module will
  be called max20751.
 
+config SENSORS_MAX31785
+   tristate "Maxim MAX31785 and compatibles"
+   default n
+   help
+ If you say yes here you get hardware monitoring support for Maxim
+ MAX31785.
+
+ This driver can also be built as a module. If so, the module will
+ be called max31785.
+
 config SENSORS_MAX34440
tristate "Maxim MAX34440 and compatibles"
default n
diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
index 459a6be3390e..a8bf0e490db9 100644
--- a/drivers/hwmon/pmbus/Makefile
+++ b/drivers/hwmon/pmbus/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SENSORS_LTC2978) += ltc2978.o
 obj-$(CONFIG_SENSORS_LTC3815)  += ltc3815.o
 obj-$(CONFIG_SENSORS_MAX16064) += max16064.o
 obj-$(CONFIG_SENSORS_MAX20751) += max20751.o
+obj-$(CONFIG_SENSORS_MAX31785) += max31785.o
 obj-$(CONFIG_SENSORS_MAX34440) += max34440.o
 obj-$(CONFIG_SENSORS_MAX8688)  += max8688.o
 obj-$(CONFIG_SENSORS_TPS40422) += tps40422.o
diff --git a/drivers/hwmon/pmbus/max31785.c b/drivers/hwmon/pmbus/max31785.c
new file mode 100644
index ..9313849d5160
--- /dev/null
+++ b/drivers/hwmon/pmbus/max31785.c
@@ -0,0 +1,116 @@
+/*
+ * Copyright (C) 2017 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "pmbus.h"
+
+enum max31785_regs {
+   MFR_REVISION= 0x9b,
+};
+
+#define MAX31785_NR_PAGES  23
+
+#define MAX31785_FAN_FUNCS \
+   (PMBUS_HAVE_FAN12 | PMBUS_HAVE_STATUS_FAN12)
+
+#define MAX31785_TEMP_FUNCS \
+   (PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP)
+
+#define MAX31785_VOUT_FUNCS \
+   (PMBUS_HAVE_VOUT |

[PATCH v4 6/6] pmbus: max31785: Add dual tachometer support

2017-11-02 Thread Andrew Jeffery 
The dual tachometer feature is implemented in hardware with a TACHSEL
input to indicate the rotor under measurement, and exposed on the device
by extending the READ_FAN_SPEED_1 word with two extra bytes*. The need
to read the non-standard four-byte response leads to a cut-down
implementation of i2c_smbus_xfer_emulated() included in the driver.
Further, to expose the second rotor tachometer value to userspace the
values are exposed through virtual pages. We re-route accesses to
FAN_CONFIG_1_2 and READ_FAN_SPEED_1 on undefined (in hardware) pages
23-28 to the same registers on pages 0-5, and with the latter command we
extract the value from the second word of the four-byte response.

* The documentation recommends the slower rotor be associated with
TACHSEL=0, which provides the first word of the response. The TACHSEL=0
measurement is used by the controller's closed-loop fan management.

Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/max31785   |   8 ++-
 drivers/hwmon/pmbus/max31785.c | 159 -
 2 files changed, 163 insertions(+), 4 deletions(-)

diff --git a/Documentation/hwmon/max31785 b/Documentation/hwmon/max31785
index e9edbf11948f..8e75efc5e4b9 100644
--- a/Documentation/hwmon/max31785
+++ b/Documentation/hwmon/max31785
@@ -17,8 +17,9 @@ management with temperature and remote voltage sensing. 
Various fan control
 features are provided, including PWM frequency control, temperature hysteresis,
 dual tachometer measurements, and fan health monitoring.
 
-For dual rotor fan configuration, the MAX31785 exposes the slowest rotor of the
-two in the fan[1-4]_input attributes.
+For dual-rotor configurations the MAX31785A exposes the second rotor tachometer
+readings in attributes fan[5-8]_input. By contrast the MAX31785 only exposes
+the slowest rotor measurement, and does so in the fan[1-4]_input attributes.
 
 Usage Notes
 ---
@@ -31,7 +32,8 @@ Sysfs attributes
 
 fan[1-4]_alarm Fan alarm.
 fan[1-4]_fault Fan fault.
-fan[1-4]_input Fan RPM.
+fan[1-8]_input Fan RPM. On the MAX31785A, inputs 5-8 correspond to the
+   second rotor of fans 1-4
 fan[1-4]_targetFan input target
 
 in[1-6]_crit   Critical maximum output voltage
diff --git a/drivers/hwmon/pmbus/max31785.c b/drivers/hwmon/pmbus/max31785.c
index 0d97ddf67079..2ca7febb2843 100644
--- a/drivers/hwmon/pmbus/max31785.c
+++ b/drivers/hwmon/pmbus/max31785.c
@@ -16,10 +16,82 @@
 
 enum max31785_regs {
MFR_REVISION= 0x9b,
+   MFR_FAN_CONFIG  = 0xf1,
 };
 
+#define MAX31785   0x3030
+#define MAX31785A  0x3040
+
+#define MFR_FAN_CONFIG_DUAL_TACH   BIT(12)
+
 #define MAX31785_NR_PAGES  23
 
+static int max31785_read_byte_data(struct i2c_client *client, int page,
+  int reg)
+{
+   switch (reg) {
+   case PMBUS_VOUT_MODE:
+   if (page < MAX31785_NR_PAGES)
+   return -ENODATA;
+
+   return -ENOTSUPP;
+   case PMBUS_FAN_CONFIG_12:
+   if (page < MAX31785_NR_PAGES)
+   return -ENODATA;
+
+   return pmbus_read_byte_data(client, page - MAX31785_NR_PAGES,
+   reg);
+   }
+
+   return -ENODATA;
+}
+
+static int max31785_write_byte(struct i2c_client *client, int page, u8 value)
+{
+   if (page < MAX31785_NR_PAGES)
+   return -ENODATA;
+
+   return -ENOTSUPP;
+}
+
+static int max31785_read_long_data(struct i2c_client *client, int page,
+  int reg, u32 *data)
+{
+   unsigned char cmdbuf[1];
+   unsigned char rspbuf[4];
+   int rc;
+
+   struct i2c_msg msg[2] = {
+   {
+   .addr = client->addr,
+   .flags = 0,
+   .len = sizeof(cmdbuf),
+   .buf = cmdbuf,
+   },
+   {
+   .addr = client->addr,
+   .flags = I2C_M_RD,
+   .len = sizeof(rspbuf),
+   .buf = rspbuf,
+   },
+   };
+
+   cmdbuf[0] = reg;
+
+   rc = pmbus_set_page(client, page);
+   if (rc < 0)
+   return rc;
+
+   rc = i2c_transfer(client->adapter, msg, ARRAY_SIZE(msg));
+   if (rc < 0)
+   return rc;
+
+   *data = (rspbuf[0] << (0 * 8)) | (rspbuf[1] << (1 * 8)) |
+   (rspbuf[2] << (2 * 8)) | (rspbuf[3] << (3 * 8));
+
+   return rc;
+}
+
 static int max31785_get_pwm(struct i2c_client *client, int page)
 {
int config;
@@ -76,7 +148,25 @@ static int max31785_read_word_data(struct i2c_client 
*client, int page,
int rv;
 
switch (reg) {
+   case PMBUS_READ_FAN_SPEED_1:
+   {
+   u32 val;
+
+   if (page <

[PATCH v4 5/6] pmbus: core: Add virtual page config bit

2017-11-02 Thread Andrew Jeffery 
Some circumstances call for virtual pages to expose multiple values
packed into an extended PMBus register in a manner non-compliant with
the PMBus standard. We should not try to set virtual pages on the
device; add a flag so we can avoid doing so.

Signed-off-by: Andrew Jeffery 
---
 drivers/hwmon/pmbus/pmbus.h  |  2 ++
 drivers/hwmon/pmbus/pmbus_core.c | 12 
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
index cdf3e288e626..0560a8dbcee0 100644
--- a/drivers/hwmon/pmbus/pmbus.h
+++ b/drivers/hwmon/pmbus/pmbus.h
@@ -367,6 +367,8 @@ enum pmbus_sensor_classes {
 #define PMBUS_HAVE_PWM12   BIT(20)
 #define PMBUS_HAVE_PWM34   BIT(21)
 
+#define PMBUS_PAGE_VIRTUAL BIT(31)
+
 enum pmbus_data_format { linear = 0, direct, vid };
 enum vrm_version { vr11 = 0, vr12, vr13 };
 
diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
index 55838b69e99a..af7362de405d 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -164,14 +164,18 @@ int pmbus_set_page(struct i2c_client *client, u8 page)
int rv = 0;
int newpage;
 
-   if (page != data->currpage) {
+   if (page == data->currpage)
+   return 0;
+
+   if (!(data->info->func[page] & PMBUS_PAGE_VIRTUAL)) {
rv = i2c_smbus_write_byte_data(client, PMBUS_PAGE, page);
newpage = i2c_smbus_read_byte_data(client, PMBUS_PAGE);
if (newpage != page)
-   rv = -EIO;
-   else
-   data->currpage = page;
+   return -EIO;
}
+
+   data->currpage = page;
+
return rv;
 }
 EXPORT_SYMBOL_GPL(pmbus_set_page);
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 3/6] pmbus: core: Add fan control support

2017-11-02 Thread Andrew Jeffery 
Expose fanX_target, pwmX and pwmX_enable hwmon sysfs attributes.

Fans in a PMBus device are driven by the configuration of two registers:
FAN_CONFIG_x_y and FAN_COMMAND_x: FAN_CONFIG_x_y dictates how the fan
and the tacho operate (if installed), while FAN_COMMAND_x sets the
desired fan rate. The unit of FAN_COMMAND_x is dependent on the
operational fan mode, RPM or PWM percent duty, as determined by the
corresponding FAN_CONFIG_x_y.

The mapping of fanX_target, pwmX and pwmX_enable onto FAN_CONFIG_x_y and
FAN_COMMAND_x is implemented with the addition of virtual registers and
generic implementations in the core:

1. PMBUS_VIRT_FAN_TARGET_x
2. PMBUS_VIRT_PWM_x
3. PMBUS_VIRT_PWM_ENABLE_x

The virtual registers facilitate the necessary side-effects of each
access. Examples of the read case, assuming m = 1, b = 0, R = 0:

 Read |  With  || Gives
 ---
   Attribute  | FAN_CONFIG_x_y | FAN_COMMAND_y || Value
 --++---
  fanX_target | ~PB_FAN_z_RPM  | 0x0001|| 1
  pwm1| ~PB_FAN_z_RPM  | 0x0064|| 255
  pwmX_enable | ~PB_FAN_z_RPM  | 0x0001|| 1
  fanX_target |  PB_FAN_z_RPM  | 0x0001|| 1
  pwm1|  PB_FAN_z_RPM  | 0x0064|| 0
  pwmX_enable |  PB_FAN_z_RPM  | 0x0001|| 1

And the write case:

 Write| With  ||   Sets
 -+---+++---
   Attribute  | Value || FAN_CONFIG_x_y | FAN_COMMAND_x
 -+---+++---
  fanX_target | 1 ||  PB_FAN_z_RPM  | 0x0001
  pwmX| 255   || ~PB_FAN_z_RPM  | 0x0064
  pwmX_enable | 1 || ~PB_FAN_z_RPM  | 0x0064

Also, the DIRECT mode scaling of some controllers is different between
RPM and PWM percent duty control modes, so PSC_PWM is introduced to
capture the necessary coefficients.

Signed-off-by: Andrew Jeffery 
---
 drivers/hwmon/pmbus/pmbus.h  |  29 +
 drivers/hwmon/pmbus/pmbus_core.c | 224 ---
 2 files changed, 238 insertions(+), 15 deletions(-)

diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
index 4efa2bd4f6d8..cdf3e288e626 100644
--- a/drivers/hwmon/pmbus/pmbus.h
+++ b/drivers/hwmon/pmbus/pmbus.h
@@ -190,6 +190,28 @@ enum pmbus_regs {
PMBUS_VIRT_VMON_UV_FAULT_LIMIT,
PMBUS_VIRT_VMON_OV_FAULT_LIMIT,
PMBUS_VIRT_STATUS_VMON,
+
+   /*
+* RPM and PWM Fan control
+*
+* Drivers wanting to expose PWM control must define the behaviour of
+* PMBUS_VIRT_PWM_ENABLE_[1-4] in the {read,write}_word_data callback.
+*
+* pmbus core provides default implementations for
+* PMBUS_VIRT_FAN_TARGET_[1-4] and PMBUS_VIRT_PWM_[1-4].
+*/
+   PMBUS_VIRT_FAN_TARGET_1,
+   PMBUS_VIRT_FAN_TARGET_2,
+   PMBUS_VIRT_FAN_TARGET_3,
+   PMBUS_VIRT_FAN_TARGET_4,
+   PMBUS_VIRT_PWM_1,
+   PMBUS_VIRT_PWM_2,
+   PMBUS_VIRT_PWM_3,
+   PMBUS_VIRT_PWM_4,
+   PMBUS_VIRT_PWM_ENABLE_1,
+   PMBUS_VIRT_PWM_ENABLE_2,
+   PMBUS_VIRT_PWM_ENABLE_3,
+   PMBUS_VIRT_PWM_ENABLE_4,
 };
 
 /*
@@ -223,6 +245,8 @@ enum pmbus_regs {
 #define PB_FAN_1_RPM   BIT(6)
 #define PB_FAN_1_INSTALLED BIT(7)
 
+enum pmbus_fan_mode { percent = 0, rpm };
+
 /*
  * STATUS_BYTE, STATUS_WORD (lower)
  */
@@ -313,6 +337,7 @@ enum pmbus_sensor_classes {
PSC_POWER,
PSC_TEMPERATURE,
PSC_FAN,
+   PSC_PWM,
PSC_NUM_CLASSES /* Number of power sensor classes */
 };
 
@@ -339,6 +364,8 @@ enum pmbus_sensor_classes {
 #define PMBUS_HAVE_STATUS_FAN34BIT(17)
 #define PMBUS_HAVE_VMONBIT(18)
 #define PMBUS_HAVE_STATUS_VMON BIT(19)
+#define PMBUS_HAVE_PWM12   BIT(20)
+#define PMBUS_HAVE_PWM34   BIT(21)
 
 enum pmbus_data_format { linear = 0, direct, vid };
 enum vrm_version { vr11 = 0, vr12, vr13 };
@@ -413,6 +440,8 @@ int pmbus_write_byte_data(struct i2c_client *client, int 
page, u8 reg,
  u8 value);
 int pmbus_update_byte_data(struct i2c_client *client, int page, u8 reg,
   u8 mask, u8 value);
+int pmbus_update_fan(struct i2c_client *client, int page, int id,
+u8 config, u8 mask, u16 command);
 void pmbus_clear_faults(struct i2c_client *client);
 bool pmbus_check_byte_register(struct i2c_client *client, int page, int reg);
 bool pmbus_check_word_register(struct i2c_client *client, int page, int reg);
diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
index 302f0aef59de..55838b69e99a 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -64,6 +64,7 @@ struct pmbus_sensor {
u16 reg;

[PATCH v4 4/6] pmbus: max31785: Add fan control

2017-11-02 Thread Andrew Jeffery 
The implementation makes use of the new fan control virtual registers
exposed by the pmbus core. It mixes use of the default implementations
with some overrides via the read/write handlers to handle FAN_COMMAND_1
on the MAX31785, whose definition breaks the value range into various
control bands dependent on RPM or PWM mode.

Signed-off-by: Andrew Jeffery 
---
 Documentation/hwmon/max31785   |   4 ++
 drivers/hwmon/pmbus/max31785.c | 104 -
 2 files changed, 107 insertions(+), 1 deletion(-)

diff --git a/Documentation/hwmon/max31785 b/Documentation/hwmon/max31785
index 45fb6093dec2..e9edbf11948f 100644
--- a/Documentation/hwmon/max31785
+++ b/Documentation/hwmon/max31785
@@ -32,6 +32,7 @@ Sysfs attributes
 fan[1-4]_alarm Fan alarm.
 fan[1-4]_fault Fan fault.
 fan[1-4]_input Fan RPM.
+fan[1-4]_targetFan input target
 
 in[1-6]_crit   Critical maximum output voltage
 in[1-6]_crit_alarm Output voltage critical high alarm
@@ -44,6 +45,9 @@ in[1-6]_max_alarm Output voltage high alarm
 in[1-6]_minMinimum output voltage
 in[1-6]_min_alarm  Output voltage low alarm
 
+pwm[1-4]   Fan target duty cycle (0..255)
+pwm[1-4]_enable0: full-speed, 1: manual control, 2: automatic
+
 temp[1-11]_critCritical high temperature
 temp[1-11]_crit_alarm  Chip temperature critical high alarm
 temp[1-11]_input   Measured temperature
diff --git a/drivers/hwmon/pmbus/max31785.c b/drivers/hwmon/pmbus/max31785.c
index 9313849d5160..0d97ddf67079 100644
--- a/drivers/hwmon/pmbus/max31785.c
+++ b/drivers/hwmon/pmbus/max31785.c
@@ -20,8 +20,102 @@ enum max31785_regs {
 
 #define MAX31785_NR_PAGES  23
 
+static int max31785_get_pwm(struct i2c_client *client, int page)
+{
+   int config;
+   int command;
+
+   config = pmbus_read_byte_data(client, page, PMBUS_FAN_CONFIG_12);
+   if (config < 0)
+   return config;
+
+   command = pmbus_read_word_data(client, page, PMBUS_FAN_COMMAND_1);
+   if (command < 0)
+   return command;
+
+   if (!(config & PB_FAN_1_RPM)) {
+   if (command >= 0x8000)
+   return 0;
+   else if (command >= 0x2711)
+   return 0x2710;
+
+   return command;
+   }
+
+   return 0;
+}
+
+static int max31785_get_pwm_mode(struct i2c_client *client, int page)
+{
+   int config;
+   int command;
+
+   config = pmbus_read_byte_data(client, page, PMBUS_FAN_CONFIG_12);
+   if (config < 0)
+   return config;
+
+   command = pmbus_read_word_data(client, page, PMBUS_FAN_COMMAND_1);
+   if (command < 0)
+   return command;
+
+   if (!(config & PB_FAN_1_RPM)) {
+   if (command >= 0x8000)
+   return 2;
+   else if (command >= 0x2711)
+   return 0;
+
+   return 1;
+   }
+
+   return (command >= 0x8000) ? 2 : 1;
+}
+
+static int max31785_read_word_data(struct i2c_client *client, int page,
+  int reg)
+{
+   int rv;
+
+   switch (reg) {
+   case PMBUS_VIRT_PWM_1:
+   rv = max31785_get_pwm(client, page);
+   if (rv < 0)
+   return rv;
+
+   rv *= 255;
+   rv /= 100;
+   break;
+   case PMBUS_VIRT_PWM_ENABLE_1:
+   rv = max31785_get_pwm_mode(client, page);
+   break;
+   default:
+   rv = -ENODATA;
+   break;
+   }
+
+   return rv;
+}
+
+static const int max31785_pwm_modes[] = { 0x7fff, 0x2710, 0x };
+
+static int max31785_write_word_data(struct i2c_client *client, int page,
+   int reg, u16 word)
+{
+   switch (reg) {
+   case PMBUS_VIRT_PWM_ENABLE_1:
+   if (word >= ARRAY_SIZE(max31785_pwm_modes))
+   return -EINVAL;
+
+   return pmbus_update_fan(client, page, 0, 0, PB_FAN_1_RPM,
+   max31785_pwm_modes[word]);
+   default:
+   break;
+   }
+
+   return -ENODATA;
+}
+
 #define MAX31785_FAN_FUNCS \
-   (PMBUS_HAVE_FAN12 | PMBUS_HAVE_STATUS_FAN12)
+   (PMBUS_HAVE_FAN12 | PMBUS_HAVE_STATUS_FAN12 | PMBUS_HAVE_PWM12)
 
 #define MAX31785_TEMP_FUNCS \
(PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP)
@@ -32,11 +126,19 @@ enum max31785_regs {
 static const struct pmbus_driver_info max31785_info = {
.pages = MAX31785_NR_PAGES,
 
+   .write_word_data = max31785_write_word_data,
+   .read_word_data = max31785_read_word_data,
+
/* RPM */
.format[PSC_FAN] = direct,
.m[PSC_FAN] = 1,
.b[PSC_FAN] = 0,
.R[PSC_FAN] = 0,
+   /* PWM */
+   .format[PSC_PWM] = direct,
+   .m[PSC_PWM] = 1,
+   .b[PSC_PWM] =

[PATCH v2 1/6] dmaengine: doc: Add ReST style dmaengine document

2017-11-02 Thread Vinod Koul 
This removes the index file and adds the index.rst as placeholder
and update driver-api index to add dmaengine. As a consequence
dmaengine documentation will be in driver-api/

Signed-off-by: Vinod Koul 
---
 Documentation/dmaengine/00-INDEX |  8 
 Documentation/driver-api/dmaengine/index.rst | 13 +
 Documentation/driver-api/index.rst   |  1 +
 3 files changed, 14 insertions(+), 8 deletions(-)
 delete mode 100644 Documentation/dmaengine/00-INDEX
 create mode 100644 Documentation/driver-api/dmaengine/index.rst

diff --git a/Documentation/dmaengine/00-INDEX b/Documentation/dmaengine/00-INDEX
deleted file mode 100644
index 07de6573d22b..
--- a/Documentation/dmaengine/00-INDEX
+++ /dev/null
@@ -1,8 +0,0 @@
-00-INDEX
-   - this file.
-client.txt
-   -the DMA Engine API Guide.
-dmatest.txt
-   - how to compile, configure and use the dmatest system.
-provider.txt
-   - the DMA controller API.
\ No newline at end of file
diff --git a/Documentation/driver-api/dmaengine/index.rst 
b/Documentation/driver-api/dmaengine/index.rst
new file mode 100644
index ..8c90a6443810
--- /dev/null
+++ b/Documentation/driver-api/dmaengine/index.rst
@@ -0,0 +1,13 @@
+===
+DMAEngine documentation
+===
+
+DMAEngine documentation provides documents for various aspects of DMAEngine
+framework.
+
+.. only::  subproject
+
+   Indices
+   ===
+
+   * :ref:`genindex`
diff --git a/Documentation/driver-api/index.rst 
b/Documentation/driver-api/index.rst
index 9c20624842b7..d17a9876b473 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -46,6 +46,7 @@ available subsections can be seen below.
pinctl
gpio
misc_devices
+   dmaengine/index
 
 .. only::  subproject and html
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/6] dmaengine: doc: ReSTize provider doc

2017-11-02 Thread Vinod Koul 
This moves and converts provider file with some format changes
for RST style

Signed-off-by: Vinod Koul 
---
 Documentation/dmaengine/provider.txt| 424 
 Documentation/driver-api/dmaengine/index.rst|  11 +
 Documentation/driver-api/dmaengine/provider.rst | 508 
 3 files changed, 519 insertions(+), 424 deletions(-)
 delete mode 100644 Documentation/dmaengine/provider.txt
 create mode 100644 Documentation/driver-api/dmaengine/provider.rst

diff --git a/Documentation/dmaengine/provider.txt 
b/Documentation/dmaengine/provider.txt
deleted file mode 100644
index 5dbe054a40ad..
--- a/Documentation/dmaengine/provider.txt
+++ /dev/null
@@ -1,424 +0,0 @@
-DMAengine controller documentation
-==
-
-Hardware Introduction
-+
-
-Most of the Slave DMA controllers have the same general principles of
-operations.
-
-They have a given number of channels to use for the DMA transfers, and
-a given number of requests lines.
-
-Requests and channels are pretty much orthogonal. Channels can be used
-to serve several to any requests. To simplify, channels are the
-entities that will be doing the copy, and requests what endpoints are
-involved.
-
-The request lines actually correspond to physical lines going from the
-DMA-eligible devices to the controller itself. Whenever the device
-will want to start a transfer, it will assert a DMA request (DRQ) by
-asserting that request line.
-
-A very simple DMA controller would only take into account a single
-parameter: the transfer size. At each clock cycle, it would transfer a
-byte of data from one buffer to another, until the transfer size has
-been reached.
-
-That wouldn't work well in the real world, since slave devices might
-require a specific number of bits to be transferred in a single
-cycle. For example, we may want to transfer as much data as the
-physical bus allows to maximize performances when doing a simple
-memory copy operation, but our audio device could have a narrower FIFO
-that requires data to be written exactly 16 or 24 bits at a time. This
-is why most if not all of the DMA controllers can adjust this, using a
-parameter called the transfer width.
-
-Moreover, some DMA controllers, whenever the RAM is used as a source
-or destination, can group the reads or writes in memory into a buffer,
-so instead of having a lot of small memory accesses, which is not
-really efficient, you'll get several bigger transfers. This is done
-using a parameter called the burst size, that defines how many single
-reads/writes it's allowed to do without the controller splitting the
-transfer into smaller sub-transfers.
-
-Our theoretical DMA controller would then only be able to do transfers
-that involve a single contiguous block of data. However, some of the
-transfers we usually have are not, and want to copy data from
-non-contiguous buffers to a contiguous buffer, which is called
-scatter-gather.
-
-DMAEngine, at least for mem2dev transfers, require support for
-scatter-gather. So we're left with two cases here: either we have a
-quite simple DMA controller that doesn't support it, and we'll have to
-implement it in software, or we have a more advanced DMA controller,
-that implements in hardware scatter-gather.
-
-The latter are usually programmed using a collection of chunks to
-transfer, and whenever the transfer is started, the controller will go
-over that collection, doing whatever we programmed there.
-
-This collection is usually either a table or a linked list. You will
-then push either the address of the table and its number of elements,
-or the first item of the list to one channel of the DMA controller,
-and whenever a DRQ will be asserted, it will go through the collection
-to know where to fetch the data from.
-
-Either way, the format of this collection is completely dependent on
-your hardware. Each DMA controller will require a different structure,
-but all of them will require, for every chunk, at least the source and
-destination addresses, whether it should increment these addresses or
-not and the three parameters we saw earlier: the burst size, the
-transfer width and the transfer size.
-
-The one last thing is that usually, slave devices won't issue DRQ by
-default, and you have to enable this in your slave device driver first
-whenever you're willing to use DMA.
-
-These were just the general memory-to-memory (also called mem2mem) or
-memory-to-device (mem2dev) kind of transfers. Most devices often
-support other kind of transfers or memory operations that dmaengine
-support and will be detailed later in this document.
-
-DMA Support in Linux
-
-
-Historically, DMA controller drivers have been implemented using the
-async TX API, to offload operations such as memory copy, XOR,
-cryptography, etc., basically any memory to memory operation.
-
-Over time, the need for memory to device transfers

[PATCH v2 4/6] dmaengine: doc: ReSTize dmatest doc

2017-11-02 Thread Vinod Koul 
This converts and moves dmatest file with some format
changes for RST style

Signed-off-by: Vinod Koul 
---
 .../dmaengine/dmatest.rst} | 96 +-
 Documentation/driver-api/dmaengine/index.rst   | 10 +++
 2 files changed, 67 insertions(+), 39 deletions(-)
 rename Documentation/{dmaengine/dmatest.txt => 
driver-api/dmaengine/dmatest.rst} (50%)

diff --git a/Documentation/dmaengine/dmatest.txt 
b/Documentation/driver-api/dmaengine/dmatest.rst
similarity index 50%
rename from Documentation/dmaengine/dmatest.txt
rename to Documentation/driver-api/dmaengine/dmatest.rst
index fb683c72dea8..3922c0a3f0c0 100644
--- a/Documentation/dmaengine/dmatest.txt
+++ b/Documentation/driver-api/dmaengine/dmatest.rst
@@ -1,11 +1,13 @@
-   DMA Test Guide
-   ==
+==
+DMA Test Guide
+==
 
-   Andy Shevchenko 
+Andy Shevchenko 
 
 This small document introduces how to test DMA drivers using dmatest module.
 
-   Part 1 - How to build the test module
+Part 1 - How to build the test module
+=
 
 The menuconfig contains an option that could be found by following path:
Device Drivers -> DMA Engine support -> DMA Test client
@@ -13,25 +15,31 @@ The menuconfig contains an option that could be found by 
following path:
 In the configuration file the option called CONFIG_DMATEST. The dmatest could
 be built as module or inside kernel. Let's consider those cases.
 
-   Part 2 - When dmatest is built as a module...
+Part 2 - When dmatest is built as a module
+==
 
-Example of usage:
-   % modprobe dmatest channel=dma0chan0 timeout=2000 iterations=1 run=1
+Example of usage: ::
 
-...or:
-   % modprobe dmatest
-   % echo dma0chan0 > /sys/module/dmatest/parameters/channel
-   % echo 2000 > /sys/module/dmatest/parameters/timeout
-   % echo 1 > /sys/module/dmatest/parameters/iterations
-   % echo 1 > /sys/module/dmatest/parameters/run
+% modprobe dmatest channel=dma0chan0 timeout=2000 iterations=1 run=1
 
-...or on the kernel command line:
+...or: ::
 
-   dmatest.channel=dma0chan0 dmatest.timeout=2000 dmatest.iterations=1 
dmatest.run=1
+% modprobe dmatest
+% echo dma0chan0 > /sys/module/dmatest/parameters/channel
+% echo 2000 > /sys/module/dmatest/parameters/timeout
+% echo 1 > /sys/module/dmatest/parameters/iterations
+% echo 1 > /sys/module/dmatest/parameters/run
 
-Hint: available channel list could be extracted by running the following
-command:
-   % ls -1 /sys/class/dma/
+...or on the kernel command line: ::
+
+dmatest.channel=dma0chan0 dmatest.timeout=2000 dmatest.iterations=1 
dmatest.run=1
+
+..hint:: available channel list could be extracted by running the following
+ command:
+
+::
+
+% ls -1 /sys/class/dma/
 
 Once started a message like "dmatest: Started 1 threads using dma0chan0" is
 emitted. After that only test failure messages are reported until the test
@@ -39,8 +47,9 @@ stops.
 
 Note that running a new test will not stop any in progress test.
 
-The following command returns the state of the test.
-   % cat /sys/module/dmatest/parameters/run
+The following command returns the state of the test. ::
+
+% cat /sys/module/dmatest/parameters/run
 
 To wait for test completion userpace can poll 'run' until it is false, or use
 the wait parameter. Specifying 'wait=1' when loading the module causes module
@@ -50,15 +59,19 @@ before returning. For example, the following scripts wait 
for 42 tests
 to complete before exiting. Note that if 'iterations' is set to 'infinite' then
 waiting is disabled.
 
-Example:
-   % modprobe dmatest run=1 iterations=42 wait=1
-   % modprobe -r dmatest
-...or:
-   % modprobe dmatest run=1 iterations=42
-   % cat /sys/module/dmatest/parameters/wait
-   % modprobe -r dmatest
+Example: ::
+
+% modprobe dmatest run=1 iterations=42 wait=1
+% modprobe -r dmatest
 
-   Part 3 - When built-in in the kernel...
+...or: ::
+
+% modprobe dmatest run=1 iterations=42
+% cat /sys/module/dmatest/parameters/wait
+% modprobe -r dmatest
+
+Part 3 - When built-in in the kernel
+
 
 The module parameters that is supplied to the kernel command line will be used
 for the first performed test. After user gets a control, the test could be
@@ -66,27 +79,32 @@ re-run with the same or different parameters. For the 
details see the above
 section "Part 2 - When dmatest is built as a module..."
 
 In both cases the module parameters are used as the actual values for the test
-case. You always could check them at run-time by running
-   % grep -H . /sys/module/dmatest/parameters/*
+case. You always could check them at run-time by running ::
+

[PATCH v2 5/6] dmaengine: doc: ReSTize pxa_dma doc

2017-11-02 Thread Vinod Koul 
This converts and moves pxa_dma file with some format
changes for RST style

Signed-off-by: Vinod Koul 
---
 Documentation/dmaengine/pxa_dma.txt| 153 
 Documentation/driver-api/dmaengine/index.rst   |  10 ++
 Documentation/driver-api/dmaengine/pxa_dma.rst | 190 +
 3 files changed, 200 insertions(+), 153 deletions(-)
 delete mode 100644 Documentation/dmaengine/pxa_dma.txt
 create mode 100644 Documentation/driver-api/dmaengine/pxa_dma.rst

diff --git a/Documentation/dmaengine/pxa_dma.txt 
b/Documentation/dmaengine/pxa_dma.txt
deleted file mode 100644
index 0736d44b5438..
--- a/Documentation/dmaengine/pxa_dma.txt
+++ /dev/null
@@ -1,153 +0,0 @@
-PXA/MMP - DMA Slave controller
-==
-
-Constraints

-  a) Transfers hot queuing
- A driver submitting a transfer and issuing it should be granted the 
transfer
- is queued even on a running DMA channel.
- This implies that the queuing doesn't wait for the previous transfer end,
- and that the descriptor chaining is not only done in the irq/tasklet code
- triggered by the end of the transfer.
- A transfer which is submitted and issued on a phy doesn't wait for a phy 
to
- stop and restart, but is submitted on a "running channel". The other
- drivers, especially mmp_pdma waited for the phy to stop before relaunching
- a new transfer.
-
-  b) All transfers having asked for confirmation should be signaled
- Any issued transfer with DMA_PREP_INTERRUPT should trigger a callback 
call.
- This implies that even if an irq/tasklet is triggered by end of tx1, but
- at the time of irq/dma tx2 is already finished, tx1->complete() and
- tx2->complete() should be called.
-
-  c) Channel running state
- A driver should be able to query if a channel is running or not. For the
- multimedia case, such as video capture, if a transfer is submitted and 
then
- a check of the DMA channel reports a "stopped channel", the transfer 
should
- not be issued until the next "start of frame interrupt", hence the need to
- know if a channel is in running or stopped state.
-
-  d) Bandwidth guarantee
- The PXA architecture has 4 levels of DMAs priorities : high, normal, low.
- The high priorities get twice as much bandwidth as the normal, which get 
twice
- as much as the low priorities.
- A driver should be able to request a priority, especially the real-time
- ones such as pxa_camera with (big) throughputs.
-
-Design
---
-  a) Virtual channels
- Same concept as in sa11x0 driver, ie. a driver was assigned a "virtual
- channel" linked to the requestor line, and the physical DMA channel is
- assigned on the fly when the transfer is issued.
-
-  b) Transfer anatomy for a scatter-gather transfer
- ++-+---++-+
- | desc-sg[0] | ... | desc-sg[last] | status updater | finisher/linker |
- ++-+---++-+
-
- This structure is pointed by dma->sg_cpu.
- The descriptors are used as follows :
-  - desc-sg[i]: i-th descriptor, transferring the i-th sg
-element to the video buffer scatter gather
-  - status updater
-Transfers a single u32 to a well known dma coherent memory to leave
-a trace that this transfer is done. The "well known" is unique per
-physical channel, meaning that a read of this value will tell which
-is the last finished transfer at that point in time.
-  - finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN
-  - linker: has ddadr= desc-sg[0] of next transfer, dcmd=0
-
-  c) Transfers hot-chaining
- Suppose the running chain is :
- Buffer 1 Buffer 2
- +-++---+  ++++---+
- | d0 | .. | dN | l |  | d0 | .. | dN | f |
- +-++-|-+  ^+++---+
-  ||
-  ++
-
- After a call to dmaengine_submit(b3), the chain will look like :
-  Buffer 1  Buffer 2 Buffer 3
- +-++---+  ++++---+  ++++---+
- | d0 | .. | dN | l |  | d0 | .. | dN | l |  | d0 | .. | dN | f |
- +-++-|-+  ^+++-|-+  ^+++---+
-  ||||
-  ++++
-   new_link
-
- If while new_link was created the DMA channel stopped, it is _not_
- restarted. Hot-chaining doesn't break the assumption that
- dma_async_issue_pending() is to be used to ensure the transfer is 
actually started.
-
- One exception to this rule :
-   - if Buffer1 and Buffer2 had all their addresses 8 bytes aligned
-   - and if Buffer3 has at least one address not 4 bytes aligned
-   -

[PATCH v2 3/6] dmaengine: doc: ReSTize client API doc

2017-11-02 Thread Vinod Koul 
This converts and moves client API file with some format
changes for RST style

Signed-off-by: Vinod Koul 
---
 Documentation/dmaengine/client.txt| 222 -
 Documentation/driver-api/dmaengine/client.rst | 275 ++
 Documentation/driver-api/dmaengine/index.rst  |  11 ++
 3 files changed, 286 insertions(+), 222 deletions(-)
 delete mode 100644 Documentation/dmaengine/client.txt
 create mode 100644 Documentation/driver-api/dmaengine/client.rst

diff --git a/Documentation/dmaengine/client.txt 
b/Documentation/dmaengine/client.txt
deleted file mode 100644
index c72b4563de10..
--- a/Documentation/dmaengine/client.txt
+++ /dev/null
@@ -1,222 +0,0 @@
-   DMA Engine API Guide
-   
-
-Vinod Koul 
-
-NOTE: For DMA Engine usage in async_tx please see:
-   Documentation/crypto/async-tx-api.txt
-
-
-Below is a guide to device driver writers on how to use the Slave-DMA API of 
the
-DMA Engine. This is applicable only for slave DMA usage only.
-
-The slave DMA usage consists of following steps:
-1. Allocate a DMA slave channel
-2. Set slave and controller specific parameters
-3. Get a descriptor for transaction
-4. Submit the transaction
-5. Issue pending requests and wait for callback notification
-
-1. Allocate a DMA slave channel
-
-   Channel allocation is slightly different in the slave DMA context,
-   client drivers typically need a channel from a particular DMA
-   controller only and even in some cases a specific channel is desired.
-   To request a channel dma_request_chan() API is used.
-
-   Interface:
-   struct dma_chan *dma_request_chan(struct device *dev, const char *name);
-
-   Which will find and return the 'name' DMA channel associated with the 'dev'
-   device. The association is done via DT, ACPI or board file based
-   dma_slave_map matching table.
-
-   A channel allocated via this interface is exclusive to the caller,
-   until dma_release_channel() is called.
-
-2. Set slave and controller specific parameters
-
-   Next step is always to pass some specific information to the DMA
-   driver. Most of the generic information which a slave DMA can use
-   is in struct dma_slave_config. This allows the clients to specify
-   DMA direction, DMA addresses, bus widths, DMA burst lengths etc
-   for the peripheral.
-
-   If some DMA controllers have more parameters to be sent then they
-   should try to embed struct dma_slave_config in their controller
-   specific structure. That gives flexibility to client to pass more
-   parameters, if required.
-
-   Interface:
-   int dmaengine_slave_config(struct dma_chan *chan,
- struct dma_slave_config *config)
-
-   Please see the dma_slave_config structure definition in dmaengine.h
-   for a detailed explanation of the struct members. Please note
-   that the 'direction' member will be going away as it duplicates the
-   direction given in the prepare call.
-
-3. Get a descriptor for transaction
-
-   For slave usage the various modes of slave transfers supported by the
-   DMA-engine are:
-
-   slave_sg- DMA a list of scatter gather buffers from/to a peripheral
-   dma_cyclic  - Perform a cyclic DMA operation from/to a peripheral till the
- operation is explicitly stopped.
-   interleaved_dma - This is common to Slave as well as M2M clients. For slave
-address of devices' fifo could be already known to the driver.
-Various types of operations could be expressed by setting
-appropriate values to the 'dma_interleaved_template' members.
-
-   A non-NULL return of this transfer API represents a "descriptor" for
-   the given transaction.
-
-   Interface:
-   struct dma_async_tx_descriptor *dmaengine_prep_slave_sg(
-   struct dma_chan *chan, struct scatterlist *sgl,
-   unsigned int sg_len, enum dma_data_direction direction,
-   unsigned long flags);
-
-   struct dma_async_tx_descriptor *dmaengine_prep_dma_cyclic(
-   struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
-   size_t period_len, enum dma_data_direction direction);
-
-   struct dma_async_tx_descriptor *dmaengine_prep_interleaved_dma(
-   struct dma_chan *chan, struct dma_interleaved_template *xt,
-   unsigned long flags);
-
-   The peripheral driver is expected to have mapped the scatterlist for
-   the DMA operation prior to calling dmaengine_prep_slave_sg(), and must
-   keep the scatterlist mapped until the DMA operation has completed.
-   The scatterlist must be mapped using the DMA struct device.
-   If a mapping needs to be synchronized later, dma_sync_*_for_*() must be
-   called using the DMA struct device, too.
-   So, normal setup should look like this:
-
-   nr_sg = dma_map_sg(chan->device->dev, sgl, sg_len);
-

[PATCH v2 0/6] dmaengine: ReSTize documentation

2017-11-02 Thread Vinod Koul 
So here is the conversion of the dmaengine documents from txt files to rst
format. Not much functional change but somehow git detects only one rename
(possibly due to fixed whitespace and indent to make new format happier)

Changes in v2:
  - move the Documentation to driver-api
  - fix whitespace and more indent issue

Vinod Koul (6):
  dmaengine: doc: Add ReST style dmaengine document
  dmaengine: doc: ReSTize provider doc
  dmaengine: doc: ReSTize client API doc
  dmaengine: doc: ReSTize dmatest doc
  dmaengine: doc: ReSTize pxa_dma doc
  MAINTAINERS: update DMAengine documentation location

 Documentation/dmaengine/00-INDEX   |   8 -
 Documentation/dmaengine/client.txt | 222 -
 Documentation/dmaengine/provider.txt   | 424 -
 Documentation/dmaengine/pxa_dma.txt| 153 ---
 Documentation/driver-api/dmaengine/client.rst  | 275 +++
 .../dmaengine/dmatest.rst} |  96 ++--
 Documentation/driver-api/dmaengine/index.rst   |  55 +++
 Documentation/driver-api/dmaengine/provider.rst| 508 +
 Documentation/driver-api/dmaengine/pxa_dma.rst | 190 
 Documentation/driver-api/index.rst |   1 +
 MAINTAINERS|   2 +-
 11 files changed, 1087 insertions(+), 847 deletions(-)
 delete mode 100644 Documentation/dmaengine/00-INDEX
 delete mode 100644 Documentation/dmaengine/client.txt
 delete mode 100644 Documentation/dmaengine/provider.txt
 delete mode 100644 Documentation/dmaengine/pxa_dma.txt
 create mode 100644 Documentation/driver-api/dmaengine/client.rst
 rename Documentation/{dmaengine/dmatest.txt => 
driver-api/dmaengine/dmatest.rst} (50%)
 create mode 100644 Documentation/driver-api/dmaengine/index.rst
 create mode 100644 Documentation/driver-api/dmaengine/provider.rst
 create mode 100644 Documentation/driver-api/dmaengine/pxa_dma.rst

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 6/6] MAINTAINERS: update DMAengine documentation location

2017-11-02 Thread Vinod Koul 
WIth ReST style documentation, we moved it to driver-api/dmaengine
so update this in MAINTAINERS entry

Signed-off-by: Vinod Koul 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2281af4b41b6..1d65d7e6044f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4223,7 +4223,7 @@ S:Maintained
 F: drivers/dma/
 F: include/linux/dmaengine.h
 F: Documentation/devicetree/bindings/dma/
-F: Documentation/dmaengine/
+F: Documentation/driver-api/dmaengine/
 T: git git://git.infradead.org/users/vkoul/slave-dma.git
 
 DMA MAPPING HELPERS
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Add Tim Bird to list of enforcement statement endorsers

2017-11-02 Thread Bird, Timothy 
Add my name to the list.

Signed-off-by: Tim Bird 
---
 Documentation/process/kernel-enforcement-statement.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/process/kernel-enforcement-statement.rst 
b/Documentation/process/kernel-enforcement-statement.rst
index 1e23d42..69ee258 100644
--- a/Documentation/process/kernel-enforcement-statement.rst
+++ b/Documentation/process/kernel-enforcement-statement.rst
@@ -60,6 +60,7 @@ we might work for today, have in the past, or will in the 
future.
   - Felipe Balbi
   - Arnd Bergmann
   - Ard Biesheuvel
+  - Tim Bird
   - Paolo Bonzini (Red Hat)
   - Christian Borntraeger
   - Mark Brown (Linaro)
-- 
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/1] locking/qspinlock/x86: Avoid test-and-set when PV_DEDICATED is set

2017-11-02 Thread Eduardo Valentin 
On Thu, Nov 02, 2017 at 07:24:16PM +0100, Paolo Bonzini wrote:
> On 02/11/2017 19:08, Eduardo Valentin wrote:
> > On Thu, Nov 02, 2017 at 06:56:46PM +0100, Paolo Bonzini wrote:
> >> On 02/11/2017 18:45, Eduardo Valentin wrote:
> >>> Currently, the existing qspinlock implementation will fallback to
> >>> test-and-set if the hypervisor has not set the PV_UNHALT flag.
> >>>
> >>> This patch gives the opportunity to guest kernels to select
> >>> between test-and-set and the regular queueu fair lock implementation
> >>> based on the PV_DEDICATED KVM feature flag. When the PV_DEDICATED
> >>> flag is not set, the code will still fall back to test-and-set,
> >>> but when the PV_DEDICATED flag is set, the code will use
> >>> the regular queue spinlock implementation.
> >>
> >> Have you seen Waiman's series that lets you specify this on the guest
> >> command line instead?  Would this be acceptable for your use case?
> > 
> > No, can you please share a link to it? is it already merged to tip/master?
> 
> [PATCH-tip v2 0/2] x86/paravirt: Enable users to choose PV lock type
> https://lkml.org/lkml/2017/11/1/655
> 
> >> (In other words, is there a difference for you between making the host
> >> vs. guest administrator toggle the feature?  "@amazon.com" means you are
> >> the host admin, how would you use it?)
> > 
> > The way I think of this is this is a flag set by host side so the
> > guest adapts accordingly.
> > 
> > If the admin in guest side wants to ignore what the host is
> > flagging, that is a different story.
> 
> Okay, this makes sense.  But perhaps it should be a separate CPUID leaf,
> such as "configuration hints", rather than properly a feature.

Oh OK, you don't think this starts to deviate from the feature concept.
But would the PV_UNHALT also go to "configuration hints" bucket?

Another way to see this is we have three locking feature options to select from,
so we need at least two bits here.

> 
> Paolo

-- 
All the best,
Eduardo Valentin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/1] locking/qspinlock/x86: Avoid test-and-set when PV_DEDICATED is set

2017-11-02 Thread Eduardo Valentin 
Longman,

On Thu, Nov 02, 2017 at 02:12:13PM -0400, Waiman Long wrote:
> On 11/02/2017 02:08 PM, Eduardo Valentin wrote:
> > On Thu, Nov 02, 2017 at 06:56:46PM +0100, Paolo Bonzini wrote:
> >> On 02/11/2017 18:45, Eduardo Valentin wrote:
> >>> Currently, the existing qspinlock implementation will fallback to
> >>> test-and-set if the hypervisor has not set the PV_UNHALT flag.
> >>>
> >>> This patch gives the opportunity to guest kernels to select
> >>> between test-and-set and the regular queueu fair lock implementation
> >>> based on the PV_DEDICATED KVM feature flag. When the PV_DEDICATED
> >>> flag is not set, the code will still fall back to test-and-set,
> >>> but when the PV_DEDICATED flag is set, the code will use
> >>> the regular queue spinlock implementation.
> >> Have you seen Waiman's series that lets you specify this on the guest
> >> command line instead?  Would this be acceptable for your use case?
> >>
> > No, can you please share a link to it? is it already merged to tip/master?
> 
> See https://lkml.org/lkml/2017/11/1/655

Oh I see, thanks. I think that patch would help, but I believe the series and 
this patch are complementary.

Paolo, back to your question, I think this patch still makes sense in 
combination with Waiman's series
for the following case:

+ * If this argument is not specified, the kernel will automatically choose
+ * an appropriate one depending on X86_FEATURE_HYPERVISOR and hypervisor
+ * specific settings.
+ */

 In this case, the hypervisor can still flag PV_DEDICATED and the guest would 
not pick test, when
that scenario is desirable.

> 
> Cheers,
> Longman
> 

-- 
All the best,
Eduardo Valentin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/1] locking/qspinlock/x86: Avoid test-and-set when PV_DEDICATED is set

2017-11-02 Thread Paolo Bonzini 
On 02/11/2017 19:08, Eduardo Valentin wrote:
> On Thu, Nov 02, 2017 at 06:56:46PM +0100, Paolo Bonzini wrote:
>> On 02/11/2017 18:45, Eduardo Valentin wrote:
>>> Currently, the existing qspinlock implementation will fallback to
>>> test-and-set if the hypervisor has not set the PV_UNHALT flag.
>>>
>>> This patch gives the opportunity to guest kernels to select
>>> between test-and-set and the regular queueu fair lock implementation
>>> based on the PV_DEDICATED KVM feature flag. When the PV_DEDICATED
>>> flag is not set, the code will still fall back to test-and-set,
>>> but when the PV_DEDICATED flag is set, the code will use
>>> the regular queue spinlock implementation.
>>
>> Have you seen Waiman's series that lets you specify this on the guest
>> command line instead?  Would this be acceptable for your use case?
> 
> No, can you please share a link to it? is it already merged to tip/master?

[PATCH-tip v2 0/2] x86/paravirt: Enable users to choose PV lock type
https://lkml.org/lkml/2017/11/1/655

>> (In other words, is there a difference for you between making the host
>> vs. guest administrator toggle the feature?  "@amazon.com" means you are
>> the host admin, how would you use it?)
> 
> The way I think of this is this is a flag set by host side so the
> guest adapts accordingly.
> 
> If the admin in guest side wants to ignore what the host is
> flagging, that is a different story.

Okay, this makes sense.  But perhaps it should be a separate CPUID leaf,
such as "configuration hints", rather than properly a feature.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/1] locking/qspinlock/x86: Avoid test-and-set when PV_DEDICATED is set

2017-11-02 Thread Waiman Long 
On 11/02/2017 02:08 PM, Eduardo Valentin wrote:
> On Thu, Nov 02, 2017 at 06:56:46PM +0100, Paolo Bonzini wrote:
>> On 02/11/2017 18:45, Eduardo Valentin wrote:
>>> Currently, the existing qspinlock implementation will fallback to
>>> test-and-set if the hypervisor has not set the PV_UNHALT flag.
>>>
>>> This patch gives the opportunity to guest kernels to select
>>> between test-and-set and the regular queueu fair lock implementation
>>> based on the PV_DEDICATED KVM feature flag. When the PV_DEDICATED
>>> flag is not set, the code will still fall back to test-and-set,
>>> but when the PV_DEDICATED flag is set, the code will use
>>> the regular queue spinlock implementation.
>> Have you seen Waiman's series that lets you specify this on the guest
>> command line instead?  Would this be acceptable for your use case?
>>
> No, can you please share a link to it? is it already merged to tip/master?

See https://lkml.org/lkml/2017/11/1/655

Cheers,
Longman

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/1] locking/qspinlock/x86: Avoid test-and-set when PV_DEDICATED is set

2017-11-02 Thread Eduardo Valentin 
On Thu, Nov 02, 2017 at 06:56:46PM +0100, Paolo Bonzini wrote:
> On 02/11/2017 18:45, Eduardo Valentin wrote:
> > Currently, the existing qspinlock implementation will fallback to
> > test-and-set if the hypervisor has not set the PV_UNHALT flag.
> > 
> > This patch gives the opportunity to guest kernels to select
> > between test-and-set and the regular queueu fair lock implementation
> > based on the PV_DEDICATED KVM feature flag. When the PV_DEDICATED
> > flag is not set, the code will still fall back to test-and-set,
> > but when the PV_DEDICATED flag is set, the code will use
> > the regular queue spinlock implementation.
> 
> Have you seen Waiman's series that lets you specify this on the guest
> command line instead?  Would this be acceptable for your use case?
> 

No, can you please share a link to it? is it already merged to tip/master?

> (In other words, is there a difference for you between making the host
> vs. guest administrator toggle the feature?  "@amazon.com" means you are
> the host admin, how would you use it?)
> 

The way I think of this is this is a flag set by host side so the guest adapts 
accordingly.

If the admin in guest side wants to ignore what the host is flagging, that is a 
different story.

> Thanks,
> 
> Paolo
> 
> > Cc: Paolo Bonzini 
> > Cc: "Radim Krčmář" 
> > Cc: Jonathan Corbet 
> > Cc: Thomas Gleixner 
> > Cc: Ingo Molnar 
> > Cc: "H. Peter Anvin" 
> > Cc: x...@kernel.org
> > Cc: Peter Zijlstra 
> > Cc: Waiman Long 
> > Cc: k...@vger.kernel.org
> > Cc: linux-doc@vger.kernel.org
> > Cc: linux-ker...@vger.kernel.org
> > Cc: Jan H. Schoenherr 
> > Cc: Anthony Liguori 
> > Suggested-by: Matt Wilson 
> > Signed-off-by: Eduardo Valentin 
> > ---
> > V2:
> >  - rebase on top of tip/master
> > 
> >  Documentation/virtual/kvm/cpuid.txt  | 6 ++
> >  arch/x86/include/asm/qspinlock.h | 4 
> >  arch/x86/include/uapi/asm/kvm_para.h | 1 +
> >  3 files changed, 11 insertions(+)
> > 
> > diff --git a/Documentation/virtual/kvm/cpuid.txt 
> > b/Documentation/virtual/kvm/cpuid.txt
> > index 3c65feb..117066a 100644
> > --- a/Documentation/virtual/kvm/cpuid.txt
> > +++ b/Documentation/virtual/kvm/cpuid.txt
> > @@ -54,6 +54,12 @@ KVM_FEATURE_PV_UNHALT  || 7 || guest 
> > checks this feature bit
> > ||   || before enabling 
> > paravirtualized
> > ||   || spinlock support.
> >  
> > --
> > +KVM_FEATURE_PV_DEDICATED   || 8 || guest checks this feature 
> > bit
> > +   ||   || to determine if they run on
> > +   ||   || dedicated vCPUs, allowing 
> > opti-
> > +   ||   || mizations such as usage of
> > +   ||   || qspinlocks.
> > +--
> >  KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||24 || host will warn if no 
> > guest-side
> > ||   || per-cpu warps are expected 
> > in
> > ||   || kvmclock.
> > diff --git a/arch/x86/include/asm/qspinlock.h 
> > b/arch/x86/include/asm/qspinlock.h
> > index 308dfd0..3751898 100644
> > --- a/arch/x86/include/asm/qspinlock.h
> > +++ b/arch/x86/include/asm/qspinlock.h
> > @@ -2,6 +2,8 @@
> >  #define _ASM_X86_QSPINLOCK_H
> >  
> >  #include 
> > +#include 
> > +
> >  #include 
> >  #include 
> >  #include 
> > @@ -57,6 +59,8 @@ static inline bool virt_spin_lock(struct qspinlock *lock)
> > if (!static_branch_likely(_spin_lock_key))
> > return false;
> >  
> > +   if (kvm_para_has_feature(KVM_FEATURE_PV_DEDICATED))
> > +   return false;
> > /*
> >  * On hypervisors without PARAVIRT_SPINLOCKS support we fall
> >  * back to a Test-and-Set spinlock, because fair locks have
> > diff --git a/arch/x86/include/uapi/asm/kvm_para.h 
> > b/arch/x86/include/uapi/asm/kvm_para.h
> > index a965e5b0..d151300 100644
> > --- a/arch/x86/include/uapi/asm/kvm_para.h
> > +++ b/arch/x86/include/uapi/asm/kvm_para.h
> > @@ -24,6 +24,7 @@
> >  #define KVM_FEATURE_STEAL_TIME 5
> >  #define KVM_FEATURE_PV_EOI 6
> >  #define KVM_FEATURE_PV_UNHALT  7
> > +#define KVM_FEATURE_PV_DEDICATED   8
> >  
> >  /* The last 8 bits are used to indicate how to interpret the flags field
> >   * in pvclock structure. If no bits are set, all flags are ignored.
> > 
> 
> 

-- 
All the best,
Eduardo Valentin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org

[keyutils PATCH v2] man: keyctl_read(3): fix documentation for short buffer case

2017-11-02 Thread Eric Biggers 
From: Eric Biggers 

When keyctl_read() is passed a buffer that is too small, the behavior is
inconsistent.  Some key types will fill as much of the buffer as
possible, while others won't copy anything.  Moreover, the in-kernel
documentation contradicted the man page on this point.

Update the man page to say that this point is unspecified.

Signed-off-by: Eric Biggers 
---
 man/keyctl_read.3 | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/man/keyctl_read.3 b/man/keyctl_read.3
index 25821ad..852bc05 100644
--- a/man/keyctl_read.3
+++ b/man/keyctl_read.3
@@ -33,8 +33,8 @@ permission on a key to be able to read it.
 and
 .I buflen
 specify the buffer into which the payload data will be placed.  If the buffer
-is too small, the full size of the payload will be returned and no copy will
-take place.
+is too small, then the full size of the payload will be returned, and the
+contents of the buffer may be overwritten in some undefined way.
 .P
 .BR keyctl_read_alloc ()
 is similar to
@@ -62,8 +62,8 @@ though the byte-ordering is as appropriate for the kernel.
 On success
 .BR keyctl_read ()
 returns the amount of data placed into the buffer.  If the buffer was too
-small, then the size of buffer required will be returned, but no data will be
-transferred.
+small, then the size of buffer required will be returned, and the contents of
+the buffer may have been overwritten in some undefined way.
 .P
 On success
 .BR keyctl_read_alloc ()
-- 
2.15.0.403.gc27cc4dac6-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] KEYS: fix in-kernel documentation for keyctl_read()

2017-11-02 Thread Eric Biggers 
From: Eric Biggers 

When keyctl_read() is passed a buffer that is too small, the behavior is
inconsistent.  Some key types will fill as much of the buffer as
possible, while others won't copy anything.  Moreover, the in-kernel
documentation contradicted the man page on this point.

Update the in-kernel documentation to say that this point is
unspecified.

Signed-off-by: Eric Biggers 
---
 Documentation/security/keys/core.rst | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/security/keys/core.rst 
b/Documentation/security/keys/core.rst
index 1266eeae45f6..9ce7256c6edb 100644
--- a/Documentation/security/keys/core.rst
+++ b/Documentation/security/keys/core.rst
@@ -628,12 +628,12 @@ The keyctl syscall functions are:
  defined key type will return its data as is. If a key type does not
  implement this function, error EOPNOTSUPP will result.
 
- As much of the data as can be fitted into the buffer will be copied to
- userspace if the buffer pointer is not NULL.
-
- On a successful return, the function will always return the amount of data
- available rather than the amount copied.
+ If the specified buffer is too small, then the size of the buffer required
+ will be returned.  Note that in this case, the contents of the buffer may
+ have been overwritten in some undefined way.
 
+ Otherwise, on success, the function will return the amount of data copied
+ into the buffer.
 
   *  Instantiate a partially constructed key::
 
-- 
2.15.0.403.gc27cc4dac6-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/1] locking/qspinlock/x86: Avoid test-and-set when PV_DEDICATED is set

2017-11-02 Thread Paolo Bonzini 
On 02/11/2017 18:45, Eduardo Valentin wrote:
> Currently, the existing qspinlock implementation will fallback to
> test-and-set if the hypervisor has not set the PV_UNHALT flag.
> 
> This patch gives the opportunity to guest kernels to select
> between test-and-set and the regular queueu fair lock implementation
> based on the PV_DEDICATED KVM feature flag. When the PV_DEDICATED
> flag is not set, the code will still fall back to test-and-set,
> but when the PV_DEDICATED flag is set, the code will use
> the regular queue spinlock implementation.

Have you seen Waiman's series that lets you specify this on the guest
command line instead?  Would this be acceptable for your use case?

(In other words, is there a difference for you between making the host
vs. guest administrator toggle the feature?  "@amazon.com" means you are
the host admin, how would you use it?)

Thanks,

Paolo

> Cc: Paolo Bonzini 
> Cc: "Radim Krčmář" 
> Cc: Jonathan Corbet 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: x...@kernel.org
> Cc: Peter Zijlstra 
> Cc: Waiman Long 
> Cc: k...@vger.kernel.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: Jan H. Schoenherr 
> Cc: Anthony Liguori 
> Suggested-by: Matt Wilson 
> Signed-off-by: Eduardo Valentin 
> ---
> V2:
>  - rebase on top of tip/master
> 
>  Documentation/virtual/kvm/cpuid.txt  | 6 ++
>  arch/x86/include/asm/qspinlock.h | 4 
>  arch/x86/include/uapi/asm/kvm_para.h | 1 +
>  3 files changed, 11 insertions(+)
> 
> diff --git a/Documentation/virtual/kvm/cpuid.txt 
> b/Documentation/virtual/kvm/cpuid.txt
> index 3c65feb..117066a 100644
> --- a/Documentation/virtual/kvm/cpuid.txt
> +++ b/Documentation/virtual/kvm/cpuid.txt
> @@ -54,6 +54,12 @@ KVM_FEATURE_PV_UNHALT  || 7 || guest 
> checks this feature bit
> ||   || before enabling 
> paravirtualized
> ||   || spinlock support.
>  
> --
> +KVM_FEATURE_PV_DEDICATED   || 8 || guest checks this feature bit
> +   ||   || to determine if they run on
> +   ||   || dedicated vCPUs, allowing 
> opti-
> +   ||   || mizations such as usage of
> +   ||   || qspinlocks.
> +--
>  KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||24 || host will warn if no 
> guest-side
> ||   || per-cpu warps are expected in
> ||   || kvmclock.
> diff --git a/arch/x86/include/asm/qspinlock.h 
> b/arch/x86/include/asm/qspinlock.h
> index 308dfd0..3751898 100644
> --- a/arch/x86/include/asm/qspinlock.h
> +++ b/arch/x86/include/asm/qspinlock.h
> @@ -2,6 +2,8 @@
>  #define _ASM_X86_QSPINLOCK_H
>  
>  #include 
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -57,6 +59,8 @@ static inline bool virt_spin_lock(struct qspinlock *lock)
>   if (!static_branch_likely(_spin_lock_key))
>   return false;
>  
> + if (kvm_para_has_feature(KVM_FEATURE_PV_DEDICATED))
> + return false;
>   /*
>* On hypervisors without PARAVIRT_SPINLOCKS support we fall
>* back to a Test-and-Set spinlock, because fair locks have
> diff --git a/arch/x86/include/uapi/asm/kvm_para.h 
> b/arch/x86/include/uapi/asm/kvm_para.h
> index a965e5b0..d151300 100644
> --- a/arch/x86/include/uapi/asm/kvm_para.h
> +++ b/arch/x86/include/uapi/asm/kvm_para.h
> @@ -24,6 +24,7 @@
>  #define KVM_FEATURE_STEAL_TIME   5
>  #define KVM_FEATURE_PV_EOI   6
>  #define KVM_FEATURE_PV_UNHALT7
> +#define KVM_FEATURE_PV_DEDICATED 8
>  
>  /* The last 8 bits are used to indicate how to interpret the flags field
>   * in pvclock structure. If no bits are set, all flags are ignored.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 1/1] locking/qspinlock/x86: Avoid test-and-set when PV_DEDICATED is set

2017-11-02 Thread Eduardo Valentin 
Currently, the existing qspinlock implementation will fallback to
test-and-set if the hypervisor has not set the PV_UNHALT flag.

This patch gives the opportunity to guest kernels to select
between test-and-set and the regular queueu fair lock implementation
based on the PV_DEDICATED KVM feature flag. When the PV_DEDICATED
flag is not set, the code will still fall back to test-and-set,
but when the PV_DEDICATED flag is set, the code will use
the regular queue spinlock implementation.

Cc: Paolo Bonzini 
Cc: "Radim Krčmář" 
Cc: Jonathan Corbet 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: Peter Zijlstra 
Cc: Waiman Long 
Cc: k...@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Jan H. Schoenherr 
Cc: Anthony Liguori 
Suggested-by: Matt Wilson 
Signed-off-by: Eduardo Valentin 
---
V2:
 - rebase on top of tip/master

 Documentation/virtual/kvm/cpuid.txt  | 6 ++
 arch/x86/include/asm/qspinlock.h | 4 
 arch/x86/include/uapi/asm/kvm_para.h | 1 +
 3 files changed, 11 insertions(+)

diff --git a/Documentation/virtual/kvm/cpuid.txt 
b/Documentation/virtual/kvm/cpuid.txt
index 3c65feb..117066a 100644
--- a/Documentation/virtual/kvm/cpuid.txt
+++ b/Documentation/virtual/kvm/cpuid.txt
@@ -54,6 +54,12 @@ KVM_FEATURE_PV_UNHALT  || 7 || guest checks 
this feature bit
||   || before enabling paravirtualized
||   || spinlock support.
 --
+KVM_FEATURE_PV_DEDICATED   || 8 || guest checks this feature bit
+   ||   || to determine if they run on
+   ||   || dedicated vCPUs, allowing opti-
+   ||   || mizations such as usage of
+   ||   || qspinlocks.
+--
 KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||24 || host will warn if no guest-side
||   || per-cpu warps are expected in
||   || kvmclock.
diff --git a/arch/x86/include/asm/qspinlock.h b/arch/x86/include/asm/qspinlock.h
index 308dfd0..3751898 100644
--- a/arch/x86/include/asm/qspinlock.h
+++ b/arch/x86/include/asm/qspinlock.h
@@ -2,6 +2,8 @@
 #define _ASM_X86_QSPINLOCK_H
 
 #include 
+#include 
+
 #include 
 #include 
 #include 
@@ -57,6 +59,8 @@ static inline bool virt_spin_lock(struct qspinlock *lock)
if (!static_branch_likely(_spin_lock_key))
return false;
 
+   if (kvm_para_has_feature(KVM_FEATURE_PV_DEDICATED))
+   return false;
/*
 * On hypervisors without PARAVIRT_SPINLOCKS support we fall
 * back to a Test-and-Set spinlock, because fair locks have
diff --git a/arch/x86/include/uapi/asm/kvm_para.h 
b/arch/x86/include/uapi/asm/kvm_para.h
index a965e5b0..d151300 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -24,6 +24,7 @@
 #define KVM_FEATURE_STEAL_TIME 5
 #define KVM_FEATURE_PV_EOI 6
 #define KVM_FEATURE_PV_UNHALT  7
+#define KVM_FEATURE_PV_DEDICATED   8
 
 /* The last 8 bits are used to indicate how to interpret the flags field
  * in pvclock structure. If no bits are set, all flags are ignored.
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Echte Darlehen Angebot bei 2%

2017-11-02 Thread Mr Kelly Williams 
Schönen Tag,

Sie benötigen einen echten Kredit online Ihre Rechnungen zu sichern?
Startet ein neues Unternehmen? Sie benötigen einen persönlichen Kredit
oder Business-Darlehen? Wir bieten ein Darlehen von € 10.000 bis €
500,000.000.00 mit 2% Zinsen pro Jahr und auch mit einem
erschwinglichen Rückzahlungsbedingungen und Zustand. Ich suche für
Darlehen und Projektinvestmentfonds ? Wir halten professionelle
Exzellenz, unsere Definition von Exzellenz liegt in hervorragenden
Kundenservice, erschwingliche Zahlung und Rückzahlung Pläne, schnell
und einfach-Prozess.
Hochachtungsvoll

Freundliche Grüße,
Herr Kelly Williams
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html