tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git 200GbE
branch HEAD: 9eaff63bfb59b93a79ac8450e3d1e45a1f72f29a Merge branch
'net-ethernet-ti-am65-cpsw-fixes-to-multi-queue-rx-feature'
elapsed time: 935m
configs tested: 212
configs skipped: 7
The following config
On Wed, 6 Nov 2024 02:07:55 +0100 Arkadiusz Kubalewski wrote:
> +What:/sys/class/ptp/ptp/ts_point
> +Date:October 2024
> +Contact: Arkadiusz Kubalewski
> +Description:
> + This file provides control over the point in time in
> + which th
On Mon, 4 Nov 2024 09:40:50 -0300 Wander Lairson Costa wrote:
> This reverts commit 338c4d3902feb5be49bfda530a72c7ab860e2c9f.
>
> Sebastian noticed the ISR indirectly acquires spin_locks, which are
> sleeping locks under PREEMPT_RT, which leads to kernel splats.
>
> Signed-off-by: Wander Lairson
>From: Kitszel, Przemyslaw
>Sent: Tuesday, October 29, 2024 9:22 AM
>
>On 10/28/24 21:47, Arkadiusz Kubalewski wrote:
>> Allow user to control the latch point of ptp HW timestamps in E825
>
>sometimes you write ptp, sometimes PTP, I would make it consistent
>(but subject line is fine as is)
>
>> d
>From: Kitszel, Przemyslaw
>Sent: Tuesday, October 29, 2024 9:25 AM
>Subject: Re: [PATCH net-next v2 1/2] ptp: add control over HW timestamp
>latch point
>
>On 10/28/24 21:47, Arkadiusz Kubalewski wrote:
>> Currently HW support of PTP/timesync solutions in network PHY chips
>> can be implemented w
>From: Intel-wired-lan On Behalf Of
>Vadim Fedorenko
>Sent: Tuesday, October 29, 2024 5:17 PM
>
>On 29/10/2024 15:56, Kubalewski, Arkadiusz wrote:
>>> From: Vadim Fedorenko
>>> Sent: Tuesday, October 29, 2024 12:30 PM
>>>
>>> On 28/10/2024 20:47, Arkadiusz Kubalewski wrote:
HW support of PTP
Allow user to control the latch point of ptp HW timestamps in E825
devices.
Usage, examples:
** Obtain current state:
$ cat /sys/class/net/eth/device/ptp/ts_point
Command returns enum/integer:
* 1 - timestamp latched by PHY at the beginning of SFD,
* 2 - timestamp latched by PHY after the SFD,
*
Currently HW support of ptp/timesync solutions in network PHY chips can be
implemented with two different approaches, the timestamp maybe latched
either at the beginning or after the Start of Frame Delimiter (SFD) [1].
Allow ptp device drivers to provide user with control over the HW
timestamp lat
HW support of ptp/timesync solutions in network PHY chips can be
achieved with two different approaches, the timestamp maybe latched
either in the beginning or after the Start of Frame Delimiter (SFD) [1].
Allow ptp device drivers to provide user with control over the timestamp
latch point.
[1] h
gcc-13.2.0
arc allyesconfiggcc-13.2.0
archsdk_defconfiggcc-13.2.0
arc randconfig-001-20241105gcc-13.2.0
arc randconfig-002-20241105gcc-13.2.0
arm allmodconfig
On 11/1/2024 11:53 PM, Paul Menzel wrote:
> Dear Jacob,
>
>
> Thank you for the patch.
>
> Am 02.11.24 um 00:05 schrieb Jacob Keller:
>> The ixgbe PF driver logs an info message when a VF attempts to negotiate an
>> API version which it does not support:
>>
>>VF 0 requested invalid api ve
On 11/1/2024 4:05 PM, Jacob Keller wrote:
> The ixgbe PF driver logs an info message when a VF attempts to negotiate an
> API version which it does not support:
>
> VF 0 requested invalid api version 6
>
> The ixgbevf driver attempts to load with mailbox API v1.5, which is
> required for bes
On 11/1/2024 4:05 PM, Jacob Keller wrote:
> Commit 339f28964147 ("ixgbevf: Add support for new mailbox communication
> between PF and VF") added support for v1.5 of the PF to VF mailbox
> communication API. This commit mistakenly enabled IPSEC offload for API
> v1.5.
>
> No implementation of th
> -Original Message-
> From: Michal Swiatkowski
> Sent: Monday, November 4, 2024 3:25 AM
> To: Paul Menzel
> Cc: David Laight ; Drewek, Wojciech
> ; Szycik, Marcin ;
> net...@vger.kernel.org; Knitter, Konrad ;
> Chmielewski, Pawel ; ho...@kernel.org; intel-
> wired-...@lists.osuosl.org
> -Original Message-
> From: Paul Menzel
> Sent: Friday, November 1, 2024 11:54 PM
> To: Keller, Jacob E
> Cc: intel-wired-...@lists.osuosl.org; Yifei Liu ;
> Kitszel,
> Przemyslaw
> Subject: Re: [Intel-wired-lan] [PATCH iwl-net 2/2] ixgbe: downgrade logging of
> unsupported VF API ve
Hi Paul and Jake,
Please see inline.
> On Nov 1, 2024, at 11:53 PM, Paul Menzel wrote:
>
> Dear Jacob,
>
>
> Thank you for the patch.
>
> Am 02.11.24 um 00:05 schrieb Jacob Keller:
>> The ixgbe PF driver logs an info message when a VF attempts to negotiate an
>> API version which it does no
From: Ahmed Zaki
Add lock class key changes to prevent lockdep from complaining
when PF reset the VFs.
Signed-off-by: Ahmed Zaki
Reviewed-by: Przemek Kitszel
Reviewed-by: Madhu Chittim
Signed-off-by: Tarun K Singh
---
drivers/net/ethernet/intel/idpf/idpf_main.c | 32 +
1
Rename 'vport_ctrl_lock' to 'vport_cfg_lock'. Rename related
functions name for lock and unlock.
Reviewed-by: Przemek Kitszel
Signed-off-by: Tarun K Singh
---
drivers/net/ethernet/intel/idpf/idpf.h| 16 +++
.../net/ethernet/intel/idpf/idpf_ethtool.c| 46 +--
driv
Change idpf_vport_ctrl_lock's argument from netdev to adapter.
Reviewed-by: Przemek Kitszel
Signed-off-by: Tarun K Singh
---
drivers/net/ethernet/intel/idpf/idpf.h| 16 ++---
.../net/ethernet/intel/idpf/idpf_ethtool.c| 59 ++-
drivers/net/ethernet/intel/idpf/idpf_lib
Add new 'vport_init_lock' to prevent locking issue.
The existing 'vport_cfg_lock' was controlling the vport initialization,
re-initialization due to reset, and de-initialization of code flow.
In addition to controlling the above behavior it was also controlling
the parallel netdevice calls such as
This series fix deadlock issues in the driver. The first patch changes
argument of function 'idpf_vport_ctrl_lock' to adapter. The second patch
renames 'vport_ctrl_lock' to 'vport_cfg_lock'. The first 2 patches make the
third patch easier to review. The third patch fixes the locking issue,
and the
: powerpc64-randconfig-r071-20241104
(https://download.01.org/0day-ci/archive/20241105/202411052110.vjxfpzue-...@intel.com/config)
compiler: clang version 20.0.0git (https://github.com/llvm/llvm-project
639a7ac648f1e50ccd2556e17d401c04f9cce625)
If you fix the issue in a separate patch/commit (i.e
://download.01.org/0day-ci/archive/20241105/202411052110.vjxfpzue-...@intel.com/config)
compiler: clang version 20.0.0git (https://github.com/llvm/llvm-project
639a7ac648f1e50ccd2556e17d401c04f9cce625)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch
From: Ahmed Zaki
commit 6ebbe97a488179f5dc85f2f1e0c89b486e99ee97 upstream.
While the iavf driver adds a s/w limit (128) on the number of FDIR
filters that the VF can request, a malicious VF driver can request more
than that and exhaust the resources for other VFs.
Add a similar limit in ice.
C
ror/Warning ids grouped by kconfigs:
recent_errors
`-- parisc-randconfig-001-20241105
|--
drivers-net-ethernet-intel-iavf-iavf_txrx.c:(.text):undefined-reference-to-iavf_ptp_extend_32b_timestamp
|--
drivers-net-ethernet-intel-iavf-iavf_virtchnl.c:(.text):undefined-reference-to-iavf_ptp_cap_supp
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Konrad Knitter
> Sent: 23 October 2024 15:37
> To: intel-wired-...@lists.osuosl.org
> Cc: Keller, Jacob E ; net...@vger.kernel.org;
> j...@resnulli.us; da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Konrad Knitter
> Sent: 23 October 2024 15:37
> To: intel-wired-...@lists.osuosl.org
> Cc: Keller, Jacob E ; net...@vger.kernel.org;
> j...@resnulli.us; da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Konrad Knitter
> Sent: 23 October 2024 15:37
> To: intel-wired-...@lists.osuosl.org
> Cc: Keller, Jacob E ; net...@vger.kernel.org;
> j...@resnulli.us; da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.
From: Karol Kolacinski
Driver always naively assumes, that for PTP purposes, PHY lane to
configure is corresponding to PF ID.
This is not true for some port configurations, e.g.:
- 2x50G per quad, where lanes used are 0 and 2 on each quad, but PF IDs
are 0 and 1
- 100G per quad on 2 quads, whe
From: Karol Kolacinski
Fix ETH56G FC-FEC incorrect Rx offset value by changing it from -255.96
to -469.26 ns.
Those values are derived from HW spec and reflect internal delays.
Hex value is a fixed point representation in Q23.9 format.
Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E
From: Karol Kolacinski
Quad registers are read/written incorrectly. E825 devices always use
quad 0 address and differentiate between the PHYs by changing SBQ
destination device (phy_0 or phy_0_peer).
Add helpers for reading/writing PTP registers shared per quad and use
correct quad address and S
From: Karol Kolacinski
Current implementation checks revision of all PHYs on all PFs, which is
incorrect and may result in initialization failure. Check only the
revision of the current PHY.
Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products")
Reviewed-by: Arkadiusz Kubalew
E825 products have incorrect initialization procedure, which may lead to
initialization failures and register values.
Fix E825 products initialization by adding correct sync delay, checking
the PHY revision only for current PHY and adding proper destination
device when reading port/quad.
In addit
allyesconfiggcc-13.2.0
arcdefconfiggcc-14.1.0
arc nsim_700_defconfiggcc-14.1.0
arc randconfig-001-20241105gcc-13.2.0
arc randconfig-002-20241105gcc-13.2.0
arc vdk_hs38_smp_defconfiggcc-14.1.0
arm
34 matches
Mail list logo
