| # 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 | 
 | 	select INPUT | 
 | 	default y if !UML | 
 | 	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 | 
 | 	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 | 
 | 	  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 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 | 
 | 	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_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 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 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" |