From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2D920C48BD5 for ; Tue, 25 Jun 2019 12:35:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 107DB213F2 for ; Tue, 25 Jun 2019 12:35:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729760AbfFYMfF (ORCPT ); Tue, 25 Jun 2019 08:35:05 -0400 Received: from verein.lst.de ([213.95.11.211]:34505 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726653AbfFYMfE (ORCPT ); Tue, 25 Jun 2019 08:35:04 -0400 Received: by newverein.lst.de (Postfix, from userid 2407) id 4BA6A68B05; Tue, 25 Jun 2019 14:34:33 +0200 (CEST) Date: Tue, 25 Jun 2019 14:34:33 +0200 From: Christoph Hellwig To: BjoernRiemerriemer@fokus.fraunhofer.de, Matt Porter , Herbert Valerio Riedel Cc: linux-mips@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: DMA API usage in au1000_eth.c Message-ID: <20190625123433.GA4607@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi all, you are the persons that have their names listed in the driver, hope you all remember what you did 15 years ago :) The au1000_eth driver uses the DMA API somewhat oddly. For one it uses the DMA_ATTR_NON_CONSISTENT flag to allocate memory that is not DMA coherent, accompanied by a comment say: /* Allocate the data buffers * Snooping works fine with eth on all au1xxx */ which suggests that it actually is DMA coherent. As far as I can tell many amd mips platforms are DMA coherent, in which case DMA_ATTR_NON_CONSISTENT is no-op and everything is fine here. But it seems some are not, in which case DMA_ATTR_NON_CONSISTENT will give us not coherent memory, in which case something would be broken? Removing DMA_ATTR_NON_CONSISTENT would be no-op on coherent platforms, but return an address in the cache segement on those that are non-coherent. Do you know if the hardware event cares? The next issue is that it calls virt_to_phys on the return value from dma_alloc_attrs. Why would the hardware care about the physical address and not the DMA address (in general those are the same in mips)? Last but not least it stores the kernel address return from dma_alloc_attrs in a u32 instead of a pointer, which is a little odd and not type safe, but not otherwise dramatic. I can prepare a patch to fix these up, but I'd like to confirm my theory about coherent of the platform and device first.