> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Marcin Szycik
> Sent: Tuesday, April 23, 2024 8:07 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Marcin Szycik ;
> Drewek, Wojciech ; Michal Swiatkowski
>
> Subject: [Intel-wired-lan] [PATCH iwl-next] ic
> -Original Message-
> From: Intel-wired-lan On Behalf Of Jacob
> Keller
> Sent: Saturday, April 27, 2024 4:17 AM
> To: Intel Wired LAN
> Cc: Keller, Jacob E ; Michal Swiatkowski
>
> Subject: [Intel-wired-lan] [PATCH iwl-next] ice: add and use roundup_u64
> instead of open coding equi
allnoconfig gcc
i386 allyesconfig gcc
i386 buildonly-randconfig-001-20240507 clang
i386 buildonly-randconfig-002-20240507 clang
i386 buildonly-randconfig-003-20240507 clang
i386 buildonly-randconfig-004-20240507 gcc
> Why so long?
> Furthermore, if I am reading this right, it appears that, with the
> proposed change, e1000e_phy_has_link_generic will poll the PHY link up
> to 10 times, with 100ms delay between each iteration - until the link is
> up. Won't it lead to wasting all this time, if the link is actua
On 4/23/2024 13:24, Corinna Vinschen wrote:
During successful probe, igc logs this:
[5.133667] igc :01:00.0 (unnamed net_device) (uninitialized): PHC added
The reason is that igc_ptp_init() is called very early, even b
> Why PHY is this?
It's the Intel I219-LM, and I haven't found any other device having
the same issue.
> It might be the PHY manufacture has an errata, since
> this is probably not the MAC causing the problem, but the PHY itself.
Yes. The problem seems to be a PHY problem. I'm wondering if doing a
i386 allnoconfig gcc
i386 allyesconfig gcc
i386 buildonly-randconfig-001-20240507 clang
i386 buildonly-randconfig-002-20240507 clang
i386 buildonly-randconfig-003-20240507 clang
i386 buildonly
Hi,
Currently ice driver does not allow creating more than one networking
device per physical function. The only way to have more hardware backed
netdev is to use SR-IOV.
Following patchset adds support for devlink port API. For each new
pcisf type port, driver allocates new VSI, configures all r
From: Piotr Raczynski
Add required plumbing for new VSI type dedicated to devlink subfunctions.
Make sure that the vsi is properly configured and destroyed. Also allow
loading XDP and AF_XDP sockets.
The first implementation of devlink subfunctions supports only one Tx/Rx
queue pair per given su
From: Piotr Raczynski
Make some of the netdevice_ops functions visible from outside for
another VSI type created netdev.
Reviewed-by: Przemek Kitszel
Reviewed-by: Wojciech Drewek
Signed-off-by: Piotr Raczynski
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/ice.h |
From: Piotr Raczynski
Implement devlink port handlers responsible for ethernet type devlink
subfunctions. Create subfunction devlink port and setup all resources
needed for a subfunction netdev to operate. Configure new VSI for each
new subfunction, initialize and configure interrupts and Tx/Rx r
When subfunction VSI is open the same code as for PF VSI should be
executed. Also when up is complete. Reflect that in code by adding
subfunction VSI to consideration.
In case of stopping, PF doesn't have additional tasks, so the same
is with subfunction VSI.
Signed-off-by: Michal Swiatkowski
--
From: Piotr Raczynski
Make devlink allocation function generic to use it for PF and for SF.
Add function for SF devlink port creation. It will be used in next
patch.
Create header file for subfunction device. Define subfunction device
structure there as it is needed for devlink allocation and p
From: Piotr Raczynski
Implement subfunction driver. It is probe when subfunction port is
activated.
VSI is already created. During the probe VSI is being configured.
MAC unicast and broadcast filter is added to allow traffic to pass.
Store subfunction pointer in VSI struct. The same is done for
From: Piotr Raczynski
Configure netdevice for subfunction usecase. Mostly it is reusing ops
from the PF netdevice.
SF netdev is linked to devlink port registered after SF activation.
Reviewed-by: Jiri Pirko
Signed-off-by: Piotr Raczynski
Signed-off-by: Michal Swiatkowski
---
drivers/net/eth
Store subfunction and VF pointer in port representor structure as an
union. Add port representor type to distinguish between each of them.
Keep the same flow of port representor creation, but instead of general
attach function create helpers for VF and subfunction attach function.
Type of port re
Add check for subfunction before setting target VSI. It is needed for PF
in switchdev mode but not for subfunction (even in switchdev mode).
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/ice_txrx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
Now there is another type of port representor. Correct checking if
parent device is ready to reflect also new PR type.
Reviewed-by: Wojciech Drewek
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/ice_ethtool.c | 7 +++
drivers/net/ethernet/intel/ice/ice_repr.c| 12
Subfunction port representor needs the basic netdevice ops to work
correctly. Create them.
Reviewed-by: Wojciech Drewek
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/ice_repr.c | 57 +--
1 file changed, 43 insertions(+), 14 deletions(-)
diff --git a/d
Flow for creating Tx topology is the same as for VF port representors,
but the devlink port is stored in different place (sf->devlink_port).
When creating VF devlink lock isn't taken, when creating subfunction it
is. Setting Tx topology function needs to take this lock, check if it
was taken befor
Implement add / delete vlan for subfunction type VSI.
Reviewed-by: Wojciech Drewek
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/Makefile | 1 +
.../ethernet/intel/ice/ice_sf_vsi_vlan_ops.c | 21 +++
.../ethernet/intel/ice/ice_sf_vsi_vlan_ops.h |
From: Piotr Raczynski
Use previously implemented SF aux driver. It is probe during SF
activation and remove after deactivation.
Signed-off-by: Piotr Raczynski
Signed-off-by: Michal Swiatkowski
---
.../ethernet/intel/ice/devlink/devlink_port.c | 108 ++
.../ethernet/intel/ice/d
On Tue, May 07, 2024 at 11:24:05AM +0200, En-Wei WU wrote:
> > Why PHY is this?
> It's the Intel I219-LM, and I haven't found any other device having
> the same issue.
There is no Linux PHY driver for this device, only the code buried in
the e1000e MAC driver. Sometimes Intel use Marvell PHYs, and
> > (1) How serious this problem is. It is normal for link establishment to
> > take a few seconds from plugging the cable (due to PHY
> > auto-negotiation), and I can accept some link instability during that time.
> Actually, the problem is not critical since the link will be up
> permanently afte
On Fri, May 03, 2024 at 06:18:36PM +0800, Ricky Wu wrote:
> As described in https://bugzilla.kernel.org/show_bug.cgi?id=218642,
> Intel I219-LM reports link up -> link down -> link up after hot-plugging
> the Ethernet cable.
Please could you quote some parts of 802.3 which state this is a
problem.
Bui,
> Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from
> userspace to that buffer. Later, we use sscanf on this buffer but we don't
> ensure that the string is terminated inside the buffer, this can lead to
> OOB read when using sscanf. Fix this issue by using memdup_use
Bui,
> Currently, we allocate a count-sized kernel buffer and copy count from
> userspace to that buffer. Later, we use kstrtouint on this buffer but we
> don't ensure that the string is terminated inside the buffer, this can
> lead to OOB read when using kstrtouint. Fix this issue by using
> me
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240507 gcc
arc randconfig-002-20240507 gcc
arc
allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240507 gcc
arc randconfig-002-20240507 gcc
arm
allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240507 gcc
arc randconfig-002-20240507 gcc
arm
On 07/05/2024 15:10, Andrew Lunn wrote:
On Tue, May 07, 2024 at 11:24:05AM +0200, En-Wei WU wrote:
Why PHY is this?
It's the Intel I219-LM, and I haven't found any other device having
the same issue.
There is no Linux PHY driver for this device, only the code buried in
the e1000e MAC driver.
On 07/05/2024 15:31, Andrew Lunn wrote:
On Fri, May 03, 2024 at 06:18:36PM +0800, Ricky Wu wrote:
As described in https://bugzilla.kernel.org/show_bug.cgi?id=218642,
Intel I219-LM reports link up -> link down -> link up after hot-plugging
the Ethernet cable.
Please could you quote some parts o
32 matches
Mail list logo
