btrfs: write_dev_flush does not return ENOMEM anymore
[linux/fpc-iii.git] / Documentation / ABI / testing / sysfs-platform-kim
blobc1653271872a9ff7d38306558c0f9c2e78fb6abf
1 What:           /sys/devices/platform/kim/dev_name
2 Date:           January 2010
3 KernelVersion:  2.6.38
4 Contact:        "Pavan Savoy" <pavan_savoy@ti.com>
5 Description:
6                 Name of the UART device at which the WL128x chip
7                 is connected. example: "/dev/ttyS0".
8                 The device name flows down to architecture specific board
9                 initialization file from the SFI/ATAGS bootloader
10                 firmware. The name exposed is read from the user-space
11                 dameon and opens the device when install is requested.
13 What:           /sys/devices/platform/kim/baud_rate
14 Date:           January 2010
15 KernelVersion:  2.6.38
16 Contact:        "Pavan Savoy" <pavan_savoy@ti.com>
17 Description:
18                 The maximum reliable baud-rate the host can support.
19                 Different platforms tend to have different high-speed
20                 UART configurations, so the baud-rate needs to be set
21                 locally and also sent across to the WL128x via a HCI-VS
22                 command. The entry is read and made use by the user-space
23                 daemon when the ldisc install is requested.
25 What:           /sys/devices/platform/kim/flow_cntrl
26 Date:           January 2010
27 KernelVersion:  2.6.38
28 Contact:        "Pavan Savoy" <pavan_savoy@ti.com>
29 Description:
30                 The WL128x makes use of flow control mechanism, and this
31                 entry most often should be 1, the host's UART is required
32                 to have the capability of flow-control, or else this
33                 entry can be made use of for exceptions.
35 What:           /sys/devices/platform/kim/install
36 Date:           January 2010
37 KernelVersion:  2.6.38
38 Contact:        "Pavan Savoy" <pavan_savoy@ti.com>
39 Description:
40                 When one of the protocols Bluetooth, FM or GPS wants to make
41                 use of the shared UART transport, it registers to the shared
42                 transport driver, which will signal the user-space for opening,
43                 configuring baud and install line discipline via this sysfs
44                 entry. This entry would be polled upon by the user-space
45                 daemon managing the UART, and is notified about the change
46                 by the sysfs_notify. The value would be '1' when UART needs
47                 to be opened/ldisc installed, and would be '0' when UART
48                 is no more required and needs to be closed.