This commit refactors the iwctl_giwaplist() function so that the sparse
warning "the frame size of 1292 bytes is larger than 1024 bytes
[-Wframe-larger-than=]" is no more.
The root cause of this warning were two arrays allocated on the stack
and this commit changes this - these arrays are now kmalloc'ed. As a
result the function is refactored and hopefully stil working the same.
I were not able to test these changes so at least the carefull review
is more than welcomed.
Note that my changes has broadened the set of error codes that this
function can return. The new error code is ENOMEM. Luckily, this is
no issue.
Signed-off-by: Konrad Zapalowicz <bergo.torino@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In commit 78a650dc19
there was a typo error
abyVT3226_InitTable -> at3226_init_table
abyVT3226D0_InitTable -> at3226d0_init_table
Shoud be vt3226_init_table and vt3226d0_init_table
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix wFmSequence and wFrameCtl to __le16
Don't restrict to u8, if packet is a duplicate both bytes of __le16 will be
the same.
Fixes warnings
wctl.c:66:9: warning: restricted __le16 degrades to integer
wctl.c:71:56: warning: restricted __le16 degrades to integer
wctl.c:73:49: warning: cast from restricted __le16
wctl.c:83:30: warning: incorrect type in assignment (different base types)
wctl.c:83:30: expected unsigned short [unsigned] [usertype] wFmSequence
wctl.c:83:30: got restricted __le16 [usertype] seq_ctrl
wctl.c:85:28: warning: incorrect type in assignment (different base types)
wctl.c:85:28: expected unsigned short [unsigned] [usertype] wFrameCtl
wctl.c:85:28: got restricted __le16 [usertype] frame_control
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We try to free two pages when only one has been allocated.
Cleanup path is unlikely, so I haven't found any trace that would fit,
but I hope that free_pages_prepare() does catch it.
Cc: stable@vger.kernel.org
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Reviewed-by: Amos Kong <akong@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The generic SPMI example was missing an equal sign in the assignment
of the #size-cells property.
Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
uni_pagedir.readonly is never set. Let's get rid of superfluous check
codes.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The vc_data.vc_uni_pagedir filed is currently long int, supposedly to
be served generically. This, however, leads to lots of cast to
pointer, and rather it worsens the readability significantly.
Actually, we have now only a single uni_pagedir map implementation,
and this won't change likely. So, it'd be much more simple and
error-prone to just use the exact pointer for struct uni_pagedir
instead of long.
Ditto for vc_uni_pagedir_loc. It's a pointer to the uni_pagedir, thus
it can be changed similarly to the exact type.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The vgacon driver prepares a two element array of uni_pagedir_loc and
uses the second item as its own reference counter for sharing the
uni_pagedir. And the code assumes blindly that the second item is
available if the assigned vc_uni_pagedir isn't the standard one, which
might be wrong (although currently it's so).
This patch fixes that wrong assumption, and gives a slight cleanup
along with it: namely, instead of array, just give the uni_pagedir_loc
and a separate refcount variable. It makes the code a bit more
understandable at first glance.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Put architecture-specific assembly code where it belongs,
allowing for support of additional architectures such as arm64 in
the future.
Signed-off-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some backends call hvc_kick() to wakeup the HVC thread from its
slumber upon incoming characters. This however doesn't work
properly because it uses msleep_interruptible() which is mostly
immune to wake_up_process(). It will basically go back to sleep
until the timeout is expired (only signals can really wake it).
Replace it with a simple shedule_timeout_interruptible() instead,
which may wakeup earlier every now and then but we really don't
care in this case.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit extends the compatible string list of the xhci-platform
binding with the new "renesas,xhci-r8a7790" and "renesas,xhci-r8a7791"
compatible strings. It is used to describe the xHCI controller which
is available in the R-Car H2 and M2 SoCs.
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some platforms (such as the Renesas R-Car) need to initialize some specific
registers after xhci driver calls usb_add_hcd() and before the driver calls
xhci_run(). So, this patch adds the xhci_plat_start() function.
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
regulator_get_optional() doesn't hold an exclusive reference to
the regulator. Fix the documentation and reword the exclusive
documentation to fix the grammatical error "this reference is
held".
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Most other mainstream terminals support "xterm256" colours, which means
people sometimes use these blindly without checking capabilities.
Because of hardware limitations of VGA consoles, colours are downgraded to
16 foregrounds and 8 backgrounds. On fbdev consoles it would be possible
to support them without quality loss, but adding that would require quite a
large amount of code.
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 5f5c9ae56c
"serial_core: Unregister console in uart_remove_one_port()"
fixed a crash where a serial port was removed but
not deregistered as a console.
There is a side effect of that commit for platforms having serial consoles
and of_serial configured (CONFIG_SERIAL_OF_PLATFORM). The serial console
is disabled midway through the boot process.
This cessation of the serial console affects PowerPC computers
such as the MVME5100 and SAM440EP.
The sequence is:
bootconsole [udbg0] enabled
....
serial8250/16550 driver initialises and registers its UARTS,
one of these is the serial console.
console [ttyS0] enabled
....
of_serial probes "platform" devices, registering them as it goes.
One of these is the serial console.
console [ttyS0] disabled.
The disabling of the serial console is due to:
a. unregister_console in printk not clearing the
CONS_ENABLED bit in the console flags,
even though it has announced that the console is disabled; and
b. of_platform_serial_probe in of_serial not setting the port type
before it registers with serial8250_register_8250_port.
This patch ensures that the serial console is re-enabled when of_serial
registers a serial port that corresponds to the designated console.
Signed-off-by: Stephen Chivers <schivers@csc.com>
Tested-by: Stephen Chivers <schivers@csc.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [unregister_console]
Cc: stable <stable@vger.kernel.org> # 3.15
===
The above failure was identified in Linux-3.15-rc2.
Tested using MVME5100 and SAM440EP PowerPC computers with
kernels built from Linux-3.15-rc5 and tty-next.
The continued operation of the serial console is vital for computers
such as the MVME5100 as that Single Board Computer does not
have any grapical/display hardware.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8250 uart driver currently supports only software assisted hw flow
control. The software assisted hw flow control maintains a hw_stopped
flag in the tty structure to stop and start transmission and use modem
status interrupt for the event to drive the handshake signals. This is
not needed if hw has flow control capabilities. This patch adds a
DT attribute for enabling hw flow control for a uart port. Also skip
stop and start if this flag is present in flag field of the port
structure.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
CC: Rob Herring <robh+dt@kernel.org>
CC: Pawel Moll <pawel.moll@arm.com>
CC: Mark Rutland <mark.rutland@arm.com>
CC: Ian Campbell <ijc+devicetree@hellion.org.uk>
CC: Kumar Gala <galak@codeaurora.org>
CC: Randy Dunlap <rdunlap@infradead.org>
CC: Jiri Slaby <jslaby@suse.cz>
CC: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On sam9x5, dedicated CTS (and RTS) pins are unusable together with the
LCDC, the EMAC, or the MMC because they share the same line.
Moreover, the USART controller doesn't handle DTR/DSR/DCD/RI signals,
so we have to control them via GPIO.
This patch permits to use GPIOs to control the CTS/RTS/DTR/DSR/DCD/RI
signals.
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch add some helpers to control modem lines (CTS/RTS/DSR...) via
GPIO.
This will be useful for many boards which have a serial controller that
only handle CTS/RTS pins (or even just RX/TX).
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
RTS pin is an active low pin.
For now, this doesn't change anything as the ACTIVE_LOW flag is not
handled in atmel_serial, but it will be in 3.16.
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sccnxp_timer() is triggered only by timer, so there are no need to
check for timer_pending().
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch disables the receiver ready interrupt for imx_stop_rx.
It reduces the interrupt numbers when the uart is going to close
or suspend.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The DMA wait queue makes the code very complicated:
For RX, the @->stop_rx hook does not really stop the RX;
For TX, the @->stop_tx hook does not really stop the TX.
The above make the imx_shutdown has to wait the RX/TX DMA to be finished.
In order to make code more simple, this patch removes the DMA wait queue.
By calling the dmaengine_terminate_all, this patch makes the RX stops
immediately after we call the @->stop_rx hook, so does the TX.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the imx_startup(), we will reset the uart port which will reset all
the FIFOs, including the URXD.
So the code to clear the RX FIFO is redundant. Just remove it.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Current code resets the uart port only when it supports the irda mode.
In actually, we also need to reset the uart port in the non-irda mode.
A hang was caught in the following case:
UART A transmits data to the other end. But the transmission maybe
terminated. In some corner case, the TX FIFO maybe not empty.
The kernel will hang at the imx_set_termios():
............................................................
while (!(readl(sport->port.membase + USR2) & USR2_TXDC))
barrier();
............................................................
This patch resets the uart port all the time in the imx_startup().
And fix the hang.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bit 7 of UCR3 is described in the i.MX reference manuals (with the exception
of i.MX1) as follows:
ADNIMP: Autobaud Detection Not Improved-. Disables new features of
autobaud detection (See Baud Rate Automatic Detection
Protocol, for more details).
0 Autobaud detection new features selected
1 Keep old autobaud detection mechanism
The "new features" mechanism occasionally cause the receiver to get out of sync
and continuously produce received characters of '\xff'.
In order to reproduce the problem:
$ stty -F /dev/ttymxc0 19200
- Change the terminal baudrate to 19200
- Type in the console and it should look good
- Change the terminal baudrate back to 115200
- Type 'b' in the console, then a stream of garbage characters is seen.
Also rename the bit definition as per the reference manual.
Tested on mx6q, mx6dl, mx6solo and mx53.
Based on a patch from Eric Nelson for U-boot.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Tested-by: Eric Nelson <eric.nelson@boundarydevices.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This Multi-IO card has one serial 16550-like and one parallel port connector.
Here's the lspci output, after this commit is applied:
03:07.0 Serial controller: Device 4348:5053 (rev 10) (prog-if 02 [16550])
Subsystem: Device 4348:5053
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 21
Region 0: I/O ports at cf00 [size=8]
Region 1: I/O ports at ce00 [size=8]
Kernel driver in use: parport_serial
Kernel modules: 8250_pci, parport_serial
This commit adds an entry with the device ID to the blacklist declared in
8250_pci to prevent the driver from taking ownership. Also, and as was done
for the 2S/1P variant, add a quirk to skip autodetection and set the correct
type to 16550A clone.
Proper entries are added to parport_serial, to support the device parallel
and serial ports.
Cc: Gianluca Anzolin <gianluca@sottospazio.it>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add missing specification of efm32_uart_exit as module_exit.
This fixes the following compilation warning:
drivers/tty/serial/efm32-uart.c:840:123: warning: ‘efm32_uart_exit’ defined but not used [-Wunused-function]
Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
Cc: Jiri Slaby <jslaby@suse.cz>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add format and argument checking and fix misuses in the dbg macro.
Add __printf
Use %pR for resource
Add #include guard to samsung.h
Move static functions from .h to .c
Use vscnprintf instead of length unguarded vsprintf
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Don't activate the TX Space available IRQ on startup, or a simple
$ cat /dev/ttyHSU0
will cause an endless amount of IRQs, as there is always space in
the TX FIFO available if no data is going to be sent.
Also correct comments for IRQ names (RX and TX swapped).
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@men.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On my test platform (B2020/STiH416) the serial port issues bad characters
during the initial message avalanche as the console comes up. The problem
also occurs when dense(ish) I/O is done using the polled I/O interface.
The problem is fixed for me by using the FIFO half-empty bit rather than
FIFO full bit. Note that using the half-empty bit causes the FIFO to be
managed in a similar way to interrupt based I/O (i.e. where the hardware
gets best test coverage).
Running the FIFO half full will have no impact (good or bad) on console
performance. The UART will still remain fully saturated and the busy-wait
until the FIFO is empty in asc_console_write() will complete at the same
time.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>