summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2022-09-01net: move from strlcpy with unused retval to strscpyWolfram Sang40-75/+75
Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by a coccinelle script. Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/ Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> # for CAN Link: https://lore.kernel.org/r/20220830201457.7984-1-wsa+renesas@sang-engineering.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-31net: phy: smsc: use device-managed clock APIHeiner Kallweit1-25/+5
Simplify the code by using the device-managed clock API. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/b222be68-ba7e-999d-0a07-eca0ecedf74e@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-31net: hns3: net: hns3: add querying and setting fec off mode from firmwareGuangbin Huang3-12/+16
For some new devices, the FEC mode can not be set to OFF in speed 200G. In order to flexibly adapt to all types of devices, driver queries fec ability from firmware to decide whether OFF mode can be supported. Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: hns3: add querying and setting fec llrs mode from firmwareHao Lan6-1/+22
This patch supports llrs fec mode in speed 200G for some new devices, and suppoprts querying llrs fec ability from firmware. Signed-off-by: Hao Lan <lanhao@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: hns3: add querying fec ability from firmwareGuangbin Huang2-9/+26
For some new devices, driver can queries fec ability from firmware to decide which FEC mode can be supported. If devices of old version which not support querying fec ability, driver sets fixed ability according to current speed. Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: hns3: add getting capabilities of gro offload and fd from firmwareGuangbin Huang7-24/+42
As some new devices may not support GRO offload and flow table director, to support these devices, driver needs to querying capabilities of GRO offload and flow table director from firmware. Whether the driver supports these two features depends on capabilities. For old device of version HNAE3_DEVICE_VERSION_V2, driver sets their capabilities of these two features to fixed value. Setting default features of netdev and debugfs also need to identify whether support these two features. Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: thunderbolt: Update module description with mention of USB4Mika Westerberg1-2/+3
It is Thunderbolt/USB4 now so reflect that in the module description too to avoid any confusion. No functional changes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: thunderbolt: Enable full end-to-end flow controlMika Westerberg1-9/+20
USB4NET protocol allows the networking drivers to take advantage of end-to-end flow control supported by the USB4 host interface. This should prevent the receiving side from dropping network packets. In adddition add a module parameter that can be used to turn this off just in case it causes problems. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31thunderbolt: Add back Intel Falcon Ridge end-to-end flow control workaroundMika Westerberg1-7/+42
As we are now enabling full end-to-end flow control to the Thunderbolt networking driver, in order for it to work properly on second generation Thunderbolt hardware (Falcon Ridge), we need to add back the workaround that was removed with commit 53f13319d131 ("thunderbolt: Get rid of E2E workaround"). However, this time we only apply it for Falcon Ridge controllers as a form of an additional quirk. For non-Falcon Ridge this does nothing. While there fix a typo 'reqister' -> 'register' in the comment. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31thunderbolt: Show link type for XDomain connections tooMika Westerberg4-8/+12
Following what we do for routers already, extend this to XDomain connections as well. This will show in sysfs whether the link is in USB4 or Thunderbolt mode. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: thunderbolt: Enable DMA paths only after rings are enabledMika Westerberg1-11/+17
If the other host starts sending packets early on it is possible that we are still in the middle of populating the initial Rx ring packets to the ring. This causes the tbnet_poll() to mess over the queue and causes list corruption. This happens specifically when connected with macOS as it seems start sending various IP discovery packets as soon as its side of the paths are configured. To prevent this we move the DMA path enabling to happen after we have primed the Rx ring. This makes sure no incoming packets can arrive before we are ready to handle them. Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable") Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31phy: lan966x: add support for QUSGMIIMaxime Chevallier1-0/+3
Makes so that the serdes driver also takes QUSGMII in consideration. It's configured exactly as QSGMII as far as the serdes driver is concerned. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: dsa: microchip: remove IS_9893 flagOleksij Rempel3-8/+2
Use chip_id as other places of this code do it Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: dsa: microchip: remove unused sgmii variableOleksij Rempel2-6/+0
This variable is not used. So, remove it. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: dsa: microchip: ksz9477: remove unused "on" variableOleksij Rempel1-2/+0
This variable is not used on ksz9477 side. Remove it. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: dsa: microchip: remove unused port phy variableOleksij Rempel3-7/+0
This variable is unused. So, drop it. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: dsa: microchip: ksz9477: use internal_phy instead of phy_port_cntOleksij Rempel1-13/+7
With code refactoring was introduced new variable internal_phy. Let's use it. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: dsa: microchip: add regmap_range for KSZ9477 chipOleksij Rempel1-0/+272
Add register validation for KSZ9477 Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: dsa: microchip: ksz9477: remove MII_CTRL1000 check from ksz9477_w_phy()Oleksij Rempel1-4/+0
The reason why PHYlib may access MII_CTRL1000 on the chip without GBit support is only if chip provides wrong information about extended caps register. This issue is now handled by ksz9477_r_phy_quirks() With proper regmap_ranges provided for all chips we will be able to catch this kind of bugs any way. So, remove this sanity check. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: dsa: microchip: add regmap_range for KSZ8563 chipOleksij Rempel1-0/+121
Add register validation for KSZ8563. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: dsa: microchip: add support for regmap_access_tablesOleksij Rempel2-4/+45
This is complex driver with support for different chips with different layouts. To detect at least some bugs earlier, we should validate register accesses by using regmap_access_table support. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: dsa: microchip: KSZ9893: do not write to not supported Output Clock ↵Oleksij Rempel1-0/+5
Control Register This issue was detected after adding regmap register access validation. KSZ9893 compatible chips do not have "Output Clock Control Register 0x0103". So, avoid writing to it. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: dsa: microchip: ksz8795: add error handling to ksz8_r/w_phyOleksij Rempel1-21/+81
Now ksz_pread/ksz_pwrite can return error value. So, make use of it. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: dsa: microchip: ksz9477: add error handling to ksz9477_r/w_phyOleksij Rempel1-5/+7
Now ksz_pread/ksz_pwrite can return error value. So, make use of it. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: dsa: microchip: forward error value on all ksz_pread/ksz_pwrite functionsOleksij Rempel1-18/+20
ksz_read*/ksz_write* are able to return errors, so forward it. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: dsa: microchip: allow to pass return values for PHY read/write accessesOleksij Rempel8-20/+34
PHY access may end with errors on different levels. So, allow to forward return values where possible. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: dsa: microchip: don't announce extended register support on non Gbit chipsOleksij Rempel1-0/+11
This issue was detected after adding support of regmap_ranges for KSZ8563R chip. This chip is reporting extended registers support without having actual extended registers. This made PHYlib request not existing registers. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: dsa: microchip: do per-port Gbit detection instead of per-chipOleksij Rempel3-18/+9
KSZ8563 has two 100Mbit PHYs and CPU port with RGMII support. Since 1000Mbit configuration for the RGMII capable MAC is present, we should use per port validation. As main part of migration to per-port validation we need to rework ksz9477_switch_init() function. Which is using undocumented REG_GLOBAL_OPTIONS register to detect per-chip Gbit support. So, it is related to some sort of risk for regressions. To reduce this risk I compared the code with publicly available documentations. This function will executed on following currently supported chips: struct ksz_chip_data OF compatible KSZ9477 KSZ9477 KSZ9897 KSZ9897 KSZ9893 KSZ9893, KSZ9563 KSZ8563 KSZ8563 KSZ9567 KSZ9567 Only KSZ9893, KSZ9563, KSZ8563 document existence of 0xf == REG_GLOBAL_OPTIONS register with bit field description "SKU ID": KSZ9893 0x0C KSZ9563 0x1C KSZ8563 0x3C The existence of hidden flags is not documented. KSZ9477, KSZ9897, KSZ9567 do not document this register at all. Only KSZ8563 is documented as non Gbit chip: 100Mbit PHYs and RGMII CPU port. So, this change should not introduce a regression for configurations with properly used OF compatibles. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31net: dsa: microchip: add separate struct ksz_chip_data for KSZ8563 chipOleksij Rempel3-3/+44
Add separate entry for the KSZ8563 chip. According to the documentation it can support Gbit only on RGMII port. So, we will need to be able to describe in the followup patch. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-31mlxsw: spectrum: Add a copy of 'struct mlxsw_config_profile' for Spectrum-4Amit Cohen1-1/+28
Starting from Spectrum-4, the maximum number of LAG IDs can be configured by software via CONFIG_PROFILE command during driver initialization. Add a dedicated instance of 'struct mlxsw_config_profile' for Spectrum-4 and set the 'max_lag' field to 128, which is the same amount of LAG entries as in Spectrum-{2,3}. Without this configuration, firmware reserves 256 (the value of 'cap_max_lag' resource) entries at beginning of PGT table for LAG identifiers, which means that less entries in PGT will be available. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-31mlxsw: Add a helper function for getting maximum LAG IDAmit Cohen3-11/+36
Currently the driver queries the maximum supported LAG ID from firmware. This will not be accurate anymore once the driver will configure 'max_lag' via CONFIG_PROFILE command. For resource query, firmware returns the maximum LAG ID which is supported by hardware. Software can configure firmware to do not allocate entries for all the supported LAGs, and to limit LAG IDs. In this case, the resource query will not return the actual maximum LAG ID. Add a helper function for getting this value. In case that 'max_lag' field was set during initialization, return the value which was used, otherwise, query firmware for the maximum supported ID. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-31mlxsw: Support configuring 'max_lag' via CONFIG_PROFILEAmit Cohen2-0/+7
In the device, LAG identifiers are stored in the port group table (PGT). During initialization, firmware reserves a certain amount of entries at the beginning of this table for LAG identifiers. In Spectrum-4, the size of the PGT table did not increase, but the maximum number of LAG identifiers was doubled, leaving less room for others entries (e.g., flood entries) that also reside in the PGT. Therefore, in order to avoid a regression and as long as there is no explicit requirement to support 256 LAGs, mlxsw driver will configure the firmware to allocate the same amount of LAG entries (128) as in Spectrum-{2,3}. This configuration is done using 'max_lag' field in CONFIG_PROFILE command. Extend 'struct mlxsw_config_profile' to support 'max_lag' field and configure firmware accordingly. A next patch will adjust Spectrum-4 to configure 'max_lag' field. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-31mlxsw: cmd: Edit the comment of 'max_lag' field in CONFIG_PROFILEAmit Cohen1-0/+3
Starting from Spectrum-4, the maximum number of LAG IDs can be configured by software via CONFIG_PROFILE command during driver initialization. Edit the comment of 'max_lag' field to mention that this field is reserved in Spectrum-1/2/3 and describe firmware behavior. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-31mlxsw: minimal: Return -ENOMEM on allocation failureDan Carpenter1-2/+6
These error paths return success but they should return -ENOMEM. Fixes: 01328e23a476 ("mlxsw: minimal: Extend module to port mapping with slot index") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/YwjgwoJ3M7Kdq9VK@kili Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-31net/mlx5e: Do not use err uninitialized in mlx5e_rep_add_meta_tunnel_rule()Nathan Chancellor1-7/+3
Clang warns: drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:481:6: error: variable 'err' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if (IS_ERR(flow_rule)) { ^~~~~~~~~~~~~~~~~ drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:489:9: note: uninitialized use occurs here return err; ^~~ drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:481:2: note: remove the 'if' if its condition is always true if (IS_ERR(flow_rule)) { ^~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:474:9: note: initialize the variable 'err' to silence this warning int err; ^ = 0 1 error generated. There is little reason to have the 'goto + error variable' construct in this function. Get rid of it and just return the PTR_ERR value in the if statement and 0 at the end. Fixes: 430e2d5e2a98 ("net/mlx5: E-Switch, Move send to vport meta rule creation") Link: https://github.com/ClangBuiltLinux/linux/issues/1695 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/20220825180607.2707947-1-nathan@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-31funeth: remove pointless check of devlink pointer in create/destroy_netdev() ↵Jiri Pirko1-8/+4
flows Once devlink port is successfully registered, the devlink pointer is not NULL. Therefore, the check is going to be always true and therefore pointless. Remove it. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Dimitris Michailidis <dmichail@fungible.com> Link: https://lore.kernel.org/r/20220826110411.1409446-1-jiri@resnulli.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-30net: ngbe: Add build support for ngbeMengyuan Lou6-0/+267
Add build options and guidance doc. Initialize pci device access for Wangxun Gigabit Ethernet devices. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Mengyuan Lou <mengyuanlou@net-swift.com> Link: https://lore.kernel.org/r/20220826034609.51854-1-mengyuanlou@net-swift.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-08-30nfp: add support for eeprom get and set commandBaowen Zheng1-0/+157
Add support for eeprom get and set operation with ethtool command. with this change, we can support commands as: #ethtool -e enp101s0np0 offset 0 length 6 Offset Values ------ ------ 0x0000: 00 15 4d 16 66 33 #ethtool -E enp101s0np0 magic 0x400019ee offset 5 length 1 value 0x88 We make this change to persist MAC change during driver reload and system reboot. Signed-off-by: Baowen Zheng <baowen.zheng@corigine.com> Signed-off-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-08-30nfp: check if application firmware is indifferent to port speedYinjun Zhang4-1/+59
A new tlv type is introduced to indicate if application firmware is indifferent to port speed, and inform management firmware of the result. And the result is always true for flower application firmware since it's indifferent to port speed from the start and will never change. Signed-off-by: Yinjun Zhang <yinjun.zhang@corigine.com> Reviewed-by: Louis Peens <louis.peens@corigine.com> Signed-off-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-08-30nfp: propagate port speed from management firmwareYinjun Zhang6-24/+79
In future releases the NIC application firmware may be indifferent to port speeds - not built for specific port speeds - and consequently it will not be able to report VF port speeds to the driver without first learning them. With this change, the driver will pass the speed of physical ports from management firmware to application firmware, and the latter will copy the speed of port 0 to all the active VFs. So that the driver can get VF port speed as before. The port speed of a VF may be requested from userspace using: ethtool <vf-intf> Signed-off-by: Yinjun Zhang <yinjun.zhang@corigine.com> Reviewed-by: Louis Peens <louis.peens@corigine.com> Signed-off-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-08-29net: sparx5: add support for mrouter portsCasper Andersson4-7/+80
All multicast should be forwarded to mrouter ports. Mrouter ports must therefore be part of all active multicast groups, and override flooding from being disabled. Signed-off-by: Casper Andersson <casper.casan@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-29net: sparx5: add list for mdb entries in driverCasper Andersson3-82/+132
Keep track of all mdb entries in software for easy access. Signed-off-by: Casper Andersson <casper.casan@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-29genetlink: start to validate reserved header bytesJakub Kicinski10-0/+10
We had historically not checked that genlmsghdr.reserved is 0 on input which prevents us from using those precious bytes in the future. One use case would be to extend the cmd field, which is currently just 8 bits wide and 256 is not a lot of commands for some core families. To make sure that new families do the right thing by default put the onus of opting out of validation on existing families. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Acked-by: Paul Moore <paul@paul-moore.com> (NetLabel) Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-27net: fman: memac: Uninitialized variable on error pathDan Carpenter1-1/+1
The "fixed_link" is only allocated sometimes but it's freed unconditionally in the error handling. Set it to NULL so we don't free uninitialized data. Fixes: 9ea4742a55ca ("net: fman: Configure fixed link in memac_initialization") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Sean Anderson <sean.anderson@seco.com> Link: https://lore.kernel.org/r/Ywd2X6gdKmTfYBxD@kili Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-27net: ftmac100: add an opportunity to get ethaddr from the platformSergei Antonov1-0/+5
This driver always generated a random ethernet address. Leave it as a fallback solution, but add a call to platform_get_ethdev_address(). Handle EPROBE_DEFER returned from platform_get_ethdev_address() to retry when EEPROM is ready. Signed-off-by: Sergei Antonov <saproj@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20220824151724.2698107-1-saproj@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-27net: dsa: mv88e6xxx: Allow external SMI if serialMarcus Carlberg1-1/+1
p0_mode set to one of the supported serial mode should not prevent configuring the external SMI interface in mv88e6xxx_g2_scratch_gpio_set_smi. The current masking of the p0_mode only checks the first 2 bits. This results in switches supporting serial mode cannot setup external SMI on certain serial modes (Ex: 1000BASE-X and SGMII). Extend the mask of the p0_mode to include the reduced modes and serial modes as allowed modes for the external SMI interface. Signed-off-by: Marcus Carlberg <marcus.carlberg@axis.com> Link: https://lore.kernel.org/r/20220824093706.19049-1-marcus.carlberg@axis.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-27net/mlx4: Fix error check for dma_map_sgJack Wang1-2/+2
dma_map_sg return 0 on error. Signed-off-by: Jack Wang <jinpu.wang@ionos.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/20220825063533.21015-1-jinpu.wang@ionos.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-27mlx4: Do type_clear() for devlink ports when type_set() was called previouslyJiri Pirko1-0/+3
Whenever the type_set() is called on a devlink port, accompany it by matching type_clear() during cleanup. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20220825114031.1361478-1-jiri@resnulli.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-27net: dsa: mv88e6xxx: support RGMII cmodeMarcus Carlberg2-0/+27
Since the probe defaults all interfaces to the highest speed possible (10GBASE-X in mv88e6393x) before the phy mode configuration from the devicetree is considered it is currently impossible to use port 0 in RGMII mode. This change will allow RGMII modes to be configurable for port 0 enabling port 0 to be configured as RGMII as well as serial depending on configuration. Signed-off-by: Marcus Carlberg <marcus.carlberg@axis.com> Link: https://lore.kernel.org/r/20220822144136.16627-1-marcus.carlberg@axis.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-26Merge tag 'wireless-next-2022-08-26-v2' of ↵David S. Miller44-358/+907
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes berg says: ==================== Various updates: * rtw88: operation, locking, warning, and code style fixes * rtw89: small updates * cfg80211/mac80211: more EHT/MLO (802.11be, WiFi 7) work * brcmfmac: a couple of fixes * misc cleanups etc. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.39.0) at 2025-01-24 01:52:05 +0300