On Thu, Feb 12, 2015 at 09:09:30AM +0800, Viresh Kumar wrote:
> On 11 February 2015 at 18:38, Peter Zijlstra wrote:
> > I think its better to be strict; esp. with new interfaces. It avoids
> > confusion.
> >
> > Suppose a driver writer sees these new methods and thinks to use one
> > while still h
On 11 February 2015 at 18:38, Peter Zijlstra wrote:
> I think its better to be strict; esp. with new interfaces. It avoids
> confusion.
>
> Suppose a driver writer sees these new methods and thinks to use one
> while still having the set_mode() one -- ie. he didn't actually read the
> comment. We'
On Wed, Feb 11, 2015 at 11:24:53AM +0800, Viresh Kumar wrote:
> On 10 February 2015 at 22:15, Peter Zijlstra wrote:
> > On Wed, Feb 04, 2015 at 01:06:23PM +0530, Viresh Kumar wrote:
> >> + /*
> >> + * Mode transition callback(s): Only one of the two groups should be
> >> + * defined:
On 10 February 2015 at 22:15, Peter Zijlstra wrote:
> On Wed, Feb 04, 2015 at 01:06:23PM +0530, Viresh Kumar wrote:
>> + /*
>> + * Mode transition callback(s): Only one of the two groups should be
>> + * defined:
>> + * - set_mode(), only for modes <= CLOCK_EVT_MODE_RESUME.
>> +
On Wed, Feb 04, 2015 at 01:06:23PM +0530, Viresh Kumar wrote:
> + /*
> + * Mode transition callback(s): Only one of the two groups should be
> + * defined:
> + * - set_mode(), only for modes <= CLOCK_EVT_MODE_RESUME.
> + * - set_mode_{shutdown|periodic|oneshot|resume}().
> +
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, ad
6 matches
Mail list logo
