On 2/23/19 12:50 AM, Lukas Wunner wrote:
>
> [EXTERNAL EMAIL]
>
> On Fri, Feb 22, 2019 at 07:56:28PM +, alex_gagn...@dellteam.com wrote:
>> On 2/21/19 1:36 AM, Lukas Wunner wrote:
>>> On Tue, Feb 19, 2019 at 07:20:28PM -0600, Alexandru Gagniuc wrote:
mutex_lock(&ctrl->state_lo
On Fri, Feb 22, 2019 at 07:56:28PM +, alex_gagn...@dellteam.com wrote:
> On 2/21/19 1:36 AM, Lukas Wunner wrote:
> > On Tue, Feb 19, 2019 at 07:20:28PM -0600, Alexandru Gagniuc wrote:
> >>mutex_lock(&ctrl->state_lock);
> >> + present = pciehp_card_present(ctrl);
> >> + link_active = pcieh
On 2/21/19 1:36 AM, Lukas Wunner wrote:
> On Tue, Feb 19, 2019 at 07:20:28PM -0600, Alexandru Gagniuc wrote:
>> mutex_lock(&ctrl->state_lock);
>> +present = pciehp_card_present(ctrl);
>> +link_active = pciehp_check_link_active(ctrl);
>> switch (ctrl->state) {
>
> These two assign
On Tue, Feb 19, 2019 at 07:20:28PM -0600, Alexandru Gagniuc wrote:
> @@ -213,6 +213,21 @@ void pciehp_handle_disable_request(struct controller
> *ctrl)
> ctrl->request_result = pciehp_disable_slot(ctrl, SAFE_REMOVAL);
> }
>
> +static bool is_delayed_presence_up_event(struct controller *ct
According to PCIe 3.0, the presence detect state is a logical OR of
in-band and out-of-band presence. With this, we'd expect the presence
state to always be asserted when the link comes up.
Not all hardware follows this, and it is possible for the presence to
come up after the link. In this case,
5 matches
Mail list logo