Commit eaa85689 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/w1-2.6 

* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/w1-2.6:
  [PATCH] w1: warning fix
  [PATCH] w1: clean up W1_CON dependency.
  [PATCH] drivers/w1/w1.c: fix a compile error
  [PATCH] W1: fix dependencies of W1_SLAVE_DS2433_CRC
  [PATCH] W1: possible cleanups
  [PATCH] W1: cleanups
  [PATCH] w1 exports
  [PATCH] w1: Use mutexes instead of semaphores.
  [PATCH] w1: Make w1 connector notifications depend on connector.
  [PATCH] w1: netlink: Mark netlink group 1 as unused.
  [PATCH] w1: Move w1-connector definitions into linux/include/connector.h
  [PATCH] w1: Userspace communication protocol over connector.
  [PATCH] w1: Replace dscore and ds_w1_bridge with ds2490 driver.
  [PATCH] w1: Added default generic read/write operations.
parents 6c763eb9 c6976a4e

Documentation/w1/masters/ds2490

0 → 100644
+18 −0
Original line number Diff line number Diff line 
Kernel driver ds2490

====================



Supported chips:

  * Maxim DS2490 based



Author: Evgeniy Polyakov <johnpol@2ka.mipt.ru>





Description

-----------



The Maixm/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.

Documentation/w1/w1.generic

+15 −3
Original line number Diff line number Diff line
@@ -27,8 +27,19 @@ When a w1 master driver registers with the w1 subsystem, the following occurs: 


When a device is found on the bus, w1 core checks if driver for it's family is

loaded. If so, the family driver is attached to the slave.

If there is no driver for the family, a simple sysfs entry is created

for the slave device.

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
@@ -89,4 +100,5 @@ 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.

Documentation/w1/w1.netlink

0 → 100644
+98 −0
Original line number Diff line number Diff line 
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 new master or slave device found

	either due to automatic or requested search.

2. Userspace commands. Includes read/write and search/alarm search comamnds.

3. Replies to userspace commands.





Protocol.

========



[struct cn_msg] - connector header. It's length field is equal to size of the attached data.

[struct w1_netlink_msg] - w1 netlink header.

	__u8 type 	- message type.

			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/ search/alarm search

					for bus master device where given slave device found).

	__u8 res	- reserved

	__u16 len	- size of attached to this header data.

	union {

		__u8 id;			 - slave unique device id

		struct w1_mst {

			__u32		id;	 - master's id.

			__u32		res;	 - reserved

		} mst;

	} id;



[strucrt w1_netlink_cmd] - command for gived 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.

	__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 of 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;





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 of 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 muster 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/connector

2. http://tservice.net.ru/~s0mbre/archive/w1

This archive includes userspace application w1d.c which

uses read/write/search commands for all master/slave devices found on the bus.

drivers/w1/Kconfig

+13 −1
Original line number Diff line number Diff line
@@ -3,7 +3,7 @@ menu "Dallas's 1-wire bus" 
config W1

	tristate "Dallas's 1-wire support"

	---help---

	  Dallas's 1-wire bus is useful to connect slow 1-pin devices

	  Dallas' 1-wire bus is useful to connect slow 1-pin devices

	  such as iButtons and thermal sensors.



	  If you want W1 support, you should say Y here.
@@ -11,6 +11,18 @@ config W1 
	  This W1 support can also be built as a module.  If so, the module

	  will be called wire.ko.



config W1_CON

	depends on CONNECTOR && W1

	bool "Userspace communication over connector"

	default y

	--- help ---

	  This allows to communicate with userspace using connector [Documentation/connector].

	  There are three types of messages between w1 core and userspace:

	  1. Events. They are generated each time new master or slave device found

		either due to automatic or requested search.

	  2. Userspace commands. Includes read/write and search/alarm search comamnds.

	  3. Replies to userspace commands.



source drivers/w1/masters/Kconfig

source drivers/w1/slaves/Kconfig

drivers/w1/Makefile

+0 −4
Original line number Diff line number Diff line
@@ -2,10 +2,6 @@ 
# Makefile for the Dallas's 1-wire bus.

#



ifneq ($(CONFIG_NET), y)

EXTRA_CFLAGS	+= -DNETLINK_DISABLED

endif



ifeq ($(CONFIG_W1_DS2433_CRC), y)

EXTRA_CFLAGS	+= -DCONFIG_W1_F23_CRC

endif

CRA Git | Maintained and supported by SUSTech CRA and CCSE