summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2023-06-08ice: introduce ICE_TX_TSTAMP_WORK enumerationJacob Keller
The ice_ptp_process_ts() function and its various helper functions return a boolean value indicating whether any work is remaining. This use of a boolean has grown confusing as we have multiple helpers that pass status between each other. Readers must be aware of what "true" and "false" mean, and it is very easy to get their meaning inverted. The names of the functions are not standard "yes/no" questions, which is the best practice for boolean returns. Replace this use of an enumeration with a custom type, enum ice_tx_tstamp_work. This enumeration clearly indicates whether all work is done, or if more work is pending. To aid in readability, factor the actual list iteration and processing out into ice_ptp_process_tx_tstamp(), making it void. Then call this in ice_ptp_tx_tstamp() ensuring that we always check the Tracker list at the end when determining the appropriate return value. Now the return value is an explicit name instead of the true or false value. This is easier to follow and makes reading the resulting callers much simpler. In addition, this paves the way for future work to allow E822 hardware to process timestamps for all functions using a single interrupt on the clock owning PF. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Arpana Arland <arpanax.arland@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-06-08ice: always return IRQ_WAKE_THREAD in ice_misc_intr()Karol Kolacinski
Refactor the ice_misc_intr() function to always return IRQ_WAKE_THREAD, and schedule the service task during the soft IRQ thread function instead of at the end of the hard IRQ handler. Remove the duplicate call to ice_service_task_schedule() that happened when we got a PCI exception. Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Arpana Arland <arpanax.arland@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-06-08ice: handle extts in the miscellaneous interrupt threadKarol Kolacinski
The ice_ptp_extts_work() and ice_ptp_periodic_work() functions are both scheduled on the same kthread worker, pf.ptp.kworker. The ice_ptp_periodic_work() function sends to the firmware to interact with the PHY, and must block to wait for responses. This can cause delay in responding to the PFINT_OICR_TSYN_EVNT interrupt cause, ultimately resulting in disruption to processing an input signal of the frequency is high enough. In our testing, even 100 Hz signals get disrupted. Fix this by instead processing the signal inside the miscellaneous interrupt thread prior to handling Tx timestamps. Use atomic bits in a new pf->misc_thread bitmap in order to safely communicate which tasks require processing within the ice_misc_intr_thread_fn(). This ensures the communication of desired tasks from the ice_misc_intr() are correctly processed without racing even in the event that the interrupt triggers again before the thread function exits. Fixes: 172db5f91d5f ("ice: add support for auxiliary input/output pins") Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Arpana Arland <arpanax.arland@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-06-08wifi: rtlwifi: remove misused flag from HAL dataDmitry Antipov
Always rely on 'driver_is_goingto_unload' of 'struct rtl_hal' and remove (presumably misused) 'driver_going2unload' from it. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230605100700.111644-1-dmantipov@yandex.ru
2023-06-08wifi: rtlwifi: remove unused dualmac control leftoversDmitry Antipov
Remove 'struct rtl_dualmac_easy_concurrent_ctl' of 'struct rtl_priv' and related code in '_rtl_pci_tx_chk_waitq()'. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230602065940.149198-2-dmantipov@yandex.ru
2023-06-08wifi: rtlwifi: remove unused timer and related codeDmitry Antipov
Drop unused 'dualmac_easyconcurrent_retrytimer' of 'struct rtl_works', corresponding 'rtl_easy_concurrent_retrytimer_callback()' handler, 'dualmac_easy_concurrent' function pointer of 'struct rtl_hal_ops' and related call to 'timer_setup()' in '_rtl_init_deferred_work()'. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230602065940.149198-1-dmantipov@yandex.ru
2023-06-08wifi: rsi: Do not set MMC_PM_KEEP_POWER in shutdownMarek Vasut
It makes no sense to set MMC_PM_KEEP_POWER in shutdown. The flag indicates to the MMC subsystem to keep the slot powered on during suspend, but in shutdown the slot should actually be powered off. Drop this call. Fixes: 063848c3e155 ("rsi: sdio: Add WOWLAN support for S5 shutdown state") Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230527222859.273768-1-marex@denx.de
2023-06-08wifi: rsi: Do not configure WoWlan in shutdown hook if not enabledMarek Vasut
In case WoWlan was never configured during the operation of the system, the hw->wiphy->wowlan_config will be NULL. rsi_config_wowlan() checks whether wowlan_config is non-NULL and if it is not, then WARNs about it. The warning is valid, as during normal operation the rsi_config_wowlan() should only ever be called with non-NULL wowlan_config. In shutdown this rsi_config_wowlan() should only ever be called if WoWlan was configured before by the user. Add checks for non-NULL wowlan_config into the shutdown hook. While at it, check whether the wiphy is also non-NULL before accessing wowlan_config . Drop the single-use wowlan_config variable, just inline it into function call. Fixes: 16bbc3eb8372 ("rsi: fix null pointer dereference during rsi_shutdown()") Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230527222833.273741-1-marex@denx.de
2023-06-08wifi: brcmfmac: Detect corner error case earlier with logNeal Sidhwaney
In brcmf_chip_recognition(), the return value from an MMIO read is interpreted as various fields without checking if it failed, which is harmless today, as the interpreted fields are checked for validity a few lines below. However, in corner cases (on my MacbookPro 14,1, sometimes after waking from sleep or soft reboot), when this happens, it causes the logging to be misleading, because the message indicates an unsupported chip type ("brcmfmac: brcmf_chip_recognition: chip backplane type 15 is not supported"). This patch detects this case slightly earlier and logs an appropriate message, with the same return result as is the case today. Signed-off-by: Neal Sidhwaney <nealsid@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230603060021.57225-1-nealsid@gmail.com
2023-06-08wifi: rtw89: 8852c: update RF radio A/B parameters to R63Ping-Ke Shih
Update 8852c radio A/B parameters from internal HALRF_029_00_102 R63. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230602150556.36777-9-pkshih@realtek.com
2023-06-08wifi: rtw89: 8852c: update TX power tables to R63 with 6 GHz power type (3 of 3)Zong-Zhe Yang
Update TX power tables to RF version R63. TX power tables' changes: * TX power byrate: tweak a bit * TX power limit, TX power limit RU, TX power shape: configure values for MEXICO, UKRAINE, CHILE, QATAR tweak a bit on other configured values * 6 GHz TX power limit, 6 GHz TX power limit RU: add an extra dimension for 6 GHz regulatory power type, i.e. STD (standard power), LPI (low power indoor), VLP (very low power) Besides, we adjust TX power handling at 6 GHz in phy to consider 6 GHz regulatory power type. 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/20230602150556.36777-8-pkshih@realtek.com
2023-06-08wifi: rtw89: 8852c: update TX power tables to R63 with 6 GHz power type (2 of 3)Zong-Zhe Yang
Update TX power tables to RF version R63. TX power tables' changes: * TX power byrate: tweak a bit * TX power limit, TX power limit RU, TX power shape: configure values for MEXICO, UKRAINE, CHILE, QATAR tweak a bit on other configured values * 6 GHz TX power limit, 6 GHz TX power limit RU: add an extra dimension for 6 GHz regulatory power type, i.e. STD (standard power), LPI (low power indoor), VLP (very low power) Besides, we adjust TX power handling at 6 GHz in phy to consider 6 GHz regulatory power type. 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/20230602150556.36777-7-pkshih@realtek.com
2023-06-08wifi: rtw89: 8852c: update TX power tables to R63 with 6 GHz power type (1 of 3)Zong-Zhe Yang
Update TX power tables to RF version R63. TX power tables' changes: * TX power byrate: tweak a bit * TX power limit, TX power limit RU, TX power shape: configure values for MEXICO, UKRAINE, CHILE, QATAR tweak a bit on other configured values * 6 GHz TX power limit, 6 GHz TX power limit RU: add an extra dimension for 6 GHz regulatory power type, i.e. STD (standard power), LPI (low power indoor), VLP (very low power) Besides, we adjust TX power handling at 6 GHz in phy to consider 6 GHz regulatory power type. 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/20230602150556.36777-6-pkshih@realtek.com
2023-06-08wifi: rtw89: process regulatory for 6 GHz power typeZong-Zhe Yang
Configure the corresponding power type for 6 GHz regulatory if we can determine one single target. Otherwise, we use the default one. 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/20230602150556.36777-5-pkshih@realtek.com
2023-06-08wifi: rtw89: regd: update regulatory map to R64-R40Zong-Zhe Yang
Update notes: According to Realtek Regulatory R40 and Realtek Channel Plan R64, configure rtw89_regulatory mapping of 6 GHz for more countries and adjust rtw89_regulatory mapping of 2/5 GHz for a few countries. 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/20230602150556.36777-4-pkshih@realtek.com
2023-06-08wifi: rtw89: regd: judge 6 GHz according to chip and BIOSZong-Zhe Yang
We allow platform to disable 6 GHz on chips, which supports 6 GHz, through BIOS. Driver will evaluate Realtek acpi DSM with RTW89_ACPI_DSM_FUNC_6G_DIS (function 3) to get whether 6 GHz should be disabled. 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/20230602150556.36777-3-pkshih@realtek.com
2023-06-08wifi: rtw89: refine clearing supported bands to check 2/5 GHz firstZong-Zhe Yang
We refine to check if supported bands of NL80211_BAND_2GHZ and NL80211_BAND_5GHZ exist before freeing their iftype_data. For now, it does not really encounter problems because all current chips support both 2 GHz and 5 GHz. But, driver actually allows chips to declare whether 2/5 GHz are supported or not. In case some future chips really don't support them, we refine this code. 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/20230602150556.36777-2-pkshih@realtek.com
2023-06-08wifi: rtw89: 8851b: configure CRASH_TRIGGER feature for 8851BZong-Zhe Yang
RTL8851B firmware supports CRASH_TRIGGER feature from v0.29.41.0. After this is configured, debugfs fw_crash can support type 1 on RTL8851B to trigger firmware crash and verify L2 recovery through simulation. 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/20230531060713.57203-5-pkshih@realtek.com
2023-06-08wifi: rtw89: set TX power without precondition during setting channelZong-Zhe Yang
The key condition to check in wrapper of setting TX power is whether entity is active or not. Before entity is active, we restrict TX power from being set by outside callers, e.g. SAR/regulatory. We mark entity as inactive when powering off MAC. Then, we will mark it as active when we initialize HW channel stuffs after MAC power on. Although we can get an active entity after leaving idle phase, TX power doesn't be set well for default channel until stack set target channel for connection. It causes that RF things cannot use better TX power during this interval. Below are some cases which may encounter this or a similar situation. * hw scan process before connection As described above. * right after restart hardware process (SER L2) HW stuffs of target channel is initialized after mac80211 restart hardware, but we unexpectedly need to wait one more command to set channel again or to set TX power. To fix it and improve RF behavior in that interval, during setting channel, we don't need to check entity state before setting TX power, which actually is used to restrict outside callers. It means we call chip ops directly to replace the wrapper call. Then, TX power can be initialized as long as we initialize/setup HW stuffs on one channel. Besides, all chips should configure ops of setting TX power, so we remove trivial check on pointer. 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/20230531060713.57203-4-pkshih@realtek.com
2023-06-08wifi: rtw89: debug: txpwr table access only valid page according to chipZong-Zhe Yang
We now support RTL8851B which has only single RF path. For chip with single RF path, TX power page is valid only in single path section. So, we refine debugfs txpwr table to access TX power page according to RF path number of runtime chip. It can prevent us from reading beyond valid sections. 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/20230531060713.57203-3-pkshih@realtek.com
2023-06-08wifi: rtw89: 8851b: enable hw_scan supportPo-Hao Huang
This enables hw_scan for 8851b after firmware version 0.29.37.1. Extend the channel info struct with padding zeros so newer firmware can work properly, this change is backward compatible with older firmware. Signed-off-by: Po-Hao Huang <phhuang@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/20230531060713.57203-2-pkshih@realtek.com
2023-06-08ice: Don't dereference NULL in ice_gnss_read error pathSimon Horman
If pf is NULL in ice_gnss_read() then it will be dereferenced in the error path by a call to dev_dbg(ice_pf_to_dev(pf), ...). Avoid this by simply returning in this case. If logging is desired an alternate approach might be to use pr_err() before returning. Flagged by Smatch as: .../ice_gnss.c:196 ice_gnss_read() error: we previously assumed 'pf' could be null (see line 131) Fixes: 43113ff73453 ("ice: add TTY for GNSS module for E810T device") Signed-off-by: Simon Horman <horms@kernel.org> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Tested-by: Sunitha Mekala <sunithax.d.mekala@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-06-08net: txgbe: Support phylink MAC layerJiawen Wu
Add phylink support to Wangxun 10Gb Ethernet controller for the 10GBASE-R interface. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-06-08net: txgbe: Implement phylink pcsJiawen Wu
Register MDIO bus for PCS layer to use Synopsys designware XPCS, support 10GBASE-R interface to the controller. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-06-08net: pcs: Add 10GBASE-R mode for Synopsys Designware XPCSJiawen Wu
Add basic support for XPCS using 10GBASE-R interface. This mode will be extended to use interrupt, so set pcs.poll false. And avoid soft reset so that the device using this mode is in the default configuration. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-06-08net: txgbe: Support GPIO to SFP socketJiawen Wu
Register GPIO chip and handle GPIO IRQ for SFP socket. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-06-08net: txgbe: Add SFP module identifyJiawen Wu
Register SFP platform device to get modules information. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Piotr Raczynski <piotr.raczynski@intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-06-08net: txgbe: Register I2C platform deviceJiawen Wu
Register the platform device to use Designware I2C bus master driver. Use regmap to read/write I2C device region from given base offset. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Piotr Raczynski <piotr.raczynski@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-06-08net: txgbe: Register fixed rate clockJiawen Wu
In order for I2C to be able to work in standard mode, register a fixed rate clock for each I2C device. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-06-08net: txgbe: Add software nodes to support phylinkJiawen Wu
Register software nodes for GPIO, I2C, SFP and PHYLINK. Define the device properties. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Piotr Raczynski <piotr.raczynski@intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-06-08bnxt_en: Implement .set_port / .unset_port UDP tunnel callbacksSomnath Kotur
As per the new udp tunnel framework, drivers which need to know the details of a port entry (i.e. port type) when it gets deleted should use the .set_port / .unset_port callbacks. Implementing the current .udp_tunnel_sync callback would mean that the deleted tunnel port entry would be all zeros. This used to work on older firmware because it would not check the input when deleting a tunnel port. With newer firmware, the delete will now fail and subsequent tunnel port allocation will fail as a result. Fixes: 442a35a5a7aa ("bnxt: convert to new udp_tunnel_nic infra") Reviewed-by: Kalesh Anakkur Purayil <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-06-08bnxt_en: Prevent kernel panic when receiving unexpected PHC_UPDATE eventPavan Chebbi
The firmware can send PHC_RTC_UPDATE async event on a PF that may not have PTP registered. In such a case, there will be a null pointer deference for bp->ptp_cfg when we try to handle the event. Fix it by not registering for this event with the firmware if !bp->ptp_cfg. Also, check that bp->ptp_cfg is valid before proceeding when we receive the event. Fixes: 8bcf6f04d4a5 ("bnxt_en: Handle async event when the PHC is updated in RTC mode") Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-06-08bnxt_en: Skip firmware fatal error recovery if chip is not accessibleVikas Gupta
Driver starts firmware fatal error recovery by detecting heartbeat failure or fw reset count register changing. But these checks are not reliable if the device is not accessible. This can happen while DPC (Downstream Port containment) is in progress. Skip firmware fatal recovery if pci_device_is_present() returns false. Fixes: acfb50e4e773 ("bnxt_en: Add FW fatal devlink_health_reporter.") Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-06-08bnxt_en: Query default VLAN before VNIC setup on a VFSomnath Kotur
We need to call bnxt_hwrm_func_qcfg() on a VF to query the default VLAN that may be setup by the PF. If a default VLAN is enabled, the VF cannot support VLAN acceleration on the receive side and the VNIC must be setup to strip out the default VLAN tag. If a default VLAN is not enabled, the VF can support VLAN acceleration on the receive side. The VNIC should be set up to strip or not strip the VLAN based on the RX VLAN acceleration setting. Without this call to determine the default VLAN before calling bnxt_setup_vnic(), the VNIC may not be set up correctly. For example, bnxt_setup_vnic() may set up to strip the VLAN tag based on stale default VLAN information. If RX VLAN acceleration is not enabled, the VLAN tag will be incorrectly stripped and the RX data path will not work correctly. Fixes: cf6645f8ebc6 ("bnxt_en: Add function for VF driver to query default VLAN.") Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-06-08bnxt_en: Don't issue AP reset during ethtool's reset operationSreekanth Reddy
Only older NIC controller's firmware uses the PROC AP reset type. Firmware on 5731X/5741X and newer chips does not support this reset type. When bnxt_reset() issues a series of resets, this PROC AP reset may actually fail on these newer chips because the firmware is not ready to accept this unsupported command yet. Avoid this unnecessary error by skipping this reset type on chips that don't support it. Fixes: 7a13240e3718 ("bnxt_en: fix ethtool_reset_flags ABI violations") Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-06-08bnxt_en: Fix bnxt_hwrm_update_rss_hash_cfg()Pavan Chebbi
We must specify the vnic id of the vnic in the input structure of this firmware message. Otherwise we will get an error from the firmware. Fixes: 98a4322b70e8 ("bnxt_en: update RSS config using difference algorithm") Reviewed-by: Kalesh Anakkur Purayil <kalesh-anakkur.purayil@broadcom.com> Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-06-07net: bcmgenet: Fix EEE implementationFlorian Fainelli
We had a number of short comings: - EEE must be re-evaluated whenever the state machine detects a link change as wight be switching from a link partner with EEE enabled/disabled - tx_lpi_enabled controls whether EEE should be enabled/disabled for the transmit path, which applies to the TBUF block - We do not need to forcibly enable EEE upon system resume, as the PHY state machine will trigger a link event that will do that, too Fixes: 6ef398ea60d9 ("net: bcmgenet: add EEE support") Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/20230606214348.2408018-1-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-07eth: ixgbe: fix the wake conditionJakub Kicinski
Flip the netif_carrier_ok() condition in queue wake logic. When I moved it to inside __netif_txq_completed_wake() I missed negating it. This made the condition ineffective and could probably lead to crashes. Fixes: 301f227fc860 ("net: piggy back on the memory barrier in bql when waking queues") Reviewed-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://lore.kernel.org/r/20230607010826.960226-2-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-07eth: bnxt: fix the wake conditionJakub Kicinski
The down condition should be the negation of the wake condition, IOW when I moved it from: if (cond && wake()) to if (__netif_txq_completed_wake(cond)) Cond should have been negated. Flip it now. This bug leads to occasional crashes with netconsole. It may also lead to queue never waking up in case BQL is not enabled. Reported-by: David Wei <davidhwei@meta.com> Fixes: 08a096780d92 ("bnxt: use new queue try_stop/try_wake macros") Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20230607010826.960226-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-07net: dsa: mv88e6xxx: implement USXGMII mode for mv88e6393xMichal Smulski
Enable USXGMII mode for mv88e6393x chips. Tested on Marvell 88E6191X. Signed-off-by: Michal Smulski <michal.smulski@ooma.com> Link: https://lore.kernel.org/r/20230605174442.12493-1-msmulski2@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-07net/mlx5e: simplify condition after napi budget handling changeJakub Kicinski
Since recent commit budget can't be 0 here. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-06-07mlx5/core: E-Switch, Allocate ECPF vport if it's an eswitch managerBodong Wang
Eswitch vport is needed for eswitch manager when creating LAG, to create egress rules. However, this was not handled when ECPF is an eswitch manager. Signed-off-by: Bodong Wang <bodong@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-06-07net/mlx5: Skip inline mode check after mlx5_eswitch_enable_locked() failureJiri Pirko
Commit bffaa916588e ("net/mlx5: E-Switch, Add control for inline mode") added inline mode checking to esw_offloads_start() with a warning printed out in case there is a problem. Tne inline mode checking was done even after mlx5_eswitch_enable_locked() call failed, which is pointless. Later on, commit 8c98ee77d911 ("net/mlx5e: E-Switch, Add extack messages to devlink callbacks") converted the error/warning prints to extack setting, which caused that the inline mode check error to overwrite possible previous extack message when mlx5_eswitch_enable_locked() failed. User then gets confusing error message. Fix this by skipping check of inline mode after mlx5_eswitch_enable_locked() call failed. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-06-07net/mlx5e: TC, refactor access to hash keyOz Shlomo
Currently, a temp object is filled and used as a key for rhashtable_lookup. Lookups will only works while key remains the first attribute in the relevant rhashtable node object. Fix this by passing a key, instead of a object containing the key. Signed-off-by: Oz Shlomo <ozsh@nvidia.com> Reviewed-by: Paul Blakey <paulb@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-06-07net/mlx5e: Remove RX page cache leftoversTariq Toukan
Remove unused definitions left after the removal of the RX page cache feature. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-06-07net/mlx5e: Expose catastrophic steering error countersLama Kayal
Add generated_pkt_steering_fail and handled_pkt_steering_fail to devlink heatlth reporter. generated_pkt_steering_fail indicates the number of packets dropped due to illegal steering operation within the vport steering domain. handled_pkt_steering_fail indicates the number of packets dropped due to illegal steering operation, originated by the vport. Also, update devlink reporter functionality documentation with the newly exposed counters. Signed-off-by: Lama Kayal <lkayal@nvidia.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-06-07net/mlx5: Enable 4 ports VF LAGShay Drory
Now, after all preparation are done, enable 4 ports VF LAG Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-06-07net/mlx5: LAG, block multiport eswitch LAG in case ldev have more than 2 portsShay Drory
multiport eswitch LAG is not supported over more than two ports. Add a check in order to block multiport eswitch LAG over such devices. Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-06-07net/mlx5: LAG, block multipath LAG in case ldev have more than 2 portsShay Drory
multipath LAG is not supported over more than two ports. Add a check in order to block multipath LAG over such configurations. Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-06-07net/mlx5: LAG, change mlx5_shared_fdb_supported() to staticShay Drory
mlx5_shared_fdb_supported() is used only in a single file. Change the function to be static. Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-07 02:06:22 +0000