On Fri, Feb 14, 2014 at 12:21 AM, Izumi, Taku <izumi.taku@xxxxxxxxxxxxxx> wrote:
>> Hmm... I see that the Slot has a power controller. Which means that the power to the slot shall not be turned on automatically
>> (by HW) when the card is plugged in. Also meaning that the link will not come up automatically - so this does not seem
>> like the Link state based hotplug kicking in.
>>
>> What I suspect is this one:
>>
>> f02d1843d83b "PCI: pciehp: Remove surprise bit checks"
>
> You are right.
> In case of omitting comit-f02d1843, it worked as expected.
> Slot power doesn't become ON automatically when PCIe card is inserted.
OK, I dropped f02d1843d83b ("PCI: pciehp: Remove surprise bit
checks"). Thanks for testing, everybody!
I think our handling of slot capabilities and control is a bit
haphazard. It seems like we're mostly responding to things that
break, and we don't really have a coherent explanation of how things
*should* work in different configurations. I think it would be good
if somebody wrote up something for Documentation/PCI, with references
to the relevant specifications, that describes how we think things
should work. For example, I think we have at least four models:
1) ExpressCard
2) Slots with attention button
3) Slots with no button where we expect a software UI, e.g., Taku's box
4) Devices with no actual slot, no button, etc., e.g., Rajat's system
We handle these slightly differently, implicitly relying on various
capability tests scattered throughout the code. I think we should be
able to come up with a scheme that would make this more explicit and
make pciehp simpler and more consistent.
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
