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 12:32:15 -0700
From:   Guenter Roeck <linux@roeck-us.net>
To:     Christoph Hellwig <hch@infradead.org>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 4.19-rc1
Message-ID: <20180827193215.GA18363@roeck-us.net>
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>
 <20180827181311.GA24778@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180827181311.GA24778@infradead.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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