> >
> > This one is perfect, thanks!
>
> Can I add your Reviewed-by provided I remove the hunk above?
>
> Luis
Sure, I'm OK.
Regards,
Igor
On Thu, May 14, 2020 at 05:53:41PM +0300, Igor Russkikh wrote:
> >
> > So do you mean like the changes below?
> >
> > diff --git a/drivers/net/ethernet/qlogic/qed/qed_debug.c
> > b/drivers/net/ethernet/qlogic/qed/qed_debug.c
> > index f4eebaabb6d0..95cb7da2542e 100644
> > --- a/drivers/net/ethern
>
> So do you mean like the changes below?
>
> diff --git a/drivers/net/ethernet/qlogic/qed/qed_debug.c
> b/drivers/net/ethernet/qlogic/qed/qed_debug.c
> index f4eebaabb6d0..95cb7da2542e 100644
> --- a/drivers/net/ethernet/qlogic/qed/qed_debug.c
> +++ b/drivers/net/ethernet/qlogic/qed/qed_debug.c
On Tue, May 12, 2020 at 07:23:28PM +0300, Igor Russkikh wrote:
>
> >> So I think its not a good place to insert this call.
> >> Its hard to find exact good place to insert it in qed.
> >
> > Is there a way to check if what happened was indeed a fw crash?
>
> Our driver has two firmwares (slowpat
>> So I think its not a good place to insert this call.
>> Its hard to find exact good place to insert it in qed.
>
> Is there a way to check if what happened was indeed a fw crash?
Our driver has two firmwares (slowpath and fastpath).
For slowpath firmware the way to understand it crashed is t
On Sat, May 09, 2020 at 09:32:51AM +0300, Igor Russkikh wrote:
>
> > This makes use of the new module_firmware_crashed() to help
> > annotate when firmware for device drivers crash. When firmware
> > crashes devices can sometimes become unresponsive, and recovery
> > sometimes requires a driver un
> This makes use of the new module_firmware_crashed() to help
> annotate when firmware for device drivers crash. When firmware
> crashes devices can sometimes become unresponsive, and recovery
> sometimes requires a driver unload / reload and in the worst cases
> a reboot.
>
> Using a taint flag
