sfc: parse headers of devlink flash images

This parsing is necessary to obtain the metadata which will be
used in a subsequent patch to write the image to the device.

Signed-off-by: Edward Cree <e

sfc: parse headers of devlink flash images

This parsing is necessary to obtain the metadata which will be
used in a subsequent patch to write the image to the device.

Signed-off-by: Edward Cree <[email protected]>
Link: https://patch.msgid.link/65318300f3f1b1462925f917f7c0d0ac833955ae.1739186253.git.ecree.xilinx@gmail.com
Signed-off-by: Jakub Kicinski <[email protected]>

show more ...

sfc: functions to register for conntrack zone offload

Bind a stub callback to the netfilter flow table.

Reviewed-by: Pieter Jansen van Vuuren <[email protected]>
Reviewed-by: Simon H

sfc: functions to register for conntrack zone offload

Bind a stub callback to the netfilter flow table.

Reviewed-by: Pieter Jansen van Vuuren <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Signed-off-by: Edward Cree <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

sfc: some plumbing towards TC encap action offload

Create software objects to manage the metadata for encap actions that
can be attached to TC rules. However, since we don't yet have the
neighbou

sfc: some plumbing towards TC encap action offload

Create software objects to manage the metadata for encap actions that
can be attached to TC rules. However, since we don't yet have the
neighbouring information (needed to generate the Ethernet header),
all rules with encap actions are marked as "unready" and thus insert
the fallback action into hardware rather than actually offloading the
encapsulation action.

Reviewed-by: Pieter Jansen van Vuuren <[email protected]>
Signed-off-by: Edward Cree <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>

show more ...

sfc: add devlink support for ef100

Add devlink infrastructure support. Further patches add devlink
info and devlink port support.

Signed-off-by: Alejandro Lucero <[email protected]>
Re

sfc: add devlink support for ef100

Add devlink infrastructure support. Further patches add devlink
info and devlink port support.

Signed-off-by: Alejandro Lucero <[email protected]>
Reviewed-by: Jiri Pirko <[email protected]>
Acked-by: Martin Habets <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>

show more ...

sfc: add extra RX channel to receive MAE counter updates on ef100

Currently there is no counter-allocating machinery to connect the
resulting counter update values to; that will be added in a
subs

sfc: add extra RX channel to receive MAE counter updates on ef100

Currently there is no counter-allocating machinery to connect the
resulting counter update values to; that will be added in a
subsequent patch.

Signed-off-by: Edward Cree <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

sfc: bind blocks for TC offload on EF100

Bind direct blocks for the MAE-admin PF and each VF representor.
Currently these connect to a stub efx_tc_flower() that only returns
-EOPNOTSUPP; subsequent

sfc: bind blocks for TC offload on EF100

Bind direct blocks for the MAE-admin PF and each VF representor.
Currently these connect to a stub efx_tc_flower() that only returns
-EOPNOTSUPP; subsequent patches will implement flower offloads to the
Match-Action Engine.

Signed-off-by: Edward Cree <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

sfc: insert default MAE rules to connect VFs to representors

Default rules are low-priority switching rules which the hardware uses
in the absence of higher-priority rules. Each representor requir

sfc: insert default MAE rules to connect VFs to representors

Default rules are low-priority switching rules which the hardware uses
in the absence of higher-priority rules. Each representor requires a
corresponding rule matching traffic from its representee VF and
delivering to the PF (where a check on INGRESS_MPORT in
__ef100_rx_packet() will direct it to the representor). No rule is
required in the reverse direction, because representor TX uses a TX
override descriptor to bypass the MAE and deliver directly to the VF.
Since inserting any rule into the MAE disables the firmware's own
default rules, also insert a pair of rules to connect the PF to the
physical network port and vice-versa.

Signed-off-by: Edward Cree <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>

show more ...

sfc: determine representee m-port for EF100 representors

An MAE port, or m-port, is a port (source/destination for traffic) on
the Match-Action Engine (the internal switch on EF100).
Representors w

sfc: determine representee m-port for EF100 representors

An MAE port, or m-port, is a port (source/destination for traffic) on
the Match-Action Engine (the internal switch on EF100).
Representors will use their representee's m-port for two purposes: as
a destination override on TX from the representor, and as a source
match in 'default rules' to steer representee traffic (when not
matched by e.g. a TC flower rule) to representor RX via the parent
PF's receive queue.

Signed-off-by: Edward Cree <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

sfc: add skeleton ef100 VF representors

No net_device_ops yet, just a placeholder netdev created per VF.

Signed-off-by: Edward Cree <[email protected]>
Signed-off-by: David S. Miller <davem@da

sfc: add skeleton ef100 VF representors

No net_device_ops yet, just a placeholder netdev created per VF.

Signed-off-by: Edward Cree <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

sfc: Add a basic Siena module

Make the (un)load message more specific to differentiate it from
the sfc.ko messages.

Signed-off-by: Martin Habets <[email protected]>
Signed-off-by: Jakub Kici

sfc: Add a basic Siena module

Make the (un)load message more specific to differentiate it from
the sfc.ko messages.

Signed-off-by: Martin Habets <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>

show more ...

sfc: Disable Siena support

Disable the build of Siena code until later in this patch series.
Prevent sfc.ko from binding to Siena NICs.

efx_init_sriov/efx_fini_sriov is only used for Siena. Remove

sfc: Disable Siena support

Disable the build of Siena code until later in this patch series.
Prevent sfc.ko from binding to Siena NICs.

efx_init_sriov/efx_fini_sriov is only used for Siena. Remove calls
to those.

Signed-off-by: Martin Habets <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

sfc: add EF100 VF support via a write to sriov_numvfs

This patch extends the EF100 PF driver by adding .sriov_configure()
which would allow users to enable and disable virtual functions
using the sr

sfc: add EF100 VF support via a write to sriov_numvfs

This patch extends the EF100 PF driver by adding .sriov_configure()
which would allow users to enable and disable virtual functions
using the sriov sysfs.

Signed-off-by: Pieter Jansen van Vuuren <[email protected]>
Signed-off-by: Edward Cree <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>

show more ...

sfc: skeleton EF100 PF driver

No TX or RX path, no MCDI, not even an ifup/down handler.
Besides stubs, the bulk of the patch deals with reading the Xilinx
extended PCIe capability, which tells us w

sfc: skeleton EF100 PF driver

No TX or RX path, no MCDI, not even an ifup/down handler.
Besides stubs, the bulk of the patch deals with reading the Xilinx
extended PCIe capability, which tells us where to find our BAR.

Though in the same module, EF100 has its own struct pci_driver,
which is named sfc_ef100.

A small number of additional nic_type methods are added; those in the
TX (tx_enqueue) and RX (rx_packet) paths are called through indirect
call wrappers to minimise the performance impact.

Signed-off-by: Edward Cree <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

sfc: move mcdi filtering code

Signed-off-by: Alexandru-Mihai Maftei <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

sfc: move some ethtool code

Various ethtool entry points are moved.

Signed-off-by: Alexandru-Mihai Maftei <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

sfc: move MCDI VI alloc/free code

One function was renamed here, the other contains code extracted from
another.

Signed-off-by: Alexandru-Mihai Maftei <[email protected]>
Signed-off-by: David

sfc: move MCDI VI alloc/free code

One function was renamed here, the other contains code extracted from
another.

Signed-off-by: Alexandru-Mihai Maftei <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

sfc: move some port link state/caps code

The moved code handles MCDI port link state and capabilities.

Signed-off-by: Alexandru-Mihai Maftei <[email protected]>
Signed-off-by: David S. Miller

sfc: move some port link state/caps code

The moved code handles MCDI port link state and capabilities.

Signed-off-by: Alexandru-Mihai Maftei <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

sfc: move common tx code

Once again, a tiny bit of refactoring was required to stitch the code
together (i.e. adding headers). The moved code deals with managing tx
queues and mappings.

Signed-off-

sfc: move common tx code

Once again, a tiny bit of refactoring was required to stitch the code
together (i.e. adding headers). The moved code deals with managing tx
queues and mappings.

Signed-off-by: Alexandru-Mihai Maftei <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

sfc: move common rx code

The moved code deals with managing rx buffers and queues.
A tiny bit of refactoring was required in other files to stitch the
code together.

Signed-off-by: Alexandru-Mihai

sfc: move common rx code

The moved code deals with managing rx buffers and queues.
A tiny bit of refactoring was required in other files to stitch the
code together.

Signed-off-by: Alexandru-Mihai Maftei <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

sfc: move some channel-related code

Just a handful of function, but also removed many 'static' identifiers
so the code builds. These will, of course, be moved.
Module parameters for IRQ moderation t

sfc: move some channel-related code

Just a handful of function, but also removed many 'static' identifiers
so the code builds. These will, of course, be moved.
Module parameters for IRQ moderation threshold also moved.

Small code styling fixes included.

Signed-off-by: Alexandru-Mihai Maftei <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

sfc: move reset workqueue code

Small functions doing work that will be common, related to reset
workqueue management.

Signed-off-by: Alexandru-Mihai Maftei <[email protected]>
Signed-off-by: D

sfc: move reset workqueue code

Small functions doing work that will be common, related to reset
workqueue management.

Signed-off-by: Alexandru-Mihai Maftei <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

net: ethernet: sfc: Make subdir logic consistent with other vendors

Both SFC and SFC_FALCON depend on NET_VENDOR_SOLARFLARE, hence use the
latter to decide whether to descend into the sfc subdirecto

net: ethernet: sfc: Make subdir logic consistent with other vendors

Both SFC and SFC_FALCON depend on NET_VENDOR_SOLARFLARE, hence use the
latter to decide whether to descend into the sfc subdirectory.
Move the rule to descend into sfc/falcon to the sfc subdirectory.

Signed-off-by: Geert Uytterhoeven <[email protected]>
Acked-by: Martin Habets <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.

For non */uapi/* files that summary was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139

and resulted in the first patch in this series.

If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930

and resulted in the second patch in this series.

- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:

SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1

and that resulted in the third patch in this series.

- when the two scanners agreed on the detected license(s), that became
the concluded license(s).

- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.

- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).

- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.

- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct

This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.

Reviewed-by: Kate Stewart <[email protected]>
Reviewed-by: Philippe Ombredanne <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver

Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena

sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver

Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).

The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.

This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.

Also, increment minor version of both drivers (to 4.1).

For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.

Signed-off-by: Edward Cree <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...

sfc: Firmware-Assisted TSO version 2

Add support for FATSOv2 to the driver. FATSOv2 offloads far more of the task
of TCP segmentation to the firmware, such that we now just pass a single
super-pac

sfc: Firmware-Assisted TSO version 2

Add support for FATSOv2 to the driver. FATSOv2 offloads far more of the task
of TCP segmentation to the firmware, such that we now just pass a single
super-packet to the NIC. This means TSO has a great deal in common with a
normal DMA transmit, apart from adding a couple of option descriptors.
NIC-specific checks have been moved off the fast path and in to
initialisation where possible.

This also moves FATSOv1/SWTSO to a new file (tx_tso.c). The end of transmit
and some error handling is now outside TSO, since it is common with other
code.

Signed-off-by: Edward Cree <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...