# SPDX-License-Identifier: GPL-2.0 
 | 
config TTY 
 | 
    bool "Enable TTY" if EXPERT 
 | 
    default y 
 | 
    help 
 | 
      Allows you to remove TTY support which can save space, and 
 | 
      blocks features that require TTY from inclusion in the kernel. 
 | 
      TTY is required for any text terminals or serial port 
 | 
      communication. Most users should leave this enabled. 
 | 
  
 | 
if TTY 
 | 
  
 | 
config VT 
 | 
    bool "Virtual terminal" if EXPERT 
 | 
    depends on !UML 
 | 
    select INPUT 
 | 
    default y 
 | 
    help 
 | 
      If you say Y here, you will get support for terminal devices with 
 | 
      display and keyboard devices. These are called "virtual" because you 
 | 
      can run several virtual terminals (also called virtual consoles) on 
 | 
      one physical terminal. This is rather useful, for example one 
 | 
      virtual terminal can collect system messages and warnings, another 
 | 
      one can be used for a text-mode user session, and a third could run 
 | 
      an X session, all in parallel. Switching between virtual terminals 
 | 
      is done with certain key combinations, usually Alt-<function key>. 
 | 
  
 | 
      The setterm command ("man setterm") can be used to change the 
 | 
      properties (such as colors or beeping) of a virtual terminal. The 
 | 
      man page console_codes(4) ("man console_codes") contains the special 
 | 
      character sequences that can be used to change those properties 
 | 
      directly. The fonts used on virtual terminals can be changed with 
 | 
      the setfont ("man setfont") command and the key bindings are defined 
 | 
      with the loadkeys ("man loadkeys") command. 
 | 
  
 | 
      You need at least one virtual terminal device in order to make use 
 | 
      of your keyboard and monitor. Therefore, only people configuring an 
 | 
      embedded system would want to say N here in order to save some 
 | 
      memory; the only way to log into such a system is then via a serial 
 | 
      or network connection. 
 | 
  
 | 
      If unsure, say Y, or else you won't be able to do much with your new 
 | 
      shiny Linux system :-) 
 | 
  
 | 
config CONSOLE_TRANSLATIONS 
 | 
    depends on VT 
 | 
    default y 
 | 
    bool "Enable character translations in console" if EXPERT 
 | 
    help 
 | 
      This enables support for font mapping and Unicode translation 
 | 
      on virtual consoles. 
 | 
  
 | 
config VT_CONSOLE 
 | 
    bool "Support for console on virtual terminal" if EXPERT 
 | 
    depends on VT 
 | 
    default y 
 | 
    help 
 | 
      The system console is the device which receives all kernel messages 
 | 
      and warnings and which allows logins in single user mode. If you 
 | 
      answer Y here, a virtual terminal (the device used to interact with 
 | 
      a physical terminal) can be used as system console. This is the most 
 | 
      common mode of operations, so you should say Y here unless you want 
 | 
      the kernel messages be output only to a serial port (in which case 
 | 
      you should say Y to "Console on serial port", below). 
 | 
  
 | 
      If you do say Y here, by default the currently visible virtual 
 | 
      terminal (/dev/tty0) will be used as system console. You can change 
 | 
      that with a kernel command line option such as "console=tty3" which 
 | 
      would use the third virtual terminal as system console. (Try "man 
 | 
      bootparam" or see the documentation of your boot loader (lilo or 
 | 
      loadlin) about how to pass options to the kernel at boot time.) 
 | 
  
 | 
      If unsure, say Y. 
 | 
  
 | 
config VT_CONSOLE_SLEEP 
 | 
    def_bool y 
 | 
    depends on VT_CONSOLE && PM_SLEEP 
 | 
  
 | 
config HW_CONSOLE 
 | 
    bool 
 | 
    depends on VT && !UML 
 | 
    default y 
 | 
  
 | 
config VT_HW_CONSOLE_BINDING 
 | 
    bool "Support for binding and unbinding console drivers" 
 | 
    depends on HW_CONSOLE 
 | 
    help 
 | 
      The virtual terminal is the device that interacts with the physical 
 | 
      terminal through console drivers. On these systems, at least one 
 | 
      console driver is loaded. In other configurations, additional console 
 | 
      drivers may be enabled, such as the framebuffer console. If more than 
 | 
      1 console driver is enabled, setting this to 'y' will allow you to 
 | 
      select the console driver that will serve as the backend for the 
 | 
      virtual terminals. 
 | 
  
 | 
      See <file:Documentation/driver-api/console.rst> for more 
 | 
      information. For framebuffer console users, please refer to 
 | 
      <file:Documentation/fb/fbcon.rst>. 
 | 
  
 | 
config UNIX98_PTYS 
 | 
    bool "Unix98 PTY support" if EXPERT 
 | 
    default y 
 | 
    help 
 | 
      A pseudo terminal (PTY) is a software device consisting of two 
 | 
      halves: a master and a slave. The slave device behaves identical to 
 | 
      a physical terminal; the master device is used by a process to 
 | 
      read data from and write data to the slave, thereby emulating a 
 | 
      terminal. Typical programs for the master side are telnet servers 
 | 
      and xterms. 
 | 
  
 | 
      Linux has traditionally used the BSD-like names /dev/ptyxx for 
 | 
      masters and /dev/ttyxx for slaves of pseudo terminals. This scheme 
 | 
      has a number of problems. The GNU C library glibc 2.1 and later, 
 | 
      however, supports the Unix98 naming standard: in order to acquire a 
 | 
      pseudo terminal, a process opens /dev/ptmx; the number of the pseudo 
 | 
      terminal is then made available to the process and the pseudo 
 | 
      terminal slave can be accessed as /dev/pts/<number>. What was 
 | 
      traditionally /dev/ttyp2 will then be /dev/pts/2, for example. 
 | 
  
 | 
      All modern Linux systems use the Unix98 ptys.  Say Y unless 
 | 
      you're on an embedded system and want to conserve memory. 
 | 
  
 | 
config LEGACY_PTYS 
 | 
    bool "Legacy (BSD) PTY support" 
 | 
    default y 
 | 
    help 
 | 
      A pseudo terminal (PTY) is a software device consisting of two 
 | 
      halves: a master and a slave. The slave device behaves identical to 
 | 
      a physical terminal; the master device is used by a process to 
 | 
      read data from and write data to the slave, thereby emulating a 
 | 
      terminal. Typical programs for the master side are telnet servers 
 | 
      and xterms. 
 | 
  
 | 
      Linux has traditionally used the BSD-like names /dev/ptyxx 
 | 
      for masters and /dev/ttyxx for slaves of pseudo 
 | 
      terminals. This scheme has a number of problems, including 
 | 
      security.  This option enables these legacy devices; on most 
 | 
      systems, it is safe to say N. 
 | 
  
 | 
config LEGACY_PTY_COUNT 
 | 
    int "Maximum number of legacy PTY in use" 
 | 
    depends on LEGACY_PTYS 
 | 
    range 0 256 
 | 
    default "256" 
 | 
    help 
 | 
      The maximum number of legacy PTYs that can be used at any one time. 
 | 
      The default is 256, and should be more than enough.  Embedded 
 | 
      systems may want to reduce this to save memory. 
 | 
  
 | 
      When not in use, each legacy PTY occupies 12 bytes on 32-bit 
 | 
      architectures and 24 bytes on 64-bit architectures. 
 | 
  
 | 
config LDISC_AUTOLOAD 
 | 
    bool "Automatically load TTY Line Disciplines" 
 | 
    default y 
 | 
    help 
 | 
      Historically the kernel has always automatically loaded any 
 | 
      line discipline that is in a kernel module when a user asks 
 | 
      for it to be loaded with the TIOCSETD ioctl, or through other 
 | 
      means.  This is not always the best thing to do on systems 
 | 
      where you know you will not be using some of the more 
 | 
      "ancient" line disciplines, so prevent the kernel from doing 
 | 
      this unless the request is coming from a process with the 
 | 
      CAP_SYS_MODULE permissions. 
 | 
  
 | 
      Say 'Y' here if you trust your userspace users to do the right 
 | 
      thing, or if you have only provided the line disciplines that 
 | 
      you know you will be using, or if you wish to continue to use 
 | 
      the traditional method of on-demand loading of these modules 
 | 
      by any user. 
 | 
  
 | 
      This functionality can be changed at runtime with the 
 | 
      dev.tty.ldisc_autoload sysctl, this configuration option will 
 | 
      only set the default value of this functionality. 
 | 
  
 | 
source "drivers/tty/serial/Kconfig" 
 | 
  
 | 
config SERIAL_NONSTANDARD 
 | 
    bool "Non-standard serial port support" 
 | 
    depends on HAS_IOMEM 
 | 
    help 
 | 
      Say Y here if you have any non-standard serial boards -- boards 
 | 
      which aren't supported using the standard "dumb" serial driver. 
 | 
      This includes intelligent serial boards such as Cyclades, 
 | 
      Digiboards, etc. These are usually used for systems that need many 
 | 
      serial ports because they serve many terminals or dial-in 
 | 
      connections. 
 | 
  
 | 
      Note that the answer to this question won't directly affect the 
 | 
      kernel: saying N will just cause the configurator to skip all 
 | 
      the questions about non-standard serial boards. 
 | 
  
 | 
      Most people can say N here. 
 | 
  
 | 
config ROCKETPORT 
 | 
    tristate "Comtrol RocketPort support" 
 | 
    depends on SERIAL_NONSTANDARD && (ISA || EISA || PCI) 
 | 
    help 
 | 
      This driver supports Comtrol RocketPort and RocketModem PCI boards.    
 | 
      These boards provide 2, 4, 8, 16, or 32 high-speed serial ports or 
 | 
      modems.  For information about the RocketPort/RocketModem  boards 
 | 
      and this driver read <file:Documentation/driver-api/serial/rocket.rst>. 
 | 
  
 | 
      To compile this driver as a module, choose M here: the 
 | 
      module will be called rocket. 
 | 
  
 | 
      If you want to compile this driver into the kernel, say Y here.  If 
 | 
      you don't have a Comtrol RocketPort/RocketModem card installed, say N. 
 | 
  
 | 
config CYCLADES 
 | 
    tristate "Cyclades async mux support" 
 | 
    depends on SERIAL_NONSTANDARD && (PCI || ISA) 
 | 
    select FW_LOADER 
 | 
    help 
 | 
      This driver supports Cyclades Z and Y multiserial boards. 
 | 
      You would need something like this to connect more than two modems to 
 | 
      your Linux box, for instance in order to become a dial-in server. 
 | 
  
 | 
      For information about the Cyclades-Z card, read 
 | 
      <file:Documentation/driver-api/serial/cyclades_z.rst>. 
 | 
  
 | 
      To compile this driver as a module, choose M here: the 
 | 
      module will be called cyclades. 
 | 
  
 | 
      If you haven't heard about it, it's safe to say N. 
 | 
  
 | 
config CYZ_INTR 
 | 
    bool "Cyclades-Z interrupt mode operation" 
 | 
    depends on CYCLADES && PCI 
 | 
    help 
 | 
      The Cyclades-Z family of multiport cards allows 2 (two) driver op 
 | 
      modes: polling and interrupt. In polling mode, the driver will check 
 | 
      the status of the Cyclades-Z ports every certain amount of time 
 | 
      (which is called polling cycle and is configurable). In interrupt 
 | 
      mode, it will use an interrupt line (IRQ) in order to check the 
 | 
      status of the Cyclades-Z ports. The default op mode is polling. If 
 | 
      unsure, say N. 
 | 
  
 | 
config MOXA_INTELLIO 
 | 
    tristate "Moxa Intellio support" 
 | 
    depends on SERIAL_NONSTANDARD && (ISA || EISA || PCI) 
 | 
    select FW_LOADER 
 | 
    help 
 | 
      Say Y here if you have a Moxa Intellio multiport serial card. 
 | 
  
 | 
      To compile this driver as a module, choose M here: the 
 | 
      module will be called moxa. 
 | 
  
 | 
config MOXA_SMARTIO 
 | 
    tristate "Moxa SmartIO support v. 2.0" 
 | 
    depends on SERIAL_NONSTANDARD && (PCI || EISA || ISA) 
 | 
    help 
 | 
      Say Y here if you have a Moxa SmartIO multiport serial card and/or 
 | 
      want to help develop a new version of this driver. 
 | 
  
 | 
      This is upgraded (1.9.1) driver from original Moxa drivers with 
 | 
      changes finally resulting in PCI probing. 
 | 
  
 | 
      This driver can also be built as a module. The module will be called 
 | 
      mxser. If you want to do that, say M here. 
 | 
  
 | 
config SYNCLINK 
 | 
    tristate "Microgate SyncLink card support" 
 | 
    depends on SERIAL_NONSTANDARD && PCI && ISA_DMA_API 
 | 
    help 
 | 
      Provides support for the SyncLink ISA and PCI multiprotocol serial 
 | 
      adapters. These adapters support asynchronous and HDLC bit 
 | 
      synchronous communication up to 10Mbps (PCI adapter). 
 | 
  
 | 
      This driver can only be built as a module ( = code which can be 
 | 
      inserted in and removed from the running kernel whenever you want). 
 | 
      The module will be called synclink.  If you want to do that, say M 
 | 
      here. 
 | 
  
 | 
config SYNCLINKMP 
 | 
    tristate "SyncLink Multiport support" 
 | 
    depends on SERIAL_NONSTANDARD && PCI 
 | 
    help 
 | 
      Enable support for the SyncLink Multiport (2 or 4 ports) 
 | 
      serial adapter, running asynchronous and HDLC communications up 
 | 
      to 2.048Mbps. Each ports is independently selectable for 
 | 
      RS-232, V.35, RS-449, RS-530, and X.21 
 | 
  
 | 
      This driver may be built as a module ( = code which can be 
 | 
      inserted in and removed from the running kernel whenever you want). 
 | 
      The module will be called synclinkmp.  If you want to do that, say M 
 | 
      here. 
 | 
  
 | 
config SYNCLINK_GT 
 | 
    tristate "SyncLink GT/AC support" 
 | 
    depends on SERIAL_NONSTANDARD && PCI 
 | 
    help 
 | 
      Support for SyncLink GT and SyncLink AC families of 
 | 
      synchronous and asynchronous serial adapters 
 | 
      manufactured by Microgate Systems, Ltd. (www.microgate.com) 
 | 
  
 | 
config ISI 
 | 
    tristate "Multi-Tech multiport card support" 
 | 
    depends on SERIAL_NONSTANDARD && PCI 
 | 
    select FW_LOADER 
 | 
    help 
 | 
      This is a driver for the Multi-Tech cards which provide several 
 | 
      serial ports.  The driver is experimental and can currently only be 
 | 
      built as a module. The module will be called isicom. 
 | 
      If you want to do that, choose M here. 
 | 
  
 | 
config N_HDLC 
 | 
    tristate "HDLC line discipline support" 
 | 
    depends on SERIAL_NONSTANDARD 
 | 
    help 
 | 
      Allows synchronous HDLC communications with tty device drivers that 
 | 
      support synchronous HDLC such as the Microgate SyncLink adapter. 
 | 
  
 | 
      This driver can be built as a module ( = code which can be 
 | 
      inserted in and removed from the running kernel whenever you want). 
 | 
      The module will be called n_hdlc. If you want to do that, say M 
 | 
      here. 
 | 
  
 | 
config PPC_EPAPR_HV_BYTECHAN 
 | 
    bool "ePAPR hypervisor byte channel driver" 
 | 
    depends on PPC 
 | 
    select EPAPR_PARAVIRT 
 | 
    help 
 | 
      This driver creates /dev entries for each ePAPR hypervisor byte 
 | 
      channel, thereby allowing applications to communicate with byte 
 | 
      channels as if they were serial ports. 
 | 
  
 | 
config PPC_EARLY_DEBUG_EHV_BC 
 | 
    bool "Early console (udbg) support for ePAPR hypervisors" 
 | 
    depends on PPC_EPAPR_HV_BYTECHAN=y 
 | 
    help 
 | 
      Select this option to enable early console (a.k.a. "udbg") support 
 | 
      via an ePAPR byte channel.  You also need to choose the byte channel 
 | 
      handle below. 
 | 
  
 | 
config PPC_EARLY_DEBUG_EHV_BC_HANDLE 
 | 
    int "Byte channel handle for early console (udbg)" 
 | 
    depends on PPC_EARLY_DEBUG_EHV_BC 
 | 
    default 0 
 | 
    help 
 | 
      If you want early console (udbg) output through a byte channel, 
 | 
      specify the handle of the byte channel to use. 
 | 
  
 | 
      For this to work, the byte channel driver must be compiled 
 | 
      in-kernel, not as a module. 
 | 
  
 | 
      Note that only one early console driver can be enabled, so don't 
 | 
      enable any others if you enable this one. 
 | 
  
 | 
      If the number you specify is not a valid byte channel handle, then 
 | 
      there simply will be no early console output.  This is true also 
 | 
      if you don't boot under a hypervisor at all. 
 | 
  
 | 
config GOLDFISH_TTY 
 | 
    tristate "Goldfish TTY Driver" 
 | 
    depends on GOLDFISH 
 | 
    select SERIAL_CORE 
 | 
    select SERIAL_CORE_CONSOLE 
 | 
    help 
 | 
      Console and system TTY driver for the Goldfish virtual platform. 
 | 
  
 | 
config GOLDFISH_TTY_EARLY_CONSOLE 
 | 
    bool 
 | 
    default y if GOLDFISH_TTY=y 
 | 
    select SERIAL_EARLYCON 
 | 
  
 | 
config N_GSM 
 | 
    tristate "GSM MUX line discipline support (EXPERIMENTAL)" 
 | 
    depends on NET 
 | 
    help 
 | 
      This line discipline provides support for the GSM MUX protocol and 
 | 
      presents the mux as a set of 61 individual tty devices. 
 | 
  
 | 
config NOZOMI 
 | 
    tristate "HSDPA Broadband Wireless Data Card - Globe Trotter" 
 | 
    depends on PCI 
 | 
    help 
 | 
      If you have a HSDPA driver Broadband Wireless Data Card - 
 | 
      Globe Trotter PCMCIA card, say Y here. 
 | 
  
 | 
      To compile this driver as a module, choose M here, the module 
 | 
      will be called nozomi. 
 | 
  
 | 
config MIPS_EJTAG_FDC_TTY 
 | 
    bool "MIPS EJTAG Fast Debug Channel TTY" 
 | 
    depends on MIPS_CDMM 
 | 
    help 
 | 
      This enables a TTY and console on the MIPS EJTAG Fast Debug Channels, 
 | 
      if they are present. This can be useful when working with an EJTAG 
 | 
      probe which supports it, to get console output and a login prompt via 
 | 
      EJTAG without needing to connect a serial cable. 
 | 
  
 | 
      TTY devices are named e.g. ttyFDC3c2 (for FDC channel 2 of the FDC on 
 | 
      CPU3). 
 | 
  
 | 
      The console can be enabled with console=fdc1 (for FDC channel 1 on all 
 | 
      CPUs). Do not use the console unless there is a debug probe attached 
 | 
      to drain the FDC TX FIFO. 
 | 
  
 | 
      If unsure, say N. 
 | 
  
 | 
config MIPS_EJTAG_FDC_EARLYCON 
 | 
    bool "Early FDC console" 
 | 
    depends on MIPS_EJTAG_FDC_TTY 
 | 
    help 
 | 
      This registers a console on FDC channel 1 very early during boot (from 
 | 
      MIPS arch code). This is useful for bring-up and debugging early boot 
 | 
      issues. 
 | 
  
 | 
      Do not enable unless there is a debug probe attached to drain the FDC 
 | 
      TX FIFO. 
 | 
  
 | 
      If unsure, say N. 
 | 
  
 | 
config MIPS_EJTAG_FDC_KGDB 
 | 
    bool "Use KGDB over an FDC channel" 
 | 
    depends on MIPS_EJTAG_FDC_TTY && KGDB 
 | 
    default y 
 | 
    help 
 | 
      This enables the use of KGDB over an FDC channel, allowing KGDB to be 
 | 
      used remotely or when a serial port isn't available. 
 | 
  
 | 
config MIPS_EJTAG_FDC_KGDB_CHAN 
 | 
    int "KGDB FDC channel" 
 | 
    depends on MIPS_EJTAG_FDC_KGDB 
 | 
    range 2 15 
 | 
    default 3 
 | 
    help 
 | 
      FDC channel number to use for KGDB. 
 | 
  
 | 
config NULL_TTY 
 | 
    tristate "NULL TTY driver" 
 | 
    help 
 | 
      Say Y here if you want a NULL TTY which simply discards messages. 
 | 
  
 | 
      This is useful to allow userspace applications which expect a console 
 | 
      device to work without modifications even when no console is 
 | 
      available or desired. 
 | 
  
 | 
      In order to use this driver, you should redirect the console to this 
 | 
      TTY, or boot the kernel with console=ttynull. 
 | 
  
 | 
      If unsure, say N. 
 | 
  
 | 
config TRACE_ROUTER 
 | 
    tristate "Trace data router for MIPI P1149.7 cJTAG standard" 
 | 
    depends on TRACE_SINK 
 | 
    help 
 | 
      The trace router uses the Linux tty line discipline framework to 
 | 
      route trace data coming from a tty port (say UART for example) to 
 | 
      the trace sink line discipline driver and to another tty port (say 
 | 
      USB). This is part of a solution for the MIPI P1149.7, compact JTAG, 
 | 
      standard, which is for debugging mobile devices. The PTI driver in 
 | 
      drivers/misc/pti.c defines the majority of this MIPI solution. 
 | 
  
 | 
      You should select this driver if the target kernel is meant for 
 | 
      a mobile device containing a modem.  Then you will need to select 
 | 
      "Trace data sink for MIPI P1149.7 cJTAG standard" line discipline 
 | 
      driver. 
 | 
  
 | 
config TRACE_SINK 
 | 
    tristate "Trace data sink for MIPI P1149.7 cJTAG standard" 
 | 
    help 
 | 
      The trace sink uses the Linux line discipline framework to receive 
 | 
      trace data coming from the trace router line discipline driver 
 | 
      to a user-defined tty port target, like USB. 
 | 
      This is to provide a way to extract modem trace data on 
 | 
      devices that do not have a PTI HW module, or just need modem 
 | 
      trace data to come out of a different HW output port. 
 | 
      This is part of a solution for the P1149.7, compact JTAG, standard. 
 | 
  
 | 
      If you select this option, you need to select 
 | 
      "Trace data router for MIPI P1149.7 cJTAG standard". 
 | 
  
 | 
config VCC 
 | 
    tristate "Sun Virtual Console Concentrator" 
 | 
    depends on SUN_LDOMS 
 | 
    help 
 | 
      Support for Sun logical domain consoles. 
 | 
  
 | 
source "drivers/tty/hvc/Kconfig" 
 | 
  
 | 
config RPMSG_TTY 
 | 
    tristate "RPMSG tty driver" 
 | 
    depends on RPMSG 
 | 
    help 
 | 
      Say y here to export rpmsg endpoints as tty devices, usually found 
 | 
      in /dev/ttyRPMSGx. 
 | 
      This makes it possible for user-space programs to send and receive 
 | 
      rpmsg messages as a standard tty protocol. 
 | 
  
 | 
      To compile this driver as a module, choose M here: the module will be 
 | 
      called rpmsg_tty. 
 | 
  
 | 
endif # TTY 
 | 
  
 | 
source "drivers/tty/serdev/Kconfig" 
 |