- Feb 17, 2011
-
-
Niranjana Vishwanathapura authored
msm_smd_tty driver provides tty device interface to 'DS' and 'GPSNMEA' streaming SMD ports. Cc: Brian Swetland <swetland@google.com> Signed-off-by:
Niranjana Vishwanathapura <nvishwan@codeaurora.org> Acked-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Yin Kangkai authored
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:
Yin Kangkai <kangkai.yin@linux.intel.com> Signed-off-by:
-
Yin Kangkai authored
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:
-
Russ Gorby authored
renamed spi_driver variable to not be h/w specific set driver name to use DRVNAME define removed commented-out define Signed-off-by:
Russ Gorby <russ.gorby@intel.com> Signed-off-by:
-
Russ Gorby authored
The probe routine should call spi_setup() to configure the SPI bus so it can properly communicate with the device. E.g. the device operates in SPI mode 1. Called spi_setup to configure SPI mode, max_speed_hz, and bpw Signed-off-by:
-
Russ Gorby authored
Platforms containing the 6260 can run up to 25Mhz. For these platforms set max_speed_hz to 25Mhz. Signed-off-by:
-
Russ Gorby authored
driver should support 32bit SPI transfers. The boolean variable only allowed 8/16. Changed to support 8/16/32 for future enabling of 32 bpw. Signed-off-by:
-
Russ Gorby authored
This driver is a SPI protocol driver and has no DMA ops associated with the device so the call will fail. Furthermore, the DMA allocation made here will be used by the SPI controller driver (parent dev) so it makes sense to pass that device instead. Signed-off-by:
-
Russ Gorby authored
The port ops must be set AFTER calling port init as that function zeroes the structure Signed-off-by:
-
Jiri Olsa authored
seems there's no longer need for using con_buf/conf_buf_mtx as vcs_read/vcs_write buffer for user's data. The do_con_write function, that was the other user of this, is currently using its own kmalloc-ed buffer. Not sure when this got changed, as I was able to find this code in 2.6.9, but it's already gone as far as current git history goes - 2.6.12-rc2. AFAICS there's a behaviour change with the current change. The lseek is not completely mutually exclusive with the vcs_read/vcs_write - the file->f_pos might get updated via lseek callback during the vcs_read/vcs_write processing. I tried to find out if the prefered behaviour is to keep this in sync within read/write/lseek functions, but I did not find any pattern on different places. I guess if user end up calling write/lseek from different threads she should know what she's doing. If needed we could use dedicated fd mutex/buffer. Signed-off-by:
Jiri Olsa <jolsa@redhat.com> Signed-off-by:
-
Jiri Olsa authored
there's a race between vcs's lseek handler and VC release. The lseek handler does not hold console_lock and touches VC's size info. If during this the VC got released, there's an access violation. Following program triggers the issue for me: [SNIP] #define _BSD_SOURCE #include <stdio.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <sys/ioctl.h> #include <linux/vt.h> #include <unistd.h> #include <errno.h> static int run_seek(void) { while(1) { int fd; fd = open("./vcs30", O_RDWR); while(lseek(fd, 0, 0) != -1); close(fd); } } static int open_ioctl_tty(void) { return open("/dev/tty1", O_RDWR); } static int do_ioctl(int fd, int req, int i) { return ioctl(fd, req, i); } #define INIT(i) do_ioctl(ioctl_fd, VT_ACTIVATE, i) #define SHUT(i) do_ioctl(ioctl_fd, VT_DISALLOCATE, i) int main(int argc, char **argv) { int ioctl_fd = open_ioctl_tty(); if (ioctl < 0) { perror("open tty1 failed\n"); return -1; } if ((-1 == mknod("vcs30", S_IFCHR|0666, makedev(7, 30))) && (errno != EEXIST)) { printf("errno %d\n", errno); perror("failed to create vcs30"); return -1; } do_ioctl(ioctl_fd, VT_LOCKSWITCH, 0); if (!fork()) run_seek(); while(1) { INIT(30); SHUT(30); } return 0; } [SNIP] Signed-off-by: -
Mandeep Singh Baines authored
printk()s without a priority level default to KERN_WARNING. To reduce noise at KERN_WARNING, this patch set the priority level appriopriately for unleveled printks()s. This should be useful to folks that look at dmesg warnings closely. Signed-off-by:
Mandeep Singh Baines <msb@chromium.org> Signed-off-by:
-
Mike Frysinger authored
This converts the existing bfin_jtag_comm TTY driver to the HVC layer so that the common HVC code can worry about all of the TTY/polling crap and leave the Blackfin code to worry about the Blackfin bits. Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
-
Arthur Taylor authored
virtual console: add keyboard mode OFF Add a new mode for the virtual console keyboard OFF in which all input other than shift keys is ignored. Prevents vt input buffers from overflowing when a program opens but doesn't read from a tty, like X11 using evdev for input. Signed-off-by:
Arthur Taylor <art@ified.ca> Signed-off-by:
-
- Feb 04, 2011
-
-
Stephen Boyd authored
The inline assembly differences for v6 vs. v7 in the hvc_dcc driver are purely optimizations. On a v7 processor, an mrc with the pc sets the condition codes to the 28-31 bits of the register being read. It just so happens that the TX/RX full bits the DCC driver is testing for are high enough in the register to be put into the condition codes. On a v6 processor, this "feature" isn't implemented and thus we have to do the usual read, mask, test operations to check for TX/RX full. Since we already test the RX/TX full bits before calling __dcc_getchar() and __dcc_putchar() we don't actually need to do anything special for v7 over v6. The only difference is in hvc_dcc_get_chars(). We would test RX full, poll RX full, and then read a character from the buffer, whereas now we will test RX full, read a character from the buffer, and then test RX full again for the second iteration of the loop. It doesn't seem possible for the buffer to go from full to empty between testing the RX full and reading a character. Therefore, replace the v7 versions with the v6 versions and everything works the same. Acked-by:
Tony Lindgren <tony@atomide.com> Cc: Arnd Bergmann <arnd@arndb.de> Acked-by:
Nicolas Pitre <nicolas.pitre@linaro.org> Cc: Daniel Walker <dwalker@codeaurora.org> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Stephen Boyd authored
Casting and anding with 0xff is unnecessary in hvc_dcc_put_chars() since buf is already a char[]. __dcc_get_char() can't return an int less than 0 since it only returns a char. Simplify the if statement in hvc_dcc_get_chars() to take this into account. Cc: Daniel Walker <dwalker@codeaurora.org> Signed-off-by:
-
Stephen Boyd authored
Without marking the asm __dcc_getstatus() volatile my compiler decides it can cache the value of __ret in a register and then check the value of it continually in hvc_dcc_put_chars() (I had to replace get_wait/put_wait with 1 and fixup the branch otherwise my disassembler barfed on __dcc_(get|put)char). 00000000 <hvc_dcc_put_chars>: 0: ee103e11 mrc 14, 0, r3, cr0, cr1, {0} 4: e3a0c000 mov ip, #0 ; 0x0 8: e2033202 and r3, r3, #536870912 ; 0x20000000 c: ea000006 b 2c <hvc_dcc_put_chars+0x2c> 10: e3530000 cmp r3, #0 ; 0x0 14: 1afffffd bne 10 <hvc_dcc_put_chars+0x10> 18: e7d1000c ldrb r0, [r1, ip] 1c: ee10fe11 mrc 14, 0, pc, cr0, cr1, {0} 20: 2afffffd bcs 1c <hvc_dcc_put_chars+0x1c> 24: ee000e15 mcr 14, 0, r0, cr0, cr5, {0} 28: e28cc001 add ip, ip, #1 ; 0x1 2c: e15c0002 cmp ip, r2 30: bafffff6 blt 10 <hvc_dcc_put_chars+0x10> 34: e1a00002 mov r0, r2 38: e12fff1e bx lr As you can see, the value of the mrc is checked against DCC_STATUS_TX (bit 29) and then stored in r3 for later use. Marking the asm volatile produces the following: 00000000 <hvc_dcc_put_chars>: 0: e3a03000 mov r3, #0 ; 0x0 4: ea000007 b 28 <hvc_dcc_put_chars+0x28> 8: ee100e11 mrc 14, 0, r0, cr0, cr1, {0} c: e3100202 tst r0, #536870912 ; 0x20000000 10: 1afffffc bne 8 <hvc_dcc_put_chars+0x8> 14: e7d10003 ldrb r0, [r1, r3] 18: ee10fe11 mrc 14, 0, pc, cr0, cr1, {0} 1c: 2afffffd bcs 18 <hvc_dcc_put_chars+0x18> 20: ee000e15 mcr 14, 0, r0, cr0, cr5, {0} 24: e2833001 add r3, r3, #1 ; 0x1 28: e1530002 cmp r3, r2 2c: bafffff5 blt 8 <hvc_dcc_put_chars+0x8> 30: e1a00002 mov r0, r2 34: e12fff1e bx lr which looks better and actually works. Mark all the inline assembly in this file as volatile since we don't want the compiler to optimize away these statements or move them around in any way. Acked-by:
-
- Feb 03, 2011
-
-
Tomoya MORINAGA authored
PCH_DMA is not always enabled when a user uses PCH_UART. Since overhead of DMA is not small, in case of low frequent communication, without DMA is better. Thus, "select PCH_DMA" and DMADEVICES are unnecessary Signed-off-by:
Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by:
-
Tomoya MORINAGA authored
Support ML7213 device of OKI SEMICONDUCTOR. ML7213 is companion chip of Intel Atom E6xx series for IVI(In-Vehicle Infotainment). ML7213 is completely compatible for Intel EG20T PCH. Signed-off-by:
-
Tejun Heo authored
m68k_serial->tqueue_hangup is unused. Remove it. Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: Greg Ungerer <gerg@uclinux.org> Signed-off-by:
-
Yin Kangkai authored
On some platforms, we need to restore the console speed on resume even it was not suspended (no_console_suspend), and on others we don't have to do that. So don't care about the "console_suspend_enabled" and unconditionally reset the console speed if it is a console. This is actually a redo of ba15ab0e (Set proper console speed on resume if console suspend is disabled) from Deepak Saxena. I also tried to investigate more to find out if this change will break others, here is what I've found out: commit 891b9dd1 Author: Jason Wang <jason77.wang@gmail.com> serial-core: restore termios settings when resume console ports commit ca2e71aa Author: Jason Wang <jason77.wang@gmail.com> serial-core: skip call set_termios/console_start when no_console_suspend commit 4547be78 Author: Stanislav Brabec <sbrabec@suse.cz> serial-core: resume serial hardware with no_console_suspend commit ba15ab0e Author: Deepak Saxena <dsaxena@laptop.org> Set proper console speed on resume if console suspend is disabled from ba15ab0e, we learned that, even if the console suspend is disabled (when no_console_suspend is set), we may still need to "reset the port to the state it was in before we suspended." Then with 4547be78, this piece of code is removed. And then Jason Wang added that back in ca2e71aa and 891b9dd1, to fix some breakage on OMAP3EVM platform. From ca2e71aa we learned that the "set_termios" things is actually needed by both console is suspended and not suspended. That's why I removed the console_suspended_enabled condition, and only call console_start() when we actually suspeneded it. I also noticed in this thread: http://marc.info/?t=129079257100004&r=1&w=2 , which talked about on some platforms, UART HW will be cut power whether or not we set no_console_suspend, and then on resume it does not work quite well. I have a similar HW, and this patch fixed this issue, don't know if this patch also works on their platforms. [Update: Stanislav tested this patch on Zaurus and reported it improves the situation. Thanks.] CC: Greg KH <greg@kroah.com> CC: Deepak Saxena <dsaxena@laptop.org> CC: Jason Wang <jason77.wang@gmail.com> CC: Stanislav Brabec <sbrabec@suse.cz> CC: Daniel Drake <dsd@laptop.org> Signed-off-by:
-
Dan Carpenter authored
This is used to store the spi_device ->modalias so they have to be the same size. SPI_NAME_SIZE is 32. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Tejun Heo authored
flush_scheduled_work() is scheduled to be deprecated. Explicitly sync flush the used work items instead. Note that before this change, flush_scheduled_work() wouldn't have properly flushed tty->buf.work if it were on timer. Signed-off-by:
-
Jarkko Nikula authored
OMAP can do also dynamic idling so wake-up enable register should be set also while system is running. If UART_OMAP_WER is not set, then for instance the RX activity cannot wake up the UART port that is sleeping. This RX wake-up feature was working when the 8250 driver was used instead of omap-serial. Reason for this is that the 8250 doesn't set the UART_OMAP_WER and then arch/arm/mach-omap2/pm34xx.c ends up saving and restoring the reset default which is the same than value OMAP_UART_WER_MOD_WKUP here. Fix this by moving the conditional UART_OMAP_WER write from serial_omap_pm into serial_omap_startup where wake-up bits are set unconditionally. Signed-off-by:
Jarkko Nikula <jhnikula@gmail.com> Cc: Govindraj.R <govindraj.raja@ti.com> Signed-off-by:
-
Thomas Weber authored
Magic SysRq key is not working for OMAP on new serial console ttyOx because SUPPORT_SYSRQ is not defined for omap-serial. This patch defines SUPPORT_SYSRQ in omap-serial and enables handling of Magic SysRq character. Further there is an issue of losing first break character. Removing the reset of the lsr_break_flag fixes this issue. Signed-off-by:
Thomas Weber <weber@corscience.de> Acked-by:
Govindraj.R <govindraj.raja@ti.com> Tested-by:
Manjunath G Kondaiah <manjugk@ti.com> Acked-by:
Kevin Hilman <khilman@ti.com> Signed-off-by:
-
Russ Gorby authored
Some platform attributes (e.g. max_hz, use_dma) were being intuited from the modem type. These things should be specified by the platform data. Added max_hz, use_dma to ifx_modem_platform_data definition, replaced is_6160 w/ modem_type, and changed clients accordingly Signed-off-by:
-
Feng Tang authored
This is kind of a revert for commit 669b7a09 "hsu: add a periodic timer to check dma rx channel", which is a workaround for a bug in A0 stepping silicon, where a dma rx data timeout is missing for some case. Since new silicon has fixed it and the old version is phasing out, no need to carry on it any more. Signed-off-by:
Feng Tang <feng.tang@intel.com> Signed-off-by:
-
Vasiliy Kulikov authored
sport->port.irq is unsigned, check for <0 doesn't make sense. Explicitly cast it to int to check for error. Signed-off-by:
Vasiliy Kulikov <segoon@openwall.com> Signed-off-by:
-
- Jan 26, 2011
-
-
Torben Hohn authored
The -rt patches change the console_semaphore to console_mutex. As a result, a quite large chunk of the patches changes all acquire/release_console_sem() to acquire/release_console_mutex() This commit makes things use more neutral function names which dont make implications about the underlying lock. The only real change is the return value of console_trylock which is inverted from try_acquire_console_sem() This patch also paves the way to switching console_sem from a semaphore to a mutex. [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: make console_trylock return 1 on success, per Geert] Signed-off-by:
Torben Hohn <torbenh@gmx.de> Cc: Thomas Gleixner <tglx@tglx.de> Cc: Greg KH <gregkh@suse.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Jan 23, 2011
-
-
Randy Dunlap authored
Fix build errors by selecting SERIAL_CORE: ERROR: "uart_register_driver" [drivers/tty/serial/apbuart.ko] undefined! ERROR: "uart_write_wakeup" [drivers/tty/serial/apbuart.ko] undefined! ERROR: "uart_update_timeout" [drivers/tty/serial/apbuart.ko] undefined! ERROR: "uart_get_divisor" [drivers/tty/serial/apbuart.ko] undefined! ERROR: "uart_get_baud_rate" [drivers/tty/serial/apbuart.ko] undefined! ERROR: "uart_add_one_port" [drivers/tty/serial/apbuart.ko] undefined! ERROR: "uart_unregister_driver" [drivers/tty/serial/apbuart.ko] undefined! ERROR: "uart_remove_one_port" [drivers/tty/serial/apbuart.ko] undefined! Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Cc: Daniel Hellstrom <daniel@gaisler.com> Signed-off-by:
-
Paul Fulghum authored
Fix locking in read and write code of n_hdlc line discipline. 2.6.36 replaced lock_kernel() with tty_lock(). The tty mutex is not dropped automatically when the thread sleeps like the BKL. This results in a blocked read or write holding the tty mutex and stalling operations by other devices that use the tty mutex. A review of n_hdlc read and write code shows: 1. neither BKL or tty mutex are required for correct operation 2. read can block while read data is available if data is posted between availability check and call to interruptible_sleep_on() 3. write does not set process state to TASK_INTERRUPTIBLE on each pass through the processing loop which can cause unneeded scheduling of the thread The unnecessary tty mutex references have been removed. Read changed to use same code as n_tty read for completing reads and blocking. Write corrected to set process state to TASK_INTERRUPTIBLE on each pass through processing loop. Signed-off-by:
Paul Fulghum <paulkf@microgate.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Pavel Machek authored
Unbreak Billionton CF bluetooth card. This actually fixes a regression on zaurus. Signed-off-by:
Pavel Machek <pavel@ucw.cz> Cc: stable <stable@kernel.org> Signed-off-by:
-
Kay Sievers authored
This fixes the build warnings in the tty code, and uses the proper function for iterating over the console devices. Signed-off-by:
Kay Sievers <kay.sievers@vrfy.org> Signed-off-by:
-
Dave Airlie authored
With framebuffer handover and multiple GPUs, we get into a position where the fbcon unbinds the vesafb framebuffer for GPU 1, but we still have a radeon framebuffer bound from GPU 0, so we don't unregister the console driver. Then when we tried to bind the new radeon framebuffer for GPU1 we never get to the bind call as we fail due to the console being registered already. This changes the return value to -EBUSY when the driver is already registered and continues to bind for -EBUSY. Signed-off-by:
Dave Airlie <airlied@redhat.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
- Jan 13, 2011
-
-
Greg Kroah-Hartman authored
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: -
Greg Kroah-Hartman authored
As requested by Arnd Bergmann, the hvc drivers are now moved to the drivers/tty/hvc/ directory. The virtio_console.c driver was also moved, as it required the hvc_console.h file to be able to be built, and it really is a hvc driver. Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
- Dec 17, 2010
-
-
Werner Fink authored
This has been in the SuSE kernels for a very long time. Signed-off-by:
Werner Fink <werner@suse.de> Signed-off-by:
-
Kay Sievers authored
tty: add 'active' sysfs attribute to tty0 and console device Userspace can query the actual virtual console, and the configured console devices behind /dev/tt0 and /dev/console. The last entry in the list of devices is the active device, analog to the console= kernel command line option. The attribute supports poll(), which is raised when the virtual console is changed or /dev/console is reconfigured. Signed-off-by:
-
- Dec 16, 2010
-
-
Ken Mills authored
gsm_data_alloc buffer allocation could fail and it is not being checked. Add check for allocated buffer and return if the buffer allocation fails. Signed-off-by:
Ken Mills <ken.k.mills@intel.com> Signed-off-by:
-
Ken Mills authored
Fix message length handling when building header When the message length is greater than 127, the length field in the header is built incorrectly. According to the spec, when the length is less than 128 the length field is a single byte formatted as: bbbbbbb1. When it is greater than 127 then the field is two bytes of the format: bbbbbbb0 bbbbbbbb. Signed-off-by:
-
