summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-03-22net: ethernet: ti: am65-cpsw: Enable SGMII mode for J7200Siddharth Vadapalli
TI's J7200 SoC supports SGMII mode with the CPSW5G instance of the CPSW Ethernet Switch. Thus, enable it by adding SGMII mode to the extra_modes member of the "j7200_cpswxg_pdata" SoC data. Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22net: ethernet: ti: am65-cpsw: Add support for SGMII modeSiddharth Vadapalli
Add support for configuring the CPSW Ethernet Switch in SGMII mode. Depending on the SoC, allow selecting SGMII mode as a supported interface, based on the compatible used. Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22net: ethernet: ti: am65-cpsw: Simplify setting supported interfaceSiddharth Vadapalli
Convert the existing IF/ELSE statement based approach of setting the supported_interfaces member of struct "phylink_config", to SWITCH statements. This will help scale to newer PHY-MODES as well as newer compatibles. Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22net: dsa: mt7530: move setting ssc_delta to PHY_INTERFACE_MODE_TRGMII caseArınç ÜNAL
Move setting the ssc_delta variable to under the PHY_INTERFACE_MODE_TRGMII case as it's only needed when trgmii is used. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Link: https://lore.kernel.org/r/20230320190520.124513-3-arinc.unal@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22net: dsa: mt7530: move lowering TRGMII driving to mt7530_setup()Arınç ÜNAL
Move lowering the TRGMII Tx clock driving to mt7530_setup(), after setting the core clock, as seen on the U-Boot MediaTek ethernet driver. Move the code which looks like it lowers the TRGMII Rx clock driving to after the TRGMII Tx clock driving is lowered. This is run after lowering the Tx clock driving on the U-Boot MediaTek ethernet driver as well. This way, the switch should consume less power regardless of port 6 being used. Update the comment explaining mt7530_pad_clk_setup(). Tested rgmii and trgmii modes of port 6 and rgmii mode of port 5 on MCM MT7530 on MT7621AT Unielec U7621-06 and standalone MT7530 on MT7623NI Bananapi BPI-R2. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Link: https://source.denx.de/u-boot/u-boot/-/blob/29a48bf9ccba45a5e560bb564bbe76e42629325f/drivers/net/mtk_eth.c#L682 Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Link: https://lore.kernel.org/r/20230320190520.124513-2-arinc.unal@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22net: dsa: mt7530: move enabling disabling core clock to mt7530_pll_setup()Arınç ÜNAL
Split the code that enables and disables TRGMII clocks and core clock. Move enabling and disabling core clock to mt7530_pll_setup() as it's supposed to be run there. Add 20 ms delay before enabling the core clock as seen on the U-Boot MediaTek ethernet driver. Change the comment for enabling and disabling TRGMII clocks as the code seems to affect both TXC and RXC. Tested rgmii and trgmii modes of port 6 and rgmii mode of port 5 on MCM MT7530 on MT7621AT Unielec U7621-06 and standalone MT7530 on MT7623NI Bananapi BPI-R2. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Link: https://source.denx.de/u-boot/u-boot/-/blob/29a48bf9ccba45a5e560bb564bbe76e42629325f/drivers/net/mtk_eth.c#L589 Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Link: https://lore.kernel.org/r/20230320190520.124513-1-arinc.unal@arinc9.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22liquidio: remove unused IQ_INSTR_MODE_64B functionTom Rix
clang with W=1 reports drivers/net/ethernet/cavium/liquidio/request_manager.c:43:19: error: unused function 'IQ_INSTR_MODE_64B' [-Werror,-Wunused-function] static inline int IQ_INSTR_MODE_64B(struct octeon_device *oct, int iq_no) ^ This function and its macro wrapper are not used, so remove them. Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230321184811.1827306-1-trix@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22net: asix: fix modprobe "sysfs: cannot create duplicate filename"Grant Grundler
"modprobe asix ; rmmod asix ; modprobe asix" fails with: sysfs: cannot create duplicate filename \ '/devices/virtual/mdio_bus/usb-003:004' Issue was originally reported by Anton Lundin on 2022-06-22 (link below). Chrome OS team hit the same issue in Feb, 2023 when trying to find work arounds for other issues with AX88172 devices. The use of devm_mdiobus_register() with usbnet devices results in the MDIO data being associated with the USB device. When the asix driver is unloaded, the USB device continues to exist and the corresponding "mdiobus_unregister()" is NOT called until the USB device is unplugged or unauthorized. So the next "modprobe asix" will fail because the MDIO phy sysfs attributes still exist. The 'easy' (from a design PoV) fix is to use the non-devm variants of mdiobus_* functions and explicitly manage this use in the asix_bind and asix_unbind function calls. I've not explored trying to fix usbnet initialization so devm_* stuff will work. Fixes: e532a096be0e5 ("net: usb: asix: ax88772: add phylib support") Reported-by: Anton Lundin <glance@acc.umu.se> Link: https://lore.kernel.org/netdev/20220623063649.GD23685@pengutronix.de/T/ Tested-by: Eizan Miyamoto <eizan@chromium.org> Signed-off-by: Grant Grundler <grundler@chromium.org> Link: https://lore.kernel.org/r/20230321170539.732147-1-grundler@chromium.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22gve: Cache link_speed value from deviceJoshua Washington
The link speed is never changed for the uptime of a VM, and the current implementation sends an admin queue command for each call. Admin queue command invocations have nontrivial overhead (e.g., VM exits), which can be disruptive to users if triggered frequently. Our telemetry data shows that there are VMs that make frequent calls to this admin queue command. Caching the result of the original admin queue command would eliminate the need to send multiple admin queue commands on subsequent calls to retrieve link speed. Fixes: 7e074d5a76ca ("gve: Enable Link Speed Reporting in the driver.") Signed-off-by: Joshua Washington <joshwash@google.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230321172332.91678-1-joshwash@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22Merge tag 'ipsec-libreswan-mlx5' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux Leon Romanovsky says: ==================== Extend packet offload to fully support libreswan The following patches are an outcome of Raed's work to add packet offload support to libreswan [1]. The series includes: * Priority support to IPsec policies * Statistics per-SA (visible through "ip -s xfrm state ..." command) * Support to IKE policy holes * Fine tuning to acquire logic. [1] https://github.com/libreswan/libreswan/pull/986 Link: https://lore.kernel.org/all/cover.1678714336.git.leon@kernel.org * tag 'ipsec-libreswan-mlx5' of https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux: net/mlx5e: Update IPsec per SA packets/bytes count net/mlx5e: Use one rule to count all IPsec Tx offloaded traffic net/mlx5e: Support IPsec acquire default SA net/mlx5e: Allow policies with reqid 0, to support IKE policy holes xfrm: copy_to_user_state fetch offloaded SA packets/bytes statistics xfrm: add new device offload acquire flag net/mlx5e: Use chains for IPsec policy priority offload net/mlx5: fs_core: Allow ignore_flow_level on TX dest net/mlx5: fs_chains: Refactor to detach chains from tc usage ==================== Link: https://lore.kernel.org/r/20230320094722.1009304-1-leon@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22dt-bindings: net: Drop unneeded quotesRob Herring
Cleanup bindings dropping unneeded quotes. Once all these are fixed, checking for this can be enabled in yamllint. Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> # for bindings/net/can Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> # for bindings/net/toshiba,visconti-dwmac.yaml Reviewed-by: Heiko Stuebner <heiko@sntech.de> #rockchip Link: https://lore.kernel.org/r/20230320233758.2918972-1-robh@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22Merge branch 'net-dsa-b53-configure-6318-and-63268-rgmii-ports'Jakub Kicinski
Álvaro Fernández Rojas says: ==================== net: dsa: b53: configure 6318 and 63268 RGMII ports BCM6318 and BCM63268 need special configuration for their RGMII ports, so we need to be able to identify them as a special BCM63xx switch. In the meantime, let's add some missing BCM63xx SoCs to B53 MMAP device table. This should be applied after "net: dsa: b53: add support for BCM63xx RGMIIs": https://patchwork.kernel.org/project/netdevbpf/patch/20230319220805.124024-1-noltari@gmail.com/ Álvaro Fernández Rojas (4): dt-bindings: net: dsa: b53: add more 63xx SoCs net: dsa: b53: mmap: add more 63xx SoCs net: dsa: b53: mmap: allow passing a chip ID net: dsa: b53: add BCM63268 RGMII configuration .../devicetree/bindings/net/dsa/brcm,b53.yaml | 3 ++ drivers/net/dsa/b53/b53_common.c | 19 +++++++++++- drivers/net/dsa/b53/b53_mmap.c | 29 +++++++++++++++---- drivers/net/dsa/b53/b53_priv.h | 9 +++++- drivers/net/dsa/b53/b53_regs.h | 1 + 5 files changed, 53 insertions(+), 8 deletions(-) ==================== Link: https://lore.kernel.org/r/20230321173359.251778-1-noltari@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22net: dsa: b53: add BCM63268 RGMII configurationÁlvaro Fernández Rojas
BCM63268 requires special RGMII configuration to work. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22net: dsa: b53: mmap: allow passing a chip IDÁlvaro Fernández Rojas
BCM6318 and BCM63268 SoCs require a special handling for their RGMIIs, so we should be able to identify them as a special BCM63xx switch. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22net: dsa: b53: mmap: add more 63xx SoCsÁlvaro Fernández Rojas
BCM6318, BCM6362 and BCM63268 are SoCs with a B53 MMAP switch. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22dt-bindings: net: dsa: b53: add more 63xx SoCsÁlvaro Fernández Rojas
BCM6318, BCM6362 and BCM63268 are SoCs with a B53 MMAP switch. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22ethernet: remove superfluous clearing of phydevWolfram Sang
phy_disconnect() calls phy_detach() which already clears 'phydev' if it is attached to a struct net_device. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20230321131745.27688-1-wsa+renesas@sang-engineering.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22Merge branch 'bnxt-ptp-optimizations'Jakub Kicinski
Pavan Chebbi says: ==================== bnxt PTP optimizations Patches to 1. Enforce software based freq adjustments only on shared PHC NIC 2. A prerequisite change to expand capability storage field to accommodate more Firmware reported capabilities ==================== Link: https://lore.kernel.org/r/20230321144449.15289-1-pavan.chebbi@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22bnxt: Enforce PTP software freq adjustments only when in non-RTC modePavan Chebbi
Currently driver performs software based frequency adjustments when RTC capability is not discovered or when in shared PHC mode. But there may be some old firmware versions that still support hardware freq adjustments without RTC capability being exposed. In this situation driver will use non-realtime mode even on single host NICs. Hence enforce software frequency adjustments only when running in shared PHC mode. Make suitable changes for cyclecounter for the same. Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22bnxt: Defer PTP initialization to after querying function capsPavan Chebbi
Driver uses the flag BNXT_FLAG_MULTI_HOST to determine whether to use non-realtime mode PHC when running on a multi host NIC. However when ptp initializes on a NIC with shared PHC, we still don't have this flag set yet because HWRM_FUNC_QCFG is issued much later. Move the ptp initialization code after we have issued func_qcfg. The next patch will use the BNXT_FLAG_MULTI_HOST flag during PTP initialization. Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22bnxt: Change fw_cap to u64 to accommodate more capability bitsPavan Chebbi
The current fw_cap field (u32) has run out of bits to save any new capability. Change the field to u64. Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Acked-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22tools: ynl: Fix genlmsg header encoding formatsDonald Hunter
The pack strings use 'b' signed char for cmd and version but struct genlmsghdr defines them as unsigned char. Use 'B' instead. Fixes: 4e4480e89c47 ("tools: ynl: move the cli and netlink code around") Signed-off-by: Donald Hunter <donald.hunter@gmail.com> Link: https://lore.kernel.org/r/20230319193803.97453-1-donald.hunter@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22net: enetc: fix aggregate RMON counters not showing the rangesVladimir Oltean
When running "ethtool -S eno0 --groups rmon" without an explicit "--src emac|pmac" argument, the kernel will not report rx-rmon-etherStatsPkts64to64Octets, rx-rmon-etherStatsPkts65to127Octets, etc. This is because on ETHTOOL_MAC_STATS_SRC_AGGREGATE, we do not populate the "ranges" argument. ocelot_port_get_rmon_stats() does things differently and things work there. I had forgotten to make sure that the code is structured the same way in both drivers, so do that now. Fixes: cf52bd238b75 ("net: enetc: add support for MAC Merge statistics counters") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230321232831.1200905-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-22Bluetooth: Remove "Power-on" check from Mesh featureBrian Gix
The Bluetooth mesh experimental feature enable was requiring the controller to be powered off in order for the Enable to work. Mesh is supposed to be enablable regardless of the controller state, and created an unintended requirement that the mesh daemon be started before the classic bluetoothd daemon. Fixes: af6bcc1921ff ("Bluetooth: Add experimental wrapper for MGMT based mesh") Signed-off-by: Brian Gix <brian.gix@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2023-03-22Bluetooth: Fix race condition in hci_cmd_sync_clearMin Li
There is a potential race condition in hci_cmd_sync_work and hci_cmd_sync_clear, and could lead to use-after-free. For instance, hci_cmd_sync_work is added to the 'req_workqueue' after cancel_work_sync The entry of 'cmd_sync_work_list' may be freed in hci_cmd_sync_clear, and causing kernel panic when it is used in 'hci_cmd_sync_work'. Here's the call trace: dump_stack_lvl+0x49/0x63 print_report.cold+0x5e/0x5d3 ? hci_cmd_sync_work+0x282/0x320 kasan_report+0xaa/0x120 ? hci_cmd_sync_work+0x282/0x320 __asan_report_load8_noabort+0x14/0x20 hci_cmd_sync_work+0x282/0x320 process_one_work+0x77b/0x11c0 ? _raw_spin_lock_irq+0x8e/0xf0 worker_thread+0x544/0x1180 ? poll_idle+0x1e0/0x1e0 kthread+0x285/0x320 ? process_one_work+0x11c0/0x11c0 ? kthread_complete_and_exit+0x30/0x30 ret_from_fork+0x22/0x30 </TASK> Allocated by task 266: kasan_save_stack+0x26/0x50 __kasan_kmalloc+0xae/0xe0 kmem_cache_alloc_trace+0x191/0x350 hci_cmd_sync_queue+0x97/0x2b0 hci_update_passive_scan+0x176/0x1d0 le_conn_complete_evt+0x1b5/0x1a00 hci_le_conn_complete_evt+0x234/0x340 hci_le_meta_evt+0x231/0x4e0 hci_event_packet+0x4c5/0xf00 hci_rx_work+0x37d/0x880 process_one_work+0x77b/0x11c0 worker_thread+0x544/0x1180 kthread+0x285/0x320 ret_from_fork+0x22/0x30 Freed by task 269: kasan_save_stack+0x26/0x50 kasan_set_track+0x25/0x40 kasan_set_free_info+0x24/0x40 ____kasan_slab_free+0x176/0x1c0 __kasan_slab_free+0x12/0x20 slab_free_freelist_hook+0x95/0x1a0 kfree+0xba/0x2f0 hci_cmd_sync_clear+0x14c/0x210 hci_unregister_dev+0xff/0x440 vhci_release+0x7b/0xf0 __fput+0x1f3/0x970 ____fput+0xe/0x20 task_work_run+0xd4/0x160 do_exit+0x8b0/0x22a0 do_group_exit+0xba/0x2a0 get_signal+0x1e4a/0x25b0 arch_do_signal_or_restart+0x93/0x1f80 exit_to_user_mode_prepare+0xf5/0x1a0 syscall_exit_to_user_mode+0x26/0x50 ret_from_fork+0x15/0x30 Fixes: 6a98e3836fa2 ("Bluetooth: Add helper for serialized HCI command execution") Cc: stable@vger.kernel.org Signed-off-by: Min Li <lm0963hack@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2023-03-22Bluetooth: btintel: Iterate only bluetooth device ACPI entriesKiran K
Current flow interates over entire ACPI table entries looking for Bluetooth Per Platform Antenna Gain(PPAG) entry. This patch iterates over ACPI entries relvant to Bluetooth device only. Fixes: c585a92b2f9c ("Bluetooth: btintel: Set Per Platform Antenna Gain(PPAG)") Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2023-03-22Bluetooth: ISO: fix timestamped HCI ISO data packet parsingPauli Virtanen
Use correct HCI ISO data packet header struct when the packet has timestamp. The timestamp, when present, goes before the other fields (Core v5.3 4E 5.4.5), so the structs are not compatible. Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2023-03-22Bluetooth: btusb: Remove detection of ISO packets over bulkLuiz Augusto von Dentz
This removes the code introduced by 14202eff214e1e941fefa0366d4c3bc4b1a0d500 as hci_recv_frame is now able to detect ACL packets that are in fact ISO packets. Fixes: 14202eff214e ("Bluetooth: btusb: Detect if an ACL packet is in fact an ISO packet") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2023-03-22Bluetooth: hci_core: Detect if an ACL packet is in fact an ISO packetLuiz Augusto von Dentz
Because some transports don't have a dedicated type for ISO packets (see 14202eff214e1e941fefa0366d4c3bc4b1a0d500) they may use ACL type when in fact they are ISO packets. In the past this was left for the driver to detect such thing but it creates a problem when using the likes of btproxy when used by a VM as the host would not be aware of the connection the guest is doing it won't be able to detect such behavior, so this make bt_recv_frame detect when it happens as it is the common interface to all drivers including guest VMs. Fixes: 14202eff214e ("Bluetooth: btusb: Detect if an ACL packet is in fact an ISO packet") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2023-03-22Bluetooth: hci_sync: Resume adv with no RPA when active scanZhengping Jiang
The address resolution should be disabled during the active scan, so all the advertisements can reach the host. The advertising has to be paused before disabling the address resolution, because the advertising will prevent any changes to the resolving list and the address resolution status. Skipping this will cause the hci error and the discovery failure. According to the bluetooth specification: "7.8.44 LE Set Address Resolution Enable command This command shall not be used when: - Advertising (other than periodic advertising) is enabled, - Scanning is enabled, or - an HCI_LE_Create_Connection, HCI_LE_Extended_Create_Connection, or HCI_LE_Periodic_Advertising_Create_Sync command is outstanding." If the host is using RPA, the controller needs to generate RPA for the advertising, so the advertising must remain paused during the active scan. If the host is not using RPA, the advertising can be resumed after disabling the address resolution. Fixes: 9afc675edeeb ("Bluetooth: hci_sync: allow advertise when scan without RPA") Signed-off-by: Zhengping Jiang <jiangzp@google.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2023-03-22Merge tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-armLinus Torvalds
Pull ARM fix from Russell King: "Just one fix for now to eliminate a KASAN false positive" * tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: 9290/1: uaccess: Fix KASAN false-positives
2023-03-22Merge tag 'bootconfig-fixes-v6.3-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull bootconfig fixes from Masami Hiramatsu: - Fix bootconfig test script to test increased maximum number (8192) node correctly - Change the console message if there is no bootconfig data and the kernel is compiled with CONFIG_BOOT_CONFIG_FORCE=y * tag 'bootconfig-fixes-v6.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: bootconfig: Change message if no bootconfig with CONFIG_BOOT_CONFIG_FORCE=y bootconfig: Fix testcase to increase max node
2023-03-22netfilter: keep conntrack reference until IPsecv6 policy checks are doneMadhu Koriginja
Keep the conntrack reference until policy checks have been performed for IPsec V6 NAT support, just like ipv4. The reference needs to be dropped before a packet is queued to avoid having the conntrack module unloadable. Fixes: 58a317f1061c ("netfilter: ipv6: add IPv6 NAT support") Signed-off-by: Madhu Koriginja <madhu.koriginja@nxp.com> Signed-off-by: Florian Westphal <fw@strlen.de>
2023-03-22xtables: move icmp/icmpv6 logic to xt_tcpudpFlorian Westphal
icmp/icmp6 matches are baked into ip(6)_tables.ko. This means that even if iptables-nft is used, a rule like "-p icmp --icmp-type 1" will load the ip(6)tables modules. Move them to xt_tcpdudp.ko instead to avoid this. This will also allow to eventually add kconfig knobs to build kernels that support iptables-nft but not iptables-legacy (old set/getsockopt interface). Signed-off-by: Florian Westphal <fw@strlen.de>
2023-03-22netfilter: xtables: disable 32bit compat interface by defaultFlorian Westphal
This defaulted to 'y' because before this knob existed the 32bit compat layer was always compiled in if CONFIG_COMPAT was set. 32bit iptables on 64bit kernel isn't common anymore, so remove the default-y now. Signed-off-by: Florian Westphal <fw@strlen.de>
2023-03-22netfilter: nft_masq: deduplicate eval call-backsJeremy Sowden
nft_masq has separate ipv4 and ipv6 call-backs which share much of their code, and an inet one switch containing a switch that calls one of the others based on the family of the packet. Merge the ipv4 and ipv6 ones into the inet one in order to get rid of the duplicate code. Const-qualify the `priv` pointer since we don't need to write through it. Signed-off-by: Jeremy Sowden <jeremy@azazel.net> Signed-off-by: Florian Westphal <fw@strlen.de>
2023-03-22netfilter: nft_redir: use `struct nf_nat_range2` throughout and deduplicate ↵Jeremy Sowden
eval call-backs `nf_nat_redirect_ipv4` takes a `struct nf_nat_ipv4_multi_range_compat`, but converts it internally to a `struct nf_nat_range2`. Change the function to take the latter, factor out the code now shared with `nf_nat_redirect_ipv6`, move the conversion to the xt_REDIRECT module, and update the ipv4 range initialization in the nft_redir module. Replace a bare hex constant for 127.0.0.1 with a macro. Remove `WARN_ON`. `nf_nat_setup_info` calls `nf_ct_is_confirmed`: /* Can't setup nat info for confirmed ct. */ if (nf_ct_is_confirmed(ct)) return NF_ACCEPT; This means that `ct` cannot be null or the kernel will crash, and implies that `ctinfo` is `IP_CT_NEW` or `IP_CT_RELATED`. nft_redir has separate ipv4 and ipv6 call-backs which share much of their code, and an inet one switch containing a switch that calls one of the others based on the family of the packet. Merge the ipv4 and ipv6 ones into the inet one in order to get rid of the duplicate code. Const-qualify the `priv` pointer since we don't need to write through it. Assign `priv->flags` to the range instead of OR-ing it in. Set the `NF_NAT_RANGE_PROTO_SPECIFIED` flag once during init, rather than on every eval. Signed-off-by: Jeremy Sowden <jeremy@azazel.net> Signed-off-by: Florian Westphal <fw@strlen.de>
2023-03-22xdp: bpf_xdp_metadata use EOPNOTSUPP for no driver supportJesper Dangaard Brouer
When driver doesn't implement a bpf_xdp_metadata kfunc the fallback implementation returns EOPNOTSUPP, which indicate device driver doesn't implement this kfunc. Currently many drivers also return EOPNOTSUPP when the hint isn't available, which is ambiguous from an API point of view. Instead change drivers to return ENODATA in these cases. There can be natural cases why a driver doesn't provide any hardware info for a specific hint, even on a frame to frame basis (e.g. PTP). Lets keep these cases as separate return codes. When describing the return values, adjust the function kernel-doc layout to get proper rendering for the return values. Fixes: ab46182d0dcb ("net/mlx4_en: Support RX XDP metadata") Fixes: bc8d405b1ba9 ("net/mlx5e: Support RX XDP metadata") Fixes: 306531f0249f ("veth: Support RX XDP metadata") Fixes: 3d76a4d3d4e5 ("bpf: XDP metadata RX kfuncs") Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> Acked-by: Stanislav Fomichev <sdf@google.com> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com> Acked-by: Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/167940675120.2718408.8176058626864184420.stgit@firesoul Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-03-22mlxsw: spectrum_fid: Fix incorrect local port typeIdo Schimmel
Local port is a 10-bit number, but it was mistakenly stored in a u8, resulting in firmware errors when using a netdev corresponding to a local port higher than 255. Fix by storing the local port in u16, as is done in the rest of the code. Fixes: bf73904f5fba ("mlxsw: Add support for 802.1Q FID family") Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/eace1f9d96545ab8a2775db857cb7e291a9b166b.1679398549.git.petrm@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-03-22selftests/net: Add SHA256 computation over data sent in tcp_mmapXiaoyan Li
Add option to compute and send SHA256 over data sent (-i). This is to ensure the correctness of data received. Data is randomly populated from /dev/urandom. Tested: ./tcp_mmap -s -z -i ./tcp_mmap -z -H $ADDR -i SHA256 is correct ./tcp_mmap -s -i ./tcp_mmap -H $ADDR -i SHA256 is correct Signed-off-by: Coco Li <lixiaoyan@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20230321081202.2370275-2-lixiaoyan@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-03-22net-zerocopy: Reduce compound page head accessXiaoyan Li
When compound pages are enabled, although the mm layer still returns an array of page pointers, a subset (or all) of them may have the same page head since a max 180kb skb can span 2 hugepages if it is on the boundary, be a mix of pages and 1 hugepage, or fit completely in a hugepage. Instead of referencing page head on all page pointers, use page length arithmetic to only call page head when referencing a known different page head to avoid touching a cold cacheline. Tested: See next patch with changes to tcp_mmap Correntess: On a pair of separate hosts as send with MSG_ZEROCOPY will force a copy on tx if using loopback alone, check that the SHA on the message sent is equivalent to checksum on the message received, since the current program already checks for the length. echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages ./tcp_mmap -s -z ./tcp_mmap -H $DADDR -z SHA256 is correct received 2 MB (100 % mmap'ed) in 0.005914 s, 2.83686 Gbit cpu usage user:0.001984 sys:0.000963, 1473.5 usec per MB, 10 c-switches Performance: Run neper between adjacent hosts with the same config tcp_stream -Z --skip-rx-copy -6 -T 20 -F 1000 --stime-use-proc --test-length=30 Before patch: stime_end=37.670000 After patch: stime_end=30.310000 Signed-off-by: Coco Li <lixiaoyan@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20230321081202.2370275-1-lixiaoyan@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-03-22bootconfig: Change message if no bootconfig with CONFIG_BOOT_CONFIG_FORCE=yMasami Hiramatsu (Google)
Change no bootconfig data error message if user do not specify 'bootconfig' option but CONFIG_BOOT_CONFIG_FORCE=y. With CONFIG_BOOT_CONFIG_FORCE=y, the kernel proceeds bootconfig check even if user does not specify 'bootconfig' option. So the current error message is confusing. Let's show just an information message to notice skipping the bootconfig in that case. Link: https://lore.kernel.org/all/167754610254.318944.16848412476667893329.stgit@devnote2/ Fixes: b743852ccc1d ("Allow forcing unconditional bootconfig processing") Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/all/CAMuHMdV9jJvE2y8gY5V_CxidUikCf5515QMZHzTA3rRGEOj6=w@mail.gmail.com/ Suggested-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Tested-by: Paul E. McKenney <paulmck@kernel.org> Acked-by: Mukesh Ojha <quic_mojha@quicinc.com>
2023-03-22wifi: mac80211: fix mesh path discovery based on unicast packetsFelix Fietkau
If a packet has reached its intended destination, it was bumped to the code that accepts it, without first checking if a mesh_path needs to be created based on the discovered source. Fix this by moving the destination address check further down. Cc: stable@vger.kernel.org Fixes: 986e43b19ae9 ("wifi: mac80211: fix receiving A-MSDU frames on mesh interfaces") Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20230314095956.62085-3-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-22wifi: mac80211: fix qos on mesh interfacesFelix Fietkau
When ieee80211_select_queue is called for mesh, the sta pointer is usually NULL, since the nexthop is looked up much later in the tx path. Explicitly check for unicast address in that case in order to make qos work again. Cc: stable@vger.kernel.org Fixes: 50e2ab392919 ("wifi: mac80211: fix queue selection for mesh/OCB interfaces") Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20230314095956.62085-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-22sh_eth: remove open coded netif_running()Wolfram Sang
It had a purpose back in the days, but today we have a handy helper. Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20230321065826.2044-1-wsa+renesas@sang-engineering.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-03-22wifi: iwlwifi: mvm: protect TXQ list manipulationJohannes Berg
Some recent upstream debugging uncovered the fact that in iwlwifi, the TXQ list manipulation is racy. Introduce a new state bit for when the TXQ is completely ready and can be used without locking, and if that's not set yet acquire the lock to check everything correctly. Reviewed-by: Benjamin Berg <benjamin.berg@intel.com> Tested-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-22wifi: iwlwifi: mvm: fix mvmtxq->stopped handlingJohannes Berg
This could race if the queue is redirected while full, then the flushing internally would start it while it's not yet usable again. Fix it by using two state bits instead of just one. Reviewed-by: Benjamin Berg <benjamin.berg@intel.com> Tested-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-22net: ethernet: ti: am65-cpts: adjust estf following ptp changesGrygorii Strashko
When the CPTS clock is synced/adjusted by running linuxptp (ptp4l/phc2sys), it will cause the TSN EST schedule to drift away over time. This is because the schedule is driven by the EstF periodic counter whose pulse length is defined in ref_clk cycles and it does not automatically sync to CPTS clock. _______ _| ^ expected cycle start time boundary _______________ _|_|___|_| ^ EstF drifted away -> direction To fix it, the same PPM adjustment has to be applied to EstF as done to the PHC CPTS clock, in order to correct the TSN EST cycle length and keep them in sync. Drifted cycle: AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230373377017 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230373877017 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230374377017 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230374877017 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230375377017 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230375877023 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230376377018 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230376877018 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635968230377377018 Stable cycle: AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863193375473 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863193875473 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863194375473 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863194875473 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863195375473 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863195875473 AM65_CPTS_EVT: 7 e1:01770001 e2:000000ff t:1635966863196375473 Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Roger Quadros <rogerq@kernel.org> Acked-by: Richard Cochran <richardcochran@gmail.com> Link: https://lore.kernel.org/r/20230321062600.2539544-1-s-vadapalli@ti.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-03-22net-sysfs: display two backlog queue len separatelyJason Xing
Sometimes we need to know which one of backlog queue can be exactly long enough to cause some latency when debugging this part is needed. Thus, we can then separate the display of both. Signed-off-by: Jason Xing <kernelxing@tencent.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230321015746.96994-1-kerneljasonxing@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-03-22virtio/vsock: check transport before skb allocationArseniy Krasnov
Pointer to transport could be checked before allocation of skbuff, thus there is no need to free skbuff when this pointer is NULL. Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> Reviewed-by: Bobby Eshleman <bobby.eshleman@bytedance.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://lore.kernel.org/r/08d61bef-0c11-c7f9-9266-cb2109070314@sberdevices.ru Signed-off-by: Paolo Abeni <pabeni@redhat.com>
generated by cgit (git 2.34.1) at 2025-07-16 02:49:30 +0000