[U-Boot] [U-Boot, 36/36] rockchip: add common board file for rockchip platform

[Tom Rini]

On Fri, Apr 13, 2018 at 03:51:07PM +0800, Kever Yang wrote:
> Hi Philipp,
> 
> 
> On 04/08/2018 09:45 AM, Kever Yang wrote:
> >>> +__weak int arch_cpu_init(void)
> >>> +{
> >>> +    return 0;
> >>> +}
> >>> +
> >>> +__weak int rk_board_init_f(void)
> >>> +{
> >>> +    return 0;
> >>> +}
> >> This doesn't really help in modularising our board-support and I am
> >> not a fan of adding something like 'rk_board_init_f' in the first place.
> >>
> >> Instead this should be implemented in a way that actually makes the
> >> code structure easier and more resilient for the future (having __weak
> >> functions at the architecture-level doesn't really help)... in fact
> >> the only other uses of __weak in the U-Boot source-base are within
> >> SPL, as there's no other way to provide hooks there.
> > I know your proposal is to use DM for board init, then could you make it
> > more
> > clear about how to handle this in your solution?
> > We need to do:
> > - same board init flow for all rockchip platform;
> > - something different but common in soc level;
> > - something different in board level;
> 
> I didn't see your response for this, could you send out your patches?
> 
> I admit that I'm not very clear about the limitation of '__weak' function,
> but I do see there are many '__weak' function in common/board_f/r.c,
> and my common board file is connect to the board_r.c.
> 
> @Simon, @Tom,
>     Could you kindly give some comment here?

I am perhaps more of a fan of using weak functions than other people
are.  The problem with weak functions is that you must know when
designing the code that it can safely only be overridden in one place
per build.  Otherwise the results are not predictable.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180413/759eb09f/attachment.sig>