Re: [PATCH] clockevents: Add (missing) default case for switch blocks

From: Ingo Molnar
Date: Fri Feb 20 2015 - 04:37:14 EST

* Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:

> > So this whole approach looks fragile for several reasons:
> >
> > - 'mode setting' callbacks are just bad by design
> > because they mix several functions into the same entry
> > point, complicating the handler functions
> > unnecessarily. We should reduce complexity, not expand
> > on it.
> >
> > - now by adding 'default' you hide from drivers the
> > ability to easily discover whether it has been updated
> > to some new core clockevents mode setting feature or
> > not.
> So this patch was a follow on from bd624d75db21
> ("clockevents: Introduce mode specific callbacks").
> That patch changes the set_mode() interface; and provides
> per mode functions.

So why is a 'default' mode needed then? It makes the
addition of new modes to the legacy handler easier, which
looks backwards.

> New (and updated) drivers should not use ->set_mode()
> anymore, but it was felt that we do not want to go do
> flag day changes.

I fully agree that we don't want flag day changes, but make
it really apparent that it's an obsolete interface:

- rename it to set_mode_obsolete()

- try to convert as many of the easy cases as possible -
the overwhelming majority of mode setting functions
look reasonably simple.

- get rid of the mode enum in the core, and rename the


> And it allows for adding optional modes; not every driver
> needs to go implement all mode functions if there is a
> sane default action.
> But it does mean we need to be able to add values to the
> enum.

So I'm confused: if we are using proper callbacks (like my
example outlined) , why is a 'mode enum' needed at all?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at