endian patches

[Bjørn Mork]

"Tobin C. Harding" <me at 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 at 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