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
