- 04 2月, 2012 1 次提交
-
-
由 Cong Wang 提交于
On sparc, there is a build failure: drivers/tty/serial/8250/8250.c:48:21: error: suncore.h: No such file or directory drivers/tty/serial/8250/8250.c:3275: error: implicit declaration of function 'sunserial_register_minors' drivers/tty/serial/8250/8250.c:3305: error: implicit declaration of function 'sunserial_unregister_minors' this is due to commit 9bef3d41 (serial: group all the 8250 related code together) moved these files into 8250/ subdirectory, but forgot to change the reference to drivers/tty/serial/suncore.h. Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: NWANG Cong <xiyou.wangcong@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 25 1月, 2012 1 次提交
-
-
由 Paul Gortmaker 提交于
The drivers/tty/serial dir is already getting rather busy. Relocate the 8250 related drivers to their own subdir to reduce the clutter. Note that sunsu.c is not included in this move -- it is 8250-like hardware, but it does not use any of the existing infrastructure -- and does not depend on SERIAL_8250. Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 10 12月, 2011 6 次提交
-
-
由 Paul Gortmaker 提交于
Currently serial8250_handle_irq is a trivial wrapper around serial8250_handle_port, which actually does all the work. Since there are no other callers of serial8250_handle_port, we can just move it inline into serial8250_handle_irq. This also makes it more clear what functionality any custom IRQ handlers need to provide if not using serial8250_default_handle_irq. Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com> Acked-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Paul Gortmaker 提交于
The current 8250 timeout code duplicates the code path in serial8250_default_handle_irq and then serial8250_handle_irq i.e. reading iir, check for IIR_NO_INT, and then calling serial8250_handle_port. So the immediate thought is to replace the duplicated code with a call to serial8250_default_handle_irq. But this highlights a problem. We let 8250 driver variants use their own IRQ handler via specifying their own custom ->handle_irq, but in the event of a timeout, we ignore their handler and implicitly run serial8250_default_handle_irq instead. So, go through the struct to get ->handle_irq and call that, which for most will still be serial8250_default_handle_irq. Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com> Acked-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Paul Gortmaker 提交于
For drivers that need to construct their own IRQ handler, the three components are seen in the current handle_port -- i.e. Rx, Tx and modem_status. Make these exported symbols so that "almost" 8250 UARTs can construct their own IRQ handler with these shared components, while working around their own unique errata issues. The function names are given a serial8250 prefix, since they are now entering the global namespace. Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com> Acked-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Paul Gortmaker 提交于
The receive_chars() was taking a pointer to a passed in LSR value in status and knocking off bits as it processed them. But since receive_chars isn't returning a value, we can instead pass in a normal non-pointer value for LSR, and simply return the residual (unprocessed) LSR once it is done. The value in this cleanup, is that it clarifies the API of the receive_chars prior to exporting it to other 8250-like drivers for shared usage. Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com> Acked-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Paul Gortmaker 提交于
Since we want to promote sharing and move away from one single uart driver with a bunch of platform specific bugfixes all munged into one, relocate some header like material from the C file to the header. Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com> Acked-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Wolfram Sang 提交于
Makes it easier to find all occurences requesting CONF_MODE_B. Signed-off-by: NWolfram Sang <w.sang@pengutronix.de> Acked-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 27 11月, 2011 1 次提交
-
-
由 Dan Williams 提交于
Workaround dropped notifications in the iir register. Prevent reads coincident with new interrupt notifications by reading the iir at most once per interrupt. Reported-by: NNhan H Mai <nhan.h.mai@intel.com> Signed-off-by: NDan Williams <dan.j.williams@intel.com> Acked-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 16 11月, 2011 2 次提交
-
-
由 Greg Kroah-Hartman 提交于
This reverts commit 9636b755. It wasn't supposed to be applied, thanks to Doug for letting me know. Cc: Doug Anderson <dianders@chromium.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Doug Anderson 提交于
On Tegra UARTs (except UART1), the DTR / DCD / DSR lines are not externally accessible. Instead, the DTR line internally appears to be looped back to be the input to the DCD and DSR lines. The net effect of this is that when we drop DTR (like when we suspend), we'll see DCD drop too. ...and when we see DCD drop, we treat that as a hangup. In order to prevent this hangup from occurring at every sleep, we need to force DTR to remain high on Tegra UARTs. This patch uses the mcr_mask / mcr_force fields, which were originally added for the kludge ALPHA_KLUDGE_MCR. Using these fields does not prevent us from removing ALPHA_KLUDGE_MCR--we can just remove the "if" tests I have added and always init mcr_mask / mcr_force from the serial8250_config. NOTE: If we have people that are using UARTA on a Tegra and need to control DTR, we'll need to either add a separate port type for UARTA or we'll need to add some tegra-specific code to detect whether the DTR needs to be left high. Signed-off-by: NDoug Anderson <dianders@chromium.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 27 9月, 2011 1 次提交
-
-
由 Konrad Rzeszutek Wilk 提交于
On my BIOSTAR TA890FXE the ttyS0 ends up spewing: [904682.485933] ttyS0: LSR safety check engaged! [904692.505895] ttyS0: LSR safety check engaged! [904702.525972] ttyS0: LSR safety check engaged! [904712.545967] ttyS0: LSR safety check engaged! [904722.566125] ttyS0: LSR safety check engaged! .. lets limit it so it won't be the only thing visible in the ring buffer. CC: Alan Cox <alan@linux.intel.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 23 9月, 2011 1 次提交
-
-
由 Søren Holm 提交于
The EFR (Enhenced-Features-Register) is located at a different offset than the other devices supporting UART_CAP_EFR. This change add a special setup quick to set UPF_EXAR_EFR on the port. UPF_EXAR_EFR is then used to the port type to PORT_XR17D15X since it is for sure a XR17D15X uart. Signed-off-by: NSøren Holm <sgh@sgh.dk> Acked-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 20 9月, 2011 1 次提交
-
-
由 Arnd Bergmann 提交于
This iotype is only used by the legacy_serial code in powerpc, so the code should live there, rather than be compiled in for every 8250 driver. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: linuxppc-dev@lists.ozlabs.org Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: linux-serial@vger.kernel.org Acked-by: NDavid Daney <david.daney@cavium.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 27 8月, 2011 1 次提交
-
-
由 Jamie Iles 提交于
Allow modules to use the normal 8250 irq handler inside their own. Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: NJamie Iles <jamie@jamieiles.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 24 8月, 2011 3 次提交
-
-
由 Jamie Iles 提交于
Now that platforms can override the port IRQ handler and the only user of these UPIO modes has been converted over, kill off UPIO_DWAPB and UPIO_DWAPB32. Acked-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NJamie Iles <jamie@jamieiles.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Jamie Iles 提交于
Some ports (e.g. Synopsys DesignWare 8250) have special requirements for handling the interrupts. Allow these platforms to specify their own interrupt handler that will override the default. serial8250_handle_irq() is provided so that platforms can extend the IRQ handler rather than completely replacing it. Signed-off-by: NJamie Iles <jamie@jamieiles.com> Acked-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Al Cooper 提交于
This is to fix an issue where output will suddenly become very slow. The problem occurs on 8250 UARTS with the hardware bug UART_BUG_THRE. BACKGROUND For normal UARTs (without UART_BUG_THRE): When the serial core layer gets new transmit data and the transmitter is idle, it buffers the data and calls the 8250s' serial8250_start_tx() routine which will simply enable the TX interrupt in the IER register and return. This should immediately fire a THRE interrupt and begin transmitting the data. For buggy UARTs (with UART_BUG_THRE): merely enabling the TX interrupt in IER does not necessarily generate a new THRE interrupt. Therefore, a background timer periodically checks to see if there is pending data, and starts transmission if that is the case. The bug happens on SMP systems when the system has nothing to transmit, the transmit interrupt is disabled and the following sequence occurs: - CPU0: The background timer routine serial8250_backup_timeout() starts and saves the state of the interrupt enable register (IER) and then disables all interrupts in IER. NOTE: The transmit interrupt (TI) bit is saved as disabled. - CPU1: The serial core gets data to transmit, grabs the port lock and calls serial8250_start_tx() which enables the TI in IER. - CPU0: serial8250_backup_timeout() waits for the port lock. - CPU1: finishes (with TI enabled) and releases the port lock. - CPU0: serial8250_backup_timeout() calls the interrupt routine which will transmit the next fifo's worth of data and then restores the IER from the previously saved value (TI disabled). At this point, as long as the serial core has more transmit data buffered, it will not call serial8250_start_tx() again and the background timer routine will slowly transmit the data. The fix is to have serial8250_start_tx() get the port lock before it saves the IER state and release it after restoring IER. This will prevent serial8250_start_tx() from running in parallel. Signed-off-by: NAl Cooper <alcooperx@gmail.com> Cc: stable <stable@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 02 7月, 2011 1 次提交
-
-
由 Stephen Warren 提交于
Commit 4539c24f "tty/serial: Add explicit PORT_TEGRA type" introduced separate flags describing the need for IER bits UUE and RTOIE. Both bits are required for the XSCALE port type. While that patch updated uart_config[] as required, the auto-probing code wasn't updated to set the RTOIE flag when an XSCALE port type was detected. This caused such ports to stop working. This patch rectifies that. Reported-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Tested-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NStephen Warren <swarren@nvidia.com> Cc: stable <stable@kernel.org> [3.0] Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 08 6月, 2011 2 次提交
-
-
由 Jiri Slaby 提交于
With virtual machines like qemu, it's pretty common to see "too much work for irq4" messages nowadays. This happens when a bunch of output is printed on the emulated serial console. This is caused by too low PASS_LIMIT. When ISR loops more than the limit, it spits the message. I've been using a kernel with doubled the limit and I couldn't see no problems. Maybe it's time to get rid of the message now? Signed-off-by: NJiri Slaby <jirislaby@gmail.com> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
When changing the port type, the capabilities flags should be changed also, otherwise the capabilities will not correspond to the port type, which make set_sleep() crash on rmmod. This patch just assign the correct capabilites when the port changes. Signed-off-by: NBreno Leitao <leitao@linux.vnet.ibm.com> CC: Michael Reed <mreed@linux.vnet.ibm.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 20 5月, 2011 2 次提交
-
-
由 Stephen Warren 提交于
When a break is received, Tegra's UART apparently fills the FIFO with 0 bytes. These must be drained so that they aren't interpreted as actual data received. This allows e.g. MAGIC_SYSRQ to work on Tegra's UARTs. v2: Added FIXME comment to clear_rx_fifo Originally-by: NLaxman Dewangan <ldewangan@nvidia.com> Cc: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: NStephen Warren <swarren@nvidia.com> Acked-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Stephen Warren 提交于
Tegra's UART is currently auto-detected as PORT_XSCALE due to register bit UART_IER.UUE being writable. However, the Tegra documentation states that this register bit is reserved. Hence, we should not program it. Instead, the documentation specifies that the UART is 16550 compatible. However, Tegra does need register bit UART_IER.RTOIE set, which is not enabled by any 16550 port type. This was not noticed before, since PORT_XSCALE enables CAP_UUE, which conflates both UUE and RTOIE bit programming. This change defines PORT_TEGRA that doesn't set UART_CAP_UUE, but does set UART_CAP_RTOIE, which is a new capability indicating that the RTOIE bit needs to be enabled. Based-on-code-by: NLaxman Dewangan <ldewangan@nvidia.com> Cc: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: NStephen Warren <swarren@nvidia.com> Acked-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 20 4月, 2011 1 次提交
-
-
由 Jovi Zhang 提交于
remove invalid location line in each file header after location moved from driver/char to driver/tty Signed-off-by: NJovi Zhang <bookjovi@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 31 3月, 2011 1 次提交
-
-
由 Lucas De Marchi 提交于
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>
-
- 18 2月, 2011 2 次提交
-
-
由 Yin Kangkai 提交于
In 8250.c original ns16550 autoconfig code, we change the divisor latch when we goto to high speed mode, we're assuming the previous speed is legacy. This some times is not true. For example in a system with both CONFIG_SERIAL_8250 and CONFIG_SERIAL_8250_PNP set, in this case, the code (autoconfig) will be called twice, one in serial8250_init/probe() and the other is from serial_pnp_probe. When serial_pnp_probe calls the autoconfig for NS16550A, it's already in high speed mode, change the divisor latch (quot << 3) in this case will make the UART console garbled. CC: Greg Kroah-Hartman <greg@kroah.com> CC: David Woodhouse <dwmw2@infradead.org> CC: linux-kernel@vger.kernel.org CC: stable@kernel.org Signed-off-by: NYin Kangkai <kangkai.yin@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Yin Kangkai 提交于
For any reason if the NS16550A was not work in high speed mode (e.g. we hold NS16550A from going to high speed mode in autoconfig_16550a()), now we are resume from suspend, we should also set the uartclk to the correct value. Otherwise it is still the old 1843200 and that will bring issues. CC: Greg Kroah-Hartman <greg@kroah.com> CC: David Woodhouse <dwmw2@infradead.org> CC: linux-kernel@vger.kernel.org CC: stable@kernel.org Signed-off-by: NYin Kangkai <kangkai.yin@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 23 1月, 2011 1 次提交
-
-
由 Pavel Machek 提交于
Unbreak Billionton CF bluetooth card. This actually fixes a regression on zaurus. Signed-off-by: NPavel Machek <pavel@ucw.cz> Cc: stable <stable@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 14 1月, 2011 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
The serial drivers are really just tty drivers, so move them to drivers/tty/ to make things a bit neater overall. This is part of the tty/serial driver movement proceedure as proposed by Arnd Bergmann and approved by everyone involved a number of months ago. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Rogier Wolff <R.E.Wolff@bitwizard.nl> Cc: Michael H. Warfield <mhw@wittsend.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 11 12月, 2010 3 次提交
-
-
由 Ondrej Puzman 提交于
I have found a bug in 8250.c driver which causes that 16550A uart FIFOs are not turned on during initialization if they are manually configured by setserial. UART is then working only as plain 16450 without FIFOs. On systems with higher interrupt latency this causes buffer overruns and loss of received data when using higher communication speeds. I'm working for a company which produces industrial computers. These devices typically contain high number (8 or more) of traditional 16550A uarts - we use TL16C554A chips, but that is not much relevant. UARTs are connected to the CPU by ISA bus (Celeron based devices) or LPC bus (Atom based devices). In the Linux the UARTs are using standard 8250.c driver and are initialized using setserial command: setserial /dev/ttyS4 uart 16550A port 0x3E0 irq 10 baud_base 115200 This executes the UART initialization through serial8250_startup() function. At the beginning of the function up->capabilities is initialized from uart_config: up->capabilities = uart_config[up->port.type].flags; Please note that neither up->port.fifosize nor up->tx_loadsz is initialized here!! Later in the same function serial8250_clear_fifos() is called and disables FIFOs. The above comment says that they will be reenabled in set_termios (they won't ...) After serial8250_startup() the serial8250_set_termios() is called. In this function the following check fails because up->port.fifosize is zero because it is not initialized correctly. if (up->capabilities & UART_CAP_FIFO && up->port.fifosize > 1) { if (baud < 2400) fcr = UART_FCR_ENABLE_FIFO | UART_FCR_TRIGGER_1; else fcr = uart_config[up->port.type].fcr; } fcr variable remains zero and in the end the FCR register is set to zero which results in disabled FIFOs even if the UART type is 16550A. This is also true for other types of UARTs with FIFOs. If the UART is autoconfigured via 'setserial /dev/ttySx autoconfig' then port.fifosize and tx_loadsz are initialized correctly in the autoconfig() function and the UART is working correctly then. I checked the source codes and I can say that this bug is present in 2.6.x series of kernels for a couple of years. Namely I can confirm its presence in 2.6.16.57, 2.6.32.24 and 2.6.36.1 (tested all of them on our hardware). I think it was not noticed before because not many people use manually configured non PNP UARTs on ISA/LPC bus these days. Also the data loss caused by buffer overruns occures only if IRQ latency is higher then time needed to receive one character on given communication speed. For example our hardware looses received characters only if the UARTs are connected throught LPC bus with SERIRQ (serial IRQ transport) and not if they are connected to ISA bus because LPC SERIRQ has higher interrupt latency then parallel ISA interupt lines. Here is the patch to correct the bug created against 2.6.36.1: Signed-off-by: NOndrej Puzman <puzman@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Jamie Iles 提交于
Some platforms contain a Synopsys DesignWare APB UART that is attached to a 32-bit APB bus where sub-word accesses are not allowed. Add a new IO type (UPIO_DWAPB32) that performs 32 bit acccesses to the UART. v2: - don't test for 32 bit in the output fast path, provide a separate dwabp32_serial_out() function. Refactor dwabp_serial_out() so that we can reuse the LCR saving code. v3: - rebased on top of "8250: use container_of() instead of casting" Signed-off-by: NJamie Iles <jamie@jamieiles.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Jamie Iles 提交于
The 8250 driver structure uart_8250_port took advantage of the fact that the struct uart_port was the first member of its structure and used an explicit cast to convert to the derived class. Replace the explicit casts with container_of() for safety and clarity. Signed-off-by: NJamie Iles <jamie@jamieiles.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 01 12月, 2010 1 次提交
-
-
由 Andrei Emeltchenko 提交于
Access to some registers depends on register access mode Three different modes are available for OMAP (at least) • Operational mode LCR_REG[7] = 0x0 • Configuration mode A LCR_REG[7] = 0x1 and LCR_REG[7:0]! = 0xBF • Configuration mode B LCR_REG[7] = 0x1 and LCR_REG[7:0] = 0xBF Define access modes and remove redefinitions and magic numbers in serial drivers (and later in bluetooth driver). Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@nokia.com> Acked-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 17 11月, 2010 1 次提交
-
-
由 Peter Zijlstra 提交于
While trying to debug a cpu-hotplug issue I noticed printk() stopped working once the cpu got marked offline, since the 8250 serial console doesn't have any per-cpu resources the CON_ANYTIME bit is the safe and documented way to make it work again. Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 14 11月, 2010 1 次提交
-
-
由 Ingo Molnar 提交于
This reverts commit 47d3904f. Crashes any x86 serial console bootup: Console: colour VGA+ 80x25 BUG: unable to handle kernel NULL pointer dereference at 0000000000000158 IP: [<ffffffff811ebcb4>] serial8250_do_set_termios+0x1d4/0x430 ... Signed-off-by: NIngo Molnar <mingo@elte.hu> Cc: Greg KH <gregkh@suse.de> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 12 11月, 2010 1 次提交
-
-
由 Lawrence Rust 提交于
Calling tcsetattr prevents any thread(s) currently suspended in ioctl TIOCMIWAIT for the same device from ever resuming. If a thread is suspended inside a call to ioctl TIOCMIWAIT, waiting for a modem status change, then the 8250 driver enables modem status interrupts (MSI). The device interrupt service routine resumes the suspended thread(s) on the next MSI. If while the thread(s) are suspended, another thread calls tcsetattr then the 8250 driver disables MSI (unless CTS/RTS handshaking is enabled) thus preventing the suspended thread(s) from ever being resumed. This patch only disables MSI in tcsetattr handling if there are no suspended threads. Program to demonstrate bug & fix: /* gcc miwait.c -o miwait -l pthread */ #include <stdio.h> #include <errno.h> #include <unistd.h> #include <fcntl.h> #include <pthread.h> #include <termios.h> #include <sys/ioctl.h> #include <linux/serial.h> static void* monitor( void* pv); static int s_fd; int main( void) { const char kszDev[] = "/dev/ttyS0"; pthread_t t; struct termios tio; s_fd = open( kszDev, O_RDWR | O_NONBLOCK); if ( s_fd < 0) return fprintf( stderr, "Error(%d) opening %s: %s\n", errno, kszDev, strerror( errno)), 1; pthread_create( &t, NULL, &monitor, NULL); /* Modem status changes seen here */ puts( "Main: awaiting status changes"); sleep( 5); tcgetattr( s_fd, &tio); tio.c_cflag ^= CSTOPB; /* But not after here */ puts( "Main: tcsetattr called"); tcsetattr( s_fd, TCSANOW, &tio); for (;;) sleep( 1); } static void* monitor( void* pv) { (void)pv; for(;;) { unsigned uModem; struct serial_icounter_struct cnt; if ( ioctl( s_fd, TIOCMGET, &uModem) < 0) fprintf( stderr, "Error(%d) in TIOCMGET: %s\n", errno, strerror( errno)); printf( "Modem status:%s%s%s%s%s%s\n", (uModem & TIOCM_RTS) ? " RTS" : "", (uModem & TIOCM_DTR) ? " DTR" : "", (uModem & TIOCM_CTS) ? " CTS" : "", (uModem & TIOCM_DSR) ? " DSR" : "", (uModem & TIOCM_CD) ? " CD" : "", (uModem & TIOCM_RI) ? " RI" : "" ); if ( ioctl( s_fd, TIOCGICOUNT, &cnt) < 0) fprintf( stderr, "Error(%d) in TIOCGICOUNT: %s\n", errno, strerror( errno)); printf( "Irqs: CTS:%d DSR:%d RNG:%d DCD:%d Rx:%d Tx:%d Frame:%d Orun:%d Par:%d Brk:%d Oflow:%d\n", cnt.cts, cnt.dsr, cnt.rng, cnt.dcd, cnt.rx, cnt.tx, cnt.frame, cnt.overrun, cnt.parity, cnt.brk, cnt.buf_overrun ); fputs( "Waiting...", stdout), fflush( stdout); if ( 0 > ioctl( s_fd, TIOCMIWAIT, (unsigned long)(TIOCM_CAR | TIOCM_RNG | TIOCM_DSR | TIOCM_CTS))) fprintf( stderr, "\nError(%d) in TIOCMIWAIT: %s\n", errno, strerror( errno)); fputs( "\n", stdout); } return NULL; } Signed-off by Lawrence Rust <lawrence@softsystem.co.uk> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 23 10月, 2010 4 次提交
-
-
由 Daniel Drake 提交于
Running a serial console, if too many kernel messages are generated within a short time causing a lot of serial I/O, the 8250 driver will generate another kernel message reporting this, which just adds to the I/O. It has a cascading effect and quickly results the system being brought to its knees by a flood of "too much work" messages. Ratelimit the error message to avoid this. [akpm@linux-foundation.org: use the superior printk_ratelimited()] [akpm@linux-foundation.org: printk_ratelimited() needs ratelimit.h] Signed-off-by: NDaniel Drake <dsd@laptop.org> Acked-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alan Cox 提交于
Not every platform that has generic legacy 8250 ports manages to have them clocked the right way or without errata. Provide a generic interface to allow platforms to override the default behaviour in a manner that dumps the complexity in *their* code not the 8250 driver. Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NDirk Brandewie <dirk.brandewie@gmail.com> Acked-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Manuel Lauss 提交于
Add a hook for platforms to specify custom pm methods. Signed-off-by: NManuel Lauss <manuel.lauss@googlemail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Anton Vorontsov 提交于
Soon we will use that handy function in the altera_uart driver. Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-