[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20151215.132650.1190111989349535666.davem@davemloft.net>
Date: Tue, 15 Dec 2015 13:26:50 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: sergei.shtylyov@...entembedded.com
Cc: netdev@...r.kernel.org, linux-sh@...r.kernel.org
Subject: Re: [PATCH] sh_eth: fix descriptor access endianness
From: Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
Date: Tue, 15 Dec 2015 21:06:16 +0300
> On 12/15/2015 08:53 PM, David Miller wrote:
>
>>>>> The driver never calls cpu_to_edmac() when writing the descriptor
>>>>> address
>>>>> and edmac_to_cpu() when reading it, although it should -- fix this.
>>>>>
>>>>> Note that the frame/buffer length descriptor field accesses also need
>>>>> fixing
>>>>> but since they are both 16-bit we can't use
>>>>> {cpu|edmac}_to_{edmac|cpu}()...
>>>>>
>>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
>>>>
>>>> Applied.
>>>
>>> I was going to rework this to fix _all_ cases, and sent follow-up
>>> email about that yesterday... Haven't you received it?
>>
>> I saw it but you were not entirely clear whether you were going to do
>> that work in a follow-on patch or not.
>>
>> If you don't clearly say "Dave, please drop this patch." expect me to
>> do random things.
>
> Previously I had a plan to get rid of never used EDMAC_BIG_ENDIAN and
> then get rid of {edmac|cpu}_to_{cpu|edmac}() and fix 16-bit descriptor
> R/W by using {cpu|le32}_to_{le32|cpu}(). How's that plan to you?
I personally don't care what work you do on this driver.
All I care about is that people communicate clearly with me when they
want me to take, or not take, a given patch.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists