Either will work fine, but you are unlikely to find any commercial devices that run at your peculiar baud-rate.
It would be perfectly OK if you are sending data to something else that you have made.

Hi, I did not mention having an FPGA on each side, not commercial devices. For example simple UART interface between two FPGAs. Then Tx and Rx will support the said baud rate, right ? If Tx and Rx are made with custom logic.

 

Hi, I did not mention having an FPGA on each side, not commercial devices. For example simple UART interface between two FPGAs. Then Tx and Rx will support the said baud rate, right ? If Tx and Rx are made with custom logic.

Yes.
Have you thought about using synchronous data and sending a clock signal (like SPI)? It requires less logic synchronise.
FPGAs aren't my thing, but I'm sure you can make an SPI interface more easily than a UART

 

It is very common for one MCU to communicate with another MCU via UART protocol. Think about it. If both MCUs, even from different families and manufacturers, are operating from 8MHz crystals, or multiples of 8MHz, then the error in baud will be extremely small at whatever common baud you select.

 

How about baud rate 100,000 instead of 115,200 ? If UART clock running at 10 MHz would there be any baud error ?

Or 80,000 instead of 115,000 ? If UART clock running at 8 MHz would there be any baud error ?

The problem depends on the set of integer divisors available. The set of integer divisors that will produce a set of baud rates with minimal error is the same when identical hardware is used on both sides. As was mentioned earlier in this thread the availability of a PLL increases the set of possible baud rates considerably. Lastly, we come to the problem of different hardware on either side of the UART where the set of available baud rates with minimal error happens to be the empty set. In this case using a non-standard crystal on one of the devices is arguably the best alternative.