Unnecessary enforcement of 32-boundaries in oni_read_frame() about liboni HOT 1 OPEN

To be fair, while it might have originated from xillybus requirements, it now is more related to the general ONIX pipeline than any specific driver. This is because, for performance, we just pack the pipeline endpoint into 32-bit words. (Part of it is still 16-bit words, but we are actively working towards making the whole pipeline work natively at 32bit).

However, while this is true of all our current hardware, it is not necessarily true for any possible ONI implementation. That said, it is still good to cater for the possibility of some hardware having specific word sizes, as the opposite will entail unnecessary buffering (e.g.: asking for 5 bytes from a device only capable of streaming 16-bit words).

I think the proper solution would be to let the onidrivers to specify their read word size and use it instead of a fixed size. Of course, if this results in padding being required, it will be the hardware responsibility (as it is now, since it is the ONIX hardware which adds padding zeroes)

from liboni.