On Mon, May 01, 2017 at 09:39:23AM +0200, Bjørn Mork wrote:
"Tobin C. Harding" <me@tobin.cc> writes:
Should [drivers/staging/*] patches to endian code be tested on hardware before submission?
All patches should be tested before submission, IF possible.
But there is no reason to hold back a patch just because you cannot test it yourself. Submit it anyway, noting the level of testing you have done. E.g. "build-tested only", or "verified on LE but not tested on BE", or whatever you find appropriate.
It is not uncommon for the author/submitter to be unable to test bug fixes on real hardware. Many endian fixes will be obvious enough to make testing unnessary. And even if the maintainer thinks testing is necessary, there might be reviewers with the necessary hardware but without the time or insight to write the code.
I don't think there ever is a reason not to post a patch. Just make sure that you have done as much as you can to verify it yourself, and describe what you have done. Make it clear if you think it needs more testing, and why you haven't done that. Missing hardware is a very good reason.
During recent development of ks7010 driver, and from watching patch review on devel@linuxdriverproject.org, I formed the opinion that patches fixing endian issues need to be tested on hardware before they can be *guaranteed* to be correct.
No patch is *guaranteed* to be correct in my experience :)
Seriously, I don't think there is anything special about endian fixes. Yes, they do add an additional hardware dimension, which often will trigger the missing test hardware problem. But the question about whether testing on hardware is necessary or not is the same as for all other fixes. So is the answer: It depends.
Endian fixes like documenting the hardware registers, and adding conversion to and from the CPU endianness when accessing them, will often be obvious enough to be applicable even without testing.
Bjørn
thanks Bjørn