Spreading FUD [was: The fatal logic error in EC write transaction(EC transaction is done in interrupt context)]

[Alexey Starikovskiy <aystarik@gmail.com>]

Yakui,

Please take a look at the subject of the thread -- notice words "fatal"
and "(EC transaction is done in interrupt context)".
Looks horrible, isn't it? Now we begin to get into details, and it appears
that it is not fatal, introduced 3.5 years ago, and has nothing to do with
interrupt context transaction patch.
So, the whole point of your message is to spread FUD about "fast 
transaction" patch,
and show how great you are. I would guess that you've failed in 
achieving both goals.

If you cry "wolf!" too often, you'll get ignored, when the real wolf 
appears.

Now, for a positive example, the same message without exclamation marks...
---------------------------------------------------------------------------------------------------------------------------------
Subject: difference in EC transaction protocol
Hi Alex,
I've noticed difference in EC transaction protocol for write and 
burst-disable commands,
namely all that end with writing byte to EC -- they don't wait for last 
confirmation interrupt and
next transaction might start before current one completes.
May be this is the "root cause" we are looking for.
Regards,
Yakui
---------------------------------------------------------------------------------------------------------------------------------
Note that this message is shorter, and is not offensive.
Smile, and people may start to like you...

Regards,
Alex.

P.S. And I don't agree with your analysis as you still believe that 
before the fast transaction mutex was
not released at the same time as it is now.

Zhao Yakui wrote:
> On Sun, 2008-11-09 at 00:47 +0800, Alexey Starikovskiy wrote:
>   
>> Yakui,
>> This is not about my patch, this is about your ego...
>>     
> Thanks for the reply. I know that this is not introduced by your patch.
> In the previous kernel the EC transaction is explicitly divided into
> several phases. Only when EC transaction is really finished, the EC
> mutex lock is released.  In such case the previous EC transaction is
> already  finished when OS begins another EC transaction. So the issue
> about "1 microsecond" won't appear.
No. No matter how many phases, transaction is done and EC mutex is released
as soon as last write happens. EC driver never waited for confirmation 
for last written byte.
>  But in your patch(EC transaction is
> done in interrupt context) when EC mutex is released , maybe the
> previous EC transaction is not really finished. In such case the  issue
> of "1 microsecond"  will appear.
> Is what I said right?
No. my patch has same "optimization" as appeared in EC driver since 
introduction of interrupt mode.
May be it is more visible now, and you managed to notice it, while still 
failing to see it in earlier EC driver versions?
I agree that there are some benefits in not doing this optimization, 
thus I made the patch to drop it.
>  
>   
>> My patch did not introduce this behaviour, it was there since "burst mode" was introduced, and may be even earlier. You may ask Luming Yu, why he was so optimistic about 1 microsecond (is he still around? you did not include him into CC yet...).
>>     
Actually, I gave too much credit to Shanghai office... Interrupt mode patch was written by Dmitry Torokhov, not Luming Yu.

> In my email what I said is only to point out the logic error. Maybe
>   
No, see above.
> there is no problem that the EC mutex is released before EC transaction
> is really finished. IMO this is still a logic error. The program  logic
> states that EC transaction is already finished but the EC transaction is
> not really finished. They are inconsistent..
>    The more important is that the failure in EC transaction can't be
> detected in time.
>   
>    Do you agree with my analysis?
>   
>   
No, see above.