[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e5273fa943335bbc1300360d7944c66d57ea5e27.camel@intel.com>
Date: Thu, 21 Nov 2019 15:52:18 -0800
From: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
To: Pavel Machek <pavel@...x.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Anirudh Venkataramanan <anirudh.venkataramanan@...el.com>,
Tony Brelinski <tonyx.brelinski@...el.com>,
Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 4.19 063/422] ice: Prevent control queue operations
during reset
On Wed, 2019-11-20 at 22:48 +0100, Pavel Machek wrote:
> Hi!
> > [ Upstream commit fd2a981777d911b2e94cdec50779c85c58a0dec9 ]
> >
> > Once reset is issued, the driver loses all control queue interfaces.
> > Exercising control queue operations during reset is incorrect and
> > may result in long timeouts.
> >
> > This patch introduces a new field 'reset_ongoing' in the hw structure.
> > This is set to 1 by the core driver when it receives a reset interrupt.
> > ice_sq_send_cmd checks reset_ongoing before actually issuing the
> > control
> > queue operation. If a reset is in progress, it returns a soft error
> > code
> > (ICE_ERR_RESET_PENDING) to the caller. The caller may or may not have
> > to
> > take any action based on this return. Once the driver knows that the
> > reset is done, it has to set reset_ongoing back to 0. This will allow
> > control queue operations to be posted to the hardware again.
> >
> > This "bail out" logic was specifically added to ice_sq_send_cmd (which
> > is pretty low level function) so that we have one solution in one place
> > that applies to all types of control queues.
>
> I don't think this is suitable for stable. Would driver maintainers
> comment?
Actually this change is fine for stable.
>
> > + *
> > + * As this is the start of the reset/rebuild cycle,
> > set
> > + * both to indicate that.
> > + */
> > + hw->reset_ongoing = true;
> > }
> > }
>
> This should be = 1, since variable is u8...
This variable is treated as a bool, and since bools vary depending on
architecture, Linus has stated that using a u8 would be more consistent
across the vary architectures. So we have used u8's for variables treated
as bools.
In addition, there has been no issue assigning "true" or "false" to a u8.
>
> Best regards,
> Pav
> el
>
> > +++ b/drivers/net/ethernet/intel/ice/ice_type.h
> > @@ -293,6 +293,7 @@ struct ice_hw {
> > u8 sw_entry_point_layer;
> >
> > u8 evb_veb; /* true for VEB, false for VEPA */
> > + u8 reset_ongoing; /* true if hw is in reset, false otherwise */
> > struct ice_bus_info bus;
> > struct ice_nvm_info nvm;
> > struct ice_hw_dev_caps dev_caps; /* device capabilities */
> > --
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists