Documentation/driver-api/serial/serial-rs485.rst
Source file repositories/reference/linux-study-clean/Documentation/driver-api/serial/serial-rs485.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/driver-api/serial/serial-rs485.rst- Extension
.rst- Size
- 5142 bytes
- Lines
- 136
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/serial.hsys/ioctl.h
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
===========================
RS485 Serial Communications
===========================
1. Introduction
===============
EIA-485, also known as TIA/EIA-485 or RS-485, is a standard defining the
electrical characteristics of drivers and receivers for use in balanced
digital multipoint systems.
This standard is widely used for communications in industrial automation
because it can be used effectively over long distances and in electrically
noisy environments.
2. Hardware-related Considerations
==================================
Some CPUs/UARTs (e.g., Atmel AT91 or 16C950 UART) contain a built-in
half-duplex mode capable of automatically controlling line direction by
toggling RTS or DTR signals. That can be used to control external
half-duplex hardware like an RS485 transceiver or any RS232-connected
half-duplex devices like some modems.
For these microcontrollers, the Linux driver should be made capable of
working in both modes, and proper ioctls (see later) should be made
available at user-level to allow switching from one mode to the other, and
vice versa.
3. Data Structures Already Available in the Kernel
==================================================
The Linux kernel provides the struct serial_rs485 to handle RS485
communications. This data structure is used to set and configure RS485
parameters in the platform data and in ioctls.
The device tree can also provide RS485 boot time parameters
[#DT-bindings]_. The serial core fills the struct serial_rs485 from the
values given by the device tree when the driver calls
uart_get_rs485_mode().
Any driver for devices capable of working both as RS232 and RS485 should
implement the ``rs485_config`` callback and provide ``rs485_supported``
in the ``struct uart_port``. The serial core calls ``rs485_config`` to do
the device specific part in response to TIOCSRS485 ioctl (see below). The
``rs485_config`` callback receives a pointer to a sanitizated struct
serial_rs485. The struct serial_rs485 userspace provides is sanitized
before calling ``rs485_config`` using ``rs485_supported`` that indicates
what RS485 features the driver supports for the ``struct uart_port``.
TIOCGRS485 ioctl can be used to read back the struct serial_rs485
matching to the current configuration.
.. kernel-doc:: include/uapi/linux/serial.h
:identifiers: serial_rs485 uart_get_rs485_mode
4. Usage from user-level
========================
From user-level, RS485 configuration can be get/set using the previous
ioctls. For instance, to set RS485 you can use the following code::
#include <linux/serial.h>
/* Include definition for RS485 ioctls: TIOCGRS485 and TIOCSRS485 */
#include <sys/ioctl.h>
/* Open your specific device (e.g., /dev/mydevice): */
int fd = open ("/dev/mydevice", O_RDWR);
if (fd < 0) {
/* Error handling. See errno. */
}
Annotation
- Immediate include surface: `linux/serial.h`, `sys/ioctl.h`.
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.