On 13 February 2015 at 10:11, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Friday, February 13, 2015 08:54:56 AM Viresh Kumar wrote:
It is not possible for the clockevents core to know which modes (other than those with a corresponding feature flag) are supported by a particular implementation. And drivers are expected to handle transition to all modes elegantly, as ->set_mode() would be issued for them unconditionally.
Now, adding support for a new mode complicates things a bit if we want to use the legacy ->set_mode() callback. We need to closely review all clockevents drivers to see if they would break on addition of a new mode. And after such reviews, it is found that we have to do non-trivial changes to most of the drivers [1].
Introduce mode-specific set_mode_*() callbacks, some of which the drivers may or may not implement. A missing callback would clearly convey the message that the corresponding mode isn't supported.
This is not going to fly AFAICS if you don't say what exacly you need it for.
For this: https://lkml.org/lkml/2014/5/9/508