Re: [PATCH 13/21] arc: dma-mapping: skip invalidating before bidirectional DMA
On 4/2/23 08:52, Vineet Gupta wrote: > CC Shahab > > On 3/27/23 17:43, Arnd Bergmann wrote: >> From: Arnd Bergmann >> >> Some architectures that need to invalidate buffers after bidirectional >> DMA because of speculative prefetching only do a simpler writeback >> before that DMA, while architectures that don't need to do the second >> invalidate tend to have a combined writeback+invalidate before the >> DMA. >> >> arc is one of the architectures that does both, which seems unnecessary. >> >> Change it to behave like arm/arm64/xtensa instead, and use just a >> writeback before the DMA when we do the invalidate afterwards. >> >> Signed-off-by: Arnd Bergmann > > Reviewed-by: Vineet Gupta > > Shahab can you give this a spin on hsdk - run glibc testsuite over ssh > and make sure nothing strange happens. > > Thx, > -Vineet Tested-by: Shahab Vahedi No regression was observed for the ARC target before and after applying these 21 patches. The test environment and its summary follow. board: ARC HSDK base: repo: linux-next tag:next-20230403 commit: 31bd35b66249 Add linux-next specific files for 20230403 hotfix: net: stmmac: check fwnode for phy device before scanning for phy [1] glibc: 2.37 Summary of test results: 20 FAIL 4227 PASS 38 UNSUPPORTED 16 XFAIL 2 XPASS [1] https://lore.kernel.org/lkml/20230405093945.3549491-1-michael.wei.hong@intel.com/#r -- Shahab
Re: [PATCH 13/21] arc: dma-mapping: skip invalidating before bidirectional DMA
On 4/2/23 08:52, Vineet Gupta wrote: > CC Shahab > > On 3/27/23 17:43, Arnd Bergmann wrote: >> From: Arnd Bergmann >> >> Some architectures that need to invalidate buffers after bidirectional >> DMA because of speculative prefetching only do a simpler writeback >> before that DMA, while architectures that don't need to do the second >> invalidate tend to have a combined writeback+invalidate before the >> DMA. >> >> arc is one of the architectures that does both, which seems unnecessary. >> >> Change it to behave like arm/arm64/xtensa instead, and use just a >> writeback before the DMA when we do the invalidate afterwards. >> >> Signed-off-by: Arnd Bergmann > > Reviewed-by: Vineet Gupta > > Shahab can you give this a spin on hsdk - run glibc testsuite over ssh and > make sure nothing strange happens. > > Thx, > -Vineet On it. -- Shahab
Re: [PATCH 3/3] memblock: cleanup memblock_free interface
On 9/23/21 9:43 AM, Mike Rapoport wrote: > From: Mike Rapoport > > For ages memblock_free() interface dealt with physical addresses even > despite the existence of memblock_alloc_xx() functions that return a > virtual pointer. > > Introduce memblock_phys_free() for freeing physical ranges and repurpose > memblock_free() to free virtual pointers to make the following pairing > abundantly clear: > > int memblock_phys_free(phys_addr_t base, phys_addr_t size); > phys_addr_t memblock_phys_alloc(phys_addr_t base, phys_addr_t size); > > void *memblock_alloc(phys_addr_t size, phys_addr_t align); > void memblock_free(void *ptr, size_t size); > > Replace intermediate memblock_free_ptr() with memblock_free() and drop > unnecessary aliases memblock_free_early() and memblock_free_early_nid(). > > Suggested-by: Linus Torvalds > Signed-off-by: Mike Rapoport arch/arc part: Reviewed-by: Shahab Vahedi Thanks, Shahab
