On Fri, 15 Sep 2000, David Hinds wrote:
> >
> > socket->events = 0;
> >
> > to "yenta_get_status()". Nothing more, nothing less.
>
> I think this is a bad idea. Ignoring latched events and relying on
> the current socket status is unsafe. You can ignore transient
> card-detect events when the driver hasn't yet started the power up
> sequence, but you cannot ignore them at other times, because the
> bridge does stuff (like cutting power, and redetecting card type) on
> its own.
Hmm.. You're probably right.
It still implies to me that the cs.c code is doing things at too low a
level - it does stuff at a controller level which means that the actual
low-level driver has a hard time trying to figure out what the CS level
really wants. For example, if the higher levels just had a "set power
state" thing, the low-level driver could know that the higher levels want
to change power, and more-over the low-level driver might be able to make
a decision based on that ("it's powering up the card, so I can get rid of
old events").
Right now, the low-level driver has no clue, it just has to assume that
any "set_socket()" call might be a power-up event, for example. It can
compare the new voltage to the one it has programmed in the controller,
but as Andrew pointed out that isn't actually even reliable - because
reading the power level is not going to actually tell you if the
controller had shut off power on its own for some reason.
I don't like Andrew's patch: I see why he does what he does, but it feels
like papering over the real problem which is that the interfaces are just
too opaque for the cs.c code to easily tell the controller what to do, and
vice versa. They both have state, and neither of them can look at the
others state, even though they are really talking about the same thing.
I don't like this "pass hints around" approach. Why not say outright what
you want done, instead of having magic flags that in combination with
other magic flags imply what is going on?
Actually, I'd love to just clear the events _after_ we have passed them
off to the cs layer (instead of before), but that would be inherently
racy, and we might end up missing a valid event if it came in at just the
right time. But a "acknowledge events" callback might work (ie the CS
layer would do a "acknowledge card present change" callback after it was
happy with the situation and had powered up the new card).
Or, we could just do the initial debouncing, all the SS_PENDING etc stuff
in the low-level driver. Which would side-step the communication issue
completely...
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:26 EST