lwn.git/drivers/tty/serial, branch docs-4.17

Merge tag 'acpi-part2-4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

2018-02-09T17:44:25+00:00

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

ACPI: SPCR: Make SPCR available to x86

2018-02-07T10:39:58+00:00

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 Acked-by: Ingo Molnar Reviewed-by: Mark Salter Tested-by: Mark Salter Signed-off-by: Rafael J. Wysocki

Merge tag 'driver-core-4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2018-02-01T18:00:28+00:00

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 ...

tty: serial: exar: Relocate sleep wake-up handling

2018-01-25T11:44:50+00:00

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 Signed-off-by: Aaron Sierra Signed-off-by: Greg Kroah-Hartman

serial: imx: fix endless loop during suspend

2018-01-22T13:20:56+00:00

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 Signed-off-by: Greg Kroah-Hartman

serial: core: mark port as initialized after successful IRQ change

2018-01-22T13:20:56+00:00

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 Signed-off-by: Greg Kroah-Hartman

serial: mxs-auart: don't use GPIOF_* with gpiod_get_direction

2018-01-22T13:17:44+00:00

The documentation was wrong, gpiod_get_direction() returns 0/1 instead of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47 ("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 Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: Revert "Improve clock rate setting"

2018-01-22T13:13:40+00:00

The commit de9e33bdfa22 ("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 de9e33bdfa22 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: de9e33bdfa22 ("serial: 8250_dw: Improve clock rate setting") Cc: stable # 4.15 Cc: Ed Blake Cc: Heikki Krogerus Cc: Lukas Wunner Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman

gpio: serial: max310x: Support open-drain configuration for GPIOs

2018-01-09T18:36:51+00:00

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 Reviewed-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

serial: 8250_ingenic: Parse earlycon options

2018-01-09T15:49:14+00:00

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 Signed-off-by: Greg Kroah-Hartman