[UPSTREAM 0/2] pcf50633 changes

[Mike (mwester)]

Mike (mwester) wrote:
> Werner Almesberger wrote:
>> Balaji Rao wrote:
>>> 4. Emergency 8s shutdown has been temporarily removed from the driver
>>> as it certainly does not belong there.
>> What's the plan for this one ? Lots of people seem to feel a strong
>> emotionally attachment to having the equivalent of ctrl-alt-del :)
> 
> I'm rather concerned; it's all too easy to have this functionality get
> lost in the shuffle if it's not implemented up front.

What's the status of this -- has this missing functionality been returned?

>>> 5. 'Suppress onkey events on resume' - must be a better way to handle
>>> this. Can't it be done from userspace ?
>> It seems that whoever has initiated the suspend should also take care
>> of the consequences, yes. This is only about user space, not the
>> hang-on-resume Matt has fixed recently, right ?
> 
> This is the use-case where something initiated a suspend, and the user
> depressed the power key to awaken the device.  In order to do this in
> user-space, someone will need to devise a fool-proof algorithm for
> user-space that can ensure that whatever process reads the power key
> event can distinguish between a power-key event that is real versus a
> power key event that is to be ignored, because it was just the remnants
> of the wake event.

Same question for this one.  I know everyone on this list would like to
see userspace adopt the new kernel; this will be a very visible
regression for the users.

> I rather suspect that the algorithm to do that will need to know the
> wake reason (which is yet to be implemented, according to Balaji's email).
> 
> The big problem I see with leaving this to user space is that it means
> that we need to track down every bit of user-space code that might ever
> read the onkey event, and add logic to that code to inspect the wake
> reason and decide if the event is to be ignored.  Besides, it just
> "feels wrong" -- the button push was to wake up the hardware and nothing
> more; since the user is not intending to signal anything to user space,
> it just seems rational to have the kernel suppress that event after it
> has done its job.  Other wise it's just a spurious event from the point
> of view of an application.
> 
> Mike (mwester)

Mike (mwester)