On 08/10/2016 10:28 AM, Guilherme G. Piccoli wrote:
On 08/10/2016 04:59 AM, Yuval Mintz wrote:
Why would the published resume() from pci_error_handlers be called
in this
scenario?
It isn't. That's why I specifically commented on commit message:
"There are two
cases though that another path is
> > Why would the published resume() from pci_error_handlers be called in this
> scenario?
>
> It isn't. That's why I specifically commented on commit message: "There are
> two
> cases though that another path is taken on the code".
>
> The code path reach bnx2x_chip_cleanup() on device removal
On 08/10/2016 04:59 AM, Yuval Mintz wrote:
Why would the published resume() from pci_error_handlers be called in this
scenario?
It isn't. That's why I specifically commented on commit message: "There are two
cases though that another path is taken on the code".
The code path reach bnx2x_chip_
> When PCI error is detected, in some architectures (like PowerPC) a slot reset
> is
> performed - the driver's error handlers are in charge of "disable"
> device before the reset, and re-enable it after a successful slot reset.
>
> There are two cases though that another path is taken on the cod
On 08/09/2016 09:14 AM, Yuval Mintz wrote:
When PCI error is detected, in some architectures (like PowerPC) a slot reset is
performed - the driver's error handlers are in charge of "disable"
device before the reset, and re-enable it after a successful slot reset.
There are two cases though that
