netdev - Re: [PATCH] driver:net:stmmac: Disable DMA store and forward mode if platform data force_sf_dma

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJxxZ0O0wH=Y0gXWUGE0zf3p6meB+3Hkh0vwfjYPzHbaFFz8mw@mail.gmail.com>
Date:	Thu, 22 Aug 2013 16:40:24 +0800
From:	Sonic Zhang <sonic.adi@...il.com>
To:	Giuseppe CAVALLARO <peppe.cavallaro@...com>
Cc:	netdev <netdev@...r.kernel.org>,
	adi-buildroot-devel@...ts.sourceforge.net,
	Sonic Zhang <sonic.zhang@...log.com>
Subject: Re: [PATCH] driver:net:stmmac: Disable DMA store and forward mode if
 platform data force_sf_dma_mode is negative.

Hi Peppe,

On Mon, Aug 19, 2013 at 10:29 PM, Giuseppe CAVALLARO
<peppe.cavallaro@...com> wrote:
> On 8/19/2013 12:51 PM, Sonic Zhang wrote:
>>
>> Hi Giuseppe,
>>
>> On Mon, Aug 19, 2013 at 3:45 PM, Giuseppe CAVALLARO
>> <peppe.cavallaro@...com> wrote:
>>>
>>> On 8/19/2013 9:31 AM, Sonic Zhang wrote:
>>>>
>>>>
>>>> Hi Giuseppe,
>>>>
>>>> On Mon, Aug 19, 2013 at 2:03 PM, Giuseppe CAVALLARO
>>>> <peppe.cavallaro@...com> wrote:
>>>>>
>>>>>
>>>>> Hello Sonic
>>>>>
>>>>>
>>>>> On 8/15/2013 9:37 AM, Sonic Zhang wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Sonic Zhang <sonic.zhang@...log.com>
>>>>>>
>>>>>> Some synopsys ip implementation doesn't support DMA store and forward
>>>>>> mode,
>>>>>> such as BF60x. So, define force_sf_dma_mode negative to use DMA
>>>>>> thresholds
>>>>>> only.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I think that you should not pass the force_sf_dma_mode platform field
>>>>> at all (and it doesn't make sense to force it as negative).
>>>>> To use the threshold you should reset tx_coe. In fact, your HW cannot
>>>>> perform the Hw csum if SF is not available.
>>>>> Note that, the HW cap register (if available) can override (set/reset)
>>>>>    tx_coe.
>>>>
>>>>
>>>>
>>>> Even if I reset tx_coe, the SF mode is still set to RX DMA in current
>>>> stmmac_dma_operation_mode(). SF mode is not supported in both RX DMA
>>>> and TX DMA in Blackfin MAC.
>>>
>>>
>>>
>>> yes this is true. the SF is always set for the RX path because I have
>>> never had and known HW w/o RX csum (since the 209).
>>>
>>> So I think the code could be improved to disable/enable the SF also for
>>> the RX path.
>>>
>>>
>>>>>
>>>>> I tested, long time ago, this scenario on old mac w/o HW cap register
>>>>> and w/o SF.
>>>>
>>>>
>>>>
>>>> Blackfin synopsys MAC IP has the HW cap register with tx_coe set to 1,
>>>> but the HW tx_coe doesn't really work. I have the other patch to
>>>> disable HW tx_coe in board file and override the HW cap register.
>>>
>>>
>>>
>>> AFAIK the HW shouldn't be able to perform the csum in HW w/o SF.
>>>
>>> Maybe, an easy way could be to use a new field to force the threshold
>>> mode. This should also remove the csum in HW (IMO) and program the
>>> DMA operation register.
>>>
>>
>> The problem is that HW RX csum works perfectly on Blackfin MAC
>> although the SF mode is not supported in RX DMA.
>
>
> hmm maybe we should ask SYNP. I'll try.
>
>
>> I may need 2 platform
>> fields to force RX DMA threshold and disable HW tx_coe. One field
>> doesn't cover both cases well.
>
>
> concerning tx_coe, I had added it to inform the stmmac that the HW
> was (or not) able to do the csum in hw. This was true on chip w/o
> the HW cap register. If you have the HW cap reg so let me assume
> there is another problem. For example, I worked (time ago) on an HW
> where the cap reg declared that the mac was able to perform the csum
> in hw but, after debugging it, I discovered that the problem was on
> SG. I mean, the HW was able to do the csum in HW but had problems on
> fragmented frame (I mean, frames that were split in one more
> descriptor).
>
> I will send you the patch I used to fix that... maybe you are in the
> same scenario.
>
> Concerning the threshold, just to avoid to complicate the code, we could
> keep force_sf_dma_mode and add force_thresh_dma_mode that force both
> rx and tx. I do not want to remove the force_sf_dma_mode that is also
> used on some platforms (AFAIK).
> Do not forget to update the stmmac.txt and devicetree support
> What do you think?
> I also think that the patch should be prepared on top of net-next.

OK, I will use the new flag and update document and device tree as well.
When can you send me your fragmented frame patch?

Regards,

Sonic
--
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