This patch move the 10% broadcast protection from the individual setup
to ksz_setup. In the ksz9477, broadcast protection is updated in reset
function.
Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch move the common initialization of switches to ksz_setup and
perform the switch specific initialization using the ksz_dev_ops
function pointer.
Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In order to transmit the STP BPDU packet to the CPU port, the STP
address 01-80-c2-00-00-00 has to be added to static alu table for
ksz8795 series switch. For the ksz9477 switch, there is reserved
multicast table which handles forwarding the particular set of
multicast address to cpu port. So enabling the multicast reserved table
and updated the cpu port index. The stp addr is enabled during the setup
phase using the enable_stp_addr pointer in struct ksz_dev_ops.
Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

To have the common set of initialization in ksz_setup, introduced the
new config_cpu_port member to ksz_dev_ops. Since both the ksz8795.c and
ksz9477.c configuring the cpu port in the setup function, introduced the
member.
Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch renames the shutdown to reset in ksz_dev_ops in order to use
the reset dev_ops in the ksz_setup.
Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add per port priority support for bonding active slave re-selection during
failover. A higher number means higher priority in selection. The primary
slave still has the highest priority. This option also follows the
primary_reselect rules.

This option could only be configured via netlink.
Signed-off-by: NHangbin Liu <liuhangbin@gmail.com>
Acked-by: NJonathan Toppins <jtoppins@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Remove the repeated word 'and' from comments
Signed-off-by: NJiang Jian <jiangjian@cdjrlc.com>
Link: https://lore.kernel.org/r/20220622144841.21274-1-jiangjian@cdjrlc.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Remove the repeated word 'and' from comments
Signed-off-by: NJiang Jian <jiangjian@cdjrlc.com>
Link: https://lore.kernel.org/r/20220622144526.20659-1-jiangjian@cdjrlc.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

The GPY115 and GPY2xx PHYs contain an integrated temperature sensor. It
accuracy is +/- 5°C. Add support for it.
Signed-off-by: NMichael Walle <michael@walle.cc>
Acked-by: NGuenter Roeck <linux@roeck-us.net>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20220622141716.3517645-1-michael@walle.ccSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Instead of open-coding the bad characters replacement in the hwmon name,
use the new devm_hwmon_sanitize_name().
Signed-off-by: NMichael Walle <michael@walle.cc>
Acked-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Instead of open-coding the bad characters replacement in the hwmon name,
use the new hwmon_sanitize_name().
Signed-off-by: NMichael Walle <michael@walle.cc>
Acked-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
Acked-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

The perout function is used to generate a 1PPS signal, synchronized
to the PHC.  This is accomplished by a using the hardware oneshot
functionality, which is reset by a timer.

The external timestamp function is set up for a 1PPS input pulse,
and uses a timer to poll for temestamps.

Both functions use the SYNC_OUT/SYNC_IN1 pin, so cannot run
simultaneously.
Co-developed-by: NLasse Johnsen <l@ssejohnsen.me>
Signed-off-by: NLasse Johnsen <l@ssejohnsen.me>
Signed-off-by: NJonathan Lemon <jonathan.lemon@gmail.com>
Acked-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

This adds PTP support for BCM54210E Broadcom PHYs, in particular,
the BCM54213PE, as used in the Rasperry PI CM4.  It has only been
tested on that hardware.
Signed-off-by: NJonathan Lemon <jonathan.lemon@gmail.com>
Acked-by: NRichard Cochran <richardcochran@gmail.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Add 'struct bcm_ptp_private' to bcm54xx_phy_priv which points to
an optional PTP structure attached to the PHY.  This is allocated
on probe if PHY PTP support is configured, and if the driver supports
PTP for the specified PHY.

Add the bcm_ptp_probe(), bcm_ptp_config_init() and bcn_ptp_stop()
API functions to the bcm-phy library.
Signed-off-by: NJonathan Lemon <jonathan.lemon@gmail.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Acked-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Currently, all the device specific speed setting functions convert
SPEED_MAX to the actual speed of the port. Rather than having each
of the mv88e6xxx chip specifics handling SPEED_MAX, derive it from
the mac_capabilities instead.

This is only needed for CPU and DSA ports, so move the logic up into
mv88e6xxx_setup_port() - which allows us to kill off all users of
SPEED_MAX throughout the driver.
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Remove mv88e6065_port_set_speed_duplex() - this is never called, and
thus is completely redundant.
Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Add support for ethtool -p|--identify
by enabling blinking of the panel LED if supported by the NIC firmware.
Signed-off-by: NSixiang Chen <sixiang.chen@corigine.com>
Signed-off-by: NSimon Horman <simon.horman@corigine.com>
Acked-by: NJakub Kicinski <kuba@kernel.org>
Link: https://lore.kernel.org/r/20220622083938.291548-1-simon.horman@corigine.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>

The following sequence currently causes a driver bug warning
when using virtio_net:

  # ip link set eth0 up
  # echo mem > /sys/power/state (or e.g. # rtcwake -s 10 -m mem)
  <resume>
  # ip link set eth0 down

  Missing register, driver bug
  WARNING: CPU: 0 PID: 375 at net/core/xdp.c:138 xdp_rxq_info_unreg+0x58/0x60
  Call trace:
   xdp_rxq_info_unreg+0x58/0x60
   virtnet_close+0x58/0xac
   __dev_close_many+0xac/0x140
   __dev_change_flags+0xd8/0x210
   dev_change_flags+0x24/0x64
   do_setlink+0x230/0xdd0
   ...

This happens because virtnet_freeze() frees the receive_queue
completely (including struct xdp_rxq_info) but does not call
xdp_rxq_info_unreg(). Similarly, virtnet_restore() sets up the
receive_queue again but does not call xdp_rxq_info_reg().

Actually, parts of virtnet_freeze_down() and virtnet_restore_up()
are almost identical to virtnet_close() and virtnet_open(): only
the calls to xdp_rxq_info_(un)reg() are missing. This means that
we can fix this easily and avoid such problems in the future by
just calling virtnet_close()/open() from the freeze/restore handlers.

Aside from adding the missing xdp_rxq_info calls the only difference
is that the refill work is only cancelled if netif_running(). However,
this should not make any functional difference since the refill work
should only be active if the network interface is actually up.

Fixes: 754b8a21 ("virtio_net: setup xdp_rxq_info")
Signed-off-by: NStephan Gerhold <stephan.gerhold@kernkonzept.com>
Acked-by: NJesper Dangaard Brouer <brouer@redhat.com>
Acked-by: NJason Wang <jasowang@redhat.com>
Link: https://lore.kernel.org/r/20220621114845.3650258-1-stephan.gerhold@kernkonzept.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Intel I210 on some Intel Alder Lake platforms can only achieve ~750Mbps
Tx speed via iperf. The RR2DCDELAY shows around 0x2xxx DMA delay, which
will be significantly lower when 1) ASPM is disabled or 2) SoC package
c-state stays above PC3. When the RR2DCDELAY is around 0x1xxx the Tx
speed can reach to ~950Mbps.

According to the I210 datasheet "8.26.1 PCIe Misc. Register - PCIEMISC",
"DMA Idle Indication" doesn't seem to tie to DMA coalesce anymore, so
set it to 1b for "DMA is considered idle when there is no Rx or Tx AND
when there are no TLPs indicating that CPU is active detected on the
PCIe link (such as the host executes CSR or Configuration register read
or write operation)" and performing Tx should also fall under "active
CPU on PCIe link" case.

In addition to that, commit b6e0c419 ("igb: Move DMA Coalescing init
code to separate function.") seems to wrongly changed from enabling
E1000_PCIEMISC_LX_DECISION to disabling it, also fix that.

Fixes: b6e0c419 ("igb: Move DMA Coalescing init code to separate function.")
Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
Link: https://lore.kernel.org/r/20220621221056.604304-1-anthony.l.nguyen@intel.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Add support multi-gigabit and single-port Ethernet
PHY transceiver (AQR113C).
Signed-off-by: NBhadram Varka <vbhadram@nvidia.com>
Link: https://lore.kernel.org/r/20220621034027.56508-1-vbhadram@nvidia.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Use the recently introduced mdiodev accessors for the lynx PCS.
Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://lore.kernel.org/r/E1o3Zd8-002yHI-G2@rmk-PC.armlinux.org.ukSigned-off-by: NJakub Kicinski <kuba@kernel.org>

The current mgmt ethernet timeout is set to 100ms. This value is too
big and would slow down any mdio command in case the mgmt ethernet
packet have some problems on the receiving part.
Reduce it to just 5ms to handle case when some operation are done on the
master port that would cause the mgmt ethernet to not work temporarily.

Fixes: 5950c7c0 ("net: dsa: qca8k: add support for mgmt read/write in Ethernet packet")
Signed-off-by: NChristian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20220621151633.11741-1-ansuelsmth@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

It was discovered that the Documentation lacks of a fundamental detail
on how to correctly change the MAX_FRAME_SIZE of the switch.

In fact if the MAX_FRAME_SIZE is changed while the cpu port is on, the
switch panics and cease to send any packet. This cause the mgmt ethernet
system to not receive any packet (the slow fallback still works) and
makes the device not reachable. To recover from this a switch reset is
required.

To correctly handle this, turn off the cpu ports before changing the
MAX_FRAME_SIZE and turn on again after the value is applied.

Fixes: f58d2598 ("net: dsa: qca8k: implement the port MTU callbacks")
Cc: stable@vger.kernel.org
Signed-off-by: NChristian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20220621151122.10220-1-ansuelsmth@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

there is an unexpected word "the" in the comments that need to be removed
Signed-off-by: NJiang Jian <jiangjian@cdjrlc.com>
Reviewed-by: NAlex Elder <elder@linaro.org>
Link: https://lore.kernel.org/r/20220621085001.61320-1-jiangjian@cdjrlc.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

there is an unexpected word "the" in the comments that need to be removed
Signed-off-by: NJiang Jian <jiangjian@cdjrlc.com>
Link: https://lore.kernel.org/r/20220621084537.58402-1-jiangjian@cdjrlc.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Remove unnecessary void* type castings.
Signed-off-by: NYu Zhe <yuzhe@nfschina.com>
Acked-by: NTaehee Yoo <ap420073@gmail.com>
Link: https://lore.kernel.org/r/20220621021648.2544-1-yuzhe@nfschina.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Under CONFIG_FORTIFY_SOURCE=y and CONFIG_UBSAN_BOUNDS=y, Clang is bugged
here for calculating the size of the destination buffer (0x10 instead of
0x14). This copy is a fixed size (sizeof(struct fw_section_info_st)), with
the source and dest being struct fw_section_info_st, so the memcpy should
be safe, assuming the index is within bounds, which is UBSAN_BOUNDS's
responsibility to figure out.

Avoid the whole thing and just do a direct assignment. This results in
no change to the executable code.

[This is a duplicate of commit 2c0ab32b ("hinic: Replace memcpy()
 with direct assignment") which was applied to net-next.]

Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Tom Rix <trix@redhat.com>
Cc: llvm@lists.linux.dev
Link: https://github.com/ClangBuiltLinux/linux/issues/1592Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org> # build
Link: https://lore.kernel.org/r/20220616052312.292861-1-keescook@chromium.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>

This reverts commit 8fc74d18.

BAR0 is the main (only?) register bank for this device. We most
obviously can't unmap it before the netdev is unregistered.
This was pointed out in review but the patch got reposted and
merged, anyway.

The author of the patch was only testing it with a QEMU model,
which I presume does not emulate enough for the netdev to be brought
up (author's replies are not visible in lore because they kept sending
their emails in HTML).

Link: https://lore.kernel.org/all/20220616085059.680dc215@kernel.org/
Fixes: 8fc74d18 ("drivers/net/ethernet/neterion/vxge: Fix a use-after-free bug in vxge-main.c")
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

rFID and dummy FID do not support FID->VNI mapping. Currently, these
families do not implement the vni_{set, clear}() operations. Instead, there
is a check if these functions are implemented.

Similarly, 'SFMR.nve_tunnel_flood_ptr' is not relevant for rFID and dummy
FID, therefore, these families do not implement
nve_flood_index_{set, clear}().

Align the behavior to other unsupported operations, implement the functions
and just return an error or warn. Then, checks like '!ops->vni_set' can be
removed.
Signed-off-by: NAmit Cohen <amcohen@nvidia.com>
Signed-off-by: NIdo Schimmel <idosch@nvidia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The previous patch added 'fid_offset' field to FID structure. Now, this
field can be used when VNI is set using SFMR register. Currently
'fid_offset' is set to zero, instead, use the new field which is now set
to zero and in the future will be changed.
Signed-off-by: NAmit Cohen <amcohen@nvidia.com>
Signed-off-by: NIdo Schimmel <idosch@nvidia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

SFMR register contains a 'fid_offset' field which is used when flooding
tables of type FID offset are used.

Currently, the driver sets this field to zero, as flooding tables of type
FID are used.

Using unified bridge model, the driver will use FID offset flooding
tables. As preparation, add 'fid_offset' to 'struct mlxsw_sp_fid'. Then,
use this field instead of passing zero to the function that configures
SFMR.

Set the new field as part of 'ops->setup()', for that, implement this
function for dummy FID and rFID.
Signed-off-by: NAmit Cohen <amcohen@nvidia.com>
Signed-off-by: NIdo Schimmel <idosch@nvidia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently, as part of mlxsw_pci_init(), resources are queried from firmware
before issuing the 'CONFIG_PROFILE' command.

There are resources whose size depend on the enablement of the unified
bridge model that is performed via 'CONFIG_PROFILE' command. As a
preparation for unified bridge model, add an additional query after issuing
this command. Both queries are required as KVD sizes are read from
firmware and then are configured as part of 'CONFIG_PROFILE' command.
Signed-off-by: NAmit Cohen <amcohen@nvidia.com>
Signed-off-by: NIdo Schimmel <idosch@nvidia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently, the length of 'config_profile.flood_mode' is defined as 2
bits, while the correct length is 3 bits.

As preparation for unified bridge model, which will use the whole field
length, fix it and increase the field to the correct size.
Signed-off-by: NAmit Cohen <amcohen@nvidia.com>
Signed-off-by: NIdo Schimmel <idosch@nvidia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently magic constant is used for setting 'flood_mode' as part of
config profile.

As preparation for unified bridge model, which will require different
'flood_mode', add a dedicated enumerator for this field and use it as
part of 'struct mlxsw_config_profile'.

Add the relevant value for unified bridge model.
Signed-off-by: NAmit Cohen <amcohen@nvidia.com>
Signed-off-by: NIdo Schimmel <idosch@nvidia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The above mentioned function calls two functions which return values, but
it ignores them.

Check if the return value is an error, handle it in such case and return
an error back to the caller.
Signed-off-by: NAmit Cohen <amcohen@nvidia.com>
Signed-off-by: NIdo Schimmel <idosch@nvidia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The function returns 'false' upon failure and 'true' upon success.
Convert it to the usual scheme of returning integer error codes and
align the callers.
Signed-off-by: NAmit Cohen <amcohen@nvidia.com>
Signed-off-by: NIdo Schimmel <idosch@nvidia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The above mentioned function just returns an error in case that
mlxsw_sp_bridge_ports_flood_table_set() fails. That means that the previous
configurations are not cleaned.

Fix it by adding error path to clean the configurations in case of error.
Signed-off-by: NAmit Cohen <amcohen@nvidia.com>
Signed-off-by: NIdo Schimmel <idosch@nvidia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The above mentioned function is called for each port in bridge when the
multicast behavior is changed. Currently, it updates all the relevant
MID entries only for the first call, but the update of flooding per port
is done only for the port that it was called for it.

To simplify this behavior, it is possible to handle flooding for all the
ports in the first call, then, the other calls will do nothing. For
that, new functions are required to set flooding for all ports, no
'struct mlxsw_sp_port' is required.

This issue was found while extending this function for unified bridge
model, the above mentioned change will ease the extending later.
Signed-off-by: NAmit Cohen <amcohen@nvidia.com>
Signed-off-by: NIdo Schimmel <idosch@nvidia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The function mlxsw_sp_port_mc_disabled_set() sets
'bridge_device->multicast_enabled' twice. Remove the unnecessary setting.
Signed-off-by: NAmit Cohen <amcohen@nvidia.com>
Signed-off-by: NIdo Schimmel <idosch@nvidia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently the above mentioned function gets 'struct mlxsw_sp_port',
while the only use of this structure is to get 'mlxsw_sp_port->mlxsw_sp'.

Instead, pass 'struct mlxsw_sp'.
Signed-off-by: NAmit Cohen <amcohen@nvidia.com>
Signed-off-by: NIdo Schimmel <idosch@nvidia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>