Le dimanche 9 mai 2010 05:21:46, Michael Evans a écrit :
> Florian, I'm very much not a fan of the Makefile level solution you've
>  used.
> 
> Is that behavior required to work regardless of multi-threading
> linkers/make processes?  I can see situations where it could work for
> some builders all the time, some builders none of the time, and some
> builders intermittently.

It is guaranteed to work even on multi-threaded systems, which is how I tested 
the stuff as well.

> 
> Where my patch, which moves the function from clock.o out of the arch
> level and in to the core level, will always work since it solves it at
> a kernel list level.  Even the init.h file mentions:
> "
> /* initcalls are now grouped by functionality into separate
>  * subsections. Ordering inside the subsections is determined
>  * by link order.
> "
> 
> Link order might not always obey the assumption that objects are
> linked in left to right order based on the invocation of a single
> command; I read that as a statement to explicitly re-order
> dependencies so that you are //sure// they will execute in the correct
> order.
> 
> On Sat, May 8, 2010 at 7:20 AM, Florian Fainelli <flor...@openwrt.org> wrote:
> > Hi Michael,
> >
> > Le samedi 8 mai 2010 02:08:56, Michael J. Evans a écrit :
> >> Change ar7_init_clocks to a core level function, removing a race
> >> condition.
> >>
> >> Both ar7_init_clocks and ar7_register_devices were using arch_initcall.
> >> However ar7_register_devices depended on values changed by
> >> ar7_init_clocks.
> >
> > Yes this is correct, I have a committed a slightly smaller and simpler
> > fix which also results in clocks being initialized first, then devices
> > registered. initcall macros evalute the order of functions at link time,
> > so it's up to you to re-order them properly to get linked and called in
> > the right order.
> >
> > Thanks for tracking this down.
> >
> >> Also add a printk so that the resulting effect is obvious.
> >>
> >> Signed-off-by: Michael J. Evans <mjevans1...@gmail.com>
> >>
> >> --- a/arch/mips/ar7/clock.c
> >> +++ b/arch/mips/ar7/clock.c
> >> @@ -424,4 +424,4 @@ int __init ar7_init_clocks(void)
> >>
> >>       return 0;
> >>  }
> >> -arch_initcall(ar7_init_clocks);
> >> +core_initcall(ar7_init_clocks);
> >>
> >> --- a/arch/mips/ar7/platform.c
> >> +++ b/arch/mips/ar7/platform.c
> >> @@ -665,6 +665,8 @@ static int __init ar7_register_devices(void)
> >>  #ifdef CONFIG_SERIAL_8250
> >>       static struct uart_port uart_port[2];
> >>
> >> +     printk (KERN_INFO "ar7_register_devices: serial clock %d hz.\n",
> >> +             ar7_bus_freq() / 2);
> >>       memset(uart_port, 0, sizeof(struct uart_port) * 2);
> >>
> >>       uart_port[0].type = PORT_16550A;
> >> _______________________________________________
> >> openwrt-devel mailing list
> >> openwrt-devel@lists.openwrt.org
> >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to