Skip to content

drivers: serial: uart_mcux_lpuart: Fix pinctrl flow control #88866

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

bas-archembedded
Copy link
Contributor

Currently the driver code does not actually request the flow control state, it only checks if the state exists. To fix this we should simply call pinctrl_apply_state() and if that fails, meaning no flow control state exists, fall back to default pin mux settings.

Another case that needed fixing is run time flow control enabling ie in the case where we have a WIFI/bluetooth module connected and we initially operate without flow control but later enable it after firmware download.

This patch addresses this as well by making a generic function to achieve this.

@github-actions github-actions bot added platform: NXP Drivers NXP Semiconductors, drivers area: UART Universal Asynchronous Receiver-Transmitter labels Apr 21, 2025
@bas-archembedded bas-archembedded force-pushed the dev/fix_flowctrl_pinctrl branch from 63d58b9 to f350689 Compare April 21, 2025 15:07
@dcpleung dcpleung assigned mmahadevan108 and dleach02 and unassigned dcpleung Apr 21, 2025
@dleach02
Copy link
Member

@bas-archembedded is there a test case in Zephyr that would test for this?

dleach02
dleach02 previously approved these changes Apr 23, 2025
@bas-archembedded
Copy link
Contributor Author

@dleach02 Not that I can find, but I have tested this using the "hci_nxp_setup" stuff to bring up a NXP IW612 based module and getting bluetooth and WIFI working at the same time with independent firmware(s).

I am still waiting to get access to some proprietary protocol information of that module but it seems it needs a nudge over the RTS line to get going after the WIFI firmware was loaded.

@dleach02
Copy link
Member

@bas-archembedded can you address the compliance error.

Currently the driver code does not actually request the flow control
state, it only checks if the state exists. To fix this we should
simply call pinctrl_apply_state() and if that fails, meaning no
flow control state exists, fall back to default pin mux settings.

Another case that needed fixing is run time flow control enabling
ie in the case where we have a WIFI/bluetooth module connected
and we initially operate without flow control but later enable
it after firmware download.

This patch addresses this as well by making a generic function
to achieve this.

Signed-off-by: Bas van Loon <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: UART Universal Asynchronous Receiver-Transmitter platform: NXP Drivers NXP Semiconductors, drivers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants