drivers/serial/uart_ns16550: CMD_SET_DLF should be removed

[ghost]

This part of the uart drv_cmd API should be either public-facing or removed.

The value of the DLF is a function of the baud rate, and IMO shouldn't be manipulated independently. It should be accounted for in set_baud_rate() (if at all), so the API and orphaned header should be removed.

[dcpleung]

IIRC, DLF is a Synopsys extension to 16550 on their DesignWare IP block. It is there to manipulate the clock divisor to get certain baud rate.

[ghost]

IIRC, DLF is a Synopsys extension to 16550 on their DesignWare IP block. It is there to manipulate the clock divisor to get certain baud rate.

Yeah. It's a trim value of sorts, which accounts for the fact that common baud rates can't be precisely derived from "nice" clocks (e.g., 25MHz). Currently there's a method to set this at boot (via devicetree) just as there's a boot-time baud rate. Arguably if the value is going to be dynamic (that is, the baud rate is going to change at run time), then set_baud_rate() should be modified to compute the right value or use a table or something, rather than a separate ioctl-style call.

[dcpleung]

Maybe something like the quirks in Linux kernel would work here. But then the driver will need to identify the chips (via vendor/device IDs) to apply those quirks. It could get complicated as the ID table often needs to be expanded for new chips.

[ghost]

Well, I think we can rely on the current scheme or some minor modification thereof: just use devicetree to say "yes, use DLF on this port". We need not include any DLF-related code if the DT for the board/SoC doesn't mention it.