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;
Date:   Mon, 27 Aug 2018 11:13:11 -0700
From:   Christoph Hellwig <hch@infradead.org>
To:     Guenter Roeck <linux@roeck-us.net>
Cc:     Christoph Hellwig <hch@infradead.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 4.19-rc1
Message-ID: <20180827181311.GA24778@infradead.org>
References: <CA+55aFw9mxNPX6OtOp-aoUMdXSg=gBkQudGGamo__sh_ts_LdQ@mail.gmail.com>
 <20180827134459.GA16094@roeck-us.net>
 <20180827154641.GA17201@infradead.org>
 <20180827171152.GA2705@roeck-us.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180827171152.GA2705@roeck-us.net>
User-Agent: Mutt/1.9.2 (2017-12-15)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.