Closed bstreiff closed 1 year ago
@ni/rtos
also pinging @sjasonsmith who also expressed a desire to look at this but whom I cannot seem to add as a reviewer
The generic "transceiver interface" that was added in the earliest patches is now gone-- transceiver enable/disable just happens in the port startup/shutdown callbacks now. Having that as a separate API might have been nice, but I think it'd only be justifiable if I ported other 8250 drivers to use it
I think that when this was originally created there were not yet upstream mechanisms for RS-485 configuration. It's role decreased as it was merged with newer kernel versions, until finally reaching complete obsolescence in this PR.
changes in v2:
BIT
macroni16550_config_rs485
-> ni16550_rs485_config
to match struct member it is assigned toport->rs485
(uart_set_rs485_config
does this for us)rs485_supported
to declare supportACR
for parity with PCI devicestxvr_ops
as deprecated (note AzDO#2280538)I've reset approvals in order to review v2.
v3 drops the rts delay stuff out of the rs485-supported struct.
Merged into nilrt/master/6.0
The National Instruments (NI) 16550 is a standard 16550 with larger FIFOs and embedded RS-232/RS-485 transceiver control circuitry. This patch adds a driver that can operate this UART.
This patch set is a combination and reformulation of
There are significant differences between that pile of patches and what we have here, which is:
CONFIG_SERIAL_8250_NI
instead ofCONFIG_SERIAL_8250_NI16550
-- this lets the two implementations live side-by-side in our tree (rationale below)platform_device
instead of a pile of custom initialization bodged into the8250_pnp
code. This pushes more of the NI16550-specific code into its own file (and reducing future merge conflicts)platform_device
, on x64, device enumeration happens a little bit differently than enumeration via the legacy PNP system. This should be invisible to most users unless they go digging real hard in sysfs ($(realpath /sys/class/tty/ttyS1)
on a cRIO-904x becomes/sys/devices/pci0000:00/0000:00:1f.0/NIC792B:00/tty/ttyS1
instead of/sys/devices/pnp0/00:01/tty/ttyS1
-- however most users are probably just going to be using/dev/ttyS1
, which doesn't change.)PORT_NI16550_*
is gone; we just usePORT_16550A
. This is a visible change to userspace (/sys/class/ttyS1/type
and also viaserial_struct::type
with theTIOCGSERIAL
ioctl), but userspace could not rely on the values we had been using anyway (since we had to keep renumbering on every kernel upgrade). Note that use of this field for identification purposes seems to have fallen out of fashion-- in fact for USB serial devices as of f64d74a59c47 they all just returnPORT_UNKNOWN
.NI_16BYTE_FIFO
is gone now (as are the distinctni,ni16550-f16
andni,ni16550-f128
OF names)-- instead we look at theTFS
/RFS
registers; these have been present in the common UART core since at least 2012, and if they're somehow not there, then 128 bytes seems fine as an assumption, since the single 16-byte-FIFO instantiation seems to have been the exception.NI_CAP_PMR
has a slightly more interesting tale-- it was added to the common core in 2014, shipped in the CVS product line, and then removed with no explanation in 2015. (Filed AzDO 2275198 to HW about that.) At any rate, in the current version of the register map, that register is now no longer reserved and there's risk that it could be reused for some future purpose, so we have to keep the magic flag. :(ni,ni16550
OF ID becausecheckpatch.pl
complains about it.checkpatch.pl
also complains if you don't put it in its own commit, which is why it's separated. I didn't actually try to give this a spin on a device using OF-based enumeration (aka Zynq-based cRIO) due to the effort involved in getting this version of the driver working with the current Zynq kernel.This is hopefully a lot cleaner and more upstream-acceptable-- but because it's a significant reworking, I'd like for it to simmer in our trees for a little bit to get some ATS runtime (in particular, get some testing on more than just a cRIO-904x with hand-testing with pyserial!). If it causes problems, we have a quick escape hatch (we can flip the kconfig token back)-- if it turns out good, then we can start tackling reverts on the older implementation.
You might also notice that "8250_ni" is named kind of generically-- I did consider trying to add support for PCI/PXI devices, at least to the extent of the since-reverted attempt in fdc2de87124f ("serial/8250: Add support for NI-Serial PXI/PXIe+485 devices."). I think this is viable to add to 8250_ni (the RS-232 control register looks the same, so this mostly amounts to "add PCI enumeration and
num_ports
/address offsetting)), but wouldn't be a total replacement for the NI-Serial ni843x driver (lack of DMA). Maybe later...I went with citing Jaeden and Karthik as the original authors-- most of the other changes since then have been mostly-trivial adding of IDs and/or handling the effects of 8250 core changes. Let me know if you think that should change.