Re: [RFC/PATCH] mmc: core: Signal wakeup event at card insert/removal

[Ulf Hansson <ulf.hansson@linaro.org>]

Hi John,

> So how does the notification done to userspace? I wonder if you could
> use the select/lock/read style method for releasing the kernel space
> wakeup_source, as is done in the input layer?

If I understand what you mean correctly, it is very similar what Zoran
tried to do before in his patch!?

For the mmc subsystem, especially considering the pitfalls around the
scheduled detect work, I think it will be hard to get this right, if
implementing like this. I fear we might end up in situations were the
wakeup_source is never "relaxed".

>
>
>> Not sure how to set the time-out value to meet all expectations. I
>> believe we could also consider that inserting/removing a card is a
>> quite seldom operation, so using a bit higher value than necessary
>> might be okay. What do you think?
>
> As long as its sure to be *very* rare, then slightly longer delays
> aren't a major problem.  The trouble with the timeout style wakelocks is
> that they are easy to misuse and that hurts power efficiency. (I've
> heard stories of badly written wifi drivers that took 5 minute timed
> wakelocks on packets, which effectively kept devices from ever sleeping).

In this case, I am more confident that this would actually simplify
code that much, so we can get around all the scary pitfalls.

I can only think of one case which could lead to problem. If there is
a host driver, enabled for wakeup, that gets spurious card detect
irqs, outside the window were you expect a card to be
detected/removed, and at the same time do not have a software
mechanism to "debounce" the irqs. But, should we even consider this as
a valid case?

Kind regards
Ulf Hansson

>
> So if possible, its much better to have a normal path where the pm_relax
> is called in most cases, using the timeout for only the few places where
> you really can't get an end point.
>
> thanks
> -john