Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp126381imm; Thu, 10 May 2018 16:56:10 -0700 (PDT) X-Google-Smtp-Source: AB8JxZofXreSrWbf5ug9Kh2MXnytE4p7idUxeUFEgZkgDSjabhMx86Jv3n6ag5DruxSnmQMQSTQd X-Received: by 2002:a65:5cc6:: with SMTP id b6-v6mr2558997pgt.84.1525996570391; Thu, 10 May 2018 16:56:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525996570; cv=none; d=google.com; s=arc-20160816; b=0K3pGlMVQGBHbQNSaQXOjGBYGy/m3kN5XUqrKlSQ+de4OGKjwZ9X11gdTTcUJLVVAo O0cGzB4l2DHoKfRz82JXORlS+KB/15+VlLce6b/Mq9xZOqGMmE3/MNCERkb/P0fpBK5S 76Yo3epLHA9Mr9+QAb1J+rEp0RPNSpgG1KhZrQDbBQtUvrs36L2yFGZuqhcPaW4cIh1W NlWSLFGdvQEkdRiYpayB25ntpt8BsCasttUUFajbSBA7eG2jQXOfJOFquzKF0IxgvGak KqoP69Arjb6qD91G4XuxhyUI7CSGdP9HepLkBwQE+HA2JlRQg+f+IuMUFf4hL9knGsOV fktw== 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=WlyqWcW1BgYekYDuiGGvjZsXTrmSrNaP0DqTAp72kNo=; b=c2NGi79mKk6Y6vQD6QmbKUMsb/cfkxlTqmqOer7qBOMky/58EPMgDGa/TRrFfM7Vd1 4neBOFQSfle0rFXcNGk4D4ZDVFOuVInHBc1N/F79dv5SOjpGLV+UxWhkXYH2HVbBqKK/ 25VEU+wjqtryoE3v/EUtGDd5iK+3CmFEcZ55d97/r7Aa5rzSsYm1iFIJzMYmcIre6g62 F8ow/HA4kDBOrQUtIpOeXuk/lCnZPu+q4YkEOTyMA6eW7OhXipdeOFtYIKj87YPz96/E w4290z8gxRJuUv3052oIz5rqXWUucmq0Mg0GBe8BoWDgfUPqBu3n4VS74m2+8AYWFvMQ HaFg== 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 q2-v6si1506497pgc.567.2018.05.10.16.55.56; Thu, 10 May 2018 16:56:10 -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 S1751649AbeEJXzN (ORCPT + 99 others); Thu, 10 May 2018 19:55:13 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:57866 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751370AbeEJXzK (ORCPT ); Thu, 10 May 2018 19:55:10 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 137BB22C16; Thu, 10 May 2018 19:55:06 -0400 (EDT) Date: Fri, 11 May 2018 09:55:04 +1000 (AEST) From: Finn Thain To: Michael Schmitz cc: Geert Uytterhoeven , "David S. Miller" , linux-m68k , netdev , Linux Kernel Mailing List , Christoph Hellwig Subject: Re: [PATCH net] macmace: Set platform device coherent_dma_mask In-Reply-To: Message-ID: References: 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 Fri, 11 May 2018, Michael Schmitz wrote: > > > Perhaps you can add a new helper > > > (platform_device_register_simple_dma()?) that takes the DMA mask, > > > too? ... > > > > So far, it looks like macmace and macsonic would be the only callers > > of this new API call. > > > > What's worse, if you do pass a dma_mask in struct > > platform_device_info, you end up with this problem in > > platform_device_register_full(): > > > > if (pdevinfo->dma_mask) { > > /* > > * This memory isn't freed when the device is put, > > * I don't have a nice idea for that though. Conceptually > > * dma_mask in struct device should not be a pointer. > > * See http://thread.gmane.org/gmane.linux.kernel.pci/9081 > > */ > > pdev->dev.dma_mask = > > kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL); > > Maybe platform_device_register_full() should rather check whether > dev.coherent_dma_mask is set, and make dev.dma_mask point to that? This > is how we solved the warning issue for the Zorro bus devices... > (8614f1b58bd0e920a5859464a500b93152c5f8b1) > The claim in the comment above that a pointer is the wrong solution suggests that your proposal won't get far. Also, your proposal doesn't address the other issues I raised: a new platform_device_register_simple_dma() API would only have two callers, and the dma mask setup for device-tree probed platform devices is apparently a work-in-progress (which I don't want to churn up). > > > With people setting the mask to kill the WARNING splat, this may > > > become more common. > > > > Since the commit which introduced the WARNING, only commits f61e64310b75 > > ("m68k: set dma and coherent masks for platform FEC ethernets") and > > 7bcfab202ca7 ("powerpc/macio: set a proper dma_coherent_mask") seem to be > > aimed at squelching that WARNING. > > > > (Am I missing any others?) > > Zorro devices :-) Right, I should add commit 55496d3fe2ac ("zorro: Set up z->dev.dma_mask for the DMA API") to that list. > Which begs the question: why can' you set up all Nubus bus devices' DMA > masks in nubus_device_register(), or nubus_add_board()? I am expecting to see the same WARNING from the nubus sonic driver but it hasn't happened yet, so I don't have a patch for it yet. In anycase, the nubus fix would be a lot like the zorro bus fix, so I don't see a problem. --