| 1 | |
| 2 |
|
| 3 | =============================
|
| 4 | TTY Driver and TTY Operations
|
| 5 | =============================
|
| 6 |
|
| 7 | .. contents:: :local:
|
| 8 |
|
| 9 | Allocation
|
| 10 | ==========
|
| 11 |
|
| 12 | The first thing a driver needs to do is to allocate a struct tty_driver. This
|
| 13 | is done by tty_alloc_driver() (or __tty_alloc_driver()). Next, the newly
|
| 14 | allocated structure is filled with information. See `TTY Driver Reference`_ at
|
| 15 | the end of this document on what actually shall be filled in.
|
| 16 |
|
| 17 | The allocation routines expect a number of devices the driver can handle at
|
| 18 | most and flags. Flags are those starting ``TTY_DRIVER_`` listed and described
|
| 19 | in `TTY Driver Flags`_ below.
|
| 20 |
|
| 21 | When the driver is about to be freed, tty_driver_kref_put() is called on that.
|
| 22 | It will decrements the reference count and if it reaches zero, the driver is
|
| 23 | freed.
|
| 24 |
|
| 25 | For reference, both allocation and deallocation functions are explained here in
|
| 26 | detail:
|
| 27 |
|
| 28 | .. kernel-doc:: include/linux/tty_driver.h
|
| 29 | :identifiers: tty_alloc_driver
|
| 30 | .. kernel-doc:: drivers/tty/tty_io.c
|
| 31 | :identifiers: __tty_alloc_driver tty_driver_kref_put
|
| 32 |
|
| 33 | TTY Driver Flags
|
| 34 | ----------------
|
| 35 |
|
| 36 | Here comes the documentation of flags accepted by tty_alloc_driver() (or
|
| 37 | __tty_alloc_driver()):
|
| 38 |
|
| 39 | .. kernel-doc:: include/linux/tty_driver.h
|
| 40 | :identifiers: tty_driver_flag
|
| 41 |
|
| 42 | ----
|
| 43 |
|
| 44 | Registration
|
| 45 | ============
|
| 46 |
|
| 47 | When a struct tty_driver is allocated and filled in, it can be registered using
|
| 48 | tty_register_driver(). It is recommended to pass ``TTY_DRIVER_DYNAMIC_DEV`` in
|
| 49 | flags of tty_alloc_driver(). If it is not passed, *all* devices are also
|
| 50 | registered during tty_register_driver() and the following paragraph of
|
| 51 | registering devices can be skipped for such drivers. However, the struct
|
| 52 | tty_port part in `Registering Devices`_ is still relevant there.
|
| 53 |
|
| 54 | .. kernel-doc:: drivers/tty/tty_io.c
|
| 55 | :identifiers: tty_register_driver tty_unregister_driver
|
| 56 |
|
| 57 | Registering Devices
|
| 58 | -------------------
|
| 59 |
|
| 60 | Every TTY device shall be backed by a struct tty_port. Usually, TTY drivers
|
| 61 | embed tty_port into device's private structures. Further details about handling
|
| 62 | tty_port can be found in :doc:`tty_port`. The driver is also recommended to use
|
| 63 | tty_port's reference counting by tty_port_get() and tty_port_put(). The final
|
| 64 | put is supposed to free the tty_port including the device's private struct.
|
| 65 |
|
| 66 | Unless ``TTY_DRIVER_DYNAMIC_DEV`` was passed as flags to tty_alloc_driver(),
|
| 67 | TTY driver is supposed to register every device discovered in the system
|
| 68 | (the latter is preferred). This is performed by tty_register_device(). Or by
|
| 69 | tty_register_device_attr() if the driver wants to expose some information
|
| 70 | through struct attribute_group. Both of them register ``index``'th device and
|
| 71 | upon return, the device can be opened. There are also preferred tty_port
|
| 72 | variants described in `Linking Devices to Ports`_ later. It is up to driver to
|
| 73 | manage free indices and choosing the right one. The TTY layer only refuses to
|
| 74 | register more devices than passed to tty_alloc_driver().
|
| 75 |
|
| 76 | When the device is opened, the TTY layer allocates struct tty_struct and starts
|
| 77 | calling operations from :c:member:`tty_driver.ops`, see `TTY Operations
|
| 78 | Reference`_.
|
| 79 |
|
| 80 | The registration routines are documented as follows:
|
| 81 |
|
| 82 | .. kernel-doc:: drivers/tty/tty_io.c
|
| 83 | :identifiers: tty_register_device tty_register_device_attr
|
| 84 | tty_unregister_device
|
| 85 |
|
| 86 | ----
|
| 87 |
|
| 88 | Linking Devices to Ports
|
| 89 | ------------------------
|
| 90 | As stated earlier, every TTY device shall have a struct tty_port assigned to
|
| 91 | it. It must be known to the TTY layer at :c:member:`tty_driver.ops.install()`
|
| 92 | at latest. There are few helpers to *link* the two. Ideally, the driver uses
|
| 93 | tty_port_register_device() or tty_port_register_device_attr() instead of
|
| 94 | tty_register_device() and tty_register_device_attr() at the registration time.
|
| 95 | This way, the driver needs not care about linking later on.
|
| 96 |
|
| 97 | If that is not possible, the driver still can link the tty_port to a specific
|
| 98 | index *before* the actual registration by tty_port_link_device(). If it still
|
| 99 | does not fit, tty_port_install() can be used from the
|
| 100 | :c:member:`tty_driver.ops.install` hook as a last resort. The last one is
|
| 101 | dedicated mostly for in-memory devices like PTY where tty_ports are allocated
|
| 102 | on demand.
|
| 103 |
|
| 104 | The linking routines are documented here:
|
| 105 |
|
| 106 | .. kernel-doc:: drivers/tty/tty_port.c
|
| 107 | :identifiers: tty_port_link_device tty_port_register_device
|
| 108 | tty_port_register_device_attr
|
| 109 |
|
| 110 | ----
|
| 111 |
|
| 112 | TTY Driver Reference
|
| 113 | ====================
|
| 114 |
|
| 115 | All members of struct tty_driver are documented here. The required members are
|
| 116 | noted at the end. struct tty_operations are documented next.
|
| 117 |
|
| 118 | .. kernel-doc:: include/linux/tty_driver.h
|
| 119 | :identifiers: tty_driver
|
| 120 |
|
| 121 | ----
|
| 122 |
|
| 123 | TTY Operations Reference
|
| 124 | ========================
|
| 125 |
|
| 126 | When a TTY is registered, these driver hooks can be invoked by the TTY layer:
|
| 127 |
|
| 128 | .. kernel-doc:: include/linux/tty_driver.h
|
| 129 | :identifiers: tty_operations
|
| 130 |
|