* [PATCH 2/6] docs: writing-schema.md: convert from markdown to ReST
From: Mauro Carvalho Chehab @ 2019-07-31 20:08 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Rob Herring, Mark Rutland, devicetree,
Rob Herring
In-Reply-To: <cover.1564603513.git.mchehab+samsung@kernel.org>
The documentation standard is ReST and not markdown.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/writing-schema.md | 130 -----------------
Documentation/devicetree/writing-schema.rst | 153 ++++++++++++++++++++
2 files changed, 153 insertions(+), 130 deletions(-)
delete mode 100644 Documentation/devicetree/writing-schema.md
create mode 100644 Documentation/devicetree/writing-schema.rst
diff --git a/Documentation/devicetree/writing-schema.md b/Documentation/devicetree/writing-schema.md
deleted file mode 100644
index dc032db36262..000000000000
--- a/Documentation/devicetree/writing-schema.md
+++ /dev/null
@@ -1,130 +0,0 @@
-# Writing DeviceTree Bindings in json-schema
-
-Devicetree bindings are written using json-schema vocabulary. Schema files are
-written in a JSON compatible subset of YAML. YAML is used instead of JSON as it
-considered more human readable and has some advantages such as allowing
-comments (Prefixed with '#').
-
-## Schema Contents
-
-Each schema doc is a structured json-schema which is defined by a set of
-top-level properties. Generally, there is one binding defined per file. The
-top-level json-schema properties used are:
-
-- __$id__ - A json-schema unique identifier string. The string must be a valid
-URI typically containing the binding's filename and path. For DT schema, it must
-begin with "http://devicetree.org/schemas/". The URL is used in constructing
-references to other files specified in schema "$ref" properties. A $ref values
-with a leading '/' will have the hostname prepended. A $ref value a relative
-path or filename only will be prepended with the hostname and path components
-of the current schema file's '$id' value. A URL is used even for local files,
-but there may not actually be files present at those locations.
-
-- __$schema__ - Indicates the meta-schema the schema file adheres to.
-
-- __title__ - A one line description on the contents of the binding schema.
-
-- __maintainers__ - A DT specific property. Contains a list of email address(es)
-for maintainers of this binding.
-
-- __description__ - Optional. A multi-line text block containing any detailed
-information about this binding. It should contain things such as what the block
-or device does, standards the device conforms to, and links to datasheets for
-more information.
-
-- __select__ - Optional. A json-schema used to match nodes for applying the
-schema. By default without 'select', nodes are matched against their possible
-compatible string values or node name. Most bindings should not need select.
-
-- __allOf__ - Optional. A list of other schemas to include. This is used to
-include other schemas the binding conforms to. This may be schemas for a
-particular class of devices such as I2C or SPI controllers.
-
-- __properties__ - A set of sub-schema defining all the DT properties for the
-binding. The exact schema syntax depends on whether properties are known,
-common properties (e.g. 'interrupts') or are binding/vendor specific properties.
-
- A property can also define a child DT node with child properties defined
-under it.
-
- For more details on properties sections, see 'Property Schema' section.
-
-- __patternProperties__ - Optional. Similar to 'properties', but names are regex.
-
-- __required__ - A list of DT properties from the 'properties' section that
-must always be present.
-
-- __examples__ - Optional. A list of one or more DTS hunks implementing the
-binding. Note: YAML doesn't allow leading tabs, so spaces must be used instead.
-
-Unless noted otherwise, all properties are required.
-
-## Property Schema
-
-The 'properties' section of the schema contains all the DT properties for a
-binding. Each property contains a set of constraints using json-schema
-vocabulary for that property. The properties schemas are what is used for
-validation of DT files.
-
-For common properties, only additional constraints not covered by the common
-binding schema need to be defined such as how many values are valid or what
-possible values are valid.
-
-Vendor specific properties will typically need more detailed schema. With the
-exception of boolean properties, they should have a reference to a type in
-schemas/types.yaml. A "description" property is always required.
-
-The Devicetree schemas don't exactly match the YAML encoded DT data produced by
-dtc. They are simplified to make them more compact and avoid a bunch of
-boilerplate. The tools process the schema files to produce the final schema for
-validation. There are currently 2 transformations the tools perform.
-
-The default for arrays in json-schema is they are variable sized and allow more
-entries than explicitly defined. This can be restricted by defining 'minItems',
-'maxItems', and 'additionalItems'. However, for DeviceTree Schemas, a fixed
-size is desired in most cases, so these properties are added based on the
-number of entries in an 'items' list.
-
-The YAML Devicetree format also makes all string values an array and scalar
-values a matrix (in order to define groupings) even when only a single value
-is present. Single entries in schemas are fixed up to match this encoding.
-
-## Testing
-
-### Dependencies
-
-The DT schema project must be installed in order to validate the DT schema
-binding documents and validate DTS files using the DT schema. The DT schema
-project can be installed with pip:
-
-`pip3 install git+https://github.com/devicetree-org/dt-schema.git@master`
-
-dtc must also be built with YAML output support enabled. This requires that
-libyaml and its headers be installed on the host system.
-
-### Running checks
-
-The DT schema binding documents must be validated using the meta-schema (the
-schema for the schema) to ensure they are both valid json-schema and valid
-binding schema. All of the DT binding documents can be validated using the
-`dt_binding_check` target:
-
-`make dt_binding_check`
-
-In order to perform validation of DT source files, use the `dtbs_check` target:
-
-`make dtbs_check`
-
-This will first run the `dt_binding_check` which generates the processed schema.
-
-It is also possible to run checks with a single schema file by setting the
-'DT_SCHEMA_FILES' variable to a specific schema file.
-
-`make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/trivial-devices.yaml`
-
-
-## json-schema Resources
-
-[JSON-Schema Specifications](http://json-schema.org/)
-
-[Using JSON Schema Book](http://usingjsonschema.com/)
diff --git a/Documentation/devicetree/writing-schema.rst b/Documentation/devicetree/writing-schema.rst
new file mode 100644
index 000000000000..8f71d1e2ac52
--- /dev/null
+++ b/Documentation/devicetree/writing-schema.rst
@@ -0,0 +1,153 @@
+:orphan:
+
+Writing DeviceTree Bindings in json-schema
+==========================================
+
+Devicetree bindings are written using json-schema vocabulary. Schema files are
+written in a JSON compatible subset of YAML. YAML is used instead of JSON as it
+considered more human readable and has some advantages such as allowing
+comments (Prefixed with '#').
+
+Schema Contents
+---------------
+
+Each schema doc is a structured json-schema which is defined by a set of
+top-level properties. Generally, there is one binding defined per file. The
+top-level json-schema properties used are:
+
+$id
+ A json-schema unique identifier string. The string must be a valid
+ URI typically containing the binding's filename and path. For DT schema, it must
+ begin with "http://devicetree.org/schemas/". The URL is used in constructing
+ references to other files specified in schema "$ref" properties. A $ref values
+ with a leading '/' will have the hostname prepended. A $ref value a relative
+ path or filename only will be prepended with the hostname and path components
+ of the current schema file's '$id' value. A URL is used even for local files,
+ but there may not actually be files present at those locations.
+
+$schema
+ Indicates the meta-schema the schema file adheres to.
+
+title
+ A one line description on the contents of the binding schema.
+
+maintainers
+ A DT specific property. Contains a list of email address(es)
+ for maintainers of this binding.
+
+description
+ Optional. A multi-line text block containing any detailed
+ information about this binding. It should contain things such as what the block
+ or device does, standards the device conforms to, and links to datasheets for
+ more information.
+
+select
+ Optional. A json-schema used to match nodes for applying the
+ schema. By default without 'select', nodes are matched against their possible
+ compatible string values or node name. Most bindings should not need select.
+
+ allOf
+ Optional. A list of other schemas to include. This is used to
+ include other schemas the binding conforms to. This may be schemas for a
+ particular class of devices such as I2C or SPI controllers.
+
+ properties
+ A set of sub-schema defining all the DT properties for the
+ binding. The exact schema syntax depends on whether properties are known,
+ common properties (e.g. 'interrupts') or are binding/vendor specific properties.
+
+A property can also define a child DT node with child properties defined
+under it.
+
+For more details on properties sections, see 'Property Schema' section.
+
+patternProperties
+ Optional. Similar to 'properties', but names are regex.
+
+required
+ A list of DT properties from the 'properties' section that
+ must always be present.
+
+examples
+ Optional. A list of one or more DTS hunks implementing the
+ binding. Note: YAML doesn't allow leading tabs, so spaces must be used instead.
+
+Unless noted otherwise, all properties are required.
+
+Property Schema
+---------------
+
+The 'properties' section of the schema contains all the DT properties for a
+binding. Each property contains a set of constraints using json-schema
+vocabulary for that property. The properties schemas are what is used for
+validation of DT files.
+
+For common properties, only additional constraints not covered by the common
+binding schema need to be defined such as how many values are valid or what
+possible values are valid.
+
+Vendor specific properties will typically need more detailed schema. With the
+exception of boolean properties, they should have a reference to a type in
+schemas/types.yaml. A "description" property is always required.
+
+The Devicetree schemas don't exactly match the YAML encoded DT data produced by
+dtc. They are simplified to make them more compact and avoid a bunch of
+boilerplate. The tools process the schema files to produce the final schema for
+validation. There are currently 2 transformations the tools perform.
+
+The default for arrays in json-schema is they are variable sized and allow more
+entries than explicitly defined. This can be restricted by defining 'minItems',
+'maxItems', and 'additionalItems'. However, for DeviceTree Schemas, a fixed
+size is desired in most cases, so these properties are added based on the
+number of entries in an 'items' list.
+
+The YAML Devicetree format also makes all string values an array and scalar
+values a matrix (in order to define groupings) even when only a single value
+is present. Single entries in schemas are fixed up to match this encoding.
+
+Testing
+-------
+
+Dependencies
+~~~~~~~~~~~~
+
+The DT schema project must be installed in order to validate the DT schema
+binding documents and validate DTS files using the DT schema. The DT schema
+project can be installed with pip::
+
+ pip3 install git+https://github.com/devicetree-org/dt-schema.git@master
+
+dtc must also be built with YAML output support enabled. This requires that
+libyaml and its headers be installed on the host system.
+
+Running checks
+~~~~~~~~~~~~~~
+
+The DT schema binding documents must be validated using the meta-schema (the
+schema for the schema) to ensure they are both valid json-schema and valid
+binding schema. All of the DT binding documents can be validated using the
+``dt_binding_check`` target::
+
+ make dt_binding_check
+
+In order to perform validation of DT source files, use the `dtbs_check` target::
+
+ make dtbs_check
+
+This will first run the `dt_binding_check` which generates the processed schema.
+
+It is also possible to run checks with a single schema file by setting the
+``DT_SCHEMA_FILES`` variable to a specific schema file.
+
+::
+
+ make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/trivial-devices.yaml
+
+
+json-schema Resources
+---------------------
+
+
+`JSON-Schema Specifications <http://json-schema.org/>`_
+
+`Using JSON Schema Book <http://usingjsonschema.com/>`_
--
2.21.0
^ permalink raw reply related
* [PATCH 6/6] docs: w1: convert to ReST and add to the kAPI group of docs
From: Mauro Carvalho Chehab @ 2019-07-31 20:08 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Evgeniy Polyakov
In-Reply-To: <cover.1564603513.git.mchehab+samsung@kernel.org>
The 1wire documentation was written with w1 developers in
mind, so, it makes sense to add it together with the driver-api
set.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/ABI/stable/sysfs-bus-w1 | 2 +-
.../ABI/stable/sysfs-driver-w1_ds28e04 | 4 +-
.../ABI/stable/sysfs-driver-w1_ds28ea00 | 2 +-
Documentation/index.rst | 1 +
Documentation/w1/index.rst | 21 +++++
.../w1/masters/{ds2482 => ds2482.rst} | 16 +++-
.../w1/masters/{ds2490 => ds2490.rst} | 6 +-
Documentation/w1/masters/index.rst | 14 +++
Documentation/w1/masters/mxc-w1 | 12 ---
Documentation/w1/masters/mxc-w1.rst | 17 ++++
.../w1/masters/{omap-hdq => omap-hdq.rst} | 12 +--
.../w1/masters/{w1-gpio => w1-gpio.rst} | 21 +++--
Documentation/w1/slaves/index.rst | 16 ++++
.../w1/slaves/{w1_ds2406 => w1_ds2406.rst} | 4 +-
.../w1/slaves/{w1_ds2413 => w1_ds2413.rst} | 9 ++
Documentation/w1/slaves/w1_ds2423 | 47 ----------
Documentation/w1/slaves/w1_ds2423.rst | 54 +++++++++++
.../w1/slaves/{w1_ds2438 => w1_ds2438.rst} | 10 ++-
.../w1/slaves/{w1_ds28e04 => w1_ds28e04.rst} | 5 ++
.../w1/slaves/{w1_ds28e17 => w1_ds28e17.rst} | 16 ++--
.../w1/slaves/{w1_therm => w1_therm.rst} | 11 ++-
.../w1/{w1.generic => w1-generic.rst} | 88 ++++++++++--------
.../w1/{w1.netlink => w1-netlink.rst} | 89 +++++++++++--------
23 files changed, 308 insertions(+), 169 deletions(-)
create mode 100644 Documentation/w1/index.rst
rename Documentation/w1/masters/{ds2482 => ds2482.rst} (71%)
rename Documentation/w1/masters/{ds2490 => ds2490.rst} (98%)
create mode 100644 Documentation/w1/masters/index.rst
delete mode 100644 Documentation/w1/masters/mxc-w1
create mode 100644 Documentation/w1/masters/mxc-w1.rst
rename Documentation/w1/masters/{omap-hdq => omap-hdq.rst} (90%)
rename Documentation/w1/masters/{w1-gpio => w1-gpio.rst} (75%)
create mode 100644 Documentation/w1/slaves/index.rst
rename Documentation/w1/slaves/{w1_ds2406 => w1_ds2406.rst} (96%)
rename Documentation/w1/slaves/{w1_ds2413 => w1_ds2413.rst} (81%)
delete mode 100644 Documentation/w1/slaves/w1_ds2423
create mode 100644 Documentation/w1/slaves/w1_ds2423.rst
rename Documentation/w1/slaves/{w1_ds2438 => w1_ds2438.rst} (93%)
rename Documentation/w1/slaves/{w1_ds28e04 => w1_ds28e04.rst} (93%)
rename Documentation/w1/slaves/{w1_ds28e17 => w1_ds28e17.rst} (88%)
rename Documentation/w1/slaves/{w1_therm => w1_therm.rst} (95%)
rename Documentation/w1/{w1.generic => w1-generic.rst} (59%)
rename Documentation/w1/{w1.netlink => w1-netlink.rst} (77%)
diff --git a/Documentation/ABI/stable/sysfs-bus-w1 b/Documentation/ABI/stable/sysfs-bus-w1
index 140d85b4ae92..992dfb183ed0 100644
--- a/Documentation/ABI/stable/sysfs-bus-w1
+++ b/Documentation/ABI/stable/sysfs-bus-w1
@@ -6,6 +6,6 @@ Description: Bus scanning interval, microseconds component.
control systems are attached/generate presence for as short as
100 ms - hence the tens-to-hundreds milliseconds scan intervals
are required.
- see Documentation/w1/w1.generic for detailed information.
+ see Documentation/w1/w1-generic.rst for detailed information.
Users: any user space application which wants to know bus scanning
interval
diff --git a/Documentation/ABI/stable/sysfs-driver-w1_ds28e04 b/Documentation/ABI/stable/sysfs-driver-w1_ds28e04
index 26579ee868c9..3e1c1fa8d54d 100644
--- a/Documentation/ABI/stable/sysfs-driver-w1_ds28e04
+++ b/Documentation/ABI/stable/sysfs-driver-w1_ds28e04
@@ -2,7 +2,7 @@ What: /sys/bus/w1/devices/.../pio
Date: May 2012
Contact: Markus Franke <franm@hrz.tu-chemnitz.de>
Description: read/write the contents of the two PIO's of the DS28E04-100
- see Documentation/w1/slaves/w1_ds28e04 for detailed information
+ see Documentation/w1/slaves/w1_ds28e04.rst for detailed information
Users: any user space application which wants to communicate with DS28E04-100
@@ -11,5 +11,5 @@ What: /sys/bus/w1/devices/.../eeprom
Date: May 2012
Contact: Markus Franke <franm@hrz.tu-chemnitz.de>
Description: read/write the contents of the EEPROM memory of the DS28E04-100
- see Documentation/w1/slaves/w1_ds28e04 for detailed information
+ see Documentation/w1/slaves/w1_ds28e04.rst for detailed information
Users: any user space application which wants to communicate with DS28E04-100
diff --git a/Documentation/ABI/stable/sysfs-driver-w1_ds28ea00 b/Documentation/ABI/stable/sysfs-driver-w1_ds28ea00
index e928def14f28..534e63731a49 100644
--- a/Documentation/ABI/stable/sysfs-driver-w1_ds28ea00
+++ b/Documentation/ABI/stable/sysfs-driver-w1_ds28ea00
@@ -2,5 +2,5 @@ What: /sys/bus/w1/devices/.../w1_seq
Date: Apr 2015
Contact: Matt Campbell <mattrcampbell@gmail.com>
Description: Support for the DS28EA00 chain sequence function
- see Documentation/w1/slaves/w1_therm for detailed information
+ see Documentation/w1/slaves/w1_therm.rst for detailed information
Users: any user space application which wants to communicate with DS28EA00
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 472b8abe52e9..0a564f3c336e 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -117,6 +117,7 @@ needed).
target/index
timers/index
spi/index
+ w1/index
watchdog/index
virtual/index
input/index
diff --git a/Documentation/w1/index.rst b/Documentation/w1/index.rst
new file mode 100644
index 000000000000..57cba81865e2
--- /dev/null
+++ b/Documentation/w1/index.rst
@@ -0,0 +1,21 @@
+. SPDX-License-Identifier: GPL-2.0
+
+================
+1-Wire Subsystem
+================
+
+.. toctree::
+ :maxdepth: 1
+
+
+ w1-generic.rst
+ w1-netlink.rst
+ masters/index
+ slaves/index
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/w1/masters/ds2482 b/Documentation/w1/masters/ds2482.rst
similarity index 71%
rename from Documentation/w1/masters/ds2482
rename to Documentation/w1/masters/ds2482.rst
index 56f8edace6ac..17ebe8f660cd 100644
--- a/Documentation/w1/masters/ds2482
+++ b/Documentation/w1/masters/ds2482.rst
@@ -1,13 +1,19 @@
+====================
Kernel driver ds2482
====================
Supported chips:
+
* Maxim DS2482-100, Maxim DS2482-800
+
Prefix: 'ds2482'
+
Addresses scanned: None
+
Datasheets:
- http://datasheets.maxim-ic.com/en/ds/DS2482-100.pdf
- http://datasheets.maxim-ic.com/en/ds/DS2482-800.pdf
+
+ - http://datasheets.maxim-ic.com/en/ds/DS2482-100.pdf
+ - http://datasheets.maxim-ic.com/en/ds/DS2482-800.pdf
Author: Ben Gardner <bgardner@wabtec.com>
@@ -23,9 +29,11 @@ General Remarks
---------------
Valid addresses are 0x18, 0x19, 0x1a, and 0x1b.
+
However, the device cannot be detected without writing to the i2c bus, so no
detection is done. You should instantiate the device explicitly.
-$ modprobe ds2482
-$ echo ds2482 0x18 > /sys/bus/i2c/devices/i2c-0/new_device
+::
+ $ modprobe ds2482
+ $ echo ds2482 0x18 > /sys/bus/i2c/devices/i2c-0/new_device
diff --git a/Documentation/w1/masters/ds2490 b/Documentation/w1/masters/ds2490.rst
similarity index 98%
rename from Documentation/w1/masters/ds2490
rename to Documentation/w1/masters/ds2490.rst
index 3e091151dd80..7e5b50f9c0f5 100644
--- a/Documentation/w1/masters/ds2490
+++ b/Documentation/w1/masters/ds2490.rst
@@ -1,7 +1,9 @@
+====================
Kernel driver ds2490
====================
Supported chips:
+
* Maxim DS2490 based
Author: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
@@ -18,6 +20,7 @@ which has 0x81 family ID integrated chip and DS2490
low-level operational chip.
Notes and limitations.
+
- The weak pullup current is a minimum of 0.9mA and maximum of 6.0mA.
- The 5V strong pullup is supported with a minimum of 5.9mA and a
maximum of 30.4 mA. (From DS2490.pdf)
@@ -65,4 +68,5 @@ Notes and limitations.
reattaching would clear the problem. usbmon output in the guest and
host did not explain the problem. My guess is a bug in either qemu
or the host OS and more likely the host OS.
--- 03-06-2008 David Fries <David@Fries.net>
+
+03-06-2008 David Fries <David@Fries.net>
diff --git a/Documentation/w1/masters/index.rst b/Documentation/w1/masters/index.rst
new file mode 100644
index 000000000000..4442a98850ad
--- /dev/null
+++ b/Documentation/w1/masters/index.rst
@@ -0,0 +1,14 @@
+. SPDX-License-Identifier: GPL-2.0
+
+=====================
+1-wire Master Drivers
+=====================
+
+.. toctree::
+ :maxdepth: 1
+
+ ds2482
+ ds2490
+ mxc-w1
+ omap-hdq
+ w1-gpio
diff --git a/Documentation/w1/masters/mxc-w1 b/Documentation/w1/masters/mxc-w1
deleted file mode 100644
index 38be1ad65532..000000000000
--- a/Documentation/w1/masters/mxc-w1
+++ /dev/null
@@ -1,12 +0,0 @@
-Kernel driver mxc_w1
-====================
-
-Supported chips:
- * Freescale MX27, MX31 and probably other i.MX SoCs
- Datasheets:
- http://www.freescale.com/files/32bit/doc/data_sheet/MCIMX31.pdf?fpsp=1
- http://cache.freescale.com/files/dsp/doc/archive/MCIMX27.pdf?fsrch=1&WT_TYPE=
- Data%20Sheets&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation
-
-Author: Originally based on Freescale code, prepared for mainline by
- Sascha Hauer <s.hauer@pengutronix.de>
diff --git a/Documentation/w1/masters/mxc-w1.rst b/Documentation/w1/masters/mxc-w1.rst
new file mode 100644
index 000000000000..334f9893103f
--- /dev/null
+++ b/Documentation/w1/masters/mxc-w1.rst
@@ -0,0 +1,17 @@
+====================
+Kernel driver mxc_w1
+====================
+
+Supported chips:
+
+ * Freescale MX27, MX31 and probably other i.MX SoCs
+
+ Datasheets:
+
+ - http://www.freescale.com/files/32bit/doc/data_sheet/MCIMX31.pdf?fpsp=1
+ - http://cache.freescale.com/files/dsp/doc/archive/MCIMX27.pdf?fsrch=1&WT_TYPE=Data%20Sheets&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation
+
+Author:
+
+ Originally based on Freescale code, prepared for mainline by
+ Sascha Hauer <s.hauer@pengutronix.de>
diff --git a/Documentation/w1/masters/omap-hdq b/Documentation/w1/masters/omap-hdq.rst
similarity index 90%
rename from Documentation/w1/masters/omap-hdq
rename to Documentation/w1/masters/omap-hdq.rst
index 234522709a5f..345298a59e50 100644
--- a/Documentation/w1/masters/omap-hdq
+++ b/Documentation/w1/masters/omap-hdq.rst
@@ -1,9 +1,10 @@
-Kernel driver for omap HDQ/1-wire module.
+========================================
+Kernel driver for omap HDQ/1-wire module
========================================
Supported chips:
================
- HDQ/1-wire controller on the TI OMAP 2430/3430 platforms.
+HDQ/1-wire controller on the TI OMAP 2430/3430 platforms.
A useful link about HDQ basics:
===============================
@@ -40,9 +41,10 @@ driver(drivers/w1/slaves/w1_bq27000.c) sets the ID to 1.
Please note to load both the modules with a different ID if required, but note
that the ID used should be same for both master and slave driver loading.
-e.g:
-insmod omap_hdq.ko W1_ID=2
-inamod w1_bq27000.ko F_ID=2
+e.g::
+
+ insmod omap_hdq.ko W1_ID=2
+ inamod w1_bq27000.ko F_ID=2
The driver also supports 1-wire mode. In this mode, there is no need to
pass slave ID as parameter. The driver will auto-detect slaves connected
diff --git a/Documentation/w1/masters/w1-gpio b/Documentation/w1/masters/w1-gpio.rst
similarity index 75%
rename from Documentation/w1/masters/w1-gpio
rename to Documentation/w1/masters/w1-gpio.rst
index 623961d9e83f..18fdb7366372 100644
--- a/Documentation/w1/masters/w1-gpio
+++ b/Documentation/w1/masters/w1-gpio.rst
@@ -1,3 +1,4 @@
+=====================
Kernel driver w1-gpio
=====================
@@ -16,28 +17,30 @@ Documentation/devicetree/bindings/w1/w1-gpio.txt
Example (mach-at91)
-------------------
-#include <linux/gpio/machine.h>
-#include <linux/w1-gpio.h>
+::
-static struct gpiod_lookup_table foo_w1_gpiod_table = {
+ #include <linux/gpio/machine.h>
+ #include <linux/w1-gpio.h>
+
+ static struct gpiod_lookup_table foo_w1_gpiod_table = {
.dev_id = "w1-gpio",
.table = {
GPIO_LOOKUP_IDX("at91-gpio", AT91_PIN_PB20, NULL, 0,
GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN),
},
-};
+ };
-static struct w1_gpio_platform_data foo_w1_gpio_pdata = {
+ static struct w1_gpio_platform_data foo_w1_gpio_pdata = {
.ext_pullup_enable_pin = -EINVAL,
-};
+ };
-static struct platform_device foo_w1_device = {
+ static struct platform_device foo_w1_device = {
.name = "w1-gpio",
.id = -1,
.dev.platform_data = &foo_w1_gpio_pdata,
-};
+ };
-...
+ ...
at91_set_GPIO_periph(foo_w1_gpio_pdata.pin, 1);
at91_set_multi_drive(foo_w1_gpio_pdata.pin, 1);
gpiod_add_lookup_table(&foo_w1_gpiod_table);
diff --git a/Documentation/w1/slaves/index.rst b/Documentation/w1/slaves/index.rst
new file mode 100644
index 000000000000..d0697b202f09
--- /dev/null
+++ b/Documentation/w1/slaves/index.rst
@@ -0,0 +1,16 @@
+. SPDX-License-Identifier: GPL-2.0
+
+====================
+1-wire Slave Drivers
+====================
+
+.. toctree::
+ :maxdepth: 1
+
+ w1_ds2406
+ w1_ds2413
+ w1_ds2423
+ w1_ds2438
+ w1_ds28e04
+ w1_ds28e17
+ w1_therm
diff --git a/Documentation/w1/slaves/w1_ds2406 b/Documentation/w1/slaves/w1_ds2406.rst
similarity index 96%
rename from Documentation/w1/slaves/w1_ds2406
rename to Documentation/w1/slaves/w1_ds2406.rst
index 8137fe6f6c3d..d3e68266084f 100644
--- a/Documentation/w1/slaves/w1_ds2406
+++ b/Documentation/w1/slaves/w1_ds2406.rst
@@ -1,7 +1,9 @@
+=======================
w1_ds2406 kernel driver
=======================
Supported chips:
+
* Maxim DS2406 (and other family 0x12) addressable switches
Author: Scott Alfter <scott@alfter.us>
@@ -9,7 +11,7 @@ Author: Scott Alfter <scott@alfter.us>
Description
-----------
-The w1_ds2406 driver allows connected devices to be switched on and off.
+The w1_ds2406 driver allows connected devices to be switched on and off.
These chips also provide 128 bytes of OTP EPROM, but reading/writing it is
not supported. In TSOC-6 form, the DS2406 provides two switch outputs and
can be provided with power on a dedicated input. In TO-92 form, it provides
diff --git a/Documentation/w1/slaves/w1_ds2413 b/Documentation/w1/slaves/w1_ds2413.rst
similarity index 81%
rename from Documentation/w1/slaves/w1_ds2413
rename to Documentation/w1/slaves/w1_ds2413.rst
index 936263a8ccb4..c15bb5b919b7 100644
--- a/Documentation/w1/slaves/w1_ds2413
+++ b/Documentation/w1/slaves/w1_ds2413.rst
@@ -1,11 +1,16 @@
+=======================
Kernel driver w1_ds2413
=======================
Supported chips:
+
* Maxim DS2413 1-Wire Dual Channel Addressable Switch
supported family codes:
+
+ ================ ====
W1_FAMILY_DS2413 0x3A
+ ================ ====
Author: Mariusz Bialonczyk <manio@skyboo.net>
@@ -20,11 +25,13 @@ Reading state
The "state" file provides one-byte value which is in the same format as for
the chip PIO_ACCESS_READ command (refer the datasheet for details):
+======== =============================================================
Bit 0: PIOA Pin State
Bit 1: PIOA Output Latch State
Bit 2: PIOB Pin State
Bit 3: PIOB Output Latch State
Bit 4-7: Complement of Bit 3 to Bit 0 (verified by the kernel module)
+======== =============================================================
This file is readonly.
@@ -34,9 +41,11 @@ You can set the PIO pins using the "output" file.
It is writable, you can write one-byte value to this sysfs file.
Similarly the byte format is the same as for the PIO_ACCESS_WRITE command:
+======== ======================================
Bit 0: PIOA
Bit 1: PIOB
Bit 2-7: No matter (driver will set it to "1"s)
+======== ======================================
The chip has some kind of basic protection against transmission errors.
diff --git a/Documentation/w1/slaves/w1_ds2423 b/Documentation/w1/slaves/w1_ds2423
deleted file mode 100644
index 3f98b505a0ee..000000000000
--- a/Documentation/w1/slaves/w1_ds2423
+++ /dev/null
@@ -1,47 +0,0 @@
-Kernel driver w1_ds2423
-=======================
-
-Supported chips:
- * Maxim DS2423 based counter devices.
-
-supported family codes:
- W1_THERM_DS2423 0x1D
-
-Author: Mika Laitio <lamikr@pilppa.org>
-
-Description
------------
-
-Support is provided through the sysfs w1_slave file. Each opening and
-read sequence of w1_slave file initiates the read of counters and ram
-available in DS2423 pages 12 - 15.
-
-Result of each page is provided as an ASCII output where each counter
-value and associated ram buffer is outpputed to own line.
-
-Each lines will contain the values of 42 bytes read from the counter and
-memory page along the crc=YES or NO for indicating whether the read operation
-was successful and CRC matched.
-If the operation was successful, there is also in the end of each line
-a counter value expressed as an integer after c=
-
-Meaning of 42 bytes represented is following:
- - 1 byte from ram page
- - 4 bytes for the counter value
- - 4 zero bytes
- - 2 bytes for crc16 which was calculated from the data read since the previous crc bytes
- - 31 remaining bytes from the ram page
- - crc=YES/NO indicating whether read was ok and crc matched
- - c=<int> current counter value
-
-example from the successful read:
-00 02 00 00 00 00 00 00 00 6d 38 00 ff ff 00 00 fe ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=YES c=2
-00 02 00 00 00 00 00 00 00 e0 1f 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=YES c=2
-00 29 c6 5d 18 00 00 00 00 04 37 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=YES c=408798761
-00 05 00 00 00 00 00 00 00 8d 39 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff crc=YES c=5
-
-example from the read with crc errors:
-00 02 00 00 00 00 00 00 00 6d 38 00 ff ff 00 00 fe ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=YES c=2
-00 02 00 00 22 00 00 00 00 e0 1f 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=NO
-00 e1 61 5d 19 00 00 00 00 df 0b 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=NO
-00 05 00 00 20 00 00 00 00 8d 39 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff crc=NO
diff --git a/Documentation/w1/slaves/w1_ds2423.rst b/Documentation/w1/slaves/w1_ds2423.rst
new file mode 100644
index 000000000000..755d659ad997
--- /dev/null
+++ b/Documentation/w1/slaves/w1_ds2423.rst
@@ -0,0 +1,54 @@
+Kernel driver w1_ds2423
+=======================
+
+Supported chips:
+
+ * Maxim DS2423 based counter devices.
+
+supported family codes:
+
+ =============== ====
+ W1_THERM_DS2423 0x1D
+ =============== ====
+
+Author: Mika Laitio <lamikr@pilppa.org>
+
+Description
+-----------
+
+Support is provided through the sysfs w1_slave file. Each opening and
+read sequence of w1_slave file initiates the read of counters and ram
+available in DS2423 pages 12 - 15.
+
+Result of each page is provided as an ASCII output where each counter
+value and associated ram buffer is outpputed to own line.
+
+Each lines will contain the values of 42 bytes read from the counter and
+memory page along the crc=YES or NO for indicating whether the read operation
+was successful and CRC matched.
+If the operation was successful, there is also in the end of each line
+a counter value expressed as an integer after c=
+
+Meaning of 42 bytes represented is following:
+
+ - 1 byte from ram page
+ - 4 bytes for the counter value
+ - 4 zero bytes
+ - 2 bytes for crc16 which was calculated from the data read since the previous crc bytes
+ - 31 remaining bytes from the ram page
+ - crc=YES/NO indicating whether read was ok and crc matched
+ - c=<int> current counter value
+
+example from the successful read::
+
+ 00 02 00 00 00 00 00 00 00 6d 38 00 ff ff 00 00 fe ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=YES c=2
+ 00 02 00 00 00 00 00 00 00 e0 1f 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=YES c=2
+ 00 29 c6 5d 18 00 00 00 00 04 37 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=YES c=408798761
+ 00 05 00 00 00 00 00 00 00 8d 39 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff crc=YES c=5
+
+example from the read with crc errors::
+
+ 00 02 00 00 00 00 00 00 00 6d 38 00 ff ff 00 00 fe ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=YES c=2
+ 00 02 00 00 22 00 00 00 00 e0 1f 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=NO
+ 00 e1 61 5d 19 00 00 00 00 df 0b 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=NO
+ 00 05 00 00 20 00 00 00 00 8d 39 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff crc=NO
diff --git a/Documentation/w1/slaves/w1_ds2438 b/Documentation/w1/slaves/w1_ds2438.rst
similarity index 93%
rename from Documentation/w1/slaves/w1_ds2438
rename to Documentation/w1/slaves/w1_ds2438.rst
index e64f65a09387..a29309a3f8e5 100644
--- a/Documentation/w1/slaves/w1_ds2438
+++ b/Documentation/w1/slaves/w1_ds2438.rst
@@ -2,10 +2,13 @@ Kernel driver w1_ds2438
=======================
Supported chips:
+
* Maxim DS2438 Smart Battery Monitor
supported family codes:
+ ================ ====
W1_FAMILY_DS2438 0x26
+ ================ ====
Author: Mariusz Bialonczyk <manio@skyboo.net>
@@ -56,8 +59,11 @@ Opening and reading this file initiates the CONVERT_V (voltage conversion)
command of the chip.
Depending on a sysfs filename a different input for the A/D will be selected:
-vad: general purpose A/D input (VAD)
-vdd: battery input (VDD)
+
+vad:
+ general purpose A/D input (VAD)
+vdd:
+ battery input (VDD)
After the voltage conversion the value is returned as decimal ASCII.
Note: To get a volts the value has to be divided by 100.
diff --git a/Documentation/w1/slaves/w1_ds28e04 b/Documentation/w1/slaves/w1_ds28e04.rst
similarity index 93%
rename from Documentation/w1/slaves/w1_ds28e04
rename to Documentation/w1/slaves/w1_ds28e04.rst
index 7819b65cfa48..b12b118890d3 100644
--- a/Documentation/w1/slaves/w1_ds28e04
+++ b/Documentation/w1/slaves/w1_ds28e04.rst
@@ -1,11 +1,16 @@
+========================
Kernel driver w1_ds28e04
========================
Supported chips:
+
* Maxim DS28E04-100 4096-Bit Addressable 1-Wire EEPROM with PIO
supported family codes:
+
+ ================= ====
W1_FAMILY_DS28E04 0x1C
+ ================= ====
Author: Markus Franke, <franke.m@sebakmt.com> <franm@hrz.tu-chemnitz.de>
diff --git a/Documentation/w1/slaves/w1_ds28e17 b/Documentation/w1/slaves/w1_ds28e17.rst
similarity index 88%
rename from Documentation/w1/slaves/w1_ds28e17
rename to Documentation/w1/slaves/w1_ds28e17.rst
index 7fcfad5b4a37..e2d9f96d8f2c 100644
--- a/Documentation/w1/slaves/w1_ds28e17
+++ b/Documentation/w1/slaves/w1_ds28e17.rst
@@ -1,11 +1,16 @@
+========================
Kernel driver w1_ds28e17
========================
Supported chips:
+
* Maxim DS28E17 1-Wire-to-I2C Master Bridge
supported family codes:
+
+ ================= ====
W1_FAMILY_DS28E17 0x19
+ ================= ====
Author: Jan Kandziora <jjj@gmx.de>
@@ -20,11 +25,11 @@ a DS28E17 can be accessed by the kernel or userspace tools as if they were
connected to a "native" I2C bus master.
-An udev rule like the following
--------------------------------------------------------------------------------
-SUBSYSTEM=="i2c-dev", KERNEL=="i2c-[0-9]*", ATTRS{name}=="w1-19-*", \
- SYMLINK+="i2c-$attr{name}"
--------------------------------------------------------------------------------
+An udev rule like the following::
+
+ SUBSYSTEM=="i2c-dev", KERNEL=="i2c-[0-9]*", ATTRS{name}=="w1-19-*", \
+ SYMLINK+="i2c-$attr{name}"
+
may be used to create stable /dev/i2c- entries based on the unique id of the
DS28E17 chip.
@@ -65,4 +70,3 @@ structure is created.
See https://github.com/ianka/w1_ds28e17 for even more information.
-
diff --git a/Documentation/w1/slaves/w1_therm b/Documentation/w1/slaves/w1_therm.rst
similarity index 95%
rename from Documentation/w1/slaves/w1_therm
rename to Documentation/w1/slaves/w1_therm.rst
index d1f93af36f38..90531c340a07 100644
--- a/Documentation/w1/slaves/w1_therm
+++ b/Documentation/w1/slaves/w1_therm.rst
@@ -1,7 +1,9 @@
+======================
Kernel driver w1_therm
-====================
+======================
Supported chips:
+
* Maxim ds18*20 based temperature sensors.
* Maxim ds1825 based temperature sensors.
@@ -13,12 +15,16 @@ Description
w1_therm provides basic temperature conversion for ds18*20 devices, and the
ds28ea00 device.
-supported family codes:
+
+Supported family codes:
+
+==================== ====
W1_THERM_DS18S20 0x10
W1_THERM_DS1822 0x22
W1_THERM_DS18B20 0x28
W1_THERM_DS1825 0x3B
W1_THERM_DS28EA00 0x42
+==================== ====
Support is provided through the sysfs w1_slave file. Each open and
read sequence will initiate a temperature conversion then provide two
@@ -51,6 +57,7 @@ If so, it will activate the master's strong pullup.
In case the detection of parasite devices using this command fails
(seems to be the case with some DS18S20) the strong pullup can
be force-enabled.
+
If the strong pullup is enabled, the master's strong pullup will be
driven when the conversion is taking place, provided the master driver
does support the strong pullup (or it falls back to a pullup
diff --git a/Documentation/w1/w1.generic b/Documentation/w1/w1-generic.rst
similarity index 59%
rename from Documentation/w1/w1.generic
rename to Documentation/w1/w1-generic.rst
index c51b1ab012d0..da4e8b4e9b01 100644
--- a/Documentation/w1/w1.generic
+++ b/Documentation/w1/w1-generic.rst
@@ -1,5 +1,7 @@
-The 1-wire (w1) subsystem
-------------------------------------------------------------------
+=========================================
+Introduction to the 1-wire (w1) subsystem
+=========================================
+
The 1-wire bus is a simple master-slave bus that communicates via a single
signal wire (plus ground, so two wires).
@@ -12,14 +14,16 @@ communication with slaves.
All w1 slave devices must be connected to a w1 bus master device.
Example w1 master devices:
- DS9490 usb device
- W1-over-GPIO
- DS2482 (i2c to w1 bridge)
- Emulated devices, such as a RS232 converter, parallel port adapter, etc
+
+ - DS9490 usb device
+ - W1-over-GPIO
+ - DS2482 (i2c to w1 bridge)
+ - Emulated devices, such as a RS232 converter, parallel port adapter, etc
What does the w1 subsystem do?
-------------------------------------------------------------------
+------------------------------
+
When a w1 master driver registers with the w1 subsystem, the following occurs:
- sysfs entries for that w1 master are created
@@ -43,24 +47,28 @@ be read, since no device was selected.
W1 device families
-------------------------------------------------------------------
+------------------
+
Slave devices are handled by a driver written for a family of w1 devices.
A family driver populates a struct w1_family_ops (see w1_family.h) and
registers with the w1 subsystem.
Current family drivers:
-w1_therm - (ds18?20 thermal sensor family driver)
+
+w1_therm
+ - (ds18?20 thermal sensor family driver)
provides temperature reading function which is bound to ->rbin() method
of the above w1_family_ops structure.
-w1_smem - driver for simple 64bit memory cell provides ID reading method.
+w1_smem
+ - driver for simple 64bit memory cell provides ID reading method.
You can call above methods by reading appropriate sysfs files.
What does a w1 master driver need to implement?
-------------------------------------------------------------------
+-----------------------------------------------
The driver for w1 bus master must provide at minimum two functions.
@@ -75,25 +83,26 @@ See struct w1_bus_master definition in w1.h for details.
w1 master sysfs interface
-------------------------------------------------------------------
-<xx-xxxxxxxxxxxx> - A directory for a found device. The format is family-serial
-bus - (standard) symlink to the w1 bus
-driver - (standard) symlink to the w1 driver
-w1_master_add - (rw) manually register a slave device
-w1_master_attempts - (ro) the number of times a search was attempted
-w1_master_max_slave_count
- - (rw) maximum number of slaves to search for at a time
-w1_master_name - (ro) the name of the device (w1_bus_masterX)
-w1_master_pullup - (rw) 5V strong pullup 0 enabled, 1 disabled
-w1_master_remove - (rw) manually remove a slave device
-w1_master_search - (rw) the number of searches left to do,
- -1=continual (default)
-w1_master_slave_count
- - (ro) the number of slaves found
-w1_master_slaves - (ro) the names of the slaves, one per line
-w1_master_timeout - (ro) the delay in seconds between searches
-w1_master_timeout_us
- - (ro) the delay in microseconds beetwen searches
+-------------------------
+
+========================= =====================================================
+<xx-xxxxxxxxxxxx> A directory for a found device. The format is
+ family-serial
+bus (standard) symlink to the w1 bus
+driver (standard) symlink to the w1 driver
+w1_master_add (rw) manually register a slave device
+w1_master_attempts (ro) the number of times a search was attempted
+w1_master_max_slave_count (rw) maximum number of slaves to search for at a time
+w1_master_name (ro) the name of the device (w1_bus_masterX)
+w1_master_pullup (rw) 5V strong pullup 0 enabled, 1 disabled
+w1_master_remove (rw) manually remove a slave device
+w1_master_search (rw) the number of searches left to do,
+ -1=continual (default)
+w1_master_slave_count (ro) the number of slaves found
+w1_master_slaves (ro) the names of the slaves, one per line
+w1_master_timeout (ro) the delay in seconds between searches
+w1_master_timeout_us (ro) the delay in microseconds beetwen searches
+========================= =====================================================
If you have a w1 bus that never changes (you don't add or remove devices),
you can set the module parameter search_count to a small positive number
@@ -111,11 +120,14 @@ decrements w1_master_search by 1 (down to 0) and increments
w1_master_attempts by 1.
w1 slave sysfs interface
-------------------------------------------------------------------
-bus - (standard) symlink to the w1 bus
-driver - (standard) symlink to the w1 driver
-name - the device name, usually the same as the directory name
-w1_slave - (optional) a binary file whose meaning depends on the
- family driver
-rw - (optional) created for slave devices which do not have
- appropriate family driver. Allows to read/write binary data.
+------------------------
+
+=================== ============================================================
+bus (standard) symlink to the w1 bus
+driver (standard) symlink to the w1 driver
+name the device name, usually the same as the directory name
+w1_slave (optional) a binary file whose meaning depends on the
+ family driver
+rw (optional) created for slave devices which do not have
+ appropriate family driver. Allows to read/write binary data.
+=================== ============================================================
diff --git a/Documentation/w1/w1.netlink b/Documentation/w1/w1-netlink.rst
similarity index 77%
rename from Documentation/w1/w1.netlink
rename to Documentation/w1/w1-netlink.rst
index 94ad4c420828..aaa13243a5e4 100644
--- a/Documentation/w1/w1.netlink
+++ b/Documentation/w1/w1-netlink.rst
@@ -1,22 +1,26 @@
-Userspace communication protocol over connector [1].
+===============================================
+Userspace communication protocol over connector
+===============================================
-
-Message types.
+Message types
=============
There are three types of messages between w1 core and userspace:
+
1. Events. They are generated each time a new master or slave device
- is found either due to automatic or requested search.
+ is found either due to automatic or requested search.
2. Userspace commands.
3. Replies to userspace commands.
-Protocol.
+Protocol
========
-[struct cn_msg] - connector header.
+::
+
+ [struct cn_msg] - connector header.
Its length field is equal to size of the attached data
-[struct w1_netlink_msg] - w1 netlink header.
+ [struct w1_netlink_msg] - w1 netlink header.
__u8 type - message type.
W1_LIST_MASTERS
list current bus masters
@@ -40,7 +44,7 @@ Protocol.
} mst;
} id;
-[struct w1_netlink_cmd] - command for given master or slave device.
+ [struct w1_netlink_cmd] - command for given master or slave device.
__u8 cmd - command opcode.
W1_CMD_READ - read command
W1_CMD_WRITE - write command
@@ -71,18 +75,18 @@ when it is added to w1 core.
Currently replies to userspace commands are only generated for read
command request. One reply is generated exactly for one w1_netlink_cmd
read request. Replies are not combined when sent - i.e. typical reply
-messages looks like the following:
+messages looks like the following::
-[cn_msg][w1_netlink_msg][w1_netlink_cmd]
-cn_msg.len = sizeof(struct w1_netlink_msg) +
+ [cn_msg][w1_netlink_msg][w1_netlink_cmd]
+ cn_msg.len = sizeof(struct w1_netlink_msg) +
sizeof(struct w1_netlink_cmd) +
cmd->len;
-w1_netlink_msg.len = sizeof(struct w1_netlink_cmd) + cmd->len;
-w1_netlink_cmd.len = cmd->len;
+ w1_netlink_msg.len = sizeof(struct w1_netlink_cmd) + cmd->len;
+ w1_netlink_cmd.len = cmd->len;
Replies to W1_LIST_MASTERS should send a message back to the userspace
which will contain list of all registered master ids in the following
-format:
+format::
cn_msg (CN_W1_IDX.CN_W1_VAL as id, len is equal to sizeof(struct
w1_netlink_msg) plus number of masters multiplied by 4)
@@ -90,39 +94,47 @@ format:
number of masters multiplied by 4 (u32 size))
id0 ... idN
- Each message is at most 4k in size, so if number of master devices
- exceeds this, it will be split into several messages.
+Each message is at most 4k in size, so if number of master devices
+exceeds this, it will be split into several messages.
W1 search and alarm search commands.
-request:
-[cn_msg]
- [w1_netlink_msg type = W1_MASTER_CMD
- id is equal to the bus master id to use for searching]
- [w1_netlink_cmd cmd = W1_CMD_SEARCH or W1_CMD_ALARM_SEARCH]
-reply:
+request::
+
+ [cn_msg]
+ [w1_netlink_msg type = W1_MASTER_CMD
+ id is equal to the bus master id to use for searching]
+ [w1_netlink_cmd cmd = W1_CMD_SEARCH or W1_CMD_ALARM_SEARCH]
+
+reply::
+
[cn_msg, ack = 1 and increasing, 0 means the last message,
- seq is equal to the request seq]
+ seq is equal to the request seq]
[w1_netlink_msg type = W1_MASTER_CMD]
[w1_netlink_cmd cmd = W1_CMD_SEARCH or W1_CMD_ALARM_SEARCH
len is equal to number of IDs multiplied by 8]
[64bit-id0 ... 64bit-idN]
+
Length in each header corresponds to the size of the data behind it, so
w1_netlink_cmd->len = N * 8; where N is number of IDs in this message.
- Can be zero.
-w1_netlink_msg->len = sizeof(struct w1_netlink_cmd) + N * 8;
-cn_msg->len = sizeof(struct w1_netlink_msg) +
+Can be zero.
+
+::
+
+ w1_netlink_msg->len = sizeof(struct w1_netlink_cmd) + N * 8;
+ cn_msg->len = sizeof(struct w1_netlink_msg) +
sizeof(struct w1_netlink_cmd) +
N*8;
-W1 reset command.
-[cn_msg]
- [w1_netlink_msg type = W1_MASTER_CMD
- id is equal to the bus master id to use for searching]
- [w1_netlink_cmd cmd = W1_CMD_RESET]
+W1 reset command::
+ [cn_msg]
+ [w1_netlink_msg type = W1_MASTER_CMD
+ id is equal to the bus master id to use for searching]
+ [w1_netlink_cmd cmd = W1_CMD_RESET]
-Command status replies.
+
+Command status replies
======================
Each command (either root, master or slave with or without w1_netlink_cmd
@@ -150,7 +162,7 @@ All w1_netlink_cmd command structures are handled in every w1_netlink_msg,
even if there were errors, only length mismatch interrupts message processing.
-Operation steps in w1 core when new command is received.
+Operation steps in w1 core when new command is received
=======================================================
When new message (w1_netlink_msg) is received w1 core detects if it is
@@ -167,7 +179,7 @@ When all commands (w1_netlink_cmd) are processed master device is unlocked
and next w1_netlink_msg header processing started.
-Connector [1] specific documentation.
+Connector [1] specific documentation
====================================
Each connector message includes two u32 fields as "address".
@@ -180,10 +192,11 @@ Sequence number for reply is the same as was in request, and
acknowledge number is set to seq+1.
-Additional documantion, source code examples.
-============================================
+Additional documentation, source code examples
+==============================================
1. Documentation/driver-api/connector.rst
2. http://www.ioremap.net/archive/w1
-This archive includes userspace application w1d.c which uses
-read/write/search commands for all master/slave devices found on the bus.
+
+ This archive includes userspace application w1d.c which uses
+ read/write/search commands for all master/slave devices found on the bus.
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 5/6] docs: fs: convert porting to ReST
From: Jonathan Corbet @ 2019-07-31 20:17 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel
In-Reply-To: <a2303fe9fa2103e7d1f8589e1f91a7d65497e8b7.1564603513.git.mchehab+samsung@kernel.org>
On Wed, 31 Jul 2019 17:08:52 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> This file has its own proper style, except that, after a while,
> the coding style gets violated and whitespaces are placed on
> different ways.
>
> As Sphinx and ReST are very sentitive to whitespace differences,
> I had to opt if each entry after required/mandatory/... fields
> should start with zero spaces or with a tab. I opted to start them
> all from the zero position, in order to avoid needing to break lines
> with more than 80 columns, with would make harder for review.
>
> Most of the other changes at porting.rst were made to use an unified
> notation with works nice as a text file while also produce a good html
> output after being parsed.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/filesystems/porting.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst
> index 66aa521e6376..f18506083ced 100644
> --- a/Documentation/filesystems/porting.rst
> +++ b/Documentation/filesystems/porting.rst
> @@ -158,7 +158,7 @@ Callers of notify_change() need ->i_mutex now.
> New super_block field ``struct export_operations *s_export_op`` for
> explicit support for exporting, e.g. via NFS. The structure is fully
> documented at its declaration in include/linux/fs.h, and in
> -Documentation/filesystems/nfs/Exporting.
> +Documentation/filesystems/nfs/exporting.rst.
>
> Briefly it allows for the definition of decode_fh and encode_fh operations
> to encode and decode filehandles, and allows the filesystem to use
This patch doesn't match the changelog at all. I think it's one leftover
fix after the previous version of the patch was applied...?
jon
^ permalink raw reply
* Re: [PATCH 0/6] ReST conversion patches not applied yet
From: Jonathan Corbet @ 2019-07-31 20:17 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
alsa-devel, Maxime Ripard, samba-technical, Mark Brown,
devicetree, Liam Girdwood, linux-iio, Lars-Peter Clausen,
Evgeniy Dushistov, Jonathan Cameron, Peter Meerwald-Stadler,
Steve French, Alexander Shishkin, Chen-Yu Tsai, Suzuki K Poulose,
linux-cifs, Dave Kleikamp, Mark Rutland, Evgeniy Polyakov,
Mathieu Poirier, Rob Herring, jfs-discussion, linux-arm-kernel,
Hartmut Knaack, linux-spi
In-Reply-To: <cover.1564603513.git.mchehab+samsung@kernel.org>
On Wed, 31 Jul 2019 17:08:47 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> As promised, this is the rebased version of the patches that were not applied
> from the /26 patch series because you had merge conflicts.
>
> They're all based on your docs-next branch, so should apply fine.
>
> The first one fixes all but one error with a broken reference.
>
> The only broken reference right now is due to a DT patch with was not
> accepted (no idea why), but whose driver is upstream.
All but 5/6 applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH 0/6] ReST conversion patches not applied yet
From: Mark Brown @ 2019-07-31 20:20 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, linux-kernel, alsa-devel, Maxime Ripard,
samba-technical, devicetree, Liam Girdwood, linux-iio,
Lars-Peter Clausen, Evgeniy Dushistov, Jonathan Cameron,
Peter Meerwald-Stadler, Steve French, Alexander Shishkin,
Chen-Yu Tsai, Suzuki K Poulose, linux-cifs, Dave Kleikamp,
Mark Rutland, Evgeniy Polyakov, Mathieu Poirier, Rob Herring,
jfs-discussion, linux-arm-kernel, Hartmut Knaack, linux-spi
In-Reply-To: <20190731141734.1fa9ce64@lwn.net>
[-- Attachment #1: Type: text/plain, Size: 832 bytes --]
On Wed, Jul 31, 2019 at 02:17:34PM -0600, Jonathan Corbet wrote:
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> > As promised, this is the rebased version of the patches that were not applied
> > from the /26 patch series because you had merge conflicts.
> >
> > They're all based on your docs-next branch, so should apply fine.
> >
> > The first one fixes all but one error with a broken reference.
> >
> > The only broken reference right now is due to a DT patch with was not
> > accepted (no idea why), but whose driver is upstream.
> All but 5/6 applied, thanks.
Oh, I still hadn't reviewed this version of the SPI stuff :(
There were outstanding questions about where it was going to get moved
to but if I read the diff correctly it looks like it didn't actually get
moved in the end?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 1/6] docs: fix a couple of new broken references
From: Rob Herring @ 2019-07-31 20:21 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel@vger.kernel.org, Jonathan Corbet, Liam Girdwood,
Mark Brown, Mark Rutland, Maxime Ripard, Chen-Yu Tsai,
Mathieu Poirier, Suzuki K Poulose, Alexander Shishkin,
Dave Kleikamp, Evgeniy Dushistov, Linux-ALSA, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
jfs-discussion
In-Reply-To: <5b4fae5978d309641fa8ba233a9efe2b48201cd6.1564603513.git.mchehab+samsung@kernel.org>
On Wed, Jul 31, 2019 at 2:08 PM Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
>
> Those are due to recent changes. Most of the issues
> can be automatically fixed with:
>
> $ ./scripts/documentation-file-ref-check --fix
>
> The only exception was the sound binding with required
> manual work.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt | 2 +-
Acked-by: Rob Herring <robh@kernel.org>
> MAINTAINERS | 4 ++--
> drivers/hwtracing/coresight/Kconfig | 2 +-
> fs/jfs/Kconfig | 2 +-
> fs/ufs/Kconfig | 2 +-
> 5 files changed, 6 insertions(+), 6 deletions(-)
^ permalink raw reply
* Re: [PATCH 5/6] docs: fs: convert porting to ReST
From: Mauro Carvalho Chehab @ 2019-07-31 20:22 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel
In-Reply-To: <20190731141707.6f3d21d7@lwn.net>
Em Wed, 31 Jul 2019 14:17:07 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Wed, 31 Jul 2019 17:08:52 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > This file has its own proper style, except that, after a while,
> > the coding style gets violated and whitespaces are placed on
> > different ways.
> >
> > As Sphinx and ReST are very sentitive to whitespace differences,
> > I had to opt if each entry after required/mandatory/... fields
> > should start with zero spaces or with a tab. I opted to start them
> > all from the zero position, in order to avoid needing to break lines
> > with more than 80 columns, with would make harder for review.
> >
> > Most of the other changes at porting.rst were made to use an unified
> > notation with works nice as a text file while also produce a good html
> > output after being parsed.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > ---
> > Documentation/filesystems/porting.rst | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst
> > index 66aa521e6376..f18506083ced 100644
> > --- a/Documentation/filesystems/porting.rst
> > +++ b/Documentation/filesystems/porting.rst
> > @@ -158,7 +158,7 @@ Callers of notify_change() need ->i_mutex now.
> > New super_block field ``struct export_operations *s_export_op`` for
> > explicit support for exporting, e.g. via NFS. The structure is fully
> > documented at its declaration in include/linux/fs.h, and in
> > -Documentation/filesystems/nfs/Exporting.
> > +Documentation/filesystems/nfs/exporting.rst.
> >
> > Briefly it allows for the definition of decode_fh and encode_fh operations
> > to encode and decode filehandles, and allows the filesystem to use
>
> This patch doesn't match the changelog at all. I think it's one leftover
> fix after the previous version of the patch was applied...?
Gah, sorry. Yeah, you're right: this is just a fixup patch.
>
> jon
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH] tools: memory-model: add it to the Documentation body
From: Paul E. McKenney @ 2019-07-31 20:25 UTC (permalink / raw)
To: Akira Yokosawa
Cc: Alan Stern, Mauro Carvalho Chehab, Joel Fernandes,
Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Andrea Parri, Will Deacon, Peter Zijlstra,
Boqun Feng, Nicholas Piggin, David Howells, Jade Alglave,
Luc Maranget, Daniel Lustig, Ingo Molnar, Jason Gunthorpe,
SeongJae Park, linux-arch
In-Reply-To: <cb9785b7-ed43-b91a-7392-e50216bd5771@gmail.com>
On Thu, Aug 01, 2019 at 12:19:25AM +0900, Akira Yokosawa wrote:
> On Wed, 31 Jul 2019 09:52:05 -0400, Alan Stern wrote:
> > On Tue, 30 Jul 2019, Mauro Carvalho Chehab wrote:
> >
> >> Em Tue, 30 Jul 2019 18:17:01 -0400
> >> Joel Fernandes <joel@joelfernandes.org> escreveu:
> >
> >>>>> (4) I would argue that every occurence of
> >>>>> A ->(some dependency) B should be replaced with fixed size font in the HTML
> >>>>> results.
> >>>>
> >>>> Just place those with ``A -> (some dependency)``. This will make them use
> >>>> a fixed size font.
> >>>
> >>> Ok, understood all these. I guess my point was all of these will need to be
> >>> done to make this document useful from a ReST conversion standpoint. Until
> >>> then it is probably just better off being plain text - since there are so
> >>> many of those ``A -> (dep) B`` things.
> >
> >> On a very quick look, it seems that, if we replace:
> >>
> >> (\S+\s->\S*\s\w+)
> >>
> >> by:
> >> ``\1``
> >>
> >>
> >> On an editor that would allow to manually replace the regex (like kate),
> >> most of those can be get.
> >>
> >> See patch enclosed.
> >
> > Some time ago I considered the problem of converting this file to ReST
> > format. But I gave up on the idea, because the necessary changes were
> > so widespread and the resulting text file would not be easily readable.
> >
> > Replacing things of the form "A ->dep B" just scratches the surface.
> > That document teems with variable names, formulas, code extracts, and
> > other things which would all need to be rendered in a different font
> > style. The density of the markup required to do this would be
> > phenomenally high.
> >
> > In my opinion it simply was not worthwhile.
>
> +1 on keeping this and the other .txt files of LKMM intact.
Looks like a pretty clear consensus thus far. Any objections to keeping
these .txt for the time being?
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 0/6] ReST conversion patches not applied yet
From: Mauro Carvalho Chehab @ 2019-07-31 20:26 UTC (permalink / raw)
To: Mark Brown
Cc: Jonathan Corbet, Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel, alsa-devel, Maxime Ripard, samba-technical,
devicetree, Liam Girdwood, linux-iio, Lars-Peter Clausen,
Evgeniy Dushistov, Jonathan Cameron, Peter Meerwald-Stadler,
Steve French, Alexander Shishkin, Chen-Yu Tsai, Suzuki K Poulose,
linux-cifs, Dave Kleikamp, Mark Rutland, Evgeniy Polyakov,
Mathieu Poirier, Rob Herring, jfs-discussion, linux-arm-kernel,
Hartmut Knaack, linux-spi
In-Reply-To: <20190731202007.GI4369@sirena.org.uk>
Em Wed, 31 Jul 2019 21:20:07 +0100
Mark Brown <broonie@kernel.org> escreveu:
> On Wed, Jul 31, 2019 at 02:17:34PM -0600, Jonathan Corbet wrote:
> > Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > > As promised, this is the rebased version of the patches that were not applied
> > > from the /26 patch series because you had merge conflicts.
> > >
> > > They're all based on your docs-next branch, so should apply fine.
> > >
> > > The first one fixes all but one error with a broken reference.
> > >
> > > The only broken reference right now is due to a DT patch with was not
> > > accepted (no idea why), but whose driver is upstream.
>
> > All but 5/6 applied, thanks.
>
> Oh, I still hadn't reviewed this version of the SPI stuff :(
It is basically the one sent on that /26 patch series, just rebased
on the top of docs-next.
> There were outstanding questions about where it was going to get moved
> to but if I read the diff correctly it looks like it didn't actually get
> moved in the end?
Yeah, it doesn't have the move. My understanding from our discussions
is that we didn't reach a conclusion.
In any case, I can send a separate patch with the move part once
we reach an agreement about what's the best way to proceed (or you
can do it directly, if you prefer so).
Thanks,
Mauro
^ permalink raw reply
* [PATCH] docs: fs: porting.rst: fix a broken reference to another doc
From: Mauro Carvalho Chehab @ 2019-07-31 20:27 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
With all those document shifts, references to documents get
broken.
Fix one such occurrence at porting.rst.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/filesystems/porting.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst
index 66aa521e6376..f18506083ced 100644
--- a/Documentation/filesystems/porting.rst
+++ b/Documentation/filesystems/porting.rst
@@ -158,7 +158,7 @@ Callers of notify_change() need ->i_mutex now.
New super_block field ``struct export_operations *s_export_op`` for
explicit support for exporting, e.g. via NFS. The structure is fully
documented at its declaration in include/linux/fs.h, and in
-Documentation/filesystems/nfs/Exporting.
+Documentation/filesystems/nfs/exporting.rst.
Briefly it allows for the definition of decode_fh and encode_fh operations
to encode and decode filehandles, and allows the filesystem to use
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] of/platform: Add missing const qualifier in of_link_property
From: Saravana Kannan @ 2019-07-31 20:33 UTC (permalink / raw)
To: Nathan Chancellor
Cc: David Collins, Jonathan Corbet,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Frank Rowand, Greg Kroah-Hartman, Android Kernel Team,
Linux Doc Mailing List, LKML, Mark Rutland, Rafael J. Wysocki,
Rob Herring, kbuild test robot
In-Reply-To: <20190731181733.60422-1-natechancellor@gmail.com>
On Wed, Jul 31, 2019 at 11:19 AM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> Clang errors:
>
> drivers/of/platform.c:632:28: error: initializing 'struct
> supplier_bindings *' with an expression of type 'const struct
> supplier_bindings [4]' discards qualifiers
> [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
> struct supplier_bindings *s = bindings;
> ^ ~~~~~~~~
> 1 error generated.
>
> Fixes: 05f812549f53 ("of/platform: Add functional dependency link from DT bindings")
> Reported-by: kbuild test robot <lkp@intel.com>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
>
> Given this is still in the driver-core-testing branch, I am fine with
> this being squashed in if desired.
>
> drivers/of/platform.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index e2da90e53edb..21838226d68a 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -629,7 +629,7 @@ static bool of_link_property(struct device *dev, struct device_node *con_np,
> const char *prop)
> {
> struct device_node *phandle;
> - struct supplier_bindings *s = bindings;
> + const struct supplier_bindings *s = bindings;
> unsigned int i = 0;
> bool done = true, matched = false;
Odd. I never got that email. Thanks for fixing this. I'll squash it
into my patch series since I have a bunch of other kbuild errors about
documentation.
-Saravana
^ permalink raw reply
* Re: [PATCH] of/platform: Add missing const qualifier in of_link_property
From: Nathan Chancellor @ 2019-07-31 20:37 UTC (permalink / raw)
To: Saravana Kannan
Cc: David Collins, Jonathan Corbet,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Frank Rowand, Greg Kroah-Hartman, Android Kernel Team,
Linux Doc Mailing List, LKML, Mark Rutland, Rafael J. Wysocki,
Rob Herring, kbuild test robot
In-Reply-To: <CAGETcx9LXP9b_W_1XQFmjODPJVrbnU+vH1RKer2i=jU7Q7EADg@mail.gmail.com>
On Wed, Jul 31, 2019 at 01:33:40PM -0700, Saravana Kannan wrote:
> On Wed, Jul 31, 2019 at 11:19 AM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > Clang errors:
> >
> > drivers/of/platform.c:632:28: error: initializing 'struct
> > supplier_bindings *' with an expression of type 'const struct
> > supplier_bindings [4]' discards qualifiers
> > [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
> > struct supplier_bindings *s = bindings;
> > ^ ~~~~~~~~
> > 1 error generated.
> >
> > Fixes: 05f812549f53 ("of/platform: Add functional dependency link from DT bindings")
> > Reported-by: kbuild test robot <lkp@intel.com>
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> > ---
> >
> > Given this is still in the driver-core-testing branch, I am fine with
> > this being squashed in if desired.
> >
> > drivers/of/platform.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> > index e2da90e53edb..21838226d68a 100644
> > --- a/drivers/of/platform.c
> > +++ b/drivers/of/platform.c
> > @@ -629,7 +629,7 @@ static bool of_link_property(struct device *dev, struct device_node *con_np,
> > const char *prop)
> > {
> > struct device_node *phandle;
> > - struct supplier_bindings *s = bindings;
> > + const struct supplier_bindings *s = bindings;
> > unsigned int i = 0;
> > bool done = true, matched = false;
>
> Odd. I never got that email. Thanks for fixing this. I'll squash it
> into my patch series since I have a bunch of other kbuild errors about
> documentation.
>
> -Saravana
It was a clang only email (which currently just get sent to our
clang-built-linux mailing list as there is a lot of overlap with GCC).
Not sure why there was no GCC email about this but oh well. Thanks for
picking it up!
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH 0/6] ReST conversion patches not applied yet
From: Mark Brown @ 2019-07-31 20:37 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Jonathan Corbet, Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel, alsa-devel, Maxime Ripard, samba-technical,
devicetree, Liam Girdwood, linux-iio, Lars-Peter Clausen,
Evgeniy Dushistov, Jonathan Cameron, Peter Meerwald-Stadler,
Steve French, Alexander Shishkin, Chen-Yu Tsai, Suzuki K Poulose,
linux-cifs, Dave Kleikamp, Mark Rutland, Evgeniy Polyakov,
Mathieu Poirier, Rob Herring, jfs-discussion, linux-arm-kernel,
Hartmut Knaack, linux-spi
In-Reply-To: <20190731172613.32d65ad8@coco.lan>
[-- Attachment #1: Type: text/plain, Size: 933 bytes --]
On Wed, Jul 31, 2019 at 05:26:13PM -0300, Mauro Carvalho Chehab wrote:
> Mark Brown <broonie@kernel.org> escreveu:
> > There were outstanding questions about where it was going to get moved
> > to but if I read the diff correctly it looks like it didn't actually get
> > moved in the end?
> Yeah, it doesn't have the move. My understanding from our discussions
> is that we didn't reach a conclusion.
Yes, that was my understanding too which was why I was surprised to see
this going in. This is OK then, I'd have acked it.
> In any case, I can send a separate patch with the move part once
> we reach an agreement about what's the best way to proceed (or you
> can do it directly, if you prefer so).
I'm not likely to do anything without someone sending patches, I'm not
clear on the utility of the move with the current division of the
manuals. I don't know if it makes sense to have an embedded developer's
manual as well?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 484 bytes --]
^ permalink raw reply
* Re: [PATCH 1/6] docs: fix a couple of new broken references
From: Dave Kleikamp @ 2019-07-31 20:36 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet,
Liam Girdwood, Mark Brown, Rob Herring, Mark Rutland,
Maxime Ripard, Chen-Yu Tsai, Mathieu Poirier, Suzuki K Poulose,
Alexander Shishkin, Dave Kleikamp, Evgeniy Dushistov, alsa-devel,
devicetree, linux-arm-kernel, jfs-discussion
In-Reply-To: <5b4fae5978d309641fa8ba233a9efe2b48201cd6.1564603513.git.mchehab+samsung@kernel.org>
On 7/31/19 3:08 PM, Mauro Carvalho Chehab wrote:
> Those are due to recent changes. Most of the issues
> can be automatically fixed with:
>
> $ ./scripts/documentation-file-ref-check --fix
>
> The only exception was the sound binding with required
> manual work.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: > Dave Kleikamp <dave.kleikamp@oracle.com>
> ---
> Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt | 2 +-
> MAINTAINERS | 4 ++--
> drivers/hwtracing/coresight/Kconfig | 2 +-
> fs/jfs/Kconfig | 2 +-
> fs/ufs/Kconfig | 2 +-
> 5 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt b/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt
> index 2ca3d138528e..7ecf6bd60d27 100644
> --- a/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt
> +++ b/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt
> @@ -4,7 +4,7 @@ Allwinner SUN8I audio codec
> On Sun8i-A33 SoCs, the audio is separated in different parts:
> - A DAI driver. It uses the "sun4i-i2s" driver which is
> documented here:
> - Documentation/devicetree/bindings/sound/sun4i-i2s.txt
> + Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml
> - An analog part of the codec which is handled as PRCM registers.
> See Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
> - An digital part of the codec which is documented in this current
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6de82f019a52..f109a8bcffda 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8659,7 +8659,7 @@ L: jfs-discussion@lists.sourceforge.net
> W: http://jfs.sourceforge.net/
> T: git git://github.com/kleikamp/linux-shaggy.git
> S: Maintained
> -F: Documentation/filesystems/jfs.txt
> +F: Documentation/admin-guide/jfs.rst
> F: fs/jfs/
>
> JME NETWORK DRIVER
> @@ -16439,7 +16439,7 @@ F: drivers/hid/hid-udraw-ps3.c
> UFS FILESYSTEM
> M: Evgeniy Dushistov <dushistov@mail.ru>
> S: Maintained
> -F: Documentation/filesystems/ufs.txt
> +F: Documentation/admin-guide/ufs.rst
> F: fs/ufs/
>
> UHID USERSPACE HID IO DRIVER:
> diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
> index 14638db4991d..7a9f5fb08330 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -106,7 +106,7 @@ config CORESIGHT_CPU_DEBUG
> can quickly get to know program counter (PC), secure state,
> exception level, etc. Before use debugging functionality, platform
> needs to ensure the clock domain and power domain are enabled
> - properly, please refer Documentation/trace/coresight-cpu-debug.txt
> + properly, please refer Documentation/trace/coresight-cpu-debug.rst
> for detailed description and the example for usage.
>
> endif
> diff --git a/fs/jfs/Kconfig b/fs/jfs/Kconfig
> index 22a273bd4648..05cb0e8e4382 100644
> --- a/fs/jfs/Kconfig
> +++ b/fs/jfs/Kconfig
> @@ -5,7 +5,7 @@ config JFS_FS
> select CRC32
> help
> This is a port of IBM's Journaled Filesystem . More information is
> - available in the file <file:Documentation/filesystems/jfs.txt>.
> + available in the file <file:Documentation/admin-guide/jfs.rst>.
>
> If you do not intend to use the JFS filesystem, say N.
>
> diff --git a/fs/ufs/Kconfig b/fs/ufs/Kconfig
> index fcb41516ea59..6d30adb6b890 100644
> --- a/fs/ufs/Kconfig
> +++ b/fs/ufs/Kconfig
> @@ -9,7 +9,7 @@ config UFS_FS
> this file system as well. Saying Y here will allow you to read from
> these partitions; if you also want to write to them, say Y to the
> experimental "UFS file system write support", below. Please read the
> - file <file:Documentation/filesystems/ufs.txt> for more information.
> + file <file:Documentation/admin-guide/ufs.rst> for more information.
>
> The recently released UFS2 variant (used in FreeBSD 5.x) is
> READ-ONLY supported.
>
^ permalink raw reply
* Re: [PATCH 2/6] docs: writing-schema.md: convert from markdown to ReST
From: Rob Herring @ 2019-07-31 20:45 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Mark Rutland, devicetree
In-Reply-To: <a239cd93ad86579ce7e02bc3032abd33b476e193.1564603513.git.mchehab+samsung@kernel.org>
On Wed, Jul 31, 2019 at 05:08:49PM -0300, Mauro Carvalho Chehab wrote:
> The documentation standard is ReST and not markdown.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/writing-schema.md | 130 -----------------
> Documentation/devicetree/writing-schema.rst | 153 ++++++++++++++++++++
> 2 files changed, 153 insertions(+), 130 deletions(-)
> delete mode 100644 Documentation/devicetree/writing-schema.md
> create mode 100644 Documentation/devicetree/writing-schema.rst
Applied, thanks.
Rob
^ permalink raw reply
* Re: [PATCH 2/6] docs: writing-schema.md: convert from markdown to ReST
From: Jonathan Corbet @ 2019-07-31 20:48 UTC (permalink / raw)
To: Rob Herring
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, linux-kernel, Mark Rutland, devicetree
In-Reply-To: <20190731204500.GA6131@bogus>
On Wed, 31 Jul 2019 14:45:00 -0600
Rob Herring <robh@kernel.org> wrote:
> On Wed, Jul 31, 2019 at 05:08:49PM -0300, Mauro Carvalho Chehab wrote:
> > The documentation standard is ReST and not markdown.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > Acked-by: Rob Herring <robh@kernel.org>
> > ---
> > Documentation/devicetree/writing-schema.md | 130 -----------------
> > Documentation/devicetree/writing-schema.rst | 153 ++++++++++++++++++++
> > 2 files changed, 153 insertions(+), 130 deletions(-)
> > delete mode 100644 Documentation/devicetree/writing-schema.md
> > create mode 100644 Documentation/devicetree/writing-schema.rst
>
> Applied, thanks.
I've applied that to docs-next as well - your ack suggested to me that you
weren't intending to take it...
jon
^ permalink raw reply
* Re: [PATCH 0/6] ReST conversion patches not applied yet
From: Mauro Carvalho Chehab @ 2019-07-31 21:27 UTC (permalink / raw)
To: Mark Brown
Cc: Jonathan Corbet, Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel, alsa-devel, Maxime Ripard, samba-technical,
devicetree, Liam Girdwood, linux-iio, Lars-Peter Clausen,
Evgeniy Dushistov, Jonathan Cameron, Peter Meerwald-Stadler,
Steve French, Alexander Shishkin, Chen-Yu Tsai, Suzuki K Poulose,
linux-cifs, Dave Kleikamp, Mark Rutland, Evgeniy Polyakov,
Mathieu Poirier, Rob Herring, jfs-discussion, linux-arm-kernel,
Hartmut Knaack, linux-spi
In-Reply-To: <20190731203712.GJ4369@sirena.org.uk>
Em Wed, 31 Jul 2019 21:37:12 +0100
Mark Brown <broonie@kernel.org> escreveu:
> On Wed, Jul 31, 2019 at 05:26:13PM -0300, Mauro Carvalho Chehab wrote:
> > Mark Brown <broonie@kernel.org> escreveu:
>
> > > There were outstanding questions about where it was going to get moved
> > > to but if I read the diff correctly it looks like it didn't actually get
> > > moved in the end?
>
> > Yeah, it doesn't have the move. My understanding from our discussions
> > is that we didn't reach a conclusion.
>
> Yes, that was my understanding too which was why I was surprised to see
> this going in. This is OK then, I'd have acked it.
>
> > In any case, I can send a separate patch with the move part once
> > we reach an agreement about what's the best way to proceed (or you
> > can do it directly, if you prefer so).
>
> I'm not likely to do anything without someone sending patches, I'm not
> clear on the utility of the move with the current division of the
> manuals.
Same here: I do see value on having docs focused on their audience.
Yet, I'm not so sure how worth is to break some subsystem documentation
into books, as, on some cases, this would mean huge efforts.
I'd prefer to see the big picture first, finishing the conversion and
then looking at the resulting docs.
Meanwhile, if someone needs something that it is at the wrong book, he
can just use some search tool to seek what he needs, no matter on
what book the relevant information is stored.
> I don't know if it makes sense to have an embedded developer's
> manual as well?
Yeah, that's a good question.
Jon is planning todo a documentation track at LPC. One of the things
that should be discussed, IMO, is how we'll organize the books.
I suspect that, once we finish the conversion of the remaining ~300
files to ReST, the next logical step is to check what are the gaps
and have a list of pending tasks.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH 2/6] docs: writing-schema.md: convert from markdown to ReST
From: Rob Herring @ 2019-07-31 21:30 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, linux-kernel@vger.kernel.org, Mark Rutland,
devicetree
In-Reply-To: <20190731144816.71238678@lwn.net>
On Wed, Jul 31, 2019 at 2:48 PM Jonathan Corbet <corbet@lwn.net> wrote:
>
> On Wed, 31 Jul 2019 14:45:00 -0600
> Rob Herring <robh@kernel.org> wrote:
>
> > On Wed, Jul 31, 2019 at 05:08:49PM -0300, Mauro Carvalho Chehab wrote:
> > > The documentation standard is ReST and not markdown.
> > >
> > > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > > Acked-by: Rob Herring <robh@kernel.org>
> > > ---
> > > Documentation/devicetree/writing-schema.md | 130 -----------------
> > > Documentation/devicetree/writing-schema.rst | 153 ++++++++++++++++++++
> > > 2 files changed, 153 insertions(+), 130 deletions(-)
> > > delete mode 100644 Documentation/devicetree/writing-schema.md
> > > create mode 100644 Documentation/devicetree/writing-schema.rst
> >
> > Applied, thanks.
>
> I've applied that to docs-next as well - your ack suggested to me that you
> weren't intending to take it...
Well, I acked it first when it was in one big patch, then suggested it
be split out in case we have changes to it (wishful thinking).
Rob
^ permalink raw reply
* Re: [PATCH 0/6] ReST conversion patches not applied yet
From: Mark Brown @ 2019-07-31 21:55 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Jonathan Corbet, Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel, alsa-devel, Maxime Ripard, samba-technical,
devicetree, Liam Girdwood, linux-iio, Lars-Peter Clausen,
Evgeniy Dushistov, Jonathan Cameron, Peter Meerwald-Stadler,
Steve French, Alexander Shishkin, Chen-Yu Tsai, Suzuki K Poulose,
linux-cifs, Dave Kleikamp, Mark Rutland, Evgeniy Polyakov,
Mathieu Poirier, Rob Herring, jfs-discussion, linux-arm-kernel,
Hartmut Knaack, linux-spi
In-Reply-To: <20190731182729.01c98cd3@coco.lan>
[-- Attachment #1: Type: text/plain, Size: 725 bytes --]
On Wed, Jul 31, 2019 at 06:27:29PM -0300, Mauro Carvalho Chehab wrote:
> Meanwhile, if someone needs something that it is at the wrong book, he
> can just use some search tool to seek what he needs, no matter on
> what book the relevant information is stored.
OTOH it might be weird for the intended audience of the book.
> Mark Brown <broonie@kernel.org> escreveu:
> > I don't know if it makes sense to have an embedded developer's
> > manual as well?
> Yeah, that's a good question.
> Jon is planning todo a documentation track at LPC. One of the things
> that should be discussed, IMO, is how we'll organize the books.
I'll be at Plumbers, not sure what the schedule's looking like yet
though.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v9 3/7] of/platform: Add functional dependency link from DT bindings
From: Saravana Kannan @ 2019-07-31 22:17 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Rafael J. Wysocki,
Frank Rowand, Jonathan Corbet
Cc: Saravana Kannan, devicetree, linux-kernel, David Collins,
kernel-team, kbuild test robot, linux-doc, clang-built-linux
In-Reply-To: <20190731221721.187713-1-saravanak@google.com>
Add device-links after the devices are created (but before they are
probed) by looking at common DT bindings like clocks and
interconnects.
Automatically adding device-links for functional dependencies at the
framework level provides the following benefits:
- Optimizes device probe order and avoids the useless work of
attempting probes of devices that will not probe successfully
(because their suppliers aren't present or haven't probed yet).
For example, in a commonly available mobile SoC, registering just
one consumer device's driver at an initcall level earlier than the
supplier device's driver causes 11 failed probe attempts before the
consumer device probes successfully. This was with a kernel with all
the drivers statically compiled in. This problem gets a lot worse if
all the drivers are loaded as modules without direct symbol
dependencies.
- Supplier devices like clock providers, interconnect providers, etc
need to keep the resources they provide active and at a particular
state(s) during boot up even if their current set of consumers don't
request the resource to be active. This is because the rest of the
consumers might not have probed yet and turning off the resource
before all the consumers have probed could lead to a hang or
undesired user experience.
Some frameworks (Eg: regulator) handle this today by turning off
"unused" resources at late_initcall_sync and hoping all the devices
have probed by then. This is not a valid assumption for systems with
loadable modules. Other frameworks (Eg: clock) just don't handle
this due to the lack of a clear signal for when they can turn off
resources. This leads to downstream hacks to handle cases like this
that can easily be solved in the upstream kernel.
By linking devices before they are probed, we give suppliers a clear
count of the number of dependent consumers. Once all of the
consumers are active, the suppliers can turn off the unused
resources without making assumptions about the number of consumers.
By default we just add device-links to track "driver presence" (probe
succeeded) of the supplier device. If any other functionality provided
by device-links are needed, it is left to the consumer/supplier
devices to change the link when they probe.
kbuild test robot reported clang error about missing const
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
---
.../admin-guide/kernel-parameters.txt | 5 +
drivers/of/platform.c | 165 ++++++++++++++++++
2 files changed, 170 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 7ccd158b3894..dba3200d3516 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3170,6 +3170,11 @@
This can be set from sysctl after boot.
See Documentation/admin-guide/sysctl/vm.rst for details.
+ of_devlink [KNL] Make device links from common DT bindings. Useful
+ for optimizing probe order and making sure resources
+ aren't turned off before the consumer devices have
+ probed.
+
ohci1394_dma=early [HW] enable debugging via the ohci1394 driver.
See Documentation/debugging-via-ohci1394.txt for more
info.
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 7801e25e6895..64c4b91988f2 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -508,6 +508,170 @@ int of_platform_default_populate(struct device_node *root,
}
EXPORT_SYMBOL_GPL(of_platform_default_populate);
+bool of_link_is_valid(struct device_node *con, struct device_node *sup)
+{
+ of_node_get(sup);
+ /*
+ * Don't allow linking a device node as a consumer of one of its
+ * descendant nodes. By definition, a child node can't be a functional
+ * dependency for the parent node.
+ */
+ while (sup) {
+ if (sup == con) {
+ of_node_put(sup);
+ return false;
+ }
+ sup = of_get_next_parent(sup);
+ }
+ return true;
+}
+
+static int of_link_to_phandle(struct device *dev, struct device_node *sup_np)
+{
+ struct platform_device *sup_dev;
+ u32 dl_flags = DL_FLAG_AUTOPROBE_CONSUMER;
+ int ret = 0;
+
+ /*
+ * Since we are trying to create device links, we need to find
+ * the actual device node that owns this supplier phandle.
+ * Often times it's the same node, but sometimes it can be one
+ * of the parents. So walk up the parent till you find a
+ * device.
+ */
+ while (sup_np && !of_find_property(sup_np, "compatible", NULL))
+ sup_np = of_get_next_parent(sup_np);
+ if (!sup_np)
+ return 0;
+
+ if (!of_link_is_valid(dev->of_node, sup_np)) {
+ of_node_put(sup_np);
+ return 0;
+ }
+ sup_dev = of_find_device_by_node(sup_np);
+ of_node_put(sup_np);
+ if (!sup_dev)
+ return -ENODEV;
+ if (!device_link_add(dev, &sup_dev->dev, dl_flags))
+ ret = -ENODEV;
+ put_device(&sup_dev->dev);
+ return ret;
+}
+
+static struct device_node *parse_prop_cells(struct device_node *np,
+ const char *prop, int index,
+ const char *binding,
+ const char *cell)
+{
+ struct of_phandle_args sup_args;
+
+ /* Don't need to check property name for every index. */
+ if (!index && strcmp(prop, binding))
+ return NULL;
+
+ if (of_parse_phandle_with_args(np, binding, cell, index, &sup_args))
+ return NULL;
+
+ return sup_args.np;
+}
+
+static struct device_node *parse_clocks(struct device_node *np,
+ const char *prop, int index)
+{
+ return parse_prop_cells(np, prop, index, "clocks", "#clock-cells");
+}
+
+static struct device_node *parse_interconnects(struct device_node *np,
+ const char *prop, int index)
+{
+ return parse_prop_cells(np, prop, index, "interconnects",
+ "#interconnect-cells");
+}
+
+static int strcmp_suffix(const char *str, const char *suffix)
+{
+ unsigned int len, suffix_len;
+
+ len = strlen(str);
+ suffix_len = strlen(suffix);
+ if (len <= suffix_len)
+ return -1;
+ return strcmp(str + len - suffix_len, suffix);
+}
+
+static struct device_node *parse_regulators(struct device_node *np,
+ const char *prop, int index)
+{
+ if (index || strcmp_suffix(prop, "-supply"))
+ return NULL;
+
+ return of_parse_phandle(np, prop, 0);
+}
+
+/**
+ * struct supplier_bindings - Information for parsing supplier DT binding
+ *
+ * @parse_prop: If the function cannot parse the property, return NULL.
+ * Otherwise, return the phandle listed in the property
+ * that corresponds to the index.
+ */
+struct supplier_bindings {
+ struct device_node *(*parse_prop)(struct device_node *np,
+ const char *name, int index);
+};
+
+static const struct supplier_bindings bindings[] = {
+ { .parse_prop = parse_clocks, },
+ { .parse_prop = parse_interconnects, },
+ { .parse_prop = parse_regulators, },
+ { },
+};
+
+static bool of_link_property(struct device *dev, struct device_node *con_np,
+ const char *prop)
+{
+ struct device_node *phandle;
+ const struct supplier_bindings *s = bindings;
+ unsigned int i = 0;
+ bool done = true, matched = false;
+
+ while (!matched && s->parse_prop) {
+ while ((phandle = s->parse_prop(con_np, prop, i))) {
+ matched = true;
+ i++;
+ if (of_link_to_phandle(dev, phandle))
+ /*
+ * Don't stop at the first failure. See
+ * Documentation for bus_type.add_links for
+ * more details.
+ */
+ done = false;
+ }
+ s++;
+ }
+ return done ? 0 : -ENODEV;
+}
+
+static bool of_devlink;
+core_param(of_devlink, of_devlink, bool, 0);
+
+static int of_link_to_suppliers(struct device *dev)
+{
+ struct property *p;
+ bool done = true;
+
+ if (!of_devlink)
+ return 0;
+ if (unlikely(!dev->of_node))
+ return 0;
+
+ for_each_property_of_node(dev->of_node, p)
+ if (of_link_property(dev, dev->of_node, p->name))
+ done = false;
+
+ return done ? 0 : -ENODEV;
+}
+
#ifndef CONFIG_PPC
static const struct of_device_id reserved_mem_matches[] = {
{ .compatible = "qcom,rmtfs-mem" },
@@ -523,6 +687,7 @@ static int __init of_platform_default_populate_init(void)
if (!of_have_populated_dt())
return -ENODEV;
+ platform_bus_type.add_links = of_link_to_suppliers;
/*
* Handle certain compatibles explicitly, since we don't want to create
* platform_devices for every node in /reserved-memory with a
--
2.22.0.709.g102302147b-goog
^ permalink raw reply related
* Re: [PATCH v4 3/3] f2fs: Support case-insensitive file name lookups
From: Chao Yu @ 2019-08-01 1:11 UTC (permalink / raw)
To: Nathan Chancellor, Daniel Rosenberg
Cc: Jaegeuk Kim, Jonathan Corbet, linux-f2fs-devel, linux-kernel,
linux-doc, linux-fsdevel, linux-api, kernel-team
In-Reply-To: <20190731175748.GA48637@archlinux-threadripper>
Hi Nathan,
Thanks for the report! :)
On 2019/8/1 1:57, Nathan Chancellor wrote:
> Hi all,
>
> <snip>
>
>> diff --git a/fs/f2fs/hash.c b/fs/f2fs/hash.c
>> index cc82f142f811f..99e79934f5088 100644
>> --- a/fs/f2fs/hash.c
>> +++ b/fs/f2fs/hash.c
>> @@ -14,6 +14,7 @@
>> #include <linux/f2fs_fs.h>
>> #include <linux/cryptohash.h>
>> #include <linux/pagemap.h>
>> +#include <linux/unicode.h>
>>
>> #include "f2fs.h"
>>
>> @@ -67,7 +68,7 @@ static void str2hashbuf(const unsigned char *msg, size_t len,
>> *buf++ = pad;
>> }
>>
>> -f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
>> +static f2fs_hash_t __f2fs_dentry_hash(const struct qstr *name_info,
>> struct fscrypt_name *fname)
>> {
>> __u32 hash;
>> @@ -103,3 +104,35 @@ f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
>> f2fs_hash = cpu_to_le32(hash & ~F2FS_HASH_COL_BIT);
>> return f2fs_hash;
>> }
>> +
>> +f2fs_hash_t f2fs_dentry_hash(const struct inode *dir,
>> + const struct qstr *name_info, struct fscrypt_name *fname)
>> +{
>> +#ifdef CONFIG_UNICODE
>> + struct f2fs_sb_info *sbi = F2FS_SB(dir->i_sb);
>> + const struct unicode_map *um = sbi->s_encoding;
>> + int r, dlen;
>> + unsigned char *buff;
>> + struct qstr *folded;
>> +
>> + if (name_info->len && IS_CASEFOLDED(dir)) {
>> + buff = f2fs_kzalloc(sbi, sizeof(char) * PATH_MAX, GFP_KERNEL);
>> + if (!buff)
>> + return -ENOMEM;
>> +
>> + dlen = utf8_casefold(um, name_info, buff, PATH_MAX);
>> + if (dlen < 0) {
>> + kvfree(buff);
>> + goto opaque_seq;
>> + }
>> + folded->name = buff;
>> + folded->len = dlen;
>> + r = __f2fs_dentry_hash(folded, fname);
>> +
>> + kvfree(buff);
>> + return r;
>> + }
>> +opaque_seq:
>> +#endif
>> + return __f2fs_dentry_hash(name_info, fname);
>> +}
>
> Clang now warns:
>
> fs/f2fs/hash.c:128:3: warning: variable 'folded' is uninitialized when used here [-Wuninitialized]
> folded->name = buff;
> ^~~~~~
> fs/f2fs/hash.c:116:21: note: initialize the variable 'folded' to silence this warning
> struct qstr *folded;
> ^
> = NULL
> 1 warning generated.
>
> I assume that it wants to be initialized with f2fs_kzalloc as well but
> I am not familiar with this code and what it expects to do.
>
> Please look into this when you get a chance!
That should be a bug, it needs to define a struct qstr type variable rather than
a pointer there.
Jaegeuk, could you fix this in you branch?
Thanks,
> Nathan
> .
>
^ permalink raw reply
* [PATCH] mailmap: add entry for Gao Xiang
From: Chao Yu @ 2019-08-01 3:17 UTC (permalink / raw)
To: corbet; +Cc: linux-doc, gaoxiang25, chao, Chao Yu
Add entry to connect all Gao Xiang's email addresses.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
---
.mailmap | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.mailmap b/.mailmap
index 4ff3f20b4f11..00588c37e99d 100644
--- a/.mailmap
+++ b/.mailmap
@@ -79,6 +79,8 @@ Frank Rowand <frowand.list@gmail.com> <frowand@mvista.com>
Frank Rowand <frowand.list@gmail.com> <frank.rowand@am.sony.com>
Frank Rowand <frowand.list@gmail.com> <frank.rowand@sonymobile.com>
Frank Zago <fzago@systemfabricworks.com>
+Gao Xiang <xiang@kernel.org> <gaoxiang25@huawei.com>
+Gao Xiang <xiang@kernel.org> <hsiangkao@aol.com>
Greg Kroah-Hartman <greg@echidna.(none)>
Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman <greg@kroah.com>
--
2.18.0.rc1
^ permalink raw reply related
* Re: [PATCH] mailmap: add entry for Gao Xiang
From: Gao Xiang @ 2019-08-01 3:31 UTC (permalink / raw)
To: Chao Yu, corbet; +Cc: linux-doc, chao, Miao Xie
In-Reply-To: <20190801031750.17094-1-yuchao0@huawei.com>
On 2019/8/1 11:17, Chao Yu wrote:
> Add entry to connect all Gao Xiang's email addresses.
>
> Signed-off-by: Chao Yu <yuchao0@huawei.com>
Acked-by: Gao Xiang <gaoxiang25@huawei.com>
Thanks,
Gao Xiang
^ permalink raw reply
* Re: [PATCH v4 3/3] f2fs: Support case-insensitive file name lookups
From: Jaegeuk Kim @ 2019-08-01 4:05 UTC (permalink / raw)
To: Chao Yu
Cc: Nathan Chancellor, Daniel Rosenberg, Jonathan Corbet,
linux-f2fs-devel, linux-kernel, linux-doc, linux-fsdevel,
linux-api, kernel-team
In-Reply-To: <5d6c5da8-ad1e-26e2-0a3d-84949cd4e9aa@huawei.com>
On 08/01, Chao Yu wrote:
> Hi Nathan,
>
> Thanks for the report! :)
>
> On 2019/8/1 1:57, Nathan Chancellor wrote:
> > Hi all,
> >
> > <snip>
> >
> >> diff --git a/fs/f2fs/hash.c b/fs/f2fs/hash.c
> >> index cc82f142f811f..99e79934f5088 100644
> >> --- a/fs/f2fs/hash.c
> >> +++ b/fs/f2fs/hash.c
> >> @@ -14,6 +14,7 @@
> >> #include <linux/f2fs_fs.h>
> >> #include <linux/cryptohash.h>
> >> #include <linux/pagemap.h>
> >> +#include <linux/unicode.h>
> >>
> >> #include "f2fs.h"
> >>
> >> @@ -67,7 +68,7 @@ static void str2hashbuf(const unsigned char *msg, size_t len,
> >> *buf++ = pad;
> >> }
> >>
> >> -f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
> >> +static f2fs_hash_t __f2fs_dentry_hash(const struct qstr *name_info,
> >> struct fscrypt_name *fname)
> >> {
> >> __u32 hash;
> >> @@ -103,3 +104,35 @@ f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
> >> f2fs_hash = cpu_to_le32(hash & ~F2FS_HASH_COL_BIT);
> >> return f2fs_hash;
> >> }
> >> +
> >> +f2fs_hash_t f2fs_dentry_hash(const struct inode *dir,
> >> + const struct qstr *name_info, struct fscrypt_name *fname)
> >> +{
> >> +#ifdef CONFIG_UNICODE
> >> + struct f2fs_sb_info *sbi = F2FS_SB(dir->i_sb);
> >> + const struct unicode_map *um = sbi->s_encoding;
> >> + int r, dlen;
> >> + unsigned char *buff;
> >> + struct qstr *folded;
> >> +
> >> + if (name_info->len && IS_CASEFOLDED(dir)) {
> >> + buff = f2fs_kzalloc(sbi, sizeof(char) * PATH_MAX, GFP_KERNEL);
> >> + if (!buff)
> >> + return -ENOMEM;
> >> +
> >> + dlen = utf8_casefold(um, name_info, buff, PATH_MAX);
> >> + if (dlen < 0) {
> >> + kvfree(buff);
> >> + goto opaque_seq;
> >> + }
> >> + folded->name = buff;
> >> + folded->len = dlen;
> >> + r = __f2fs_dentry_hash(folded, fname);
> >> +
> >> + kvfree(buff);
> >> + return r;
> >> + }
> >> +opaque_seq:
> >> +#endif
> >> + return __f2fs_dentry_hash(name_info, fname);
> >> +}
> >
> > Clang now warns:
> >
> > fs/f2fs/hash.c:128:3: warning: variable 'folded' is uninitialized when used here [-Wuninitialized]
> > folded->name = buff;
> > ^~~~~~
> > fs/f2fs/hash.c:116:21: note: initialize the variable 'folded' to silence this warning
> > struct qstr *folded;
> > ^
> > = NULL
> > 1 warning generated.
> >
> > I assume that it wants to be initialized with f2fs_kzalloc as well but
> > I am not familiar with this code and what it expects to do.
> >
> > Please look into this when you get a chance!
>
> That should be a bug, it needs to define a struct qstr type variable rather than
> a pointer there.
>
> Jaegeuk, could you fix this in you branch?
Yeah, let me apply this.
--- a/fs/f2fs/hash.c
+++ b/fs/f2fs/hash.c
@@ -113,25 +113,27 @@ f2fs_hash_t f2fs_dentry_hash(const struct inode *dir,
const struct unicode_map *um = sbi->s_encoding;
int r, dlen;
unsigned char *buff;
- struct qstr *folded;
+ struct qstr folded;
- if (name_info->len && IS_CASEFOLDED(dir)) {
- buff = f2fs_kzalloc(sbi, sizeof(char) * PATH_MAX, GFP_KERNEL);
- if (!buff)
- return -ENOMEM;
+ if (!name_info->len || !IS_CASEFOLDED(dir))
+ goto opaque_seq;
- dlen = utf8_casefold(um, name_info, buff, PATH_MAX);
- if (dlen < 0) {
- kvfree(buff);
- goto opaque_seq;
- }
- folded->name = buff;
- folded->len = dlen;
- r = __f2fs_dentry_hash(folded, fname);
+ buff = f2fs_kzalloc(sbi, sizeof(char) * PATH_MAX, GFP_KERNEL);
+ if (!buff)
+ return -ENOMEM;
+ dlen = utf8_casefold(um, name_info, buff, PATH_MAX);
+ if (dlen < 0) {
kvfree(buff);
- return r;
+ goto opaque_seq;
}
+ folded.name = buff;
+ folded.len = dlen;
+ r = __f2fs_dentry_hash(&folded, fname);
+
+ kvfree(buff);
+ return r;
+
opaque_seq:
#endif
return __f2fs_dentry_hash(name_info, fname);
^ permalink raw reply
* Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Janne Karhunen @ 2019-08-01 6:21 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, Jens Wiklander,
Jonathan Corbet, dhowells, jejb, Jarkko Sakkinen, Mimi Zohar,
James Morris, Serge E. Hallyn, Casey Schaufler, Ard Biesheuvel,
Daniel Thompson, Linux Doc Mailing List,
Linux Kernel Mailing List, linux-arm-kernel,
tee-dev @ lists . linaro . org
In-Reply-To: <CAFA6WYOEqe1a1DCyVYKA+oZaZ0n5hnjxdubstUnrwdUW1-4xHw@mail.gmail.com>
On Wed, Jul 31, 2019 at 4:58 PM Sumit Garg <sumit.garg@linaro.org> wrote:
> > To clarify a bit further - my thought was to support any type of trust
> > source.
>
> That could be very well accomplished via Trusted Keys abstraction
> framework [1]. A trust source just need to implement following APIs:
>
> struct trusted_key_ops ts_trusted_key_ops = {
> .migratable = 0, /* non-migratable */
> .init = init_ts_trusted,
> .seal = ts_key_seal,
> .unseal = ts_key_unseal,
> .get_random = ts_get_random,
> .cleanup = cleanup_ts_trusted,
> };
Which is basically the same as implementing a new keytype in the
kernel; abstraction is not raised in any considerable manner this way?
I chose the userspace plugin due to this, you can use userspace aids
to provide any type of service. Use the crypto library you desire to
do the magic you want.
> > With the
> > user mode helper in between anyone can easily add their own thing in
> > there.
>
> Isn't actual purpose to have trusted keys is to protect user-space
> from access to kernel keys in plain format? Doesn't user mode helper
> defeat that purpose in one way or another?
Not really. CPU is in the user mode while running the code, but the
code or the secure keydata being is not available to the 'normal'
userspace. It's like microkernel service/driver this way. The usermode
driver is part of the kernel image and it runs on top of a invisible
rootfs.
--
Janne
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox