On 2/23/24 17:06, Maciej Fijalkowski wrote:
1. pcaps are free'd right after AQ routines are done, no need for
devm_'s
2. a test frame for loopback test in ethtool -t is destroyed at the end
of the test so we don't need devm_ here either.
Signed-off-by: Maciej Fijalkowski
---
drivers/n
Hello Paul,
On Mon Feb 26 2024, Paul Menzel wrote:
> Dear Kurt,
>
>
> Thank you for the patch. Some nits from my side.
>
> Am 26.02.24 um 09:51 schrieb Kurt Kanzenbach:
>> Add support for offloading MQPRIO. The hardware has four priorities as well
>> as four queues. Each queue must be a assigned w
Mon, Feb 26, 2024 at 04:11:23PM CET, mschm...@redhat.com wrote:
>There is a need for synchronization between ice PFs on the same physical
>adapter.
>
>Add a "struct ice_adapter" for holding data shared between PFs of the
>same multifunction PCI device. The struct is refcounted - each ice_pf
>holds
On Sun, 25 Feb 2024 08:18:00 +0100 Jiri Pirko wrote:
> >Do you recall any specific param that got rejected from mlx5?
> >Y'all were allowed to add the eq sizing params, which I think
> >is not going to be mlx5-only for long. Otherwise I only remember
> >cases where I'd try to push people to use the
All MAC drivers have been converted to use the link mode members of
keee. So remove the _u32 values, and the code in the ethtool core to
convert the legacy _u32 values to link modes.
Reviewed-by: Simon Horman
Signed-off-by: Andrew Lunn
---
include/linux/ethtool.h | 3 ---
net/ethtool/eee.c
Make use of the existing linkmode helpers for converting PHY EEE
register values into links modes, now that ethtool_keee uses link
modes, rather than u32 values.
Reviewed-by: Simon Horman
Signed-off-by: Andrew Lunn
---
drivers/net/ethernet/intel/igc/igc_ethtool.c | 9 +
1 file changed,
Make use of the existing linkmode helpers for converting PHY EEE
register values into links modes, now that ethtool_keee uses link
modes, rather than u32 values.
Reviewed-by: Simon Horman
Signed-off-by: Andrew Lunn
---
drivers/net/ethernet/intel/igb/igb_ethtool.c | 35 ++
Make use of the existing linkmode helpers for converting PHY EEE
register values into links modes, now that ethtool_keee uses link
modes, rather than u32 values.
Reviewed-by: Simon Horman
Signed-off-by: Andrew Lunn
---
drivers/net/ethernet/intel/e1000e/ethtool.c | 17 -
1 file c
Energy Efficient Ethernet should always be negotiated with the link
peer. Don't include SUPPORTED_Autoneg in the results of get_eee() for
supported, advertised or lp_advertised, since it is
assumed. Additionally, ethtool(1) ignores the set bit, and no other
driver sets this.
Reviewed-by: Jacob Kel
Convert the tables to make use of ETHTOOL link mode bits, rather than
the old u32 SUPPORTED speeds. Make use of the linkmode helps to set
bits and compare linkmodes. As a result, the _u32 members of keee are
no longer used, a step towards removing them.
Signed-off-by: Andrew Lunn
---
drivers/net
Make use of the existing linkmode helpers for bit manipulation of EEE
advertise, support and link partner support. The aim is to drop the
restricted _u32 variants in the near future.
Reviewed-by: Simon Horman
Signed-off-by: Andrew Lunn
---
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 60 ++
Make use of the existing linkmode helpers for converting PHY EEE
register values into links modes, now that ethtool_keee uses link
modes, rather than u32 values.
Signed-off-by: Andrew Lunn
---
drivers/net/usb/ax88179_178a.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff -
Make use of the existing linkmode helpers for converting PHY EEE
register values into links modes, now that ethtool_keee uses link
modes, rather than u32 values.
Rework determining if EEE is active to make is similar as to how
phylib decides, and make use of a phylib helper to validate if EEE is
v
EEE has until recently been limited to lower speeds due to the use of
the legacy u32 for link speeds. This restriction has been lifted, with
the use of linkmode bitmaps, added in the following patches:
1f069de63602 ethtool: add linkmode bitmap support to struct ethtool_keee
1d756ff13da6 ethtool: a
The indentation for ice_set_ctx and ice_write_rxq_ctx breaks the function
name after the return type. This style of breaking is used a lot throughout
the ice driver, even in cases where its not actually helpful for
readability. We no longer prefer this style of line splitting in the
driver, and new
The functions used to pack the Tx and Rx context into the hardware format
rely on using BIT() and then subtracting 1 to get a bitmask. These
functions even have a comment about how x86 machines can't use this method
for certain widths because the SHL instructions will not work properly.
The Linux
In ice_common.c there are 4 functions used for converting the unpacked
software Tx and Rx context structure data into the packed format used by
hardware. These functions have extremely generic names:
* ice_write_byte
* ice_write_word
* ice_write_dword
* ice_write_qword
When I saw these functi
The ice driver has a handful of functions used for packing Tx and Rx context
data from the structured software layout to the bit-packed hardware layout.
The function names are uninformative, being named "ice_write_". While
they are static to the file, it is still not a good idea to use such broad
On 01.02.2024 13:22, Alexander Lobakin wrote:
> bitmap_size() is a pretty generic name and one may want to use it for
> a generic bitmap API function. At the same time, its logic is not
> "generic", i.e. it's not just `nbits -> size of bitmap in bytes`
> converter as it would be expected from its n
On 2024-02-26 6:21 a.m., Alexey Kodanev wrote:
There are currently two pairs of identical checks and calls
to iavf_{add|del}_cloud_filter().
Detected using the static analysis tool - Svace.
Signed-off-by: Alexey Kodanev
---
drivers/net/ethernet/intel/iavf/iavf_main.c | 9 -
1 fil
On 2/26/2024 12:11 PM, Michal Schmidt wrote:
> On Mon, Feb 26, 2024 at 8:36 PM Jacob Keller wrote:
>> On 2/26/2024 7:11 AM, Michal Schmidt wrote:
>>> The writing is performed indirectly, by the hardware, as a result of
>>> the driver writing GLTSYN_CMD_SYNC in ice_ptp_exec_tmr_cmd. I wasn't
>>>
On Mon, Feb 26, 2024 at 8:36 PM Jacob Keller wrote:
> On 2/26/2024 7:11 AM, Michal Schmidt wrote:
> > The writing is performed indirectly, by the hardware, as a result of
> > the driver writing GLTSYN_CMD_SYNC in ice_ptp_exec_tmr_cmd. I wasn't
> > sure if the ice_flush there is enough to make sure
On Mon, Feb 26, 2024 at 8:17 PM Jacob Keller wrote:
> On 2/26/2024 7:11 AM, Michal Schmidt wrote:
> > This series removes the use of the heavy-weight PTP hardware semaphore
> > in the gettimex64 path. Instead, serialization of access to the time
> > register is done using a host-side spinlock. The
On 2/26/2024 7:11 AM, Michal Schmidt wrote:
> This is a cleanup. It is unnecessary to have this function just to call
> another function.
>
> Signed-off-by: Michal Schmidt
Obvious cleanup, thanks!
Reviewed-by: Jacob Keller
On 2/26/2024 7:11 AM, Michal Schmidt wrote:
> The PTP hardware semaphore (PFTSYN_SEM) is used to synchronize
> operations that program the PTP timers. The operations involve issuing
> commands to the sideband queue. The E810 does not have a hardware
> sideband queue, so the admin queue is used.
On 2/26/2024 7:11 AM, Michal Schmidt wrote:
> There is a need for synchronization between ice PFs on the same physical
> adapter.
>
> Add a "struct ice_adapter" for holding data shared between PFs of the
> same multifunction PCI device. The struct is refcounted - each ice_pf
> holds a reference
On 2/26/2024 7:11 AM, Michal Schmidt wrote:
> This series removes the use of the heavy-weight PTP hardware semaphore
> in the gettimex64 path. Instead, serialization of access to the time
> register is done using a host-side spinlock. The timer hardware is
> shared between PFs on the PCI adapter
On 2/23/2024 5:07 AM, Martin Kulas wrote:
> Dear Karol,
>
> On Thu, Feb 22, 2024 at 05:30:09PM +, Kolacinski, Karol wrote:
> [...]
>>
>> On Tue, Feb 20, 2024 at 2:17PM +0100, Martin Kulas wrote:
>>>
>>> After having applied that commit, the TX timestamp read latency stays
>>> unacceptable
On Fri, Feb 23, 2024 at 07:40:24AM +0100, Michal Swiatkowski wrote:
> During VSI reconfiguration filters and VSI config which is set in
> ice_vf_init_host_cfg() are lost. Recall the host configuration function
> to restore them.
>
> Without this config VF on which MSI-X amount was changed might ha
Hi all,
I couldn't see any replies to this issue (but I'm also not subscribed to
the list, probably something I should consider...) but I have another
instance of the issue reported.
Now cc'ing other parties in the hope to get indication this is already
solved (somehow) or will be looked int
There are currently two pairs of identical checks and calls
to iavf_{add|del}_cloud_filter().
Detected using the static analysis tool - Svace.
Signed-off-by: Alexey Kodanev
---
drivers/net/ethernet/intel/iavf/iavf_main.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/net/et
The "qv_info" ptr cannot be NULL when it gets the address of
an element of the flexible array "qvlist_info->qv_info".
Detected using the static analysis tool - Svace.
Signed-off-by: Alexey Kodanev
---
drivers/net/ethernet/intel/i40e/i40e_client.c | 4
drivers/net/ethernet/intel/i40e/i
This is a cleanup. It is unnecessary to have this function just to call
another function.
Signed-off-by: Michal Schmidt
---
drivers/net/ethernet/intel/ice/ice_ptp.c | 25 +++-
1 file changed, 3 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_pt
The PTP hardware semaphore (PFTSYN_SEM) is used to synchronize
operations that program the PTP timers. The operations involve issuing
commands to the sideband queue. The E810 does not have a hardware
sideband queue, so the admin queue is used. The admin queue is slow.
I have observed delays in hund
There is a need for synchronization between ice PFs on the same physical
adapter.
Add a "struct ice_adapter" for holding data shared between PFs of the
same multifunction PCI device. The struct is refcounted - each ice_pf
holds a reference to it.
Its first use will be for PTP. I expect it will be
This series removes the use of the heavy-weight PTP hardware semaphore
in the gettimex64 path. Instead, serialization of access to the time
register is done using a host-side spinlock. The timer hardware is
shared between PFs on the PCI adapter, so the spinlock must be shared
between ice_pf instanc
On Thu, Feb 22, 2024 at 01:39:55PM +0100, Michal Swiatkowski wrote:
> In case of traffic going from the VF (so ingress for port representor)
> source VSI should be consider during packet classification. It is
> needed for hardware to not match packets from different ports with
> filters added on ot
On Thu, Feb 22, 2024 at 01:39:56PM +0100, Michal Swiatkowski wrote:
> Add new matching type for ip_proto.
>
> Use it in the same lookup type as for TTL. In hardware it has the same
> protocol ID, but different offset.
>
> Example command to add filter with ip_proto:
> $tc filter add dev eth10 ing
Fri, Dec 08, 2023 at 01:42:27AM CET, pawel.kamin...@intel.com wrote:
>Add support for driver-specific devlink loopback param. Supported values
>are "enabled", "disabled" and "prioritized". Default configuration is
>set to "enabled".
>
>Add documentation in networking/devlink/ice.rst.
>
>In previous
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Pawel Kaminski
> Sent: Friday, December 8, 2023 1:42 AM
> To: intel-wired-lan@osuosl.org
> Cc: Kitszel, Przemyslaw ;
> net...@vger.kernel.org; Kaminski, Pawel ;
> Wilczynski, Michal
> Subject: [Intel-wired-lan] [PATCH iwl-next v2
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Kaminski, Pawel
> Sent: Thursday, December 7, 2023 1:26 AM
> To: Jakub Kicinski
> Cc: Kitszel, Przemyslaw ; intel-wired-
> l...@osuosl.org; Wilczynski, Michal ;
> net...@vger.kernel.org
> Subject: Re: [Intel-wired-lan] [PATCH iwl
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> kernel test robot
> Sent: Thursday, May 18, 2023 6:34 AM
> To: Ertman, David M ; intel-wired-
> l...@lists.osuosl.org
> Cc: l...@lists.linux.dev; oe-kbuild-...@lists.linux.dev
> Subject: Re: [Intel-wired-lan] [PATCH iwl-next v6 02
Dear Kurt,
Thank you for the patch. Some nits from my side.
Am 26.02.24 um 09:51 schrieb Kurt Kanzenbach:
Add support for offloading MQPRIO. The hardware has four priorities as well
as four queues. Each queue must be a assigned with a unique priority.
However, the priorities are only consider
Add support for offloading MQPRIO. The hardware has four priorities as well
as four queues. Each queue must be a assigned with a unique priority.
However, the priorities are only considered in TSN Tx mode. There are two
TSN Tx modes. In case of MQPRIO the Qbv capability is not
required. Therefore,
44 matches
Mail list logo
