Mike Isely wrote:
> On Fri, 21 May 2010, Mauro Carvalho Chehab wrote:
>
>> Mike Isely wrote:
>>> Mauro:
>>>
>>> You are reading too much into that comment.
>>>
>>> I never said it was valid to do what had been done, only that for the
>>> longest time this is what the driver did and it never caused a problem
>>> that I was made aware of. What I said there was correct, that this is
>>> what the driver had been doing in the past, that it's definitely causing
>>> a problem now and thus that is why this patch exists.
>> As I said, this is not right:
>> "Apparently later kernels don't like this behavior"
>
> Mauro:
>
> That statement was in reference to the fact that previously the problem
> had gone undetected, but now later kernels can notice and complain about
> this, thus "later kernels don't like this behavior".
>
> We can debate that perhaps the statement can be worded better, but that
> doesn't make it *wrong*.
>
Calling 2.6.12 kernel as "later kernels" doesn't seem right to me (that was
about the kernel were em28xx driver were introduced).
>
>> It is not "later kernels". DMA over stack were never supported. Your driver
>> had a bug that you didn't noticed for long time, probably because nobody
>> reported you this issue, since it appears only on some non-Intel archs and
>> on i386 with more than 3.12 Gb of RAM, and when the stack happens to be after
>> the first 3.12 Gb (with is a somewhat rare condition).
>
> I understand your point perfectly that this was never right or valid.
> In fact, I also understood that point long before you decided to explain
> it to me here - after all my realization of this problem in the driver
> is why I wrote the patch in the first place. Absolutely no argument
> there about the importance of the change.
>
> None of that however justifies putting words into an author's mouth,
> which is effectively what you did by replacing that commit comment.
>
First of all, it is clearly stated at the patch that the description
were changed and by whom:
[[email protected]: fix patch description]
Second, it is an usual upstream practice to fix descriptions where needed.
The patch description is a precious resource for people that are seeking
for similar bugs, and for those that are trying to understand some code.
So, it is important to not send broken/incomplete comments to kernel,
or comments that may have a dubious interpretation. So, subsystem maintainers
frequently need to fix comments.
Anyway, to end this discussion, I can simply revert the patch from the
staging tree, waiting for a new patch from you with a fixed comment.
Also, if you prefer, next time, I won't apply any patch from you if I
found a bad comment without your ack, even if it means that you'll
probably loose a merge window.
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
