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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux