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>
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: 172db5f91d ("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>
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
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: 16bbc3eb83 ("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
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
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
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
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
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
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
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
Pull xfs fixes from Dave Chinner:
"These are a set of regression fixes discovered on recent kernels. I
was hoping to send this to you a week and half ago, but events out of
my control delayed finalising the changes until early this week.
Whilst the diffstat looks large for this stage of the merge window, a
large chunk of it comes from moving the guts of one function from one
file to another i.e. it's the same code, it is just run in a different
context where it is safe to hold a specific lock. Otherwise the
individual changes are relatively small and straigtht forward.
Summary:
- Propagate unlinked inode list corruption back up to log recovery
(regression fix)
- improve corruption detection for AGFL entries, AGFL indexes and
XEFI extents (syzkaller fuzzer oops report)
- Avoid double perag reference release (regression fix)
- Improve extent merging detection in scrub (regression fix)
- Fix a new undefined high bit shift (regression fix)
- Fix for AGF vs inode cluster buffer deadlock (regression fix)"
* tag 'xfs-6.4-rc5-fixes' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
xfs: collect errors from inodegc for unlinked inode recovery
xfs: validate block number being freed before adding to xefi
xfs: validity check agbnos on the AGFL
xfs: fix agf/agfl verification on v4 filesystems
xfs: fix double xfs_perag_rele() in xfs_filestream_pick_ag()
xfs: fix broken logic when detecting mergeable bmap records
xfs: Fix undefined behavior of shift into sign bit
xfs: fix AGF vs inode cluster buffer deadlock
xfs: defered work could create precommits
xfs: restore allocation trylock iteration
xfs: buffer pins need to hold a buffer reference
David Howells says:
====================
crypto, splice, net: Make AF_ALG handle sendmsg(MSG_SPLICE_PAGES)
Here are patches to make AF_ALG handle the MSG_SPLICE_PAGES internal
sendmsg flag. MSG_SPLICE_PAGES is an internal hint that tells the protocol
that it should splice the pages supplied if it can. The sendpage functions
are then turned into wrappers around that.
This set consists of the following parts:
(1) Move netfs_extract_iter_to_sg() to somewhere more general and rename
it to drop the "netfs" prefix. We use this to extract directly from
an iterator into a scatterlist.
(2) Make AF_ALG use iov_iter_extract_pages(). This has the additional
effect of pinning pages obtained from userspace rather than taking
refs on them. Pages from kernel-backed iterators would not be pinned,
but AF_ALG isn't really meant for use by kernel services.
(3) Change AF_ALG still further to use extract_iter_to_sg().
(4) Make af_alg_sendmsg() support MSG_SPLICE_PAGES support and make
af_alg_sendpage() just a wrapper around sendmsg(). This has to take
refs on the pages pinned for the moment.
(5) Make hash_sendmsg() support MSG_SPLICE_PAGES by simply ignoring it.
hash_sendpage() is left untouched to be removed later, after the
splice core has been changed to call sendmsg().
====================
Link: https://lore.kernel.org/r/20230606130856.1970660-1-dhowells@redhat.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Jiawen Wu says:
====================
TXGBE PHYLINK support
Implement I2C, SFP, GPIO and PHYLINK to setup TXGBE link.
Because our I2C and PCS are based on Synopsys Designware IP-core, extend
the i2c-designware and pcs-xpcs driver to realize our functions.
====================
Link: https://lore.kernel.org/r/20230606092107.764621-1-jiawenwu@trustnetic.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
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>
Michael Chan says:
====================
bnxt_en: Bug fixes
This patchset has the following fixes for bnxt_en:
1. Add missing VNIC ID parameter in the FW message when getting an
updated RSS configuration from the FW.
2. Fix a warning when doing ethtool reset on newer chips.
3. Fix VLAN issue on a VF when a default VLAN is assigned.
4. Fix a problem during DPC (Downstream Port containment) scenario.
5. Fix a NULL pointer dereference when receiving a PTP event from FW.
6. Fix VXLAN/Geneve UDP port delete/add with newer FW.
====================
Link: https://lore.kernel.org/r/20230607075409.228450-1-michael.chan@broadcom.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
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: 442a35a5a7 ("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>
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: 8bcf6f04d4 ("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>
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: acfb50e4e7 ("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>
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: cf6645f8eb ("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>
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: 7a13240e37 ("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>
Simon Wunderlich says:
====================
Here is a batman-adv bugfix:
- fix a broken sync while rescheduling delayed work,
by Vladislav Efanov
* tag 'batadv-net-pullrequest-20230607' of git://git.open-mesh.org/linux-merge:
batman-adv: Broken sync while rescheduling delayed work
====================
Link: https://lore.kernel.org/r/20230607155515.548120-1-sw@simonwunderlich.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
