- 15 Mar, 2023 12 commits
-
-
Krzysztof Kozlowski authored
The driver can match only via the DT table so the table should be always used and the of_match_ptr does not have any sense (this also allows ACPI matching via PRP0001, even though it is not relevant here). drivers/net/ethernet/ni/nixge.c:1253:34: error: ‘nixge_dt_ids’ defined but not used [-Werror=unused-const-variable=] Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Krzysztof Kozlowski authored
The driver can match only via the DT table so the table should be always used and the of_match_ptr does not have any sense (this also allows ACPI matching via PRP0001, even though it is not relevant here). drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c:220:34: error: ‘sxgbe_dt_ids’ defined but not used [-Werror=unused-const-variable=] Signed-off-by:
-
Krzysztof Kozlowski authored
The driver can match only via the DT table so the table should be always used and the of_match_ptr does not have any sense (this also allows ACPI matching via PRP0001, even though it is not relevant here). drivers/net/ethernet/marvell/pxa168_eth.c:1575:34: error: ‘pxa168_eth_of_match’ defined but not used [-Werror=unused-const-variable=] Signed-off-by:
-
Krzysztof Kozlowski authored
The driver can match only via the DT table so the table should be always used and the of_match_ptr does not have any sense (this also allows ACPI matching via PRP0001, even though it is not relevant here). drivers/net/ethernet/stmicro/stmmac/dwmac-generic.c:72:34: error: ‘dwmac_generic_match’ defined but not used [-Werror=unused-const-variable=] Signed-off-by:
-
Krzysztof Kozlowski authored
The driver is specific to ARCH_QCOM which depends on OF thus the driver is OF-only. Its of_device_id table is built unconditionally, thus of_match_ptr() for ID table does not make sense. Signed-off-by:
-
David S. Miller authored
Oleksij Rempel says: ==================== net: dsa: microchip: tc-ets support changes v3: - add tc_ets_supported to match supported devices - dynamically regenerated default TC to queue map. - add Acked-by to the first patch changes v2: - run egress limit configuration on all queue separately. Otherwise configuration may not apply correctly. ==================== Signed-off-by: -
Oleksij Rempel authored
Add ETS Qdisc support for KSZ9477 of switches. Current implementation is limited to strict priority mode. Tested on KSZ8563R with following configuration: tc qdisc replace dev lan2 root handle 1: ets strict 4 \ priomap 3 3 2 2 1 1 0 0 ip link add link lan2 name v1 type vlan id 1 \ egress-qos-map 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7 and patched iperf3 version: https://github.com/esnet/iperf/pull/1476 iperf3 -c 172.17.0.1 -b100M -l1472 -t100 -u -R --sock-prio 2 Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Acked-by:
Arun Ramadoss <arun.ramadoss@microchip.com> Signed-off-by:
-
Oleksij Rempel authored
Add ksz_setup_tc_mode() to make queue scheduling and shaping configuration more visible. Signed-off-by:
-
Jakub Kicinski authored
Eric Dumazet says: ==================== ipv6: optimize rt6_score_route() This patch series remove an expensive rwlock acquisition in rt6_check_neigh()/rt6_score_route(). First patch adds missing annotations, and second patch implements the optimization. ==================== Link: https://lore.kernel.org/r/20230313201732.887488-1-edumazet@google.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
rt6_check_neigh() uses read_lock() to protect n->nud_state reading. This seems overkill and causes false sharing. Signed-off-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Reviewed-by:
Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by:
-
Eric Dumazet authored
We have many lockless accesses to n->nud_state. Before adding another one in the following patch, add annotations to readers and writers. Signed-off-by:
-
Horatiu Vultur authored
As the function always returns 0 change the return type to be void instead of int. In this way also remove a wrong message in case of error which would never happen. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by:
Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by:
-
- 14 Mar, 2023 2 commits
-
-
Rob Herring authored
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when we just want to test for presence of a property and nothing more. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230310144716.1544083-1-robh@kernel.orgSigned-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== i40e: support XDP multi-buffer Tirthendu Sarkar says: This patchset adds multi-buffer support for XDP. Tx side already has support for multi-buffer. This patchset focuses on Rx side. The last patch contains actual multi-buffer changes while the previous ones are preparatory patches. On receiving the first buffer of a packet, xdp_buff is built and its subsequent buffers are added to it as frags. While 'next_to_clean' keeps pointing to the first descriptor, the newly introduced 'next_to_process' keeps track of every descriptor for the packet. On receiving EOP buffer the XDP program is called and appropriate action is taken (building skb for XDP_PASS, reusing page for XDP_DROP, adjusting page offsets for XDP_{REDIRECT,TX}). The patchset also streamlines page offset adjustments for buffer reuse to make it easier to post process the rx_buffers after running XDP prog. With this patchset there does not seem to be any performance degradation for XDP_PASS and some improvement (~1% for XDP_TX, ~5% for XDP_DROP) when measured using xdp_rxq_info program from samples/bpf/ for 64B packets. v1: https://lore.kernel.org/netdev/20230306210822.3381942-1-anthony.l.nguyen@intel.com/ * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: i40e: add support for XDP multi-buffer Rx i40e: add xdp_buff to i40e_ring struct i40e: introduce next_to_process to i40e_ring i40e: use frame_sz instead of recalculating truesize for building skb i40e: Change size to truesize when using i40e_rx_buffer_flip() i40e: add pre-xdp page_count in rx_buffer i40e: change Rx buffer size for legacy-rx to support XDP multi-buffer i40e: consolidate maximum frame size calculation for vsi ==================== Link: https://lore.kernel.org/r/20230309212819.1198218-1-anthony.l.nguyen@intel.comSigned-off-by:
-
- 13 Mar, 2023 8 commits
-
-
Pedro Tammela authored
Add tests that check if filters can bind actions, that is create an action independently and then bind to a filter. tdc-tests under category 'infra': 1..18 ok 1 abdc - Reference pedit action object in filter ok 2 7a70 - Reference mpls action object in filter ok 3 d241 - Reference bpf action object in filter ok 4 383a - Reference connmark action object in filter ok 5 c619 - Reference csum action object in filter ok 6 a93d - Reference ct action object in filter ok 7 8bb5 - Reference ctinfo action object in filter ok 8 2241 - Reference gact action object in filter ok 9 35e9 - Reference gate action object in filter ok 10 b22e - Reference ife action object in filter ok 11 ef74 - Reference mirred action object in filter ok 12 2c81 - Reference nat action object in filter ok 13 ac9d - Reference police action object in filter ok 14 68be - Reference sample action object in filter ok 15 cf01 - Reference skbedit action object in filter ok 16 c109 - Reference skbmod action object in filter ok 17 4abc - Reference tunnel_key action object in filter ok 18 dadd - Reference vlan action object in filter Reviewed-by:
Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
Pedro Tammela <pctammela@mojatatu.com> Link: https://lore.kernel.org/r/20230309175554.304824-1-pctammela@mojatatu.comSigned-off-by:
-
Maxim Korotkov authored
The value of an arithmetic expression is subject of possible overflow due to a failure to cast operands to a larger data type before performing arithmetic. Used macro for multiplication instead operator for avoiding overflow. Found by Security Code and Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by:
Maxim Korotkov <korotkov.maxim.s@gmail.com> Reviewed-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://lore.kernel.org/r/20230309174347.3515-1-korotkov.maxim.s@gmail.comSigned-off-by:
-
Jiri Pirko authored
Virtio spec introduced a feature VIRTIO_NET_F_GUEST_HDRLEN which when set implicates that device benefits from knowing the exact size of the header. For compatibility, to signal to the device that the header is reliable driver also needs to set this feature. Without this feature set by driver, device has to figure out the header size itself. Quoting the original virtio spec: "hdr_len is a hint to the device as to how much of the header needs to be kept to copy into each packet" "a hint" might not be clear for the reader what does it mean, if it is "maybe like that" of "exactly like that". This feature just makes it crystal clear and let the device count on the hdr_len being filled up by the exact length of header. Also note the spec already has following note about hdr_len: "Due to various bugs in implementations, this field is not useful as a guarantee of the transport header size." Without this feature the device needs to parse the header in core data path handling. Accurate information helps the device to eliminate such header parsing and directly use the hardware accelerators for GSO operation. virtio_net_hdr_from_skb() fills up hdr_len to skb_headlen(skb). The driver already complies to fill the correct value. Introduce the feature and advertise it. Note that virtio spec also includes following note for device implementation: "Caution should be taken by the implementation so as to prevent a malicious driver from attacking the device by setting an incorrect hdr_len." There is a plan to support this feature in our emulated device. A device of SolidRun offers this feature bit. They claim this feature will save the device a few cycles for every GSO packet. Link: https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v1.2-cs01.html#x1-230006x3Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
Parav Pandit <parav@nvidia.com> Reviewed-by:
Alvaro Karsz <alvaro.karsz@solid-run.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Acked-by:
Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20230309094559.917857-1-jiri@resnulli.usSigned-off-by:
-
Kristian Overskeid authored
If no frames has been exchanged with a node for HSR_NODE_FORGET_TIME, the node will be deleted from the node_db list. If a frame is sent to the node after it is deleted, a netdev_err message for each slave interface is produced. This should not happen with dan nodes because of supervision frames, but can happen often with san nodes, which clutters the kernel log. Since the hsr protocol does not support sans, this is only relevant for the prp protocol. Signed-off-by:
Kristian Overskeid <koverskeid@gmail.com> Link: https://lore.kernel.org/r/20230309092302.179586-1-koverskeid@gmail.comSigned-off-by:
-
Heiner Kallweit authored
Use unified device property API. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/a969f012-1d3b-7a36-51cf-89a5f8f15a9b@gmail.comSigned-off-by:
-
Vincenzo Palazzo authored
suppress unused warnings and fix the error that there is with the W=1 enabled. Warning generated net/socket.c: In function ‘__sys_getsockopt’: net/socket.c:2300:13: error: variable ‘max_optlen’ set but not used [-Werror=unused-but-set-variable] 2300 | int max_optlen; Signed-off-by:
Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Reviewed-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://lore.kernel.org/r/20230310221851.304657-1-vincenzopalazzodev@gmail.comSigned-off-by:
-
Alexander Stein authored
Before putting the PHY into IEEE power down mode, disable IRQs to prevent accessing the PHY once MDIO has already been shutdown. Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20230310074500.3472858-1-alexander.stein@ew.tq-group.comSigned-off-by:
-
Horatiu Vultur authored
Lan8841 has 10 GPIOs and it has 2 events(EVENT_A and EVENT_B). It is possible to assigned the 2 events to any of the GPIOs, but a GPIO can have only 1 event at a time. These events are used to generate periodic signals. It is possible to configure the length, the start time and the period of the signal by configuring the event. Currently the SW uses only EVENT_A to generate the perout. These events are generated by comparing the target time with the PHC time. In case the PHC time is changed to a value bigger than the target time + reload time, then it would generate only 1 event and then it would stop because target time + reload time is small than PHC time. Therefore it is required to change also the target time every time when the PHC is changed. The same will apply also when the PHC time is changed to a smaller value. This was tested using: testptp -L 6,2 testptp -p 1000000000 -w 200000000 Signed-off-by:
-
- 11 Mar, 2023 18 commits
-
-
Muhammad Usama Anjum authored
make versioncheck reports the following: ./drivers/net/ethernet/qlogic/qede/qede.h: 10 linux/version.h not needed. ./drivers/net/ethernet/qlogic/qede/qede_ethtool.c: 7 linux/version.h not needed. So remove linux/version.h from both of these files. Also remove linux/compiler.h while at it as it is also not being used. Signed-off-by:
Muhammad Usama Anjum <usama.anjum@collabora.com> Reviewed-by:
-
Edward Cree authored
EF100 can pop and/or push up to two VLAN tags. Signed-off-by:
Edward Cree <ecree.xilinx@gmail.com> Reviewed-by:
-
Jakub Kicinski authored
Siddharth Vadapalli says: ==================== Update CPSW bindings for Serdes PHY This series adds documentation for the Serdes PHY. Also, the name used to refer to the Serdes PHY in the am65-cpsw driver is updated to match the documented name. Documenting the Serdes PHY bindings was missed out in the already merged series at: https://lore.kernel.org/r/20230104103432.1126403-1-s-vadapalli@ti.com/ This miss was pointed out at: https://lore.kernel.org/r/CAMuHMdW5atq-FuLEL3htuE3t2uO86anLL3zeY7n1RqqMP_rH1g@mail.gmail.com/ v2: https://lore.kernel.org/r/20230308051835.276552-1-s-vadapalli@ti.com/ v1: https://lore.kernel.org/r/20230306094750.159657-1-s-vadapalli@ti.com/ ==================== Link: https://lore.kernel.org/r/20230309073612.431287-1-s-vadapalli@ti.comSigned-off-by:
-
Siddharth Vadapalli authored
The bindings for the am65-cpsw driver use the name "serdes" to refer to the Serdes PHY. Thus, update the name used for the Serdes PHY within the am65_cpsw_init_serdes_phy() function from "serdes-phy" to "serdes". Signed-off-by:
Siddharth Vadapalli <s-vadapalli@ti.com> Signed-off-by:
-
Siddharth Vadapalli authored
Update bindings to include Serdes PHY as an optional PHY, in addition to the existing CPSW MAC's PHY. The CPSW MAC's PHY is required while the Serdes PHY is optional. The Serdes PHY handle has to be provided only when the Serdes is being configured in a Single-Link protocol. Using the name "serdes-phy" to represent the Serdes PHY handle, the am65-cpsw-nuss driver can obtain the Serdes PHY and request the Serdes to be configured. Signed-off-by:
-
Vadim Fedorenko authored
Flashing firmware via devlink flash was failing on PTP OCP devices because it is using Quad SPI mode, but the driver was not properly behaving. With force_irq flag landed it now can be fixed. Signed-off-by:
Vadim Fedorenko <vadfed@meta.com> Link: https://lore.kernel.org/r/20230309105421.2953451-1-vadfed@meta.comSigned-off-by:
-
Jakub Kicinski authored
Merge tag 'wireless-next-2023-03-10' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== wireless-next patches for 6.4 Major changes: cfg80211 * 6 GHz improvements * HW timestamping support * support for randomized auth/deauth TA for PASN privacy (also for mac80211) mac80211 * radiotap TLV and EHT support for the iwlwifi sniffer * HW timestamping support * per-link debugfs for multi-link brcmfmac * support for Apple (M1 Pro/Max) devices iwlwifi * support for a few new devices * EHT sniffer support rtw88 * better support for some SDIO devices (e.g. MAC address from efuse) rtw89 * HW scan support for 8852b * better support for 6 GHz scanning * tag 'wireless-next-2023-03-10' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (84 commits) wifi: iwlwifi: mvm: fix EOF bit reporting wifi: iwlwifi: Do not include radiotap EHT user info if not needed wifi: iwlwifi: mvm: add EHT RU allocation to radiotap wifi: iwlwifi: Update logs for yoyo reset sw changes wifi: iwlwifi: mvm: clean up duplicated defines wifi: iwlwifi: rs-fw: break out for unsupported bandwidth wifi: iwlwifi: Add support for B step of BnJ-Fm4 wifi: iwlwifi: mvm: make flush code a bit clearer wifi: iwlwifi: mvm: avoid UB shift of snif_queue wifi: iwlwifi: mvm: add primary 80 known for EHT radiotap wifi: iwlwifi: mvm: parse FW frame metadata for EHT sniffer mode wifi: iwlwifi: mvm: decode USIG_B1_B7 RU to nl80211 RU width wifi: iwlwifi: mvm: rename define to generic name wifi: iwlwifi: mvm: allow Microsoft to use TAS wifi: iwlwifi: mvm: add all EHT based on data0 info from HW wifi: iwlwifi: mvm: add EHT radiotap info based on rate_n_flags wifi: iwlwifi: mvm: add an helper function radiotap TLVs wifi: radiotap: separate vendor TLV into header/content wifi: iwlwifi: reduce verbosity of some logging events wifi: iwlwifi: Adding the code to get RF name for MsP device ... ==================== Link: https://lore.kernel.org/r/20230310120159.36518-1-johannes@sipsolutions.netSigned-off-by:
-
Jakub Kicinski authored
Russell King says: ==================== Rework SFP A2 access conditionals This series reworks the SFP A2 (diagnostics and control) access so we don't end up testing a variable number of conditions in several places. This also resolves a minor issue where we may have a module indicating that it is not SFF8472 compliant, doesn't implement A2, but fails to set the enhanced option byte to zero, leading to accesses to the A2 page that fail. The first patch adds a new flag "have_a2" which indicates whether we should be accessing the A2 page, and uses this for hwmon. The conditions are kept the same. The second patch extends the check for soft-state polling and control by using this "have_a2" flag (which effectively augments the check to include some level of SFF8472 compliance.) ==================== Link: https://lore.kernel.org/r/ZAoBnqGBnIZzLwpV@shell.armlinux.org.ukSigned-off-by:
-
Russell King (Oracle) authored
The soft state bits are stored in the A2h memory space, and require SFF-8472 compliance. This is what our have_a2 flag tells us, so use this to indicate whether we should attempt to use the soft signals. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by:
-
Russell King (Oracle) authored
The hwmon code wants to know when it is safe to access the A2h data stored in a separate address. We indicate that this is present when we have SFF-8472 compliance and the lack of an address-change sequence., The same conditions are also true if we want to access other controls and status in the A2h address. So let's make a flag to indicate whether we can access it, instead of repeating the conditions throughout the code. For now, only convert the hwmon code. Signed-off-by:
-
Jakub Kicinski authored
Gal Pressman says: ==================== Couple of minor improvements to build_skb variants First patch replaces open-coded occurrences of skb_propagate_pfmemalloc() in build_skb() and build_skb_around(). The secnod patch adds a likely() to the skb allocation in build_skb(). ==================== Link: https://lore.kernel.org/r/20230308131720.2103611-1-gal@nvidia.comSigned-off-by:
-
Gal Pressman authored
Similarly to napi_build_skb(), it is likely the skb allocation in build_skb() succeeded. frag_size != 0 is also likely, as stated in __build_skb_around(). Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-by:
Gal Pressman <gal@nvidia.com> Reviewed-by:
Larysa Zaremba <larysa.zaremba@intel.com> Reviewed-by:
-
Gal Pressman authored
Use skb_propagate_pfmemalloc() in build_skb()/build_skb_around() instead of open-coding it. Reviewed-by:
-
Jens Axboe authored
The tap driver already supports passing in nonblocking state based on O_NONBLOCK, add support for checking IOCB_NOWAIT as well. With that done, we can flag it with FMODE_NOWAIT as well. Signed-off-by:
Jens Axboe <axboe@kernel.dk> Link: https://lore.kernel.org/r/8f859870-e6e2-09ca-9c0f-a2aa7c984fb2@kernel.dkSigned-off-by:
-
Jens Axboe authored
tun already checks for both O_NONBLOCK and IOCB_NOWAIT in its read and write iter handlers, so it's fully ready for FMODE_NOWAIT. But for some reason it doesn't set it. Rectify that oversight. Signed-off-by:
-
Jakub Kicinski authored
Horatiu Vultur says: ==================== net: lan966x: Add support for IS1 VCAP Provide the Ingress Stage 1 (IS1) VCAP (Versatile Content-Aware Processor) support for the Lan966x platform. The IS1 VCAP has 3 lookups and they are accessible with a TC chain id: - chain 1000000: IS1 Lookup 0 - chain 1100000: IS1 Lookup 1 - chain 1200000: IS1 Lookup 2 The IS1 is capable of different actions like rewrite VLAN tags, change priority of the frames, police the traffic, etc. These features will be added at a later point. The IS1 currently implements the action that allows setting the value of a PAG (Policy Association Group) key field in the frame metadata and this can be used for matching in an IS2 VCAP rule. In this way a rule in IS0 VCAP can be linked to rules in the IS2 VCAP. The linking is exposed by using the TC "goto chain" action with an offset from the IS2 chain ids. For example "goto chain 8000001" will use a PAG value of 1 to chain to a rule in IS2 lookup 0. ==================== Link: https://lore.kernel.org/r/20230307220929.834219-1-horatiu.vultur@microchip.comSigned-off-by:
-
Horatiu Vultur authored
IS1 VCAP has it's own list of supported ethernet protocol types which is different than the IS2 VCAP. Therefore separate the list of known protocol types based on the VCAP type. Signed-off-by:
-
Horatiu Vultur authored
Allow rules to be chained between IS1 VCAP and IS2 VCAP. Chaining between IS1 lookups or between IS2 lookups are not supported by the hardware. Signed-off-by:
-
