* endian patches
@ 2017-04-30 23:26 Tobin C. Harding
2017-05-01 5:17 ` valdis.kletnieks at vt.edu
2017-05-01 7:39 ` Bjørn Mork
0 siblings, 2 replies; 4+ messages in thread
From: Tobin C. Harding @ 2017-04-30 23:26 UTC (permalink / raw)
To: kernelnewbies
Should [drivers/staging/*] patches to endian code be tested on hardware
before submission?
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.
Is this opinion well founded?
thanks,
Tobin.
^ permalink raw reply [flat|nested] 4+ messages in thread
* endian patches
2017-04-30 23:26 endian patches Tobin C. Harding
@ 2017-05-01 5:17 ` valdis.kletnieks at vt.edu
2017-05-01 7:39 ` Bjørn Mork
1 sibling, 0 replies; 4+ messages in thread
From: valdis.kletnieks at vt.edu @ 2017-05-01 5:17 UTC (permalink / raw)
To: kernelnewbies
On Mon, 01 May 2017 09:26:40 +1000, "Tobin C. Harding" said:
> Should [drivers/staging/*] patches to endian code be tested on hardware
> before submission?
The first obvious question is: Is the hardware even available for the
opposite endian systems?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170501/4ad21714/attachment.bin
^ permalink raw reply [flat|nested] 4+ messages in thread
* endian patches
2017-04-30 23:26 endian patches Tobin C. Harding
2017-05-01 5:17 ` valdis.kletnieks at vt.edu
@ 2017-05-01 7:39 ` Bjørn Mork
2017-05-01 9:47 ` Tobin C. Harding
1 sibling, 1 reply; 4+ messages in thread
From: Bjørn Mork @ 2017-05-01 7:39 UTC (permalink / raw)
To: kernelnewbies
"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 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* endian patches
2017-05-01 7:39 ` Bjørn Mork
@ 2017-05-01 9:47 ` Tobin C. Harding
0 siblings, 0 replies; 4+ messages in thread
From: Tobin C. Harding @ 2017-05-01 9:47 UTC (permalink / raw)
To: kernelnewbies
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 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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-05-01 9:47 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-04-30 23:26 endian patches Tobin C. Harding
2017-05-01 5:17 ` valdis.kletnieks at vt.edu
2017-05-01 7:39 ` Bjørn Mork
2017-05-01 9:47 ` Tobin C. Harding
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).