linux-kernel - Re: Linux 4.19-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180827181311.GA24778@infradead.org>
Date:   Mon, 27 Aug 2018 11:13:11 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 4.19-rc1

On Mon, Aug 27, 2018 at 10:11:52AM -0700, Guenter Roeck wrote:
> When building sparc32 images, this results in the following
> error.
> 
> drivers/base/platform.c: In function 'setup_pdev_archdata':
> drivers/base/platform.c:235:22: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
>    pdev->dev.dma_mask = &pdev->dma_mask;
> 
> pdev->dev.dma_mask is u64 *, pdev->dma_mask is dma_addr_t which in turn
> is either u32 or u64 depending on the architecture.

Yes, I've fixed this up to be a u64.

> 
> > +++ b/include/linux/platform_device.h
> > @@ -25,6 +25,7 @@ struct platform_device {
> >  	int		id;
> >  	bool		id_auto;
> >  	struct device	dev;
> > +	dma_addr_t	dma_mask;
> 
> ... so this will have to be u64, or the pointer in struct device would
> have to be fixed.
> 
> However, even changing the definition to u64 does not help: The warnings
> are still reported. This is because setup_pdev_archdata() is not called
> for any of the affected devices. That is kind of interesting since it
> means that arch_setup_pdev_archdata() won't be called for those devices
> either.

Yeah, this is odd.  I'll need some more time to figure out where
the platform devices for sbus are allocated.