linux-kernel - Re: linux cache routines for Write-back cache policy on MIPS24KE

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071003105751.GD29244@linux-mips.org>
Date:	Wed, 3 Oct 2007 11:57:51 +0100
From:	Ralf Baechle <ralf@...ux-mips.org>
To:	veerasena reddy <veerasena_b@...oo.co.in>
Cc:	linux-mips <linux-mips@...ux-mips.org>,
	"linux-kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: linux cache routines for Write-back cache policy on  MIPS24KE

On Mon, Oct 01, 2007 at 01:10:59PM +0100, veerasena reddy wrote:

> Is there any problem if we use the below API's in
> linxu-2.6.18 
>   - dma_cache_wback_inv()
>   - dma_cache_wback()
>   - dma_cache_inv()
> 
> functionality wise, especially in r4k.c i dont see any
> difference between the implementation of these APIs.
> 
> Can we apply the 2.6.24 patch to kill these APIs on
> 2.6.18 kernel? In this case what APIs i can use for
> writeback, invalidation or both?
> 
> I couldn't find any info. related to the above API in
> DMA-API.txt. Could you please give some pointers on
> the usage/working of these APIs.

dma_cache_* were never documented.  They respresent the earliest attempt
at coming up with an API that enables portable drivers and it has a few
shortcomings and like so many early things it was never formally documented,
so don't expect any well defined semantics.  The functions never got
formally retired probably because it somehow managed to stay under the
radar.

Any drivers should use the APIs documented in Documentation/DMA-API.txt
only.  The almost equivalent operation for dma_cache_* would be
dma_sync_single and dma_sync_sg.

Don't even dream about using dma_cache_* for anything but DMA coherency.
They're all internal low level APIs which know nothing about Linux's
virtual memory system.

Anyway, it would be much easier to help you if we knew what you are trying
to achieve with these functions.

  Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/