From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752256AbeEKF3H (ORCPT ); Fri, 11 May 2018 01:29:07 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:41120 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750927AbeEKF3G (ORCPT ); Fri, 11 May 2018 01:29:06 -0400 Date: Fri, 11 May 2018 15:28:58 +1000 (AEST) From: Finn Thain To: Michael Schmitz , Geert Uytterhoeven cc: "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: <0b13a08d-ba2d-b9dc-4fd9-1f6bad5cd1ee@gmail.com> Message-ID: References: <0b13a08d-ba2d-b9dc-4fd9-1f6bad5cd1ee@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 11 May 2018, Michael Schmitz wrote: > > I'm afraid using platform_device_register() (which you already use for > the SCC devices) is the only option handling this on a per-device basis > without touching platform core code, while at the same time keeping the > DMA mask setup out of device drivers I don't think that will fly. If you call platform_device_register() and follow that with a dma mask assignment, you could race with the bus matching and driver probe, and we are back to the same WARNING message. If you want to use platform_device_register(), you'd have to implement arch_setup_pdev_archdata() and use that to set up the dma mask. > (I can see Geert's point there - device driver code might be shared > across implementations of the device on platforms with different DMA > mask requirements,, something the driver can't be expected to know > about). As I said, these drivers might be expected to be portable between Macs and early PowerMacs, but the same dma mask would apply AFAIK. If a platform driver isn't expected to be portable, I think either method is reasonable: arch_setup_pdev_archdata() or the method in the patch. Anyway, there is this in arch/powerpc/kernel/setup-common.c: void arch_setup_pdev_archdata(struct platform_device *pdev) { pdev->archdata.dma_mask = DMA_BIT_MASK(32); pdev->dev.dma_mask = &pdev->archdata.dma_mask; ... I'm inclined to propose something similar for m68k. That should fix the problem, since arch_setup_pdev_archdata() is already in the call chain: platform_device_register_simple() platform_device_register_resndata() platform_device_register_full() platform_device_alloc() arch_setup_pdev_archdata() Thoughts? Will this have nasty side effects for m68k platforms that use smaller dma masks? -- > > Cheers, > > Michael > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Finn Thain Subject: Re: [PATCH net] macmace: Set platform device coherent_dma_mask Date: Fri, 11 May 2018 15:28:58 +1000 (AEST) Message-ID: References: <0b13a08d-ba2d-b9dc-4fd9-1f6bad5cd1ee@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: "David S. Miller" , linux-m68k , netdev , Linux Kernel Mailing List , Christoph Hellwig To: Michael Schmitz , Geert Uytterhoeven Return-path: In-Reply-To: <0b13a08d-ba2d-b9dc-4fd9-1f6bad5cd1ee@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Fri, 11 May 2018, Michael Schmitz wrote: > > I'm afraid using platform_device_register() (which you already use for > the SCC devices) is the only option handling this on a per-device basis > without touching platform core code, while at the same time keeping the > DMA mask setup out of device drivers I don't think that will fly. If you call platform_device_register() and follow that with a dma mask assignment, you could race with the bus matching and driver probe, and we are back to the same WARNING message. If you want to use platform_device_register(), you'd have to implement arch_setup_pdev_archdata() and use that to set up the dma mask. > (I can see Geert's point there - device driver code might be shared > across implementations of the device on platforms with different DMA > mask requirements,, something the driver can't be expected to know > about). As I said, these drivers might be expected to be portable between Macs and early PowerMacs, but the same dma mask would apply AFAIK. If a platform driver isn't expected to be portable, I think either method is reasonable: arch_setup_pdev_archdata() or the method in the patch. Anyway, there is this in arch/powerpc/kernel/setup-common.c: void arch_setup_pdev_archdata(struct platform_device *pdev) { pdev->archdata.dma_mask = DMA_BIT_MASK(32); pdev->dev.dma_mask = &pdev->archdata.dma_mask; ... I'm inclined to propose something similar for m68k. That should fix the problem, since arch_setup_pdev_archdata() is already in the call chain: platform_device_register_simple() platform_device_register_resndata() platform_device_register_full() platform_device_alloc() arch_setup_pdev_archdata() Thoughts? Will this have nasty side effects for m68k platforms that use smaller dma masks? -- > > Cheers, > > Michael >