endian patches

[Tobin C. Harding]

On Mon, May 01, 2017 at 09:39:23AM +0200, Bjørn Mork wrote:
> "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

thanks Bjørn