linux-stable.git/drivers/tty/serial/8250, branch linux-4.13.y

serial: 8250_fintek: Fix finding base_port with activated SuperIO

2017-11-24T07:35:58+00:00

commit fd97e66c5529046e989a0879c3bb58fddb592c71 upstream.

The SuperIO will be configured at boot time by BIOS, but some BIOS
will not deactivate the SuperIO when the end of configuration. It'll
lead to mismatch for pdata->base_port in probe_setup_port(). So we'll
deactivate all SuperIO before activate special base_port in
fintek_8250_enter_key().

Tested on iBASE MI802.

Tested-by: Ji-Ze Hong (Peter Hong) 
Signed-off-by: Ji-Ze Hong (Peter Hong) 
Reviewd-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'tty-4.13-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

2017-08-13T19:33:35+00:00

Pull tty/serial fixes from Greg KH:
 "Here are two tty serial driver fixes for 4.13-rc5. One is a revert of
  a -rc1 patch that turned out to not be a good idea, and the other is a
  fix for the pl011 serial driver.

  Both have been in linux-next with no reported issues"

* tag 'tty-4.13-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  Revert "serial: Delete dead code for CIR serial ports"
  tty: pl011: fix initialization order of QDF2400 E44

Revert "serial: Delete dead code for CIR serial ports"

2017-08-01T16:50:18+00:00

This reverts commit 1104321a7b3bb670dc614ffa7958c553e7b3b836.

The code is not dead at all and breaks winbond-cir.

Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
00:02: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
00:03: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a CIR port
lirc lirc0: lirc_dev: driver ir-lirc-codec (winbond-cir) registered at minor = 0
winbond-cir 00:03: Region 0x2f8-0x2ff already in use!
winbond-cir: probe of 00:03 failed with error -16

Signed-off-by: Sean Young 
Reviewed-by: Matthias Brugger 
Signed-off-by: Greg Kroah-Hartman

gpio: exar: Use correct property prefix and document bindings

2017-08-01T11:43:55+00:00

The device-specific property should be prefixed with the vendor name,
not "linux,", as Linus Walleij pointed out. Change this and document the
bindings of this platform device.

We didn't ship the old binding in a release yet. So we can still change
it without breaking an official API.

Fixes: 380b1e2f3a2f ("gpio-exar/8250-exar: Make set of exported GPIOs configurable")
Signed-off-by: Jan Kiszka 
Acked-by: Rob Herring 
Signed-off-by: Linus Walleij

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

gpio-exar/8250-exar: Rearrange gpiochip parenthood

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

Set the parent of the exar gpiochip to its platform device, like other
gpiochips are doing it. In order to keep the relationship discoverable
for ACPI systems, set the platform device companion to the PCI device.

Signed-off-by: Jan Kiszka 
Reviewed-by: Andy Shevchenko 
Acked-by: Linus Walleij

gpio-exar/8250-exar: Do not even instantiate a GPIO device for Commtech cards

2017-07-03T06:23:09+00:00

Commtech adapters need the MPIOs for internal purposes, and the
gpio-exar driver already refused to pick them up. But there is actually
no point in even creating the underlying platform device.

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