From: Michael Schmitz <schmitzmic@gmail.com> To: Finn Thain <fthain@telegraphics.com.au> Cc: Geert Uytterhoeven <geert@linux-m68k.org>, "David S. Miller" <davem@davemloft.net>, linux-m68k <linux-m68k@vger.kernel.org>, netdev <netdev@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Christoph Hellwig <hch@lst.de> Subject: Re: [PATCH net] macmace: Set platform device coherent_dma_mask Date: Sat, 12 May 2018 10:02:03 +1200 [thread overview] Message-ID: <23ed7ff8-c1d7-a069-3058-3944c7586116@gmail.com> (raw) In-Reply-To: <alpine.LNX.2.21.1805112003250.8@nippy.intranet> Hi Finn, Am 11.05.2018 um 22:06 schrieb Finn Thain: >> 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. True, but there might be other uses for deviating from a platform default (I'm thinking of Atari SCSI and floppy drivers here). But we could chose the correct mask to set in arch_setup_pdev_archdata() instead, as it's a platform property not a driver property in that case. >> ... 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); I'd suggest using WARN_ON() so we catch all uses on a particular platform. I initially thought it necessary to warn on unset mask here, but I see that would throw up a lot of redundant false positives. Cheers, Michael
WARNING: multiple messages have this Message-ID (diff)
From: Michael Schmitz <schmitzmic@gmail.com> To: Finn Thain <fthain@telegraphics.com.au> Cc: Geert Uytterhoeven <geert@linux-m68k.org>, "David S. Miller" <davem@davemloft.net>, linux-m68k <linux-m68k@lists.linux-m68k.org>, netdev <netdev@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Christoph Hellwig <hch@lst.de> Subject: Re: [PATCH net] macmace: Set platform device coherent_dma_mask Date: Sat, 12 May 2018 10:02:03 +1200 [thread overview] Message-ID: <23ed7ff8-c1d7-a069-3058-3944c7586116@gmail.com> (raw) In-Reply-To: <alpine.LNX.2.21.1805112003250.8@nippy.intranet> Hi Finn, Am 11.05.2018 um 22:06 schrieb Finn Thain: >> 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. True, but there might be other uses for deviating from a platform default (I'm thinking of Atari SCSI and floppy drivers here). But we could chose the correct mask to set in arch_setup_pdev_archdata() instead, as it's a platform property not a driver property in that case. >> ... 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); I'd suggest using WARN_ON() so we catch all uses on a particular platform. I initially thought it necessary to warn on unset mask here, but I see that would throw up a lot of redundant false positives. Cheers, Michael
next prev parent reply other threads:[~2018-05-11 22:02 UTC|newest] Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <S1751632AbeECEYA/20180503042400Z+254@vger.kernel.org> 2018-05-03 7:25 ` [PATCH net] macmace: Set platform device coherent_dma_mask Geert Uytterhoeven 2018-05-03 7:25 ` Geert Uytterhoeven 2018-05-03 8:38 ` Finn Thain 2018-05-03 8:38 ` Finn Thain 2018-05-03 8:46 ` Geert Uytterhoeven 2018-05-03 8:46 ` Geert Uytterhoeven 2018-05-03 8:51 ` Christoph Hellwig 2018-05-03 8:51 ` Christoph Hellwig 2018-05-03 20:24 ` Michael Schmitz 2018-05-03 20:24 ` Michael Schmitz 2018-05-04 7:24 ` Geert Uytterhoeven 2018-05-04 7:24 ` Geert Uytterhoeven 2018-05-04 8:16 ` Michael Schmitz 2018-05-04 8:16 ` Michael Schmitz 2018-05-10 1:25 ` Finn Thain 2018-05-10 1:25 ` Finn Thain 2018-05-10 1:25 ` Finn Thain 2018-05-10 1:25 ` Finn Thain 2018-05-10 20:27 ` Michael Schmitz 2018-05-10 20:27 ` Michael Schmitz 2018-05-10 23:55 ` Finn Thain 2018-05-10 23:55 ` Finn Thain 2018-05-11 2:11 ` Michael Schmitz 2018-05-11 2:11 ` Michael Schmitz 2018-05-11 3:28 ` Finn Thain 2018-05-11 3:28 ` Finn Thain 2018-05-11 4:18 ` Michael Schmitz 2018-05-11 4:18 ` Michael Schmitz 2018-05-11 5:28 ` Finn Thain 2018-05-11 5:28 ` Finn Thain 2018-05-11 9:30 ` Michael Schmitz 2018-05-11 9:30 ` Michael Schmitz 2018-05-11 10:06 ` Finn Thain 2018-05-11 10:06 ` Finn Thain 2018-05-11 22:02 ` Michael Schmitz [this message] 2018-05-11 22:02 ` Michael Schmitz 2018-05-03 4:23 Finn Thain -- strict thread matches above, loose matches on Subject: below -- 2018-05-03 4:23 Finn Thain 2018-05-03 4:23 Finn Thain 2018-05-03 4:23 Finn Thain 2018-05-03 4:23 Finn Thain
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=23ed7ff8-c1d7-a069-3058-3944c7586116@gmail.com \ --to=schmitzmic@gmail.com \ --cc=davem@davemloft.net \ --cc=fthain@telegraphics.com.au \ --cc=geert@linux-m68k.org \ --cc=hch@lst.de \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-m68k@vger.kernel.org \ --cc=netdev@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.