Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1129775imm; Sat, 26 May 2018 22:23:59 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr8WyJa1RLLe2GPZyOz8sd7E8IoDkloX9VJUQ8WuJTCwAj59NdqMQLJz8Qek8g72qgQa/Zh X-Received: by 2002:a63:87c8:: with SMTP id i191-v6mr6867074pge.124.1527398639092; Sat, 26 May 2018 22:23:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527398639; cv=none; d=google.com; s=arc-20160816; b=AtPJyc38kXcxoFMO0eerRmW8YaCsA12iUrdjykgtukXPjDcANOPaO0CRQUf0+oZltk 8+qMvdPyq8iXWvhX7RYmCzhnhPBEpFmIivFpXTDca599hhqRUVV2afYRKlTMB7Zig6Q8 TbwbyaRpTtEJXK/41GNKXuh56j/SDy/Ob97DzKBmm/OTHX/shviC4M3tJKs3fIQ2hKBK MO/LNl6ABrlg70zrdxvdbROAk4zpPCotN/Ve8fhtgVgh/chnHKykjxw8Wkk3QTLoVzE7 naeZAQ5yUBEeRxDfE1/YbwDkYU5sN5Vabv2wmcpsJynrzgVYaEKvhRsjnazx41XlG9Fy FRyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:dkim-signature:arc-authentication-results; bh=65/rd/irK/Il7N5z0vNcWxb0CS3Fv+3UtzdO0vVqOXM=; b=uKxf7fQLLlBwnOBKfmsyjiE1ef1UUx5WsmcIOBycwh3dX2FwEgGX3SjslpBhSQDR0/ ZlbfZsuLQmNxSqvjt/0kWeEpeIc0CFTZVXsaqKLxxqJmhrEIykleb1CbqrvLO921dIaO 8uybnSN4raCMMy+3FUnQPDNdZg7UO8LHTu/1Rx+htGUKPaLf0RAsgrJH15mn3vAgsXMs Yzn46tYX1mhI54+7Kb70ZGn27yOZjcWclnvg12g/Zq1Z4umVOYm/aspalJRe4yqDxgGs UeM8iod0cfbzTgrgDlftn6ec2fWFqy7NnbGFvYY0FyYmCHfkoua1w/nWs1sTCzaAm90N 4/Rw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PcuiRDHP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f85-v6si27339613pfj.125.2018.05.26.22.23.04; Sat, 26 May 2018 22:23:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PcuiRDHP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755181AbeE0FWy (ORCPT + 99 others); Sun, 27 May 2018 01:22:54 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:43868 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755119AbeE0FWv (ORCPT ); Sun, 27 May 2018 01:22:51 -0400 Received: by mail-pf0-f193.google.com with SMTP id j20-v6so4359551pff.10 for ; Sat, 26 May 2018 22:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=65/rd/irK/Il7N5z0vNcWxb0CS3Fv+3UtzdO0vVqOXM=; b=PcuiRDHPzMQa/UBfsxU67nyOowdiIk4+ajYLHYZDdL73fEjGPOOmDBjYOS67NsGtww XbvIMYApQFERn1LFEmGjXqet5jkO2yr9er8li9jvWmbcTjrpDHD1L3Jj7/jAfHQG0A7S SWpicBHkGOMGncF6jzlSk3GEeQ9fHL4Fo9Ikwvh8kjID0y5xv9u0Pm7vl5yVU7VD5atX iB4cM+LKUuChu9BqW5ghC9M2RVR2feYxU/TGvK5pobCjFEZxvXrjRpwAf7q1AxrSlWib ZOpyYdPSnOSZeAGAcB1iWYLXBtEkWIQzR9KcoHRi5yt0BeBNRJFCUyPWzNPtULAJtVc0 VsDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=65/rd/irK/Il7N5z0vNcWxb0CS3Fv+3UtzdO0vVqOXM=; b=hrzaCyBqO8pa5Dy21X6RLQ7IL0seM7BvumaTnicu+BJb1OZtZ4O4Au8rGp9jWsSXCN cjo3icXc1Qz+JbV6lUIO1qBLWXhhRpZ9RQwSgt6YTbXdvRTEjmzCxVWaVRnYOkyb11Q8 YOMarh07MZ0pnWJ/jAjMshtdGPUMe2SOLoj81/BT5UOAYvplCHFTen2qiTdkoM4hUBBF F+XQmAN8P3UVoEmwEhnBztEhXLks9VTgEGnsAbhDBpupamYx3ifXAdNPiWE7SRcR9Vfl 9hE4HKmRhMa/w1oVRPEDIKKrPQ1+HsnTjqyMniiJxkDEz1ftY/rc+KK+1b7GsTfCANIT aLFg== X-Gm-Message-State: ALKqPwfrwnivwYmX+93KkWGjsI7kiPNigxbEHZwvPJu3sXsXm+2nfNCg dNZf40clRF/98Do+iRL0fjsihw== X-Received: by 2002:a62:4a88:: with SMTP id c8-v6mr8686316pfj.23.1527398570889; Sat, 26 May 2018 22:22:50 -0700 (PDT) Received: from [192.168.1.101] (222-154-41-72-adsl.bb.spark.co.nz. [222.154.41.72]) by smtp.gmail.com with ESMTPSA id 185-v6sm49055792pfu.13.2018.05.26.22.22.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 May 2018 22:22:50 -0700 (PDT) Subject: Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet To: Finn Thain , Guenter Roeck References: <1527378785-13326-1-git-send-email-linux@roeck-us.net> Cc: Joshua Thompson , Greg Ungerer , Geert Uytterhoeven , linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org From: Michael Schmitz X-Enigmail-Draft-Status: N1110 Message-ID: <55c1c33b-4a34-bd72-57de-577ce8d95e0b@gmail.com> Date: Sun, 27 May 2018 17:22:42 +1200 User-Agent: Mozilla/5.0 (X11; Linux ppc; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Finn, was your patch to implement this in arch_setup_pdev_archdata() rejected? That should have fixed the warning already ... Am 27.05.2018 um 15:01 schrieb Finn Thain: > On Sat, 26 May 2018, Guenter Roeck wrote: > >> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no >> coherent_dma_mask") the NatSemi SONIC Ethernet driver is issuing the >> following warning on driver initialization on Macintosh q800 systems. >> >> SONIC ethernet @50f0a000, MAC 08:00:07:12:34:56, IRQ 3 >> ------------[ cut here ]------------ >> WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 macsonic_init+0x6a/0x15a >> Modules linked in: >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.17.0-rc6-mac-00286-g527f47c #1 >> Stack from 0781fdd8: >> 0781fdd8 003615b3 000181ba 000005c4 07a24cbc 00000000 00000000 000020e8 >> 07a24800 002c196c 0001824e 00334c06 00000204 001f782a 00000009 00000000 >> 00000000 003358d9 001f782a 00334c06 00000204 00000003 00000000 07a24800 >> 002b5cb6 000372ec 001f8b1a 07a24800 00359203 50f0a000 07a14a48 00000003 >> 00000000 07845c0a 0039dcca 003c835c 003c835c 0035b924 001c19de 07845c00 >> 07845c0a 0039dcca 001c06dc 07845c0a 0781fed8 00000007 0054d040 07845c0a >> Call Trace: [<000181ba>] __warn+0xc0/0xc2 >> [<000020e8>] do_one_initcall+0x0/0x140 >> [<0001824e>] warn_slowpath_null+0x26/0x2c >> [<001f782a>] macsonic_init+0x6a/0x15a >> [<001f782a>] macsonic_init+0x6a/0x15a >> [<002b5cb6>] memcmp+0x0/0x2a >> [<000372ec>] printk+0x0/0x18 >> [<001f8b1a>] mac_sonic_platform_probe+0x380/0x404 >> >> As per the warning the coherent_dma_mask is not set on this device. >> There is nothing special about the DMA memory coherency on this hardware >> so we can just set the mask to 32bits in the platform data for the FEC >> ethernet devices. >> >> Signed-off-by: Guenter Roeck > > Acked-by: Finn Thain > > Geert, assuming that Guenter's patch is acceptable, would you also accept > a similar patch for the "macmace" platform device? > >> --- >> Modeled after f61e64310b75 ("m68k: set dma and coherent masks for platform >> FEC ethernets"). >> >> RFC: Is "nothing special about the DMA memory coherency" correect ? >> > > As I understand it, "cache-coherence" is meaningless unless you have > multiple CPU cores and caches. If there's only one CPU core, its cache > can't be said to be "coherent" or "non-coherent". Moreover, DMA (direct > memory access) concerns an IO device and a memory, not a cache, so the > term "coherent dma" is bogus IMHO. DMA does concern the CPU cache insofar as (without explicit cache maintenance) the CPU cache may hold stale data after a DMA write, or data to be used in a DMA read may not have been written back from cache to memory. As far as I understand it, the generic DMA API does handle these cache maintenance aspects without a need for action at the driver level. But you're correct that the question of coherent memory does not arise on uniprocessor systems, so the whole warning could have been avoided. Unless 'coherent memory' in this context means no explicit cache maintenance is required (CPU does bus snooping - which of our platforms fully support that)? Cheers, Michael