<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/tty/serial/imx.c, branch linux-6.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.9.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.9.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2024-07-18T11:22:50Z</updated>
<entry>
<title>serial: imx: ensure RTS signal is not left active after shutdown</title>
<updated>2024-07-18T11:22:50Z</updated>
<author>
<name>Rasmus Villemoes</name>
<email>linux@rasmusvillemoes.dk</email>
</author>
<published>2024-06-25T18:42:05Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e6cf5d6888b7436a891acf2e14af81b7b4574649'/>
<id>urn:sha1:e6cf5d6888b7436a891acf2e14af81b7b4574649</id>
<content type='text'>
commit 1af2156e58f3af1216ce2f0456b3b8949faa5c7e upstream.

If a process is killed while writing to a /dev/ttymxc* device in RS485
mode, we observe that the RTS signal is left high, thus making it
impossible for other devices to transmit anything.

Moreover, the -&gt;tx_state variable is left in state SEND, which means
that when one next opens the device and configures baud rate etc., the
initialization code in imx_uart_set_termios dutifully ensures the RTS
pin is pulled down, but since -&gt;tx_state is already SEND, the logic in
imx_uart_start_tx() does not in fact pull the pin high before
transmitting, so nothing actually gets on the wire on the other side
of the transceiver. Only when that transmission is allowed to complete
is the state machine then back in a consistent state.

This is completely reproducible by doing something as simple as

  seq 10000 &gt; /dev/ttymxc0

and hitting ctrl-C, and watching with a logic analyzer.

Signed-off-by: Rasmus Villemoes &lt;linux@rasmusvillemoes.dk&gt;
Cc: stable &lt;stable@kernel.org&gt;
Reviewed-by: Marek Vasut &lt;marex@denx.de&gt;
Link: https://lore.kernel.org/r/20240625184206.508837-1-linux@rasmusvillemoes.dk
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: imx: Raise TX trigger level to 8</title>
<updated>2024-07-11T10:51:05Z</updated>
<author>
<name>Matthias Schiffer</name>
<email>matthias.schiffer@ew.tq-group.com</email>
</author>
<published>2024-05-08T13:37:44Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9377188736a09567ed9af88b8737d7c64c5053f3'/>
<id>urn:sha1:9377188736a09567ed9af88b8737d7c64c5053f3</id>
<content type='text'>
[ Upstream commit a3d8728ab079951741efa11360df43dbfacba7ab ]

At the default TX trigger level of 2 in non-DMA mode (meaning that an
interrupt is generated when less than 2 characters are left in the
FIFO), we have observed frequent buffer underruns at 115200 Baud on an
i.MX8M Nano. This can cause communication issues if the receiving side
expects a continuous transfer.

Increasing the level to 8 makes the UART trigger an interrupt earlier,
giving the kernel enough time to refill the FIFO, at the cost of
triggering one interrupt per ~24 instead of ~30 bytes of transmitted
data (as the i.MX UART has a 32 byte FIFO).

Signed-off-by: Michael Krummsdorf &lt;michael.krummsdorf@tq-group.com&gt;
Signed-off-by: Matthias Schiffer &lt;matthias.schiffer@ew.tq-group.com&gt;
Link: https://lore.kernel.org/r/20240508133744.35858-1-matthias.schiffer@ew.tq-group.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>serial: imx: only set receiver level if it is zero</title>
<updated>2024-07-05T07:38:20Z</updated>
<author>
<name>Stefan Eichenberger</name>
<email>stefan.eichenberger@toradex.com</email>
</author>
<published>2024-07-03T11:25:40Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f05cdbe17a3fbd745554cf66767022b9660ee080'/>
<id>urn:sha1:f05cdbe17a3fbd745554cf66767022b9660ee080</id>
<content type='text'>
commit 9706fc87b4cff0ac4f5d5d62327be83fe72e3108 upstream.

With commit a81dbd0463ec ("serial: imx: set receiver level before
starting uart") we set the receiver level to its default value. This
caused a regression when using SDMA, where the receiver level is 9
instead of 8 (default). This change will first check if the receiver
level is zero and only then set it to the default. This still avoids the
interrupt storm when the receiver level is zero.

Fixes: a81dbd0463ec ("serial: imx: set receiver level before starting uart")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Stefan Eichenberger &lt;stefan.eichenberger@toradex.com&gt;
Link: https://lore.kernel.org/r/20240703112543.148304-1-eichest@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: imx: set receiver level before starting uart</title>
<updated>2024-07-05T07:38:10Z</updated>
<author>
<name>Stefan Eichenberger</name>
<email>stefan.eichenberger@toradex.com</email>
</author>
<published>2024-06-21T15:37:49Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0d6d5bb896db119b1489735213805d1374fcffb9'/>
<id>urn:sha1:0d6d5bb896db119b1489735213805d1374fcffb9</id>
<content type='text'>
commit a81dbd0463eca317eee44985a66aa6cc2ce5c101 upstream.

Set the receiver level to something &gt; 0 before calling imx_uart_start_rx
in rs485_config. This is necessary to avoid an interrupt storm that
might prevent the system from booting. This was seen on an i.MX7 device
when the rs485-rts-active-low property was active in the device tree.

Fixes: 6d215f83e5fc ("serial: imx: warn user when using unsupported configuration")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Stefan Eichenberger &lt;stefan.eichenberger@toradex.com&gt;
Link: https://lore.kernel.org/r/20240621153829.183780-1-eichest@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: imx: Introduce timeout when waiting on transmitter empty</title>
<updated>2024-06-27T11:52:18Z</updated>
<author>
<name>Esben Haabendal</name>
<email>esben@geanix.com</email>
</author>
<published>2024-04-11T12:19:23Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=53b2c95547427c358f45515a9f144efee95e3701'/>
<id>urn:sha1:53b2c95547427c358f45515a9f144efee95e3701</id>
<content type='text'>
[ Upstream commit e533e4c62e9993e62e947ae9bbec34e4c7ae81c2 ]

By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential
deadlock.

In case of the timeout, there is not much we can do, so we simply ignore
the transmitter state and optimistically try to continue.

Signed-off-by: Esben Haabendal &lt;esben@geanix.com&gt;
Acked-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Link: https://lore.kernel.org/r/919647898c337a46604edcabaf13d42d80c0915d.1712837613.git.esben@geanix.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tty: serial: imx: Fix broken RS485</title>
<updated>2024-03-02T21:10:35Z</updated>
<author>
<name>Rickard x Andersson</name>
<email>rickaran@axis.com</email>
</author>
<published>2024-02-21T11:53:04Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=672448ccf9b6a676f96f9352cbf91f4d35f4084a'/>
<id>urn:sha1:672448ccf9b6a676f96f9352cbf91f4d35f4084a</id>
<content type='text'>
When about to transmit the function imx_uart_start_tx is called and in
some RS485 configurations this function will call imx_uart_stop_rx. The
problem is that imx_uart_stop_rx will enable loopback in order to
release the RS485 bus, but when loopback is enabled transmitted data
will just be looped to RX.

This patch fixes the above problem by not enabling loopback when about
to transmit.

This driver now works well when used for RS485 half duplex master
configurations.

Fixes: 79d0224f6bf2 ("tty: serial: imx: Handle RS485 DE signal active high")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Rickard x Andersson &lt;rickaran@axis.com&gt;
Tested-by: Christoph Niedermaier &lt;cniedermaier@dh-electronics.com&gt;
Link: https://lore.kernel.org/r/20240221115304.509811-1-rickaran@axis.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: core, imx: do not set RS485 enabled if it is not supported</title>
<updated>2024-01-04T15:29:51Z</updated>
<author>
<name>Lino Sanfilippo</name>
<email>l.sanfilippo@kunbus.com</email>
</author>
<published>2024-01-03T06:18:16Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=74eab89b26ac433ad857292f4707b43c1a8f0209'/>
<id>urn:sha1:74eab89b26ac433ad857292f4707b43c1a8f0209</id>
<content type='text'>
If the imx driver cannot support RS485 it nullifies the ports
rs485_supported structure. But it still calls uart_get_rs485_mode() which
may set the RS485_ENABLED flag nevertheless.

This may lead to an attempt to configure RS485 even if it is not supported
when the flag is evaluated in uart_configure_port() at port startup.

Avoid this by bailing out of uart_get_rs485_mode() if the RS485_ENABLED
flag is not supported by the caller.

With this fix a check for RTS availability is now obsolete in the imx
driver, since it can not evaluate to true any more. So remove this check.

Furthermore the explicit nullifcation of rs485_supported is not needed,
since the memory has already been set to zeros at allocation. So remove
this, too.

Fixes: 00d7a00e2a6f ("serial: imx: Fill in rs485_supported")
Cc: Shawn Guo &lt;shawnguo@kernel.org&gt;
Cc: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Cc:  &lt;stable@vger.kernel.org&gt;
Suggested-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Lino Sanfilippo &lt;l.sanfilippo@kunbus.com&gt;
Reviewed-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240103061818.564-6-l.sanfilippo@kunbus.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: Do not hold the port lock when setting rx-during-tx GPIO</title>
<updated>2024-01-04T15:26:09Z</updated>
<author>
<name>Lino Sanfilippo</name>
<email>l.sanfilippo@kunbus.com</email>
</author>
<published>2024-01-03T06:18:12Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=07c30ea5861fb26a77dade8cdc787252f6122fb1'/>
<id>urn:sha1:07c30ea5861fb26a77dade8cdc787252f6122fb1</id>
<content type='text'>
Both the imx and stm32 driver set the rx-during-tx GPIO in rs485_config().
Since this function is called with the port lock held, this can be a
problem in case that setting the GPIO line can sleep (e.g. if a GPIO
expander is used which is connected via SPI or I2C).

Avoid this issue by moving the GPIO setting outside of the port lock into
the serial core and thus making it a generic feature.

Also with commit c54d48543689 ("serial: stm32: Add support for rs485
RX_DURING_TX output GPIO") the SER_RS485_RX_DURING_TX flag is only set if a
rx-during-tx GPIO is _not_ available, which is wrong. Fix this, too.

Furthermore reset old GPIO settings in case that changing the RS485
configuration failed.

Fixes: c54d48543689 ("serial: stm32: Add support for rs485 RX_DURING_TX output GPIO")
Fixes: ca530cfa968c ("serial: imx: Add support for RS485 RX_DURING_TX output GPIO")
Cc: Shawn Guo &lt;shawnguo@kernel.org&gt;
Cc: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Cc:  &lt;stable@vger.kernel.org&gt;
Signed-off-by: Lino Sanfilippo &lt;l.sanfilippo@kunbus.com&gt;
Link: https://lore.kernel.org/r/20240103061818.564-2-l.sanfilippo@kunbus.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: imx: Ensure that imx_uart_rs485_config() is called with enabled clock</title>
<updated>2024-01-04T15:21:30Z</updated>
<author>
<name>Christoph Niedermaier</name>
<email>cniedermaier@dh-electronics.com</email>
</author>
<published>2023-12-26T11:36:47Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7c45eaa813476bd195ac1227a64b52f9cf2e2030'/>
<id>urn:sha1:7c45eaa813476bd195ac1227a64b52f9cf2e2030</id>
<content type='text'>
There are register accesses in the function imx_uart_rs485_config(). The
clock must be enabled for these accesses. This was ensured by calling it
via the function uart_rs485_config() in the probe() function within the
range where the clock is enabled. With the commit 7c7f9bc986e6 ("serial:
Deassert Transmit Enable on probe in driver-specific way") it was removed
from the probe() function and is now only called through the function
uart_add_one_port() which is located at the end of the probe() function.
But the clock is already switched off in this area. To ensure that the
clock is enabled during register access, move the disabling of the clock
to the very end of the probe() function. To avoid leaking enabled clocks
on error also add an error path for exiting with disabling the clock.

Fixes: 7c7f9bc986e6 ("serial: Deassert Transmit Enable on probe in driver-specific way")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Christoph Niedermaier &lt;cniedermaier@dh-electronics.com&gt;
Reviewed-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Link: https://lore.kernel.org/r/20231226113647.39376-1-cniedermaier@dh-electronics.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: imx: Correct clock error message in function probe()</title>
<updated>2024-01-04T15:20:56Z</updated>
<author>
<name>Christoph Niedermaier</name>
<email>cniedermaier@dh-electronics.com</email>
</author>
<published>2023-12-24T09:32:09Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3e189470cad27d41a3a9dc02649f965b7ed1c90f'/>
<id>urn:sha1:3e189470cad27d41a3a9dc02649f965b7ed1c90f</id>
<content type='text'>
Correct the clock error message by changing the clock name.

Fixes: 1e512d45332b ("serial: imx: add error messages when .probe fails")
Signed-off-by: Christoph Niedermaier &lt;cniedermaier@dh-electronics.com&gt;
Reviewed-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Link: https://lore.kernel.org/r/20231224093209.2612-1-cniedermaier@dh-electronics.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
