On Wed, Feb 12, 2025 at 08:30:20PM +0200, Leon Romanovsky wrote:
> On Wed, Feb 12, 2025 at 12:56:48PM +0100, Steffen Klassert wrote:
> > On Wed, Feb 05, 2025 at 08:20:21PM +0200, Leon Romanovsky wrote:
> > > From: Leon Romanovsky
> > >
> > > SA replay mode is initialized differently for user-spac
The E610 adapters contain an embedded chip with firmware which can be
updated using devlink flash. The firmware which runs on this chip is
referred to as the Embedded Management Processor firmware (EMP
firmware).
Activating the new firmware image currently requires that the system be
rebooted. Thi
Introduce 2 E610 specific callbacks implementations:
-ixgbe_start_hw_e610() which expands the regular .start_hw callback with
getting FW version information
-ixgbe_read_pba_string_e610() which gets Product Board Assembly string
Extend EEPROM ops with new .read_pba_string in order to distinguish
ge
Add functions reading inactive versions from the inactive flash
banks.
Print stored NVM, OROM and netlist versions by devlink when there
is an ongoing update for E610 devices.
Reviewed-by: Mateusz Polchlopek
Reviewed-by: Przemek Kitszel
Co-developed-by: Slawomir Mrozowicz
Signed-off-by: Slawom
From: Karol Kolacinski
Add a description of PTP pins support by the adapters to ice driver
documentation.
Signed-off-by: Karol Kolacinski
---
v2:
- no change, updated series
---
.../device_drivers/ethernet/intel/ice.rst | 13 +
1 file changed, 13 insertions(+)
diff --git
DPLL-enabled E810 NIC driver provides user with list of input and output
pins. Hardware internal design impacts user control over SMA and U.FL
pins. Currently end-user view on those dpll pins doesn't provide any layer
of abstraction. On the hardware level SMA and U.FL pins are tied together
due to
From: Karol Kolacinski
This change aligns E810 PTP pin control to all other products.
Currently, SMA/U.FL port expanders are controlled together with SDP pins
connected to 1588 clock. To align this, separate this control by
exposing only SDP20..23 pins in PTP API on adapters with DPLL.
Clear er
Previously control of the dpll SMA/U.FL pins was partially done through
ptp API, decouple pins control from both interfaces (dpll and ptp).
Allow the SMA/U.FL pins control over a dpll subsystem, and leave ptp
related SDP pins control over a ptp subsystem.
Arkadiusz Kubalewski (1):
ice: redesign
Currently iwdev->rf is allocated in irdma_probe(), but free in
irdma_ib_dealloc_device(). It can be misleading. Move the free to
irdma_remove() to be more obvious.
Freeing in irdma_ib_dealloc_device() leads to KASAN use-after-free
issue. Which can also lead to NULL pointer dereference. Fix this.
E610 devices give possibility to show more detailed info than the previous
boards.
Extend reporting NVM info with following pieces:
fw.mgmt.api -> version number of the API
fw.mgmt.build -> identifier of the source for the FW
fw.psid.api -> version defining the format of the flash contents
fw.n
From: Slawomir Mrozowicz
Add functions reading the OROM version info and use them
as a part of the setting NVM info procedure.
Reviewed-by: Mateusz Polchlopek
Reviewed-by: Przemek Kitszel
Signed-off-by: Slawomir Mrozowicz
Co-developed-by: Piotr Kwapulinski
Signed-off-by: Piotr Kwapulinski
S
From: Slawomir Mrozowicz
Add functions reading the netlist version info and use them
as a part of the setting NVM info procedure.
Reviewed-by: Mateusz Polchlopek
Signed-off-by: Slawomir Mrozowicz
Co-developed-by: Piotr Kwapulinski
Signed-off-by: Piotr Kwapulinski
Signed-off-by: Jedrzej Jagie
On Fri, 14 Feb 2025 15:23:29 +0100 Arkadiusz Kubalewski wrote:
> Previously control of the dpll SMA/U.FL pins was partially done through
> ptp API, decouple pins control from both interfaces (dpll and ptp).
> Allow the SMA/U.FL pins control over a dpll subsystem, and leave ptp
> related SDP pins co
On Fri Feb 14 2025, Abdul Rahim, Faizal wrote:
> On 14/2/2025 3:12 am, Kurt Kanzenbach wrote:
>> On Thu Feb 13 2025, Vladimir Oltean wrote:
>>> So, confusingly to me, it seems like one operating mode is fundamentally
>>> different from the other, and something will have to change if both will
>>> b
tc clsact qdisc allows us to add offloaded egress rules with commands such
as the following one:
tc filter add dev egress protocol lldp flower skip_sw action drop
Support the egress rule drop action when added to PF, with a few caveats:
* in switchdev mode, all PF traffic has to go uplink with a
Only a single VSI can be in charge of sending LLDP frames, sometimes it is
beneficial to assign this function to a VF, that is possible to do with tc
capabilities in the switchdev mode. It requires first blocking the PF from
sending the LLDP frames with a following command:
tc filter add dev egre
Allow to:
* receive LLDP packets on a VF in legacy mode
* receive LLDP packets on a VF in switchdev mode
* transmit LLDP from a VF in switchdev mode
Many VSIs can receive LLDP packets, but only one VSI
per port can transmit LLDP, therefore LLDP TX from VF
requires adding an egress drop rule to the
From: Mateusz Pacuszka
When a trusted VF tries to configure an LLDP multicast address, configure a
rule that would mirror the traffic to this VF, untrusted VFs are not
allowed to receive LLDP at all, so the request to add LLDP MAC address will
always fail for them.
Add a forwarding LLDP filter t
Commit 34295a3696fb ("ice: implement new LLDP filter command")
introduced the ability to use LLDP-specific filter that directs all
LLDP traffic to a single VSI. However, current goal is for all trusted VFs
to be able to see LLDP neighbors, which is impossible to do with the
special filter.
Make us
From: Mateusz Pacuszka
In case the rule already exists and another VSI wants to subscribe to it
new VSI list is being created and both VSIs are moved to it.
Currently, the check for already existing VSI with the same rule is done
based on fdw_id.hw_vsi_id, which applies only to LOOKUP_RX flag.
Ch
On Wed, Feb 12, 2025 at 01:36:18PM -0800, Tony Nguyen wrote:
>
>
> On 2/8/2025 5:22 AM, Larysa Zaremba wrote:
>
> ...
>
> > @@ -8393,20 +8395,42 @@ ice_setup_tc_cls_flower(struct ice_netdev_priv *np,
> > }
> > /**
> > - * ice_setup_tc_block_cb - callback handler registered for TC block
> >
Remove the headers argument from the ice_tc_count_lkups() function, because
it is not used anywhere.
Reviewed-by: Michal Swiatkowski
Signed-off-by: Larysa Zaremba
---
drivers/net/ethernet/intel/ice/ice_tc_lib.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/dr
On 14/2/2025 4:56 pm, Kurt Kanzenbach wrote:
On Fri Feb 14 2025, Abdul Rahim, Faizal wrote:
On 14/2/2025 3:12 am, Kurt Kanzenbach wrote:
On Thu Feb 13 2025, Vladimir Oltean wrote:
So, confusingly to me, it seems like one operating mode is fundamentally
different from the other, and somethin
On 14/2/2025 6:22 pm, Vladimir Oltean wrote:
Faizal,
On Fri, Feb 14, 2025 at 05:43:19PM +0800, Abdul Rahim, Faizal wrote:
Hi Kurt & Vladimir,
After reading Vladimir's reply on tc, hw queue, and socket priority mapping
for both taprio and mqprio, I agree they should follow the same priority
On Fri, Feb 14, 2025 at 07:20:08PM +0800, Abdul Rahim, Faizal wrote:
> Okay. I can look into this in a separate patch submission, but just an
> FYI—this adds another dependency to the second part of the igc fpe
> submission (preemptible tc on taprio + mqprio). This new patch
> (driver-specific priv
On Fri, Feb 14, 2025, at 11:29, Steffen Klassert wrote:
> On Wed, Feb 12, 2025 at 08:30:20PM +0200, Leon Romanovsky wrote:
>> On Wed, Feb 12, 2025 at 12:56:48PM +0100, Steffen Klassert wrote:
>> > On Wed, Feb 05, 2025 at 08:20:21PM +0200, Leon Romanovsky wrote:
>> > > From: Leon Romanovsky
>> >
Faizal,
On Fri, Feb 14, 2025 at 05:43:19PM +0800, Abdul Rahim, Faizal wrote:
> > > Hi Kurt & Vladimir,
> > >
> > > After reading Vladimir's reply on tc, hw queue, and socket priority
> > > mapping
> > > for both taprio and mqprio, I agree they should follow the same priority
> > > scheme for con
defconfiggcc-14.2.0
archsdk_defconfiggcc-14.2.0
arc randconfig-001-20250214gcc-13.2.0
arc randconfig-001-20250214gcc-14.2.0
arc randconfig-002-20250214gcc-13.2.0
arc randconfig
gcc-13.2.0
arc allyesconfiggcc-13.2.0
arc randconfig-001-20250214gcc-13.2.0
arc randconfig-002-20250214gcc-13.2.0
arm alldefconfiggcc-14.2.0
arm allmodconfig
hsdk_defconfiggcc-14.2.0
arc randconfig-001-20250214gcc-13.2.0
arc randconfig-001-20250214gcc-14.2.0
arc randconfig-002-20250214gcc-13.2.0
arc randconfig-002-20250214gcc-14.2.0
arm
Use the pldmfw library to implement device flash update for
the Intel ixgbe networking device driver specifically for E610 devices.
This support uses the devlink flash update interface.
Using the pldmfw library, the provided firmware file will be scanned for
the three major components, "fw.undi" f
Provide devlink .info_get() callback implementation to allow the
driver to report detailed version information. The following info
is reported:
"serial_number" -> The PCI DSN of the adapter
"fw.bundle_id" -> Unique identifier for the combined flash image
"fw.undi" -> Version of the Option ROM c
From: Slawomir Mrozowicz
Read NVM related info from the flash.
Add several helper functions used to access the flash data,
find memory banks, calculate offsets, calculate the flash size.
Reviewed-by: Przemek Kitszel
Reviewed-by: Mateusz Polchlopek
Signed-off-by: Slawomir Mrozowicz
Co-develop
Add an initial support for devlink interface to ixgbe driver.
Similarly to i40e driver the implementation doesn't enable
devlink to manage device-wide configuration. Devlink instance
is created for each physical function of PCIe device.
Create separate directory for devlink related ixgbe files
an
Add E610 implementation of fw_recovery_mode MAC operation.
In case of E610 information about recovery mode is obtained
from FW_MODES field in IXGBE_GL_MNG_FWSM register (0x000B6134).
Introduce recovery specific probing flow and init only
vital features.
User should be able to perform NVM update
From: Andrii Staikov
The driver should detect whether the device entered FW rollback
mode and then notify user with the dedicated message including
FW and NVM versions.
Even if the driver detected rollback mode, this should not result
in an probe error and the normal flow proceeds.
FW tries to
Add E610 specific function checking whether the FW API version
is compatible with the driver expectations.
The major API version should be less than or equal to the expected
API version. If not the driver won't be fully operational.
Check the minor version, and if it is more than two versions les
On 2/13/25 21:39, Tantilov, Emil S wrote:
On 2/12/2025 10:21 AM, Simon Horman wrote:
On Mon, Feb 10, 2025 at 06:38:51PM -0800, Emil Tantilov wrote:
Current init logic ignores the error code from register_netdev(),
which will cause WARN_ON() on attempt to unregister it, if there was
one,
and th
Create devlink specific directory for more convenient future feature
development.
Flashing and reloading are supported only by E610 devices.
Introduce basic FW/NVM validation since devlink reload introduces
possibility of runtime NVM update. Check FW API version, FW recovery mode
and FW rollback
Prevent from proceeding if there's nothing to print.
Suggested-by: Przemek Kitszel
Reviewed-by: Jiri Pirko
Signed-off-by: Jedrzej Jagielski
---
net/devlink/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/devlink/dev.c b/net/devlink/dev.c
index d6e3db300acb..026027
From: Przemek Kitszel
Wrap use of netdev_priv() in order to change the allocator of the device
private structure from alloc_etherdev_mq() to the devlink in next commit.
All but one netdev_priv() calls in the whole driver are replaced, the
remaining one is called on MACVLAN (so not ixgbe) device.
From: Karol Kolacinski
Add a description of PTP pins support by the adapters to ice driver
documentation.
Reviewed-by: Milena Olech
Signed-off-by: Karol Kolacinski
Signed-off-by: Arkadiusz Kubalewski
---
v3:
- add missing reviewed-by and signed-off-by
---
.../device_drivers/ethernet/intel/ic
DPLL-enabled E810 NIC driver provides user with list of input and output
pins. Hardware internal design impacts user control over SMA and U.FL
pins. Currently end-user view on those dpll pins doesn't provide any layer
of abstraction. On the hardware level SMA and U.FL pins are tied together
due to
From: Karol Kolacinski
This change aligns E810 PTP pin control to all other products.
Currently, SMA/U.FL port expanders are controlled together with SDP pins
connected to 1588 clock. To align this, separate this control by
exposing only SDP20..23 pins in PTP API on adapters with DPLL.
Clear er
Previously control of the dpll SMA/U.FL pins was partially done through
ptp API, decouple pins control from both interfaces (dpll and ptp).
Allow the SMA/U.FL pins control over a dpll subsystem, and leave ptp
related SDP pins control over a ptp subsystem.
Arkadiusz Kubalewski (1):
ice: redesign
Current init logic ignores the error code from register_netdev(),
which will cause WARN_ON() on attempt to unregister it, if there was one,
and there is no info for the user that the creation of the netdev failed.
WARNING: CPU: 89 PID: 6902 at net/core/dev.c:11512
unregister_netdevice_many_notify
On Thu, 13 Feb 2025 16:30:59 -0800 Jacob Keller wrote:
> Analyzing the places where we take crit_lock in the driver there are two
> sources:
>
> a) several of the work queue tasks including adminq_task, watchdog_task,
> reset_task, and the finish_config task.
>
> b) various callbacks which ultima
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Thu, 13 Feb 2025 09:31:41 +0300 you wrote:
> If pci_alloc_irq_vectors() can't allocate the minimum number of vectors
> then it returns -ENOSPC so there is no need to check for that in the
> caller. In fact, becaus
48 matches
Mail list logo
