On Thu, Nov 01, 2012 at 01:00:43PM -0400, Alan Stern wrote:
> On Thu, 1 Nov 2012, Greg KH wrote:
> 
> > On Thu, Nov 01, 2012 at 08:59:11AM -0700, Sarah Sharp wrote:
> > > On Mon, Oct 29, 2012 at 04:28:39PM +0800, Lan Tianyu wrote:
> > > > This patch is to set xhci root hub's DeviceRemovable according to usb 
> > > > port's
> > > > connect type which currently comes from ACPI information. If ACPI 
> > > > information
> > > > was different with PORTSC, there would be a warning.
> > > 
> > > You should also add the note here that you're trusting the ACPI tables
> > > over the xHCI DeviceRemovable port status register bits when you decide
> > > whether to mark a port as hard-wired.  Tianyu is doing it this way
> > > because Windows is likely to rely on the ACPI tables over the
> > > DeviceRemovable bits.
> > 
> > "Likely"?  Is that going to be tested anywhere in the Windows test
> > suites?
> > 
> > I would think that the bits would be more reliable than the ACPI tables.
> 
> I would expect that the ACPI tables and other parts of the BIOS are
> easier for manufacturers to update than the settings in other system
> components (like xHCI controllers).  Even an end user can re-flash the
> BIOS.
> 
> Of course, that doesn't mean the ACPI values are always going to be
> right; firmware-derived values are notoriously unreliable.  And as for
> which values Windows will rely upon, probably only the people in
> Redmond know for sure.

That was bad wording, sorry.  I know that the Intel developers who
designed this mechanism have advised Microsoft to use the APCI tables.
In fact, they weren't even aware of the DeviceRemovable bits until I
told them about it.  Microsoft's own documentation talks about the ACPI
tables as well, see:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff553550%28v=vs.85%29.aspx

So, AFAIK, Microsoft will be using the ACPI tables to determine which
ports are safe to power off.

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to