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(>state_lock);
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(>state_lock);
> >> + present = pciehp_card_present(ctrl);
> >> + link_active =
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(>state_lock);
>> +present = pciehp_card_present(ctrl);
>> +link_active = pciehp_check_link_active(ctrl);
>> switch (ctrl->state) {
>
> These two assignments
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
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
