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]

Date:   Mon, 27 Aug 2018 12:32:15 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     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 11:13:11AM -0700, Christoph Hellwig wrote:
> 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.

I think it is scan_one_device() in arch/sparc/kernel/of_device_32.c
and arch/sparc/kernel/of_device_64.c.

Guenter