[U-Boot] [PATCH] sunxi: use CONFIG_DEFAULT_FDT_FILE everywhere

[Maxime Ripard]

On Mon, Jun 04, 2018 at 11:15:34AM -0700, Martin Kelly wrote:
> [snip as the thread is getting long]
> 
> On 06/04/2018 01:21 AM, Maxime Ripard wrote:
> > On Fri, Jun 01, 2018 at 10:16:32AM -0700, Martin Kelly wrote:
> > > On 06/01/2018 04:05 AM, Maxime Ripard wrote:
> > > 
> > > I can see the issues with new defconfigs, but I'm not sure if it will really
> > > be that bad. If we apply this patch against sunxi master, then shouldn't new
> > > patches get tested and rebased against it? In that case, if they have not
> > > set DEFAULT_FDT_FILE, it will default to "", the boards won't boot, and the
> > > mistake must be fixed prior to merging.
> > 
> > Unless one has tested it with a version prior to your patch, and sends
> > it. Not a lot of people are testing with the next branch in the
> > various trees.
> > 
> > > Alternatively if we add the Kconfig boolean, we need to worry about what
> > > happens when people have DEFAULT_FDT_FILE set already. I guess we would need
> > > to default the new Kconfig boolean to be custom in order to keep those
> > > configs from breaking. But if we do that, sunxi will break by default (since
> > > sunxi configs don't have the value set).
> > > 
> > > What would you suggest the default value of the new boolean to be?
> > 
> > config DEFAULT_FDT_FILE_USE_DEFAULT_DEVICE_TREE
> > 	bool "whatever"
> > 	default y if ARCH_ROCKCHIP
> > 	default y if ARCH_SUNXI
> > 
> > and in the headers
> > 
> > #ifdef CONFIG_DEFAULT_FDT_FILE_USE_DEFAULT_DEVICE_TREE
> > #define CONFIG_DEFAULT_FDT_FILE CONFIG_DEFAULT_DEVICE_TREE ".dtb"
> > #endif
> > 
> > And that's done.
> 
> I didn't know Kconfig can set different default values for each
> architecture like that; that does indeed solve the problem. However,
> I don't think it's a good idea to have sunxi use an alternate
> mechanism than the other boards.
> 
> To be clear, are you proposing a general config option that would
> apply to every board? In that case, the header logic would be in a
> global header rather than a board-specific one.

Yes, that's what I had in mind.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180606/c5395ef5/attachment.sig>