summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-02-12can: m_can: Implement receive coalescingMarkus Schneider-Pargmann
m_can offers the possibility to set an interrupt on reaching a watermark level in the receive FIFO. This can be used to implement coalescing. Unfortunately there is no hardware timeout available to trigger an interrupt if only a few messages were received within a given time. To solve this I am using a hrtimer to wake up the irq thread after x microseconds. The timer is always started if receive coalescing is enabled and new received frames were available during an interrupt. The timer is stopped if during a interrupt handling no new data was available. If the timer is started the new item interrupt is disabled and the watermark interrupt takes over. If the timer is not started again, the new item interrupt is enabled again, notifying the handler about every new item received. Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Link: https://lore.kernel.org/all/20240207093220.2681425-5-msp@baylibre.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2024-02-12can: m_can: Write transmit header and data in one transactionMarkus Schneider-Pargmann
Combine header and data before writing to the transmit fifo to reduce the overhead for peripheral chips. Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/all/20240207093220.2681425-4-msp@baylibre.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2024-02-12can: m_can: Move hrtimer init to m_can_class_registerMarkus Schneider-Pargmann
The hrtimer_init() is called in m_can_plat_probe() and the hrtimer function is set in m_can_class_register(). For readability it is better to keep these two together in m_can_class_register(). Cc: Judith Mendez <jm@ti.com> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/all/20240207093220.2681425-3-msp@baylibre.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2024-02-12can: m_can: Start/Cancel polling timer together with interruptsMarkus Schneider-Pargmann
Interrupts are enabled/disabled in more places than just m_can_start() and m_can_stop(). Couple the polling timer with enabling/disabling of all interrupts to achieve equivalent behavior. Cc: Judith Mendez <jm@ti.com> Fixes: b382380c0d2d ("can: m_can: Add hrtimer to generate software interrupt") Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/all/20240207093220.2681425-2-msp@baylibre.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2024-02-12Merge patch series "can: esd: add support for esd GmbH PCIe/402 CAN interface"Marc Kleine-Budde
Stefan Mätje <stefan.maetje@esd.eu> says: The purpose of this patch is to introduce a new CAN driver to support the esd GmbH 402 family of CAN interface boards. The hardware design is based on a CAN controller implemented in a FPGA attached to a PCIe link. More information on these boards can be found following the links included in the commit message. This patch supports all boards but will operate the CAN-FD capable boards only in Classic-CAN mode. The CAN-FD support will be added when the initial patch has stabilized. The patch is reuses the previous work of my former colleague: Link: https://lore.kernel.org/linux-can/1426592308-23817-1-git-send-email-thomas.koerper@esd.eu The patch is based on the linux-can-next main branch. Changed in v11: No functional, only editorial changes due to feedback on v10. - Make lifetime of macros used for hardware timestamp calculation very short by #undef-ing them after use. - Fixed insertion order of new entry in MAINTAINERS file. Changed in v10: Most changes due to feedback by Vincent Mailhol https://lore.kernel.org/linux-can/CAMZ6RqLOAC930GNOU+pWuoi6FgYwFOuFrSyAzVjvE2fuVgy8oA@mail.gmail.com - Add support for ethtool operations by using default operations provided by the can_dev module for drivers with hardware time stamp support. - Factor out core unregistration into pci402_unregister_core(). - Factor out getting next TX fifo index into acc_tx_fifo_next(). - Stop counting alloc_can_err_skb() failures in rx_dropped statistic. - Add CAN_ERR_CNT flag in CAN error frames as needed. - Rework function acc_reset_fpga(). To clear I^2C bus enable bit is not necessary after FPGA reset. - Simplify struct acc_bmmsg_rxtxdone layout. - Additional non functional changes due to feedback by Vincent - Some spelling corrections: ESDACC -> esdACC Changes in v9: - Fix returning success error code in case of allocation failure in pci402_probe(). Changes in v8: - Rebased to 6.6-rc2 on linux-can-next branch main Changes in v7: - Numerous changes. Find the quoted with inline comments about changes below after the changes list. Stuff that I don't understand and where I have questions is marked with ????. Unfortunately I will be AFK till 28th of November. Changes in v6: - Fixed the statistic handling of RX overrun errors and increase net_device_stats::rx_errors instead of net_device_stats::rx_dropped. - Added a patch to not increase rx statistics when generating a CAN rx error message frame as suggested on the linux-can list. - Added a patch to not not increase rx_bytes statistics for RTR frames as suggested on the linux-can list. The last two patches change the statistics handling from the previous style used in other drivers to the newly suggested one. Changes in v5: - Added the initialization for netdev::dev_port as it is implemented for another CAN driver. See https://lore.kernel.org/linux-can/20211026180553.1953189-1-mailhol.vincent@wanadoo.fr Changes in v4: - Fixed the build failure on ARCH=arm64 that was found by the Intel kernel test robot. See https://lore.kernel.org/linux-can/202109120608.7ZbQXkRh-lkp@intel.com Removed error monitoring code that used GCC's built-in compiler functions for atomic access (__sync_* functions). GCC versions after 9 (tested with "gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04)") don't implement the intrinsic atomic as in-line code but call "__aarch64_ldadd4_acq_rel" on arm64. This GCC support function is not exported by the kernel and therefore the module build post-processing fails. Removed that code because the error monitoring never showed a problem during the development this year. Changes in v3: - Rework the bus-off restart logic in acc_set_mode() and handle_core_msg_errstatechange() to call netif_wake_queue() from the error active event. - Changed pci402_init_card() to allocate a variable sized array of struct acc_core using devm_kcalloc() instead of using a fixed size array in struct pci402_card. - Changed handle_core_msg_txabort() to release aborted TX frames in TX FIFO order. - Fixed the acc_close() function to abort all pending TX request in esdACC controller. - Fixed counting of transmit aborts in handle_core_msg_txabort(). It is now done like in can_flush_echo_skb(). - Fixed handle_core_msg_buserr() to create error frames including the CAN RX and TX error counters that were missing. - Fixed acc_set_bittiming() neither to touch LOM mode setting of esdACC controller nor to enter or leave RESET mode. The esdACC controller is going active on the CAN bus in acc_open() and is going inactive (RESET mode) again in acc_close(). - Rely on the automatic release of memory fetched by devm_kzalloc(). But still use devm_irq_free() explicitely to make sure that the interrupt handler is disconnected at that point. This avoids a possible crash in non-MSI mode due to the IRQ triggered by another device on the same PCI IRQ line. - Changed to use DMA map API instead of pci_*_consistent compatibility wrappers. - Fixed stale email references and updated copyright information. - Removed any traces of future CAN-FD support. Changes in v2: - Avoid warning triggered by -Wshift-count-overflow on architectures with 32-bit dma_addr_t. - Fixed Makefile not to build the kernel module always. Doing this renamed esd402_pci.c to esd_402_pci-core.c as recommended by Marc. previous versions: v1 - https://lore.kernel.org/linux-can/20210728203647.15240-1-Stefan.Maetje@esd.eu v2 - https://lore.kernel.org/linux-can/20210730173805.3926-1-Stefan.Maetje@esd.eu v3 - https://lore.kernel.org/linux-can/20210908164640.23243-1-stefan.maetje@esd.eu v4 - https://lore.kernel.org/linux-can/20210916172152.5127-1-stefan.maetje@esd.eu v5 - https://lore.kernel.org/linux-can/20211109155326.2608822-1-stefan.maetje@esd.eu v6 - https://lore.kernel.org/linux-can/20211201220328.3079270-1-stefan.maetje@esd.eu v7 - https://lore.kernel.org/linux-can/20221106224156.3619334-1-stefan.maetje@esd.eu v8 - https://lore.kernel.org/linux-can/20231025141635.1459606-1-stefan.maetje@esd.eu v9 - https://lore.kernel.org/linux-can/20231107184103.2802678-1-stefan.maetje@esd.eu v10 - https://lore.kernel.org/linux-can/20231120175657.4070921-1-stefan.maetje@esd.eu Link: https://lore.kernel.org/all/20231122160211.2110448-1-stefan.maetje@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2024-02-12can: esd: add support for esd GmbH PCIe/402 CAN interface familyStefan Mätje
This patch adds support for the PCI based PCIe/402 CAN interface family from esd GmbH that is available with various form factors (https://esd.eu/en/products/402-series-can-interfaces). All boards utilize a FPGA based CAN controller solution developed by esd (esdACC). For more information on the esdACC see https://esd.eu/en/products/esdacc. This driver detects all available CAN interface board variants of the family but atm. operates the CAN-FD capable devices in Classic-CAN mode only! A later patch will introduce the CAN-FD functionality in this driver. Co-developed-by: Thomas Körper <thomas.koerper@esd.eu> Signed-off-by: Thomas Körper <thomas.koerper@esd.eu> Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu> Link: https://lore.kernel.org/all/20231122160211.2110448-3-stefan.maetje@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2024-02-12MAINTAINERS: add Stefan Mätje as maintainer for the esd electronics GmbH ↵Stefan Mätje
PCIe/402 CAN drivers Adding myself (Stefan Mätje) as a maintainer for the upcoming driver of the PCIe/402 interface card family. Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu> Link: https://lore.kernel.org/all/20231122160211.2110448-2-stefan.maetje@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2024-02-12can: isotp: support dynamic flow control parametersOliver Hartkopp
The ISO15765-2 standard supports to take the PDUs communication parameters blocksize (BS) and Separation Time minimum (STmin) either from the first received flow control (FC) "static" or from every received FC "dynamic". Add a new CAN_ISOTP_DYN_FC_PARMS flag to support dynamic FC parameters. Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://lore.kernel.org/all/20231208165729.3011-1-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2024-02-12can: bcm: add recvmsg flags for own, local and remote trafficNicolas Maier
CAN RAW sockets allow userspace to tell if a received CAN frame comes from the same socket, another socket on the same host, or another host. See commit 1e55659ce6dd ("can-raw: add msg_flags to distinguish local traffic"). However, this feature is missing in CAN BCM sockets. Add the same feature to CAN BCM sockets. When reading a received frame (opcode RX_CHANGED) using recvmsg, two flags in msg->msg_flags may be set following the previous convention (from CAN RAW), to distinguish between 'own', 'local' and 'remote' CAN traffic. Update the documentation to reflect this change. Signed-off-by: Nicolas Maier <nicolas.maier.dev@gmail.com> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://lore.kernel.org/all/20240120081018.2319-1-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2024-02-12wifi: rtw89: change qutoa to DBCC by default for WiFi 7 chipsPing-Ke Shih
Since WiFi 7 is expected to support MLO, so we should enable MAC-0/1 and PHY-0/1. By default, set dbcc_en=true, change quota to DBCC mode, and set MLO mode to 2 + 0 that means we only use 2x2 connection on MAC/PHY-0 for now. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-12-pkshih@realtek.com
2024-02-12wifi: rtw89: reference quota mode when setting Tx powerPo-Hao Huang
Reference the current quota mode to avoid misleading warnings. This patch is required after supporting DBCC quota mode. 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://msgid.link/20240209065229.34515-11-pkshih@realtek.com
2024-02-12wifi: rtw89: 8922a: implement AP mode related reg for BE generationChih-Kang Chang
Modify reg for BE generation when AP stop, otherwise have warning messages "Polling beacon packet empty fail". Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-10-pkshih@realtek.com
2024-02-12wifi: rtw89: 8922a: correct register definition and merge IO for ↵Ping-Ke Shih
ctrl_nbtg_bt_tx() ctrl_nbtg_bt_tx is used to control AGC settings under non-shared path condition, which is affected by BT TX. To speed up IO, merge continual bit mask into one IO. Also, correct a register definition. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-9-pkshih@realtek.com
2024-02-12wifi: rtw89: differentiate narrow_bw_ru_dis setting according to chip genZong-Zhe Yang
When there are OBSS that cannot interpret 26-tone RU transmissions, we should disable 26-tone RU HE TB PPDU transmissions. So, add registers accordingly. 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://msgid.link/20240209065229.34515-8-pkshih@realtek.com
2024-02-12wifi: rtw89: use PLCP information to match BSS_COLOR and AIDPing-Ke Shih
Hardware can use spatial reuse to reduce interference in OBSS environment, and originally use MAC header to match BSS color and AID. Change to use PLCP to match them earlier to prevent margin timing. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-7-pkshih@realtek.com
2024-02-12wifi: rtw89: mac: reset PHY-1 hardware when going to enable/disablePing-Ke Shih
When going to use PHY-1, reset the hardware to make it work properly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-6-pkshih@realtek.com
2024-02-12wifi: rtw89: mac: correct MUEDCA setting for MAC-1Ping-Ke Shih
Consider mac_idx as an argument to set this register to disable QoS NULL update MUEDCA timer. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-5-pkshih@realtek.com
2024-02-12wifi: rtw89: mac: return held quota of DLE when changing MAC-1Ping-Ke Shih
DLE (data link engine) could hold quota when we are going to enable/disable MAC-1 block, so trigger hardware to return all held quota. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-4-pkshih@realtek.com
2024-02-12wifi: rtw89: load BB parameters to PHY-1Ping-Ke Shih
We are going to support MLO/DBCC, so need to load parameter table to PHY-1 as well. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-3-pkshih@realtek.com
2024-02-12wifi: rtw89: correct PHY register offset for PHY-1Ping-Ke Shih
PHY-1 can be seen as a copy of PHY-0, and the difference is their base register address, so add a function to get offset to access PHY-1. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-2-pkshih@realtek.com
2024-02-12wifi: brcmfmac: do not cast hidden SSID attribute value to booleanAlexey Berezhok
In 'brcmf_cfg80211_start_ap()', not assume that NL80211_HIDDEN_SSID_NOT_IN_USE is zero but prefer an explicit check instead. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Alexey Berezhok <a@bayrepo.ru> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240208085121.2430-1-a@bayrepo.ru
2024-02-12wifi: mwifiex: Refactor 1-element array into flexible array in struct ↵Kees Cook
mwifiex_ie_types_chan_list_param_set struct mwifiex_ie_types_chan_list_param_set::chan_scan_param is treated as a flexible array, so convert it into one so that it doesn't trip the array bounds sanitizer[1]. Only a few places were using sizeof() on the whole struct, so adjust those to follow the calculation pattern to avoid including the trailing single element. Examining binary output differences doesn't appear to show any literal size values changing, though it is obfuscated a bit by the compiler adjusting register usage and stack spill slots, etc. Link: https://github.com/KSPP/linux/issues/51 [1] Cc: Brian Norris <briannorris@chromium.org> Cc: Kalle Valo <kvalo@kernel.org> Cc: Dmitry Antipov <dmantipov@yandex.ru> Cc: Johannes Berg <johannes.berg@intel.com> Cc: zuoqilin <zuoqilin@yulong.com> Cc: Ruan Jinjie <ruanjinjie@huawei.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Gustavo A. R. Silva <gustavoars@kernel.org> Cc: linux-wireless@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240207103024.make.423-kees@kernel.org
2024-02-12wifi: wilc1000: correct CRC7 calculationDavid Mosberger-Tang
Document ATWILC1000/ATWILC3000 Baremetal Wi-Fi/BLE Link Controller Software Design Guide https://tinyurl.com/yer2xhyc says that bit 0 of the CRC7 code must always be a 1. I confirmed that today with a logic analyzer: setting bit 0 causes wilc1000 to accept a command with CRC7 enabled, whereas clearing bit 0 causes wilc1000 to reject the command with a CRC error. Signed-off-by: David Mosberger-Tang <davidm@egauge.net> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240207050736.2717641-1-davidm@egauge.net
2024-02-12wifi: rtw89: chan: MCC take reconfig into accountZong-Zhe Yang
During mac80211 reconfig, chanctx ops of multiple channels might not be called in order as normal cases. However, we expect the first active chanctx always to be put at our sub entity index 0. So, if it does not, we do a swap there. Besides, reconfig won't allocate a new chanctx object. So, we should reset the reference count when ops add chanctx. 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://msgid.link/20240206030624.23382-7-pkshih@realtek.com
2024-02-12wifi: rtw89: chan: move handling from add/remove to assign/unassign for MLOZong-Zhe Yang
After MLO, we will need to consider not only active chanctx but also active interfaces (roles) to decide entity things. So in advance, we move handling from chanctx_ops::add/remove to chanctx_ops::assign_vif/unassign_vif. Then, we can recalculate and aware active interfaces' changes. For now, behavior should not be really different, since active chanctx and active interface are one-to-one mapping before MLO. 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://msgid.link/20240206030624.23382-6-pkshih@realtek.com
2024-02-12wifi: rtw89: chan: tweak weight recalc ahead before MLOZong-Zhe Yang
Originally, we consider weight only based on how many chanctxs that mac80211 sets. However, we need to consider both active chanctxs and active interfaces to distinguish MCC (multiple channel concurrent) from impending MLO. Although the logic of handling is extended, for now, behavior might not be different under current condition. 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://msgid.link/20240206030624.23382-5-pkshih@realtek.com
2024-02-12wifi: rtw89: chan: tweak bitmap recalc ahead before MLOZong-Zhe Yang
Originally, we just declared two sub-entity, and according to rolling down mechanism, we ensured that index 0 contained sub-entity as long as there are sub-entity. So, we could use for-loop after deciding the last index. But, we are preparing to expand num of sub-entity for MLO. Then, there won't be just two sub-entity. And, there might be holes between two bits in the bitmap. So, we cannot simply do for-loop as before. Instead, we need to follow the set bits. 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://msgid.link/20240206030624.23382-4-pkshih@realtek.com
2024-02-12wifi: rtw89: chan: add sub-entity swap function to cover replacingZong-Zhe Yang
Originally, we replaced sub-entity of index 0 with another one in some cases. However, we will need a swap here in following implementations. So, we introduce it ahead and change code from replacing to swapping. 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://msgid.link/20240206030624.23382-3-pkshih@realtek.com
2024-02-12wifi: rtw89: drop TIMING_BEACON_ONLY and sync beacon TSF by selfZong-Zhe Yang
Some of our calculation during concurrent mode depend on last beacon TSF. Originally, we just set IEEE80211_HW_TIMING_BEACON_ONLY and get what we want from mac80211. But, IEEE80211_HW_TIMING_BEACON_ONLY will be restricted once we declare MLO. Since we are about to consider the MLO stuffs, so sync beacon TSF by ourselves now and unset IEEE80211_HW_TIMING_BEACON_ONLY. 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://msgid.link/20240206030624.23382-2-pkshih@realtek.com
2024-02-12wifi: wilc1000: set preamble size to auto as default in wilc_init_fw_config()Ajay Singh
WILC driver currently applies some default configuration whenever the firmware is initialized, and sets the default preamble size to short. However, despite this passed option, firmware is also able to successfully connect to access points only using long preamble, so this setting does not really enforce short preambles and is misleading regarding applied configuration. Update default configuration and make it match the firmware behavior by passing the existing WILC_FW_PREAMBLE_AUTO value (2 instead of 0). The updated setting does not really alter firmware behavior since it is still capable to connect to both short preamble and long preamble access points, but at list the setting now expresses for real the corresponding firmware behavior. More info: it has been implemented to address the transmission (Tx) blackout issue observed in the 802.11b mode. The modification has no impact on the other modes, which will continue to work as they did in the previous implementation. This change will allow the 802.11b transmission (2, 5.5, 11Mbps) to use long preamble. Signed-off-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240115-wilc_1000_fixes-v1-1-54d29463a738@bootlin.com
2024-02-12wifi: mwifiex: use kstrtoX_from_user() in debugfs handlersDmitry Antipov
Use convenient 'kstrtou32_from_user()' in 'mwifiex_verext_write()' and 'kstrtobool_from_user()' in 'mwifiex_timeshare_coex_write()', respectively. Compile tested only. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240110115314.421298-1-dmantipov@yandex.ru
2024-02-12Merge tag 'vfs-6.8-rc5.fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull vfs fixes from Christian Brauner: - Fix performance regression introduced by moving the security permission hook out of do_clone_file_range() and into its caller vfs_clone_file_range(). This causes the security hook to be called in situation were it wasn't called before as the fast permission checks were left in do_clone_file_range(). Fix this by merging the two implementations back together and restoring the old ordering: fast permission checks first, expensive ones later. - Tweak mount_setattr() permission checking so that mount properties on the real rootfs can be changed. When we added mount_setattr() we added additional checks compared to legacy mount(2). If the mount had a parent then verify that the caller and the mount namespace the mount is attached to match and if not make sure that it's an anonymous mount. But the real rootfs falls into neither category. It is neither an anoymous mount because it is obviously attached to the initial mount namespace but it also obviously doesn't have a parent mount. So that means legacy mount(2) allows changing mount properties on the real rootfs but mount_setattr(2) blocks this. This causes regressions (See the commit for details). Fix this by relaxing the check. If the mount has a parent or if it isn't a detached mount, verify that the mount namespaces of the caller and the mount are the same. Technically, we could probably write this even simpler and check that the mount namespaces match if it isn't a detached mount. But the slightly longer check makes it clearer what conditions one needs to think about. * tag 'vfs-6.8-rc5.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: fs: relax mount_setattr() permission checks remap_range: merge do_clone_file_range() into vfs_clone_file_range()
2024-02-12regmap: kunit: Ensure that changed bytes are actually differentMark Brown
During the cache sync test we verify that values we expect to have been written only to the cache do not appear in the hardware. This works most of the time but since we randomly generate both the original and new values there is a low probability that these values may actually be the same. Wrap get_random_bytes() to ensure that the values are different, there are other tests which should have similar verification that we actually changed something. While we're at it refactor the test to use three changed values rather than attempting to use one of them twice, that just complicates checking that our new values are actually new. We use random generation to try to avoid data dependencies in the tests. Reported-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://msgid.link/r/20240211-regmap-kunit-random-change-v3-1-e387a9ea4468@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-12spi: intel-pci: Add support for Lunar Lake-M SPI serial flashMika Westerberg
Add Intel Lunar Lake-M PCI ID to the driver list of supported devices. This is the same controller found in previous generations. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://msgid.link/r/20240212082027.2462849-1-mika.westerberg@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-12spi: omap2-mcspi: Revert FIFO support without DMAVaishnav Achath
MCSPI controller have few limitations regarding the transaction size when the FIFO buffer is enabled and the WCNT feature is used to find the end of word, in this case if WCNT is not a multiple of the FIFO Almost Empty Level (AEL), then the FIFO empty event is not generated correctly. In addition to this limitation, few other unknown sequence of events that causes the FIFO empty status to not reflect the exact status were found when FIFO is being used without DMA enabled during extended testing in AM65x platform. Till the exact root cause is found and fixed, revert the FIFO support without DMA. See J721E Technical Reference Manual (SPRUI1C), section 12.1.5 for further details: http://www.ti.com/lit/pdf/spruil1 This reverts commit 75223bbea840e ("spi: omap2-mcspi: Add FIFO support without DMA") Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com> Link: https://msgid.link/r/20240212120049.438495-1-vaishnav.a@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-12Merge branch 'net-avoid-slow-rcu'David S. Miller
Eric Dumazet says: ==================== net: avoid slow rcu synchronizations in cleanup_net() RTNL is a contended mutex, we prefer to expedite rcu synchronizations in contexts we hold RTNL. Similarly, cleanup_net() is a single threaded critical component and should also use synchronize_rcu_expedited() even when not holding RTNL. First patch removes a barrier with no clear purpose in ipv6_mc_down() ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-12netfilter: conntrack: expedite rcu in nf_conntrack_cleanup_net_listEric Dumazet
nf_conntrack_cleanup_net_list() is calling synchronize_net() while RTNL is not held. This effectively calls synchronize_rcu(). synchronize_rcu() is much slower than synchronize_rcu_expedited(), and cleanup_net() is currently single threaded. In many workloads we want cleanup_net() to be faster, in order to free memory and various sysfs and procfs entries as fast as possible. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Pablo Neira Ayuso <pablo@netfilter.org> Cc: Jozsef Kadlecsik <kadlec@netfilter.org> Cc: Florian Westphal <fw@strlen.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-12net: use synchronize_rcu_expedited in cleanup_net()Eric Dumazet
cleanup_net() is calling synchronize_rcu() right before acquiring RTNL. synchronize_rcu() is much slower than synchronize_rcu_expedited(), and cleanup_net() is currently single threaded. In many workloads we want cleanup_net() to be fast, in order to free memory and various sysfs and procfs entries as fast as possible. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-12ipv4/fib: use synchronize_net() when holding RTNLEric Dumazet
tnode_free() should use synchronize_net() instead of syncronize_rcu() to release RTNL sooner. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-12bridge: vlan: use synchronize_net() when holding RTNLEric Dumazet
br_vlan_flush() and nbp_vlan_flush() should use synchronize_net() instead of syncronize_rcu() to release RTNL sooner. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-12net: use synchronize_net() in dev_change_name()Eric Dumazet
dev_change_name() holds RTNL, we better use synchronize_net() instead of plain synchronize_rcu(). Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-12ipv6: mcast: remove one synchronize_net() barrier in ipv6_mc_down()Eric Dumazet
As discussed in the past (commit 2d3916f31891 ("ipv6: fix skb drops in igmp6_event_query() and igmp6_event_report()")) I think the synchronize_net() call in ipv6_mc_down() is not needed. Under load, synchronize_net() can last between 200 usec and 5 ms. KASAN seems to agree as well. Fixes: f185de28d9ae ("mld: add new workqueues for process mld events") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Taehee Yoo <ap420073@gmail.com> Cc: Cong Wang <xiyou.wangcong@gmail.com> Cc: David Ahern <dsahern@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-12net: sysfs: Fix /sys/class/net/<iface> path for statisticsBreno Leitao
The Documentation/ABI/testing/sysfs-class-net-statistics documentation is pointing to the wrong path for the interface. Documentation is pointing to /sys/class/<iface>, instead of /sys/class/net/<iface>. Fix it by adding the `net/` directory before the interface. Fixes: 6044f9700645 ("net: sysfs: document /sys/class/net/statistics/*") Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-12Merge branch 'eth-common-fault-irq-support'David S. Miller
Suraj Jaiswal says: ==================== Ethernet common fault IRQ support Changes since v13: - Update correct sender email Changes since v12: - Update correct sender email Changes since v11: - Update debug message print Changes since v10: - Update commit message Changes since v9: - prevent race condition of safety IRQ handling Changes since v8: - Use shared IRQ for sfty - update error message Changes since v7: - Add support of common sfty irq on stmmac_request_irq_multi_msi. - Remove uncecessary blank line. Changes since v6: - use name sfty_irq instead of safety_common_irq. Changes since v5: - Add description of ECC, DPP, FSM Changes since v4: - Fix DT_CHECKER warning - use name safety for the IRQ. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-12net: stmmac: Add driver support for common safety IRQSuraj Jaiswal
Add support to listen HW safety IRQ like ECC(error correction code), DPP(data path parity), FSM(finite state machine) fault in common IRQ line. Signed-off-by: Suraj Jaiswal <quic_jsuraj@quicinc.com> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-12dt-bindings: net: qcom,ethqos: add binding doc for safety IRQ for sa8775pSuraj Jaiswal
Add binding doc for safety IRQ. The safety IRQ will be triggered for ECC(error correction code), DPP(data path parity), FSM(finite state machine) error. Signed-off-by: Suraj Jaiswal <quic_jsuraj@quicinc.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-12wifi: iwlwifi: fix #ifdef CONFIG_ACPI checkArnd Bergmann
The #ifdef check around the function definition for two functions was changed without also changing the one on the declaration: drivers/net/wireless/intel/iwlwifi/fw/uefi.c:359:6: error: redefinition of 'iwl_uefi_get_sgom_table' 359 | void iwl_uefi_get_sgom_table(struct iwl_trans *trans, | ^~~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/net/wireless/intel/iwlwifi/fw/uefi.c:11: drivers/net/wireless/intel/iwlwifi/fw/uefi.h:294:6: note: previous definition of 'iwl_uefi_get_sgom_table' with type 'void(struct iwl_trans *, struct iwl_fw_runtime *)' 294 | void iwl_uefi_get_sgom_table(struct iwl_trans *trans, struct iwl_fw_runtime *fwrt) | ^~~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/intel/iwlwifi/fw/uefi.c:392:5: error: redefinition of 'iwl_uefi_get_uats_table' 392 | int iwl_uefi_get_uats_table(struct iwl_trans *trans, | ^~~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/intel/iwlwifi/fw/uefi.h:299:5: note: previous definition of 'iwl_uefi_get_uats_table' with type 'int(struct iwl_trans *, struct iwl_fw_runtime *)' 299 | int iwl_uefi_get_uats_table(struct iwl_trans *trans, | ^~~~~~~~~~~~~~~~~~~~~~~ Adapt it by merging the declarations into the existing #ifdef block. Fixes: 74f4cd710705 ("wifi: iwlwifi: take SGOM and UATS code out of ACPI ifdef") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://msgid.link/20240212112343.1148931-1-arnd@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-12tg3: fix bug caused by uninitialized variableHeiner Kallweit
The reported bug is caused by using mii_eee_cap1_mod_linkmode_t() with an uninitialized bitmap. Fix this by zero-initializing the struct containing the bitmap. Fixes: 9bc791341bc9a5c22b ("tg3: convert EEE handling to use linkmode bitmaps") Reported-by: Srikanth Aithal <sraithal@amd.com> Tested-by: Srikanth Aithal <sraithal@amd.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-12Merge branch 'dsa-realtek-common'David S. Miller
Luiz Angelo Daros de Luca says: ==================== net: dsa: realtek: variants to drivers, interfaces to a common module The current driver consists of two interface modules (SMI and MDIO) and two family/variant modules (RTL8365MB and RTL8366RB). The SMI and MDIO modules serve as the platform and MDIO drivers, respectively, calling functions from the variant modules. In this setup, one interface module can be loaded independently of the other, but both variants must be loaded (if not disabled at build time) for any type of interface. This approach doesn't scale well, especially with the addition of more switch variants (e.g., RTL8366B), leading to loaded but unused modules. Additionally, this also seems upside down, as the specific driver code normally depends on the more generic functions and not the other way around. Each variant module was converted into real drivers, serving as both a platform driver (for switches connected using the SMI interface) and an MDIO driver (for MDIO-connected switches). The relationship between the variant and interface modules is reversed, with the variant module now calling both interface functions (if not disabled at build time). While in most devices only one interface is likely used, the interface code is significantly smaller than a variant module, consuming fewer resources than the previous code. With variant modules now functioning as real drivers, compatible strings are published only in a single variant module, preventing conflicts. The patch series introduces a new common module for functions shared by both variants. This module also absorbs the two previous interface modules, as they would always be loaded anyway. The series relocates the user MII driver from realtek-smi to rtl83xx. It is now used by MDIO-connected switches instead of the generic DSA driver. There's a change in how this driver locates the MDIO node. It now only searches for a child node named "mdio". The dsa_switch in realtek_priv->ds is now embedded in the struct. It is always in use and avoids dynamic memory allocation. Testing has been performed with an RTL8367S (rtl8365mb) using MDIO interface and an RTL8366RB (rtl8366) with SMI interface. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-12net: dsa: realtek: embed dsa_switch into realtek_privLuiz Angelo Daros de Luca
Embed dsa_switch within realtek_priv to eliminate the need for a second memory allocation. Suggested-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit (git 2.34.1) at 2025-09-11 20:21:47 +0000