[Top] [All Lists]

Regarding commit a16dad7 [MIPS: Fix potencial corruption]

To: Ralf Baechle <>
Subject: Regarding commit a16dad7 [MIPS: Fix potencial corruption]
From: Shmulik Ladkani <>
Date: Tue, 1 Jan 2013 11:23:40 +0200
Cc:, Kevin Cernekee <>, Shmulik Ladkani <>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:date:from:to:cc:subject:message-id:mime-version :content-type:content-transfer-encoding; bh=KResWqwBYFV8OI+rN34d2Zyu16NSfjuhNhpYdMfilOc=; b=Z5VorQUmyend4B2yYshIFaJrtuVikHkVyi/7PTE+v1jxPdpz547uIQx/tr1AUAYFZQ Bm0+uoYlB1cX9l5HKWzIroRrs20Bq6sCigF48wUY27kAZC7CvINUHIAt5MYYjGSaOnTd 0OhB8C04hUDr8tPYpiWIhyCFV0YnKalGMpbB53cO61WPrYaUbeNuUs7odJ59d8DziF6m YxLu/Yt52e/Nzypp06RPEZDLpnTWORKLcxMSTAwG4wM3esa47k+Gi9pAEzNZpqPhgmAd X5HfGe76vf1Hsn8ZGW6B3Jum2s+Al6+t2mIyERnyBG9cWhtQ2XPHexWjikoEjx5ySoap +EQg==
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>

Commit a16dad77 (MIPS: Fix potencial corruption) seems as a revert
of a8ca8b64 (MIPS: Avoid destructive invalidation on partial cachelines).

Snip of a16dad77:

@@ -643,9 +640,6 @@ static void r4k_dma_cache_inv(unsigned long addr, unsigned 
long size)
                         * hit ops with insufficient alignment.  Solved by
                         * aligning the address to cache line size.
-                       cache_op(Hit_Writeback_Inv_SD, addr & almask);
-                       cache_op(Hit_Writeback_Inv_SD,
-                                (addr + size - 1) & almask);


The comment above the removed 'cache_op' instructions, which was
originally added as part of a8ca8b64, was not reverted, and now looks

Any reason to keep the comment? If not, I'll submit a patch removing it.

Following a8ca8b64, another commit was submitted, adding similar
'cache_op' instructions to 'mips_sc_inv' - namely 96983ffe
(MIPS: MIPSxx SC: Avoid destructive invalidation on partial L2 cachelines).

Its purpose was to extend a8ca8b64, aligning behavior of 'mips_sc_inv'
to be similar to 'r4k_dma_cache_inv'.

Since the explicit 'cache_op' instrcutions are now removed from
'r4k_dma_cache_inv' (as of a16dad77), it probably makes sense to remove
them from 'mips_sc_inv' as well.

Any reason to keep these 'cache_op's? If not, I'll submit a patch.


<Prev in Thread] Current Thread [Next in Thread>