[PATCH v3] doc: add maintainer book

[Tobin C. Harding]

There is currently very little documentation in the kernel on maintainer
level tasks. In particular there are no documents on creating pull
requests to submit to Linus.

Quoting Greg Kroah-Hartman on LKML:

Anyway, this actually came up at the kernel summit / maintainer
meeting a few weeks ago, in that "how do I make a
good pull request to Linus" is something we need to document.

Here's what I do, and it seems to work well, so maybe we should turn
it into the start of the documentation for how to do it.

(quote references: kernel summit, Europe 2017)

Create a new kernel documentation book 'how to be a maintainer'
(suggested by Jonathan Corbet). Add chapters on 'configuring git' and
'creating a pull request'.

Most of the content was written by Linus Torvalds and Greg Kroah-Hartman
in discussion on LKML. This is stated at the start of one of the
chapters and the original email thread is referenced in
'pull-requests.rst'.

Signed-off-by: Tobin C. Harding 
Reviewed-by: Greg Kroah-Hartman 

---

v3:
 - Modified details for branch and tag naming, suggested by Mauro
   Carvalho Chehab.
 - Added example email subject line for submitting pull requests.
 - Re-added Greg's reviewed-by tag from version 1.

v2:
 - Change title of book, suggested by Dan Williams.

---
 Documentation/index.rst|   1 +
 Documentation/maintainer/conf.py   |  10 ++
 Documentation/maintainer/configure-git.rst |  34 ++
 Documentation/maintainer/index.rst |  10 ++
 Documentation/maintainer/pull-requests.rst | 182 +
 5 files changed, 237 insertions(+)
 create mode 100644 Documentation/maintainer/conf.py
 create mode 100644 Documentation/maintainer/configure-git.rst
 create mode 100644 Documentation/maintainer/index.rst
 create mode 100644 Documentation/maintainer/pull-requests.rst

diff --git a/Documentation/index.rst b/Documentation/index.rst
index cb7f1ba5b3b1..a4fb34dddcf3 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -52,6 +52,7 @@ merged much easier.
dev-tools/index
doc-guide/index
kernel-hacking/index
+   maintainer/index
 
 Kernel API documentation
 
diff --git a/Documentation/maintainer/conf.py b/Documentation/maintainer/conf.py
new file mode 100644
index ..81e9eb7a7884
--- /dev/null
+++ b/Documentation/maintainer/conf.py
@@ -0,0 +1,10 @@
+# -*- coding: utf-8; mode: python -*-
+
+project = 'Linux Kernel Development Documentation'
+
+tags.add("subproject")
+
+latex_documents = [
+('index', 'maintainer.tex', 'Linux Kernel Development Documentation',
+ 'The kernel development community', 'manual'),
+]
diff --git a/Documentation/maintainer/configure-git.rst 
b/Documentation/maintainer/configure-git.rst
new file mode 100644
index ..780d2c84
--- /dev/null
+++ b/Documentation/maintainer/configure-git.rst
@@ -0,0 +1,34 @@
+.. _configuregit:
+
+Configure Git
+=
+
+This chapter describes maintainer level git configuration.
+
+Tagged branches used in :ref:`Documentation/maintainer/pull-requests.rst
+` should be signed with the developers public GPG key. Signed
+tags can be created by passing the ``-u`` flag to ``git tag``. However,
+since you would *usually* use the same key for the same project, you can
+set it once with
+::
+
+   git config user.signingkey "keyname"
+
+Alternatively, edit your ``.git/config`` or ``~/.gitconfig`` file by hand:
+::
+
+   [user]
+   name = Jane Developer
+   email = j...@domain.org
+   signingkey = j...@domain.org
+
+You may need to tell ``git`` to use ``gpg2``
+::
+
+   [gpg]
+   program = /path/to/gpg2
+
+You may also like to tell ``gpg`` which ``tty`` to use (add to your shell rc 
file)
+::
+
+   export GPG_TTY=$(tty)
diff --git a/Documentation/maintainer/index.rst 
b/Documentation/maintainer/index.rst
new file mode 100644
index ..fa84ac9cae39
--- /dev/null
+++ b/Documentation/maintainer/index.rst
@@ -0,0 +1,10 @@
+==
+Kernel Maintainer Handbook
+==
+
+.. toctree::
+   :maxdepth: 2
+
+   configure-git
+   pull-requests
+
diff --git a/Documentation/maintainer/pull-requests.rst 
b/Documentation/maintainer/pull-requests.rst
new file mode 100644
index ..a25e1002a5b9
--- /dev/null
+++ b/Documentation/maintainer/pull-requests.rst
@@ -0,0 +1,182 @@
+.. _pullrequests:
+
+Creating Pull Requests
+==
+
+This chapter describes how maintainers can create and submit pull requests
+to other maintainers. This is useful for transferring changes from one
+maintainers tree to another maintainers tree.
+
+This document was written by Tobin C. Harding (who at that time, was not an
+experienced maintainer) primarily from comments made by Greg Kroah-Hartman
+and Linus Torvalds on LKML. Suggestions and fixes by Jonathan Corbet.
+Misrepresentation was unintentional but inevitable, please d

[PATCH] docs: Expand refcount_t documentation

[Kees Cook]

This updates basics.rst to include refcount_t so it can be referenced by
other .rst files, fixes a kernel-doc typo in refcount.h so the struct
will be documented, and enhances the markup of the refcount-vs-atomic doc.

Signed-off-by: Kees Cook 
---
This builds on the "refcount-vs-atomic.rst" patch...

Elena, feel free to fold this into your refcount_t doc. Future revisions
should likely get sent to Jon Corbet and CC linux-doc.
---
 Documentation/core-api/refcount-vs-atomic.rst | 84 ---
 Documentation/driver-api/basics.rst   | 21 +--
 include/linux/refcount.h  |  2 +-
 3 files changed, 67 insertions(+), 40 deletions(-)

diff --git a/Documentation/core-api/refcount-vs-atomic.rst 
b/Documentation/core-api/refcount-vs-atomic.rst
index 5619d486e70e..315d5f882331 100644
--- a/Documentation/core-api/refcount-vs-atomic.rst
+++ b/Documentation/core-api/refcount-vs-atomic.rst
@@ -2,11 +2,16 @@
 refcount_t API compared to atomic_t
 ===
 
+.. contents:: :local:
+
+Introduction
+
+
 The goal of refcount_t API is to provide a minimal API for implementing
 an object's reference counters. While a generic architecture-independent
 implementation from lib/refcount.c uses atomic operations underneath,
-there are a number of differences between some of the refcount_*() and
-atomic_*() functions with regards to the memory ordering guarantees.
+there are a number of differences between some of the ``refcount_*()`` and
+``atomic_*()`` functions with regards to the memory ordering guarantees.
 This document outlines the differences and provides respective examples
 in order to help maintainers validate their code against the change in
 these memory ordering guarantees.
@@ -17,17 +22,17 @@ memory ordering in general and for atomic operations 
specifically.
 Relevant types of memory ordering
 =
 
-**Note**: the following section only covers some of the memory
-ordering types that are relevant for the atomics and reference
-counters and used through this document. For a much broader picture
-please consult memory-barriers.txt document.
+.. note:: The following section only covers some of the memory
+   ordering types that are relevant for the atomics and reference
+   counters and used through this document. For a much broader picture
+   please consult memory-barriers.txt document.
 
 In the absence of any memory ordering guarantees (i.e. fully unordered)
 atomics & refcounters only provide atomicity and
 program order (po) relation (on the same CPU). It guarantees that
-each atomic_*() and refcount_*() operation is atomic and instructions
+each ``atomic_*()`` and ``refcount_*()`` operation is atomic and instructions
 are executed in program order on a single CPU.
-This is implemented using READ_ONCE()/WRITE_ONCE() and
+This is implemented using :c:func:`READ_ONCE`/:c:func:`WRITE_ONCE` and
 compare-and-swap primitives.
 
 A strong (full) memory ordering guarantees that all prior loads and
@@ -36,14 +41,15 @@ before any po-later instruction is executed on the same CPU.
 It also guarantees that all po-earlier stores on the same CPU
 and all propagated stores from other CPUs must propagate to all
 other CPUs before any po-later instruction is executed on the original
-CPU (A-cumulative property). This is implemented using smp_mb().
+CPU (A-cumulative property). This is implemented using :c:func:`smp_mb`.
 
 A RELEASE memory ordering guarantees that all prior loads and
 stores (all po-earlier instructions) on the same CPU are completed
 before the operation. It also guarantees that all po-earlier
 stores on the same CPU and all propagated stores from other CPUs
 must propagate to all other CPUs before the release operation
-(A-cumulative property). This is implemented using smp_store_release().
+(A-cumulative property). This is implemented using
+:c:func:`smp_store_release`.
 
 A control dependency (on success) for refcounters guarantees that
 if a reference for an object was successfully obtained (reference
@@ -61,59 +67,70 @@ case 1) - non-"Read/Modify/Write" (RMW) ops
 ---
 
 Function changes:
-atomic_set() --> refcount_set()
-atomic_read() --> refcount_read()
+
+ * :c:func:`atomic_set` --> :c:func:`refcount_set`
+ * :c:func:`atomic_read` --> :c:func:`refcount_read`
 
 Memory ordering guarantee changes:
-none (both fully unordered)
+
+ * none (both fully unordered)
+
 
 case 2) - increment-based ops that return no value
 --
 
 Function changes:
-atomic_inc() --> refcount_inc()
-atomic_add() --> refcount_add()
+
+ * :c:func:`atomic_inc` --> :c:func:`refcount_inc`
+ * :c:func:`atomic_add` --> :c:func:`refcount_add`
 
 Memory ordering guarantee changes:
-none (both fully unordered)
 
+ * none (both fully unordered)
 
 case 3)

Re: [PATCH] refcount_t: documentation for memory ordering differences

[Kees Cook]

On Wed, Nov 29, 2017 at 4:36 AM, Elena Reshetova
 wrote:
> Some functions from refcount_t API provide different
> memory ordering guarantees that their atomic counterparts.
> This adds a document outlining these differences.
>
> Signed-off-by: Elena Reshetova 

Thanks for the improvements!

I have some markup changes to add, but I'll send that as a separate patch.

Acked-by: Kees Cook 

-Kees

> ---
>  Documentation/core-api/index.rst  |   1 +
>  Documentation/core-api/refcount-vs-atomic.rst | 129 
> ++
>  2 files changed, 130 insertions(+)
>  create mode 100644 Documentation/core-api/refcount-vs-atomic.rst
>
> diff --git a/Documentation/core-api/index.rst 
> b/Documentation/core-api/index.rst
> index d5bbe03..d4d54b0 100644
> --- a/Documentation/core-api/index.rst
> +++ b/Documentation/core-api/index.rst
> @@ -14,6 +14,7 @@ Core utilities
> kernel-api
> assoc_array
> atomic_ops
> +   refcount-vs-atomic
> cpu_hotplug
> local_ops
> workqueue
> diff --git a/Documentation/core-api/refcount-vs-atomic.rst 
> b/Documentation/core-api/refcount-vs-atomic.rst
> new file mode 100644
> index 000..5619d48
> --- /dev/null
> +++ b/Documentation/core-api/refcount-vs-atomic.rst
> @@ -0,0 +1,129 @@
> +===
> +refcount_t API compared to atomic_t
> +===
> +
> +The goal of refcount_t API is to provide a minimal API for implementing
> +an object's reference counters. While a generic architecture-independent
> +implementation from lib/refcount.c uses atomic operations underneath,
> +there are a number of differences between some of the refcount_*() and
> +atomic_*() functions with regards to the memory ordering guarantees.
> +This document outlines the differences and provides respective examples
> +in order to help maintainers validate their code against the change in
> +these memory ordering guarantees.
> +
> +memory-barriers.txt and atomic_t.txt provide more background to the
> +memory ordering in general and for atomic operations specifically.
> +
> +Relevant types of memory ordering
> +=
> +
> +**Note**: the following section only covers some of the memory
> +ordering types that are relevant for the atomics and reference
> +counters and used through this document. For a much broader picture
> +please consult memory-barriers.txt document.
> +
> +In the absence of any memory ordering guarantees (i.e. fully unordered)
> +atomics & refcounters only provide atomicity and
> +program order (po) relation (on the same CPU). It guarantees that
> +each atomic_*() and refcount_*() operation is atomic and instructions
> +are executed in program order on a single CPU.
> +This is implemented using READ_ONCE()/WRITE_ONCE() and
> +compare-and-swap primitives.
> +
> +A strong (full) memory ordering guarantees that all prior loads and
> +stores (all po-earlier instructions) on the same CPU are completed
> +before any po-later instruction is executed on the same CPU.
> +It also guarantees that all po-earlier stores on the same CPU
> +and all propagated stores from other CPUs must propagate to all
> +other CPUs before any po-later instruction is executed on the original
> +CPU (A-cumulative property). This is implemented using smp_mb().
> +
> +A RELEASE memory ordering guarantees that all prior loads and
> +stores (all po-earlier instructions) on the same CPU are completed
> +before the operation. It also guarantees that all po-earlier
> +stores on the same CPU and all propagated stores from other CPUs
> +must propagate to all other CPUs before the release operation
> +(A-cumulative property). This is implemented using smp_store_release().
> +
> +A control dependency (on success) for refcounters guarantees that
> +if a reference for an object was successfully obtained (reference
> +counter increment or addition happened, function returned true),
> +then further stores are ordered against this operation.
> +Control dependency on stores are not implemented using any explicit
> +barriers, but rely on CPU not to speculate on stores. This is only
> +a single CPU relation and provides no guarantees for other CPUs.
> +
> +
> +Comparison of functions
> +===
> +
> +case 1) - non-"Read/Modify/Write" (RMW) ops
> +---
> +
> +Function changes:
> +atomic_set() --> refcount_set()
> +atomic_read() --> refcount_read()
> +
> +Memory ordering guarantee changes:
> +none (both fully unordered)
> +
> +case 2) - increment-based ops that return no value
> +--
> +
> +Function changes:
> +atomic_inc() --> refcount_inc()
> +atomic_add() --> refcount_add()
> +
> +Memory ordering guarantee changes:
> +none (both fully unordered)
> +
> +
> +case 3) - decrement-based RMW ops that return no value
> +---

Re: [PATCH v5] HID: hid-multitouch: support fine-grain orientation reporting

[Henrik Rydberg]

On 10/12/2017 08:21 AM, Wei-Ning Huang wrote:

From: Wei-Ning Huang 

The current hid-multitouch driver only allow the report of two
orientations, vertical and horizontal. We use the Azimuth orientation
usage 0x3F under the Digitizer usage page to report orientation if the
device supports it.

Changelog:
   v1 -> v2:
- Fix commit message.
- Remove resolution reporting for ABS_MT_ORIENTATION.
   v2 -> v3:
- Fix commit message.
   v3 -> v4:
- Fix ABS_MT_ORIENTATION ABS param range.
- Don't set ABS_MT_ORIENTATION in ABS_DG_HEIGHT when it is already
  set by ABS_DG_AZIMUTH.
   v4 -> v5:
- Improve multi-touch-protocol.rst documentation.

Signed-off-by: Wei-Ning Huang 
Signed-off-by: Wei-Ning Huang 
Reviewed-by: Dmitry Torokhov 
---
  Documentation/input/multi-touch-protocol.rst |  9 ++---
  drivers/hid/hid-multitouch.c | 52 +---
  include/linux/hid.h  |  1 +
  3 files changed, 54 insertions(+), 8 deletions(-)


   Reviewed-by: Henrik Rydberg 

Thank you, Wei-Ning, and sorry for the delay. Dmitry, did you plan to 
add this to your pull request already?


Henrik

--
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: [PATCH v5] HID: hid-multitouch: support fine-grain orientation reporting

[Dmitry Torokhov]

On Wed, Nov 29, 2017 at 11:33:58PM +0100, Henrik Rydberg wrote:
> On 10/12/2017 08:21 AM, Wei-Ning Huang wrote:
> > From: Wei-Ning Huang 
> > 
> > The current hid-multitouch driver only allow the report of two
> > orientations, vertical and horizontal. We use the Azimuth orientation
> > usage 0x3F under the Digitizer usage page to report orientation if the
> > device supports it.
> > 
> > Changelog:
> >v1 -> v2:
> > - Fix commit message.
> > - Remove resolution reporting for ABS_MT_ORIENTATION.
> >v2 -> v3:
> > - Fix commit message.
> >v3 -> v4:
> > - Fix ABS_MT_ORIENTATION ABS param range.
> > - Don't set ABS_MT_ORIENTATION in ABS_DG_HEIGHT when it is already
> >   set by ABS_DG_AZIMUTH.
> >v4 -> v5:
> > - Improve multi-touch-protocol.rst documentation.
> > 
> > Signed-off-by: Wei-Ning Huang 
> > Signed-off-by: Wei-Ning Huang 
> > Reviewed-by: Dmitry Torokhov 
> > ---
> >   Documentation/input/multi-touch-protocol.rst |  9 ++---
> >   drivers/hid/hid-multitouch.c | 52 
> > +---
> >   include/linux/hid.h  |  1 +
> >   3 files changed, 54 insertions(+), 8 deletions(-)
> 
>    Reviewed-by: Henrik Rydberg 
> 
> Thank you, Wei-Ning, and sorry for the delay. Dmitry, did you plan to add
> this to your pull request already?

This should go through Jiri's tree as it is all HID stuff.

Thanks.

-- 
Dmitry
--
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: [v6,4/4] pmbus (max31785): Add dual tachometer support

[Guenter Roeck]

On Mon, Nov 20, 2017 at 03:12:06PM +1030, Andrew Jeffery wrote:
> 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 pages 23-28 (not defined by the
> hardware) 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 corresponds to the first word of the response. The
> TACHSEL=0 measurement is used by the controller's closed-loop fan
> management to judge target fan rate.
> 
> Signed-off-by: Andrew Jeffery 

Applied.

Thanks,
Guenter

> ---
>  Documentation/hwmon/max31785   |   8 +-
>  drivers/hwmon/pmbus/max31785.c | 147 ++-
>  2 files changed, 152 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/hwmon/max31785 b/Documentation/hwmon/max31785
> index 7b0a0a8cdb6b..270c5f865261 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]_target  Fan 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 8706a696c89a..bffab449be39 100644
> --- a/drivers/hwmon/pmbus/max31785.c
> +++ b/drivers/hwmon/pmbus/max31785.c
> @@ -16,9 +16,79 @@
>  
>  enum max31785_regs {
>   MFR_REVISION= 0x9b,
> + MFR_FAN_CONFIG  = 0xf1,
>  };
>  
> +#define MAX31785 0x3030
> +#define MAX31785A0x3040
> +
> +#define MFR_FAN_CONFIG_DUAL_TACH BIT(12)
> +
>  #define MAX31785_NR_PAGES23
> +#define MAX31785_NR_FAN_PAGES6
> +
> +static int max31785_read_byte_data(struct i2c_client *client, int page,
> +int reg)
> +{
> + if (page < MAX31785_NR_PAGES)
> + return -ENODATA;
> +
> + switch (reg) {
> + case PMBUS_VOUT_MODE:
> + return -ENOTSUPP;
> + case PMBUS_FAN_CONFIG_12:
> + 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)
>  {
> @@ -62,9 +132,30 @

Re: [v6,3/4] pmbus (core): Add virtual page config bit

[Guenter Roeck]

On Mon, Nov 20, 2017 at 03:12:05PM +1030, Andrew Jeffery wrote:
> 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. An example of this is the Maxim MAX31785 controller,
> which extends the READ_FAN_SPEED_1 PMBus register from two to four bytes
> to support tach readings for both rotors of a dual rotor fan. This extended
> register contains two word-sized values, one reporting the rate of the
> fastest rotor, the other the rate of the slowest. The concept of virtual
> pages aids this situation by mapping the page number onto the value to be
> selected from the vectored result.
> 
> We should not try to set virtual pages on the device as such a page
> explicitly doesn't exist; add a flag so we can avoid doing so.
> 
> Signed-off-by: Andrew Jeffery 

Applied.

Thanks,
Guenter

> ---
>  drivers/hwmon/pmbus/pmbus.h  |  2 ++
>  drivers/hwmon/pmbus/pmbus_core.c | 27 ++-
>  2 files changed, 20 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
> index b54d7604d3ef..d39d506aa63e 100644
> --- a/drivers/hwmon/pmbus/pmbus.h
> +++ b/drivers/hwmon/pmbus/pmbus.h
> @@ -372,6 +372,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 edc25efe7552..e215bbd403a5 100644
> --- a/drivers/hwmon/pmbus/pmbus_core.c
> +++ b/drivers/hwmon/pmbus/pmbus_core.c
> @@ -161,18 +161,27 @@ EXPORT_SYMBOL_GPL(pmbus_clear_cache);
>  int pmbus_set_page(struct i2c_client *client, int page)
>  {
>   struct pmbus_data *data = i2c_get_clientdata(client);
> - int rv = 0;
> - int newpage;
> + int rv;
> +
> + if (page < 0 || page == data->currpage)
> + return 0;
>  
> - if (page >= 0 && page != data->currpage) {
> + 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;
> + if (rv < 0)
> + return rv;
> +
> + rv = i2c_smbus_read_byte_data(client, PMBUS_PAGE);
> + if (rv < 0)
> + return rv;
> +
> + if (rv != page)
> + return -EIO;
>   }
> - return rv;
> +
> + data->currpage = page;
> +
> + return 0;
>  }
>  EXPORT_SYMBOL_GPL(pmbus_set_page);
>  
--
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: [v6,2/4] pmbus (max31785): Add fan control

[Guenter Roeck]

On Mon, Nov 20, 2017 at 03:12:04PM +1030, Andrew Jeffery wrote:
> 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 

Applied.

Thanks,
Guenter

> ---
>  Documentation/hwmon/max31785   |   7 ++-
>  drivers/hwmon/pmbus/max31785.c | 138 +-
>  2 files changed, 144 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/hwmon/max31785 b/Documentation/hwmon/max31785
> index 45fb6093dec2..7b0a0a8cdb6b 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]_target  Fan input target
>  
>  in[1-6]_crit Critical maximum output voltage
>  in[1-6]_crit_alarm   Output voltage critical high alarm
> @@ -44,6 +45,12 @@ in[1-6]_max_alarm  Output voltage high alarm
>  in[1-6]_min  Minimum output voltage
>  in[1-6]_min_alarmOutput voltage low alarm
>  
> +pwm[1-4] Fan target duty cycle (0..255)
> +pwm[1-4]_enable  0: Full-speed
> + 1: Manual PWM control
> + 2: Automatic PWM (tach-feedback RPM fan-control)
> + 3: Automatic closed-loop (temp-feedback fan-control)
> +
>  temp[1-11]_crit  Critical high temperature
>  temp[1-11]_crit_alarmChip 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..8706a696c89a 100644
> --- a/drivers/hwmon/pmbus/max31785.c
> +++ b/drivers/hwmon/pmbus/max31785.c
> @@ -20,8 +20,136 @@ enum max31785_regs {
>  
>  #define MAX31785_NR_PAGES23
>  
> +static int max31785_get_pwm(struct i2c_client *client, int page)
> +{
> + int rv;
> +
> + rv = pmbus_get_fan_rate_device(client, page, 0, percent);
> + if (rv < 0)
> + return rv;
> + else if (rv >= 0x8000)
> + return 0;
> + else if (rv >= 0x2711)
> + return 0x2710;
> +
> + return rv;
> +}
> +
> +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)
> + return (command >= 0x8000) ? 3 : 2;
> +
> + if (command >= 0x8000)
> + return 3;
> + else if (command >= 0x2711)
> + return 0;
> +
> + return 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);
> + break;
> + case PMBUS_VIRT_PWM_ENABLE_1:
> + rv = max31785_get_pwm_mode(client, page);
> + break;
> + default:
> + rv = -ENODATA;
> + break;
> + }
> +
> + return rv;
> +}
> +
> +static inline u32 max31785_scale_pwm(u32 sensor_val)
> +{
> + /*
> +  * The datasheet describes the accepted value range for manual PWM as
> +  * [0, 0x2710], while the hwmon pwmX sysfs interface accepts values in
> +  * [0, 255]. The MAX31785 uses DIRECT mode to scale the FAN_COMMAND
> +  * registers and in PWM mode the coefficients are m=1, b=0, R=2. The
> +  * important observation here is that 0x2710 == 1 == 100 * 100.
> +  *
> +  * R=2 (== 10^2 == 100) accounts for scaling the value provided at the
> +  * sysfs interface into the required hardware resolution, but it does
> +  * not yet yield a value that we can write to the device (this initial
> +  * scaling is handled by pmbus_data2reg()). Multiplying by 100 below
> +  * translates the parameter value into the percentage units required by
> +  * PMBus, and then we scale back by 255 as required by the hwmon pwmX
> +  * interface to yield the percentage value at the appropriate
> +  * resolution for hardware.
> +  */
> + return (sensor_val * 100) / 255;
> +}
> +
> +static int max31785_pwm_enable(struct i2c_client *client, int page,
> + u16 word)
> +{
> + int config = 0;
> + int rate;
> +
> + switch (word) {
> + case 0:
> + rate = 0x7fff;
> + break;
> + case 1:
> + 

Re: [v6,1/4] pmbus (core): Add fan control support

[Guenter Roeck]

On Mon, Nov 20, 2017 at 03:12:03PM +1030, Andrew Jeffery wrote:
> 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 configuration in 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 to
> facilitate the necessary side-effects of each access:
> 
> 1. PMBUS_VIRT_FAN_TARGET_x
> 2. PMBUS_VIRT_PWM_x
> 3. PMBUS_VIRT_PWM_ENABLE_x
> 
> Some complexity arises with the fanX_target and pwmX attributes both mapping
> onto FAN_COMMAND_x: There is no general mapping between PWM percent duty and
> RPM, so we can't display values in either attribute in terms of the other
> (which in my mind is the intuitive, if impossible, behaviour). This problem
> also affects the pwmX_enable attribute which allows userspace to switch 
> between
> full speed, manual PWM and a number of automatic control modes, possibly
> including a switch to RPM behaviour (e.g. automatically adjusting PWM duty to
> reach a RPM target, the behaviour of fanX_target).
> 
> The next most intuitive behaviour is for fanX_target and pwmX to simply be
> independent, to retain their most recently set value even if that value is not
> active on the hardware (due to switching to the alternative control mode). 
> This
> property of retaining the value independent of the hardware state has useful
> results for both userspace and the kernel: Userspace always sees a sensible
> value in the attribute (the last thing it was set to, as opposed to 0 or
> receiving an error on read), and the kernel can use the attributes as a value
> cache. This latter point eases the implementation of pwmX_enable, which can
> look up the associated pmbus_sensor object, take its cached value and apply it
> to hardware on changing control mode. This ensures we will not arbitrarily set
> a PWM value as an RPM value or vice versa, and we can assume that the RPM or
> PWM value set was sensible at least at some point in the past.
> 
> Finally, the DIRECT mode coefficients of some controllers is different between
> RPM and PWM percent duty control modes, so PSC_PWM is introduced to capture 
> the
> necessary coefficients. As pmbus core had no PWM support previously PSC_FAN
> continues to be used to capture the RPM DIRECT coefficients, but in order to
> avoid falsely applying RPM scaling to PWM values I have introduced the
> PMBUS_HAVE_PWM12 and PMB_BUS_HAVE_PWM34 feature bits. These feature bits allow
> drivers to explicitly declare PWM support in order to have the attributes
> exposed.
> 
> Signed-off-by: Andrew Jeffery 

Appled (fixed whitespace problem).

Thanks,
Guenter
--
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 2/2 v2] Documentation: add UUID/GUID to kernel-api

[Randy Dunlap]

From: Randy Dunlap 

Update kernel-doc notation in lib/uuid.c and then add UUID/GUID
function interfaces to kernel-api.

Signed-off-by: Randy Dunlap 
---
 Documentation/core-api/kernel-api.rst |6 
 lib/uuid.c|   34 
 2 files changed, 23 insertions(+), 17 deletions(-)

v2: updated to apply cleanly.

--- linux-next-20171129.orig/lib/uuid.c
+++ linux-next-20171129/lib/uuid.c
@@ -29,15 +29,14 @@ EXPORT_SYMBOL(uuid_null);
 const u8 guid_index[16] = {3,2,1,0,5,4,7,6,8,9,10,11,12,13,14,15};
 const u8 uuid_index[16] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
 
-/***
+/**
+ * generate_random_uuid - generate a random UUID
+ * @uuid: where to put the generated UUID
+ *
  * Random UUID interface
  *
- * Used here for a Boot ID, but can be useful for other kernel
- * drivers.
- ***/
-
-/*
- * Generate random UUID
+ * Used to create a Boot ID or a filesystem UUID/GUID, but can be
+ * useful for other kernel drivers.
  */
 void generate_random_uuid(unsigned char uuid[16])
 {
@@ -73,16 +72,17 @@ void uuid_gen(uuid_t *bu)
 EXPORT_SYMBOL_GPL(uuid_gen);
 
 /**
-  * uuid_is_valid - checks if UUID string valid
-  * @uuid: UUID string to check
-  *
-  * Description:
-  * It checks if the UUID string is following the format:
-  *----
-  * where x is a hex digit.
-  *
-  * Return: true if input is valid UUID string.
-  */
+ * uuid_is_valid - checks if UUID string valid
+ * @uuid:  UUID string to check
+ *
+ * Description:
+ * It checks if the UUID string is following the format:
+ * ----
+ *
+ * where x is a hex digit.
+ *
+ * Return: true if input is valid UUID string.
+ */
 bool uuid_is_valid(const char *uuid)
 {
unsigned int i;
--- linux-next-20171129.orig/Documentation/core-api/kernel-api.rst
+++ linux-next-20171129/Documentation/core-api/kernel-api.rst
@@ -148,6 +148,12 @@ Sorting
 .. kernel-doc:: lib/list_sort.c
:export:
 
+UUID/GUID
+-
+
+.. kernel-doc:: lib/uuid.c
+   :export:
+
 Memory Management in Linux
 ==
 
--
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 1/2 v2] Documentation: add Sorting section to kernel-api

[Randy Dunlap]

From: Randy Dunlap 

Add sort() and list_sort() to the kernel API documentation in a
new "Sorting" section.

Signed-off-by: Randy Dunlap 
---
 Documentation/core-api/kernel-api.rst |9 +
 1 file changed, 9 insertions(+)

v2: updated to apply cleanly.

--- linux-next-20171129.orig/Documentation/core-api/kernel-api.rst
+++ linux-next-20171129/Documentation/core-api/kernel-api.rst
@@ -139,6 +139,15 @@ Division Functions
 .. kernel-doc:: lib/gcd.c
:export:
 
+Sorting
+---
+
+.. kernel-doc:: lib/sort.c
+   :export:
+
+.. kernel-doc:: lib/list_sort.c
+   :export:
+
 Memory Management in Linux
 ==
 
--
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: [PATCH] doc: linux-wpan: Fulfill the description of missed 802.15.4 APIs

[Stefan Schmidt]

Hello


On 11/18/2017 04:55 PM, Jian-Hong Pan wrote:
> There are more functions and operations which must be used or implemented
> in each IEEE 802.15.4 device driver, but are not mentioned in the Device
> drivers API section of Documentation/networking/ieee802154.txt.  Therefore,
> I want to fulfill the missed part into the documentation with this patch.
>
> Signed-off-by: Jian-Hong Pan 
> ---
>  Documentation/networking/ieee802154.txt | 40 
> +
>  1 file changed, 40 insertions(+)
>
> diff --git a/Documentation/networking/ieee802154.txt 
> b/Documentation/networking/ieee802154.txt
> index 057e9fdbfac9..e74d8e1da0e2 100644
> --- a/Documentation/networking/ieee802154.txt
> +++ b/Documentation/networking/ieee802154.txt
> @@ -97,6 +97,46 @@ The include/net/mac802154.h defines following functions:
>   - void ieee802154_unregister_hw(struct ieee802154_hw *hw):
> freeing registered PHY
>  
> + - void ieee802154_rx_irqsafe(struct ieee802154_hw *hw, struct sk_buff *skb,
> +  u8 lqi):
> +   telling 802.15.4 module there is a new received frame in the skb with
> +   the RF Link Quality Indicator (LQI) from the hardware device
> +
> + - void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct sk_buff 
> *skb,
> + bool ifs_handling):
> +   telling 802.15.4 module the frame in the skb is or going to be
> +   transmitted through the hardware device
> +
> +The device driver must implement the following callbacks in the IEEE 802.15.4
> +operations structure at least:
> +struct ieee802154_ops {
> + ...
> + int (*start)(struct ieee802154_hw *hw);
> + void(*stop)(struct ieee802154_hw *hw);
> + ...
> + int (*xmit_async)(struct ieee802154_hw *hw, struct sk_buff *skb);
> + int (*ed)(struct ieee802154_hw *hw, u8 *level);
> + int (*set_channel)(struct ieee802154_hw *hw, u8 page, u8 channel);
> + ...
> +};
> +
> + - int start(struct ieee802154_hw *hw):
> +   handler that 802.15.4 module calls for the hardware device initialization.
> +
> + - void stop(struct ieee802154_hw *hw):
> +   handler that 802.15.4 module calls for the hardware device cleanup.
> +
> + - int xmit_async(struct ieee802154_hw *hw, struct sk_buff *skb):
> +   handler that 802.15.4 module calls for each frame in the skb going to be
> +   transmitted through the hardware device.
> +
> + - int ed(struct ieee802154_hw *hw, u8 *level):
> +   handler that 802.15.4 module calls for Energy Detection from the hardware
> +   device.
> +
> + - int set_channel(struct ieee802154_hw *hw, u8 page, u8 channel):
> +   set radio for listening on specific channel of the hardware device.
> +
>  Moreover IEEE 802.15.4 device operations structure should be filled.
>  
>  Fake drivers

This patch has been applied to the wpan-next tree and will be
part of the next pull request to net-next. Thanks!

regards
Stefan Schmidt
--
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: [PATCH 1/2] watchdog: introduce watchdog.open_timeout commandline parameter

[Guenter Roeck]

On Wed, Nov 29, 2017 at 11:56:57AM +0100, Rasmus Villemoes wrote:
> On 2017-11-28 23:14, Guenter Roeck wrote:
> > On Tue, Nov 28, 2017 at 11:35:49AM +0100, Rasmus Villemoes wrote:
> >>
> >> The unit is milliseconds rather than seconds because that covers more
> >> use cases. For example, one can effectively disable the kernel handling
> >> by setting the open_timeout to 1 ms. There are also customers with very
> >> strict requirements that may want to set the open_timeout to something
> >> like 4500 ms, which combined with a hardware watchdog that must be
> >> pinged every 250 ms ensures userspace is up no more than 5 seconds after
> >> the bootloader hands control to the kernel (250 ms until the driver gets
> >> registered and kernel handling starts, 4500 ms of kernel handling, and
> >> then up to 250 ms from the last ping until userspace takes over).
> > 
> > This is quite vague, especially since it doesn't count the time from
> > boot to starting the watchdog driver,
> 
> My example is bad, and I now realize one cannot really get such precise
> guarantees. But the example _did_ actually account for the time from
> boot to device registration - it allowed 250 ms for the kernel to get
> that far.
> 
> which can vary even across boots.
> > Why not make it specific, for example by adjusting the open timeout with
> > ktime_get_boot_ns() ?
> 
> If by "boot" we mean the moment the bootloader hands control to the
> kernel, ktime_get_boot_ns() doesn't give that either - at best, it gives
> an approximation of the time since timekeeping_init(), but it's not very
> accurate that early (I simply injected printks of ktime_get_boot_ns at
> various places in init/main.c and timestamped the output lines). If it
> overshoots, we'd be subtracting more of the allowance than we should,
> and I don't think we have any way of knowing when that happens or to
> correct for it. So I'd rather keep the code simple and let it count from
> the time the watchdog framework knows about the device, which is also
> around the time when the kernel's timekeeping is reasonably accurate.
> 
We should try to make things as accurate as possible. "It won't be perfect"
is not an argument against that.

> > I would actually make it even more specific and calculate the open
> > timeout such that the system would reboot after open_timeout, not
> > after . Any reason for not doing that ?
> > The upside would be more accuracy, and I don't really see a downside.
> 
> I don't think it would be that much more accurate - we schedule the
> pings at a frequency of half the max_hw_heartbeat_ms==$x, with the
> current code we'd get rebooted somewhere between [open_deadline + $x/2,
> open_deadline + $x], and subtracting $x from the open_timeout that would
> become [open_deadline - $x/2, open_deadline]. I'd rather not have the
> reboot happen before the open_deadline. Sure, we could subtract $x/2
> instead. Then there's the case where ->max_hw_heartbeat_ms is not set,
> so we have to use ->timeout for $x, and then there's the case of $x (or
> $x/2) being greater than $open_timeout. I'd really like to keep the code
> simple. If it helps, I'd be happy to document the exact semantics of the
> open_timeout with a nice ascii art timeline.
> 
It was not much of a problem to get that right after a watchdog was opened,
by timing pings accordingly such that the HW times out when it should.
It should not be that hard to get it working for the pre-open case as well.

Guenter
--
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: [PATCH] dmaengine: doc : Fix warning "Title underline too short" while make xmldocs

[Vinod Koul]

On Wed, Nov 29, 2017 at 12:16:56AM +0900, Masanari Iida wrote:
> This patch fix following warning during 'make xmldocs'

The patch title should not document why but should document what the patch
does. Checkpatch warns about that.

Perhpas this would make a better title: "fix short topic underline"

> Documentation/driver-api/dmaengine/client.rst:188:
> WARNING: Title underline too short.
> 
> Further APIs:
> 
> 
> Signed-off-by: Masanari Iida 
> ---
>  Documentation/driver-api/dmaengine/client.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/driver-api/dmaengine/client.rst 
> b/Documentation/driver-api/dmaengine/client.rst
> index 6245c99af8c1..fbbb2831f29f 100644
> --- a/Documentation/driver-api/dmaengine/client.rst
> +++ b/Documentation/driver-api/dmaengine/client.rst
> @@ -185,7 +185,7 @@ The details of these operations are:
>void dma_async_issue_pending(struct dma_chan *chan);
>  
>  Further APIs:
> -
> +-
>  
>  1. Terminate APIs
>  
> -- 
> 2.15.0.374.g5f9953d2c365
> 

-- 
~Vinod
--
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: [PATCH 1/2] watchdog: introduce watchdog.open_timeout commandline parameter

[Rasmus Villemoes]

On 2017-11-28 23:14, Guenter Roeck wrote:
> On Tue, Nov 28, 2017 at 11:35:49AM +0100, Rasmus Villemoes wrote:
>>
>> The unit is milliseconds rather than seconds because that covers more
>> use cases. For example, one can effectively disable the kernel handling
>> by setting the open_timeout to 1 ms. There are also customers with very
>> strict requirements that may want to set the open_timeout to something
>> like 4500 ms, which combined with a hardware watchdog that must be
>> pinged every 250 ms ensures userspace is up no more than 5 seconds after
>> the bootloader hands control to the kernel (250 ms until the driver gets
>> registered and kernel handling starts, 4500 ms of kernel handling, and
>> then up to 250 ms from the last ping until userspace takes over).
> 
> This is quite vague, especially since it doesn't count the time from
> boot to starting the watchdog driver,

My example is bad, and I now realize one cannot really get such precise
guarantees. But the example _did_ actually account for the time from
boot to device registration - it allowed 250 ms for the kernel to get
that far.

which can vary even across boots.
> Why not make it specific, for example by adjusting the open timeout with
> ktime_get_boot_ns() ?

If by "boot" we mean the moment the bootloader hands control to the
kernel, ktime_get_boot_ns() doesn't give that either - at best, it gives
an approximation of the time since timekeeping_init(), but it's not very
accurate that early (I simply injected printks of ktime_get_boot_ns at
various places in init/main.c and timestamped the output lines). If it
overshoots, we'd be subtracting more of the allowance than we should,
and I don't think we have any way of knowing when that happens or to
correct for it. So I'd rather keep the code simple and let it count from
the time the watchdog framework knows about the device, which is also
around the time when the kernel's timekeeping is reasonably accurate.

> I would actually make it even more specific and calculate the open
> timeout such that the system would reboot after open_timeout, not
> after . Any reason for not doing that ?
> The upside would be more accuracy, and I don't really see a downside.

I don't think it would be that much more accurate - we schedule the
pings at a frequency of half the max_hw_heartbeat_ms==$x, with the
current code we'd get rebooted somewhere between [open_deadline + $x/2,
open_deadline + $x], and subtracting $x from the open_timeout that would
become [open_deadline - $x/2, open_deadline]. I'd rather not have the
reboot happen before the open_deadline. Sure, we could subtract $x/2
instead. Then there's the case where ->max_hw_heartbeat_ms is not set,
so we have to use ->timeout for $x, and then there's the case of $x (or
$x/2) being greater than $open_timeout. I'd really like to keep the code
simple. If it helps, I'd be happy to document the exact semantics of the
open_timeout with a nice ascii art timeline.

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