- 09 Dec, 2021 2 commits
-
-
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:
Sergey Ryazanov <ryazanov.s.a@gmail.com> Reviewed-by:
Loic Poulain <loic.poulain@linaro.org> Acked-by:
M Chetan Kumar <m.chetan.kumar@intel.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
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 38 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:
-
Julian Wiedmann authored
Splitting up the netdev_ops allows for fine-tuning some of the ndo's in subsequent patches. Signed-off-by:
Wenjia Zhang <wenjia@linux.ibm.com> Signed-off-by:
-
Julian Wiedmann authored
Now that the OSN code is gone, we don't need the second switch statement in the RX path. And getting rid of its (unreachable) default case is a nice simplification. Also don't pass in the full HW header, all we still need is a flag to indicate whether the skb can use CSO. This we can already obtain during the first peek at the HW header. Signed-off-by:
-
Kees Cook authored
When building under -Warray-bounds, the compiler is especially conservative when faced with casts from a smaller object to a larger object. While this has found many real bugs, there are some cases that are currently false positives (like here). With this as one of the last few instances of the warning in the kernel before -Warray-bounds can be enabled globally, rearrange the functions so that there is a header-only version of hvs_send_data(). Silences this warning: net/vmw_vsock/hyperv_transport.c: In function 'hvs_shutdown_lock_held.constprop': net/vmw_vsock/hyperv_transport.c:231:32: warning: array subscript 'struct hvs_send_buf[0]' is partly outside array bounds of 'struct vmpipe_proto_header[1]' [-Warray-bounds] 231 | send_buf->hdr.pkt_type = 1; | ~~~~~~~~~~~~~~~~~~~~~~~^~~ net/vmw_vsock/hyperv_transport.c:465:36: note: while referencing 'hdr' 465 | struct vmpipe_proto_header hdr; | ^~~ This change results in no executable instruction differences. Signed-off-by:Kees Cook <keescook@chromium.org> Acked-by:
Wei Liu <wei.liu@kernel.org> Link: https://lore.kernel.org/r/20211207063217.2591451-1-keescook@chromium.orgSigned-off-by:
-
Yihao Han authored
Fix following coccicheck warning: /drivers/net/dsa/ocelot/felix_vsc9959.c:1627:13-20: WARNING opportunity for kmemdup /drivers/net/dsa/ocelot/felix_vsc9959.c:1506:16-23: WARNING opportunity for kmemdup Signed-off-by:
Yihao Han <hanyihao@vivo.com> Reviewed-by:
-
Jakub Kicinski authored
Colin Foster says: ==================== prepare ocelot for external interface control This patch set is derived from an attempt to include external control for a VSC751[1234] chip via SPI. That patch set has grown large and is getting unwieldy for reviewers and the developers... me. I'm breaking out the changes from that patch set. Some are trivial net: dsa: ocelot: remove unnecessary pci_bar variables net: dsa: ocelot: felix: Remove requirement for PCS in felix devices some are required for SPI net: dsa: ocelot: felix: add interface for custom regmaps and some are just to expose code to be shared net: mscc: ocelot: split register definitions to a separate file The entirety of this patch set should have essentially no impact on the system performance. ==================== Link: https://lore.kernel.org/r/20211207170030.1406601-1-colin.foster@in-advantage.comSigned-off-by:
-
Colin Foster authored
Move these to a separate file will allow them to be shared to other drivers. Signed-off-by:
Colin Foster <colin.foster@in-advantage.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Colin Foster authored
Add an interface so that non-mmio regmaps can be used Signed-off-by:
-
Colin Foster authored
Existing felix devices all have an initialized pcs array. Future devices might not, so running a NULL check on the array before dereferencing it will allow those future drivers to not crash at this point Signed-off-by:
-
Colin Foster authored
The pci_bar variables for the switch and imdio don't make sense for the generic felix driver. Moving them to felix_vsc9959 to limit scope and simplify the felix_info struct. Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a dev_err message. Fix it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20211206091207.113648-1-colin.i.king@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Merge tag 'wireless-drivers-next-2021-12-07' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for v5.17 First set of patches for v5.17. The biggest change is the iwlmei driver for Intel's AMT devices. Also now WCN6855 support in ath11k should be usable. Major changes: ath10k * fetch (pre-)calibration data via nvmem subsystem ath11k * enable 802.11 power save mode in station mode for qca6390 and wcn6855 * trace log support * proper board file detection for WCN6855 based on PCI ids * BSS color change support rtw88 * add debugfs file to force lowest basic rate * add quirk to disable PCI ASPM on HP 250 G7 Notebook PC mwifiex * add quirk to disable deep sleep with certain hardware revision in Surface Book 2 devices iwlwifi * add iwlmei driver for co-operating with Intel's Active Management Technology (AMT) devices * tag 'wireless-drivers-next-2021-12-07' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next: (87 commits) iwlwifi: mei: fix linking when tracing is not enabled rtlwifi: rtl8192de: Style clean-ups mwl8k: Use named struct for memcpy() region intersil: Use struct_group() for memcpy() region libertas_tf: Use struct_group() for memcpy() region libertas: Use struct_group() for memcpy() region wlcore: no need to initialise statics to false rsi: Fix out-of-bounds read in rsi_read_pkt() rsi: Fix use-after-free in rsi_rx_done_handler() brcmfmac: Configure keep-alive packet on suspend wilc1000: remove '-Wunused-but-set-variable' warning in chip_wakeup() iwlwifi: mvm: read the rfkill state and feed it to iwlmei iwlwifi: mvm: add vendor commands needed for iwlmei iwlwifi: integrate with iwlmei iwlwifi: mei: add debugfs hooks iwlwifi: mei: add the driver to allow cooperation with CSME mei: bus: add client dma interface mwifiex: Ignore BTCOEX events from the 88W8897 firmware mwifiex: Ensure the version string from the firmware is 0-terminated mwifiex: Add quirk to disable deep sleep with certain hardware revision ... ==================== Link: https://lore.kernel.org/r/20211207144211.A9949C341C1@smtp.kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Eric Dumazet says: ==================== net: second round of netdevice refcount tracking The most interesting part of this series is probably ("inet: add net device refcount tracker to struct fib_nh_common") but only future reports will confirm this guess. ==================== Link: https://lore.kernel.org/r/20211207013039.1868645-1-eric.dumazet@gmail.comSigned-off-by: -
Eric Dumazet authored
Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
