- Update the ACPICA kernel code to upstream revision 20180105 including:
* Assorted fixes (Jung-uk Kim).
* Support for X32 ABI compilation (Anuj Mittal).
* Update of ACPICA copyrights to 2018 (Bob Moore).
- Prepare for future modifications to avoid executing the _STA control
method too early (Hans de Goede).
- Make the processor performance control library code ignore _PPC
notifications if they cannot be handled and fix up the C1 idle
state definition when it is used as a fallback state (Chen Yu,
Yazen Ghannam).
- Make it possible to use the SPCR table on x86 and to replace the
original IORT table with a new one from initrd (Prarit Bhargava,
Shunyong Yang).
- Add battery-related quirks for Asus UX360UA and UX410UAK and add
quirks for table parsing on Dell XPS 9570 and Precision M5530
(Kai Heng Feng).
- Address static checker warnings in the CPPC code (Gustavo Silva).
- Avoid printing a raw pointer to the kernel log in the smart
battery driver (Greg Kroah-Hartman).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJafGvJAAoJEILEb/54YlRxiusQAKUa+OM/oxTJkOEfGGRM8NlS
Hq/PaL/TnAj3nCoZN9fM38mI4gkxqu3eVMv6kfiqRe8VYmUX9r9tRbQ9kxvEYa7n
s6Dl+wdC9UND20QJkYVzPlaXbPuZyLFHt4Fkb1hp+HAGgNNYqc4e0lJvI82F2pdo
im1UFI84jg9UQV4WpUJL6ny2c/RMNtpUV5fOKFD8lkvBvVe7mtZTZ+1nZDeqXGkV
jzdrVTHLUEDhjS1o0TBmEsJGNeGOqnK/f+m8Rq4397guPAQQq18MYNC68SzhuGjP
iqhvIvI9sF197i66l/qgsubBifOV4At8Wb0LA5cU8CQLLpEW8GDktz/kucVHyzJ4
cVKuPXptBwwtPbNFHWO8reTUFMAnP7IpjtC31ntr6xWRQCiXv0/i2hRRN54g9T7e
FAOBmmys5DKFOq50OB5WdD3/Qz5OUuVgdbrSxNFARIZpQFtUn7Np2/nmNpPgrrcl
77hO8dpeXUTVvM4HpRQN1+r0KOTLfTAvWV7LYLAjCF9ivc0Vop/tYZQ2VEMSUEFD
SGKC30mGC4pphAjxcSYV282JR7Jx7arQ71ZA5uYTRRuxnEQd/2MC71fNjrFmCgUW
1Pumw0Pw6eZRjj1FZ/pj0X5lm7AlZj0dVzsJFgNb0FcJW0nOhN3czQrA4igoSVng
B2sRv9U8YDnDtzHyTPrY
=rVdp
-----END PGP SIGNATURE-----
Merge tag 'acpi-part2-4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull more ACPI updates from Rafael Wysocki:
"These are mostly fixes and cleanups, a few new quirks, a couple of
updates related to the handling of ACPI tables and ACPICA copyrights
refreshment.
Specifics:
- Update the ACPICA kernel code to upstream revision 20180105
including:
* Assorted fixes (Jung-uk Kim)
* Support for X32 ABI compilation (Anuj Mittal)
* Update of ACPICA copyrights to 2018 (Bob Moore)
- Prepare for future modifications to avoid executing the _STA
control method too early (Hans de Goede)
- Make the processor performance control library code ignore _PPC
notifications if they cannot be handled and fix up the C1 idle
state definition when it is used as a fallback state (Chen Yu,
Yazen Ghannam)
- Make it possible to use the SPCR table on x86 and to replace the
original IORT table with a new one from initrd (Prarit Bhargava,
Shunyong Yang)
- Add battery-related quirks for Asus UX360UA and UX410UAK and add
quirks for table parsing on Dell XPS 9570 and Precision M5530 (Kai
Heng Feng)
- Address static checker warnings in the CPPC code (Gustavo Silva)
- Avoid printing a raw pointer to the kernel log in the smart battery
driver (Greg Kroah-Hartman)"
* tag 'acpi-part2-4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: sbshc: remove raw pointer from printk() message
ACPI: SPCR: Make SPCR available to x86
ACPI / CPPC: Use 64-bit arithmetic instead of 32-bit
ACPI / tables: Add IORT to injectable table list
ACPI / bus: Parse tables as term_list for Dell XPS 9570 and Precision M5530
ACPICA: Update version to 20180105
ACPICA: All acpica: Update copyrights to 2018
ACPI / processor: Set default C1 idle state description
ACPI / battery: Add quirk for Asus UX360UA and UX410UAK
ACPI: processor_perflib: Do not send _PPC change notification if not ready
ACPI / scan: Use acpi_bus_get_status() to initialize ACPI_TYPE_DEVICE devs
ACPI / bus: Do not call _STA on battery devices with unmet dependencies
PCI: acpiphp_ibm: prepare for acpi_get_object_info() no longer returning status
ACPI: export acpi_bus_get_status_handle()
ACPICA: Add a missing pair of parentheses
ACPICA: Prefer ACPI_TO_POINTER() over ACPI_ADD_PTR()
ACPICA: Avoid NULL pointer arithmetic
ACPICA: Linux: add support for X32 ABI compilation
ACPI / video: Use true for boolean value
SPCR is currently only enabled or ARM64 and x86 can use SPCR to setup
an early console.
General fixes include updating Documentation & Kconfig (for x86),
updating comments, and changing parse_spcr() to acpi_parse_spcr(),
and earlycon_init_is_deferred to earlycon_acpi_spcr_enable to be
more descriptive.
On x86, many systems have a valid SPCR table but the table version is
not 2 so the table version check must be a warning.
On ARM64 when the kernel parameter earlycon is used both the early console
and console are enabled. On x86, only the earlycon should be enabled by
by default. Modify acpi_parse_spcr() to allow options for initializing
the early console and console separately.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Mark Salter <msalter@redhat.com>
Tested-by: Mark Salter <msalter@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Here is the set of "big" driver core patches for 4.16-rc1.
The majority of the work here is in the firmware subsystem, with reworks
to try to attempt to make the code easier to handle in the long run, but
no functional change. There's also some tree-wide sysfs attribute
fixups with lots of acks from the various subsystem maintainers, as well
as a handful of other normal fixes and changes.
And finally, some license cleanups for the driver core and sysfs code.
All have been in linux-next for a while with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCWnLvPw8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ynNzACgkzjPoBytJWbpWFt6SR6L33/u4kEAnRFvVCGL
s6ygQPQhZIjKk2Lxa2hC
=Zihy
-----END PGP SIGNATURE-----
Merge tag 'driver-core-4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core updates from Greg KH:
"Here is the set of "big" driver core patches for 4.16-rc1.
The majority of the work here is in the firmware subsystem, with
reworks to try to attempt to make the code easier to handle in the
long run, but no functional change. There's also some tree-wide sysfs
attribute fixups with lots of acks from the various subsystem
maintainers, as well as a handful of other normal fixes and changes.
And finally, some license cleanups for the driver core and sysfs code.
All have been in linux-next for a while with no reported issues"
* tag 'driver-core-4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (48 commits)
device property: Define type of PROPERTY_ENRTY_*() macros
device property: Reuse property_entry_free_data()
device property: Move property_entry_free_data() upper
firmware: Fix up docs referring to FIRMWARE_IN_KERNEL
firmware: Drop FIRMWARE_IN_KERNEL Kconfig option
USB: serial: keyspan: Drop firmware Kconfig options
sysfs: remove DEBUG defines
sysfs: use SPDX identifiers
drivers: base: add coredump driver ops
sysfs: add attribute specification for /sysfs/devices/.../coredump
test_firmware: fix missing unlock on error in config_num_requests_store()
test_firmware: make local symbol test_fw_config static
sysfs: turn WARN() into pr_warn()
firmware: Fix a typo in fallback-mechanisms.rst
treewide: Use DEVICE_ATTR_WO
treewide: Use DEVICE_ATTR_RO
treewide: Use DEVICE_ATTR_RW
sysfs.h: Use octal permissions
component: add debugfs support
bus: simple-pm-bus: convert bool SIMPLE_PM_BUS to tristate
...
Exar sleep wake-up handling has been done on a per-channel basis by
virtue of INT0 being accessible from each channel's address space. I
believe this was initially done out of necessity, but now that Exar
devices have their own driver, we can do things more efficiently by
registering a dedicated INT0 handler at the PCI device level.
I see this change providing the following benefits:
1. If more than one port is active, eliminates the redundant bus
cycles for reading INT0 on every interrupt.
2. This note associated with hooking in the per-channel handler in
8250_port.c is resolved:
/* Fixme: probably not the best place for this */
Cc: Matt Schulte <matts@commtech-fastcom.com>
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Before we go into suspend mode, we enable the imx uart's interrupt for
the awake bit in the UART Status Register 1. If, for some reason, the
awake bit is already set before we enter suspend mode, we get an
interrupt immediately when we enable interrupts for awake. The uart's
clk_ipg is disabled at this point (unless there's an ongoing transfer).
We end up in the interrupt handler, which usually tries to clear the
awake bit. This doesn't work with the clock disabled. Therefore, we
keep getting interrupts forever, resulting in an endless loop.
Clear the awake bit before setting the awaken bit to signal that we want
an imx interrupt when the awake bit will be set. This ensures that we're
not woken up by events that happened before we started going into
suspend mode.
Change the clock handling so that suspend prepares and enables the clock
and suspend_noirq disables it. Revert these operations in resume_noirq and
resume.
With these preparations in place, we can now modify awake and awaken in
the suspend function when the actual imx interrupt is disabled and the
required clk_ipg is active.
Update the thaw and freeze functions to use the new clock handling since
we share the suspend_noirq function between suspend and hibernate.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
setserial changes the IRQ via uart_set_info(). It invokes
uart_shutdown() which free the current used IRQ and clear
TTY_PORT_INITIALIZED. It will then update the IRQ number and invoke
uart_startup() before returning to the caller leaving
TTY_PORT_INITIALIZED cleared.
The next open will crash with
| list_add double add: new=ffffffff839fcc98, prev=ffffffff839fcc98, next=ffffffff839fcc98.
since the close from the IOCTL won't free the IRQ (and clean the list)
due to the TTY_PORT_INITIALIZED check in uart_shutdown().
There is same pattern in uart_do_autoconfig() and I *think* it also
needs to set TTY_PORT_INITIALIZED there.
Is there a reason why uart_startup() does not set the flag by itself
after the IRQ has been acquired (since it is cleared in uart_shutdown)?
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The documentation was wrong, gpiod_get_direction() returns 0/1 instead
of the GPIOF_* flags. The docs were fixed with commit 94fc73094a
("gpio: correct docs about return value of gpiod_get_direction"). Now,
fix this user (until a better, system-wide solution is in place). This
also means we can drop the deprecated use of 'linux/gpio.h'. Yay!
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit
de9e33bdfa ("serial: 8250_dw: Improve clock rate setting")
obviously tries to cure symptoms, and not a root cause.
The root cause is the non-flexible rate calculation inside the
corresponding clock driver. What we need is to provide maximum UART
divisor value to the clock driver to allow it do the job transparently
to the caller.
Since from the initial commit message I have got no clue which clock
driver actually needs to be amended, I leave this exercise to the people
who know better the case.
Moreover, it seems [1] the fix introduced a regression. And possible
even one more [2].
Taking above, revert the commit de9e33bdfa for now.
[1]: https://www.spinics.net/lists/linux-serial/msg28872.html
[2]: https://github.com/Dunedan/mbp-2016-linux/issues/29#issuecomment-357583782
Fixes: de9e33bdfa ("serial: 8250_dw: Improve clock rate setting")
Cc: stable <stable@vger.kernel.org> # 4.15
Cc: Ed Blake <ed.blake@sondrel.com>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The push-pull vs. open-drain are the only supported output modes. The
inputs are always unconditionally equipped with weak pull-downs. That's
the only mode, so there's probably no point in exporting that. I wonder
if it's worthwhile to provide a custom dbg_show method to indicate the
current status of the outputs, though.
This patch and [1] for i2c-gpio together make it possible to bit-bang an
I2C bus over GPIOs of an UART which is connected via SPI :). Yes, this
is crazy, but it's fast enough (while on a 26Mhz SPI HW bus with a
dual-core 1.6GHz CPU) to drive an I2C bus at 200kHz, according to my
scope.
[1] https://patchwork.ozlabs.org/patch/852591/
Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the devicetree, it is possible to specify the baudrate, parity,
bits, flow of the early console, by passing a configuration string like
this:
aliases {
serial0 = &uart0;
};
chosen {
stdout-path = "serial0:57600n8";
};
This, for instance, will configure the early console for a baudrate of
57600 bps, no parity, and 8 bits per baud.
This patches implements parsing of this configuration string in the
8250_ingenic driver, which previously just ignored it.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The JZ4770 SoC's UART is no different from the other JZ SoCs, so this
commit simply adds the ingenic,jz4770-uart compatible string.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The pointed string is never modified from within uart_parse_options, so
it should be marked as const in the function prototype.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The error pointer from devm_reset_control_get_optional_shared() is
not propagated.
One of the most common problem scenarios is it returns -EPROBE_DEFER
when the reset controller has not probed yet. In this case, the
probe of the reset consumer should be deferred.
Fixes: e2860e1f62 ("serial: 8250_of: Add reset support")
Cc: stable@vger.kernel.org # v4.13+
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The wakeup mechanism via RTSDEN bit relies on the system using the RTS/CTS
lines, so only allow such wakeup method when the system actually has
RTS/CTS support.
Fixes: bc85734b12 ("serial: imx: allow waking up on RTSD")
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Martin Kaiser <martin@kaiser.cx>
Acked-by: Fugang Duan <fugang.duan@nxp.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix to return a negative error code from the port register error
handling case instead of 0, as done elsewhere in this function.
Fixes: 39be40ce06 ("serial: 8250_uniphier: fix serial port index in private data")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The rs485 flag "SER_RS485_RTS_AFTER_SEND" was wrongly read from the GPIO
flags. This caused the RTS pin to be high during boot.
Signed-off-by: Rafael Gago Castano <rgc@hms.se>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
All calls to neo_copy_data_from_uart_to_queue() are safeguarded
against NULL dereference of its parameter, except the one that
this patch changes.
That said, let's play safe and check for NULL in this case too.
Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After inspection made by Markus using Coccinelle software, he
observed that we could possibly be triggering a NULL pointer
dereference in 2 functions [0].
After discussion in mailing list, it was observed in fact
we have two unnecessary checks for NULL pointer, and they
were leading to Coccinelle warn. So, instead of reworking
the code as proposed by him, we hereby remove the
unnecessary checks, and also some unneeded extra lines in
the code.
These two unnecessary NULL checks were tracked in the call
chain as never NULL, so they can be safely removed.
No functional changes are intended.
[0] https://lkml.org/lkml/2017/11/29/705
Suggested-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Prior to this patch, the code would happily trigger TX on some ports
before having a chance of reading the RX buffer from the rest of them.
When no flow control was used, this led to RX buffer overruns and
therefore lost data under certain circumstances.
I was able to reproduce this with MAX14830 (that's a quad channel one)
and a simple daisy-chain of RX and TX ports on the eval board:
- TX0 -> RX1
- TX1 -> RX2
- TX2 -> RX3
- TX3 -> RX0
I was testing this by transferring 2MB of data at 115200 baud via each
port. I used a Solidrun Clearfog Base (Armada 388) which was talking to
the UART over an SPI bus clocked at 26MHz (the chip's maximum). Without
this patch, I would always get a "Possible RX FIFO overrun" in dmesg,
and fewer-than-expected amount of bytes received over ttyMAX0. Results
on ttyMAX{1,2,3} tended to be correct all the time, even without the
previous patches in this series and with PIO SPI transfers ("indirect
mode" as the Marvell datasheet calls it), so I assume that heavy
congestion is needed in order to reproduce this.
A drawback of this patch is that the throughput gets reduced "a bit".
Previously, a 115200 baud resulted in about 11.2kBps throughput as
reported by a simple `pv`. With this patch, the throughput of four
parallel streams is roughly 7kBps each, and 9kBps for three streams.
There is no slowdown for one or two parallel streams.
Situation is worse if bytes are being read one-by-one (such as if the
userspace wants to perform parity/framing/break checking) and therefore
without the batched reads.
With just this patch and no other modifications on top of 4.14, I was
only getting roughly 3.6kBps with four parallel streams. The
single-stream performance was the same, and I was seeing about 7.2kBps
with two parallel streams. `perf top` said that a substantial amount of
time was spent in `finish_task_switch`, `_raw_spin_unlock_irqrestore`
and `__timer_delay`.
Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The hardware has a 128 byte RX FIFO buffer for each independent UART.
Previously, the code was always reading that byte-by-byte via
independent SPI transactions and the associated overhead. In practice,
this led to up to eight bytes over SPI for just one byte in the UART's
RX FIFO:
- reading the global IRQ register (two bytes, one for command, the other
for data)
- reading one UART's ISR (again two bytes)
- reading the byte count (two bytes yet again)
- finally, reading one byte of the FIFO via another two-byte transaction
We cannot always use a batched read. If the TTY is set to intercept
break conditions or report framing or parity errors, then it is required
to check the Line Status Register (LSR) for each byte which is read from
the RX FIFO. The documentation does not show a way of doing that in a
single SPI transaction; registers 0x00 and 0x04 are separate.
In my testing, this is no silver bullet. I was feeding 2MB of random
data over four daisy-chaned UARTs of MAX14830, and this is the
distribution that I was getting:
- R <= 1: 7437322
- R <= 2: 162093
- R <= 4: 4093
- R <= 8: 4196
- R <= 16: 645
- R <= 32: 165
- R <= 64: 58
- R <= 128: 0
For a reference, batching the write operations works much better:
- W <= 1: 2664
- W <= 2: 1305
- W <= 4: 627
- W <= 8: 371
- W <= 16: 121
- W <= 32: 68
- W <= 64: 33
- W <= 128: 63139
That's probably because this HW/SW combination (Clearfog Base, Armada
388) is probably "good enough" to react to the chip's IRQ "fast enough"
most of the time. Still, I was getting RX overruns every now and then.
In future, I plan to improve this by letting the RX FIFO be filled a
little more (the chip has support for that and also for a "stale
timeout" to prevent additional starvation).
Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The transmit register supports batched writes. The key is simply to keep
sending additional bytes up to the FIFO size in the same SPI
transaction with the CS pin still being held low.
This duplicates the regmap infrastructure to a certain extent. There are
some provisions for multiple writes in there, but there does not appear
to be any support for those writes which are destined to the *same*
register (and also no standard for SPI bus transfers of these, anyway).
This patch does not solve every case (if the UART xmit circular buffer
wraps around, we're still doing two SPI transactions), but at least
it's not one-byte-per-transaction anymore.
This change does not touch the receive path at this time. Doing that in
the generic case appears to be impossible in the general case, because
the chips' status register contains data about the *current* byte in the
HW's Rx FIFO. We cannot read these two registers in one go,
unfortunately.
Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
According to my chip's datasheet [1], the IRQ output is an open
collector pin which is suitable for sharing with other chips. The chip
also has a register which indicates which UART performed a change and
the driver checks that register already, so we have everything what is
needed to effectively share the IRQ GPIO.
[1] https://datasheets.maximintegrated.com/en/ds/MAX14830.pdf
Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As suggested by Russell King, a driver should not really care about bits
such as the interrupt polarity or whether it is edge- or level-
triggered. The reasons for that include:
- an upstream IRQ controller which cannot support edge- or
level-triggered interrupts,
- board design with a built-in inverter
The interrupt type is being already specified by the Device Tree,
anyway. Other drivers (gpio/gpio-tc3589x.c for example) already work in
this way, delegating the proper IRQ line setup to the DT and not
specifying anything by hand.
Also, there's no reason to have the IRQ flags split between two places.
The SPI probing is the only entry point anyway.
Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When compile-testing an allmodconfig kernel for a platform without
sh-sci serial ports, the SERIAL_SH_SCI_NR_UARTS symbol of type "int"
doesn't get assigned a numerical default value, but an empty string,
leading to a build failure:
.config:3814:warning: symbol value '' invalid for SERIAL_SH_SCI_NR_UARTS
...
make[3]: *** [silentoldconfig] Error 1
Fix this by explicitly providing a default value of 2, like before.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Fixes: f6731485a5 ("tty: serial: sh-sci: Hide number of ports config question")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The `max310x_spi_probe` function attempted to setup the GPIO bits before
the corresponding structs for each serial port were initialized. If the
DTS file specified a GPIO hog, this led to a crash because the GPIO
stack ended up calling `max310x_gpio_direction_output` which referenced
uninitialized memory:
[<c04598c0>] (max310x_gpio_direction_output) from [<c03f5a2c>] (_gpiod_direction_output_raw+0x94/0x2d4)
[<c03f5a2c>] (_gpiod_direction_output_raw) from [<c03f991c>] (gpiod_hog+0x6c/0x154)
[<c03f991c>] (gpiod_hog) from [<c03fa2d8>] (of_gpiochip_add+0x28c/0x444)
[<c03fa2d8>] (of_gpiochip_add) from [<c03f6b2c>] (gpiochip_add_data+0x4f8/0x760)
[<c03f6b2c>] (gpiochip_add_data) from [<c03f6dd4>] (devm_gpiochip_add_data+0x40/0x7c)
[<c03f6dd4>] (devm_gpiochip_add_data) from [<c0459fec>] (max310x_spi_probe+0x530/0x894)
[<c0459fec>] (max310x_spi_probe) from [<c0503294>] (spi_drv_probe+0x7c/0xac)
[<c0503294>] (spi_drv_probe) from [<c046628c>] (driver_probe_device+0x234/0x2e8)
[<c046628c>] (driver_probe_device) from [<c0464890>] (bus_for_each_drv+0x60/0x94)
[<c0464890>] (bus_for_each_drv) from [<c0465f78>] (__device_attach+0xb0/0x114)
[<c0465f78>] (__device_attach) from [<c0465548>] (bus_probe_device+0x84/0x8c)
[<c0465548>] (bus_probe_device) from [<c0463a00>] (device_add+0x3f4/0x580)
[<c0463a00>] (device_add) from [<c0504164>] (spi_add_device+0x9c/0x134)
[<c0504164>] (spi_add_device) from [<c0504c18>] (spi_register_controller+0x484/0x910)
[<c0504c18>] (spi_register_controller) from [<c0506ee0>] (orion_spi_probe+0x2f4/0x3b4)
[<c0506ee0>] (orion_spi_probe) from [<c0467dac>] (platform_drv_probe+0x50/0xb0)
[<c0467dac>] (platform_drv_probe) from [<c046628c>] (driver_probe_device+0x234/0x2e8)
[<c046628c>] (driver_probe_device) from [<c04663f8>] (__driver_attach+0xb8/0xbc)
[<c04663f8>] (__driver_attach) from [<c04647e8>] (bus_for_each_dev+0x68/0x9c)
[<c04647e8>] (bus_for_each_dev) from [<c046574c>] (bus_add_driver+0x104/0x210)
[<c046574c>] (bus_add_driver) from [<c0466f14>] (driver_register+0x78/0xf4)
[<c0466f14>] (driver_register) from [<c0101bdc>] (do_one_initcall+0x44/0x168)
[<c0101bdc>] (do_one_initcall) from [<c0a00dc0>] (kernel_init_freeable+0x140/0x1cc)
[<c0a00dc0>] (kernel_init_freeable) from [<c078c590>] (kernel_init+0x8/0x108)
[<c078c590>] (kernel_init) from [<c0107a50>] (ret_from_fork+0x14/0x24)
This can be easily fixed by moving the corresponding code below. And
because the UARTs are already there by the time we reach this point, the
`goto` needs changing so that more stuff is freed. (I have not tested
this error path.)
Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If uart_add_one_port() fails in mxs_auart_probe, the clks has
to be disabled.Two clks are previously enabled in mxs_get_clks().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Branislav Radocaj <branislav@radocaj.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixed a spelling error in a comment.
Signed-off-by: Rolf Evers-Fischer <rolf.evers.fischer@aptiv.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If there is no clock rate for uartclk defined, disable the previously
enabled clock again.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 23f5b3fdd0 serial: 8250_dw: only get the clock rate in one place
Signed-off-by: Stefan Potyra <Stefan.Potyra@elektrobit.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On most Renesas ARM platforms, the SCIF serial ports can be used with
DMA, so most users will want DMA support to be enabled.
On SuperH platforms, SCI(F) serial ports cannot be used with DMA yet
(see also commit 219fb0c143 ("serial: sh-sci: Remove the platform
data dma slave rx/tx channel IDs")), so users will want it disabled to
reduce kernel size.
Hence follow the above rationale to configure the default, unless
CONFIG_EXPERT is enabled.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Renesas H8/300 and ARM platforms use DT and support earlycon, so most
users want earlycon support to be enabled.
On SuperH platforms, earlycon is not yet supported.
Hence follow the above rationale to configure the default, unless
CONFIG_EXPERT is enabled.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Most users will want to use a serial console.
Hence make that the default, unless CONFIG_EXPERT is enabled.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Auto-configure the maximum number of serial ports based on how many can
be present on the architecture:
- 3 on H8/300,
- 10 on SuperH,
- 18 on Reneas ARM.
The default can still be overridden if CONFIG_EXPERT is enabled.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using "make kvmconfig" results in a potentially unusable linux image
on s390. The reason is that both the (default on s390) sclp consoles
as well as the 8250 console register a ttyS<x> as console. Since there
will be no 8250 on s390 let's fence 8250. This will ensure that there
is always a working sclp console.
Reported-by: Alice Frosi <alice@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Invoke the ->rs485_config callback on probe to adjust the initial RTS
polarity based on the UART's device properties.
This implicitly fixes a bug: If RTS control is not available, rs485
should be disabled even if it was enabled through a device property.
Log an error when that occurs.
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Invoke the ->rs485_config callback on probe to set UARTMODEM_TXRTSPOL
appropriately based on the UART's device properties.
This implicitly sets UARTMODEM_TXRTSE if rs485 was enabled in the device
properties, so drop the identical code from lpuart_probe().
It also fixes a bug: If an unsupported rs485 property was specified
(rs485-rx-during-tx or rs485-rts-delay), the driver returns -ENOSYS
without performing any cleanup, in particular without calling
uart_remove_one_port() or clk_disable_unprepare(), thus leaking the
uart_port. But with the invocation of ->rs485_config, the unsupported
properties are now cleared in struct serial_rs485 and thus ignored.
It therefore seems sufficient to just log an error instead of bailing
out.
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When a driver invokes the uart_get_rs485_mode() helper, set the RTS
polarity to active high by default unless the newly introduced
"rs485-rts-active-low" property was specified.
imx contains a line to set the default RTS polarity to active high,
it is now superfluous and hence deleted.
omap-serial historically defaults to active low and supports an
"rs485-rts-active-high" property to inverse the polarity.
Retain that behavior for compatibility.
Cc: Mark Jackson <mpfj@newflow.co.uk>
Cc: Michał Oleszczyk <oleszczyk.m@gmail.com>
Cc: Rafael Gago Castano <rgc@hms.se>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit ef838a81dd ("serial: Add common rs485 device tree parsing
function") consolidated retrieval of rs485 OF properties in a common
helper function but did not #ifdef it to CONFIG_OF. The function is
therefore included on ACPI platforms as well even though it's not used.
On the other hand ACPI platforms with rs485 do exist (e.g. Siemens
IOT2040) and they may leverage _DSD to store rs485 properties. Likewise,
UART platform devices instantiated from an MFD should be able to specify
rs485 properties. In fact, the tty subsystem maintainer had asked for
a "generic" function during review of commit ef838a81dd:
https://marc.info/?l=linux-serial&m=150143441725194&w=4
Thus, instead of constraining the helper to OF platforms, make it
platform-agnostic by converting it to device_property_*() functions
and renaming it accordingly.
In imx.c, move the invocation of uart_get_rs485_mode() from
serial_imx_probe_dt() to serial_imx_probe() so that it also gets called
for non-OF devices.
In omap-serial.c, move its invocation further up within
serial_omap_probe_rs485() so that the RTS polarity can be overridden
with the driver-specific "rs485-rts-active-high" property once we
introduce a generic "rs485-rts-active-low" property.
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Richard Genoud <richard.genoud@gmail.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If either uartclk or baud are 0, avoid calculating and setting a divisor
based on them since the output will almost certainly be garbage.
This also allows platforms such as the MIPS generic kernel, which has no
way to know a valid BASE_BASE for the board it is actually booted on at
compile time, to set BASE_BAUD to 0 and avoid early_8250 setting a bad
divisor.
This fixes a regression caused by commit 31cb9a8575 ("earlycon:
initialise baud field of earlycon device structure"), which changed the
behavior of of_setup_earlycon such that it sets a baud rate in the
earlycon structure where previously it was left as 0. All boards
supported by the MIPS generic kernel started outputting garbage from the
boot console due to an incorrect divisor being set.
Fixes: 31cb9a8575 ("earlycon: initialise baud field of earlycon device structure")
Cc: stable <stable@vger.kernel.org> # 4.14
Signed-off-by: Matt Redfearn <matt.redfearn@mips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This device will be used in future Amazon EC2 instances as the primary
serial port (i.e., data sent to this port will be available via the
GetConsoleOuput [1] EC2 API).
[1] http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_GetConsoleOutput.html
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Matt Wilson <msw@amazon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since imx_disable_rx_int is only called by imx_startup,
let's integrate it into that function. Notice UCR2_ATEN is
never set by the driver. The bit is still cleaned to make
this patch a noop.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Acked-by: Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 075167ed71 ("drivers: PL011: replace UART_MIS reading with
_RIS & _IMSC") amended this driver's interrupt handler to read the
Raw Interrupt Status (RIS) and Interrupt Mask Set/Clear (IMSC) registers
instead of the Masked Interrupt Status (MIS) register. The change was
made to attain compatibility with SBSA UARTs which lack the MIS register.
However the IMSC register is cached by the driver. Using the cached
copy saves one register read per interrupt.
I've tested this change successfully on a BCM2837 (Raspberry Pi CM3).
Cc: Mathias Duckeck <m.duckeck@kunbus.de>
Cc: Phil Elwell <phil@raspberrypi.org>
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Mark Langsdorf <mlangsdo@redhat.com>
Cc: Naresh Bhat <nbhat@cavium.com>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pl011_fifo_to_tty() has two counters (max_count and fifotaken) for the
same loop. One counter should suffice. This saves one subtraction per
character read from the RX FIFO.
Cc: Mathias Duckeck <m.duckeck@kunbus.de>
Cc: Phil Elwell <phil@raspberrypi.org>
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This simply fixes a typo in the preprocessor macros. No functional
changes intended.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the code there are two separate sections which each describe some of
the bits in the AML_UART_CONTROL register.
Merge these into one section to make the code easier to read.
No functional changes intended.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "clear error" bit in the AML_UART_CONTROL register is defined twice.
Remove the AML_UART_CLR_ERR definition and replace it with
AML_UART_CLEAR_ERR.
AML_UART_CLEAR_ERR was chosen to be kept since the datasheet's
description for this bit is "Clear Error" (so developer's don't have to
translate this to "CLR_ERR").
No functional changes intended.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
With all callbacks converted, and the timer callback prototype
switched over, the TIMER_FUNC_TYPE cast is no longer needed,
so remove it. Conversion was done with the following scripts:
perl -pi -e 's|\(TIMER_FUNC_TYPE\)||g' \
$(git grep TIMER_FUNC_TYPE | cut -d: -f1 | sort -u)
perl -pi -e 's|\(TIMER_DATA_TYPE\)||g' \
$(git grep TIMER_DATA_TYPE | cut -d: -f1 | sort -u)
The now unused macros are also dropped from include/linux/timer.h.
Signed-off-by: Kees Cook <keescook@chromium.org>
