LabVIEW
Do I have any control of the USB-C ports on a cRIO-9053?
USB is not I2C or SPI so no without an external USB to I2C or SPI hardware adapter you won't be able to use that port as such.
For the rest it is all very vague. Your first sentence sounds like you want to talk to a device connected to that USB port. The second question sounds like the opposite where you want the USB C port on the cRIO to be a device interface that an external master can control. What master device? How?
If you can explain in more detail what you really want to do we may be able to help with some real suggestions. Right now it sounds like you ask some random questions without even knowing yourself what you really want.
The default usage of that USB C port on those controllers is to use it as a more modern form of Display Port interface for an external monitor. It's not the only possible usage for USB C ports but using USB ports for random hardware connections is something that has never been possible. USB is too complex to use it through generic interfaces. There is always some specific system driver needed that talks the actual protocol of the device that is connected to the USB port and USB C has made that only even more complex and not just by a percentage but by at least a magnitude if not more.
Without a kernel driver on the cRIO that talks your dongle protocol (whatever that is) and translates it into something useful on the cRIO for the NI Linux OS, I would not see how that can be useful. Something specific for your dongle has to be present in the Linux OS and be prepared to connect to your dongle when it is attached. So do you have a Linux kernel driver for your dongle? Do you have a driver at all for your dongle (Windows, whatever)?
In recent NI Linux versions (~LabVIEW 2018 or newer) the FTDI chips are by default recognized by the installed FTDI compatible driver. There should not be any need to execute special commands anymore. In earlier versions, depending on the actual serial device you had to edit the udev and before 2014 the mdev configuration to load a specific driver for certain USB serial port devices. Stock FTDI should usually work even there.
Your specific device does use a FTDI chip but with custom manufacturer and product ID. Since these two are the way Linux and any other OS identifies USB devices, and it is not a standard device contained in the according USB device ID database that was included with the build of your USB subsystem, you have to hold hands for Linux and tell it manually what driver these product and manufacturer ID should map to. This is what the documentation in the Omron documentation explains. This works since the hardware really is an FTDI RS232 compatible chip and since the Linux OS contains such a driver already, it just doesn't know that it should use that driver for this device.
For other hardware, things are usually a bit more complex, especially if it is self made hardware. If you are lucky there is a ready made stock driver for the hardware chip you used on the board and you just have to make sure that driver is installed and then tell Linux that your manufacturer and product ID map to that driver.
Another less convenient situation is if there is a Linux driver in source code for the chip but it is not a standard Linux driver and hence not included in standard kernel distributions, that the NI Linux kernel tracks indirectly through the upstream repositories. In this case you have to compile the driver yourself for the NI Linux target in question, install it on the target according to the build scripts for that driver and possibly map it also to your specific manufacturer and product ID, if you customized them.
If you don't have the ready made source code for a driver, you have to write it yourself, which only is possible if you have the low level chip documentation and you also need a bit of courage. Kernel driver development is not for the faint of heart!
If your device doesn't have a driver tracked in the main kernel, or the source code for a working driver is not available to compile it yourself for the RIO hardware, or you can't get the low level documentation for the hardware and write a driver yourself or hire someone to do so, you can consider your piece of hardware a nice decoration object on your desk as far as using it with a NI RIO device or any other non-mainstream Linux platform is concerned. For specific Linux desktop distributions, the hardware manufacturers may sometimes provide precompiled drivers, but if you ask such a manufacturer about a myRIO (or cRIO) compatible driver you will at best get a bewildered "For What??" or simply a blank star.
