Re: [PATCH v3 2/4] Documentation/atomic_ops.txt: convert to ReST markup

2016-11-27 Thread Peter Zijlstra 
On Sun, Nov 27, 2016 at 04:59:14PM -0700, Jonathan Corbet wrote:
> On Fri, 25 Nov 2016 22:58:14 +0100
> Peter Zijlstra  wrote:
> 
> > Not a fan of this. The atomic_ops.txt file needs a lot of love, and I
> > wouldn't want to edit a .rst file.
> > 
> > Then again, I probably won't actually get around to fixing this document
> > any time soon either.
> > 
> > But if and when I would get around to it, I'll have to change it back to
> > a regular .txt file.
> 
> Peter, could you please describe what the trouble with RST is? 

Mostly that its not txt. I don't know what RST is, and I frankly don't
care. For me changing this is 'make work', and I really don't need that.

Changing this away from txt will simply make want to write documentation
less, because it means having to figure out wtf RST is first, which
means I'll simply won't do it.

> Most of
> the files in Documentation/ are already almost in RST format; should we
> change them to something else? :)

Why change them? What was wrong with txt to begin with?
--
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: BALANCE PAYMENT

2016-11-27 Thread coral 

Dear Sir/s,

Please see attached.


Thanks and regards,

Accounts Department
Al Omraniya Trading Co. LLC
P.O. Box: 10757, Al Khabaisi Area,
Deira 2, Dubai, U.A.E.
Tel: +971 4 268 2730 / Fax: +971 4 268 4117

--
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 3/3] hwmon: tmp108: Update driver to use hwmon_chip_info.

2016-11-27 Thread Guenter Roeck 

On 11/27/2016 06:10 PM, John Muir wrote:

On 2016.11.27, at 15:00 , Guenter Roeck  wrote:

On Sat, Nov 26, 2016 at 09:15:37PM -0800, John Muir wrote:

Move the tmp108 driver from hwmon attribute groups to
hwmon_chip_info.

Signed-off-by: John Muir 
---


Hi John,

please have a look at the following patch.

Something else: Symbolic permissions are out of favor nowadays.
You might instead just use 0644 / 0444. Not that I really care,
but it prevents the inevitable follow-up patches.



Hi Guenter,

Thank you for this patch. I will attempt to implement the same changes using 
the older interfaces in my 4.4 implementation. I will incorporate your changes 
and other comments as soon as I can (early this week) and re-send my patch 
series.


Hi John,

My pleasure.

I also wrote a module test for the driver (with my patch applied):

https://github.com/groeck/module-tests/blob/master/scripts/tmp108.sh

Just in case you want to give it a try.

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 3/3] hwmon: tmp108: Update driver to use hwmon_chip_info.

2016-11-27 Thread John Muir 
> On 2016.11.27, at 15:00 , Guenter Roeck  wrote:
> 
> On Sat, Nov 26, 2016 at 09:15:37PM -0800, John Muir wrote:
>> Move the tmp108 driver from hwmon attribute groups to
>> hwmon_chip_info.
>> 
>> Signed-off-by: John Muir 
>> ---
> 
> Hi John,
> 
> please have a look at the following patch.
> 
> Something else: Symbolic permissions are out of favor nowadays.
> You might instead just use 0644 / 0444. Not that I really care,
> but it prevents the inevitable follow-up patches.
> 

Hi Guenter,

Thank you for this patch. I will attempt to implement the same changes using 
the older interfaces in my 4.4 implementation. I will incorporate your changes 
and other comments as soon as I can (early this week) and re-send my patch 
series.

Cheers,

John.

--
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 v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board

2016-11-27 Thread André Przywara 
On 27/11/16 09:36, Icenowy Zheng wrote:

Hi,

> 22.11.2016, 00:26, "Icenowy Zheng" :
>> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC.
>>
>> Add a device tree file for it.
>>
>> Signed-off-by: Icenowy Zheng 
>> ---
>> Changes since v2:
>> - Use generic pinconf binding instead of legacy allwinner pinctrl binding.
>> - removed uart3, which is not accessible on Orange Pi Zero.
>> - Removed sun8i-h2plus.dtsi and make Orange Pi Zero dts directly include
>>   sun8i-h3.dtsi.
>> - Removed allwinner,sun8i-h3 compatible.
>>
>>  arch/arm/boot/dts/Makefile | 1 +
>>  arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 137 
>> +++
>>  2 files changed, 138 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 802a10d..51a1dd7 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -834,6 +834,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>>  sun8i-a33-sinlinx-sina33.dtb \
>>  sun8i-a83t-allwinner-h8homlet-v2.dtb \
>>  sun8i-a83t-cubietruck-plus.dtb \
>> + sun8i-h2plus-orangepi-zero.dtb \
>>  sun8i-h3-bananapi-m2-plus.dtb \
>>  sun8i-h3-nanopi-neo.dtb \
>>  sun8i-h3-orangepi-2.dtb \
>> diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts 
>> b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>> new file mode 100644
>> index 000..b428e47
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>> @@ -0,0 +1,137 @@
>> +/*
>> + * Copyright (C) 2016 Icenowy Zheng 
>> + *
>> + * Based on sun8i-h3-orangepi-one.dts, which is:
>> + * Copyright (C) 2016 Hans de Goede 
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + * a) This file 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.
>> + *
>> + * This file is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + * b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +#include "sun8i-h3.dtsi"
>> +#include "sunxi-common-regulators.dtsi"
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/ {
>> + model = "Xunlong Orange Pi Zero";
>> + compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2plus";
>> +
>> + aliases {
>> + serial0 = &uart0;
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> + };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&leds_opi0>, <&leds_r_opi0>;
>> +
>> + pwr_led {
>> + label = "orangepi:green:pwr";
>> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
>> + default-state = "on";
>> + };
>> +
>> + status_led {
>> + label = "orangepi:red:status";
>> + gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
>> + };
>> + };
>> +};
>> +
>> +&ehci1 {
>> + status = "okay";
>> +};
>> +
>> +&mmc0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
>> + vmmc-supply = <®_vcc3v3>;
>> + bus-width = <4>;
>> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
>> + cd-inverted;
>> + status = "okay";
>> +};
>> +
>> +&ohci1 {
>> + status = "okay";
>> +};
>> +
>> +&pio {
>> + leds_opi0: led_pins@0 {
>> + pins = "PA17";
>> + function = "gpio_out";
>> + };
>> +};
>> +
>> +&r_pio {
>> + leds_r_opi0: led_pins@0 {
>> + pins = "PL10";

Re: [PATCH v3 2/4] Documentation/atomic_ops.txt: convert to ReST markup

2016-11-27 Thread Jonathan Corbet 
On Fri, 25 Nov 2016 22:58:14 +0100
Peter Zijlstra  wrote:

> Not a fan of this. The atomic_ops.txt file needs a lot of love, and I
> wouldn't want to edit a .rst file.
> 
> Then again, I probably won't actually get around to fixing this document
> any time soon either.
> 
> But if and when I would get around to it, I'll have to change it back to
> a regular .txt file.

Peter, could you please describe what the trouble with RST is?  Most of
the files in Documentation/ are already almost in RST format; should we
change them to something else? :)

Silvio, one thing that might help would be to redo the patch with a
minimum of changes and, in particular, a minimum of unnecessary markup.
Yes, it's better to put literal strings in monospace, but we don't have
to, and getting rid of a lot of ``funny quotes`` makes the changes a lot
less intrusive.

jon
--
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 3/3] hwmon: tmp108: Update driver to use hwmon_chip_info.

2016-11-27 Thread Guenter Roeck 
On Sat, Nov 26, 2016 at 09:15:37PM -0800, John Muir wrote:
> Move the tmp108 driver from hwmon attribute groups to
> hwmon_chip_info.
> 
> Signed-off-by: John Muir 
> ---

Hi John,

please have a look at the following patch.

Something else: Symbolic permissions are out of favor nowadays.
You might instead just use 0644 / 0444. Not that I really care,
but it prevents the inevitable follow-up patches.

Thanks,
Guenter

---
From: Guenter Roeck 
Date: Sun, 27 Nov 2016 14:54:19 -0800
Subject: [PATCH] hwmon: (tmp108) Add support for various attributes

Add support for temp1_{min,max}_hyst, temp1_{min,max}_alarm,
and update_interval.

Signed-off-by: Guenter Roeck 
---
 drivers/hwmon/tmp108.c | 144 ++---
 1 file changed, 124 insertions(+), 20 deletions(-)

diff --git a/drivers/hwmon/tmp108.c b/drivers/hwmon/tmp108.c
index 29ddc2e124c6..4cc2adee069a 100644
--- a/drivers/hwmon/tmp108.c
+++ b/drivers/hwmon/tmp108.c
@@ -103,7 +103,33 @@ static int tmp108_read(struct device *dev, enum 
hwmon_sensor_types type,
 {
struct tmp108 *tmp108 = dev_get_drvdata(dev);
unsigned int regval;
-   int err, reg;
+   int err, hyst;
+
+   if (type == hwmon_chip) {
+   if (attr == hwmon_chip_update_interval) {
+   err = regmap_read(tmp108->regmap, TMP108_REG_CONF,
+ ®val);
+   if (err < 0)
+   return err;
+   switch (regval & TMP108_CONF_CONVRATE_MASK) {
+   case TMP108_CONVRATE_0P25HZ:
+   default:
+   *temp = 4000;
+   break;
+   case TMP108_CONVRATE_1HZ:
+   *temp = 1000;
+   break;
+   case TMP108_CONVRATE_4HZ:
+   *temp = 250;
+   break;
+   case TMP108_CONVRATE_16HZ:
+   *temp = 63;
+   break;
+   }
+   return 0;
+   }
+   return -EOPNOTSUPP;
+   }
 
switch (attr) {
case hwmon_temp_input:
@@ -113,23 +139,57 @@ static int tmp108_read(struct device *dev, enum 
hwmon_sensor_types type,
__func__);
return -EAGAIN;
}
-   reg = TMP108_REG_TEMP;
+   err = regmap_read(tmp108->regmap, TMP108_REG_TEMP, ®val);
+   if (err < 0)
+   return err;
+   *temp = tmp108_temp_reg_to_mC(regval);
break;
case hwmon_temp_min:
-   reg = TMP108_REG_TLOW;
-   break;
case hwmon_temp_max:
-   reg = TMP108_REG_THIGH;
+   err = regmap_read(tmp108->regmap, attr == hwmon_temp_min ?
+ TMP108_REG_TLOW : TMP108_REG_THIGH, ®val);
+   if (err < 0)
+   return err;
+   *temp = tmp108_temp_reg_to_mC(regval);
+   break;
+   case hwmon_temp_min_alarm:
+   case hwmon_temp_max_alarm:
+   err = regmap_read(tmp108->regmap, TMP108_REG_CONF, ®val);
+   if (err < 0)
+   return err;
+   *temp = !!(regval & (attr == hwmon_temp_min_alarm ?
+TMP108_CONF_FL : TMP108_CONF_FH));
+   break;
+   case hwmon_temp_min_hyst:
+   case hwmon_temp_max_hyst:
+   err = regmap_read(tmp108->regmap, TMP108_REG_CONF, ®val);
+   if (err < 0)
+   return err;
+   switch (regval & TMP108_CONF_HYSTERESIS_MASK) {
+   case TMP108_HYSTERESIS_0C:
+   default:
+   hyst = 0;
+   break;
+   case TMP108_HYSTERESIS_1C:
+   hyst = 1000;
+   break;
+   case TMP108_HYSTERESIS_2C:
+   hyst = 2000;
+   break;
+   case TMP108_HYSTERESIS_4C:
+   hyst = 4000;
+   break;
+   }
+   err = regmap_read(tmp108->regmap, attr == hwmon_temp_min_hyst ?
+ TMP108_REG_TLOW : TMP108_REG_THIGH, ®val);
+   if (err < 0)
+   return err;
+   *temp = tmp108_temp_reg_to_mC(regval) - hyst;
break;
default:
return -EOPNOTSUPP;
}
 
-   err = regmap_read(tmp108->regmap, reg, ®val);
-   if (err < 0)
-   return err;
-   *temp = tmp108_temp_reg_to_mC(regval);
-
return 0;
 }
 
@@ -137,33 +197,76 @@ static int tmp108_write(struct device *dev, enum 
hwmon_sensor_types type,

Re: [PATCH v3 2/4] Documentation/atomic_ops.txt: convert to ReST markup

2016-11-27 Thread Jani Nikula 
On Sun, 27 Nov 2016, "S. Fricke"  wrote:
> Hi Peter,
>
>> On Fri, Nov 25, 2016 at 03:59:45PM +0100, Silvio Fricke wrote:
>> > ... and move to core-api folder.
>> > 
>> > Signed-off-by: Silvio Fricke 
>> > ---
>> >  Documentation/atomic_ops.txt => Documentation/core-api/atomic_ops.rst | 
>> > 777 
>> > +---
>> >  Documentation/core-api/index.rst  |   
>> > 1 +-
>> >  Documentation/process/volatile-considered-harmful.rst |   
>> > 3 +-
>> >  3 files changed, 404 insertions(+), 377 deletions(-)
>> 
>> Not a fan of this. The atomic_ops.txt file needs a lot of love, and I
>> wouldn't want to edit a .rst file.
>
> What is the problem with this rst-file? atomic_ops.rst are not so
> different to the txt variant.

There is nothing particularly wrong with the patch. Perhaps you could
leave the tabs in place instead of indenting with spaces in the code
blocks. It would result in a smaller diff. But other than that, it's
fine.

I'm sure Peter is capable of editing a file with a .rst extension, and
we can clean up any hickups afterwards if getting the formatting right
is insurmountable.

> I will drop this patch.

Please don't. Please let Jon be the judge of that.

Thanks,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
--
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

[RFC PATCH v2] docs-rst: automatically convert Graphviz and SVG images

2016-11-27 Thread Markus Heiser 
Replacement for the sphinx ``figure`` and ``images`` directive.

A image (or figure) directive which make use of the *glob* notation::

  .. figure::  hello.*

will be converted automatically with the tool chains listed below.:

* DOT to SVG: ``DOT(1)`` (http://www.graphviz.org) If graphviz is not
  available, the DOT language is inserted as literal-include.

* SVG to PDF:

  * CairoSVG (http://cairosvg.org) if installed or alternatively
  * ``convert(1)``: ImageMagick (https://www.imagemagick.org)

Signed-off-by: Markus Heiser 
---
 Documentation/conf.py  |   2 +-
 Documentation/doc-guide/hello.dot  |   3 +
 Documentation/doc-guide/sphinx.rst |  18 ++
 Documentation/sphinx/figure.py | 123 +
 4 files changed, 145 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/doc-guide/hello.dot
 create mode 100644 Documentation/sphinx/figure.py

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 1ac958c..386d792 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -34,7 +34,7 @@ from load_config import loadConfig
 # Add any Sphinx extension module names here, as strings. They can be
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
 # ones.
-extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain']
+extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 
'figure']
 
 # The name of the math extension changed on Sphinx 1.4
 if major == 1 and minor > 3:
diff --git a/Documentation/doc-guide/hello.dot 
b/Documentation/doc-guide/hello.dot
new file mode 100644
index 000..504621d
--- /dev/null
+++ b/Documentation/doc-guide/hello.dot
@@ -0,0 +1,3 @@
+graph G {
+  Hello -- World
+}
diff --git a/Documentation/doc-guide/sphinx.rst 
b/Documentation/doc-guide/sphinx.rst
index 96fe7ccb..6f8fdd1 100644
--- a/Documentation/doc-guide/sphinx.rst
+++ b/Documentation/doc-guide/sphinx.rst
@@ -217,3 +217,21 @@ Rendered as:
   * .. _`last row`:
 
 - column 3
+
+Figures
+===
+
+If you want to add an image on either Graphviz or SVG format, you should
+use Sphinx ``figure``, where the name of the image file should end with
+``.*``, like::
+
+  .. figure::  hello.*
+ :alt:hello world
+
+ DOT's hello world example
+
+
+.. figure::  hello.*
+   :alt:hello world
+
+   DOT's hello world example
diff --git a/Documentation/sphinx/figure.py b/Documentation/sphinx/figure.py
new file mode 100644
index 000..50d63bd
--- /dev/null
+++ b/Documentation/sphinx/figure.py
@@ -0,0 +1,123 @@
+# -*- coding: utf-8; mode: python -*-
+# pylint: disable=W0141,C0113,C0103,C0325
+u"""
+images
+~~
+
+Replacement for the sphinx ``figure`` and ``images`` directive.
+
+:copyright:  Copyright (C) 2016  Markus Heiser
+:license:GPL Version 2, June 1991 see Linux/COPYING for details.
+
+List of customizations:
+
+* generate PDF from SVG
+
+* generate SVG / PDF from DOT files, see
+  http://www.graphviz.org/content/dot-language
+
+A image (or figure) directive which make use of the *glob* notation will be
+converted automatically with the tool chains listed below.:
+
+* DOT to SVG: ``DOT(1)`` (http://www.graphviz.org) If graphviz is not
+  available, the DOT language is inserted as literal-include.
+
+* SVG to PDF:
+
+  * CairoSVG (http://cairosvg.org) if installed or alternatively
+  * ``convert(1)``: ImageMagick (https://www.imagemagick.org)
+"""
+
+import os
+from glob import glob
+import subprocess
+
+from docutils import nodes
+from docutils.parsers.rst import directives
+from docutils.parsers.rst.directives import images
+
+from sphinx.directives import patches
+
+try:
+import cairosvg
+except ImportError:
+cairosvg = None
+
+def cmd_exists(cmd):
+exit_code = subprocess.call(
+"type " + cmd, shell = True,
+stdout = subprocess.PIPE, stderr = subprocess.PIPE )
+return bool(exit_code == 0)
+
+convert_exists = cmd_exists('convert')
+dot_exists = cmd_exists('dot')
+
+def setup(app):  # pylint: disable=W0613
+directives.register_directive('figure', Figure)
+directives.register_directive('image', Image)
+
+def asterix_conversions(folder, node):
+if not node['uri'].endswith('.*'):
+return node
+name = folder + os.path.sep + os.path.splitext(node['uri'])[0]
+
+fnames = glob(name + '.*')
+if (name + '.dot' in fnames):
+if not dot_exists:
+with open(name + '.dot', "r") as dot:
+data = dot.read()
+node = nodes.literal_block(data, data)
+else:
+dot2svg(name)
+
+fnames = glob(name + '.*')
+if (name + '.svg' in fnames):
+svg2pdf(name)
+return node
+
+
+def dot2svg(fname):
+cmd = "dot -Tsvg %s.dot" % fname
+with open(fname + '.svg', "w") as svg:
+exit_code = subprocess.call(
+cmd, shell = True,
+stdout = svg,
+stderr = subproce

[RFC PATCH v2] doc-rst: convert SVG and graphiz (.dot) files

2016-11-27 Thread Markus Heiser 
Inspired by the RFC discussion [1] I wrote a small replacement
for the graphviz (.dot) and SVG handling.

This is just a POC, I know that it has still some weaknesses, e.g. it spits the
conversions (svg & pdf files) in the source tree. I'am just interested in your
thought and comments / thanks.

-- Markus --

[1] https://www.mail-archive.com/linux-doc@vger.kernel.org/msg07870.html

---
v2: fixed (bisect) bug / sorry
---

Markus Heiser (1):
  doc-rst: automatically convert Graphviz and SVG images

 Documentation/conf.py  |   2 +-
 Documentation/doc-guide/hello.dot  |   3 +
 Documentation/doc-guide/sphinx.rst |  18 ++
 Documentation/sphinx/figure.py | 123 +
 4 files changed, 145 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/doc-guide/hello.dot
 create mode 100644 Documentation/sphinx/figure.py

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

[RFC PATCH] doc-rst: convert SVG and graphiz (.dot) files

2016-11-27 Thread Markus Heiser 
Inspired by the RFC discussion [1] I wrote a small replacement
for the graphviz (.dot) and SVG handling.

This is just a POC, I know that it has still some weaknesses, e.g. it spits the
conversions (svg & pdf files) in the source tree. I'am just interested in your
thought and comments / thanks.

-- Markus --

[1] https://www.mail-archive.com/linux-doc@vger.kernel.org/msg07870.html

Markus Heiser (1):
  docs-rst: automatically convert Graphviz and SVG images

 Documentation/conf.py  |   2 +-
 Documentation/doc-guide/hello.dot  |   3 +
 Documentation/doc-guide/sphinx.rst |  18 ++
 Documentation/sphinx/figure.py | 123 +
 4 files changed, 145 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/doc-guide/hello.dot
 create mode 100644 Documentation/sphinx/figure.py

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

[RFC PATCH] doc-rst: automatically convert Graphviz and SVG images

2016-11-27 Thread Markus Heiser 
Replacement for the sphinx ``figure`` and ``images`` directive.

A image (or figure) directive which make use of the *glob* notation::

  .. figure::  hello.*

will be converted automatically with the tool chains listed below.:

* DOT to SVG: ``DOT(1)`` (http://www.graphviz.org) If graphviz is not
  available, the DOT language is inserted as literal-include.

* SVG to PDF:

  * CairoSVG (http://cairosvg.org) if installed or alternatively
  * ``convert(1)``: ImageMagick (https://www.imagemagick.org)

Signed-off-by: Markus Heiser 
---
 Documentation/conf.py  |   2 +-
 Documentation/doc-guide/hello.dot  |   3 +
 Documentation/doc-guide/sphinx.rst |  18 ++
 Documentation/sphinx/figure.py | 123 +
 4 files changed, 145 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/doc-guide/hello.dot
 create mode 100644 Documentation/sphinx/figure.py

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 1ac958c..386d792 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -34,7 +34,7 @@ from load_config import loadConfig
 # Add any Sphinx extension module names here, as strings. They can be
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
 # ones.
-extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain']
+extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 
'figure']
 
 # The name of the math extension changed on Sphinx 1.4
 if major == 1 and minor > 3:
diff --git a/Documentation/doc-guide/hello.dot 
b/Documentation/doc-guide/hello.dot
new file mode 100644
index 000..504621d
--- /dev/null
+++ b/Documentation/doc-guide/hello.dot
@@ -0,0 +1,3 @@
+graph G {
+  Hello -- World
+}
diff --git a/Documentation/doc-guide/sphinx.rst 
b/Documentation/doc-guide/sphinx.rst
index 96fe7ccb..6f8fdd1 100644
--- a/Documentation/doc-guide/sphinx.rst
+++ b/Documentation/doc-guide/sphinx.rst
@@ -217,3 +217,21 @@ Rendered as:
   * .. _`last row`:
 
 - column 3
+
+Figures
+===
+
+If you want to add an image on either Graphviz or SVG format, you should
+use Sphinx ``figure``, where the name of the image file should end with
+``.*``, like::
+
+  .. figure::  hello.*
+ :alt:hello world
+
+ DOT's hello world example
+
+
+.. figure::  hello.*
+   :alt:hello world
+
+   DOT's hello world example
diff --git a/Documentation/sphinx/figure.py b/Documentation/sphinx/figure.py
new file mode 100644
index 000..1aeeefa
--- /dev/null
+++ b/Documentation/sphinx/figure.py
@@ -0,0 +1,123 @@
+# -*- coding: utf-8; mode: python -*-
+# pylint: disable=W0141,C0113,C0103,C0325
+u"""
+images
+~~
+
+Replacement for the sphinx ``figure`` and ``images`` directive.
+
+:copyright:  Copyright (C) 2016  Markus Heiser
+:license:GPL Version 2, June 1991 see Linux/COPYING for details.
+
+List of customizations:
+
+* generate PDF from SVG
+
+* generate SVG / PDF from DOT files, see
+  http://www.graphviz.org/content/dot-language
+
+A image (or figure) directive which make use of the *glob* notation will be
+converted automatically with the tool chains listed below.:
+
+* DOT to SVG: ``DOT(1)`` (http://www.graphviz.org) If graphviz is not
+  available, the DOT language is inserted as literal-include.
+
+* SVG to PDF:
+
+  * CairoSVG (http://cairosvg.org) if installed or alternatively
+  * ``convert(1)``: ImageMagick (https://www.imagemagick.org)
+"""
+
+import os
+from glob import glob
+import subprocess
+
+from docutils import nodes
+from docutils.parsers.rst import directives
+from docutils.parsers.rst.directives import images
+
+from sphinx.directives import patches
+
+try:
+import cairosvg
+except ImportError:
+cairosvg = None
+
+def cmd_exists(cmd):
+exit_code = subprocess.call(
+"type " + cmd, shell = True,
+stdout = subprocess.PIPE, stderr = subprocess.PIPE )
+return bool(exit_code == 0)
+
+convert_exists = cmd_exists('convert')
+dot_exists = cmd_exists('dot')
+
+def setup(app):  # pylint: disable=W0613
+directives.register_directive('figure', Figure)
+directives.register_directive('image', Image)
+
+def asterix_conversions(folder, node):
+if not node['uri'].endswith('.*'):
+return True
+name = folder + os.path.sep + os.path.splitext(node['uri'])[0]
+
+fnames = glob(name + '.*')
+if (name + '.dot' in fnames):
+if not dot_exists:
+with open(name + '.dot', "r") as dot:
+data = dot.read()
+node = nodes.literal_block(data, data)
+else:
+dot2svg(name)
+
+fnames = glob(name + '.*')
+if (name + '.svg' in fnames):
+svg2pdf(name)
+return node
+
+
+def dot2svg(fname):
+cmd = "dot -Tsvg %s.dot" % fname
+with open(fname + '.svg', "w") as svg:
+exit_code = subprocess.call(
+cmd, shell = True,
+stdout = svg,
+stderr = subproce

Re: [PATCH v3 2/4] Documentation/atomic_ops.txt: convert to ReST markup

2016-11-27 Thread S. Fricke 
Hi Peter,

> On Fri, Nov 25, 2016 at 03:59:45PM +0100, Silvio Fricke wrote:
> > ... and move to core-api folder.
> > 
> > Signed-off-by: Silvio Fricke 
> > ---
> >  Documentation/atomic_ops.txt => Documentation/core-api/atomic_ops.rst | 
> > 777 +---
> >  Documentation/core-api/index.rst  |   
> > 1 +-
> >  Documentation/process/volatile-considered-harmful.rst |   
> > 3 +-
> >  3 files changed, 404 insertions(+), 377 deletions(-)
> 
> Not a fan of this. The atomic_ops.txt file needs a lot of love, and I
> wouldn't want to edit a .rst file.

What is the problem with this rst-file? atomic_ops.rst are not so different to
the txt variant.


I will drop this patch.

Best regards,
Silvio


-- 
-- S. Fricke  sil...@port1024.net --
   Diplom-Informatiker (FH)
   Linux-Development Matrix: @silvio:port1024.net   

--
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 2/3] hwmon: tmp108: Use devm variants of registration interfaces.

2016-11-27 Thread Guenter Roeck 

On 11/26/2016 09:15 PM, John Muir wrote:

From: John Muir 

Use the devm hwmon and thermal zone registration functions to
clean up the code and remove the need for an i2c_driver.remove
callback.

Signed-off-by: John Muir 
---
 drivers/hwmon/tmp108.c | 28 
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/drivers/hwmon/tmp108.c b/drivers/hwmon/tmp108.c
index da64517..b13d652 100644
--- a/drivers/hwmon/tmp108.c
+++ b/drivers/hwmon/tmp108.c
@@ -83,8 +83,6 @@

 struct tmp108 {
struct regmap *regmap;
-   struct device *hwmon_dev;
-   struct thermal_zone_device *tz;
u16 config;
unsigned long ready_time;
 };
@@ -245,6 +243,7 @@ static int tmp108_probe(struct i2c_client *client,
 {
struct device *dev = &client->dev;
struct device *hwmon_dev;
+   struct thermal_zone_device *tz;
struct tmp108 *tmp108;
unsigned int regval;
int err;
@@ -353,18 +352,18 @@ static int tmp108_probe(struct i2c_client *client,
if (err)
return err;

-   hwmon_dev = hwmon_device_register_with_groups(dev, client->name,
- tmp108, tmp108_groups);
+   hwmon_dev = devm_hwmon_device_register_with_groups(dev, client->name,
+  tmp108,
+  tmp108_groups);
if (IS_ERR(hwmon_dev)) {
dev_dbg(dev, "unable to register hwmon device\n");
return PTR_ERR(hwmon_dev);
}

-   tmp108->hwmon_dev = hwmon_dev;
-   tmp108->tz = thermal_zone_of_sensor_register(hwmon_dev, 0, hwmon_dev,
-&tmp108_of_thermal_ops);
-   if (IS_ERR(tmp108->tz))
-   return PTR_ERR(tmp108->tz);
+   tz = devm_thermal_zone_of_sensor_register(hwmon_dev, 0, hwmon_dev,
+ &tmp108_of_thermal_ops);
+   if (IS_ERR(tz))
+   return PTR_ERR(tz);

dev_info(dev, "%s, alert: active %s, hyst: %uC, conv: %ucHz\n",
 (tmp108->config & TMP108_CONF_TM) != 0 ?
@@ -374,16 +373,6 @@ static int tmp108_probe(struct i2c_client *client,
return 0;
 }

-static int tmp108_remove(struct i2c_client *client)
-{
-   struct tmp108 *tmp108 = i2c_get_clientdata(client);
-

With this, i2c_set_clientdata() in the probe function is no longer needed.


-   thermal_zone_of_sensor_unregister(tmp108->hwmon_dev, tmp108->tz);
-   hwmon_device_unregister(tmp108->hwmon_dev);
-
-   return 0;
-}
-
 #ifdef CONFIG_PM_SLEEP
 static int tmp108_suspend(struct device *dev)
 {
@@ -418,7 +407,6 @@ static struct i2c_driver tmp108_driver = {
.driver.name= DRIVER_NAME,
.driver.pm  = &tmp108_dev_pm_ops,
.probe  = tmp108_probe,
-   .remove = tmp108_remove,
.id_table   = tmp108_id,
 };




--
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/3] hwmon: Add Texas Instruments TMP108 temperature sensor driver.

2016-11-27 Thread Guenter Roeck 

On 11/26/2016 09:15 PM, John Muir wrote:

Add support for the TI TMP108 temperature sensor with some device
configuration parameters.

Signed-off-by: John Muir 
---
 Documentation/devicetree/bindings/hwmon/tmp108.txt |  27 ++
 Documentation/hwmon/tmp108 |  38 ++
 drivers/hwmon/Kconfig  |  11 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/tmp108.c | 429 +
 5 files changed, 506 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/tmp108.txt
 create mode 100644 Documentation/hwmon/tmp108
 create mode 100644 drivers/hwmon/tmp108.c

diff --git a/Documentation/devicetree/bindings/hwmon/tmp108.txt 
b/Documentation/devicetree/bindings/hwmon/tmp108.txt


This should be provided in a separate patch.


new file mode 100644
index 000..210af63
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/tmp108.txt
@@ -0,0 +1,27 @@
+TMP108 temperature sensor
+-
+
+This device supports I2C only.
+
+Requires node properties:
+- compatible : "ti,tmp108"
+- reg : the I2C address of the device. This is 0x48, 0x49, 0x4a, or 0x4b.
+
+Optional node properties:
+- ti,thermostat-mode-comparitor : (boolean) select the comparitor mode for the


s/comparitor/comparator/g


+  thermostat rather than the default interrupt-mode.
+- ti,alert-active-high : (boolean) make the alert pin active-high instead of
+  the default active-low.


The driver doesn't support interrupts/alerts. Do those properties really add 
value ?


+- ti,conversion-rate-cHz : (integer, cHz) select the conversion frequency for
+  continuous mode, in centi-Hz: 25, 100 (default), 400, or 1600.
+- ti,hysteresis : (integer, C) select the hysteresis value: 0, 1, 2, or 4
+  (celcius).
+

We would nor mally make the conversion rate and hysteresis user configurable,
with the update_interval and temp1_{min,max}_hyst attributes. Those are not 
really
system configuration properties.


+Example:
+   tmp108@48 {
+   compatible = "ti,tmp108";
+   reg = <0x48>;
+   ti,alert-active-high;
+   ti,hysteresis = <2>;
+   ti,conversion-rate-cHz = <25>;
+   };
diff --git a/Documentation/hwmon/tmp108 b/Documentation/hwmon/tmp108
new file mode 100644
index 000..ef2e9a3
--- /dev/null
+++ b/Documentation/hwmon/tmp108
@@ -0,0 +1,38 @@
+Kernel driver tmp108
+
+
+Supported chips:
+  * Texas Instruments TMP108
+Prefix: 'tmp108'
+Addresses scanned: none
+Datasheet: http://www.ti.com/product/tmp108
+
+Author:
+   John Muir 
+
+Description
+---
+
+The Texas Instruments TMP108 implements one temperature sensor. An alert pin
+can be set when temperatures exceed minimum or maximum values plus or minus a
+hysteresis value.
+
+The sensor is accurate to 0.75C over the range of -25 to +85 C, and to 1.0
+degree from -40 to +125 C. Resolution of the sensor is 0.0625 degree. The
+operating temperature has a minimum of -55 C and a maximum of +150 C.
+Hysteresis values can be set to 0, 1, 2, or 4C.
+
+The TMP108 has a programmable update rate that can select between 8, 4, 1, and
+0.5 Hz.
+
+By default the TMP108 reads the temperature continuously. To conserve power,
+the TMP108 has a one-shot mode where the device is normally shut-down. When a
+one shot is requested the temperature is read, the result can be retrieved,
+and then the device is shut down automatically. (This driver only supports
+continuous mode.)
+
+The driver provides the common sysfs-interface for temperatures (see
+Documentation/hwmon/sysfs-interface under Temperatures).
+
+See Documentation/devicetree/bindings/hwmon/tmp108.txt for configuration
+properties.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 45cef3d..4c173de 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1591,6 +1591,17 @@ config SENSORS_TMP103
  This driver can also be built as a module.  If so, the module
  will be called tmp103.

+config SENSORS_TMP108
+   tristate "Texas Instruments TMP108"
+   depends on I2C
+   select REGMAP_I2C
+   help
+ If you say yes here you get support for Texas Instruments TMP108
+ sensor chips.
+
+ This driver can also be built as a module.  If so, the module
+ will be called tmp108.
+
 config SENSORS_TMP401
tristate "Texas Instruments TMP401 and compatibles"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index aecf4ba..51e5256 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -152,6 +152,7 @@ obj-$(CONFIG_SENSORS_TC74)  += tc74.o
 obj-$(CONFIG_SENSORS_THMC50)   += thmc50.o
 obj-$(CONFIG_SENSORS_TMP102)   += tmp102.o
 obj-$(CONFIG_SENSORS_TMP103)   += tmp103.o
+obj-$(CONFIG_SENSORS_TMP108)   += tmp108.o
 obj-$(CONFIG_SENSORS_TMP401)   += tmp401.o
 obj-$(CONFIG_SENSORS_TMP421)   +=

Re: [PATCH v3 0/7] mux controller abstraction and iio/i2c muxes

2016-11-27 Thread Jonathan Cameron 
On 23/11/16 11:47, Peter Rosin wrote:
> On 2016-11-22 21:58, Lars-Peter Clausen wrote:
>> On 11/21/2016 02:17 PM, Peter Rosin wrote:
>> [...]
>>> I have a piece of hardware that is using the same 3 GPIO pins
>>> to control four 8-way muxes. Three of them control ADC lines
>>> to an ADS1015 chip with an iio driver, and the last one
>>> controls the SDA line of an i2c bus. We have some deployed
>>> code to handle this, but you do not want to see it or ever
>>> hear about it. I'm not sure why I even mention it. Anyway,
>>> the situation has nagged me to no end for quite some time.
>>>
>>> So, after first getting more intimate with the i2c muxing code
>>> and later discovering the drivers/iio/inkern.c file and
>>> writing a couple of drivers making use of it, I came up with
>>> what I think is an acceptable solution; add a generic mux
>>> controller driver (and subsystem) that is shared between all
>>> instances, and combine that with an iio mux driver and a new
>>> generic i2c mux driver. The new i2c mux I called "simple"
>>> since it is only hooking the i2c muxing and the new mux
>>> controller (much like the alsa simple card driver does for ASoC).
>>
>> While abstracting this properly is all nice and good and the way it should
>> be done, but it also adds a lot of complexity and the devicetree adds a lot
>> of restrictions on what can actually be represented.
> 
> This is a characterization without any specifics. But is the
> characterization true? You have two complaints, complexity
> and restrictions with bindings.
> 
>> There is a certain point where the fabric on a PCB becomes so complex that
>> it deserves to be a device on its own (like the audio fabric drivers).
>> Especially when the hardware is built with a certain application in mind and
>> the driver is supposed to impose policy which reflects this application. The
>> latter can often not properly be described with the primitives the
>> devicetree can offer.
>>
>> And I think your setup is very borderline what can be done in a declarative
>> way only and it adds a lot of complexity over a more imperative solution in
>> form of a driver. I think it is worth investigating about having a driver
>> that is specific to your fabric and handles the interdependencies of the
>> discrete components.
> 
> So, there are three "new" concepts:
> 
> 1. Sticking a mux in front of an AD-converter. That's not all that
> novel, nor complex. Quite the opposite, I'd say. In fact, I find it
> a bit amazing that there is no in-kernel support for it.
As ever first person who needs it and has the skills to write it gets to do it 
;)
Congratulations Peter ;)
> 
> 2. Reusing the same GPIO-pins to drive different muxes. There are
> obviously chips that work this way (as Jonathan pointed out) and
> these will at some point get used in Linux devices. I guess they
> already are used, but that people handle them in userspace. Or
> something? If this is complex, which I question, it will still need
> support at some point. At least that's what I believe.
> 
> 3. Using the same GPIO pins to mux things handled by different
> subsystems. Right, this is a bit crazy, and I'd rather not have this
> requirement, but this HW is what it is so I'll need to handle it in
> some way. It is also what stops me from falling back to a userspace
> solution, which is probably connected to why #1 and #2 is not supported
> by the kernel; everybody probably does muxing in userspace. Which is
> not necessarily a good idea, nor how it's supposed to be done...
> 
> So, the only thing that's out of the ordinary (as I see it), is #3.
> The question that then needs an answer is how the in-kernel solution
> for #1 and #2 would look if we do not consider #3.
> 
> And I claim that the desired solution to #1 and #2 is pretty close
> to my proposal.
> 
> A. You do not want mux-controller drivers in every subsystem that
> needs them.
Agreed.
> 
> B. You do not want every mux-consumer to know the specifics of how to
> operate every kind of mux; there are muxes that are not controlled
> with GPIO pins...
> 
> C. When you implement muxing in a subsystem, there will in some cases
> be a need to handle parallel muxing, where there is a need to share
> mux-controllers.
> 
> It just feels right to separate out the mux-controller and refer to
> it from where a mux is needed. It solves #1 and #2. And, of course,
> as a bonus #3 is also solved. But my bias is obvious.
> 
> And that leads us to the restrictions with the bindings. And the same
> thing happens; the solution for #2 also solves #3.
> 
> So how do you refer to a mux-controller from where it's needed? My
> first proposal used a dt phandle, for the second round I put them in
> the parent node. It would be super if it was possible for the mux-
> consumer to create the mux-controller device from the same dt
> node that is already bound to the mux-consumer. The problem is that
> the mux-consumer should not hard-code which mux-controller device it
> should create. Th