netdev - Re: [PATCH 1/2] net: fec: use dma_alloc

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: <8a4ba165-69ec-9c0a-8fc8-b41fd965290b@linux-m68k.org>
Date:   Tue, 6 Dec 2022 00:09:10 +1000
From:   Greg Ungerer <gerg@...ux-m68k.org>
To:     Christoph Hellwig <hch@....de>
Cc:     Joakim Zhang <qiangqing.zhang@....com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        linux-m68k@...ts.linux-m68k.org, uclinux-dev@...inux.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] net: fec: use dma_alloc_noncoherent for m532x


On 2/12/22 17:02, Christoph Hellwig wrote:
> On Thu, Dec 01, 2022 at 03:41:34PM +1000, Greg Ungerer wrote:
>>>      #ifdef CONFIG_M532x
>>> +	/*
>>> +	 * Hacky flush of all caches instead of using the DMA API for the TSO
>>> +	 * headers.
>>> +	 */
>>>    	flush_cache_all();
>>
>> Even with this corrected this will now end up failing on all other ColdFire types
>> with the FEC hardware module (all the non-M532x types) once the arch_dma_alloc()
>> returns NULL.
>>
>> Did you mean "ifndef CONFIG_COLDFIRE" here?
> 
> How did these work before given that the cache flush is conditional
> on CONFIG_M532x?

The case for the 5272 is that it only has instruction cache, no data cache.
That was the first supported part, and the one I have used the most over
the years (though not so much recently). So it should be ok.

I am not convinced about the other version 2 cores either. They all have
both instruction and data cache - they can be flexibily configured to be
all instruction, or a mix of instruction and data - but the default is
both.

I don't have a 532x platform, so I have never done any work on that.
The flush_cache_all() for that seems dubious to me.


>>> +#else
>>> +		/* m68knommu manually flushes all caches in fec_enet_rx_queue */
>>> +		txq->tso_hdrs = dma_alloc_noncoherent(&fep->pdev->dev,
>>> +					txq->bd.ring_size * TSO_HEADER_SIZE,
>>> +					&txq->tso_hdrs_dma, DMA_BIDIRECTIONAL,
>>> +					GFP_KERNEL);
>>> +#endif
>>>    		if (!txq->tso_hdrs) {
>>>    			ret = -ENOMEM;
>>>    			goto alloc_failed;
>>
>> And what about the dmam_alloc_coherent() call in fec_enet_init()?
>> Does that need changing too?
> 
> If that's actually use by the FEC implementations on coldire: yes.

It is. Testing these changes failed at boot without changing this one too.


> But maybe I need even more help on how the cache flushing is suppoѕed
> to actually work here.

Regards
Greg