> -Original Message-
> From: Dave Ertman
> Sent: Wednesday, September 18, 2024 11:03 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Kitszel, Przemyslaw
> Subject: [PATCH iwl-net] ice: fix VLAN replay after reset
>
> There is a bug currently when there are more
There is a bug currently when there are more than one VLAN defined
and any reset that affects the PF is initiated, after the reset rebuild
no traffic will pass on any VLAN but the last one created.
This is caused by the iteration though the VLANs during replay each
clearing the vsi_map bitmap of t
Make e1000e compatible with the newly added netdev-genl APIs.
$ cat /proc/interrupts | grep ens | cut -f1 --delimiter=':'
50
51
52
While e1000e allocates 3 IRQs (RX, TX, and other), it looks like e1000e
only has a single NAPI, so I've associated the NAPI with the RX IRQ (50
on my system, seen
Hi Yunsheng,
Thanks for looking into this!
On Wed, 18 Sept 2024 at 14:24, Yunsheng Lin wrote:
>
> Networking driver with page_pool support may hand over page
> still with dma mapping to network stack and try to reuse that
> page after network stack is done with it and passes it back
> to page_po
Networking driver with page_pool support may hand over page
still with dma mapping to network stack and try to reuse that
page after network stack is done with it and passes it back
to page_pool to avoid the penalty of dma mapping/unmapping.
With all the caching in the network stack, some pages may
Patch 1 fix a possible time window problem for page_pool.
Patch 2 fix the kernel crash problem at iommu_get_dma_domain
reported in [1].
When page_pool_put_unrefed_netmem() is called with allow_direct
being true, there is added checking overhead introduced in patch
1, which seem to be no noticeable
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Przemek Kitszel
> Sent: Tuesday, September 10, 2024 7:27 PM
> To: intel-wired-...@lists.osuosl.org; Nguyen, Anthony L
>
> Cc: Pucha, HimasekharX Reddy ; Zaremba,
> Larysa ; net...@vger.kernel.org; Polchlopek,
> Mateusz ; Kell
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
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
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
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/i
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
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
allnoconfiggcc-13.2.0
arc allyesconfiggcc-13.2.0
arc randconfig-001-20240918gcc-13.2.0
arc randconfig-002-20240918gcc-13.2.0
arm allnoconfigclang-20
arm
16 matches
Mail list logo