- 13 Apr, 2023 10 commits
-
-
Andrew Halaney authored
The sc8280xp has a new version of the ETHQOS hardware in it, EMAC v3. Add a compatible for this. Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Andrew Halaney <ahalaney@redhat.com> Tested-by:
Brian Masney <bmasney@redhat.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Bhupesh Sharma authored
Convert Qualcomm ETHQOS Ethernet devicetree binding to YAML. In doing so add a new property for iommus since newer platforms support using one, and without such make dtbs_check fails on them. While at it, also update the MAINTAINERS file to point to the yaml version of the bindings. Signed-off-by:
Bhupesh Sharma <bhupesh.sharma@linaro.org> [halaney: Remove duplicated properties, add MAINTAINERS and iommus] Reviewed-by:
-
Bhupesh Sharma authored
Add Qualcomm Ethernet ETHQOS compatible checks in snps,dwmac YAML binding document. Reviewed-by:
-
Bhupesh Sharma authored
As commit fc191af1 ("net: stmmac: platform: Fix misleading interrupt error msg") noted, not every stmmac based platform makes use of the 'eth_wake_irq' or 'eth_lpi' interrupts. So, update the 'interrupt-names' inside 'snps,dwmac' YAML bindings to reflect the same. Reviewed-by:
-
Ivan Vecera authored
Remove an inability of bnxt_en driver to set eswitch to switchdev mode without existing VFs by: 1. Allow to set switchdev mode in bnxt_dl_eswitch_mode_set() so representors are created only when num_vfs > 0 otherwise just set bp->eswitch_mode 2. Do not automatically change bp->eswitch_mode during bnxt_vf_reps_create() and bnxt_vf_reps_destroy() calls so the eswitch mode is managed only by an user by devlink. Just set temporarily bp->eswitch_mode to legacy to avoid re-opening of representors during destroy. 3. Create representors in bnxt_sriov_enable() if current eswitch mode is switchdev one Tested by this sequence: 1. Set PF interface up 2. Set PF's eswitch mode to switchdev 3. Created N VFs 4. Checked that N representors were created 5. Set eswitch mode to legacy 6. Checked that representors were deleted 7. Set eswitch mode back to switchdev 8. Checked that representors exist again for VFs 9. Deleted all VFs 10. Checked that all representors were deleted as well 11. Checked that current eswitch mode is still switchdev Signed-off-by:
Ivan Vecera <ivecera@redhat.com> Acked-by:
Venkat Duvvuru <venkatkumar.duvvuru@broadcom.com> Link: https://lore.kernel.org/r/20230411120443.126055-1-ivecera@redhat.comSigned-off-by:
-
Jakub Kicinski authored
Mika Westerberg says: ==================== net: thunderbolt: Fix for sparse warnings and typos This series tries to fix the rest of the sparse warnings generated against the driver. While there fix the two typos in comments as well. The previous version of the series can be found here: https://lore.kernel.org/netdev/20230404053636.51597-1-mika.westerberg@linux.intel.com/ ==================== Link: https://lore.kernel.org/r/20230411091049.12998-1-mika.westerberg@linux.intel.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Mika Westerberg authored
Fix two typos in comments: blongs -> belongs UPD -> UDP No functional changes. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Mika Westerberg authored
Fixes the following warning when the driver is built with sparse checks enabled: main.c:993:23: warning: incorrect type in initializer (different base types) main.c:993:23: expected restricted __wsum [usertype] wsum main.c:993:23: got restricted __be32 [usertype] No functional changes intended. Signed-off-by:
-
Mika Westerberg authored
Fixes the following warnings when the driver is built with sparse checks enabled: main.c:767:47: warning: restricted __le32 degrades to integer main.c:775:47: warning: restricted __le16 degrades to integer main.c:776:44: warning: restricted __le16 degrades to integer main.c:876:40: warning: incorrect type in assignment (different base types) main.c:876:40: expected restricted __le32 [usertype] frame_size main.c:876:40: got unsigned int [assigned] [usertype] frame_size main.c:877:41: warning: incorrect type in assignment (different base types) main.c:877:41: expected restricted __le32 [usertype] frame_count main.c:877:41: got unsigned int [usertype] main.c:878:41: warning: incorrect type in assignment (different base types) main.c:878:41: expected restricted __le16 [usertype] frame_index main.c:878:41: got unsigned short [usertype] main.c:879:38: warning: incorrect type in assignment (different base types) main.c:879:38: expected restricted __le16 [usertype] frame_id main.c:879:38: got unsigned short [usertype] main.c:880:62: warning: restricted __le32 degrades to integer main.c:880:35: warning: restricted __le16 degrades to integer No functional changes intended. Signed-off-by:
-
Andrew Lunn authored
A number of MDIO drivers make use of devm_mdiobus_alloc_size(). This is only available when CONFIG_MDIO_DEVRES is enabled. Add missing depends or selects, depending on if there are circular dependencies or not. This avoids linker errors, especially for randconfig builds. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Jacob Keller <jacob.e.keller@intel.com> Link: https://lore.kernel.org/r/20230409150204.2346231-1-andrew@lunn.chSigned-off-by:
-
- 12 Apr, 2023 9 commits
-
-
Simon Horman authored
Remove unused functions. These functions may have some value in documenting the hardware. But that information may be accessed via SCM history. Flagged by clang-16 with W=1. No functional change intended. Compile tested only. Signed-off-by:
Simon Horman <horms@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Brett Creeley authored
The driver was incorrectly overwriting the cyclecounter bitmask, which was truncating it and not aligning to the hardware mask value. This isn't causing any issues, but it's wrong. Fix this by not constraining the cyclecounter/hardware mask. Luckily, this seems to cause no issues, which is why this change doesn't have a fixes tag and isn't being sent to net. However, if any transformations from time->cycles are needed in the future, this change will be needed. Suggested-by:
Allen Hubbe <allen.hubbe@amd.com> Signed-off-by:
Brett Creeley <brett.creeley@amd.com> Signed-off-by:
Shannon Nelson <shannon.nelson@amd.com> Reviewed-by:
-
David S. Miller authored
Sebastian Reichel says: ==================== stmmac: Fix RK3588 error prints This fixes a couple of false positive error messages printed by stmmac on RK3588. I expect them to go via net-next since the fixes are not critical. Changes since PATCHv1: * https://lore.kernel.org/all/20230317174243.61500-1-sebastian.reichel@collabora.com/ * Add Fixes tags * Use loop to request clocks ==================== Signed-off-by:
-
Sebastian Reichel authored
The usual devm_regulator_get() call already handles "optional" regulators by returning a valid dummy and printing a warning that the dummy regulator should be described properly. This code open coded the same behaviour, but masked any errors that are not -EPROBE_DEFER and is quite noisy. This change effectively unmasks and propagates regulators errors not involving -ENODEV, downgrades the error print to warning level if no regulator is specified and captures the probe defer message for /sys/kernel/debug/devices_deferred. Fixes: 2e12f536 ("net: stmmac: dwmac-rk: Use standard devicetree property for phy regulator") Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
-
Sebastian Reichel authored
The clock requesting code is quite repetitive. Fix this by requesting the clocks via devm_clk_bulk_get_optional. The optional variant has been used, since this is effectively what the old code did. The exact clocks required depend on the platform and configuration. As a side effect this change adds correct -EPROBE_DEFER handling. Suggested-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== DSA trace events This series introduces the "dsa" trace event class, with the following events: $ trace-cmd list | grep dsa dsa dsa:dsa_fdb_add_hw dsa:dsa_mdb_add_hw dsa:dsa_fdb_del_hw dsa:dsa_mdb_del_hw dsa:dsa_fdb_add_bump dsa:dsa_mdb_add_bump dsa:dsa_fdb_del_drop dsa:dsa_mdb_del_drop dsa:dsa_fdb_del_not_found dsa:dsa_mdb_del_not_found dsa:dsa_lag_fdb_add_hw dsa:dsa_lag_fdb_add_bump dsa:dsa_lag_fdb_del_hw dsa:dsa_lag_fdb_del_drop dsa:dsa_lag_fdb_del_not_found dsa:dsa_vlan_add_hw dsa:dsa_vlan_del_hw dsa:dsa_vlan_add_bump dsa:dsa_vlan_del_drop dsa:dsa_vlan_del_not_found These are useful to debug refcounting issues on CPU and DSA ports, where entries may remain lingering, or may be removed too soon, depending on bugs in higher layers of the network stack. ==================== Signed-off-by: -
Vladimir Oltean authored
These are not as critical as the FDB/MDB trace points (I'm not aware of outstanding VLAN related bugs), but maybe they are useful to somebody, either debugging something or simply trying to learn more. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
DSA performs non-trivial housekeeping of unicast and multicast addresses on shared (CPU and DSA) ports, and puts a bit of pressure on higher layers, requiring them to behave correctly (remove these addresses exactly as many times as they were added). Otherwise, either addresses linger around forever, or DSA returns -ENOENT complaining that entries that were already deleted must be deleted again. To aid debugging, introduce some trace points specifically for FDB and MDB - that's where some of the bugs still are right now. Some bugs I have seen were also due to race conditions, see: - 630fd482 ("net: dsa: flush switchdev workqueue on bridge join error path") - a2614140 ("net: dsa: mv88e6xxx: flush switchdev FDB workqueue before removing VLAN") so it would be good to not disturb the timing too much, hence the choice to use trace points vs regular dev_dbg(). I've had these for some time on my computer in a less polished form, and they've proven useful. What I found most useful was to enable CONFIG_BOOTTIME_TRACING, add "trace_event=dsa" to the kernel cmdline, and run "cat /sys/kernel/debug/tracing/trace". This is to debug more complex environments with network managers started by the init system, things like that. Signed-off-by:
-
Andrew Lunn authored
The switch can either take the MAC or the PHY role in an MII or RMII link. There are distinct PHY_INTERFACE_ macros for these two roles. Correct the mapping so that the `REV` version is used for the PHY role. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20230411023541.2372609-1-andrew@lunn.chSigned-off-by:
-
- 11 Apr, 2023 12 commits
-
-
Shailend Chand authored
The two constants accomplish the same thing. Signed-off-by:
Shailend Chand <shailend@google.com> Reviewed-by:
-
Jakub Kicinski authored
cli.py currently throws a pure KeyError if kernel doesn't support a netlink family. Users who did not write ynl (hah) may waste their time investigating what's wrong with the Python code. Improve the error message: Traceback (most recent call last): File "/home/kicinski/devel/linux/tools/net/ynl/lib/ynl.py", line 362, in __init__ self.family = GenlFamily(self.yaml['name']) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/kicinski/devel/linux/tools/net/ynl/lib/ynl.py", line 331, in __init__ self.genl_family = genl_family_name_to_id[family_name] ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^ KeyError: 'netdev' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/kicinski/devel/linux/./tools/net/ynl/cli.py", line 52, in <module> main() File "/home/kicinski/devel/linux/./tools/net/ynl/cli.py", line 31, in main ynl = YnlFamily(args.spec, args.schema) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/kicinski/devel/linux/tools/net/ynl/lib/ynl.py", line 364, in __init__ raise Exception(f"Family '{self.yaml['name']}' not supported by the kernel") Exception: Family 'netdev' not supported by the kernel Signed-off-by: -
Jiapeng Chong authored
No functional modification involved. drivers/net/fddi/skfp/rmt.c:236 rmt_fsm() warn: if statement not indented. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4736Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Link: https://lore.kernel.org/r/20230407034157.61276-1-jiapeng.chong@linux.alibaba.comSigned-off-by:
-
Simon Horman authored
n_addr is used to store be32 values, so a sparse-friendly array of be32 to store these values. Flagged by sparse: .../mtk_ppe_debugfs.c:59:27: warning: incorrect type in assignment (different base types) .../mtk_ppe_debugfs.c:59:27: expected unsigned int .../mtk_ppe_debugfs.c:59:27: got restricted __be32 [usertype] .../mtk_ppe_debugfs.c:161:46: warning: cast to restricted __be16 No functional changes intended. Compile tested only. Signed-off-by:
-
Jakub Kicinski authored
Jakub Kicinski says: ==================== net: lockless stop/wake combo macros A lot of drivers follow the same scheme to stop / start queues without introducing locks between xmit and NAPI tx completions. I'm guessing they all copy'n'paste each other's code. The original code dates back all the way to e1000 and Linux 2.6.19. v3: https://lore.kernel.org/all/20230405223134.94665-1-kuba@kernel.org/ v2: https://lore.kernel.org/all/20230401051221.3160913-2-kuba@kernel.org/ v1: https://lore.kernel.org/all/20230322233028.269410-1-kuba@kernel.org/ rfc: https://lore.kernel.org/all/20230311050130.115138-1-kuba@kernel.org/ ==================== Link: https://lore.kernel.org/r/20230407012536.273382-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Drivers call netdev_tx_completed_queue() right before netif_txq_maybe_wake(). If BQL is enabled netdev_tx_completed_queue() should issue a memory barrier, so we can depend on that separating the stop check from the consumer index update, instead of adding another barrier in netif_txq_maybe_wake(). This matters more than the barriers on the xmit path, because the wake condition is almost always true. So we issue the consumer side barrier often. Wrap netdev_tx_completed_queue() in a local helper to issue the barrier even if BQL is disabled. Keep the same semantics as netdev_tx_completed_queue() (barrier only if bytes != 0) to make it clear that the barrier is conditional. Plus since macro gets pkt/byte counts as arguments now - we can skip waking if there were no packets completed. Signed-off-by: -
Jakub Kicinski authored
Convert bnxt to use new macros rather than open code the logic. Two differences: (1) bnxt_tx_int() will now only issue a memory barrier if it sees enough space on the ring to wake the queue. This should be fine, the mb() is between the writes to the ring pointers and checking queue state. (2) we'll start the queue instead of waking on race, this should be safe inside the xmit handler. Reviewed-by:Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Jakub Kicinski authored
Convert ixgbe to use the new macros, I think a lot of people copy the ixgbe code. The only functional change is that the unlikely() in ixgbe_clean_tx_irq() turns into a likely() inside the new macro and no longer includes total_packets && netif_carrier_ok(tx_ring->netdev) which is probably for the best, anyway. Signed-off-by: -
Jakub Kicinski authored
A lot of drivers follow the same scheme to stop / start queues without introducing locks between xmit and NAPI tx completions. I'm guessing they all copy'n'paste each other's code. The original code dates back all the way to e1000 and Linux 2.6.19. Smaller drivers shy away from the scheme and introduce a lock which may cause deadlocks in netpoll. Provide macros which encapsulate the necessary logic. The macros do not prevent false wake ups, the extra barrier required to close that race is not worth it. See discussion in: https://lore.kernel.org/all/c39312a2-4537-14b4-270c-9fe1fbb91e89@gmail.com/Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Jakub Kicinski authored
Use syntax highlight, comment out the "..." since they are not valid C. Signed-off-by: -
Jakub Kicinski authored
Somehow it feels more right to start from the probe then open, then tx... Much like the lifetime of the driver itself. Signed-off-by: -
Jakub Kicinski authored
driver.rst had a historical form of list of common problems. In the age os Sphinx and rendered documentation it's better to use the more usual title + text format. This will allow us to render kdoc into the output more naturally. No changes to the actual text. Signed-off-by:
-
- 10 Apr, 2023 9 commits
-
-
Krzysztof Kozlowski authored
Statically allocated array of pointed to hwmon_channel_info can be made const for safety. Signed-off-by:
-
Krzysztof Kozlowski authored
Statically allocated array of pointed to hwmon_channel_info can be made const for safety. Signed-off-by:
-
Krzysztof Kozlowski authored
Statically allocated array of pointed to hwmon_channel_info can be made const for safety. Signed-off-by:
-
Krzysztof Kozlowski authored
Statically allocated array of pointed to hwmon_channel_info can be made const for safety. Signed-off-by:
-
Krzysztof Kozlowski authored
Statically allocated array of pointed to hwmon_channel_info can be made const for safety. Signed-off-by:
-
Krzysztof Kozlowski authored
Statically allocated array of pointed to hwmon_channel_info can be made const for safety. Signed-off-by:
-
Krzysztof Kozlowski authored
Statically allocated array of pointed to hwmon_channel_info can be made const for safety. Signed-off-by:
-
Krzysztof Kozlowski authored
Statically allocated array of pointed to hwmon_channel_info can be made const for safety. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-stagingJakub Kicinski authored
Pull in pre-requisite patches from Guenter Roeck to constify pointers to hwmon_channel_info. * 'hwmon-const' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: constify pointers to hwmon_channel_info Link: https://lore.kernel.org/all/3a0391e7-21f6-432a-9872-329e298e1582@roeck-us.net/Signed-off-by:
-
