Thank you for contacting the Intel Embedded Community.
The information that may help you is stated in sections 2.1.7, 2.1.8, and 5.1, on pages 11, 12, 121, 122, and 123 of the Enhanced Host Controller Interface (EHCI) Specification for Universal Serial Bus (USB) Revision 2.0.
By the way, it is important to let you know that you should address your EHCI consultations to the channels listed on page 5 of the document mentioned on this communication.
We hope that this information is useful to you.
I'm sorry, but this has nothing to do with the EHCI specification. What is clearly shown, is that the chipset fails to adhere to the EHCI specification due to some obscure reason. The question is, why doesn't the write of the BIOS semaphore bit makes it trough to the application level? According to the EHCI specification it should, so what is keeping it from making it. Is it an ERRATA, prefetch or some lock bit or something else keeping it from making it through.
There are many occasions when Linux fails the EHCI handoff with different BIOSes on various Intel platforms. It may be a good idea to sort this out now, so further EHCI handoff failures can be avoided in the future. It should be in all parties interests that the EHCI handoff works on Intel platforms.
Regarding the ULSEC register, it's behavior is not documented enough. For example a 32-bit read, then modifying the OS semaphore bit and writing it back does not trigger a SMI. Only a 8-bit write to the OS semaphore byte do. The EHCI specification doesn't say anything about the mechanics behind the OS and BIOS semaphore bits, except that they should be writable. And that is exactly what doesn't happen with the BIOS semaphore bit.