There is no support for SF in legacy mode. Reflect it in the code.
Reviewed-by: Przemek Kitszel
Fixes: eda69d654c7e ("ice: add basic devlink subfunctions support")
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/devlink/devlink_port.c | 6 ++
1 file changed, 6 insertion
HW can have different input/output delays for each of the pins.
Add a field in ice_ptp_pin_desc structure to reflect that.
Implement external timestamp delay compensation.
Remove existing definitions and wrappers for periodic output propagation
delays.
Reviewed-by: Przemek Kitszel
Signed-off-by
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git dev-queue
branch HEAD: f2589ad16e14b7102f1411e3385a2abf07076406 e1000: Link NAPI
instances to queues and IRQs
elapsed time: 1814m
configs tested: 129
configs skipped: 4
The following configs have been built succ
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git dev-queue
branch HEAD: 67b41b1b985f7117d61bc2e8ab93267cec9514f5 ice: fix PHY Clock
Recovery availability check
elapsed time: 1687m
configs tested: 108
configs skipped: 3
The following configs have been built succ
On Thu, Oct 03, 2024 at 04:53:13PM -0700, Joe Damato wrote:
> On Thu, Oct 03, 2024 at 04:29:37PM -0700, Stanislav Fomichev wrote:
> > On 10/01, Joe Damato wrote:
>
> [...]
>
> > > 2. This revision seems to work (see below for a full walk through). Is
> > > this the behavior we want? Am I
On Mon, 30 Sep 2024 16:24:22 + Joe Damato wrote:
> The sizeof(struct napi_struct) can change. Don't hardcode the size to
> 400 bytes and instead use "sizeof(struct napi_struct)".
>
> While fixing this, also move other calculations into compile time
> defines.
Anticipating v3 with smaller diff
On Thu, Oct 03, 2024 at 04:29:37PM -0700, Stanislav Fomichev wrote:
> On 10/01, Joe Damato wrote:
[...]
> > 2. This revision seems to work (see below for a full walk through). Is
> > this the behavior we want? Am I missing some use case or some
> > behavioral thing other folks need?
Link queues to NAPI instances via netdev-genl API so that users can
query this information with netlink:
$ ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/netdev.yaml \
--dump queue-get --json='{"ifindex": 2}'
[{'id': 0, 'ifindex': 2, 'napi-id': 8193, 'type': 'r
Link IRQs to NAPI instances via netdev-genl API so that users can query
this information with netlink.
Compare the output of /proc/interrupts (noting that IRQ 144 is the
"other" IRQ which does not appear to have a NAPI instance):
$ cat /proc/interrupts | grep enp86s0 | cut --delimiter=":" -f1
14
Greetings:
This is an RFC to get feedback before submitting an actual series and
because I have a question for igc maintainers, see below.
This series addss support for netdev-genl to igc so that userland apps
can query IRQ, queue, and NAPI instance relationships. This is useful
because developer
On 10/01, Joe Damato wrote:
> Greetings:
>
> Welcome to RFC v4.
>
> Very important and significant changes have been made since RFC v3 [1],
> please see the changelog below for details.
>
> A couple important call outs for this revision for reviewers:
>
> 1. idpf embeds a napi_struct in an in
Implement ptp HW timestamp latch points callbacks, allow user to control
the latch point of ptp timestamps in E825 devices.
Signed-off-by: Arkadiusz Kubalewski
---
drivers/net/ethernet/intel/ice/ice_ptp.c| 48 +++
drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 52 +
Introduce:
- ops for getting and setting the HW timestamp latch point,
- enumerate possible HW timestamp latch point,
- new sysfs ptp device attribute as user knob.
HW support of PTP/timesync solutions in network PHY chips can be
achieved with two different approaches, the timestamp maybe latched
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.
Arkad
On 10/03, Arthur Fabre wrote:
> On Thu Oct 3, 2024 at 12:49 AM CEST, Stanislav Fomichev wrote:
> > On 10/02, Toke Høiland-Jørgensen wrote:
> > > Stanislav Fomichev writes:
> > >
> > > > On 10/01, Toke Høiland-Jørgensen wrote:
> > > >> Lorenzo Bianconi writes:
> > > >>
> > > >> >> On Mon Sep 30,
On Thu, Oct 03, 2024 at 03:35:54PM +0200, Alexander Lobakin wrote:
[...]
> napi_struct is the only generic struct whichs size is hardcoded in the
> macros (struct dim is already sizeof()ed, as well as cpumask_var_t), so
> I'm fine with the change you proposed in your first RFC -- I mean
>
> libet
Add high level link management support for E610 device. Enable the
following features:
- driver load
- bring up network interface
- IP address assignment
- pass traffic
- show statistics (e.g. via ethtool)
- disable network interface
- driver unload
Co-developed-by: Carolyn Wyborny
Signed-off-by:
Required for enabling the link management in E610 device.
Reviewed-by: Simon Horman
Signed-off-by: Piotr Kwapulinski
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 17 +++--
drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 12 ++--
2 files changed, 17 insertions(+), 12 d
Required to adopt x540 specific functions by E610 device.
Signed-off-by: Piotr Kwapulinski
---
drivers/net/ethernet/intel/ixgbe/ixgbe_x540.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.h
b/drivers/net/ethernet/intel/ixgbe
Add low level support for accessing NVM in E610 device. NVM operations are
handled via the Admin Command Interface. Add the following NVM specific
operations:
- acquire, release, read
- validate checksum
- read shadow ram
Co-developed-by: Stefan Wegrzyn
Signed-off-by: Stefan Wegrzyn
Co-developed
Add low level link management support for E610 device. Link management
operations are handled via the Admin Command Interface. Add the following
link management operations:
- get link capabilities
- set up link
- get media type
- get link status, link status events
- link power management
Co-devel
Add low level support for E610 device capabilities detection. The
capabilities are discovered via the Admin Command Interface. Discover the
following capabilities:
- function caps: vmdq, dcb, rss, rx/tx qs, msix, nvm, orom, reset
- device caps: vsi, fdir, 1588
- phy caps
Co-developed-by: Stefan We
Add low level support for Admin Command Interface (ACI). ACI is the
Firmware interface used by a driver to communicate with E610 adapter. Add
the following ACI features:
- data structures, macros, register definitions
- commands handling
- events handling
Co-developed-by: Stefan Wegrzyn
Signed-of
Add initial support for Intel(R) E610 Series of network devices. The E610
is based on X550 but adds firmware managed link, enhanced security
capabilities and support for updated server manageability.
This patch series adds low level support for the following features and
enables link management.
From: Jakub Kicinski
Date: Wed, 2 Oct 2024 10:17:27 -0700
> On Tue, 1 Oct 2024 07:44:36 -0700 Joe Damato wrote:
>>> But if you change any core API, let's say rename a field used in several
>>> drivers, you anyway need to adjust the affected drivers.
>>
>> Sorry, but that's a totally different a
> -Original Message-
> From: Intel-wired-lan On Behalf Of Simon
> Horman
> Sent: Monday, September 30, 2024 4:52 PM
> To: Marcin Szycik
> Cc: Keller, Jacob E ; net...@vger.kernel.org; Michal
> Swiatkowski ; intel-wired-
> l...@lists.osuosl.org; Kitszel, Przemyslaw
> Subject: Re: [Intel-w
> -Original Message-
> From: Intel-wired-lan On Behalf Of Simon
> Horman
> Sent: Tuesday, September 24, 2024 8:57 AM
> To: Loktionov, Aleksandr
> Cc: Nguyen, Anthony L ; Kubalewski, Arkadiusz
> ; intel-wired-...@lists.osuosl.org;
> net...@vger.kernel.org
> Subject: Re: [Intel-wired-lan] [
>From: Nguyen, Anthony L
>Sent: Thursday, October 3, 2024 12:18 AM
>
>On 9/30/2024 11:40 AM, Arkadiusz Kubalewski wrote:
>> The E810 Lan On Motherboard (LOM) design is vendor specific. Intel
>> provides the reference design, but it is up to vendor on the final
>> product design. For some cases, li
The E810 Lan On Motherboard (LOM) design is vendor specific. Intel
provides the reference design, but it is up to vendor on the final
product design. For some cases, like Linux DPLL support, the static
values defined in the driver does not reflect the actual LOM design.
Current implementation of ou
29 matches
Mail list logo
