kernel.git/drivers/tty/serial/max310x.c, branch linux-4.17.y

gpio: serial: max310x: Use HW type for gpio_chip's label

2018-02-28T12:40:22Z

Some debugging tools (/sys/kernel/debug/gpio, `lsgpio`) use the gpio_chip's label for displaying an additional context. Right now, the information duplicates stuff which is already available from the parent's device. This is how e.g. `lsgpio`'s output looks like: GPIO chip: gpiochip2, "spi1.2", 16 GPIO lines Comparing the output of other GPIO expanders that I have available: gpiochip4: GPIOs 464-479, parent: spi/spi1.1, mcp23s17, can sleep: gpiochip5: GPIOs 448-463, parent: i2c/0-0020, pca9555, can sleep: gpiochip2: GPIOs 496-511, parent: spi/spi1.2, spi1.2, can sleep: This patch ensures that the type of the real HW device is shown instead of duplicating the SPI path: gpiochip2: GPIOs 496-511, parent: spi/spi1.2, MAX14830, can sleep: Signed-off-by: Jan Kundrát Signed-off-by: Greg Kroah-Hartman

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

2018-01-09T18:36:51Z

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: max310x: Reduce RX work starvation

2017-12-19T08:59:02Z

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

serial: max310x: Use batched reads when reasonably safe

2017-12-19T08:59:02Z

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

serial: max310x: use a batch write op for UART transmit

2017-12-19T08:59:02Z

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

serial: max310x: Support IRQ sharing with other devices

2017-12-19T08:59:01Z

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

serial: max310x: Do not hard-code the IRQ type

2017-12-19T08:59:01Z

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

serial: max310x: Fix invalid memory access during GPIO init

2017-12-15T19:29:59Z

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: [] (max310x_gpio_direction_output) from [] (_gpiod_direction_output_raw+0x94/0x2d4) [] (_gpiod_direction_output_raw) from [] (gpiod_hog+0x6c/0x154) [] (gpiod_hog) from [] (of_gpiochip_add+0x28c/0x444) [] (of_gpiochip_add) from [] (gpiochip_add_data+0x4f8/0x760) [] (gpiochip_add_data) from [] (devm_gpiochip_add_data+0x40/0x7c) [] (devm_gpiochip_add_data) from [] (max310x_spi_probe+0x530/0x894) [] (max310x_spi_probe) from [] (spi_drv_probe+0x7c/0xac) [] (spi_drv_probe) from [] (driver_probe_device+0x234/0x2e8) [] (driver_probe_device) from [] (bus_for_each_drv+0x60/0x94) [] (bus_for_each_drv) from [] (__device_attach+0xb0/0x114) [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) [] (bus_probe_device) from [] (device_add+0x3f4/0x580) [] (device_add) from [] (spi_add_device+0x9c/0x134) [] (spi_add_device) from [] (spi_register_controller+0x484/0x910) [] (spi_register_controller) from [] (orion_spi_probe+0x2f4/0x3b4) [] (orion_spi_probe) from [] (platform_drv_probe+0x50/0xb0) [] (platform_drv_probe) from [] (driver_probe_device+0x234/0x2e8) [] (driver_probe_device) from [] (__driver_attach+0xb8/0xbc) [] (__driver_attach) from [] (bus_for_each_dev+0x68/0x9c) [] (bus_for_each_dev) from [] (bus_add_driver+0x104/0x210) [] (bus_add_driver) from [] (driver_register+0x78/0xf4) [] (driver_register) from [] (do_one_initcall+0x44/0x168) [] (do_one_initcall) from [] (kernel_init_freeable+0x140/0x1cc) [] (kernel_init_freeable) from [] (kernel_init+0x8/0x108) [] (kernel_init) from [] (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 Signed-off-by: Greg Kroah-Hartman

tty: serial: Remove redundant license text

2017-11-08T12:08:12Z

Now that the SPDX tag is in all tty files, that identifies the license in a specific and legally-defined manner. So the extra GPL text wording can be removed as it is no longer needed at all. This is done on a quest to remove the 700+ different ways that files in the kernel describe the GPL license text. And there's unneeded stuff like the address (sometimes incorrect) for the FSF which is never needed. No copyright headers or other non-license-description text was removed. Cc: Jiri Slaby Cc: Eric Anholt Cc: Stefan Wahren Cc: Florian Fainelli Cc: Ray Jui Cc: Scott Branden Cc: bcm-kernel-feedback-list@broadcom.com Cc: "James E.J. Bottomley" Cc: Helge Deller Cc: Joachim Eastwood Cc: Matthias Brugger Cc: Masahiro Yamada Cc: Tobias Klauser Cc: Russell King Cc: Vineet Gupta Cc: Richard Genoud Cc: Alexander Shiyan Cc: Baruch Siach Cc: Pat Gefre Cc: "Guilherme G. Piccoli" Cc: Jason Wessel Cc: Vladimir Zapolskiy Cc: Sylvain Lemieux Cc: Carlo Caione Cc: Kevin Hilman Cc: Liviu Dudau Cc: Sudeep Holla Cc: Lorenzo Pieralisi Cc: Andy Gross Cc: David Brown Cc: "Andreas Färber" Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Kevin Cernekee Cc: Laxman Dewangan Cc: Thierry Reding Cc: Jonathan Hunter Cc: Barry Song Cc: Patrice Chotard Cc: Maxime Coquelin Cc: Alexandre Torgue Cc: Chris Metcalf Cc: Peter Korsgaard Cc: Timur Tabi Cc: Tony Prisk Cc: Michal Simek Cc: "Sören Brinkmann" Signed-off-by: Greg Kroah-Hartman

tty: add SPDX identifiers to all remaining files in drivers/tty/

2017-11-08T12:08:12Z

It's good to have SPDX identifiers in all files to make it easier to audit the kernel tree for correct licenses. Update the drivers/tty files files with the correct SPDX license identifier based on the license text in the file itself. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This work is based on a script and data from Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. Cc: Jiri Slaby Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Chris Metcalf Cc: Jiri Kosina Cc: David Sterba Cc: James Hogan Cc: Rob Herring Cc: Eric Anholt Cc: Stefan Wahren Cc: Florian Fainelli Cc: Ray Jui Cc: Scott Branden Cc: bcm-kernel-feedback-list@broadcom.com Cc: "James E.J. Bottomley" Cc: Helge Deller Cc: Joachim Eastwood Cc: Matthias Brugger Cc: Masahiro Yamada Cc: Tobias Klauser Cc: Russell King Cc: Vineet Gupta Cc: Richard Genoud Cc: Alexander Shiyan Cc: Baruch Siach Cc: "Maciej W. Rozycki" Cc: "Uwe Kleine-König" Cc: Pat Gefre Cc: "Guilherme G. Piccoli" Cc: Jason Wessel Cc: Vladimir Zapolskiy Cc: Sylvain Lemieux Cc: Carlo Caione Cc: Kevin Hilman Cc: Liviu Dudau Cc: Sudeep Holla Cc: Lorenzo Pieralisi Cc: Andy Gross Cc: David Brown Cc: "Andreas Färber" Cc: Kevin Cernekee Cc: Laxman Dewangan Cc: Thierry Reding Cc: Jonathan Hunter Cc: Barry Song Cc: Patrice Chotard Cc: Maxime Coquelin Cc: Alexandre Torgue Cc: "David S. Miller" Cc: Peter Korsgaard Cc: Timur Tabi Cc: Tony Prisk Cc: Michal Simek Cc: "Sören Brinkmann" Cc: Thomas Gleixner Cc: Kate Stewart Cc: Philippe Ombredanne Cc: Jiri Slaby Signed-off-by: Greg Kroah-Hartman