linux.git/drivers/tty/serial, branch v4.13-rc2

tty: serial: lpuart: Fix the logic for detecting the 32-bit type UART

2017-07-17T12:14:24+00:00

Commit 0d6fce904452 ("tty: serial: lpuart: introduce lpuart_soc_data to
represent SoC property") introduced a buggy logic for detecting the 32-bit
type UART since the condition: "if (sport->port.iotype & UPIO_MEM32BE)"
is always true.

Performing such bitfield AND operation is not correct, because in the
case of Vybrid UART iotype is UPIO_MEM (2), so:

UPIO_MEM & UPIO_MEM32BE = 010 & 110 = 010, which is true.

Such logic tells the driver to always treat the UART operations as 32-bit,
leading to the driver misbehavior on Vybrid.

Fix the 32-bit type detection logic to avoid UART breakage on Vybrid.

While at it, introduce a lpuart_is_32() function to help readability.

Fixes: 0d6fce904452 ("tty: serial: lpuart: introduce lpuart_soc_data to represent SoC property")
Reported-by: Vivien Didelot 
Signed-off-by: Fabio Estevam 
Reviewed-by: Dong Aisheng 
Tested-by: Vivien Didelot 
Signed-off-by: Greg Kroah-Hartman

serial: imx: Prevent TX buffer PIO write when a DMA has been started

2017-07-17T12:14:24+00:00

Function imx_transmit_buffer starts a TX DMA if DMA is enabled, since
commit 91a1a909f921 ("serial: imx: Support sw flow control in DMA mode").
It also carries on and attempts to write the same TX buffer using PIO.
This results in TX data corruption and double-incrementing xmit->tail
with the knock-on effect of tail passing head and a page of garbage
being sent out.

This seems to be triggered mostly when using RS485 half duplex on SMP
systems, but is probably not limited to just those.

Tested locally on an i.MX6Q with an RS485 half duplex transceiver on
UART3, and also by Clemens Gruber.

Tested-by: Clemens Gruber 
Signed-off-by: Ian Jamison 
Reviewed-by: Fabio Estevam 
Signed-off-by: Greg Kroah-Hartman

Revert "serial: imx-serial - move DMA buffer configuration to DT"

2017-07-17T11:48:58+00:00

This reverts commit a3015affdf76ef279fbbb3710a220bab7e9ea04b as there
are complaints that it is incorrect.

Reported-by: Uwe Kleine-König 
Cc: Nandor Han 
Cc: Romain Perier 
Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

serial: sh-sci: Uninitialized variables in sysfs files

2017-07-17T11:19:19+00:00

The kstrtol() function returns -ERANGE as well as -EINVAL so these tests
are not enough.  It's not a super serious bug, but my static checker
correctly complains that the "r" variable might be used uninitialized.

Fixes: 5d23188a473d ("serial: sh-sci: make RX FIFO parameters tunable via sysfs")
Signed-off-by: Dan Carpenter 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

serial: st-asc: Potential error pointer dereference

2017-07-17T11:19:19+00:00

It looks like we intended to return an error code here, because we
dereference "ascport->pinctrl" on the next lines.

Fixes: 6929cb00a501 ("serial: st-asc: Read in all Pinctrl states")
Signed-off-by: Dan Carpenter 
Acked-by: Lee Jones 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

drivers: tty: serial: move inline before return type

2017-07-12T23:26:04+00:00

Make the code like the rest of the kernel.

Link: http://lkml.kernel.org/r/55d3e89d50bb03d603bfb28019fab07f48bdc714.1499284835.git.joe@perches.com
Signed-off-by: Joe Perches 
Cc: Pat Gefre 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge tag 'gpio-v4.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio

2017-07-07T19:40:27+00:00

Pull GPIO updates from Linus Walleij:
"This is the bulk of GPIO changes for the v4.13 series.

Some administrativa:

I have a slew of 8250 serial patches and the new IOT2040 serial+GPIO
driver coming in through this tree, along with a whole bunch of Exar
8250 fixes. These are ACKed by Greg and also hit drivers/platform/*
where they are ACKed by Andy Shevchenko.

Speaking about drivers/platform/* there is also a bunch of ACPI stuff
coming through that route, again ACKed by Andy.

The MCP23S08 changes are coming in here as well. You already have the
commits in your tree, so this is just a result of sharing an immutable
branch between pin control and GPIO.

Core:
- Export add/remove for lookup tables so that modules can export GPIO
descriptor tables.
- Handle GPIO sleep states: it is now possible to flag that a GPIO
line may loose its state during suspend/resume of the system to
save power. This is used in the Wolfson Micro Arizona driver.
- ACPI-based GPIO was tightened up a lot around the edges.
- Use bitmap_fill() to speed up a loop.

New drivers:
- Exar XRA1403 SPI-based GPIO.
- MVEBU driver now supports Armada 7K and 8K.
- LP87565 PMIC GPIO.
- Renesas R-CAR R8A7743 (RZ/G1M).
- The new IOT2040 8250 serial/GPIO also comes in through this
changeset.

Substantial driver changes:
- Seriously fix the Exar 8250 GPIO portions to work.
- The MCP23S08 was moved out to a pin control driver.
- Convert MEVEBU to use regmap for register access.
- Drop Vulcan support from the Broadcom driver.
- Serious cleanup and improvement of the mockup driver, giving us a
better test coverage.

Misc:
- Lots of janitorial clean up.
- A bunch of documentation fixes"

* tag 'gpio-v4.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (70 commits)
serial: exar: Add support for IOT2040 device
gpio-exar/8250-exar: Make set of exported GPIOs configurable
platform: Accept const properties
serial: exar: Factor out platform hooks
gpio-exar/8250-exar: Rearrange gpiochip parenthood
gpio: exar: Fix iomap request
gpio-exar/8250-exar: Do not even instantiate a GPIO device for Commtech cards
serial: uapi: Add support for bus termination
gpio: rcar: Add R8A7743 (RZ/G1M) support
gpio: gpio-wcove: Fix GPIO control register offset calculation
gpio: lp87565: Add support for GPIO
gpio: dwapb: fix missing first irq for edgeboth irq type
MAINTAINERS: Take maintainership for GPIO ACPI support
gpio: exar: Fix reading of directions and values
gpio: exar: Allocate resources on behalf of the platform device
gpio-exar/8250-exar: Fix passing in of parent PCI device
gpio: mockup: use devm_kcalloc() where applicable
gpio: mockup: add myself as author
gpio: mockup: improve the error message
gpio: mockup: don't return magic numbers from probe()
...

serial: exar: Add support for IOT2040 device

2017-07-03T06:33:20+00:00

This implements the setup of RS232 and the switch-over to RS485 or RS422
for the Siemens IOT2040. That uses an EXAR XR17V352 with external logic
to switch between the different modes. The external logic is controlled
via MPIO pins of the EXAR controller.

Only pin 10 can be exported as GPIO on the IOT2040. It is connected to
an LED.

As the XR17V352 used on the IOT2040 is not equipped with an external
EEPROM, it cannot present itself as IOT2040-variant via subvendor/
subdevice IDs. Thus, we have to check via DMI for the target platform.

Co-developed with Sascha Weisenberger.

Signed-off-by: Sascha Weisenberger 
Signed-off-by: Jan Kiszka 
Reviewed-by: Andy Shevchenko 
Acked-by: Greg Kroah-Hartman

gpio-exar/8250-exar: Make set of exported GPIOs configurable

2017-07-03T06:32:42+00:00

On the SIMATIC, IOT2040 only a single pin is exportable as GPIO, the
rest is required to operate the UART. To allow modeling this case,
expand the platform device data structure to specify a (consecutive) pin
subset for exporting by the gpio-exar driver.

Signed-off-by: Jan Kiszka 
Reviewed-by: Andy Shevchenko

serial: exar: Factor out platform hooks

2017-07-03T06:30:54+00:00

This prepares the addition of IOT2040 platform support by preparing the
needed setup and rs485_config hooks.

Signed-off-by: Jan Kiszka 
Reviewed-by: Andy Shevchenko 
Acked-by: Greg Kroah-Hartman