When configuring a pin as an output pin with a value of logic 0, we
end up as having a value of logic 1 on the output pin. Setting a
logic 0 a second time (or more) after that will correctly output a
logic 0 on the output pin.

By default, all GPIO pins are configured as inputs. When we enter
sc16is7xx_gpio_direction_output() for the first time, we first set the
desired value in IOSTATE, and then we configure the pin as an output.
The datasheet states that writing to IOSTATE register will trigger a
transfer of the value to the I/O pin configured as output, so if the
pin is configured as an input, nothing will be transferred.

Therefore, set the direction first in IODIR, and then set the desired
value in IOSTATE.

This is what is done in NXP application note AN10587.

Fixes: dfeae619

 ("serial: sc16is7xx")
Cc: stable@vger.kernel.org
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Reviewed-by: Lech Perczak <lech.perczak@camlingroup.com>
Tested-by: Lech Perczak <lech.perczak@camlingroup.com>
Link: https://lore.kernel.org/r/20230807214556.540627-6-hugo@hugovil.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 679875d1 ("sc16is7xx: Separate GPIOs from modem control lines")
and commit 21144bab ("sc16is7xx: Handle modem status lines")
changed the function of the GPIOs pins to act as modem control
lines without any possibility of selecting GPIO function.

As a consequence, applications that depends on GPIO lines configured
by default as GPIO pins no longer work as expected.

Also, the change to select modem control lines function was done only
for channel A of dual UART variants (752/762). This was not documented
in the log message.

Allow to specify GPIO or modem control line function in the device
tree, and for each of the ports (A or B).

Do so by using the new device-tree property named
"nxp,modem-control-line-ports" (property added in separate patch).

When registering GPIO chip controller, mask-out GPIO pins declared as
modem control lines according to this new DT property.

Fixes: 679875d1 ("sc16is7xx: Separate GPIOs from modem control lines")
Fixes: 21144bab

 ("sc16is7xx: Handle modem status lines")
Cc: stable@vger.kernel.org
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Lech Perczak <lech.perczak@camlingroup.com>
Tested-by: Lech Perczak <lech.perczak@camlingroup.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230807214556.540627-5-hugo@hugovil.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Some variants in this series of UART controllers have GPIO pins that
are shared between GPIO and modem control lines.

The pin mux mode (GPIO or modem control lines) can be set for each
ports (channels) supported by the variant.

This adds a property to the device tree to set the GPIO pin mux to
modem control lines on selected ports if needed.

Cc: stable@vger.kernel.org # 6.1.x
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Lech Perczak <lech.perczak@camlingroup.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230807214556.540627-4-hugo@hugovil.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit c8f71b49

 ("serial: sc16is7xx: setup GPIO controller later
in probe") moved GPIO setup code later in probe function. Doing so
also required to move ports cleanup code (out_ports label) after the
GPIO cleanup code.

After these moves, the out_thread label becomes misplaced and makes
part of the cleanup code illogical.

This patch remove the now obsolete out_thread label and make GPIO
setup code jump to out_ports label if it fails.

Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Reviewed-by: Lech Perczak <lech.perczak@camlingroup.com>
Tested-by: Lech Perczak <lech.perczak@camlingroup.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20230807214556.540627-3-hugo@hugovil.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The sc16is7xx_config_rs485() function is called only for the second
port (index 1, channel B), causing initialization problems for the
first port.

For the sc16is7xx driver, port->membase and port->mapbase are not set,
and their default values are 0. And we set port->iobase to the device
index. This means that when the first device is registered using the
uart_add_one_port() function, the following values will be in the port
structure:
    port->membase = 0
    port->mapbase = 0
    port->iobase  = 0

Therefore, the function uart_configure_port() in serial_core.c will
exit early because of the following check:
	/*
	 * If there isn't a port here, don't do anything further.
	 */
	if (!port->iobase && !port->mapbase && !port->membase)
		return;

Typically, I2C and SPI drivers do not set port->membase and
port->mapbase.

The max310x driver sets port->membase to ~0 (all ones). By
implementing the same change in this driver, uart_configure_port() is
now correctly executed for all ports.

Fixes: dfeae619

 ("serial: sc16is7xx")
Cc: stable@vger.kernel.org
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Lech Perczak <lech.perczak@camlingroup.com>
Tested-by: Lech Perczak <lech.perczak@camlingroup.com>
Link: https://lore.kernel.org/r/20230807214556.540627-2-hugo@hugovil.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

When there's no irq(this can be due to various reasons, for example,
no irq from HW support, or we just want to use poll solution, and so
on), falling back to poll is still better than no support at all.

Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Link: https://lore.kernel.org/r/20230806092056.2467-3-jszhang@kernel.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The driver fall back to poll style when there's no irq. "poll" still
looks better than no support.

Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230806092056.2467-2-jszhang@kernel.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

In tegra_uart_hw_init(), the return value of clk_prepare_enable() should
be checked since it might fail.

Fixes: e9ea096d

 ("serial: tegra: add serial driver")
Signed-off-by: Yi Yang <yiyang13@huawei.com>
Link: https://lore.kernel.org/r/20230817105406.228674-1-yiyang13@huawei.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

If the Sifive Uart is not used as the wake up source, suspend the uart
before the system enter the suspend state to prevent it woken up by
unexpected uart interrupt. Resume the uart once the system woken up.

Signed-off-by: Nick Hu <nick.hu@sifive.com>
Reviewed-by: Ben Dooks <ben.dooks@codethink.co.uk>
Link: https://lore.kernel.org/r/20230815090216.2575971-1-nick.hu@sifive.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The new Amlogic T7 SoC does not have a always-on uart,
so add OF_EARLYCON_DECLARE for it.

Signed-off-by: Lucas Tanure <tanure@linux.com>
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20230814080128.143613-2-tanure@linux.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Amlogic T7 SoCs uses the same UART controller as S4 SoCs and G12A.
There is no need for an extra compatible line in the driver, but
add T7 compatible line for documentation.

Signed-off-by: Lucas Tanure <tanure@linux.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230814080128.143613-1-tanure@linux.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

In shutdown, RX DMA channel is terminated. If the DMA RX callback is
scheduled but not yet executed, while a new RX DMA transfer is started, the
callback can be executed, and then disturb the ongoing RX DMA transfer.
To avoid such a case, call dmaengine_synchronize in shutdown, after the
DMA RX channel is terminated.

Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Signed-off-by: Valentin Caron <valentin.caron@foss.st.com>
Link: https://lore.kernel.org/r/20230808161906.178996-7-valentin.caron@foss.st.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

It's rather advised to rely on DMA pause / resume instead of
clearing/setting DMA request enable bit for the same purpose. Some DMA
request/acknowledge race may encountered by doing so. We prefer to use
dmaengine_pause and resume instead to pause a dma transfer when it is
necessary.

Create two new functions (stm32_usart_rx_dma_pause, stm32_usart_rx_dma
_resume) to handle dma error when pausing/resuming.

And rename stm32_usart_start_rx_dma_cyclic() to
stm32_usart_rx_dma_start_or_resume() and use this function to resume an
rx dma transfer. If resume fail, stm32_usart_rx_dma_start_or_resume can
create a new transfer to continue.

It is also safer to close DMA before reset DMAR in stm32_usart_shutdown.

Signed-off-by: Valentin Caron <valentin.caron@foss.st.com>
Link: https://lore.kernel.org/r/20230808161906.178996-6-valentin.caron@foss.st.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Create new function "stm32_usart_dma_pause_resume" that called dmaengine_
pause/resume and in case of error, terminate dma transaction.

Two other functions are created to facilitate the use of stm32_usart_dma
_pause_resume : stm32_usart_tx_dma_pause, stm32_usart_tx_dma_resume.
Equivalent functions for rx will be added in future patch.

Signed-off-by: Valentin Caron <valentin.caron@foss.st.com>
Link: https://lore.kernel.org/r/20230808161906.178996-5-valentin.caron@foss.st.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Rename stm32_usart_rx_dma_enabled to stm32_usart_rx_dma_started in order
to match with stm32_usart_tx_dma_started.

Modify argument of stm32_usart_rx_dma_started from uart_port structure to
stm32_port structure to match with stm32_usart_tx_dma_started.

Signed-off-by: Valentin Caron <valentin.caron@foss.st.com>
Link: https://lore.kernel.org/r/20230808161906.178996-4-valentin.caron@foss.st.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

DMAT is a configuration bit so it should be set at the startup of uart
port and not when a DMA transfer begins.

This patch move set of DMAT into set_termios and remove DMAT reset except
in shutdown.

Signed-off-by: Valentin Caron <valentin.caron@foss.st.com>
Link: https://lore.kernel.org/r/20230808161906.178996-3-valentin.caron@foss.st.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

It's rather advised to rely on DMA pause / resume instead of
clearing/setting DMA request enable bit for the same purpose. Some DMA
request/acknowledge race may encountered by doing so. We prefer to use
dmaengine_pause and resume instead to pause a dma transfer when it is
necessary.

It is also safer to close DMA before reset DMAT in stm32_usart_shutdown.

Signed-off-by: Valentin Caron <valentin.caron@foss.st.com>
Link: https://lore.kernel.org/r/20230808161906.178996-2-valentin.caron@foss.st.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently, changing the parameters of the n_gsm mux gives no direct control
to the user whether this should trigger a mux reset or not. The decision is
solely made by the driver based on the assumption which parameter changes
are compatible or not. Therefore, the user has no means to perform an
automatic mux reset after parameter configuration for non-conflicting
changes.

Add the parameter 'flags' to 'gsm_config_ext' to force a mux reset after
ioctl setting regardless of whether the changes made require this or not
by setting this to 'GSM_FL_RESTART'. This is done similar to
'GSM_FL_RESTART' in gsm_dlci_config.flags.

Note that 'GSM_FL_RESTART' is currently the only allowed flag to allow
additions here.

Signed-off-by: Daniel Starke <daniel.starke@siemens.com>
Link: https://lore.kernel.org/r/20230817093231.2317-9-daniel.starke@siemens.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There are multiple places in gsm_control_command and gsm_control_reply that
derive the specific DLCI handle directly out of the DLCI table in gsm.

Add a local variable which holds this handle and use it instead to improve
code readability.

Signed-off-by: Daniel Starke <daniel.starke@siemens.com>
Link: https://lore.kernel.org/r/20230817093231.2317-7-daniel.starke@siemens.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The structure gsm_mux contains the 'unsupported' field. However, there is
currently no place in the code which increases this counter.

Increase the 'unsupported' statistics counter in the following case:
- an unsupported frame type has been requested by the peer via parameter
  negotiation
- a control frame with an unsupported but known command has been received

Note that we have no means to detect an inconsistent/unsupported adaptation
sufficient accuracy as this changes the structure of the UI/UIH frames.
E.g. a one byte header is added in case of convergence layer type 2 instead
of 1 and contains the modem signal octet with the state of the signal
lines. There is no checksum or other value which indicates of this field is
correct or should be present. Therefore, we can only assume protocol
correctness here. See also 'gsm_dlci_data()' where this is handled.

Signed-off-by: Daniel Starke <daniel.starke@siemens.com>
Link: https://lore.kernel.org/r/20230817093231.2317-6-daniel.starke@siemens.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The malformed counter in gsm_mux is already increased in case of errors
detected in gsm_queue() and gsm1_receive(). gsm_dlci_command() also
detects a case for a malformed frame but does not increase the malformed
counter yet.

Fix this by also increasing the gsm_mux malformed counter in case of a
malformed frame in gsm_dlci_command().
Note that the malformed counter is not yet exposed and only set internally.

Signed-off-by: Daniel Starke <daniel.starke@siemens.com>
Link: https://lore.kernel.org/r/20230817093231.2317-5-daniel.starke@siemens.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Extend the n_gsm link statistics by a failed link open counter in
preparation for an upcoming patch which will expose these.
This counter is increased whenever an attempt to open the control channel
failed. This is true in the following cases:
- new DLCI allocation failed
- connection request (SAMB) with invalid CR flag has been received
- connection response (UA) timed out
- parameter negotiation timed out or failed

Signed-off-by: Daniel Starke <daniel.starke@siemens.com>
Link: https://lore.kernel.org/r/20230817093231.2317-4-daniel.starke@siemens.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The variable 'ret' is not used before assignment from gsm_activate_mux().
Still it gets initialized to zero at declaration.

Fix this as remarked in the link below by moving the declaration to the
first assignment.

Link: https://lore.kernel.org/all/b42bc4d1-cc9d-d115-c981-aaa053bdc59f@kernel.org/



Signed-off-by: Daniel Starke <daniel.starke@siemens.com>
Link: https://lore.kernel.org/r/20230817093231.2317-3-daniel.starke@siemens.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently, all available structure fields in gsmmux.h except those
for gsm_config are commented. Furthermore, no kernel doc comments are used.

Fix this by adding appropriate comments to the not commented fields of
gsm_config. Convert the comments of the other structs to kernel doc format.

Note that 'mru' and 'mtu' refer to the size without basic/advanced option
mode header and byte stuffing as defined in the standard in chapter 5.7.2.

Link: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516


Signed-off-by: Daniel Starke <daniel.starke@siemens.com>
Link: https://lore.kernel.org/r/20230817093231.2317-2-daniel.starke@siemens.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently, changing the parameters of a DLCI gives no direct control to the
user whether this should trigger a channel reset or not. The decision is
solely made by the driver based on the assumption which parameter changes
are compatible or not. Therefore, the user has no means to perform an
automatic channel reset after parameter configuration for non-conflicting
changes.

Add the parameter 'flags' to 'gsm_dlci_config' to force a channel reset
after ioctl setting regardless of whether the changes made require this or
not by setting this to 'GSM_FL_RESTART'.

Note that 'GSM_FL_RESTART' is currently the only allow flag to allow
additions here.

Signed-off-by: Daniel Starke <daniel.starke@siemens.com>
Link: https://lore.kernel.org/r/20230817093231.2317-1-daniel.starke@siemens.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

For the last couple of years Linux kernel got rid of a few architectures
and many platforms. Hence some PORT_* definitions in the serial_core.h
become unused and redundant. Remove them for good.

Removed IDs are checked for users against Debian Code Search engine.
Hence safe to remove as there are no consumers found (only providers).

While at it, add a note about 0-13, that are defined in the other file.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230821083857.1065282-1-andriy.shevchenko@linux.intel.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

We are used to handle "bad" states in the 'if's in the kernel. Refactor
(invert the two conditions in) __tty_buffer_request_room(), so that the
code returns from the fast paths immediately instead of postponing to
the heavy end of the function.

Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230816105530.3335-11-jirislaby@kernel.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

It makes the code both more compact, and more understandable.

Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230816105530.3335-10-jirislaby@kernel.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

* use bool for 'change' as it holds a result of a boolean.
* use size_t for 'left', so it is the same as 'size' which it is
  compared to. Both are supposed to contain an unsigned value.

Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230816105530.3335-9-jirislaby@kernel.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Use __tty_insert_flip_string_flags() for the slow path of
tty_insert_flip_char(). The former is generic enough, so there is no
reason to reimplement the injection once again.

So now we have a single function stuffing into tty buffers.

Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230816105530.3335-8-jirislaby@kernel.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The same as in the previous patch, tty_prepare_flip_string() accepts
size_t as an size argument. It returns the same size (or less). It is
unexpected that it returns a signed value and can confuse users to check
for negative values.

Instead, return the same size_t as accepted to make clear we return
values >= 0, where zero in fact means failure.

Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230816105530.3335-7-jirislaby@kernel.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

All the functions accept size_t as a size argument. They finally return
the same size (or less). It is quite unexpected that they return a
signed value and can confuse users to check for negative values.

Instead, return the same size_t as accepted to make clear we return
values >= 0, where zero in fact means failure.

Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230816105530.3335-6-jirislaby@kernel.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

And add a WARN_ON_ONCE(need_flags) to make sure we are not losing flags
in __tty_insert_flip_string_flags().

Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230816105530.3335-5-jirislaby@kernel.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

They both do the same except for flags. One mem-copies the flags from
the caller, the other mem-sets to one flag given by the caller. This can
be unified with a simple if in the unified function.

Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230816105530.3335-4-jirislaby@kernel.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Now, that tty_buffer::data has the right type, use struct_size() for
size calculation. struct_size() makes the code less error-prone and more
readable.

Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230816105530.3335-3-jirislaby@kernel.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is no reason to have tty_buffer::data typed as unsigned long.
Switch to u8, but preserve the ulong alignment using __aligned.

This allows for the cast removal from char_buf_ptr(). And for use of
struct_size() in the allocation in tty_buffer_alloc() -- in the next
patch.

Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230816105530.3335-2-jirislaby@kernel.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

My thinking was that ulong is the same as size_t everywhere. No, size_t
is uint on 32bit. So the below commit introduced a build warning on
32bit:
.../gdm724x/gdm_tty.c:165:24: warning: comparison of distinct pointer types ('typeof (2048UL) *' (aka 'unsigned long *') and 'typeof (remain) *' (aka 'unsigned int *'))

To fix this, partially revert the commit (remove constants' suffixes)
and switch to min_t() in this case instead.

/me would hope for Z (or alike) suffix for constants.

Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Fixes: c3e5c706

 (tty: gdm724x: convert counts to size_t)
Reported-by: Nathan Chancellor <nathan@kernel.org>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202308151953.rNNnAR2N-lkp@intel.com/


Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Nathan Chancellor <nathan@kernel.org> # build
Link: https://lore.kernel.org/r/20230816085322.22065-1-jirislaby@kernel.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge commit b320441c ("Merge tag 'tty-6.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty"

) into tty-next

We need the serial-core fixes in here as well.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Pull tty/serial fixes from Greg KH:
 "Here are some small tty and serial core fixes for 6.5-rc7 that resolve
  a lot of reported issues.

  Primarily in here are the fixes for the serial bus code from Tony that
  came in -rc1, as it hit wider testing with the huge number of
  different types of systems and serial ports. All of the reported
  issues with duplicate names and other issues with this code are now
  resolved.

  Other than that included in here is:

   - n_gsm fix for a previous fix

   - 8250 lockdep annotation fix

   - fsl_lpuart serial driver fix

   - TIOCSTI documentation update for previous CAP_SYS_ADMIN change

  All of these have been in linux-next for a while with no reported
  problems"

* tag 'tty-6.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  serial: core: Fix serial core port id, including multiport devices
  serial: 8250: drop lockdep annotation from serial8250_clear_IER()
  tty: n_gsm: fix the UAF caused by race condition in gsm_cleanup_mux
  serial: core: Revert port_id use
  TIOCSTI: Document CAP_SYS_ADMIN behaviour in Kconfig
  serial: 8250: Fix oops for port->pm on uart_change_pm()
  serial: 8250: Reinit port_id when adding back serial8250_isa_devs
  serial: core: Fix kmemleak issue for serial core device remove
  MAINTAINERS: Merge TTY layer and serial drivers
  serial: core: Fix serial_base_match() after fixing controller port name
  serial: core: Fix serial core controller port name to show controller id
  serial: core: Fix serial core port id to not use port->line
  serial: core: Controller id cannot be negative
  tty: serial: fsl_lpuart: Clear the error flags by writing 1 for lpuart32 platforms

Pull rust fix from Miguel Ojeda:

 - Macros: fix 'HAS_*' redefinition by the '#[vtable]' macro
   under conditional compilation

* tag 'rust-fixes-6.5-rc7' of https://github.com/Rust-for-Linux/linux:
  rust: macros: vtable: fix `HAS_*` redefinition (`gen_const_name`)