- 09 Dec, 2021 15 commits
-
-
Russell King (Oracle) authored
Use the legacy flag to indicate whether we should operate in legacy mode. This allows us to stop using the presence of a PCS as an indicator to the age of the phylink user, and make PCS presence optional. Legacy mode involves: 1) calling mac_config() whenever the link comes up 2) calling mac_config() whenever the inband advertisement changes, possibly followed by a call to mac_an_restart() 3) making use of mac_an_restart() 4) making use of mac_pcs_get_state() All the above functionality was moved to a seperate "PCS" block of operations in March 2020. Update the documents to indicate that the differences that this flag makes. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Russell King (Oracle) authored
mtk_eth_soc has not been updated for commit 7cceb599 ("net: phylink: avoid mac_config calls"), and makes use of state->speed and state->duplex in contravention of the phylink documentation. This makes reliant on the legacy behaviours, so mark it as a legacy driver. Signed-off-by:
-
Russell King (Oracle) authored
The majority of DSA drivers do not make use of the PCS support, and thus operate in legacy mode. In order to preserve this behaviour in future, we need to set the legacy_pre_march2020 flag so phylink knows this may require the legacy calls. There are some DSA drivers that do make use of PCS support, and these will continue operating as before - legacy_pre_march2020 will not prevent split-PCS support enabling the newer phylink behaviour. Signed-off-by:
-
Russell King (Oracle) authored
Add a boolean to phylink_config to indicate whether a driver has not been updated for the changes in commit 7cceb599 ("net: phylink: avoid mac_config calls"), and thus are reliant on the old behaviour. We were currently keying the phylink behaviour on the presence of a PCS, but this is sub-optimal for modern drivers that may not have a PCS. This commit merely introduces the new flag, but does not add any use, since we need all legacy drivers to set this flag before it can be used. Once these legacy drivers have been updated, we can remove this flag. Signed-off-by:
-
Gustavo A. R. Silva authored
Use 2-factor multiplication argument form devm_kcalloc() instead of devm_kzalloc(). Link: https://github.com/KSPP/linux/issues/162Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20211208040311.GA169838@embeddedorSigned-off-by:
-
Gustavo A. R. Silva authored
Use 2-factor multiplication argument form devm_kcalloc() instead of devm_kzalloc(). Link: https://github.com/KSPP/linux/issues/162Signed-off-by:
-
Jakub Kicinski authored
Antoine Tenart says: ==================== net: track the queue count at unregistration Those two patches allow to track the Rx and Tx queue count at unregistration and help in detecting illegal addition of Tx queues after unregister (a warning is added). This follows discussions on the following thread, https://lore.kernel.org/all/20211122162007.303623-1-atenart@kernel.org/T/ A patch fixing one issue linked to this was merged ealier, https://lore.kernel.org/all/20211203101318.435618-1-atenart@kernel.org/T/ ==================== Link: https://lore.kernel.org/r/20211207145725.352657-1-atenart@kernel.orgSigned-off-by:
-
Antoine Tenart authored
Calling netdev_queue_update_kobjects is allowed during device unregistration since commit 5c56580b ("net: Adjust TX queue kobjects if number of queues changes during unregister"). But this is solely to allow queue unregistrations. Any path attempting to add new queues after a device started its unregistration should be fixed. This patch adds a warning to detect such illegal use. Signed-off-by:
Antoine Tenart <atenart@kernel.org> Signed-off-by:
-
Antoine Tenart authored
When updating Rx and Tx queue kobjects, the queue count should always be updated to match the queue kobjects count. This was not done in the net device unregistration path, fix it. Tracking all queue count updates will allow in a following up patch to detect illegal updates. Signed-off-by:
-
Jakub Kicinski authored
Sergey Ryazanov says: ==================== WWAN debugfs tweaks This is a follow-up series to just applied IOSM (and WWAN) debugfs interface support [1]. The series has two main goals: 1. move the driver-specific debugfs knobs to a subdirectory; 2. make the debugfs interface optional for both IOSM and for the WWAN core. As for the first part, I must say that it was my mistake. I suggested to place debugfs entries under a common per WWAN device directory. But I missed the driver subdirectory in the example, so it become: /sys/kernel/debugfs/wwan/wwan0/trace Since the traces collection is a driver-specific feature, it is better to keep it under the driver-specific subdirectory: /sys/kernel/debugfs/wwan/wwan0/iosm/trace It is desirable to be able to entirely disable the debugfs interface. It can be disabled for several reasons, including security and consumed storage space. See detailed rationale with usage example in the 4th patch. The changes themselves are relatively simple, but require a code rearrangement. So to make changes clear, I chose to split them into preparatory and main changes and properly describe each of them. IOSM part is compile-tested only since I do not have IOSM supported device, so it needs Ack from the driver developers. I would like to thank Johannes Berg and Leon Romanovsky. Their suggestions and comments helped a lot to rework the initial over-engineered solution to something less confusing and much more simple. Thanks! 1. https://lore.kernel.org/netdev/20211120162155.1216081-1-m.chetan.kumar@linux.intel.com 2. https://patchwork.kernel.org/project/netdevbpf/patch/20211204174033.950528-1-arnd@kernel.org/ ==================== Link: https://lore.kernel.org/r/20211207092140.19142-1-ryazanov.s.a@gmail.comSigned-off-by:
-
Sergey Ryazanov authored
Debugfs interface is optional for the regular modem use. Some distros and users will want to disable this feature for security or kernel size reasons. So add a configuration option that allows to completely disable the debugfs interface of the WWAN devices. A primary considered use case for this option was embedded firmwares. For example, in OpenWrt, you can not completely disable debugfs, as a lot of wireless stuff can only be configured and monitored with the debugfs knobs. At the same time, reducing the size of a kernel and modules is an essential task in the world of embedded software. Disabling the WWAN and IOSM debugfs interfaces allows us to save 50K (x86-64 build) of space for module storage. Not much, but already considerable when you only have 16MB of storage. So it is hard to just disable whole debugfs. Users need some fine grained set of options to control which debugfs interface is important and should be available and which is not. The new configuration symbol is enabled by default and is hidden under the EXPERT option. So a regular user would not be bothered by another one configuration question. While an embedded distro maintainer will be able to a little more reduce the final image size. Signed-off-by:
Sergey Ryazanov <ryazanov.s.a@gmail.com> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Reviewed-by:
Loic Poulain <loic.poulain@linaro.org> Acked-by:
M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by:
-
Sergey Ryazanov authored
The modem traces collection is a device (and so driver) specific option. Therefore, move the related debugfs files into a driver-specific subdirectory under the common per WWAN device directory. Signed-off-by:
-
Sergey Ryazanov authored
Collecting modem firmware traces is optional for the regular modem use. There are not many reasons for aborting device initialization due to an inability to initialize the trace port and (or) its debugfs interface. So, demote the initialization failure erro message into a warning and do not break the initialization sequence in this case. Rework packet processing and deinitialization so that they do not crash in case of uninitialized trace port. This change is mainly a preparation for an upcoming configuration option introduction that will help disable driver debugfs functionality. Signed-off-by:
-
Sergey Ryazanov authored
Move the channel related structures initialization from ipc_imem_channel_init() to ipc_trace_init() and call it directly. On the one hand, this makes the trace port initialization symmetric to the deitialization, that is, it removes the additional wrapper. On the other hand, this change consolidates the trace port related code into a single source file, what facilitates an upcoming disabling of this functionality by a user choise. Signed-off-by:
-
Jakub Kicinski authored
Merge tag 'linux-can-next-for-5.17-20211208' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== can-next 2021-12-08 The first patch is by Vincent Mailhol and replaces the custom CAN units with generic one form linux/units.h. The next 3 patches are by Evgeny Boger and add Allwinner R40 support to the sun4i CAN driver. Andy Shevchenko contributes 4 patches to the hi311x CAN driver, consisting of cleanups and converting the driver to the device property API. * tag 'linux-can-next-for-5.17-20211208' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: can: hi311x: hi3110_can_probe(): convert to use dev_err_probe() can: hi311x: hi3110_can_probe(): make use of device property API can: hi311x: hi3110_can_probe(): try to get crystal clock rate from property can: hi311x: hi3110_can_probe(): use devm_clk_get_optional() to get the input clock ARM: dts: sun8i: r40: add node for CAN controller can: sun4i_can: add support for R40 CAN controller dt-bindings: net: can: add support for Allwinner R40 CAN controller can: bittiming: replace CAN units with the generic ones from linux/units.h ==================== Link: https://lore.kernel.org/r/20211208125055.223141-1-mkl@pengutronix.deSigned-off-by:
-
- 08 Dec, 2021 25 commits
-
-
Jakub Kicinski authored
Vladimir Oltean says: ==================== Rework DSA bridge TX forwarding offload API This change set is preparation work for DSA support of bridge FDB isolation. It replaces struct net_device *dp->bridge_dev with a struct dsa_bridge *dp->bridge that contains some extra information about that bridge, like a unique number kept by DSA. Up until now we computed that number only with the bridge TX forwarding offload feature, but it will be needed for other features too, like for isolation of FDB entries belonging to different bridges. Hardware implementations vary, but one common pattern seems to be the presence of a FID field which can be associated with that bridge number kept by DSA. The idea was outlined here: https://patchwork.kernel.org/project/netdevbpf/patch/20210818120150.892647-16-vladimir.oltean@nxp.com/ (the difference being that with this new proposal, drivers would not need to call dsa_bridge_num_find, instead the bridge_num would be part of the struct dsa_bridge :: num passed as argument). No functional change is intended for drivers that don't already make use of the bridge TX forwarding offload. I've tested the changes on the felix, sja1105 and mv88e6xxx drivers, but nonetheless I'm copying all DSA driver maintainers due to API changes that are taking place. Compared to v1 and v2, the amount of patches is larger, but the contents is mostly the same, just split up hopefully a bit better for review. ==================== Link: https://lore.kernel.org/r/20211206165758.1553882-1-vladimir.oltean@nxp.comSigned-off-by:
-
Vladimir Oltean authored
We don't really need new switch API for these, and with new switches which intend to add support for this feature, it will become cumbersome to maintain. The change consists in restructuring the two drivers that implement this offload (sja1105 and mv88e6xxx) such that the offload is enabled and disabled from the ->port_bridge_{join,leave} methods instead of the old ->port_bridge_tx_fwd_{,un}offload. The only non-trivial change is that mv88e6xxx_map_virtual_bridge_to_pvt() has been moved to avoid a forward declaration, and the mv88e6xxx_reg_lock() calls from inside it have been removed, since locking is now done from mv88e6xxx_port_bridge_{join,leave}. Signed-off-by:Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by:
-
Vladimir Oltean authored
This is a preparation patch for the removal of the DSA switch methods ->port_bridge_tx_fwd_offload() and ->port_bridge_tx_fwd_unoffload(). The plan is for the switch to report whether it offloads TX forwarding directly as a response to the ->port_bridge_join() method. This change deals with the noisy portion of converting all existing function prototypes to take this new boolean pointer argument. The bool is placed in the cross-chip notifier structure for bridge join, and a reference to it is provided to drivers. In the next change, DSA will then actually look at this value instead of calling ->port_bridge_tx_fwd_offload(). Signed-off-by:
-
Vladimir Oltean authored
The main desire behind this is to provide coherent bridge information to the fast path without locking. For example, right now we set dp->bridge_dev and dp->bridge_num from separate code paths, it is theoretically possible for a packet transmission to read these two port properties consecutively and find a bridge number which does not correspond with the bridge device. Another desire is to start passing more complex bridge information to dsa_switch_ops functions. For example, with FDB isolation, it is expected that drivers will need to be passed the bridge which requested an FDB/MDB entry to be offloaded, and along with that bridge_dev, the associated bridge_num should be passed too, in case the driver might want to implement an isolation scheme based on that number. We already pass the {bridge_dev, bridge_num} pair to the TX forwarding offload switch API, however we'd like to remove that and squash it into the basic bridge join/leave API. So that means we need to pass this pair to the bridge join/leave API. During dsa_port_bridge_leave, first we unset dp->bridge_dev, then we call the driver's .port_bridge_leave with what used to be our dp->bridge_dev, but provided as an argument. When bridge_dev and bridge_num get folded into a single structure, we need to preserve this behavior in dsa_port_bridge_leave: we need a copy of what used to be in dp->bridge. Switch drivers check bridge membership by comparing dp->bridge_dev with the provided bridge_dev, but now, if we provide the struct dsa_bridge as a pointer, they cannot keep comparing dp->bridge to the provided pointer, since this only points to an on-stack copy. To make this obvious and prevent driver writers from forgetting and doing stupid things, in this new API, the struct dsa_bridge is provided as a full structure (not very large, contains an int and a pointer) instead of a pointer. An explicit comparison function needs to be used to determine bridge membership: dsa_port_offloads_bridge(). Signed-off-by: -
Vladimir Oltean authored
Move the static inline helpers from net/dsa/dsa_priv.h to include/net/dsa.h, so that drivers can call functions such as dsa_port_offloads_bridge_dev(), which will be necessary after the transition to a more complex bridge structure. More functions than are needed right now are being moved, but this is done for uniformity. Signed-off-by:
-
Vladimir Oltean authored
Currently the majority of dsa_port_bridge_dev_get() calls in drivers is just to check whether a port is under the bridge device provided as argument by the DSA API. We'd like to change that DSA API so that a more complex structure is provided as argument. To keep things more generic, and considering that the new complex structure will be provided by value and not by reference, direct comparisons between dp->bridge and the provided bridge will be broken. The generic way to do the checking would simply be to do something like dsa_port_offloads_bridge(dp, &bridge). But there's a problem, we already have a function named that way, which actually takes a bridge_dev net_device as argument. Rename it so that we can use dsa_port_offloads_bridge for something else. Signed-off-by:
-
Vladimir Oltean authored
The location of the bridge device pointer and number is going to change. It is not going to be kept individually per port, but in a common structure allocated dynamically and which will have lockdep validation. Use the helpers to access these elements so that we have a migration path to the new organization. Signed-off-by:
-
Vladimir Oltean authored
The location of the bridge device pointer and number is going to change. It is not going to be kept individually per port, but in a common structure allocated dynamically and which will have lockdep validation. Create helpers to access these elements so that we have a migration path to the new organization. Signed-off-by:
-
Vladimir Oltean authored
The goal of this change is to reduce mv88e6xxx_port_vlan() to a form where dsa_port_bridge_same() can be used, since the dp->bridge_dev pointer will be hidden in a future change. To do that, we observe that the "br" pointer is deduced from a dp->bridge_dev in both cases (of a physical switch port as well as a virtual bridge). So instead of keeping the "br" pointer, we can just keep the "dp" pointer from which "br" gets derived. In the last iteration over switch ports, we must use another iterator variable, "other_dp"since now we use the "dp" variable to keep an indirect reference to the bridge. While at it, the old code used to filter only the ports which were part of the same switch as "ds". There exists a dedicated DSA port iterator for that: dsa_switch_for_each_port (which skips the ports in the tree that belong to non-local switches), so we can just use that. Signed-off-by:
-
Vladimir Oltean authored
Avoid a plethora of dsa_to_port() calls (some hidden behind dsa_is_*_port and some in plain sight) by keeping two struct dsa_port references: one to the port passed as argument, and another to the other ports of the switch that we're iterating over. This isn't called from the DSA initialization path, so there is no risk that we have user ports without a dp->slave populated. So the combined checks that a port isn't a DSA port, a CPU port, or doesn't have a slave net device (therefore is unused), are strictly equivalent to the simple check that the port is a user port. This is already handled by the DSA iterator. i gets replaced by other_dp->index, dsa_is_*_port calls get replaced by dsa_port_is_*, and dsa_to_port gets replaced by the respective pointer directly. Signed-off-by:
-
Vladimir Oltean authored
Avoid repeated calls to dsa_to_port() (some hidden behind dsa_is_user_port and some in plain sight) by keeping two struct dsa_port references: one to the port passed as argument, and another to the other ports of the switch that we're iterating over. dsa_to_port(ds, i) gets replaced by other_dp, i gets replaced by other_port which is derived from other_dp->index, dsa_is_user_port is handled by the DSA iterator. Signed-off-by:
-
Vladimir Oltean authored
The service where DSA assigns a unique bridge number for each forwarding domain is useful even for drivers which do not implement the TX forwarding offload feature. For example, drivers might use the dp->bridge_num for FDB isolation. So rename ds->num_fwd_offloading_bridges to ds->max_num_bridges, and calculate a unique bridge_num for all drivers that set this value. Signed-off-by:
-
Vladimir Oltean authored
I have seen too many bugs already due to the fact that we must encode an invalid dp->bridge_num as a negative value, because the natural tendency is to check that invalid value using (!dp->bridge_num). Latest example can be seen in commit 1bec0f05 ("net: dsa: fix bridge_num not getting cleared after ports leaving the bridge"). Convert the existing users to assume that dp->bridge_num == 0 is the encoding for invalid, and valid bridge numbers start from 1. Signed-off-by:
-
Andy Shevchenko authored
When deferred the reason is saved for further debugging. Besides that, it's fine to call dev_err_probe() in ->probe() when error code is known. Convert the driver to use dev_err_probe(). Link: https://lore.kernel.org/all/20211206165542.69887-4-andriy.shevchenko@linux.intel.comSigned-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Andy Shevchenko authored
Make use of device property API in this driver so that both OF based system and ACPI based system can use this driver. Link: https://lore.kernel.org/all/20211206165542.69887-3-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Andy Shevchenko authored
In some configurations, mainly ACPI-based, the clock frequency of the device is supplied by very well established 'clock-frequency' property. Hence, try to get it from the property at last if no other providers are available. Link: https://lore.kernel.org/all/20211206165542.69887-2-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Andy Shevchenko authored
It's not clear what was the intention of redundant usage of IS_ERR() around the clock pointer since with the error check of devm_clk_get() followed by bailout it can't be invalid, Simplify the code which fetches the input clock by using devm_clk_get_optional(). It will allow to switch to device properties approach in the future. Link: https://lore.kernel.org/all/20211206165542.69887-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Evgeny Boger authored
Allwinner R40 (also known as A40i, T3, V40) has a CAN controller. The controller is the same as in earlier A10 and A20 SoCs, but needs reset line to be deasserted before use. This patch adds a CAN node and the corresponding pinctrl descriptions. Link: https://lore.kernel.org/all/20211122104616.537156-4-boger@wirenboard.comSigned-off-by:
Evgeny Boger <boger@wirenboard.com> Signed-off-by:
-
Evgeny Boger authored
Allwinner R40 (also known as A40i, T3, V40) has a CAN controller. The controller is the same as in earlier A10 and A20 SoCs, but needs reset line to be deasserted before use. This patch adds a new compatible for R40 CAN controller. Depending on the compatible, reset line can be requested from DT. Link: https://lore.kernel.org/all/20211122104616.537156-3-boger@wirenboard.comSigned-off-by:
-
Evgeny Boger authored
Allwinner R40 (also known as A40i, T3, V40) has a CAN controller. The controller is the same as in earlier A10 and A20 SoCs, but needs reset line to be deasserted before use. This patch Introduces new compatible for R40 CAN controller with required resets property. Link: https://lore.kernel.org/all/20211122104616.537156-2-boger@wirenboard.comSigned-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Vincent Mailhol authored
In [1], we introduced a set of units in linux/can/bittiming.h. Since then, generic SI prefixes were added to linux/units.h in [2]. Those new prefixes can perfectly replace CAN specific ones. This patch replaces all occurrences of the CAN units with their corresponding prefix (from linux/units) and the unit (as a comment) according to below table. CAN units SI metric prefix (from linux/units) + unit (as a comment) ------------------------------------------------------------------------ CAN_KBPS KILO /* BPS */ CAN_MBPS MEGA /* BPS */ CAM_MHZ MEGA /* Hz */ The definition are then removed from linux/can/bittiming.h [1] commit 1d775076 ("can: bittiming: add CAN_KBPS, CAN_MBPS and CAN_MHZ macros") [2] commit 26471d4a ("units: Add SI metric prefix definitions") Link: https://lore.kernel.org/all/20211124014536.782550-1-mailhol.vincent@wanadoo.frSuggested-by:
Jimmy Assarsson <extja@kvaser.com> Suggested-by:
Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by:
Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by:
-
Jakub Kicinski authored
Alexandra Winter says: ==================== s390/net: updates 2021-12-06 This brings some maintenance improvements and removes some unnecessary code checks. ==================== Link: https://lore.kernel.org/r/20211207090452.1155688-1-wintera@linux.ibm.comSigned-off-by:
-
Julian Wiedmann authored
If qeth_check_outbound_queue() finds a partially filled TX buffer on the queue and flushes it, then the queue _must_ have been in packing mode. Remove the redundant check when updating the relevant statistics. Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by:
Alexandra Winter <wintera@linux.ibm.com> Signed-off-by:
-
Julian Wiedmann authored
Avoid a conditional branch for L2 devices when selecting the TX queue, and have shared logic for OSA devices. Signed-off-by:
-
Julian Wiedmann authored
qeth_l2_detect_dev2br_support() will only set brport_hw_features for IQD devices. So qeth_l2_bridge_getlink() and qeth_l2_bridge_setlink() will always return -EOPNOTSUPP on OSA devices. Just don't offer these callbacks instead. Signed-off-by:
-
