Received: by 10.192.165.148 with SMTP id m20csp555561imm; Wed, 9 May 2018 18:27:22 -0700 (PDT) X-Google-Smtp-Source: AB8JxZppfP2ax91ZtC8BrfZR+XXKaUNEhhQTS5kB45i9R6FdjvbhRp2j1SJv0JI88SN+Rscnx3jJ X-Received: by 10.98.65.93 with SMTP id o90mr46308356pfa.140.1525915642333; Wed, 09 May 2018 18:27:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525915642; cv=none; d=google.com; s=arc-20160816; b=HR76SqY+zPQDVs2+Gh1+k/dAajkGJcht1GsiM6ovDWW9Vxfsq644NQ3ZPSbAEg7LT9 jNPSPGBPyWiXPD8tlqgZU3VYwblLOqQrQ7qBdJbttUcO9NvUoQrm7m1HOxNw7IO5aj7E T0tb/s7tKOJpjel3Pod5QMQXECTjkJKEzPvgrTzOJIWrHuGFUPwdv95V4DqTrGbqLJ/u miQaNWPqH4o7zDpP+JAxahb0N46FcZT7FiJYSgNR4byTrsWtL8cErnDmgHjPe1MtIqPQ BgmQX//ltJfDhoS4I9Tjf3DlAHv/Kck/LJTFK2laPs4QZfztaJHgdFyD7Mp0uHyW9VPQ BiHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:message-id :in-reply-to:subject:cc:to:from:date:arc-authentication-results; bh=xef3KhZzsXW1MLH5AwU5QjvkXy6htd8AimrHBXMAalE=; b=S5K3JwD3hTc8wiKF0H4wrUnUddS7AxZFkmufg4aUqPubhNXe6tVAZG4xHXqr0kx5i5 qXkc6n9cURexPlwpnu4TjmTEAufwfnpZCFhFuHo8XLZmbS9Tc6NVi6eR+KK6N4AjDvxd jacfhvTbuJoSYi2nQ7lUwIIQHNKyPb6H8RR2f0bzhi6lY8pRtNfvCZAgEyOoY8kYlU88 zzKmRe2PSmYxMYPe33g92/xA4tBhnDylxjqecgq455J59cBGkECx7W3cKMwVk2vNlET2 P4ar3Fh3EXf1243Yu5UeU5inbLRlrPHkkrPHIyN53Zp42vwIIo9jiNCb8aXtnUNvs9F8 rlPg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z7-v6si15565675pgv.614.2018.05.09.18.27.07; Wed, 09 May 2018 18:27:22 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756325AbeEJBZ0 (ORCPT + 99 others); Wed, 9 May 2018 21:25:26 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:58130 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751803AbeEJBZZ (ORCPT ); Wed, 9 May 2018 21:25:25 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id CE1A922BF3; Wed, 9 May 2018 21:25:11 -0400 (EDT) Date: Thu, 10 May 2018 11:25:09 +1000 (AEST) From: Finn Thain To: Christoph Hellwig cc: Geert Uytterhoeven , "David S. Miller" , linux-m68k , netdev , Linux Kernel Mailing List Subject: Re: [PATCH net] macmace: Set platform device coherent_dma_mask In-Reply-To: <20180503085120.GA14574@lst.de> Message-ID: References: <20180503085120.GA14574@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 3 May 2018, Christoph Hellwig wrote: > On Thu, May 03, 2018 at 10:46:56AM +0200, Geert Uytterhoeven wrote: > > Perhaps you can add a new helper > > (platform_device_register_simple_dma()?) that takes the DMA mask, too? > > With people setting the mask to kill the WARNING splat, this may > > become more common. > > > > struct platform_device_info already has a dma_mask field, but > > platform_device_register_resndata() explicitly sets it to zero. > > Yes, that would be useful. The other assumption could be that platform > devices always allow an all-0xff dma mask. Could that have unintended side effects? The mask is presently unset by default, and my worry would be that changing it may cause some drivers to behave differently. A quick grep turns up this in drivers/spi/spi-au1550.c for example, if (pdev->dev.dma_mask == NULL) dev_warn(&pdev->dev, "no dma mask\n"); else hw->usedma = 1; Also, if pdev.dev.dma_mask is to get a default value, shouldn't it use the same default as dma_get_mask, to avoid unintended side effects? static inline u64 dma_get_mask(struct device *dev) { if (dev && dev->dma_mask && *dev->dma_mask) return *dev->dma_mask; return DMA_BIT_MASK(32); } --