Hi,
This is a series to prepare port representor for supporting also
subfunctions. We need correct devlink locking and the possibility to
update parent VSI after port representor is created.
Refactor how devlink lock is taken to suite the subfunction use case.
VSI configuration needs to be done
It is used to get representor structure during cleaning.
Reviewed-by: Wojciech Drewek
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/ice_eswitch_br.c | 4 +++-
drivers/net/ethernet/intel/ice/ice_eswitch_br.h | 1 +
drivers/net/ethernet/intel/ice/ice_repr.c | 7 ++
In case of subfunction lock will be taken for whole port creation and
removing. Do the same in VF case.
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/devlink/devlink.c | 2 --
drivers/net/ethernet/intel/ice/devlink/devlink_port.c | 4 ++--
drivers/net/ethernet/intel/i
It is needed because subfunction port representor shouldn't configure
the source VSI during representor creation.
Move the code to separate function and call it only in case the VF port
representor is being created.
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/ice_eswitc
In case of reset of VF VSI can be reallocated. To handle this case it
should be properly updated.
Reload representor as vsi->vsi_num can be different than the one stored
when representor was created.
Instead of only changing antispoof do whole VSI configuration for
eswitch.
Signed-off-by: Michal
.org/0day-ci/archive/20240610/202406100753.38qaqzo9-...@intel.com/config)
compiler: gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Reported-by
On 09.06.2024 19:33, Asbjørn Sloth Tønnesen wrote:
> Encapsulation control flags are currently not used anywhere,
> so all flags are currently unsupported by all drivers.
>
> This patch adds validation of this assumption, so that
> encapsulation flags may be used in the future.
>
> In case any
After 230f3d53a547 patch all I/O errors are being converted into EAGAIN
which leads to retries until timeout so nvmupdate sometimes fails after
more than 20 minutes!
Remove misleading EIO to EGAIN conversion and pass all errors as is.
Fixes: 230f3d53a547 ("i40e: remove i40e_status")
Co-developed-
Dear Aleksandr, dear Kelvin,
Thank you for your patch.
Am 10.06.24 um 11:20 schrieb Aleksandr Loktionov:
After 230f3d53a547 patch all I/O errors are being converted into EAGAIN
which leads to retries until timeout so nvmupdate sometimes fails after
more than 20 minutes!
Remove misleading EIO
> -Original Message-
> From: Intel-wired-lan On Behalf Of Dawid
> Osuchowski
> Sent: Friday, June 7, 2024 5:46 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: Kwan, Ngai-mint ; net...@vger.kernel.org;
> Chmielewski, Pawel ; Simon Horman
> ; Polchlopek, Mateusz ; Dawid
> Osuchowski
> S
> -Original Message-
> From: Paul Menzel
> Sent: Monday, June 10, 2024 11:45 AM
> To: Loktionov, Aleksandr ; Kang,
> Kelvin
> Cc: intel-wired-...@lists.osuosl.org; Nguyen, Anthony L
> ; net...@vger.kernel.org; Kubalewski,
> Arkadiusz ; Sokolowski, Jan
> ; Leon Romanovsky
> Subject: Re:
> -Original Message-
> From: Loktionov, Aleksandr
> Sent: Monday, June 10, 2024 12:14 PM
> To: Paul Menzel ; Kang, Kelvin
>
> Cc: intel-wired-...@lists.osuosl.org; Nguyen, Anthony L
> ; net...@vger.kernel.org; Kubalewski,
> Arkadiusz ; Sokolowski, Jan
> ; Leon Romanovsky
> Subject: RE:
On 6/8/2024 2:55 PM, Simon Horman wrote:
On Tue, Jun 04, 2024 at 09:13:49AM -0400, Mateusz Polchlopek wrote:
From: Jacob Keller
Add support for allowing a VF to enable PTP feature - Rx timestamps
The new capability is gated by VIRTCHNL_VF_CAP_PTP, which must be
set by the VF to request acc
Dear Aleksandr,
Thank you for your prompt reply.
Am 10.06.24 um 12:14 schrieb Loktionov, Aleksandr:
-Original Message-
From: Paul Menzel
Sent: Monday, June 10, 2024 11:45 AM
[…]
Am 10.06.24 um 11:20 schrieb Aleksandr Loktionov:
After 230f3d53a547 patch all I/O errors are being c
> -Original Message-
> From: Intel-wired-lan On
> Behalf Of Loktionov, Aleksandr
> Sent: Monday, June 10, 2024 12:16 PM
> To: Paul Menzel ; Kang, Kelvin
>
> Cc: Sokolowski, Jan ;
> net...@vger.kernel.org; Kubalewski, Arkadiusz
> ; Nguyen, Anthony L
> ; intel-wired-...@lists.osuosl.org;
Dear Aleksandr,
Thank you for your response.
Am 10.06.24 um 12:20 schrieb Loktionov, Aleksandr:
-Original Message-
From: Intel-wired-lan On Behalf Of
Loktionov, Aleksandr
Sent: Monday, June 10, 2024 12:16 PM
-Original Message-
From: Loktionov, Aleksandr
Sent: Monday, J
On Mon, 2024-06-10 at 08:36 +0200, Paul Menzel wrote:
> Dear Hui,
>
>
> Thank you for your patch.
>
>
> Am 10.06.24 um 03:32 schrieb Hui Wang:
> > This reverts commit bfd546a552e140b0a4c8a21527c39d6d21addb28
> >
> > Commit bfd546a552e1 ("e1000e: move force SMBUS near the end of
> > enable_ulp
Fix the problems that are triggered by tx_timeout and ice_xdp() calls,
including both pool and program operations.
PF reset can be triggered asynchronously, e.g. by tx_timeout. With some
unfortunate timings both reset and .ndo_bpf will try to access and modify
XDP rings at the same time, causing s
XDP setup and PF reset code access the same resources in the following
sections:
* ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked
* ice_vsi_rebuild() for the PF VSI - not protected
With an unfortunate timing, such accesses can result in a crash such as the
one below:
[ +1.999878
With ICE_CFG_BUSY PF state flag locking used in ice_xdp(), there is no need
to lock with VSI state inside ice_xsk_pool_setup(). For robust
synchronization the state between reset preparation and PF VSI rebuild has
to be handled, in the same way as in ice_xdp_setup_prog().
Remove locking logic from
ice_vsi_rebuild() is a critical section in the reset path. Sometimes,
rtnl-locked callbacks have to wait for it to finish. However, it is
possible they will wait for an eternity, because the critical section
contains calls to ice_queue_set_napi() that try to take rtnl_lock.
Make ice_queue_set_napi
This patch adds support for firmware update to the in-tree igb driver and it is
actually a port from the out-of-tree igb driver.
In-band firmware update is one of the essential system maintenance tasks. To
simplify this task, the Intel online firmware update
utility provides a common interface th
This patch adds support for firmware update to the in-tree ixgbe driver and it
is actually a port
from the out-of-tree ixgbe driver. In-band firmware update is one of the
essential system maintenance
tasks. To simplify this task, the Intel online firmware update utility provides
a common interfa
On 6/8/2024 5:55 AM, Simon Horman wrote:
> If you need to respin this for some reason, please consider updating
> the Kernel doc for the following to include a short description.
> Else, please consider doing so as a follow-up
>
> * struct virtchnl_ptp_caps
> * struct virtchnl_phc_time
>
> Lik
On 6/8/2024 11:14 AM, Samal, Anil wrote:
> Hi Jacob,
> Can you please help me with the branch name that I should rebase?
> Last time I rebased to "dev-queue" branch of "git clone
> git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git".
>
> Let me know, if I should use a different br
On Sun, Jun 09, 2024 at 04:15:26PM +0800, Richard chien wrote:
> This patch adds support for firmware update to the in-tree igb driver and it
> is actually a port from the out-of-tree igb driver.
> In-band firmware update is one of the essential system maintenance tasks. To
> simplify this task,
On 09/06/2024 18:33, Asbjørn Sloth Tønnesen wrote:
> Change the existing check for unsupported encapsulation control flags,
> to use the new helper flow_rule_is_supp_enc_control_flags().
>
> No functional change, only compile tested.
>
> Signed-off-by: Asbjørn Sloth Tønnesen
Acked-by: Edward Cr
On Sun, Jun 09, 2024 at 04:57:35PM +0800, Richard chien wrote:
> This patch adds support for firmware update to the in-tree ixgbe driver and
> it is actually a port
> from the out-of-tree ixgbe driver. In-band firmware update is one of the
> essential system maintenance
> tasks. To simplify this
On 6/9/2024 1:15 AM, Richard chien wrote:
> This patch adds support for firmware update to the in-tree igb driver and it
> is actually a port from the out-of-tree igb driver.
> In-band firmware update is one of the essential system maintenance tasks. To
> simplify this task, the Intel online f
On Fri, 7 Jun 2024 14:15:52 +0200 Dawid Osuchowski wrote:
> We cannot use ice_wait_for_reset() since both the ethtool handler and the
> adapter reset flow call rtnl_lock() during operation. If we wait for
> reset completion inside of an ethtool handling function such as
> ice_get_coalesce(), the w
On 6/10/24 14:36, Paul Menzel wrote:
Dear Hui,
Thank you for your patch.
Am 10.06.24 um 03:32 schrieb Hui Wang:
This reverts commit bfd546a552e140b0a4c8a21527c39d6d21addb28
Commit bfd546a552e1 ("e1000e: move force SMBUS near the end of
enable_ulp function") introduces system suspend failu
On 6/10/24 22:14, Zhang, Rui wrote:
On Mon, 2024-06-10 at 08:36 +0200, Paul Menzel wrote:
Dear Hui,
Naama also added Tested-by lines two both commits in question. Could
Intel’s test coverage please extended to the problem at hand?
Acked-by: Paul Menzel
Plus that,
1. Todd and I can test w
> -Original Message-
> From: Intel-wired-lan On Behalf Of Paul
> Greenwalt
> Sent: Thursday, June 6, 2024 7:19 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: Greenwalt, Paul
> Subject: [Intel-wired-lan] [PATCH iwl-next v1] ice: Allow different FW API
> versions based on MAC type
>
> Al
This reverts commit bfd546a552e140b0a4c8a21527c39d6d21addb28
Commit bfd546a552e1 ("e1000e: move force SMBUS near the end of
enable_ulp function") introduces system suspend failure on some
ethernet cards, at the moment, the pciid of the affected ethernet
cards include [8086:15b8] and [8086:15bc].
34 matches
Mail list logo
