Currently the user may request DPLL_PIN_STATE_SELECTABLE for an output
pin, and this would actually set the DISCONNECTED state instead.
It doesn't make any sense. SELECTABLE is valid only in case of input pins
(on AUTOMATIC type dpll), where dpll itself would select best valid input.
For the outpu
>From: Paul Menzel
>Sent: Wednesday, September 11, 2024 8:22 AM
>
>Dear Arkadiusz,
>
>
>Thank you for your patch. It’d be great if you made the summary more
>explicit. For example:
>
>ice: Disallow DPLL_PIN_STATE_SELECTABLE for dpll output pins
>
>Am 11.09.24 um 01:28 schrieb Arkadiusz Kubalewski:
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
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
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
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
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
>From: Paul Menzel
>Sent: Wednesday, September 11, 2024 8:41 AM
>
>Dear Arkadiusz,
>
>
>Thank you for your patch. It’d be great if you used a more specific
>summary. Maybe:
>
>ice: Allow full frequency range of 1 Hz–25 MHz for dpll pins
>
>Some more nits below:
>
>Am 11.09.24 um 01:29 schrieb Arka
14.1.0
arc allmodconfig clang-20
arc allnoconfig gcc-14.1.0
arc allyesconfig clang-20
arc defconfig gcc-14.1.0
arc randconfig-001-20240912 gcc-
allmodconfigclang-20
arc allnoconfiggcc-14.1.0
arc allyesconfigclang-20
arc defconfiggcc-14.1.0
arc randconfig-001-20240912gcc-13.2.0
arc randconfig-002
-20
arc allnoconfiggcc-14.1.0
arc allyesconfigclang-20
arc defconfiggcc-14.1.0
arc randconfig-001-20240912gcc-13.2.0
arc randconfig-002-20240912gcc-13.2.0
Patch 1 fix a possible time window problem for pagw_pool.
Patch 2 fix the kernel crash problem at iommu_get_dma_domain
reported in [1].
1.
https://lore.kernel.org/lkml/8067f204-1380-4d37-8ffd-007fc6f26...@kernel.org/T/
CC: Alexander Lobakin
CC: Robin Murphy
CC: Alexander Duyck
CC: IOMMU
Yun
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
On Thu, Sep 12, 2024 at 5:51 AM 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_pool to avoid the penalty of dma mapping/unmap
Hi again
It just happened again.
Same error message, but different stacktrace:
[ 7739.335650] igc :0c:00.0 eno1: PCIe link lost, device now detached
[ 7739.335656] [ cut here ]
[ 7739.335657] igc: Failed to read reg 0xc030!
[ 7739.335675] WARNING: CPU: 8 PID: 274 at
dr
Hi there
Over the past couple of months I've occasionally observed my machine
loosing its ethernet connection.
It usually only happens after I've been using the machine for a couple
of hours and it only happens around 3-4 times per month.
Every time (previously) I've just rebooted the machine and
On Thu, 12 Sep 2024 15:03:14 +0200 Jesper Juhl wrote:
> It just happened again.
> Same error message, but different stacktrace:
Hm, I wonder if it's power management related or the device just goes
sideways for other reasons. The crashes are in accessing statistics
and the relevant function doesn'
> Would you be able to decode the stack trace? It may be helpful
> to figure out which line of code this is:
>
> igc_update_stats+0x8a/0x6d0 [igc
> 22e0a697bfd5a86bd5c20d279bfffd
> 131de6bb32]
Of course. Just tell me what to do.
- Jesper
On Thu, 12 Sept 2024 at 17:37, Jakub Kicinski wrote:
>
>
On Thu, 12 Sep 2024 21:45:17 +0200 Jesper Juhl wrote:
> > Would you be able to decode the stack trace? It may be helpful
> > to figure out which line of code this is:
> >
> > igc_update_stats+0x8a/0x6d0 [igc
> > 22e0a697bfd5a86bd5c20d279bfffd
> > 131de6bb32]
>
> Of course. Just tell me what to
22 matches
Mail list logo
