summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2022-02-23net/mlx5: Lag, use local variable already defined to access E-SwitchMark Bloch
Use the local variable for dev0 (and add from dev1) instead of using the devices stored in the ldev structure. Makes the code easier to read. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5: E-switch, add drop rule support to ingress ACLMark Bloch
Support inserting an ingress ACL drop rule on the uplink in switchdev mode. This will be used by downstream patches to offload active-backup lag mode. The drop rule (if created) is the first rule in the ACL. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Maor Gottlieb <maorg@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5: E-switch, remove special uplink ingress ACL handlingMark Bloch
As both uplinks set the same metadata there is no need to merge the ACL handling of both into a single one. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Maor Gottlieb <maorg@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5: E-Switch, reserve and use same uplink metadata across portsSunil Rani
When in switchdev mode wire traffic will hit the FDB in one of two scenarios. - Shared FDB, in that case traffic from both physical ports should be tagged by the same metadata value so a single FDB rule could catch traffic from both ports. - Two E-Switches, traffic from each physical port will hit the native E-Switch which means traffic from one physical port can't reach the E-Switch of the other one. Looking at those two scenarios it means we can always use the same metadata value to tag wire traffic regardless of the mode. Reserve a single metadata value to be used to tag wire traffic. Signed-off-by: Sunil Rani <sunrani@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23net/mlx5: Add ability to insert to specific flow groupMark Bloch
If the flow table isn't an autogroup the upper driver has to create the flow groups explicitly. This information can't later be used when creating rules to insert into a specific flow group. Allow such use case. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Maor Gottlieb <maorg@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23mlx5: remove unused static inlinesJakub Kicinski
mlx5 has some unused static inline helpers in include/ while at it also clean static inlines in the driver itself. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-02-23ixgbe: Remove non-inclusive languagePiotr Skajewski
Remove non-inclusive language from the driver. Additionally correct the duplication "from from" reported by checkpatch after the changes above. Signed-off-by: Piotr Skajewski <piotrx.skajewski@intel.com> Tested-by: Dave Switzer <david.switzer@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-02-23ixgbevf: clean up some inconsistent indentingYang Li
Eliminate the follow smatch warning: drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:2756 ixgbevf_alloc_q_vector() warn: inconsistent indenting Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-02-23net: dsa: mv88e6xxx: Add support for bridge port locked modeHans Schultz
Supporting bridge ports in locked mode using the drop on lock feature in Marvell mv88e6xxx switchcores is described in the '88E6096/88E6097/88E6097F Datasheet', sections 4.4.6, 4.4.7 and 5.1.2.1 (Drop on Lock). This feature is implemented here facilitated by the locked port flag. Signed-off-by: Hans Schultz <schultz.hans+netdev@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23drivers/net/ftgmac100: fix DHCP potential failure with systemdHeyi Guo
DHCP failures were observed with systemd 247.6. The issue could be reproduced by rebooting Aspeed 2600 and then running ifconfig ethX down/up. It is caused by below procedures in the driver: 1. ftgmac100_open() enables net interface and call phy_start() 2. When PHY is link up, it calls netif_carrier_on() and then adjust_link callback 3. ftgmac100_adjust_link() will schedule the reset task 4. ftgmac100_reset_task() will then reset the MAC in another schedule After step 2, systemd will be notified to send DHCP discover packet, while the packet might be corrupted by MAC reset operation in step 4. Call ftgmac100_reset() directly instead of scheduling task to fix the issue. Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23drivers/net/ftgmac100: adjust code place for function call dependencyHeyi Guo
This is to prepare for ftgmac100_adjust_link() to call ftgmac100_reset() directly. Only code places are changed. Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23drivers/net/ftgmac100: refactor ftgmac100_reset_task to enable direct ↵Heyi Guo
function call This is to prepare for ftgmac100_adjust_link() to call reset function directly, instead of task schedule. Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: core: Add support for OSFP transceiver modulesDanielle Ratson
The driver can already dump the EEPROM contents of QSFP-DD transceiver modules via its ethtool_ops::get_module_info() and ethtool_ops::get_module_eeprom() callbacks. Add support for OSFP transceiver modules by adding their SFF-8024 Identifier Value (0x19). This is required for future NVIDIA Spectrum-4 based systems that will be equipped with OSFP transceivers. Signed-off-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: Remove resource query checkIdo Schimmel
Since SwitchX-2 support was removed in commit b0d80c013b04 ("mlxsw: Remove Mellanox SwitchX-2 ASIC support"), all the ASICs supported by mlxsw support the resource query command. Therefore, remove the resource query check and always query resources from the device. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: core: Unify method of trap support validationVadim Pasternak
Currently there are several different features defined in 'mlxsw_driver' for trap support validation. There is no reason to have dedicated features for specific traps. Perform validation of all of them by testing feature 'MLXSW_BUS_F_TXRX'. Remove trap capability validation from 'core_env.c' which is redundant after validation has been added to mlxsw_core_trap_register(). Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: spectrum: Remove SP{1,2,3} defines for FW minor and subminorJiri Pirko
The FW minor and subminor versions are the same for all generations of Spectrum ASICs. Unify them into a single set of defines. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: core: Remove unnecessary assertsVadim Pasternak
Remove unnecessary asserts for module index validation. Leave only one that is actually necessary in mlxsw_env_pmpe_listener_func() where the module index is directly read from the firmware event. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: reg: Add "mgpir_" prefix to MGPIR fields commentsVadim Pasternak
Do the same as for other registers and have "mgpir_" prefix for the MGPIR fields. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: core_thermal: Remove obsolete API for query resourceVadim Pasternak
Remove obsolete API mlxsw_core_res_query_enabled(), which is only relevant for end-of-life SwitchX-2 ASICs. Support for these ASICs was removed in commit b0d80c013b04 ("mlxsw: Remove Mellanox SwitchX-2 ASIC support"). Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: core_thermal: Rename labels according to naming conventionVadim Pasternak
Rename labels for error flow handling in order to align with naming convention used in rest of 'mlxsw' code. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: core_hwmon: Fix variable names for hwmon attributesVadim Pasternak
Replace all local variables 'mlwsw_hwmon_attr' by 'mlxsw_hwmon_attr'. All variable prefixes should start with 'mlxsw' according to the naming convention, so 'mlwsw' is changed to 'mlxsw'. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: core_thermal: Avoid creation of virtual hwmon objects by thermal moduleVadim Pasternak
The driver registers with both the hwmon and thermal subsystems. Therefore, there is no need for the thermal subsystem to automatically create hwmon entries upon registration of a thermal zone, as this results in duplicate information. Avoid creation of virtual hwmon objects by thermal subsystem by registering a thermal zone with 'no_hwmon' set to 'true'. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: spectrum_span: Ignore VLAN entries not used by the bridge in mirroringIdo Schimmel
Only VLAN entries installed on the bridge device itself should be considered when checking whether a packet with a specific VLAN can be mirrored via a bridge device. VLAN entries only used to keep context (i.e., entries with 'BRIDGE_VLAN_INFO_BRENTRY' unset) should be ignored. Fix this by preventing mirroring when the VLAN entry does not have the 'BRIDGE_VLAN_INFO_BRENTRY' flag set. Fixes: ddaff5047003 ("mlxsw: spectrum: remove guards against !BRIDGE_VLAN_INFO_BRENTRY") Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: core: Prevent trap group setting if driver does not support EMADVadim Pasternak
Avoid trap group setting if driver is not capable of EMAD support. For example, "mlxsw_minimal" driver works over I2C bus, overs which EMADs cannot be sent. Validation is performed by testing feature 'MLXSW_BUS_F_TXRX'. Fixes: 74e0494d35ac ("mlxsw: core: Move basic_trap_groups_set() call out of EMAD init code") Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23net: dsa: realtek: rtl8365mb: serialize indirect PHY register accessAlvin Šipraga
Realtek switches in the rtl8365mb family can access the PHY registers of the internal PHYs via the switch registers. This method is called indirect access. At a high level, the indirect PHY register access method involves reading and writing some special switch registers in a particular sequence. This works for both SMI and MDIO connected switches. Currently the rtl8365mb driver does not take any care to serialize the aforementioned access to the switch registers. In particular, it is permitted for other driver code to access other switch registers while the indirect PHY register access is ongoing. Locking is only done at the regmap level. This, however, is a bug: concurrent register access, even to unrelated switch registers, risks corrupting the PHY register value read back via the indirect access method described above. Arınç reported that the switch sometimes returns nonsense data when reading the PHY registers. In particular, a value of 0 causes the kernel's PHY subsystem to think that the link is down, but since most reads return correct data, the link then flip-flops between up and down over a period of time. The aforementioned bug can be readily observed by: 1. Enabling ftrace events for regmap and mdio 2. Polling BSMR PHY register for a connected port; it should always read the same (e.g. 0x79ed) 3. Wait for step 2 to give a different value Example command for step 2: while true; do phytool read swp2/2/0x01; done On my i.MX8MM, the above steps will yield a bogus value for the BSMR PHY register within a matter of seconds. The interleaved register access it then evident in the trace log: kworker/3:4-70 [003] ....... 1927.139849: regmap_reg_write: ethernet-switch reg=1004 val=bd phytool-16816 [002] ....... 1927.139979: regmap_reg_read: ethernet-switch reg=1f01 val=0 kworker/3:4-70 [003] ....... 1927.140381: regmap_reg_read: ethernet-switch reg=1005 val=0 phytool-16816 [002] ....... 1927.140468: regmap_reg_read: ethernet-switch reg=1d15 val=a69 kworker/3:4-70 [003] ....... 1927.140864: regmap_reg_read: ethernet-switch reg=1003 val=0 phytool-16816 [002] ....... 1927.140955: regmap_reg_write: ethernet-switch reg=1f02 val=2041 kworker/3:4-70 [003] ....... 1927.141390: regmap_reg_read: ethernet-switch reg=1002 val=0 phytool-16816 [002] ....... 1927.141479: regmap_reg_write: ethernet-switch reg=1f00 val=1 kworker/3:4-70 [003] ....... 1927.142311: regmap_reg_write: ethernet-switch reg=1004 val=be phytool-16816 [002] ....... 1927.142410: regmap_reg_read: ethernet-switch reg=1f01 val=0 kworker/3:4-70 [003] ....... 1927.142534: regmap_reg_read: ethernet-switch reg=1005 val=0 phytool-16816 [002] ....... 1927.142618: regmap_reg_read: ethernet-switch reg=1f04 val=0 phytool-16816 [002] ....... 1927.142641: mdio_access: SMI-0 read phy:0x02 reg:0x01 val:0x0000 <- ?! kworker/3:4-70 [003] ....... 1927.143037: regmap_reg_read: ethernet-switch reg=1001 val=0 kworker/3:4-70 [003] ....... 1927.143133: regmap_reg_read: ethernet-switch reg=1000 val=2d89 kworker/3:4-70 [003] ....... 1927.143213: regmap_reg_write: ethernet-switch reg=1004 val=be kworker/3:4-70 [003] ....... 1927.143291: regmap_reg_read: ethernet-switch reg=1005 val=0 kworker/3:4-70 [003] ....... 1927.143368: regmap_reg_read: ethernet-switch reg=1003 val=0 kworker/3:4-70 [003] ....... 1927.143443: regmap_reg_read: ethernet-switch reg=1002 val=6 The kworker here is polling MIB counters for stats, as evidenced by the register 0x1004 that we are writing to (RTL8365MB_MIB_ADDRESS_REG). This polling is performed every 3 seconds, but is just one example of such unsynchronized access. In Arınç's case, the driver was not using the switch IRQ, so the PHY subsystem was itself doing polling analogous to phytool in the above example. A test module was created [see second Link] to simulate such spurious switch register accesses while performing indirect PHY register reads and writes. Realtek was also consulted to confirm whether this is a known issue or not. The conclusion of these lines of inquiry is as follows: 1. Reading of PHY registers via indirect access will be aborted if, after executing the read operation (via a write to the INDIRECT_ACCESS_CTRL_REG), any register is accessed, other than INDIRECT_ACCESS_STATUS_REG. 2. The PHY register indirect read is only complete when INDIRECT_ACCESS_STATUS_REG reads zero. 3. The INDIRECT_ACCESS_DATA_REG, which is read to get the result of the PHY read, will contain the result of the last successful read operation. If there was spurious register access and the indirect read was aborted, then this register is not guaranteed to hold anything meaningful and the PHY read will silently fail. 4. PHY writes do not appear to be affected by this mechanism. 5. Other similar access routines, such as for MIB counters, although similar to the PHY indirect access method, are actually table access. Table access is not affected by spurious reads or writes of other registers. However, concurrent table access is not allowed. Currently this is protected via mib_lock, so there is nothing to fix. The above statements are corroborated both via the test module and through consultation with Realtek. In particular, Realtek states that this is simply a property of the hardware design and is not a hardware bug. To fix this problem, one must guard against regmap access while the PHY indirect register read is executing. Fix this by using the newly introduced "nolock" regmap in all PHY-related functions, and by aquiring the regmap mutex at the top level of the PHY register access callbacks. Although no issue has been observed with PHY register _writes_, this change also serializes the indirect access method there. This is done purely as a matter of convenience and for reasons of symmetry. Fixes: 4af2950c50c8 ("net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC") Link: https://lore.kernel.org/netdev/CAJq09z5FCgG-+jVT7uxh1a-0CiiFsoKoHYsAWJtiKwv7LXKofQ@mail.gmail.com/ Link: https://lore.kernel.org/netdev/871qzwjmtv.fsf@bang-olufsen.dk/ Reported-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reported-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23net: dsa: realtek: allow subdrivers to externally lock regmapAlvin Šipraga
Currently there is no way for Realtek DSA subdrivers to serialize consecutive regmap accesses. In preparation for a bugfix relating to indirect PHY register access - which involves a series of regmap reads and writes - add a facility for subdrivers to serialize their regmap access. Specifically, a mutex is added to the driver private data structure and the standard regmap is initialized with custom lock/unlock ops which use this mutex. Then, a "nolock" variant of the regmap is added, which is functionally equivalent to the existing regmap except that regmap locking is disabled. Functions that wish to serialize a sequence of regmap accesses may then lock the newly introduced driver-owned mutex before using the nolock regmap. Doing things this way means that subdriver code that doesn't care about serialized register access - i.e. the vast majority of code - needn't worry about synchronizing register access with an external lock: it can just continue to use the original regmap. Another advantage of this design is that, while regmaps with locking disabled do not expose a debugfs interface for obvious reasons, there still exists the original regmap which does expose this interface. This interface remains safe to use even combined with driver codepaths that use the nolock regmap, because said codepaths will use the same mutex to synchronize access. With respect to disadvantages, it can be argued that having near-duplicate regmaps is confusing. However, the naming is rather explicit, and examples will abound. Finally, while we are at it, rename realtek_smi_mdio_regmap_config to realtek_smi_regmap_config. This makes it consistent with the naming realtek_mdio_regmap_config in realtek-mdio.c. Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mt76: mt7921s: fix missing fc type/sub-type for 802.11 pktsDeren Wu
For non-mmio devices, should set fc values to proper txwi config Fixes: 48fab5bbef40 ("mt76: mt7921: introduce mt7921s support") Tested-by: Sean Wang <sean.wang@mediatek.com> Co-developed-by: Leon Yen <Leon.Yen@mediatek.com> Signed-off-by: Leon Yen <Leon.Yen@mediatek.com> Signed-off-by: Deren Wu <deren.wu@mediatek.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-23mt76: mt7915: fix potential memory leak of fw monitor packetsShayne Chen
Free the skb of fw monitor packets. Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-23mt76: mt7915: Fix channel state update error issueBo Jiao
Fix channel state update error issue due to wrong register access for mt7916. Signed-off-by: Sujuan Chen <sujuan.chen@mediatek.com> Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-23mt76: fix endianness errors in reverse_frag0_hdr_transLorenzo Bianconi
Fix ht ctl field size in mt{7615,7915,7921}_reverse_frag0_hdr_trans. Fix the following endianness warnings in mt{7615,7915,7921}_reverse_frag0_hdr_trans: drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:29: warning: cast to restricted __le32 drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:29: warning: restricted __le32 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:29: warning: restricted __le32 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:27: warning: incorrect type in assignment (different base types) drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:27: expected restricted __le16 [usertype] frame_control drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:27: got unsigned long drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:24: warning: cast to restricted __le32 drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:24: warning: restricted __le32 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:24: warning: restricted __le32 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:22: warning: incorrect type in assignment (different base types) drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:22: expected restricted __le16 [usertype] seq_ctrl drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:22: got unsigned long drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:20: warning: cast to restricted __le32 drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:20: warning: restricted __le32 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:20: warning: restricted __le32 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:18: warning: incorrect type in assignment (different base types) drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:18: expected restricted __le32 [usertype] qos_ctrl drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:18: got unsigned long drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:19: warning: cast to restricted __le32 drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:19: warning: restricted __le32 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:19: warning: restricted __le32 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:17: warning: incorrect type in assignment (different base types) drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:17: expected restricted __le32 [usertype] ht_ctrl drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:17: got unsigned long drivers/net/wireless/mediatek/mt76/mt7915/mac.c:448:25: warning: restricted __be16 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:448:38: warning: restricted __be16 degrades to integer drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1450:23: warning: incorrect type in assignment (different base types) drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1450:23: expected unsigned int [usertype] *cur_info drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1450:23: got restricted __le32 * drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1451:34: warning: cast to restricted __le32 Fixes: dc5399a50b45f ("mt76: reverse the first fragmented frame to 802.11") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-23mt76: mt7615: introduce SAR supportLorenzo Bianconi
Add SAR spec support to mt7615 driver to allow configuring SAR power limitations on the frequency ranges from the userland. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-23mt76: mt7915: fix injected MPDU transmission to not use HW A-MSDUJohan Almbladh
Before, the hardware would be allowed to transmit injected 802.11 MPDUs as A-MSDU. This resulted in corrupted frames being transmitted. Now, injected MPDUs are transmitted as-is, without A-MSDU. The fix was verified with frame injection on MT7915 hardware, both with and without the injected frame being encrypted. If the hardware cannot do A-MSDU aggregation on MPDUs, this problem would also be present in the TX path where mac80211 does the 802.11 encapsulation. However, I have not observed any such problem when disabling IEEE80211_HW_SUPPORTS_TX_ENCAP_OFFLOAD to force that mode. Therefore this fix is isolated to injected frames only. The same A-MSDU logic is also present in the mt7921 driver, so it is likely that this fix should be applied there too. I do not have access to mt7921 hardware so I have not been able to test that. Signed-off-by: Johan Almbladh <johan.almbladh@anyfinetworks.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2022-02-23remove the h8300 architectureChristoph Hellwig
Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-02-22ionic: use vmalloc includeShannon Nelson
The ever-vigilant Linux kernel test robot reminded us that we need to use the correct include files to be sure that all the build variations will work correctly. Adding the vmalloc.h include takes care of declaring our use of vzalloc() and vfree(). drivers/net/ethernet/pensando/ionic/ionic_lif.c:396:17: error: implicit declaration of function 'vfree'; did you mean 'kvfree'? drivers/net/ethernet/pensando/ionic/ionic_lif.c:531:21: warning: assignment to 'struct ionic_desc_info *' from 'int' makes pointer from integer without a cast Fixes: 116dce0ff047 ("ionic: Use vzalloc for large per-queue related buffers") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Shannon Nelson <snelson@pensando.io> Link: https://lore.kernel.org/r/20220223015731.22025-1-snelson@pensando.io Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-22ibmvnic: schedule failover only if vioctl failsSukadev Bhattiprolu
If client is unable to initiate a failover reset via H_VIOCTL hcall, then it should schedule a failover reset as a last resort. Otherwise, there is no need to do a last resort. Fixes: 334c42414729 ("ibmvnic: improve failover sysfs entry") Reported-by: Cris Forno <cforno12@outlook.com> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com> Signed-off-by: Dany Madden <drt@linux.ibm.com> Link: https://lore.kernel.org/r/20220221210545.115283-1-drt@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-22usbnet: gl620a: Replace one-element array with flexible-array memberGustavo A. R. Silva
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). This issue was found with the help of Coccinelle and audited and fixed, manually. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/79 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20220221173415.GA1149599@embeddedor Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-22net: phy: phylink: fix DSA mac_select_pcs() introductionRussell King (Oracle)
Vladimir Oltean reports that probing on DSA drivers that aren't yet populating supported_interfaces now fails. Fix this by allowing phylink to detect whether DSA actually provides an underlying mac_select_pcs() implementation. Reported-by: Vladimir Oltean <olteanv@gmail.com> Fixes: bde018222c6b ("net: dsa: add support for phylink mac_select_pcs()") Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Tested-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/E1nMCD6-00A0wC-FG@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-22net: dsa: microchip: ksz9477: reduce polling interval for statisticsOleksij Rempel
30 seconds is too long interval especially if it used with ip -s l. Reduce polling interval to 5 sec. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20220221084129.3660124-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-22rtw88: change rtw_info() to proper message levelPing-Ke Shih
Larry reported funny log entries [1] when he used rtl8821ce. These messages are not harmless, but not useful for users, so change them to rtw_dbg() level. By the way, I review all rtw_info() and change others to rtw_warn(). [1] https://lore.kernel.org/linux-wireless/c356d5ae-a7b3-3065-1121-64c446e70333@lwfinger.net/ Reported-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220218035527.9835-1-pkshih@realtek.com
2022-02-22rtw89: Limit the CFO boundaries of x'tal valueYi-Tang Chiu
Set the boundaries of x'tal value to avoid extremely adjusted results, causing severely unexpected CFO. Signed-off-by: Yi-Tang Chiu <chiuyitang@realtek.com> Signed-off-by: Yuan-Han Zhang <yuanhan1020@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220218034537.9338-1-pkshih@realtek.com
2022-02-22rtw89: phy: handle txpwr lmt/lmt_ru of 160M bandwidthZong-Zhe Yang
Add handling to fill struct rtw89_txpwr_limit and rtw89_txpwr_limit_ru for 160Mhz bandwidth case. And enlarge RTW89_5G_BW_NUM because the chip under planning can support 160Mhz bandwidth on 5G band. Moreover, refine the filling of OFDM entry of struct rtw89_txpwr_limit by using the value corresponding to primary channel. E.g. center channel 38 (40Mhz bandwidth case) Originally OFDM entry was filled by value corresponding to 'ch - 2' (36) Now, we consider that it could be 36 or 40. E.g. cneter channel 42 (80Mhz bandwidth case) Originally OFDM entry was filled by value corresponding to 'ch - 6' (36) Now, we consider that it could be 36, 40, 44, or 48. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220218034042.9218-1-pkshih@realtek.com
2022-02-22rtw89: phy: handle txpwr lmt/lmt_ru of 6G bandZong-Zhe Yang
Add declarations of 6G stuff and extend rtw89_channel_to_idx() to map 6G's channels to 6G channel indexes. While 6G, correspondingly read 6G's entry for tx power limit and limit_ru. After this, we should pay attention to chip_info::support_bands. If a chip declares 6G support, it must configure txpwr_lmt_6g and txpwr_lmt_ru_6g in case accessing NULL pointer while setting tx power limit/limit_ru on 6G band. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220218034017.9160-2-pkshih@realtek.com
2022-02-22Merge tag 'iwlwifi-next-for-kalle-2022-02-18' of ↵Kalle Valo
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next iwlwifi patches for v5.18 * Support UHB TAS enablement via BIOS; * Remove a bunch of W=1 warnings; * Add support for channel switch offload; * Support a new FW API command version; * Support 32 Rx AMPDU sessions in newer devices; * Support a few new FW API command versions; * Some debugging infra fixes; * A few fixes in the HE functionality; * Add a few new devices; * A bunch of fixes for W=1 and W=3 warnings; * Add support for a couple of new devices; * Fix a potential buffer underflow; * W=1 warnings clean up continues; * Some improvements and fixes in scanning; * More work on the Bz family of devices; * Add support for band disablement via BIOS; * Bump FW API version; * Fix config structure for one device; * Support a new FW API command version; * Support new queue allocation command; * Some more debugging improvements; * Some other small fixes, clean-ups and improvements.
2022-02-22net: dsa: b53: mark as non-legacyRussell King (Oracle)
The B53 driver does not make use of the speed, duplex, pause or advertisement in its phylink_mac_config() implementation, so it can be marked as a non-legacy driver. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-22net: dsa: b53: switch to using phylink_generic_validate()Russell King (Oracle)
Switch the Broadcom b53 driver to using the phylink_generic_validate() implementation by removing its own .phylink_validate method and associated code. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-22net: dsa: b53: drop use of phylink_helper_basex_speed()Russell King (Oracle)
Now that we have a better method to select SFP interface modes, we no longer need to use phylink_helper_basex_speed() in a driver's validation function. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-22net: dsa: b53: populate supported_interfaces and mac_capabilitiesRussell King (Oracle)
Populate the supported interfaces and MAC capabilities for the Broadcom B53 DSA switches in preparation to using these for the generic validation functionality. The interface modes are derived from: - b53_serdes_phylink_validate() - SRAB mux configuration Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-22net: dsa: b53: clean up if() condition to be more readableRussell King (Oracle)
I've stared at this if() statement for a while trying to work out if it really does correspond with the comment above, and it does seem to. However, let's make it more readable and phrase it in the same way as the comment. Also add a FIXME into the comment - we appear to deny Gigabit modes for 802.3z interface modes, but 802.3z interface modes only operate at gigabit and above. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21net: dm9051: Fix use after free in dm9051_loop_tx()Dan Carpenter
This code dereferences "skb" after calling dev_kfree_skb(). Fixes: 2dc95a4d30ed ("net: Add dm9051 driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220221105440.GA10045@kili Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-21octeontx2-af: cn10k: add workaround for ptp errataNaveen Mamindlapalli
This patch adds workaround for PTP errata given below. 1. At the time of 1 sec rollover of nano-second counter, the nano-second counter is set to 0. However, it should be set to (existing counter_value - 10^9). This leads to an accumulating error in the timestamp value with each sec rollover. 2. Additionally, the nano-second counter currently is rolling over at 'h3B9A_C9FF. It should roll over at 'h3B9A_CA00. The workaround for issue #1 is to speed up the ptp clock by adjusting PTP_CLOCK_COMP register to the desired value to compensate for the nanoseconds lost per each second. The workaround for issue #2 is to slow down the ptp clock such that the rollover occurs at ~1sec. Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com> Signed-off-by: Rakesh Babu Saladi <rsaladi2@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-08 08:31:35 +0000