Re: [PATCH 2/3] usb: Take attribute avoid_reset_quirk out of usb device's attribute group

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

 



Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> writes:

> No.  Some internal ports can be pluggable, like your card reader, or
> those ones behind an rfkill switch.  But only internal ports can be
> "unpluggable".
>
> I'm apparently not explaining the ACPI methods very well.  Can you
> please take a look at the Microsoft page on them and let me know if it
> clears up your confusion:
>
> http://msdn.microsoft.com/en-us/library/windows/hardware/ff553550%28v=vs.85%29.aspx


OK, that explains a lot of things for me, along with looking at the
actual DSDT on my laptop.  I guess you are after things like PRT5 here
(note that it doesn't have any _PLD, which makes sense I believe):

            Device (USB2)
            {
                Name (_ADR, 0x001D0002)
..
                Device (URTH)
                {
                    Name (_ADR, 0x00)
                    Device (PRT4)
                    {
                        Name (_ADR, 0x01)
                        Name (_UPC, Package (0x04)
                        {
                            0xFF, 
                            0xFF, 
                            0x00, 
                            0x00
                        })
                        Name (_PLD, Buffer (0x10)
                        {
                            /* 0000 */    0x81, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
                            /* 0008 */    0x30, 0x1C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
                        })
                    }

                    Device (PRT5)
                    {
                        Name (_ADR, 0x02)
                        Name (_UPC, Package (0x04)
                        {
                            0x00, 
                            0xFF, 
                            0x00, 
                            0x00
                        })
                    }
                }

So PRT4 is internal and pluggable (and in fact connected to a modem in a
mini-PCIe slot), while PRT5 is unconnectable.  Note that it doesn't have
any visibility indication.  But that doesn't matter, does it?

No, I wouldn't mind if PRT5 was powered off.  But I do wonder what the
actual power savings could possibly be.  I assume the pins are
unconnected so that there couldn't be any power lost there, and the
controller must be active to support the other port anyway.

Some measurements sure would be interesting.

>> I'm not sure even that much is true.  For example, my Asus laptop has a
>> USB card reader that's built-in.  The connection is definitely
>> internal; the user cannot get at it (although I don't know what the
>> ACPI tables have to say about it).  But the card reader disconnects
>> itself from the USB bus whenever there's no card inserted.
>> 
>> At any rate, it seems that you should be focusing on pluggable vs. 
>> unpluggable rather than internal vs. external.
>
> Ok, fine.  I do think the internal vs external information could be
> useful to userspace to decide whether it should turn off a port, but I
> agree that unpluggable vs pluggable is more useful.

I don't think the DSDT provides enough information for me to know which
of the many internal pluggable ports I can power off.  Some of them are
connected to internal devices I care about (bluetooth and modem), and
others are connected to devices I might want to power off (fingerprint
scanner and webcam). And two internal ports are pluggable but AFAIK not
connected to anything.  I guess that must be the empty mini-PCIe slot
and the mini-PCIe slot with the wlan card.

Hmm, yes, thinking about this it might help to know which of the 5
unused ports are internal.


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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux