Param change command is queued into a separate thread for completion and control immediately returns to ucom_param to schedule the transfer enable and line state change commands, along with a quick return to the tty layer. As as side effect, tcsetattr (for instance) may return long before params reach the hardware and things can go a bit belly up without introducing artificial delays.
While here, push the knowledge of what gets executed synchronously out of ucom_queue_command. While it's likely an OK assumption that ucom_cfg_close should always be executed synchronously, there's only one caller for it and this makes it a bit easier to determine at the call-site whether the command will be executed asynchronously or not.
I also tend to wonder if ucom_cfg_open and/or ucom_cfg_line_state should also be synchronous changes, but I don't have as strong of feelings about these.