On 08:09 Tue 28 Feb , Sascha Hauer wrote:
> On Mon, Feb 27, 2017 at 11:19:27AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > use the one with the most priority.
> >
> > We can not select the clocksource at user level.
> >
> > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@xxxxxxxxxxxx>
> > ---
> > common/clock.c | 11 +++++++++++
> > include/clock.h | 3 ++-
> > 2 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/common/clock.c b/common/clock.c
> > index 2c5dd91cc..d99d06853 100644
> > --- a/common/clock.c
> > +++ b/common/clock.c
> > @@ -213,6 +213,17 @@ EXPORT_SYMBOL(mdelay_non_interruptible);
> >
> > int init_clock(struct clocksource *cs)
> > {
> > + if (current_clock && cs->priority < current_clock->priority)
> > + return -EBUSY;
>
> You should return successfully here. Otherwise driver probe functions
> return -EBUSY for something which is not the drivers fault. In fact,
> it's not an error, it's just that we currently don't have any use for an
> additional clock.
my issue is that we will report in barebox that the device is in use but in
fact is not as we exit the init_clock without doing event the init.
That's why I choosed to return -EBUSY instead of 0
> Also consider testing for <= current_clock->priority
> instead of <. All current clocks have priority 0 and we want to
> initialize only the first one.
ok
Best Regards,
J.
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
