On Mon, 2006-02-20 at 23:31 +0100, Edgar Toernig wrote: > Johannes Stezenbach wrote: > > > > I just re-read the original thread with the patches by Edgar, > > and although requested, he didn't provide a Signed-off-by: > > I've already addressed that and got flamed. I don't want to > start a discussion about that on the list. So once again to > make my (non-negotiable) position clear: I will not add a > 'Signed-off-by'. I think most people here knew that. The only ones not following this must have been Uwe. > > If the committer wants to track patch history he can put me in > as the author or add a 'Submitted-by'. If he thinks he cannot > sign off himself without someone else signing first I can only > say "Welcome to the Club". Do you by this mean to say that you did not write the code in the first place, and that's why you don't put the signed-of-by? If not, what guarantees do we have that this code is "clean"? > > > > One of the patches also sparked some discussion which > > was left unresolved... > > Well, it's hard to discuss something if the other side does not > know the hardware/driver. Put a side for a moment who knows what. There was a misunderstanding on the list reguarding what these patches did. I've tried the patches and they do what they claim (allthough not perfectly, they do improve the situation). While trying to find the cause of some problems I have with another bt878 based dvb card I have done some experimental changes here and there to my local tree (not applying these patches for reasons mentioned above) and found my self reimplementing large portions of these patches, in particular the error reporing changes(that were the center of the controversy). Allthough these changes were developed indepenantly I have seen the patches in question so that leaves the question whether my patches are any better (from a legal point of view). Any feedback is welcome on this. > > It came down to: That's more than the 'obviously correct two line > diff' so it's better to not apply it so it won't break stuff. All btxxx code as of current is a minefield, you know that as well as me. Any change might break something one never would have anticipated, so great care is needed. It should however not be enough to reject these patches. So to some technical questions, if you care to comment: The issue these patches were supposed to fix were (iirc) lots of FDSR errors with some particular card? And this was done by reducing the fifo trigger point, thus ruducing the odds of having a fifo overflow if the card did not get access to the pci bus on time? However according to my interpretation of the bt878 manual a fifo overrun condition is signaled by a FBUS error, and not FDSR. The exact reasons for getting a FDSR error (unless by having a buggy risc program) is unclear to me. However, after enabling all kinds of error reporting I've seen both types of errors. FDSR errors comes one at a time, while FBUS errors seems to happen much more seldom, but when they happen I get _a lot_ of errors in the logs. It seems also that changing the trigger point does reduce the interval of the FDSR errors, but still doesn't remove them alltogether. I hope I might have helped turning this discussion over on the constructive side by these remarks. Regards Sigmund _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
