On 8/27/24 23:52, Jacob Keller wrote:
The ice_write_rxq_ctx() function is responsible for programming the Rx
Queue context into hardware. It receives the configuration in unpacked form
via the ice_rlan_ctx structure.
This function unconditionally modifies the context to set the prefetch
enable b
allmodconfig gcc-13.2.0
arc allnoconfig gcc-13.2.0
arc allyesconfig gcc-13.2.0
arc defconfig gcc-13.2.0
arc randconfig-001-20240827 gcc-13.2.0
arc
defconfig gcc-13.2.0
arc randconfig-001-20240827 gcc-13.2.0
arc randconfig-002-20240827 gcc-13.2.0
arm allmodconfig gcc-13.2.0
arm allmodconfig gcc-14.1.0
arm
-13.2.0
arc allnoconfig gcc-13.2.0
arc allyesconfig gcc-13.2.0
arc axs101_defconfig gcc-13.2.0
arc randconfig-001-20240827 gcc-13.2.0
arc randconfig-002-20240827 gcc-13.2.0
Hi Karol,
kernel test robot noticed the following build errors:
[auto build test ERROR on 025f455f893c9f39ec392d7237d1de55d2d00101]
url:
https://github.com/intel-lab-lkp/linux/commits/Karol-Kolacinski/ice-Don-t-check-device-type-when-checking-GNSS-presence/20240827-211218
base
On 8/27/2024 2:52 PM, Jacob Keller wrote:
> The copy_rxq_ctx_to_hw() and ice_write_rxq_ctx() are updated to align with
> modern kernel style guidelines. This includes removing an unnecessary NULL
> check, updating the kdoc descriptions to align with the check-kdoc, and
> making ice_copy_rxq_ctx_
From: Vladimir Oltean
packing() is now used in some hot paths, and it would be good to get rid
of some ifs and buts that depend on "op", to speed things up a little bit.
With the main implementations now taking size_t endbit, we no longer
have to check for negative values. Update the local integ
The ice driver needs to write the Tx and Rx queue context when programming
Tx and Rx queues. This is currently done using some bespoke custom logic
via the ice_set_ctx() and its helper functions, along with bit position
definitions in the ice_tlan_ctx_info and ice_rlan_ctx_info structures.
This lo
The int_q_state field of the ice_tlan_ctx structure represents the internal
queue state. However, we never actually need to assign this or read this
during normal operation. In fact, trying to unpack it would not be possible
as it is larger than a u64. Remove this field from the ice_tlan_ctx
struct
From: Vladimir Oltean
Jacob Keller has a use case for packing() in the intel/ice networking
driver, but it cannot be used as-is.
Simply put, the API quirks for LSW32_IS_FIRST and LITTLE_ENDIAN are
naively implemented with the undocumented assumption that the buffer
length must be a multiple of 4
The ice_write_rxq_ctx() function is responsible for programming the Rx
Queue context into hardware. It receives the configuration in unpacked form
via the ice_rlan_ctx structure.
This function unconditionally modifies the context to set the prefetch
enable bit. This was done by commit c31a5c25bb19
The ice_copy_rxq_ctx_to_hw() and ice_write_rxq_ctx() functions perform some
defensive checks which are typically frowned upon by kernel style
guidelines.
In particular, they perform NULL checks on buffers which are never expected
to be NULL. Both functions are only called once and always have vali
From: Vladimir Oltean
It is not necessary to have the kernel-doc duplicated both in the
header and in the implementation. It is better to have it near the
implementation of the function, since in C, a function can have N
declarations, but only one definition.
Signed-off-by: Vladimir Oltean
Sign
From: Vladimir Oltean
Geert Uytterhoeven described packing() as "really bad API" because of
not being able to enforce const correctness. The same function is used
both when "pbuf" is input and "uval" is output, as in the other way
around.
Create 2 wrapper functions where const correctness can be
Add 24 simple KUnit tests for the lib/packing.c pack() and unpack() APIs.
The first 16 tests exercise all combinations of quirks with a simple magic
number value on a 16-byte buffer. The remaining 8 tests cover
non-multiple-of-4 buffer sizes.
These tests were originally written by Vladimir as sim
The QUIRK_MSB_ON_THE_RIGHT quirk is intended to modify pack() and unpack()
so that the most significant bit of each byte in the packed layout is on
the right.
The way the quirk is currently implemented is broken whenever the packing
code packs or unpacks any value that is not exactly a full byte.
The ice_rlan_ctx and ice_tlan_ctx structures have some fields which are
intentionally sized larger necessary relative to the packed sizes the data
must fit into. This was done because the original ice_set_ctx() function
and its helpers did not correctly handle packing when the packed bits
straddled
While reviewing the initial KUnit tests for lib/packing, Przemek pointed
out that the test values have duplicate bytes in the input sequence.
In addition, I noticed that the unit tests pack and unpack on a byte
boundary, instead of crossing bytes. Thus, we lack good coverage of the
corner cases of
From: Vladimir Oltean
While reworking the implementation, it became apparent that this check
does not exist.
There is no functional issue yet, because at call sites, "startbit" and
"endbit" are always hardcoded to correct values, and never come from the
user.
Even with the upcoming support of a
This series refactors the Tx and Rx queue context data packing in the ice
driver to use the API. This is intended to aid in the
future implementation of unpacking context data for live migration. While
it strictly does save a few bytes in the module according to bloat-o-meter,
the savings is quite
Hi Karol,
kernel test robot noticed the following build errors:
[auto build test ERROR on 025f455f893c9f39ec392d7237d1de55d2d00101]
url:
https://github.com/intel-lab-lkp/linux/commits/Karol-Kolacinski/ice-Don-t-check-device-type-when-checking-GNSS-presence/20240827-211218
base
On Tue, 27 Aug 2024 09:16:51 +0200
Przemek Kitszel wrote:
> On 8/26/24 12:17, Thomas Bogendoerfer wrote:
> > On Mon, 26 Aug 2024 11:41:19 +0200
> > Jiri Pirko wrote:
> >
> >> Mon, Aug 26, 2024 at 10:58:30AM CEST, tbogendoer...@suse.de wrote:
> >>> For PFs, which don't support SRIOV_LAG, the
On 2024-08-21 16:32, Willem de Bruijn wrote:
Krzysztof Galazka wrote:
For IPv4 and IPv6 packets shorter than minimum Ethernet
frame payload, recvmsg returns lenght including padding.
nit: length
Use length from header for checksum verification to avoid
csum test failing on correct packets
From: Przemek Kitszel
Date: Tue, 27 Aug 2024 08:58:33 +0200
> On 8/26/24 19:14, Christophe JAILLET wrote:
>> Le 26/08/2024 à 11:15, Przemek Kitszel a écrit :
>>> On 8/23/24 11:10, Dan Carpenter wrote:
On Fri, Aug 23, 2024 at 08:23:29AM +0200, Christophe JAILLET wrote:
>
It would be eve
From: Michal Michalik
Add specific functions and definitions for E830 devices to enable
PTP support.
E830 devices support direct write to GLTSYN_ registers without shadow
registers and 64 bit read of PHC time.
Enable PTM for E830 device, which is required for cross timestamp and
and dependency
Unify ice_ptp_init_tx_* functions for most of the MAC types except E82X.
This simplifies the code for the future use with new MAC types.
Reviewed-by: Przemek Kitszel
Signed-off-by: Karol Kolacinski
---
V7 -> V8: Renamed the patch and reworded the commit message
drivers/net/ethernet/intel/ice/ic
From: Jacob Keller
Devices supported by ice driver use essentially the same logic for
performing a crosstimestamp. The only difference is that E830 hardware
has different offsets. Instead of having multiple implementations,
combine them into a single ice_capture_crosststamp() function.
To suppor
Instead of using shifts and casts, use FIELD_PREP after reading 40b
timestamp values.
Reviewed-by: Simon Horman
Signed-off-by: Karol Kolacinski
---
V5 -> V6: Replaced removed macros with the new ones
drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 9 ++---
drivers/net/ethernet/intel/ice/ice
Simplify TSYN IRQ processing by moving it to a separate function and
having appropriate behavior per PHY model, instead of multiple
conditions not related to HW, but to specific timestamping modes.
When PTP is not enabled in the kernel, don't process timestamps and
return IRQ_HANDLED.
Reviewed-by
Remove unnecessary ice_is_e8xx() functions and PHY model. Instead, use
MAC type where applicable.
Don't check device type in ice_ptp_maybe_trigger_tx_interrupt(), because
in reality it depends on the ready bitmap, which only E810 does not
have.
Call ice_ptp_cfg_phy_interrupt() unconditionally, be
Don't check if the device type is E810T as non-E810T devices can support
GNSS too and PCA9575 check is enough to determine if GNSS is present or
not.
Rename ice_gnss_is_gps_present() to ice_gnss_is_module_present()
because GNSS module supports multiple GNSS providers, not only GPS.
Move functions
Add specific functions and definitions for E830 devices to enable
PTP support.
Refactor processing of timestamping interrupt, cross timestamping, and
remove usage of ice_is_e8xx() functions to avoid code redundancy.
Refactor GNSS presence check to be able to remove ice_is_e8xx()
functions.
Jacob
On Fri, Aug 23, 2024 at 10:15PM +0200, Simon Horman wrote:
>> diff --git a/drivers/net/ethernet/intel/ice/ice_gnss.c
>> b/drivers/net/ethernet/intel/ice/ice_gnss.c
>> index f02e8ca55375..dd65b2db9856 100644
>> --- a/drivers/net/ethernet/intel/ice/ice_gnss.c
>> +++ b/drivers/net/ethernet/intel/ice/
On 21.08.2024 16:20, Alexander Lobakin wrote:
> From: Wojciech Drewek
> Date: Wed, 21 Aug 2024 14:15:31 +0200
>
>> From: Jacob Keller
>>
>> Add the iavf_ptp.c file and fill it in with a skeleton framework to
>> allow registering the PTP clock device.
>> Add implementation of helper functions
On 8/27/24 09:16, Thomas Bogendoerfer wrote:
For PFs, which don't support SRIOV_LAG, there is no pf->lag struct
allocated. So before accessing pf->lag a NULL pointer check is needed.
Fixes: 1e0f9881ef79 ("ice: Flesh out implementation of support for SRIOV on bonded
interface")
Signed-off-by: Th
Tue, Aug 27, 2024 at 09:16:02AM CEST, tbogendoer...@suse.de wrote:
>For PFs, which don't support SRIOV_LAG, there is no pf->lag struct
>allocated. So before accessing pf->lag a NULL pointer check is needed.
>
>Fixes: 1e0f9881ef79 ("ice: Flesh out implementation of support for SRIOV on
>bonded inte
On 8/26/24 12:17, Thomas Bogendoerfer wrote:
On Mon, 26 Aug 2024 11:41:19 +0200
Jiri Pirko wrote:
Mon, Aug 26, 2024 at 10:58:30AM CEST, tbogendoer...@suse.de wrote:
For PFs, which don't support SRIOV_LAG, there is no pf->lag struct
allocated. So before accessing pf->lag a NULL pointer check i
For PFs, which don't support SRIOV_LAG, there is no pf->lag struct
allocated. So before accessing pf->lag a NULL pointer check is needed.
Fixes: 1e0f9881ef79 ("ice: Flesh out implementation of support for SRIOV on
bonded interface")
Signed-off-by: Thomas Bogendoerfer
---
v2:
- Added Fixes tag
v
38 matches
Mail list logo
