From e9bb627561535dd584b43a8c0afe93a67bc6a2c5 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 31 Jul 2019 17:08:53 -0300 Subject: docs: w1: convert to ReST and add to the kAPI group of docs 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 Signed-off-by: Jonathan Corbet --- Documentation/w1/index.rst | 21 ++++ Documentation/w1/masters/ds2482 | 31 ----- Documentation/w1/masters/ds2482.rst | 39 +++++++ Documentation/w1/masters/ds2490 | 68 ----------- Documentation/w1/masters/ds2490.rst | 72 ++++++++++++ Documentation/w1/masters/index.rst | 14 +++ Documentation/w1/masters/mxc-w1 | 12 -- Documentation/w1/masters/mxc-w1.rst | 17 +++ Documentation/w1/masters/omap-hdq | 52 --------- Documentation/w1/masters/omap-hdq.rst | 54 +++++++++ Documentation/w1/masters/w1-gpio | 44 ------- Documentation/w1/masters/w1-gpio.rst | 47 ++++++++ Documentation/w1/slaves/index.rst | 16 +++ Documentation/w1/slaves/w1_ds2406 | 25 ---- Documentation/w1/slaves/w1_ds2406.rst | 27 +++++ Documentation/w1/slaves/w1_ds2413 | 50 -------- Documentation/w1/slaves/w1_ds2413.rst | 59 ++++++++++ Documentation/w1/slaves/w1_ds2423 | 47 -------- Documentation/w1/slaves/w1_ds2423.rst | 54 +++++++++ Documentation/w1/slaves/w1_ds2438 | 63 ---------- Documentation/w1/slaves/w1_ds2438.rst | 69 +++++++++++ Documentation/w1/slaves/w1_ds28e04 | 36 ------ Documentation/w1/slaves/w1_ds28e04.rst | 41 +++++++ Documentation/w1/slaves/w1_ds28e17 | 68 ----------- Documentation/w1/slaves/w1_ds28e17.rst | 72 ++++++++++++ Documentation/w1/slaves/w1_therm | 67 ----------- Documentation/w1/slaves/w1_therm.rst | 74 ++++++++++++ Documentation/w1/w1-generic.rst | 133 ++++++++++++++++++++++ Documentation/w1/w1-netlink.rst | 202 +++++++++++++++++++++++++++++++++ Documentation/w1/w1.generic | 121 -------------------- Documentation/w1/w1.netlink | 189 ------------------------------ 31 files changed, 1011 insertions(+), 873 deletions(-) create mode 100644 Documentation/w1/index.rst delete mode 100644 Documentation/w1/masters/ds2482 create mode 100644 Documentation/w1/masters/ds2482.rst delete mode 100644 Documentation/w1/masters/ds2490 create mode 100644 Documentation/w1/masters/ds2490.rst 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 delete mode 100644 Documentation/w1/masters/omap-hdq create mode 100644 Documentation/w1/masters/omap-hdq.rst delete mode 100644 Documentation/w1/masters/w1-gpio create mode 100644 Documentation/w1/masters/w1-gpio.rst create mode 100644 Documentation/w1/slaves/index.rst delete mode 100644 Documentation/w1/slaves/w1_ds2406 create mode 100644 Documentation/w1/slaves/w1_ds2406.rst delete mode 100644 Documentation/w1/slaves/w1_ds2413 create mode 100644 Documentation/w1/slaves/w1_ds2413.rst delete mode 100644 Documentation/w1/slaves/w1_ds2423 create mode 100644 Documentation/w1/slaves/w1_ds2423.rst delete mode 100644 Documentation/w1/slaves/w1_ds2438 create mode 100644 Documentation/w1/slaves/w1_ds2438.rst delete mode 100644 Documentation/w1/slaves/w1_ds28e04 create mode 100644 Documentation/w1/slaves/w1_ds28e04.rst delete mode 100644 Documentation/w1/slaves/w1_ds28e17 create mode 100644 Documentation/w1/slaves/w1_ds28e17.rst delete mode 100644 Documentation/w1/slaves/w1_therm create mode 100644 Documentation/w1/slaves/w1_therm.rst create mode 100644 Documentation/w1/w1-generic.rst create mode 100644 Documentation/w1/w1-netlink.rst delete mode 100644 Documentation/w1/w1.generic delete mode 100644 Documentation/w1/w1.netlink (limited to 'Documentation/w1') 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 deleted file mode 100644 index 56f8edace6ac..000000000000 --- a/Documentation/w1/masters/ds2482 +++ /dev/null @@ -1,31 +0,0 @@ -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 - -Author: Ben Gardner - - -Description ------------ - -The Maxim/Dallas Semiconductor DS2482 is a I2C device that provides -one (DS2482-100) or eight (DS2482-800) 1-wire busses. - - -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 - diff --git a/Documentation/w1/masters/ds2482.rst b/Documentation/w1/masters/ds2482.rst new file mode 100644 index 000000000000..17ebe8f660cd --- /dev/null +++ b/Documentation/w1/masters/ds2482.rst @@ -0,0 +1,39 @@ +==================== +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 + +Author: Ben Gardner + + +Description +----------- + +The Maxim/Dallas Semiconductor DS2482 is a I2C device that provides +one (DS2482-100) or eight (DS2482-800) 1-wire busses. + + +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 diff --git a/Documentation/w1/masters/ds2490 b/Documentation/w1/masters/ds2490 deleted file mode 100644 index 3e091151dd80..000000000000 --- a/Documentation/w1/masters/ds2490 +++ /dev/null @@ -1,68 +0,0 @@ -Kernel driver ds2490 -==================== - -Supported chips: - * Maxim DS2490 based - -Author: Evgeniy Polyakov - - -Description ------------ - -The Maxim/Dallas Semiconductor DS2490 is a chip -which allows to build USB <-> W1 bridges. - -DS9490(R) is a USB <-> W1 bus master device -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) -- The hardware will detect when devices are attached to the bus on the - next bus (reset?) operation, however only a message is printed as - the core w1 code doesn't make use of the information. Connecting - one device tends to give multiple new device notifications. -- The number of USB bus transactions could be reduced if w1_reset_send - was added to the API. The name is just a suggestion. It would take - a write buffer and a read buffer (along with sizes) as arguments. - The ds2490 block I/O command supports reset, write buffer, read - buffer, and strong pullup all in one command, instead of the current - 1 reset bus, 2 write the match rom command and slave rom id, 3 block - write and read data. The write buffer needs to have the match rom - command and slave rom id prepended to the front of the requested - write buffer, both of which are known to the driver. -- The hardware supports normal, flexible, and overdrive bus - communication speeds, but only the normal is supported. -- The registered w1_bus_master functions don't define error - conditions. If a bus search is in progress and the ds2490 is - removed it can produce a good amount of error output before the bus - search finishes. -- The hardware supports detecting some error conditions, such as - short, alarming presence on reset, and no presence on reset, but the - driver doesn't query those values. -- The ds2490 specification doesn't cover short bulk in reads in - detail, but my observation is if fewer bytes are requested than are - available, the bulk read will return an error and the hardware will - clear the entire bulk in buffer. It would be possible to read the - maximum buffer size to not run into this error condition, only extra - bytes in the buffer is a logic error in the driver. The code should - should match reads and writes as well as data sizes. Reads and - writes are serialized and the status verifies that the chip is idle - (and data is available) before the read is executed, so it should - not happen. -- Running x86_64 2.6.24 UHCI under qemu 0.9.0 under x86_64 2.6.22-rc6 - with a OHCI controller, ds2490 running in the guest would operate - normally the first time the module was loaded after qemu attached - the ds2490 hardware, but if the module was unloaded, then reloaded - most of the time one of the bulk out or in, and usually the bulk in - would fail. qemu sets a 50ms timeout and the bulk in would timeout - even when the status shows data available. A bulk out write would - show a successful completion, but the ds2490 status register would - show 0 bytes written. Detaching qemu from the ds2490 hardware and - 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 diff --git a/Documentation/w1/masters/ds2490.rst b/Documentation/w1/masters/ds2490.rst new file mode 100644 index 000000000000..7e5b50f9c0f5 --- /dev/null +++ b/Documentation/w1/masters/ds2490.rst @@ -0,0 +1,72 @@ +==================== +Kernel driver ds2490 +==================== + +Supported chips: + + * Maxim DS2490 based + +Author: Evgeniy Polyakov + + +Description +----------- + +The Maxim/Dallas Semiconductor DS2490 is a chip +which allows to build USB <-> W1 bridges. + +DS9490(R) is a USB <-> W1 bus master device +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) +- The hardware will detect when devices are attached to the bus on the + next bus (reset?) operation, however only a message is printed as + the core w1 code doesn't make use of the information. Connecting + one device tends to give multiple new device notifications. +- The number of USB bus transactions could be reduced if w1_reset_send + was added to the API. The name is just a suggestion. It would take + a write buffer and a read buffer (along with sizes) as arguments. + The ds2490 block I/O command supports reset, write buffer, read + buffer, and strong pullup all in one command, instead of the current + 1 reset bus, 2 write the match rom command and slave rom id, 3 block + write and read data. The write buffer needs to have the match rom + command and slave rom id prepended to the front of the requested + write buffer, both of which are known to the driver. +- The hardware supports normal, flexible, and overdrive bus + communication speeds, but only the normal is supported. +- The registered w1_bus_master functions don't define error + conditions. If a bus search is in progress and the ds2490 is + removed it can produce a good amount of error output before the bus + search finishes. +- The hardware supports detecting some error conditions, such as + short, alarming presence on reset, and no presence on reset, but the + driver doesn't query those values. +- The ds2490 specification doesn't cover short bulk in reads in + detail, but my observation is if fewer bytes are requested than are + available, the bulk read will return an error and the hardware will + clear the entire bulk in buffer. It would be possible to read the + maximum buffer size to not run into this error condition, only extra + bytes in the buffer is a logic error in the driver. The code should + should match reads and writes as well as data sizes. Reads and + writes are serialized and the status verifies that the chip is idle + (and data is available) before the read is executed, so it should + not happen. +- Running x86_64 2.6.24 UHCI under qemu 0.9.0 under x86_64 2.6.22-rc6 + with a OHCI controller, ds2490 running in the guest would operate + normally the first time the module was loaded after qemu attached + the ds2490 hardware, but if the module was unloaded, then reloaded + most of the time one of the bulk out or in, and usually the bulk in + would fail. qemu sets a 50ms timeout and the bulk in would timeout + even when the status shows data available. A bulk out write would + show a successful completion, but the ds2490 status register would + show 0 bytes written. Detaching qemu from the ds2490 hardware and + 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 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 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 diff --git a/Documentation/w1/masters/omap-hdq b/Documentation/w1/masters/omap-hdq deleted file mode 100644 index 234522709a5f..000000000000 --- a/Documentation/w1/masters/omap-hdq +++ /dev/null @@ -1,52 +0,0 @@ -Kernel driver for omap HDQ/1-wire module. -======================================== - -Supported chips: -================ - HDQ/1-wire controller on the TI OMAP 2430/3430 platforms. - -A useful link about HDQ basics: -=============================== -http://focus.ti.com/lit/an/slua408a/slua408a.pdf - -Description: -============ -The HDQ/1-Wire module of TI OMAP2430/3430 platforms implement the hardware -protocol of the master functions of the Benchmark HDQ and the Dallas -Semiconductor 1-Wire protocols. These protocols use a single wire for -communication between the master (HDQ/1-Wire controller) and the slave -(HDQ/1-Wire external compliant device). - -A typical application of the HDQ/1-Wire module is the communication with battery -monitor (gas gauge) integrated circuits. - -The controller supports operation in both HDQ and 1-wire mode. The essential -difference between the HDQ and 1-wire mode is how the slave device responds to -initialization pulse.In HDQ mode, the firmware does not require the host to -create an initialization pulse to the slave.However, the slave can be reset by -using an initialization pulse (also referred to as a break pulse).The slave -does not respond with a presence pulse as it does in the 1-Wire protocol. - -Remarks: -======== -The driver (drivers/w1/masters/omap_hdq.c) supports the HDQ mode of the -controller. In this mode, as we can not read the ID which obeys the W1 -spec(family:id:crc), a module parameter can be passed to the driver which will -be used to calculate the CRC and pass back an appropriate slave ID to the W1 -core. - -By default the master driver and the BQ slave i/f -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 - -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 -to the bus using SEARCH_ROM procedure. 1-wire mode can be selected by -setting "ti,mode" property to "1w" in DT (see -Documentation/devicetree/bindings/w1/omap-hdq.txt for more details). -By default driver is in HDQ mode. diff --git a/Documentation/w1/masters/omap-hdq.rst b/Documentation/w1/masters/omap-hdq.rst new file mode 100644 index 000000000000..345298a59e50 --- /dev/null +++ b/Documentation/w1/masters/omap-hdq.rst @@ -0,0 +1,54 @@ +======================================== +Kernel driver for omap HDQ/1-wire module +======================================== + +Supported chips: +================ +HDQ/1-wire controller on the TI OMAP 2430/3430 platforms. + +A useful link about HDQ basics: +=============================== +http://focus.ti.com/lit/an/slua408a/slua408a.pdf + +Description: +============ +The HDQ/1-Wire module of TI OMAP2430/3430 platforms implement the hardware +protocol of the master functions of the Benchmark HDQ and the Dallas +Semiconductor 1-Wire protocols. These protocols use a single wire for +communication between the master (HDQ/1-Wire controller) and the slave +(HDQ/1-Wire external compliant device). + +A typical application of the HDQ/1-Wire module is the communication with battery +monitor (gas gauge) integrated circuits. + +The controller supports operation in both HDQ and 1-wire mode. The essential +difference between the HDQ and 1-wire mode is how the slave device responds to +initialization pulse.In HDQ mode, the firmware does not require the host to +create an initialization pulse to the slave.However, the slave can be reset by +using an initialization pulse (also referred to as a break pulse).The slave +does not respond with a presence pulse as it does in the 1-Wire protocol. + +Remarks: +======== +The driver (drivers/w1/masters/omap_hdq.c) supports the HDQ mode of the +controller. In this mode, as we can not read the ID which obeys the W1 +spec(family:id:crc), a module parameter can be passed to the driver which will +be used to calculate the CRC and pass back an appropriate slave ID to the W1 +core. + +By default the master driver and the BQ slave i/f +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 + +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 +to the bus using SEARCH_ROM procedure. 1-wire mode can be selected by +setting "ti,mode" property to "1w" in DT (see +Documentation/devicetree/bindings/w1/omap-hdq.txt for more details). +By default driver is in HDQ mode. diff --git a/Documentation/w1/masters/w1-gpio b/Documentation/w1/masters/w1-gpio deleted file mode 100644 index 623961d9e83f..000000000000 --- a/Documentation/w1/masters/w1-gpio +++ /dev/null @@ -1,44 +0,0 @@ -Kernel driver w1-gpio -===================== - -Author: Ville Syrjala - - -Description ------------ - -GPIO 1-wire bus master driver. The driver uses the GPIO API to control the -wire and the GPIO pin can be specified using GPIO machine descriptor tables. -It is also possible to define the master using device tree, see -Documentation/devicetree/bindings/w1/w1-gpio.txt - - -Example (mach-at91) -------------------- - -#include -#include - -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 = { - .ext_pullup_enable_pin = -EINVAL, -}; - -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); - platform_device_register(&foo_w1_device); diff --git a/Documentation/w1/masters/w1-gpio.rst b/Documentation/w1/masters/w1-gpio.rst new file mode 100644 index 000000000000..18fdb7366372 --- /dev/null +++ b/Documentation/w1/masters/w1-gpio.rst @@ -0,0 +1,47 @@ +===================== +Kernel driver w1-gpio +===================== + +Author: Ville Syrjala + + +Description +----------- + +GPIO 1-wire bus master driver. The driver uses the GPIO API to control the +wire and the GPIO pin can be specified using GPIO machine descriptor tables. +It is also possible to define the master using device tree, see +Documentation/devicetree/bindings/w1/w1-gpio.txt + + +Example (mach-at91) +------------------- + +:: + + #include + #include + + 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 = { + .ext_pullup_enable_pin = -EINVAL, + }; + + 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); + platform_device_register(&foo_w1_device); 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 deleted file mode 100644 index 8137fe6f6c3d..000000000000 --- a/Documentation/w1/slaves/w1_ds2406 +++ /dev/null @@ -1,25 +0,0 @@ -w1_ds2406 kernel driver -======================= - -Supported chips: - * Maxim DS2406 (and other family 0x12) addressable switches - -Author: Scott Alfter - -Description ------------ - -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 -one output and uses parasitic power only. - -The driver provides two sysfs files. state is readable; it gives the -current state of each switch, with PIO A in bit 0 and PIO B in bit 1. The -driver ORs this state with 0x30, so shell scripts get an ASCII 0/1/2/3 to -work with. output is writable; bits 0 and 1 control PIO A and B, -respectively. Bits 2-7 are ignored, so it's safe to write ASCII data. - -CRCs are checked on read and write. Failed checks cause an I/O error to be -returned. On a failed write, the switch status is not changed. diff --git a/Documentation/w1/slaves/w1_ds2406.rst b/Documentation/w1/slaves/w1_ds2406.rst new file mode 100644 index 000000000000..d3e68266084f --- /dev/null +++ b/Documentation/w1/slaves/w1_ds2406.rst @@ -0,0 +1,27 @@ +======================= +w1_ds2406 kernel driver +======================= + +Supported chips: + + * Maxim DS2406 (and other family 0x12) addressable switches + +Author: Scott Alfter + +Description +----------- + +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 +one output and uses parasitic power only. + +The driver provides two sysfs files. state is readable; it gives the +current state of each switch, with PIO A in bit 0 and PIO B in bit 1. The +driver ORs this state with 0x30, so shell scripts get an ASCII 0/1/2/3 to +work with. output is writable; bits 0 and 1 control PIO A and B, +respectively. Bits 2-7 are ignored, so it's safe to write ASCII data. + +CRCs are checked on read and write. Failed checks cause an I/O error to be +returned. On a failed write, the switch status is not changed. diff --git a/Documentation/w1/slaves/w1_ds2413 b/Documentation/w1/slaves/w1_ds2413 deleted file mode 100644 index 936263a8ccb4..000000000000 --- a/Documentation/w1/slaves/w1_ds2413 +++ /dev/null @@ -1,50 +0,0 @@ -Kernel driver w1_ds2413 -======================= - -Supported chips: - * Maxim DS2413 1-Wire Dual Channel Addressable Switch - -supported family codes: - W1_FAMILY_DS2413 0x3A - -Author: Mariusz Bialonczyk - -Description ------------ - -The DS2413 chip has two open-drain outputs (PIO A and PIO B). -Support is provided through the sysfs files "output" and "state". - -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. - -Writing output --------------- -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. -When reading the state, there is a four complement bits. -The driver is checking this complement, and when it is wrong then it is -returning I/O error. - -When writing output, the master must repeat the PIO Output Data byte in -its inverted form and it is waiting for a confirmation. -If the write is unsuccessful for three times, the write also returns -I/O error. diff --git a/Documentation/w1/slaves/w1_ds2413.rst b/Documentation/w1/slaves/w1_ds2413.rst new file mode 100644 index 000000000000..c15bb5b919b7 --- /dev/null +++ b/Documentation/w1/slaves/w1_ds2413.rst @@ -0,0 +1,59 @@ +======================= +Kernel driver w1_ds2413 +======================= + +Supported chips: + + * Maxim DS2413 1-Wire Dual Channel Addressable Switch + +supported family codes: + + ================ ==== + W1_FAMILY_DS2413 0x3A + ================ ==== + +Author: Mariusz Bialonczyk + +Description +----------- + +The DS2413 chip has two open-drain outputs (PIO A and PIO B). +Support is provided through the sysfs files "output" and "state". + +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. + +Writing output +-------------- +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. +When reading the state, there is a four complement bits. +The driver is checking this complement, and when it is wrong then it is +returning I/O error. + +When writing output, the master must repeat the PIO Output Data byte in +its inverted form and it is waiting for a confirmation. +If the write is unsuccessful for three times, the write also returns +I/O error. 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 - -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= 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 + +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= 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 deleted file mode 100644 index e64f65a09387..000000000000 --- a/Documentation/w1/slaves/w1_ds2438 +++ /dev/null @@ -1,63 +0,0 @@ -Kernel driver w1_ds2438 -======================= - -Supported chips: - * Maxim DS2438 Smart Battery Monitor - -supported family codes: - W1_FAMILY_DS2438 0x26 - -Author: Mariusz Bialonczyk - -Description ------------ - -The DS2438 chip provides several functions that are desirable to carry in -a battery pack. It also has a 40 bytes of nonvolatile EEPROM. -Because the ability of temperature, current and voltage measurement, the chip -is also often used in weather stations and applications such as: rain gauge, -wind speed/direction measuring, humidity sensing, etc. - -Current support is provided through the following sysfs files (all files -except "iad" are readonly): - -"iad" ------ -This file controls the 'Current A/D Control Bit' (IAD) in the -Status/Configuration Register. -Writing a zero value will clear the IAD bit and disables the current -measurements. -Writing value "1" is setting the IAD bit (enables the measurements). -The IAD bit is enabled by default in the DS2438. - -When writing to sysfs file bits 2-7 are ignored, so it's safe to write ASCII. -An I/O error is returned when there is a problem setting the new value. - -"page0" -------- -This file provides full 8 bytes of the chip Page 0 (00h). -This page contains the most frequently accessed information of the DS2438. -Internally when this file is read, the additional CRC byte is also obtained -from the slave device. If it is correct, the 8 bytes page data are passed -to userspace, otherwise an I/O error is returned. - -"temperature" -------------- -Opening and reading this file initiates the CONVERT_T (temperature conversion) -command of the chip, afterwards the temperature is read from the device -registers and provided as an ASCII decimal value. - -Important: The returned value has to be divided by 256 to get a real -temperature in degrees Celsius. - -"vad", "vdd" ------------- -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) - -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_ds2438.rst b/Documentation/w1/slaves/w1_ds2438.rst new file mode 100644 index 000000000000..a29309a3f8e5 --- /dev/null +++ b/Documentation/w1/slaves/w1_ds2438.rst @@ -0,0 +1,69 @@ +Kernel driver w1_ds2438 +======================= + +Supported chips: + + * Maxim DS2438 Smart Battery Monitor + +supported family codes: + ================ ==== + W1_FAMILY_DS2438 0x26 + ================ ==== + +Author: Mariusz Bialonczyk + +Description +----------- + +The DS2438 chip provides several functions that are desirable to carry in +a battery pack. It also has a 40 bytes of nonvolatile EEPROM. +Because the ability of temperature, current and voltage measurement, the chip +is also often used in weather stations and applications such as: rain gauge, +wind speed/direction measuring, humidity sensing, etc. + +Current support is provided through the following sysfs files (all files +except "iad" are readonly): + +"iad" +----- +This file controls the 'Current A/D Control Bit' (IAD) in the +Status/Configuration Register. +Writing a zero value will clear the IAD bit and disables the current +measurements. +Writing value "1" is setting the IAD bit (enables the measurements). +The IAD bit is enabled by default in the DS2438. + +When writing to sysfs file bits 2-7 are ignored, so it's safe to write ASCII. +An I/O error is returned when there is a problem setting the new value. + +"page0" +------- +This file provides full 8 bytes of the chip Page 0 (00h). +This page contains the most frequently accessed information of the DS2438. +Internally when this file is read, the additional CRC byte is also obtained +from the slave device. If it is correct, the 8 bytes page data are passed +to userspace, otherwise an I/O error is returned. + +"temperature" +------------- +Opening and reading this file initiates the CONVERT_T (temperature conversion) +command of the chip, afterwards the temperature is read from the device +registers and provided as an ASCII decimal value. + +Important: The returned value has to be divided by 256 to get a real +temperature in degrees Celsius. + +"vad", "vdd" +------------ +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) + +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 deleted file mode 100644 index 7819b65cfa48..000000000000 --- a/Documentation/w1/slaves/w1_ds28e04 +++ /dev/null @@ -1,36 +0,0 @@ -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, - -Description ------------ - -Support is provided through the sysfs files "eeprom" and "pio". CRC checking -during memory accesses can optionally be enabled/disabled via the device -attribute "crccheck". The strong pull-up can optionally be enabled/disabled -via the module parameter "w1_strong_pullup". - -Memory Access - - A read operation on the "eeprom" file reads the given amount of bytes - from the EEPROM of the DS28E04. - - A write operation on the "eeprom" file writes the given byte sequence - to the EEPROM of the DS28E04. If CRC checking mode is enabled only - fully aligned blocks of 32 bytes with valid CRC16 values (in bytes 30 - and 31) are allowed to be written. - -PIO Access - - The 2 PIOs of the DS28E04-100 are accessible via the "pio" sysfs file. - - The current status of the PIO's is returned as an 8 bit value. Bit 0/1 - represent the state of PIO_0/PIO_1. Bits 2..7 do not care. The PIO's are - driven low-active, i.e. the driver delivers/expects low-active values. diff --git a/Documentation/w1/slaves/w1_ds28e04.rst b/Documentation/w1/slaves/w1_ds28e04.rst new file mode 100644 index 000000000000..b12b118890d3 --- /dev/null +++ b/Documentation/w1/slaves/w1_ds28e04.rst @@ -0,0 +1,41 @@ +======================== +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, + +Description +----------- + +Support is provided through the sysfs files "eeprom" and "pio". CRC checking +during memory accesses can optionally be enabled/disabled via the device +attribute "crccheck". The strong pull-up can optionally be enabled/disabled +via the module parameter "w1_strong_pullup". + +Memory Access + + A read operation on the "eeprom" file reads the given amount of bytes + from the EEPROM of the DS28E04. + + A write operation on the "eeprom" file writes the given byte sequence + to the EEPROM of the DS28E04. If CRC checking mode is enabled only + fully aligned blocks of 32 bytes with valid CRC16 values (in bytes 30 + and 31) are allowed to be written. + +PIO Access + + The 2 PIOs of the DS28E04-100 are accessible via the "pio" sysfs file. + + The current status of the PIO's is returned as an 8 bit value. Bit 0/1 + represent the state of PIO_0/PIO_1. Bits 2..7 do not care. The PIO's are + driven low-active, i.e. the driver delivers/expects low-active values. diff --git a/Documentation/w1/slaves/w1_ds28e17 b/Documentation/w1/slaves/w1_ds28e17 deleted file mode 100644 index 7fcfad5b4a37..000000000000 --- a/Documentation/w1/slaves/w1_ds28e17 +++ /dev/null @@ -1,68 +0,0 @@ -Kernel driver w1_ds28e17 -======================== - -Supported chips: - * Maxim DS28E17 1-Wire-to-I2C Master Bridge - -supported family codes: - W1_FAMILY_DS28E17 0x19 - -Author: Jan Kandziora - - -Description ------------ -The DS28E17 is a Onewire slave device which acts as an I2C bus master. - -This driver creates a new I2C bus for any DS28E17 device detected. I2C buses -come and go as the DS28E17 devices come and go. I2C slave devices connected to -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}" -------------------------------------------------------------------------------- -may be used to create stable /dev/i2c- entries based on the unique id of the -DS28E17 chip. - - -Driver parameters are: - -speed: - This sets up the default I2C speed a DS28E17 get configured for as soon - it is connected. The power-on default of the DS28E17 is 400kBaud, but - chips may come and go on the Onewire bus without being de-powered and - as soon the "w1_ds28e17" driver notices a freshly connected, or - reconnected DS28E17 device on the Onewire bus, it will re-apply this - setting. - - Valid values are 100, 400, 900 [kBaud]. Any other value means to leave - alone the current DS28E17 setting on detect. The default value is 100. - -stretch: - This sets up the default stretch value used for freshly connected - DS28E17 devices. It is a multiplier used on the calculation of the busy - wait time for an I2C transfer. This is to account for I2C slave devices - which make heavy use of the I2C clock stretching feature and thus, the - needed timeout cannot be pre-calculated correctly. As the w1_ds28e17 - driver checks the DS28E17's busy flag in a loop after the precalculated - wait time, it should be hardly needed to tweak this setting. - - Leave it at 1 unless you get ETIMEDOUT errors and a "w1_slave_driver - 19-00000002dbd8: busy timeout" in the kernel log. - - Valid values are 1 to 9. The default is 1. - - -The driver creates sysfs files /sys/bus/w1/devices/19-/speed and -/sys/bus/w1/devices/19-/stretch for each device, preloaded with the default -settings from the driver parameters. They may be changed anytime. In addition a -directory /sys/bus/w1/devices/19-/i2c- for the I2C bus master sysfs -structure is created. - - -See https://github.com/ianka/w1_ds28e17 for even more information. - diff --git a/Documentation/w1/slaves/w1_ds28e17.rst b/Documentation/w1/slaves/w1_ds28e17.rst new file mode 100644 index 000000000000..e2d9f96d8f2c --- /dev/null +++ b/Documentation/w1/slaves/w1_ds28e17.rst @@ -0,0 +1,72 @@ +======================== +Kernel driver w1_ds28e17 +======================== + +Supported chips: + + * Maxim DS28E17 1-Wire-to-I2C Master Bridge + +supported family codes: + + ================= ==== + W1_FAMILY_DS28E17 0x19 + ================= ==== + +Author: Jan Kandziora + + +Description +----------- +The DS28E17 is a Onewire slave device which acts as an I2C bus master. + +This driver creates a new I2C bus for any DS28E17 device detected. I2C buses +come and go as the DS28E17 devices come and go. I2C slave devices connected to +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}" + +may be used to create stable /dev/i2c- entries based on the unique id of the +DS28E17 chip. + + +Driver parameters are: + +speed: + This sets up the default I2C speed a DS28E17 get configured for as soon + it is connected. The power-on default of the DS28E17 is 400kBaud, but + chips may come and go on the Onewire bus without being de-powered and + as soon the "w1_ds28e17" driver notices a freshly connected, or + reconnected DS28E17 device on the Onewire bus, it will re-apply this + setting. + + Valid values are 100, 400, 900 [kBaud]. Any other value means to leave + alone the current DS28E17 setting on detect. The default value is 100. + +stretch: + This sets up the default stretch value used for freshly connected + DS28E17 devices. It is a multiplier used on the calculation of the busy + wait time for an I2C transfer. This is to account for I2C slave devices + which make heavy use of the I2C clock stretching feature and thus, the + needed timeout cannot be pre-calculated correctly. As the w1_ds28e17 + driver checks the DS28E17's busy flag in a loop after the precalculated + wait time, it should be hardly needed to tweak this setting. + + Leave it at 1 unless you get ETIMEDOUT errors and a "w1_slave_driver + 19-00000002dbd8: busy timeout" in the kernel log. + + Valid values are 1 to 9. The default is 1. + + +The driver creates sysfs files /sys/bus/w1/devices/19-/speed and +/sys/bus/w1/devices/19-/stretch for each device, preloaded with the default +settings from the driver parameters. They may be changed anytime. In addition a +directory /sys/bus/w1/devices/19-/i2c- for the I2C bus master sysfs +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 deleted file mode 100644 index d1f93af36f38..000000000000 --- a/Documentation/w1/slaves/w1_therm +++ /dev/null @@ -1,67 +0,0 @@ -Kernel driver w1_therm -==================== - -Supported chips: - * Maxim ds18*20 based temperature sensors. - * Maxim ds1825 based temperature sensors. - -Author: Evgeniy Polyakov - - -Description ------------ - -w1_therm provides basic temperature conversion for ds18*20 devices, and the -ds28ea00 device. -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 -lines of ASCII output. The first line contains the nine hex bytes -read along with a calculated crc value and YES or NO if it matched. -If the crc matched the returned values are retained. The second line -displays the retained values along with a temperature in millidegrees -Centigrade after t=. - -Parasite powered devices are limited to one slave performing a -temperature conversion at a time. If none of the devices are parasite -powered it would be possible to convert all the devices at the same -time and then go back to read individual sensors. That isn't -currently supported. The driver also doesn't support reduced -precision (which would also reduce the conversion time) when reading values. - -Writing a value between 9 and 12 to the sysfs w1_slave file will change the -precision of the sensor for the next readings. This value is in (volatile) -SRAM, so it is reset when the sensor gets power-cycled. - -To store the current precision configuration into EEPROM, the value 0 -has to be written to the sysfs w1_slave file. Since the EEPROM has a limited -amount of writes (>50k), this command should be used wisely. - -The module parameter strong_pullup can be set to 0 to disable the -strong pullup, 1 to enable autodetection or 2 to force strong pullup. -In case of autodetection, the driver will use the "READ POWER SUPPLY" -command to check if there are pariste powered devices on the bus. -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 -resistor). The DS18b20 temperature sensor specification lists a -maximum current draw of 1.5mA and that a 5k pullup resistor is not -sufficient. The strong pullup is designed to provide the additional -current required. - -The DS28EA00 provides an additional two pins for implementing a sequence -detection algorithm. This feature allows you to determine the physical -location of the chip in the 1-wire bus without needing pre-existing -knowledge of the bus ordering. Support is provided through the sysfs -w1_seq file. The file will contain a single line with an integer value -representing the device index in the bus starting at 0. diff --git a/Documentation/w1/slaves/w1_therm.rst b/Documentation/w1/slaves/w1_therm.rst new file mode 100644 index 000000000000..90531c340a07 --- /dev/null +++ b/Documentation/w1/slaves/w1_therm.rst @@ -0,0 +1,74 @@ +====================== +Kernel driver w1_therm +====================== + +Supported chips: + + * Maxim ds18*20 based temperature sensors. + * Maxim ds1825 based temperature sensors. + +Author: Evgeniy Polyakov + + +Description +----------- + +w1_therm provides basic temperature conversion for ds18*20 devices, and the +ds28ea00 device. + +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 +lines of ASCII output. The first line contains the nine hex bytes +read along with a calculated crc value and YES or NO if it matched. +If the crc matched the returned values are retained. The second line +displays the retained values along with a temperature in millidegrees +Centigrade after t=. + +Parasite powered devices are limited to one slave performing a +temperature conversion at a time. If none of the devices are parasite +powered it would be possible to convert all the devices at the same +time and then go back to read individual sensors. That isn't +currently supported. The driver also doesn't support reduced +precision (which would also reduce the conversion time) when reading values. + +Writing a value between 9 and 12 to the sysfs w1_slave file will change the +precision of the sensor for the next readings. This value is in (volatile) +SRAM, so it is reset when the sensor gets power-cycled. + +To store the current precision configuration into EEPROM, the value 0 +has to be written to the sysfs w1_slave file. Since the EEPROM has a limited +amount of writes (>50k), this command should be used wisely. + +The module parameter strong_pullup can be set to 0 to disable the +strong pullup, 1 to enable autodetection or 2 to force strong pullup. +In case of autodetection, the driver will use the "READ POWER SUPPLY" +command to check if there are pariste powered devices on the bus. +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 +resistor). The DS18b20 temperature sensor specification lists a +maximum current draw of 1.5mA and that a 5k pullup resistor is not +sufficient. The strong pullup is designed to provide the additional +current required. + +The DS28EA00 provides an additional two pins for implementing a sequence +detection algorithm. This feature allows you to determine the physical +location of the chip in the 1-wire bus without needing pre-existing +knowledge of the bus ordering. Support is provided through the sysfs +w1_seq file. The file will contain a single line with an integer value +representing the device index in the bus starting at 0. diff --git a/Documentation/w1/w1-generic.rst b/Documentation/w1/w1-generic.rst new file mode 100644 index 000000000000..da4e8b4e9b01 --- /dev/null +++ b/Documentation/w1/w1-generic.rst @@ -0,0 +1,133 @@ +========================================= +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). + +Devices communicate on the bus by pulling the signal to ground via an open +drain output and by sampling the logic level of the signal line. + +The w1 subsystem provides the framework for managing w1 masters and +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 + + +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 + - the w1 bus is periodically searched for new slave devices + +When a device is found on the bus, w1 core tries to load the driver for its family +and check if it is loaded. If so, the family driver is attached to the slave. +If there is no driver for the family, default one is assigned, which allows to perform +almost any kind of operations. Each logical operation is a transaction +in nature, which can contain several (two or one) low-level operations. +Let's see how one can read EEPROM context: +1. one must write control buffer, i.e. buffer containing command byte +and two byte address. At this step bus is reset and appropriate device +is selected using either W1_SKIP_ROM or W1_MATCH_ROM command. +Then provided control buffer is being written to the wire. +2. reading. This will issue reading eeprom response. + +It is possible that between 1. and 2. w1 master thread will reset bus for searching +and slave device will be even removed, but in this case 0xff will +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) + 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. + +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. + +Emulated devices must provide the ability to set the output signal level +(write_bit) and sample the signal level (read_bit). + +Devices that support the 1-wire natively must provide the ability to write and +sample a bit (touch_bit) and reset the bus (reset_bus). + +Most hardware provides higher-level functions that offload w1 handling. +See struct w1_bus_master definition in w1.h for details. + + +w1 master sysfs interface +------------------------- + +========================= ===================================================== + 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 +for an initially small number of bus searches. Alternatively it could be +set to zero, then manually add the slave device serial numbers by +w1_master_add device file. The w1_master_add and w1_master_remove files +generally only make sense when searching is disabled, as a search will +redetect manually removed devices that are present and timeout manually +added devices that aren't on the bus. + +Bus searches occur at an interval, specified as a summ of timeout and +timeout_us module parameters (either of which may be 0) for as long as +w1_master_search remains greater than 0 or is -1. Each search attempt +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. +=================== ============================================================ diff --git a/Documentation/w1/w1-netlink.rst b/Documentation/w1/w1-netlink.rst new file mode 100644 index 000000000000..aaa13243a5e4 --- /dev/null +++ b/Documentation/w1/w1-netlink.rst @@ -0,0 +1,202 @@ +=============================================== +Userspace communication protocol over connector +=============================================== + +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. +2. Userspace commands. +3. Replies to userspace commands. + + +Protocol +======== + +:: + + [struct cn_msg] - connector header. + Its length field is equal to size of the attached data + [struct w1_netlink_msg] - w1 netlink header. + __u8 type - message type. + W1_LIST_MASTERS + list current bus masters + W1_SLAVE_ADD/W1_SLAVE_REMOVE + slave add/remove events + W1_MASTER_ADD/W1_MASTER_REMOVE + master add/remove events + W1_MASTER_CMD + userspace command for bus master + device (search/alarm search) + W1_SLAVE_CMD + userspace command for slave device + (read/write/touch) + __u8 status - error indication from kernel + __u16 len - size of data attached to this header data + union { + __u8 id[8]; - slave unique device id + struct w1_mst { + __u32 id; - master's id + __u32 res; - reserved + } mst; + } id; + + [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 + W1_CMD_SEARCH - search command + W1_CMD_ALARM_SEARCH - alarm search command + W1_CMD_TOUCH - touch command + (write and sample data back to userspace) + W1_CMD_RESET - send bus reset + W1_CMD_SLAVE_ADD - add slave to kernel list + W1_CMD_SLAVE_REMOVE - remove slave from kernel list + W1_CMD_LIST_SLAVES - get slaves list from kernel + __u8 res - reserved + __u16 len - length of data for this command + For read command data must be allocated like for write command + __u8 data[0] - data for this command + + +Each connector message can include one or more w1_netlink_msg with +zero or more attached w1_netlink_cmd messages. + +For event messages there are no w1_netlink_cmd embedded structures, +only connector header and w1_netlink_msg strucutre with "len" field +being zero and filled type (one of event types) and id: +either 8 bytes of slave unique id in host order, +or master's id, which is assigned to bus master device +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:: + + [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; + +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:: + + 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) + w1_netlink_msg (type: W1_LIST_MASTERS, len is equal to + 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. + +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:: + + [cn_msg, ack = 1 and increasing, 0 means the last message, + 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) + + 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] + + +Command status replies +====================== + +Each command (either root, master or slave with or without w1_netlink_cmd +structure) will be 'acked' by the w1 core. Format of the reply is the same +as request message except that length parameters do not account for data +requested by the user, i.e. read/write/touch IO requests will not contain +data, so w1_netlink_cmd.len will be 0, w1_netlink_msg.len will be size +of the w1_netlink_cmd structure and cn_msg.len will be equal to the sum +of the sizeof(struct w1_netlink_msg) and sizeof(struct w1_netlink_cmd). +If reply is generated for master or root command (which do not have +w1_netlink_cmd attached), reply will contain only cn_msg and w1_netlink_msg +structures. + +w1_netlink_msg.status field will carry positive error value +(EINVAL for example) or zero in case of success. + +All other fields in every structure will mirror the same parameters in the +request message (except lengths as described above). + +Status reply is generated for every w1_netlink_cmd embedded in the +w1_netlink_msg, if there are no w1_netlink_cmd structures, +reply will be generated for the w1_netlink_msg. + +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 +======================================================= + +When new message (w1_netlink_msg) is received w1 core detects if it is +master or slave request, according to w1_netlink_msg.type field. +Then master or slave device is searched for. +When found, master device (requested or those one on where slave device +is found) is locked. If slave command is requested, then reset/select +procedure is started to select given device. + +Then all requested in w1_netlink_msg operations are performed one by one. +If command requires reply (like read command) it is sent on command completion. + +When all commands (w1_netlink_cmd) are processed master device is unlocked +and next w1_netlink_msg header processing started. + + +Connector [1] specific documentation +==================================== + +Each connector message includes two u32 fields as "address". +w1 uses CN_W1_IDX and CN_W1_VAL defined in include/linux/connector.h header. +Each message also includes sequence and acknowledge numbers. +Sequence number for event messages is appropriate bus master sequence number +increased with each event message sent "through" this master. +Sequence number for userspace requests is set by userspace application. +Sequence number for reply is the same as was in request, and +acknowledge number is set to seq+1. + + +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. diff --git a/Documentation/w1/w1.generic b/Documentation/w1/w1.generic deleted file mode 100644 index c51b1ab012d0..000000000000 --- a/Documentation/w1/w1.generic +++ /dev/null @@ -1,121 +0,0 @@ -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). - -Devices communicate on the bus by pulling the signal to ground via an open -drain output and by sampling the logic level of the signal line. - -The w1 subsystem provides the framework for managing w1 masters and -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 - - -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 - - the w1 bus is periodically searched for new slave devices - -When a device is found on the bus, w1 core tries to load the driver for its family -and check if it is loaded. If so, the family driver is attached to the slave. -If there is no driver for the family, default one is assigned, which allows to perform -almost any kind of operations. Each logical operation is a transaction -in nature, which can contain several (two or one) low-level operations. -Let's see how one can read EEPROM context: -1. one must write control buffer, i.e. buffer containing command byte -and two byte address. At this step bus is reset and appropriate device -is selected using either W1_SKIP_ROM or W1_MATCH_ROM command. -Then provided control buffer is being written to the wire. -2. reading. This will issue reading eeprom response. - -It is possible that between 1. and 2. w1 master thread will reset bus for searching -and slave device will be even removed, but in this case 0xff will -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) - 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. - -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. - -Emulated devices must provide the ability to set the output signal level -(write_bit) and sample the signal level (read_bit). - -Devices that support the 1-wire natively must provide the ability to write and -sample a bit (touch_bit) and reset the bus (reset_bus). - -Most hardware provides higher-level functions that offload w1 handling. -See struct w1_bus_master definition in w1.h for details. - - -w1 master sysfs interface ------------------------------------------------------------------- - - 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 -for an initially small number of bus searches. Alternatively it could be -set to zero, then manually add the slave device serial numbers by -w1_master_add device file. The w1_master_add and w1_master_remove files -generally only make sense when searching is disabled, as a search will -redetect manually removed devices that are present and timeout manually -added devices that aren't on the bus. - -Bus searches occur at an interval, specified as a summ of timeout and -timeout_us module parameters (either of which may be 0) for as long as -w1_master_search remains greater than 0 or is -1. Each search attempt -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. diff --git a/Documentation/w1/w1.netlink b/Documentation/w1/w1.netlink deleted file mode 100644 index 94ad4c420828..000000000000 --- a/Documentation/w1/w1.netlink +++ /dev/null @@ -1,189 +0,0 @@ -Userspace communication protocol over connector [1]. - - -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. -2. Userspace commands. -3. Replies to userspace commands. - - -Protocol. -======== - -[struct cn_msg] - connector header. - Its length field is equal to size of the attached data -[struct w1_netlink_msg] - w1 netlink header. - __u8 type - message type. - W1_LIST_MASTERS - list current bus masters - W1_SLAVE_ADD/W1_SLAVE_REMOVE - slave add/remove events - W1_MASTER_ADD/W1_MASTER_REMOVE - master add/remove events - W1_MASTER_CMD - userspace command for bus master - device (search/alarm search) - W1_SLAVE_CMD - userspace command for slave device - (read/write/touch) - __u8 status - error indication from kernel - __u16 len - size of data attached to this header data - union { - __u8 id[8]; - slave unique device id - struct w1_mst { - __u32 id; - master's id - __u32 res; - reserved - } mst; - } id; - -[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 - W1_CMD_SEARCH - search command - W1_CMD_ALARM_SEARCH - alarm search command - W1_CMD_TOUCH - touch command - (write and sample data back to userspace) - W1_CMD_RESET - send bus reset - W1_CMD_SLAVE_ADD - add slave to kernel list - W1_CMD_SLAVE_REMOVE - remove slave from kernel list - W1_CMD_LIST_SLAVES - get slaves list from kernel - __u8 res - reserved - __u16 len - length of data for this command - For read command data must be allocated like for write command - __u8 data[0] - data for this command - - -Each connector message can include one or more w1_netlink_msg with -zero or more attached w1_netlink_cmd messages. - -For event messages there are no w1_netlink_cmd embedded structures, -only connector header and w1_netlink_msg strucutre with "len" field -being zero and filled type (one of event types) and id: -either 8 bytes of slave unique id in host order, -or master's id, which is assigned to bus master device -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: - -[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; - -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: - - 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) - w1_netlink_msg (type: W1_LIST_MASTERS, len is equal to - 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. - -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: - [cn_msg, ack = 1 and increasing, 0 means the last message, - 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) + - 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] - - -Command status replies. -====================== - -Each command (either root, master or slave with or without w1_netlink_cmd -structure) will be 'acked' by the w1 core. Format of the reply is the same -as request message except that length parameters do not account for data -requested by the user, i.e. read/write/touch IO requests will not contain -data, so w1_netlink_cmd.len will be 0, w1_netlink_msg.len will be size -of the w1_netlink_cmd structure and cn_msg.len will be equal to the sum -of the sizeof(struct w1_netlink_msg) and sizeof(struct w1_netlink_cmd). -If reply is generated for master or root command (which do not have -w1_netlink_cmd attached), reply will contain only cn_msg and w1_netlink_msg -structures. - -w1_netlink_msg.status field will carry positive error value -(EINVAL for example) or zero in case of success. - -All other fields in every structure will mirror the same parameters in the -request message (except lengths as described above). - -Status reply is generated for every w1_netlink_cmd embedded in the -w1_netlink_msg, if there are no w1_netlink_cmd structures, -reply will be generated for the w1_netlink_msg. - -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. -======================================================= - -When new message (w1_netlink_msg) is received w1 core detects if it is -master or slave request, according to w1_netlink_msg.type field. -Then master or slave device is searched for. -When found, master device (requested or those one on where slave device -is found) is locked. If slave command is requested, then reset/select -procedure is started to select given device. - -Then all requested in w1_netlink_msg operations are performed one by one. -If command requires reply (like read command) it is sent on command completion. - -When all commands (w1_netlink_cmd) are processed master device is unlocked -and next w1_netlink_msg header processing started. - - -Connector [1] specific documentation. -==================================== - -Each connector message includes two u32 fields as "address". -w1 uses CN_W1_IDX and CN_W1_VAL defined in include/linux/connector.h header. -Each message also includes sequence and acknowledge numbers. -Sequence number for event messages is appropriate bus master sequence number -increased with each event message sent "through" this master. -Sequence number for userspace requests is set by userspace application. -Sequence number for reply is the same as was in request, and -acknowledge number is set to seq+1. - - -Additional documantion, 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. -- cgit