Merge my system logging cleanups, triggered by the broken '\n' patches.
The line continuation handling has been broken basically forever, and
the code to handle the system log records was both confusing and
dubious. And it would do entirely the wrong thing unless you always had
a terminating newline, partly because it couldn't actually see whether a
message was marked KERN_CONT or not (but partly because the LOG_CONT
handling in the recording code was rather confusing too).
This re-introduces a real semantically meaningful KERN_CONT, and fixes
the few places I noticed where it was missing. There are probably more
missing cases, since KERN_CONT hasn't actually had any semantic meaning
for at least four years (other than the checkpatch meaning of "no log
level necessary, this is a continuation line").
This also allows the combination of KERN_CONT and a log level. In that
case the log level will be ignored if the merging with a previous line
is successful, but if a new record is needed, that new record will now
get the right log level.
That also means that you can at least in theory combine KERN_CONT with
the "pr_info()" style helpers, although any use of pr_fmt() prefixing
would make that just result in a mess, of course (the prefix would end
up in the middle of a continuing line).
* printk-cleanups:
printk: make reading the kernel log flush pending lines
printk: re-organize log_output() to be more legible
printk: split out core logging code into helper function
printk: reinstate KERN_CONT for printing continuation lines
Long long ago the kernel log buffer was a buffered stream of bytes, very
much like stdio in user space. It supported log levels by scanning the
stream and noticing the log level markers at the beginning of each line,
but if you wanted to print a partial line in multiple chunks, you just
did multiple printk() calls, and it just automatically worked.
Except when it didn't, and you had very confusing output when different
lines got all mixed up with each other. Then you got fragment lines
mixing with each other, or with non-fragment lines, because it was
traditionally impossible to tell whether a printk() call was a
continuation or not.
To at least help clarify the issue of continuation lines, we added a
KERN_CONT marker back in 2007 to mark continuation lines:
4749252776 ("printk: add KERN_CONT annotation").
That continuation marker was initially an empty string, and didn't
actuall make any semantic difference. But it at least made it possible
to annotate the source code, and have check-patch notice that a printk()
didn't need or want a log level marker, because it was a continuation of
a previous line.
To avoid the ambiguity between a continuation line that had that
KERN_CONT marker, and a printk with no level information at all, we then
in 2009 made KERN_CONT be a real log level marker which meant that we
could now reliably tell the difference between the two cases.
5fd29d6ccb ("printk: clean up handling of log-levels and newlines")
and we could take advantage of that to make sure we didn't mix up
continuation lines with lines that just didn't have any loglevel at all.
Then, in 2012, the kernel log buffer was changed to be a "record" based
log, where each line was a record that has a loglevel and a timestamp.
You can see the beginning of that conversion in commits
e11fea92e1 ("kmsg: export printk records to the /dev/kmsg interface")
7ff9554bb5 ("printk: convert byte-buffer to variable-length record buffer")
with a number of follow-up commits to fix some painful fallout from that
conversion. Over all, it took a couple of months to sort out most of
it. But the upside was that you could have concurrent readers (and
writers) of the kernel log and not have lines with mixed output in them.
And one particular pain-point for the record-based kernel logging was
exactly the fragmentary lines that are generated in smaller chunks. In
order to still log them as one recrod, the continuation lines need to be
attached to the previous record properly.
However the explicit continuation record marker that is actually useful
for this exact case was actually removed in aroundm the same time by commit
61e99ab8e3 ("printk: remove the now unnecessary "C" annotation for KERN_CONT")
due to the incorrect belief that KERN_CONT wasn't meaningful. The
ambiguity between "is this a continuation line" or "is this a plain
printk with no log level information" was reintroduced, and in fact
became an even bigger pain point because there was now the whole
record-level merging of kernel messages going on.
This patch reinstates the KERN_CONT as a real non-empty string marker,
so that the ambiguity is fixed once again.
But it's not a plain revert of that original removal: in the four years
since we made KERN_CONT an empty string again, not only has the format
of the log level markers changed, we've also had some usage changes in
this area.
For example, some ACPI code seems to use KERN_CONT _together_ with a log
level, and now uses both the KERN_CONT marker and (for example) a
KERN_INFO marker to show that it's an informational continuation of a
line.
Which is actually not a bad idea - if the continuation line cannot be
attached to its predecessor, without the log level information we don't
know what log level to assign to it (and we traditionally just assigned
it the default loglevel). So having both a log level and the KERN_CONT
marker is not necessarily a bad idea, but it does mean that we need to
actually iterate over potentially multiple markers, rather than just a
single one.
Also, since KERN_CONT was still conceptually needed, and encouraged, but
didn't actually _do_ anything, we've also had the reverse problem:
rather than having too many annotations it has too few, and there is bit
rot with code that no longer marks the continuation lines with the
KERN_CONT marker.
So this patch not only re-instates the non-empty KERN_CONT marker, it
also fixes up the cases of bit-rot I noticed in my own logs.
There are probably other cases where KERN_CONT will be needed to be
added, either because it is new code that never dealt with the need for
KERN_CONT, or old code that has bitrotted without anybody noticing.
That said, we should strive to avoid the need for KERN_CONT. It does
result in real problems for logging, and should generally not be seen as
a good feature. If we some day can get rid of the feature entirely,
because nobody does any fragmented printk calls, that would be lovely.
But until that point, let's at mark the code that relies on the hacky
multi-fragment kernel printk's. Not only does it avoid the ambiguity,
it also annotates code as "maybe this would be good to fix some day".
(That said, particularly during single-threaded bootup, the downsides of
KERN_CONT are very limited. Things get much hairier when you have
multiple threads going on and user level reading and writing logs too).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Here is the big TTY and Serial patch set for 4.9-rc1.
It also includes some drivers/dma/ changes, as those were needed by some
serial drivers, and they were all acked by the DMA maintainer. Also in
here is the long-suffering ACPI SPCR patchset, which was passed around
from maintainer to maintainer like a hot-potato. Seems I was the
sucker^Wlucky one. All of those patches have been acked by the various
subsystem maintainers as well.
All of this has been in linux-next with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iFYEABECABYFAlfyNjEPHGdyZWdAa3JvYWguY29tAAoJEDFH1A3bLfspwIcAn2uN
qCD8xQJ0Cs61hD1nUzhNygG8AJ94I4zz/fPGpyh/CtJfLQwtUdLhNA==
=Rken
-----END PGP SIGNATURE-----
Merge tag 'tty-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty and serial updates from Greg KH:
"Here is the big tty and serial patch set for 4.9-rc1.
It also includes some drivers/dma/ changes, as those were needed by
some serial drivers, and they were all acked by the DMA maintainer.
Also in here is the long-suffering ACPI SPCR patchset, which was
passed around from maintainer to maintainer like a hot-potato. Seems I
was the sucker^Wlucky one. All of those patches have been acked by the
various subsystem maintainers as well.
All of this has been in linux-next with no reported issues"
* tag 'tty-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (111 commits)
Revert "serial: pl011: add console matching function"
MAINTAINERS: update entry for atmel_serial driver
serial: pl011: add console matching function
ARM64: ACPI: enable ACPI_SPCR_TABLE
ACPI: parse SPCR and enable matching console
of/serial: move earlycon early_param handling to serial
Revert "drivers/tty: Explicitly pass current to show_stack"
tty: amba-pl011: Don't complain on -EPROBE_DEFER when no irq
nios2: dts: 10m50: Add tx-threshold parameter
serial: 8250: Set Altera 16550 TX FIFO Threshold
serial: 8250: of: Load TX FIFO Threshold from DT
Documentation: dt: serial: Add TX FIFO threshold parameter
drivers/tty: Explicitly pass current to show_stack
serial: imx: Fix DCD reading
serial: stm32: mark symbols static where possible
serial: xuartps: Add some register initialisation to cdns_early_console_setup()
serial: xuartps: Removed unwanted checks while reading the error conditions
serial: xuartps: Rewrite the interrupt handling logic
serial: stm32: use mapbase instead of membase for DMA
tty/serial: atmel: fix fractional baud rate computation
...
Here's the "big" char and misc driver update for 4.9-rc1.
Lots of little things here, all over the driver tree for subsystems that
flow through me. Nothing major that I can discern, full details are in
the shortlog.
All have been in the linux-next tree with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iFUEABECABYFAlfyOIQPHGdyZWdAa3JvYWguY29tAAoJEDFH1A3bLfsp9OQAlRy3
gSKfQUlXjTs96Bx/I5PtWysAn0r8nyKZoP1oSgsTddOCEeXngTXc
=4uPs
-----END PGP SIGNATURE-----
Merge tag 'char-misc-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver updates from Greg KH:
"Here's the "big" char and misc driver update for 4.9-rc1.
Lots of little things here, all over the driver tree for subsystems
that flow through me. Nothing major that I can discern, full details
are in the shortlog.
All have been in the linux-next tree with no reported issues"
* tag 'char-misc-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (144 commits)
drivers/misc/hpilo: Changes to support new security states in iLO5 FW
at25: fix debug and error messaging
misc/genwqe: ensure zero initialization
vme: fake: remove unexpected unlock in fake_master_set()
vme: fake: mark symbols static where possible
spmi: pmic-arb: Return an error code if sanity check fails
Drivers: hv: get rid of id in struct vmbus_channel
Drivers: hv: make VMBus bus ids persistent
mcb: Add a dma_device to mcb_device
mcb: Enable PCI bus mastering by default
mei: stop the stall timer worker if not needed
clk: probe common clock drivers earlier
vme: fake: fix build for 64-bit dma_addr_t
ttyprintk: Neaten and simplify printing
mei: me: add kaby point device ids
coresight: tmc: mark symbols static where possible
coresight: perf: deal with error condition properly
Drivers: hv: hv_util: Avoid dynamic allocation in time synch
fpga manager: Add hardware dependency to Zynq driver
Drivers: hv: utils: Support TimeSync version 4.0 protocol samples.
...
* device-properties:
serial: 8250_dw: Add quirk for APM X-Gene SoC
ACPI / LPSS: Provide build-in properties of the UART
ACPI / APD: Provide build-in properties of the UART
driver core: Don't leak secondary fwnode on device removal
This reverts commit 8b8f347d3a as it
causes build errors in linux-next
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Aleksey Makarov <aleksey.makarov@linaro.org>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds function pl011_console_match() that implements
method match of struct console. It allows to match consoles against
data specified in a string, for example taken from command line or
compiled by ACPI SPCR table handler.
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Tested-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
'ARM Server Base Boot Requiremets' [1] mentions SPCR (Serial Port
Console Redirection Table) [2] as a mandatory ACPI table that
specifies the configuration of serial console.
Defer initialization of DT earlycon until ACPI/DT decision is made.
Parse the ACPI SPCR table, setup earlycon if required,
enable specified console.
Thanks to Peter Hurley for explaining how this should work.
[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
[2] https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Tested-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We have multiple "earlycon" early_param handlers - merge the DT one into
the main earlycon one. It's a cleanup that also will be useful
to defer setting up DT console until ACPI/DT decision is made.
Rename the exported function to avoid clashing with the function from
arch/microblaze/kernel/prom.c
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Tested-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 9f12cea96f.
Mark writes:
Unfortunately, this patch will result in erroneous stack traces
on some architectures. Sorry about this; I should have verified
this more thoroughly before sending the series out.
Please drop the patch at your earliest convenience.
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Don't complain on -EPROBE_DEFER when attempting to get the irq.
the driver probe will be retried later.
Cc: Russell King <linux@armlinux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Altera 16550 soft IP UART requires 2 additional registers for
TX FIFO threshold support. These 2 registers enable the TX FIFO
Low Watermark and set the TX FIFO Low Watermark.
Set the TX FIFO threshold to the FIFO size - tx_loadsz.
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Initialize the tx_loadsz parameter from passed in devicetree
tx-threshold parameter.
The tx_loadsz is calculated as the number of bytes to fill FIFO
when tx-threshold is triggered.
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As noted in commit:
81539169f2 ("x86/dumpstack: Remove NULL task pointer convention")
... having a NULL task parameter imply current leads to subtle bugs in stack
walking code (so far seen on both 86 and arm64), makes callsites harder to
read, and is unnecessary as all callers have access to current.
As a step towards removing the problematic NULL-implies-current idiom entirely,
have the sysrq code explicitly pass current to show_stack.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The USR2_DCDIN bit is tested for in register usr1. As the name
suggests the usr2 register should be used instead. This fixes
reading the Carrier detect status.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Fixes: 90ebc48386 ("serial: imx: repair and complete handshaking")
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: <stable@vger.kernel.org> # 4.5+
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We get 2 warnings when building kernel with W=1:
drivers/tty/serial/stm32-usart.c:63:5: warning: no previous prototype for 'stm32_pending_rx' [-Wmissing-prototypes]
drivers/tty/serial/stm32-usart.c:88:15: warning: no previous prototype for 'stm32_get_char' [-Wmissing-prototypes]
In fact, these two functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add initialisation of control register and baud rate to
cdns_early_console_setup(), required when running kernel standalone
without a boot loader. Baud rate is only initialised when specified in
earlycon command-line option, otherwise it is assumed this has been
set by a boot loader. Updated Documentation/kernel-parameters.txt
accordingly.
Signed-off-by: Scott Telford <stelford@cadence.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch Remove the unwated checks while reading the parity,framing,
overrun and Break detection errors.
Signed-off-by: Nava kishore Manne <navam@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
[stelford@cadence.com: cherry picked from
https://github.com/Xilinx/linux-xlnx commit
b1cf74970df5470ffbc8e7876a9edf5e3498ef94]
Signed-off-by: Scott Telford <stelford@cadence.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The existing interrupt handling logic has following issues.
- Upon a parity error with default configuration, the control
never comes out of the ISR thereby hanging Linux.
- The error handling logic around framing and parity error are buggy.
There are chances that the errors will never be captured.
This patch ensures that the status registers are cleared on all cases so
that a hang situation never arises.
Signed-off-by: Anirudha Sarangi <anirudh@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
[stelford@cadence.com: cherry picked from
https://github.com/Xilinx/linux-xlnx commit
ac297e20d399850d7a8e373b6eccf2e183c15165 with manual conflict resolution]
Signed-off-by: Scott Telford <stelford@cadence.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Building this driver with a 64-bit dma_addr_t type results in
a compiler warning:
drivers/tty/serial/stm32-usart.c: In function 'stm32_of_dma_rx_probe':
drivers/tty/serial/stm32-usart.c:746:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
drivers/tty/serial/stm32-usart.c: In function 'stm32_of_dma_tx_probe':
drivers/tty/serial/stm32-usart.c:818:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
While the type conversion here is harmless, this hints at a different
problem: we pass an __iomem pointer into a DMA engine, which expects
a phys_addr_t. This happens to work because stm32 has no MMU and
ioremap() is an identity mapping here, but it's still an incorrect
API use. Using dma_addr_t is doubly wrong here, because that would
be the result of dma_map_single() rather than the physical address.
Using the mapbase instead fixes multiple issues:
- the warning is gone
- we don't go through ioremap in error
- the cast is gone, making it use the correct resource_size_t/phys_addr_t
type in the process.
Fixes: 3489187204 ("serial: stm32: adding dma support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Gerald Baeza <gerald.baeza@st.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The problem with previous code was it rounded values in wrong
place and produced wrong baud rate in some cases.
Signed-off-by: Alexey Starikovskiy <aystarik@gmail.com>
[nicolas.ferre@atmel.com: port to newer kernel and add commit log]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The patch makes changes not to enable parity error interrupt.
With the current implementation, each parity error results in
two distinct interrupts (almost always). The first one is normal
parity error interrupt with no data in the fifo and the second one
is a proper Rx interrupt with the received data in the fifo. By
disabling parity error interrupt we still ensure handling of
parity errors as for the Rx fifo interrupt the parity error still
shows up in the interrupt status register. Considering the fact
that the by default INPCK and IGNPAR are not set, this is the
optimal implementation for parity error handling.
Signed-off-by: Anirudha Sarangi <anirudh@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
[stelford@cadence.com: cherry picked from
https://github.com/Xilinx/linux-xlnx commit
bf9f610b445e2c9ed33c41e1e0e30b43be4e1f97 with manual conflict
resolution]
Signed-off-by: Scott Telford <stelford@cadence.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds dma mode support for rx and tx
with pio mode as fallback in case of dma error.
Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Keep the clock enabled at the end of stm32_init_port
but disable it in stm32_serial_remove.
Note that stm32_pm function is there to manage the
clock at runtime.
Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
"st,hw-flow-ctrl" property is documented in device tree
binding whereas "auto-flow-control" was used in the code.
The driver is now aligned with the binding name
"st,hw-flow-ctrl".
Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Register offset management rework to support both
stm32f4 (default) and stm32f7. Driver rework to
ensure same functional level on both stm32f4 and
stm32f7: no new feature in this version yet.
Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After issuing the reset, driver is not checking the rx and tx reset
done status. So, modified driver to wait for the reset done status.
Signed-off-by: Nava kishore Manne <navam@xilinx.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds RXBS register access support for zynqmp.
To avoid the corner error conditions it will consider only
RXBS[2:0] bits while checking the error conditions
(Parity,Framing and BRAK).
Signed-off-by: Nava kishore Manne <navam@xilinx.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Less magic that only requires comments.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 0e125a5fac ("tty: amba-pl011: define flag register bits for ZTE
device") changes earlycon function pl011_putc() to use a pointer to
uart_amba_port. This causes a regression when earlycon is enabled,
because uart_amba_port is not available yet at earlycon time. Let's
revert the change on pl011_putc() to fix the regression.
The earlycon support for ZTE device can probably be added later by
declaring a new earlycon setup function with a vendor specific
compatible.
Reported-by: Sudeep Holla <sudeep.holla@arm.com>
Fixes: 0e125a5fac ("tty: amba-pl011: define flag register bits for ZTE device")
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For now, these fall back to regular (dark) colors.
It'd be tempting to replace blink with bright backgrounds, as permitted by
CGA/VGA -- we already muck with the other programmable bit (foreground
brightness vs 512 character font). This would bring vgacon in line with
fbcon, which doesn't support blink anywhere but on some drivers renders
that bit as bright background. If that is done, this commit should be
amended to be one of ways of setting that bit.
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These codes are supported by all major terminals, thus they occasionally see
some use despite being redundant with \e[38;5;(x+8)m or (less exactly)
\e[1;3(x)m.
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some guy went on a patching spree, adding 24-bit colour support all around:
https://gist.github.com/XVilka/8346728
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
All other uses of vc_npar are inclusive (save for < NPAR) which raises
eyebrows, so let's at least do so consistently.
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This makes it show up on UBSAN:
perl -e 'for (0..15) {my @x=("0")x$_;push @x,qw(38 2 64 128 192 4);printf
"\e[%smAfter %d zeroes.\e[0m\n", join(";",@x[0..($_+5<15?$_+5:15)]), $_}'
Seems harmless: if you can programmatically read attributes of a vt
character (/dev/vcsa*), multiple probes can obtain parts of vt_mode then
lowest byte (5th on 64-bit big-endian) of a pointer.
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The ptmx_fops structure is only changed during init, so mark it as such.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dmaengine_terminate_all() is deprecated and should be replaced by
dmaengine_terminate_sync() in non-atomic context or dmaengine_terminate_async()
with dmaengine_synchronize().
See commit b36f09c3c4 ("dmaengine: Add transfer termination synchronization support")
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit 761ed4a945 ("tty: serial_core: convert uart_close to use
tty_port_close") refactored uart_close() to use tty_port_close(). At the same
time it introduced a potential NULL pointer dereference. Rearrange the code to
avoid kernel crash.
Fixes: 761ed4a945 ("tty: serial_core: convert uart_close to use tty_port_close")
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since commit 18dfef9c7f ("serial: atmel: convert to irq handling
provided mctrl-gpio"), interrupts from GPIOs are not disabled any more
when the serial port is closed, leading to an oops when the one of the
input pin is toggled (CTS/DSR/DCD/RNG).
This is only the case if those pins are used as GPIOs, i.e. declared
like that:
usart1: serial@f8020000 {
/* CTS and DTS will be handled by GPIO */
status = "okay";
rts-gpios = <&pioB 17 GPIO_ACTIVE_LOW>;
cts-gpios = <&pioB 16 GPIO_ACTIVE_LOW>;
dtr-gpios = <&pioB 14 GPIO_ACTIVE_LOW>;
dsr-gpios = <&pioC 31 GPIO_ACTIVE_LOW>;
rng-gpios = <&pioB 12 GPIO_ACTIVE_LOW>;
dcd-gpios = <&pioB 15 GPIO_ACTIVE_LOW>;
};
That's because modem interrupts used to be freed in atmel_shutdown().
After commit 18dfef9c7f ("serial: atmel: convert to irq handling
provided mctrl-gpio"), this code was just removed.
Calling atmel_disable_ms() disables the interrupts and everything works
fine again.
Tested on at91sam9g35-cm
(This patch doesn't apply on -stable kernels, fixes for 4.4 and 4.7 will
be sent after this one is applied.)
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Fixes: 18dfef9c7f ("serial: atmel: convert to irq handling provided mctrl-gpio")
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The function lpuart_start_rx_dma() is called from several
places, in some of which, such as lpuart_startup(), a lock
be held here, so we should use GFP_ATOMIC when a lock is held.
Fixes: 5887ad43ee ("tty: serial: fsl_lpuart: Use cyclic DMA for Rx")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When dev.of_node is not NULL, we also need to set IRQF_TRIGGER_FALLING
flag, otherwise it may cause uncertain interrupts.
Signed-off-by: Liu Xiang <liu.xiang6@zte.com.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guenter Roeck reported a regression caused by commit "serial: earlycon:
Extend earlycon command line option to support 64-bit addresses":
console= and earlycon= options have the following format:
...,<addr>,<options>
Historically used here simple_strtoul() had no problems with comma, but the
new and recommended kstrtoull() requires null-terminated string and returns
-EINVAL in case there are "options" at the end. There is no recommended to
use function currently that will support it, so stick to obsolete
simple_strtoull() variant.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
