summaryrefslogtreecommitdiff
path: root/drivers/tty/serial/max310x.c
AgeCommit message (Collapse)Author
2023-05-30serial: Switch i2c drivers back to use .probe()Uwe Kleine-König
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230525210147.734737-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20serial: max310x: fix IO data corruption in batched operationsJan Kundrát
After upgrading from 5.16 to 6.1, our board with a MAX14830 started producing lots of garbage data over UART. Bisection pointed out commit 285e76fc049c as the culprit. That patch tried to replace hand-written code which I added in 2b4bac48c1084 ("serial: max310x: Use batched reads when reasonably safe") with the generic regmap infrastructure for batched operations. Unfortunately, the `regmap_raw_read` and `regmap_raw_write` which were used are actually functions which perform IO over *multiple* registers. That's not what is needed for accessing these Tx/Rx FIFOs; the appropriate functions are the `_noinc_` versions, not the `_raw_` ones. Fix this regression by using `regmap_noinc_read()` and `regmap_noinc_write()` along with the necessary `regmap_config` setup; with this patch in place, our board communicates happily again. Since our board uses SPI for talking to this chip, the I2C part is completely untested. Fixes: 285e76fc049c ("serial: max310x: use regmap methods for SPI batch operations") Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Link: https://lore.kernel.org/r/79db8e82aadb0e174bc82b9996423c3503c8fb37.1680732084.git.jan.kundrat@cesnet.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-01-19serial: Make uart_handle_cts_change() status param bool activeIlpo Järvinen
Convert uart_handle_cts_change() to bool which is more appropriate than unsigned int. Rename status to active to better describe what the parameter means. While at it, make the comment about the active parameter easier to parse. Cleanup callsites from operations that are not necessary with bool. Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20230117090358.4796-10-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-11-03serial: max310x: Use uart_xmit_advance()Ilpo Järvinen
Take advantage of the new uart_xmit_advance() helper. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20221019091151.6692-22-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-07Merge tag 'tty-6.1-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial driver updates from Greg KH: "Here is the big set of TTY and Serial driver updates for 6.1-rc1. Lots of cleanups in here, no real new functionality this time around, with the diffstat being that we removed more lines than we added! Included in here are: - termios unification cleanups from Al Viro, it's nice to finally get this work done - tty serial transmit cleanups in various drivers in preparation for more cleanup and unification in future releases (that work was not ready for this release) - n_gsm fixes and updates - ktermios cleanups and code reductions - dt bindings json conversions and updates for new devices - some serial driver updates for new devices - lots of other tiny cleanups and janitorial stuff. Full details in the shortlog. All of these have been in linux-next for a while with no reported issues" * tag 'tty-6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (102 commits) serial: cpm_uart: Don't request IRQ too early for console port tty: serial: do unlock on a common path in altera_jtaguart_console_putc() tty: serial: unify TX space reads under altera_jtaguart_tx_space() tty: serial: use FIELD_GET() in lqasc_tx_ready() tty: serial: extend lqasc_tx_ready() to lqasc_console_putchar() tty: serial: allow pxa.c to be COMPILE_TESTed serial: stm32: Fix unused-variable warning tty: serial: atmel: Add COMMON_CLK dependency to SERIAL_ATMEL serial: 8250: Fix restoring termios speed after suspend serial: Deassert Transmit Enable on probe in driver-specific way serial: 8250_dma: Convert to use uart_xmit_advance() serial: 8250_omap: Convert to use uart_xmit_advance() MAINTAINERS: Solve warning regarding inexistent atmel-usart binding serial: stm32: Deassert Transmit Enable on ->rs485_config() serial: ar933x: Deassert Transmit Enable on ->rs485_config() tty: serial: atmel: Use FIELD_PREP/FIELD_GET tty: serial: atmel: Make the driver aware of the existence of GCLK tty: serial: atmel: Only divide Clock Divisor if the IP is USART tty: serial: atmel: Separate mode clearing between UART and USART dt-bindings: serial: atmel,at91-usart: Add gclk as a possible USART clock ...
2022-08-30serial: Make ->set_termios() old ktermios constIlpo Järvinen
There should be no reason to adjust old ktermios which is going to get discarded anyway. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220816115739.10928-7-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-08-16i2c: Make remove callback return voidUwe Kleine-König
The value returned by an i2c driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero that the error is ignored.) So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour, all callbacks were prepared to return 0 before. Reviewed-by: Peter Senna Tschudin <peter.senna@gmail.com> Reviewed-by: Jeremy Kerr <jk@codeconstruct.com.au> Reviewed-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Crt Mori <cmo@melexis.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Marek Behún <kabel@kernel.org> # for leds-turris-omnia Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Petr Machata <petrm@nvidia.com> # for mlxsw Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> # for surface3_power Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> # for bmc150-accel-i2c + kxcjk-1013 Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> # for media/* + staging/media/* Acked-by: Miguel Ojeda <ojeda@kernel.org> # for auxdisplay/ht16k33 + auxdisplay/lcd2s Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # for versaclock5 Reviewed-by: Ajay Gupta <ajayg@nvidia.com> # for ucsi_ccg Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # for iio Acked-by: Peter Rosin <peda@axentia.se> # for i2c-mux-*, max9860 Acked-by: Adrien Grassein <adrien.grassein@gmail.com> # for lontium-lt8912b Reviewed-by: Jean Delvare <jdelvare@suse.de> # for hwmon, i2c-core and i2c/muxes Acked-by: Corey Minyard <cminyard@mvista.com> # for IPMI Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> # for drivers/power Acked-by: Krzysztof Hałasa <khalasa@piap.pl> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-07-08serial: Embed rs485_supported to uart_portIlpo Järvinen
Embed rs485_supported to uart_port to allow serial core to tweak it as needed. Reviewed-by: Lino Sanfilippo <l.sanfilippo@kunbus.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220704094515.6831-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-27serial: take termios_rwsem for ->rs485_config() & pass termios as paramIlpo Järvinen
To be able to alter ADDRB within ->rs485_config(), take termios_rwsem before calling ->rs485_config() and pass termios. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220624204210.11112-5-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-10serial: max310x: Remove serial_rs485 sanitizationIlpo Järvinen
Serial core handles serial_rs485 sanitization. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220606100433.13793-33-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-10serial: max310x: Fill in rs485_supportedIlpo Järvinen
Add information on supported serial_rs485 features. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220606100433.13793-18-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-10serial: max310x: implement I2C supportCosmin Tanislav
I2C implementation on this chip has a few key differences compared to SPI, as described in previous patches. * extended register space access needs no extra logic * slave address is used to select which UART to communicate with To accommodate these differences, add an I2C interface config, set the RevID register address and implement an empty method for setting the GlobalCommand register, since no special handling is needed for the extended register space. To handle the port-specific slave address, create an I2C dummy device for each port, except the base one (UART0), which is expected to be the one specified in firmware, and create a regmap for each I2C device. Add minimum and maximum slave addresses to each devtype for sanity checking. Also, use a separate regmap config with no write_flag_mask, since I2C has a R/W bit in its slave address, and set the max register to the address of the RevID register, since the extended register space needs no extra logic. Finally, add the I2C driver. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com> Link: https://lore.kernel.org/r/20220605144659.4169853-5-demonsingur@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-10serial: max310x: make accessing revision id interface-agnosticCosmin Tanislav
SPI can only use 5 address bits, since one bit is reserved for specifying R/W and 2 bits are used to specify the UART port. To access registers that have addresses past 0x1F, an extended register space can be enabled by writing to the GlobalCommand register (address 0x1F). I2C uses 8 address bits. The R/W bit is placed in the slave address, and so is the UART port. Because of this, registers that have addresses higher than 0x1F can be accessed normally. To access the RevID register, on SPI, 0xCE must be written to the 0x1F address to enable the extended register space, after which the RevID register is accessible at address 0x5. 0xCD must be written to the 0x1F address to disable the extended register space. On I2C, the RevID register is accessible at address 0x25. Create an interface config struct, and add a method for toggling the extended register space and a member for the RevId register address. Implement these for SPI. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com> Link: https://lore.kernel.org/r/20220605144659.4169853-4-demonsingur@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-10serial: max310x: use a separate regmap for each portCosmin Tanislav
The driver currently does manual register manipulation in multiple places to talk to a specific UART port. In order to talk to a specific UART port over SPI, the bits U1 and U0 of the register address can be set, as explained in the Command byte configuration section of the datasheet. Make this more elegant by creating regmaps for each UART port and setting the read_flag_mask and write_flag_mask accordingly. All communcations regarding global registers are done on UART port 0, so replace the global regmap entirely with the port 0 regmap. Also, remove the 0x1f masks from reg_writeable(), reg_volatile() and reg_precious() methods, since setting the U1 and U0 bits of the register address happens inside the regmap core now. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com> Link: https://lore.kernel.org/r/20220605144659.4169853-3-demonsingur@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-06-10serial: max310x: use regmap methods for SPI batch operationsCosmin Tanislav
The SPI batch read/write operations can be implemented as simple regmap raw read and write, which will also try to do a gather write just as it is done here. Use the regmap raw read and write methods. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com> Link: https://lore.kernel.org/r/20220605144659.4169853-2-demonsingur@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-15serial: max310: remove redundant memset in rs485_configLino Sanfilippo
In uart_set_rs485_config() the serial core already nullifies the padding field of the passed serial_rs485 struct before returning it to userspace. Doing the same in the drivers rs485_config() function is redundant, so remove the concerning memset in this function. Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de> Link: https://lore.kernel.org/r/20220410104642.32195-7-LinoSanfilippo@gmx.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-09spi: make remove callback a void functionUwe Kleine-König
The value returned by an spi driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero that the error is ignored.) So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour, all callbacks were prepared to return 0 before. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Claudius Heine <ch@denx.de> Acked-by: Stefan Schmidt <stefan@datenfreihafen.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC Acked-by: Marcus Folkesson <marcus.folkesson@gmail.com> Acked-by: Łukasz Stelmach <l.stelmach@samsung.com> Acked-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20220123175201.34839-6-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2021-10-13serial: max310x: Make max310x_remove() return voidUwe Kleine-König
Up to now max310x_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of spi remove callbacks is ignored anyway. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20211012153945.2651412-18-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-09Merge 5.14-rc5 into tty-nextGreg Kroah-Hartman
We need the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27serial: max310x: Use clock-names property matching to recognize EXTCLKAndy Shevchenko
Dennis reported that on ACPI-based systems the clock frequency isn't enough to configure device properly. We have to respect the clock source as well. To achieve this match the clock-names property against "osc" to recognize external clock connection. On DT-based system this doesn't change anything. Reported-and-tested-by: Dennis Giaya <dgiaya@whoi.edu> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210723125943.22039-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-21serial: max310x: Unprepare and disable clock in error pathAndy Shevchenko
In one error case the clock may be left prepared and enabled. Unprepare and disable clock in that case to balance state of the hardware. Fixes: d4d6f03c4fb3 ("serial: max310x: Try to get crystal clock rate from property") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210625153733.12911-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-31Merge 5.13-rc4 into tty-nextGreg Kroah-Hartman
We need the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-20serial: max310x: Try to get crystal clock rate from propertyAndy Shevchenko
In some configurations, mainly ACPI-based, the clock frequency of the device is supplied by very well established 'clock-frequency' property. Hence, try to get it from the property at last if no other providers are available. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210517172930.83353-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13serial: max310x: unregister uart driver in case of failure and abortAtul Gopinathan
The macro "spi_register_driver" invokes the function "__spi_register_driver()" which has a return type of int and can fail, returning a negative value in such a case. This is currently ignored and the init() function yields success even if the spi driver failed to register. Fix this by collecting the return value of "__spi_register_driver()" and also unregister the uart driver in case of failure. Cc: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Atul Gopinathan <atulgopinathan@gmail.com> Link: https://lore.kernel.org/r/20210503115736.2104747-12-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13Revert "serial: max310x: pass return value of spi_register_driver"Greg Kroah-Hartman
This reverts commit 51f689cc11333944c7a457f25ec75fcb41e99410. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. This change did not properly unwind from the error condition, so it was not correct. Cc: Kangjie Lu <kjlu@umn.edu> Acked-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-11-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-23tty: max310x: fix flexible_array.cocci warningskernel test robot
Zero-length and one-element arrays are deprecated, see Documentation/process/deprecated.rst Flexible-array members should be used instead. Generated by: scripts/coccinelle/misc/flexible_array.cocci Fixes: 10d8b34a42171 ("serial: max310x: Driver rework") CC: Denis Efremov <efremov@linux.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: kernel test robot <lkp@intel.com> Signed-off-by: Julia Lawall <julia.lawall@inria.fr> Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2103091516020.2892@hadrien Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-10Revert "serial: max310x: rework RX interrupt handling"Alexander Shiyan
This reverts commit fce3c5c1a2d9cd888f2987662ce17c0c651916b2. FIFO is triggered 4 intervals after receiving a byte, it's good when we don't care about the time of reception, but are only interested in the presence of any activity on the line. Unfortunately, this method is not suitable for all tasks, for example, the RS-485 protocol will not work properly, since the state machine must track the request-response time and after the timeout expires, a decision is made that the device on the line is not responding. Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Link: https://lore.kernel.org/r/20210217080608.31192-1-shc_work@mail.ru Fixes: fce3c5c1a2d9 ("serial: max310x: rework RX interrupt handling") Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-28serial: max310x: Use devm_clk_get_optional() to get the input clockAndy Shevchenko
Simplify the code which fetches the input clock by using devm_clk_get_optional(). If no input clock is present devm_clk_get_optional() will return NULL instead of an error which matches the behavior of the old code. Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20201007084635.594991-2-andy.shevchenko@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-28serial: max310x: Make use of device propertiesAndy Shevchenko
Device property API allows to gather device resources from different sources, such as ACPI. Convert the drivers to unleash the power of device property API. Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20201007084635.594991-1-andy.shevchenko@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-01serial: max310x: rework RX interrupt handlingThomas Petazzoni
Currently, the RX interrupt logic uses the RXEMPTY interrupt, with the RXEMPTYINV bit set, which means we get an RX interrupt as soon as the RX FIFO is non-empty. However, with the MAX310X having a FIFO of 128 bytes, this makes very poor use of the FIFO: we trigger an interrupt as soon as the RX FIFO has one byte, which means a lot of interrupts, each only collecting a few bytes from the FIFO, causing a significant CPU load. Instead this commit relies on two other RX interrupt events: - MAX310X_IRQ_RXFIFO_BIT, which triggers when the RX FIFO has reached a certain threshold, which we define to be half of the FIFO size. This ensure we get an interrupt before the RX FIFO fills up. - MAX310X_LSR_RXTO_BIT, which triggers when the RX FIFO has received some bytes, and then no more bytes are received for a certain time. Arbitrarily, this time is defined to the time is takes to receive 4 characters. On a Microchip SAMA5D3 platform that is receiving 20 bytes every 16ms over one MAX310X UART, this patch has allowed to reduce the CPU consumption of the interrupt handler thread from ~25% to 6-7%. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Link: https://lore.kernel.org/r/20201001074415.349739-1-thomas.petazzoni@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-05serial: max310x: turn off transmitter before activating AutoCTS or auto ↵Christoph Vogtländer
transmitter flow control As documented in the data-sheet, the transmitter must be disabled before activating AutoCTS or auto transmitter flow control. Accordingly, the transmitter must be enabled after AutoCTS or auto transmitter flow control gets deactivated. Signed-off-by: Christoph Vogtländer <c.vogtlaender@sigma-surface-science.com> Link: https://lore.kernel.org/r/20190904121746.4641-1-c.vogtlaender@sigma-surface-science.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-05serial: max310x: Properly set flags in AutoCTS modeChristoph Vogtländer
Commit 391f93f2ec9f ("serial: core: Rework hw-assisted flow control support") has changed the way the AutoCTS mode is handled. According to that change, serial drivers which enable H/W AutoCTS mode must set UPSTAT_AUTORTS, UPSTAT_AUTOCTS and UPSTAT_AUTOXOFF to prevent the serial core from inadvertently disabling RX or TX. This patch adds proper handling of UPSTAT_AUTORTS, UPSTAT_AUTOCTS and UPSTAT_AUTOXOFF flags. Signed-off-by: Christoph Vogtländer <c.vogtlaender@sigma-surface-science.com> Link: https://lore.kernel.org/r/20190904121141.4570-1-c.vogtlaender@sigma-surface-science.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04tty: max310x: fix off-by-one buffer access when storing overrunJan Kundrát
A recent change split the insertion loop into two parts. The first part accessed bytes 0, 1, ... (rxlen - 2), and the second part by mistake took offset `rxlen` instead of the correct `rxlen - 1`. So one byte was not stored, and the final access wrote past the end of the rx_buf. Fixes: 9c12d739d69b (tty: max310x: Split uart characters insertion loop) Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/13ea227620aaad8a7231d42ed03a8508297d4eb3.1567027079.git.jan.kundrat@cesnet.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-03Merge 5.2-rc3 into tty-nextGreg Kroah-Hartman
We want the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21tty: max310x: Fix external crystal register setupJoe Burmeister
The datasheet states: Bit 4: ClockEnSet the ClockEn bit high to enable an external clocking (crystal or clock generator at XIN). Set the ClockEn bit to 0 to disable clocking Bit 1: CrystalEnSet the CrystalEn bit high to enable the crystal oscillator. When using an external clock source at XIN, CrystalEn must be set low. The bit 4, MAX310X_CLKSRC_EXTCLK_BIT, should be set and was not. This was required to make the MAX3107 with an external crystal on our board able to send or receive data. Signed-off-by: Joe Burmeister <joe.burmeister@devtank.co.uk> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21tty: max310x: Split uart characters insertion loopSerge Semin
Batch read mode doesn't check any conditions or flags except the Rx overflow one. But it may only happen after the last character is pushed into the RHR register. In this case we shouldn't push all the read characters with overrun flag set, but only the last one caused the FIFO overflow. This commit splits the characters retrieval loop into two parts. First one is ordinary intsert-chars procedure without taking the overrun status into account. Second part inserts the last character checking whether the overrun happened and pushing a '\0' character with TTY_OVERRUN flag to a flip-buffer. If we left the loop the way it was the '\0' character would be inserted after each character retrieved at the overrun occasion. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21tty: max310x: Optionally enable rs485 on startupSerge Semin
UART port might be pre-configured with rs485 enabled flag at the time of the port starting up process. In this case we need to have the hardware rs485-related registers initialized in accordance with the rs485 flags and settings provided by the configs descriptor. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21tty: max310x: Add rx-during-tx rs485 flag supportSerge Semin
The driver currently sets the echo suppression bit by default when rs485 is enabled. Naturally it disables any data retrieval in rs485 mode while RTSn is pushed up. The receiver gate (RX_) can be enabled just by clearing (or not setting) the EchoSuprs bit of mode2 register. So by setting or clearing the bit we implement the SER_RS485_RX_DURING_TX rs485 flag support. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21tty: max310x: Fix invalid baudrate divisors calculatorSerge Semin
Current calculator doesn't do it' job quite correct. First of all the max310x baud-rates generator supports the divisor being less than 16. In this case the x2/x4 modes can be used to double or quadruple the reference frequency. But the current baud-rate setter function just filters all these modes out by the first condition and setups these modes only if there is a clocks-baud division remainder. The former doesn't seem right at all, since enabling the x2/x4 modes causes the line noise tolerance reduction and should be only used as a last resort to enable a requested too high baud-rate. Finally the fraction is supposed to be calculated from D = Fref/(c*baud) formulae, but not from D % 16, which causes the precision loss. So to speak the current baud-rate calculator code works well only if the baud perfectly fits to the uart reference input frequency. Lets fix the calculator by implementing the algo fully compliant with the fractional baud-rate generator described in the datasheet: D = Fref / (c*baud), where c={16,8,4} is the x1/x2/x4 rate mode respectively, Fref - reference input frequency. The divisor fraction is calculated from the same formulae, but making sure it is found with a resolution of 0.0625 (four bits). Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21tty: max310x: Don't pass stacked buffers to SPISerge Semin
SPI transfer tx/rx buffers must be DMA-safe and the structure documentation clearly states this. Data declared on the system stack isn't DMA-safe [1]. Instead at least kernel memory should be used for the buffers. In order to fix this here we can create the buffers at the device probing stage and use them without any synchronization, since batch read/write methods are called from non-reentrant contexts - either from rx-event IRQ threaded handler or from the tx workqueue item. [1] Documentation/DMA-API-HOWTO.txt Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21tty: max310x: Introduce max310x_one port macro-wrapperSerge Semin
uart_port structure instance is embedded into the max310x_one super-structure, which is accessed by some of the uart-port callback methods. In order to improve the callback's code readability lets define the to_max310x_port() wrapper which just translates the passed uart_port pointer to the max310x_one one. It is also going to be handy in future commits. Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21tty: max310x: Simplify tx-work item codeSerge Semin
Since cmwq introduction in the kernel, workqueues've been turned into non-reentrant execution contexts [1]. It means any work item is guaranteed to be executed by at most one worker system-wide at any given time. Since tx-handler max310x_handle_tx() is called by a single work item we don't need it to be self-protected by the mutex. We also don't need to check the tx work item pending state before scheduling it (which in the first place was racy btw), since cmwq will make sure to reschedule the item if it wasn't pending at the moment of schedule_work() call. [1] Documentation/core-api/workqueue.rst Signed-off-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-19serial: max310x: Fix to avoid potential NULL pointer dereferenceAditya Pakki
of_match_device can return a NULL pointer when matching device is not found. This patch avoids a scenario causing NULL pointer derefernce. Signed-off-by: Aditya Pakki <pakki001@umn.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-08serial: max310x: Correction of the initial setting of the MODE1 bits for ↵Alexander Shiyan
various supported ICs. The MODE1 register bits have different values for different ICs. This patch corrects the initial setting of this register in accordance with the datasheets, which will allow you to get the expected values when debugging the driver. Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-08serial: max310x: Use struct_size() in devm_kzalloc()Gustavo A. R. Silva
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; void *entry[]; }; instance = devm_kzalloc(dev, sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = devm_kzalloc(dev, struct_size(instance, entry, count), GFP_KERNEL); This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-08serial: max310x: pass return value of spi_register_driverKangjie Lu
spi_register_driver() may fail, so let's pass its return value upstream. Signed-off-by: Kangjie Lu <kjlu@umn.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-19serial: max310x: Fix tx_empty() callbackAlexander Shiyan
Function max310x_tx_empty() accesses the IRQSTS register, which is cleared by IC when reading, so if there is an interrupt status, we will lose it. This patch implement the transmitter check only by the current FIFO level. Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-28serial: max310x: Check the clock readinessJan Kundrát
This chip has a diagnostics status bit informing about the state and stability of the clock subsystem. According to the datasheet (STSint register, bit 5, ClockReady), this bit works with the crystal oscillator, but even without the PLL. Therefore: - ensure that the clock check is done even when PLL is not active - warn when the chip thinks that the clock is not ready yet There are HW features which would let us wait asynchronously (there's a maskable IRQ for that bit), but I think that even this simple check is a net improvement. It would have saved me two days of debugging :). Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-02-28gpio: serial: max310x: Use HW type for gpio_chip's labelJan Kundrát
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 <jan.kundrat@cesnet.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-09gpio: serial: max310x: Support open-drain configuration for GPIOsJan Kundrát
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>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-02 12:41:28 +0000