On Mon, Mar 10, 2025 at 03:16:36PM -0700, Jacob Keller wrote:
> The igb_ptp_feature_enable_82580 function correctly checks that unknown
> flags are not passed to the function. However, it does not actually check
> PTP_RISING_EDGE or PTP_FALLING_EDGE when configuring the external timestamp
> functio
From: Karol Kolacinski
Rename ice_sbq_msg_dev to ice_sbq_dev_id to reflect the meaning of this
type more precisely. This enum type describes RDA (Remote Device Access)
client ids, accessible over SB (Side Band) interface.
Rename enum elements to make a driver namespace more cleaner and
consistent
When the device sends a specific input, an integer underflow can occur, leading
to MMIO write access to an invalid page.
Prevent the integer underflow by changing the type of related variables.
Signed-off-by: Kyungwook Boo
Link:
https://lore.kernel.org/lkml/ffc91764-1142-4ba2-91b6-8c773f6f7...@
On 3/9/2025 11:22 PM, Simon Horman wrote:
On Thu, Mar 06, 2025 at 04:39:56PM -0800, Emil Tantilov wrote:
Driver calls idpf_remove() from idpf_shutdown(), which can end up
calling idpf_remove() again when disabling SRIOV.
echo 1 > /sys/class/net//device/sriov_numvfs
reboot
BUG: kernel NULL poin
On 3/6/2025 9:58 PM, Michal Swiatkowski wrote:
On Thu, Mar 06, 2025 at 04:39:56PM -0800, Emil Tantilov wrote:
Driver calls idpf_remove() from idpf_shutdown(), which can end up
calling idpf_remove() again when disabling SRIOV.
The same is done in other drivers (ice, iavf). Why here it is a
> -Original Message-
> From: Song, Yoong Siang
> Sent: Friday, March 7, 2025 3:21 PM
>
> On Friday, March 7, 2025 9:25 PM, Bouska, Zdenek
> wrote:
>
> [...]
>
> >> @@ -2996,7 +3035,13 @@ static void igc_xdp_xmit_zc(struct igc_ring *ring)
> >>ntu = ring->next_to_use;
> >>budget
Subject: Re: [PATCH iwl-next] ice: use DSN instead of PCI BDF for ice_adapter
index
regarding -net vs -next, no one have complained that this bug hurts
+ return (unsigned long)pci_get_dsn(pdev);
How do you ensure there is no xarray index collision then you cut the number
like this?
On 10/03/2025 22:16, Jacob Keller wrote:
The ptp_ocp_signal_from_perout() function supports PTP_PEROUT_DUTY_CYCLE
and PTP_PEROUT_PHASE. It does not support PTP_PEROUT_ONE_SHOT, but does not
reject a request with such an unsupported flag.
Add the appropriate check to ensure that unsupported reque
Rename TSPLL and CGU functions, definitions etc. to match the file name
and have constistent naming scheme.
Reviewed-by: Michal Kubiak
Reviewed-by: Milena Olech
Signed-off-by: Karol Kolacinski
---
drivers/net/ethernet/intel/ice/ice_common.c | 28 +-
drivers/net/ethernet/intel/ice/ice_common
Collect TSPLL related functions and definitions and move them to
a separate file to have all TSPLL functionality in one place.
Move CGU related functions and definitions to ice_common.*
Reviewed-by: Michal Kubiak
Reviewed-by: Milena Olech
Signed-off-by: Karol Kolacinski
---
drivers/net/ethern
Add helpers for checking TSPLL params, disabling sticky bits,
configuring TSPLL and getting default clock frequency to simplify
the code flows.
Reviewed-by: Milena Olech
Signed-off-by: Karol Kolacinski
---
drivers/net/ethernet/intel/ice/ice_tspll.c | 152 ++---
1 file changed, 1
Instead of multiple comments, use designated initializers for TSPLL
consts.
Adjust ice_tspll_params_e82x fields sizes.
Remove ice_tspll_params_e825 definitions as according to EDS (Electrical
Design Specification) doc, E825 devices support only 156.25 MHz TSPLL
frequency for both TCXO and TIME_RE
Add a helper function to print new/current TSPLL config. This helps
avoid unnecessary casts from u8 to enums.
Reviewed-by: Michal Kubiak
Reviewed-by: Milena Olech
Signed-off-by: Karol Kolacinski
---
drivers/net/ethernet/intel/ice/ice_tspll.c | 54 --
1 file changed, 30 inse
To ensure proper operation, wait for 10 to 20 microseconds before
enabling TSPLL.
Adjust wait time after enabling TSPLL from 1-5 ms to 1-2 ms.
Those values are empirical and tested on multiple HW configurations.
Reviewed-by: Milena Olech
Signed-off-by: Karol Kolacinski
---
drivers/net/etherne
TSPLL can fail when trying to lock to TIME_REF as a clock source, e.g.
when the external clock source is not stable or connected to the board.
To continue operation after failure, try to lock again to internal TCXO
and inform user about this.
Reviewed-by: Milena Olech
Signed-off-by: Karol Kolacin
On Mon Mar 10 2025, Joe Damato wrote:
> On Fri, Mar 07, 2025 at 02:03:44PM -0800, Tony Nguyen wrote:
>> On 2/17/2025 3:31 AM, Kurt Kanzenbach wrote:
>>
>> ...
>>
>> > diff --git a/drivers/net/ethernet/intel/igb/igb_xsk.c
>> > b/drivers/net/ethernet/intel/igb/igb_xsk.c
>> > index
>> > 157d43787f
Initialize TSPLL after initializing PHC in ice_ptp.c instead of calling
for each product in PHC init in ice_ptp_hw.c.
Reviewed-by: Michal Kubiak
Reviewed-by: Milena Olech
Signed-off-by: Karol Kolacinski
---
drivers/net/ethernet/intel/ice/ice_ptp.c| 11 ++
drivers/net/ethernet/intel
Mon, Mar 10, 2025 at 09:40:16AM +0100, przemyslaw.kits...@intel.com wrote:
>> Subject: Re: [PATCH iwl-next] ice: use DSN instead of PCI BDF for
>> ice_adapter index
>
>regarding -net vs -next, no one have complained that this bug hurts
Wait, so we are now waiting for someone to hit the bug and co
From: Karol Kolacinski
According to the E825C specification, SBQ address for ports on a single
complex is device 2 for PHY 0 and device 13 for PHY1.
For accessing ports on a dual complex E825C (so called 2xNAC mode),
the driver should use destination device 2 (referred as phy_0) for
the current c
From: Karol Kolacinski
Due to the bug in FW/NVM autoload mechanism (wrong default
SB_REM_DEV_CTL register settings), the access to peer PHY and CGU
clients was disabled by default.
As the workaround solution, the register value was overwritten by the
driver at the probe or reset handling.
Remove
This patch series adds full support for timesync operations for E8225C
devices which are configured in so called 2xNAC mode (Network
Acceleration Complex). 2xNAC mode is the mode in which IO die
is housing two complexes and each of them has its own PHY connected
to it. The complex which controls ti
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Nitka, Grzegorz
> Sent: Tuesday, March 4, 2025 2:04 PM
> To: Paul Menzel ; Kolacinski, Karol
>
> Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; Kitszel,
> Przemyslaw ; Michal Swiatkowski
>
> Subject: Re: [Intel-wi
The igb_ptp_feature_enable_82580 function correctly checks that unknown
flags are not passed to the function. However, it does not actually check
PTP_RISING_EDGE or PTP_FALLING_EDGE when configuring the external timestamp
function.
The data sheet for the 82580 product says:
Upon a change in the
The lan743x_ptp_io_event_cap_en() function checks that the given request
sets only one of PTP_RISING_EDGE or PTP_FALLING_EDGE, but not both.
However, this driver does not check whether other flags (such as
PTP_EXT_OFF) are set, nor whether any future unrecognized flags are set.
Fix this by adding
In bcm_ptp_perout_locked, the driver rejects requests which have
PTP_PEROUT_PHASE set. This appears to be an attempt to reject any
unsupported flags. Unfortunately, this only checks one flag, but does not
protect against PTP_PEROUT_ONE_SHOT, or any future flags which may be
added.
Fix the check to
ommit: 992ee3ed6e9fdd0be83a7daa5ff738e3cf86047f
change-id: 20250310-jk-net-fixes-supported-extts-flags-e8434d8e2552
Best regards,
--
Jacob Keller
The ptp_ocp_signal_from_perout() function supports PTP_PEROUT_DUTY_CYCLE
and PTP_PEROUT_PHASE. It does not support PTP_PEROUT_ONE_SHOT, but does not
reject a request with such an unsupported flag.
Add the appropriate check to ensure that unsupported requests are rejected
both for PTP_PEROUT_ONE_SH
27 matches
Mail list logo
