Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp575230imm; Fri, 11 May 2018 03:06:42 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqV4R0P1ok3E7en1EmgjuLhzd84csuZhV8C1XqD2rC7EZKhaV0d7E1d1+Q66oBXC2W+gv7+ X-Received: by 2002:a63:203:: with SMTP id 3-v6mr3946522pgc.133.1526033202011; Fri, 11 May 2018 03:06:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526033201; cv=none; d=google.com; s=arc-20160816; b=tNP0kqQ29jcXeo56bcfeASBUHaBn7TzxIB5r9cD4f4gBWOSluGV3ZTHAt3BnpTSxq0 V0EVssHb5TAlgNfd1OXcEErwn0XqGc51nQplr4cqrDN8ssnmgxeNANEBBcnrFDqOHnap goBXbVtNm2f2n6NNvoyCyLW9mO9ZbEkpknISLsl5TOAclYL7CcJjdTa917sCahlb3ipP izV/Zr7wHggmyqWaj7nmM/y3e0FPQklYxj7roHC50keFMF7DszmG/qn6Lpx6lcY0J5Jx Eqr4FQCtuZC7XTwQ3Mhkcg2ksN5RHfo5LDBHdFY1mieWbWJhQTfuIpIjtdKFb1IkNJBA KLyQ== 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=y4H3f/sN+Qem4g1iZog63mzVpsZhrU5p9silcGSTbxU=; b=Y/EyQ2UQduS+A8kV2jYI7Jp4WhUhWmRVn/rI32FBNFY4nIaUZ8a3F9xwAOiOu4v3NQ bH0LhR61F4TX6FsPieXo/7FJHu6GRICkEKocHR54iVXDD4pfsf2CDXM9wggsWoFON7G9 3PtLunv/8Z0gPYwzHkxM+9ofC9+29KpbMGtdRA5FYe6bxdZbX040jUd+eHbjE32T5oaW Am4ewzwa/wrEeneqgvJgbVIV9ojn1BR4FPTRU0wuqj9dgzZMjyqWVNTt9dOfi6Mfmd51 cGKERlxS1JsLU5CjlX4pbSYBzUDTi6qdMjQB6yx8KT/RrHmFAO8fLKd7swuV4+GIBtcg yx+Q== 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 h190-v6si2299904pgc.663.2018.05.11.03.06.27; Fri, 11 May 2018 03:06:41 -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 S1752627AbeEKKGR (ORCPT + 99 others); Fri, 11 May 2018 06:06:17 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:45816 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751406AbeEKKGP (ORCPT ); Fri, 11 May 2018 06:06:15 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 8E59122BF3; Fri, 11 May 2018 06:06:09 -0400 (EDT) Date: Fri, 11 May 2018 20:06:06 +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: <8c2c3ad5-eeb5-cf61-b9fb-c6096619e310@gmail.com> Message-ID: References: <0b13a08d-ba2d-b9dc-4fd9-1f6bad5cd1ee@gmail.com> <8c2c3ad5-eeb5-cf61-b9fb-c6096619e310@gmail.com> 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: > > I wasn't proposing to follow platform_device_register() with the mask > assignment, I see. > but rather to use the same strategy from the Coldfire FEC patch > (f61e64310b75): set pdev.dev.coherent_dma_mask and pdev.dev.dma_mask > _before_ calling platform_device_register(). > That patch is attempting to solve the same problem using a different approach, but I'd prefer to keep using platform_device_register_simple(). > > If you want to avoid the overhead of defining the macmace platform > device and using platform_device_register() ... seeing as you would not > be defining just the DMA mask and nothing else, that's probably the > least effort for the MACE and SONIC drivers. > I don't mind the effort. I want to avoid all the boilerplate. > > You would have to be careful not to overwrite a pdev->dev.dma_mask and > pdev->dev.dma_coherent_mask that might have been set in a platform > device passed via platform_device_register here. Coldfire is the only > m68k platform currently using that, but there might be others in future. > That Coldfire patch could be reverted if this is a better solution. > ... But I don't think there are smaller DMA masks used by m68k drivers > that use the platform device mechanism at present. I've only looked at > arch/m68k though. So we're back at the same problem that Geert's suggestion also raised: how to identify potentially affected platform devices and drivers? Maybe we can take a leaf out of Christoph's book, and leave a noisy WARNING splat in the log. void arch_setup_pdev_archdata(struct platform_device *pdev) { WARN_ON_ONCE(pdev->dev.coherent_dma_mask != DMA_MASK_NONE || pdev->dev.dma_mask != NULL); pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask; } --