On Tue, Jul 19, 2011 at 12:46 AM, Gadiyar, Anand <gadi...@ti.com> wrote:
> Pandita, Vikram wrote:
>> On Mon, Jul 18, 2011 at 11:22 PM, Gadiyar, Anand <gadi...@ti.com> wrote:
<snip>
> But you can't just change authorship when the entire functional code
> is the same. (It doesn't matter much to me - I'm not as active on
> MUSB as I used to be; it's just the principle of the thing).

Moiz fixed the second part of your patch - which was not there on your
original work:

<snip>
+                                       if (use_mode_1) {
+                                               transfer_size =
min(request->length - request->actual,
+
channel->max_len);
                                               musb_ep->dma->desired_mode = 1;
+                                       } else {
+                                               transfer_size =
min(request->length - request->actual,
+                                                               (unsigned)len);
+
musb_ep->dma->desired_mode = 0;+
if (use_mode_1) {
+                                               transfer_size =
min(request->length - request->actual,
+
channel->max_len);
                                               musb_ep->dma->desired_mode = 1;
+                                       } else {
+                                               transfer_size =
min(request->length - request->actual,
+                                                               (unsigned)len);
+                                               musb_ep->dma->desired_mode = 0;
<snip end>

The history is:

Original author on .35 or .32 kernel : Anand Gadiyar
Fixes done by and some more forward ports: Moiz Sonasath
Tested on 3.0 and code cleanups, commit message updates, community
comment fixes: Vikram Pandita

Wonder if original author did not act all this while, is there
anything wrong in changing authorship with proper accreditation to
original author?
For future pushes, i would really like to learn what the linux
community suggests the right approach for such cases.

As i said, i am open to change and will repost as decided - there is
no attempt to sabotage anyone's work here :-)


>
>> We have been carrying this optimisation around in product kernels for
>> a long time now and we keep redoing on each migration,
>> with the downside of sometimes loosing the authorship.
>>
>> > (and if I remember correctly several
>> > attempts to get this merged upstream)? I don't see any
>> > functional changes from my original patch.
>>
>> Wonder what were the reasons for not getting accepted?
>> Can you re-ignite the discussion why it cannot be taken in then?
>
> You've already re-ignited this discussion. I haven't tested the patch
> with the current kernel (and will do so soon), but if it does still
> work and there are no objections, it ought to be merged.
>
> - Anand
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to