Re: Flames over -- Re: Which is simpler?

[Phillip Susi <psusi@cfl.rr.com>]

David Brownell wrote:
> No, not "AFAIK" ... since when I told you explicitly that was untrue,
> you then ignored that statement.  And didn't look at the specs that
> I pointed you towards, which provide the details.  (USB 2.0 spec re
> hubs; and of course the Linux-USB hub driver ... www.usb.org)

I ignored nothing.  I fully accepted your explanation as true and 
pointed out that it changes nothing; data loss in this perfectly valid 
use case just because the kernel can not be absolutely certain the user 
did not do something stupid while suspended is unacceptable.

> 
> The events that a hub receives say pretty exactly what happened.
> You should know that already, since USB behaves that way even
> when the system is _not_ suspended ... 
> 

How it behaves while running and how it behaves while suspended are 
usually two very different things.

> The full mechanism for USB is more like wakeup signaling on USB triggering
> hub wakeup (possibly cascading through a few layers of external hub), at
> some point triggering root hub wakeup, which maps to a PME# signal.  That
> relies on no more than VBUS being powered at a fraction of a milliAmpere,
> and the equivalent of a pair of voltage comparators triggering wakeup when
> USB signaling changes from J to K states for something like 10 msec.
> 
> 
> 
> Did you read about the PME# signal in the PCI PM spec?  www.pci-sig.com
> Maybe you could try that. 
> 

No, I took your word for it without protest as it doesn't change my main 
argument: data loss in the face of normal usage is not acceptable. 
Claiming that it has to be this way because the alternative _might_ 
result in data loss in the worst (mis)use case is an untenable position.


> Also the ACPI spec ... the early chapters give a decent overview of the
> different components of that model.  (ISTR two chapters try that, with
> the second being more to-the-point despite some duplicated graphics.)
> 
> - Dave
> 
>  
>