- 19 Jul, 2023 40 commits
-
-
Jakub Kicinski authored
Merge tag 'linux-can-next-for-6.6-20230719' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2023-07-19 The first 2 patches are by Judith Mendez, target the m_can driver and add hrtimer based polling support for TI AM62x SoCs, where the interrupt of the MCU domain's m_can cores is not routed to the Cortex A53 core. A patch by Rob Herring converts the grcan driver to use the correct DT include files. Michal Simek and Srinivas Neeli add support for optional reset control to the xilinx_can driver. The next 2 patches are by Jimmy Assarsson and add support for new Kvaser pciefd to the kvaser_pciefd driver. Mao Zhu's patch for the ucan driver removes a repeated word from a comment. * tag 'linux-can-next-for-6.6-20230719' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: can: ucan: Remove repeated word can: kvaser_pciefd: Add support for new Kvaser pciefd devices can: kvaser_pciefd: Move hardware specific constants and functions into a driver_data struct can: Explicitly include correct DT includes can: xilinx_can: Add support for controller reset dt-bindings: can: xilinx_can: Add reset description can: m_can: Add hrtimer to generate software interrupt dt-bindings: net: can: Remove interrupt properties for MCAN ==================== Link: https://lore.kernel.org/r/20230719072348.525039-1-mkl@pengutronix.deSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
David S. Miller authored
Guillaume Nault says: ==================== net: Remove more RTO_ONLINK users. Code that initialise a flowi4 structure manually before doing a fib lookup can easily avoid overloading ->flowi4_tos with the RTO_ONLINK bit. They can just set ->flowi4_scope correctly instead. Properly separating the routing scope from ->flowi4_tos will allow to eventually convert this field to dscp_t (to ensure proper separation between DSCP and ECN). ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Guillaume Nault authored
There's no reason for setting the RTO_ONLINK flag in ->flowi4_tos as RT_CONN_FLAGS() does. We can easily set ->flowi4_scope properly instead. This makes the code more explicit and will allow to convert ->flowi4_tos to dscp_t in the future. Signed-off-by:
Guillaume Nault <gnault@redhat.com> Reviewed-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Guillaume Nault authored
There's no reason for setting the RTO_ONLINK flag in ->flowi4_tos as RT_CONN_FLAGS() does. We can easily set ->flowi4_scope properly instead. This makes the code more explicit and will allow to convert ->flowi4_tos to dscp_t in the future. Signed-off-by:
-
Guillaume Nault authored
There's no reason for setting the RTO_ONLINK flag in ->flowi4_tos as RT_CONN_FLAGS() does. We can easily set ->flowi4_scope properly instead. This makes the code more explicit and will allow to convert ->flowi4_tos to dscp_t in the future. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueDavid S. Miller authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2023-07-14 (i40e) This series contains updates to i40e driver only. Ivan Vecera adds waiting for VF to complete initialization on VF related configuration callbacks. ==================== Signed-off-by: -
David S. Miller authored
Matthieu Baerts says: ==================== selftests: mptcp: format subtests results in TAP The current selftests infrastructure formats the results in TAP 13. This version doesn't support subtests and only the end result of each selftest is taken into account. It means that a single issue in a subtest of a selftest containing multiple subtests forces the whole selftest to be marked as failed. It also means that subtests results are not tracked by CI executing selftests. MPTCP selftests run hundreds of various subtests. It is then important to track each of them and not one result per selftest. It is particularly interesting to do that when validating stable kernels with the last version of the test suite: tests might fail because a feature is not supported but the test didn't skip that part. In this case, if subtests are not tracked, the whole selftest will be marked as failed making the other subtests useless because their results are ignored. Regarding this patch set: - The two first patches modify connect and userspace_pm selftests to continue executing other tests if there is an error before the end. This is what is done in the other MPTCP selftests. - Patches 3-5 are refactoring the code in userspace_pm selftest to reduce duplicated code, suppress some shellcheck warnings and prepare subtests' support by using new helpers. - Patch 6 adds new helpers in mptcp_lib.sh to easily support printing the subtests results in the different MPTCP selftests. - Patch 7-13 format subtests results in TAP 13 in the different MPTCP selftests. ==================== Signed-off-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
-
Matthieu Baerts authored
The current selftests infrastructure formats the results in TAP 13. This version doesn't support subtests and only the end result of each selftest is taken into account. It means that a single issue in a subtest of a selftest containing multiple subtests forces the whole selftest to be marked as failed. It also means that subtests results are not tracked by CIs executing selftests. MPTCP selftests run hundreds of various subtests. It is then important to track each of them and not one result per selftest. It is particularly interesting to do that when validating stable kernels with the last version of the test suite: tests might fail because a feature is not supported but the test didn't skip that part. In this case, if subtests are not tracked, the whole selftest will be marked as failed making the other subtests useless because their results are ignored. This patch formats subtests results in TAP in userspace_pm.sh selftest. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368Acked-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Matthieu Baerts authored
The current selftests infrastructure formats the results in TAP 13. This version doesn't support subtests and only the end result of each selftest is taken into account. It means that a single issue in a subtest of a selftest containing multiple subtests forces the whole selftest to be marked as failed. It also means that subtests results are not tracked by CIs executing selftests. MPTCP selftests run hundreds of various subtests. It is then important to track each of them and not one result per selftest. It is particularly interesting to do that when validating stable kernels with the last version of the test suite: tests might fail because a feature is not supported but the test didn't skip that part. In this case, if subtests are not tracked, the whole selftest will be marked as failed making the other subtests useless because their results are ignored. This patch formats subtests results in TAP in mptcp_sockopt.sh selftest. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368Acked-by:
-
Matthieu Baerts authored
The current selftests infrastructure formats the results in TAP 13. This version doesn't support subtests and only the end result of each selftest is taken into account. It means that a single issue in a subtest of a selftest containing multiple subtests forces the whole selftest to be marked as failed. It also means that subtests results are not tracked by CIs executing selftests. MPTCP selftests run hundreds of various subtests. It is then important to track each of them and not one result per selftest. It is particularly interesting to do that when validating stable kernels with the last version of the test suite: tests might fail because a feature is not supported but the test didn't skip that part. In this case, if subtests are not tracked, the whole selftest will be marked as failed making the other subtests useless because their results are ignored. This patch formats subtests results in TAP in simult_flows.sh selftest. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368Acked-by:
-
Matthieu Baerts authored
The current selftests infrastructure formats the results in TAP 13. This version doesn't support subtests and only the end result of each selftest is taken into account. It means that a single issue in a subtest of a selftest containing multiple subtests forces the whole selftest to be marked as failed. It also means that subtests results are not tracked by CIs executing selftests. MPTCP selftests run hundreds of various subtests. It is then important to track each of them and not one result per selftest. It is particularly interesting to do that when validating stable kernels with the last version of the test suite: tests might fail because a feature is not supported but the test didn't skip that part. In this case, if subtests are not tracked, the whole selftest will be marked as failed making the other subtests useless because their results are ignored. This patch formats subtests results in TAP in diag.sh selftest. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368Acked-by:
-
Matthieu Baerts authored
The current selftests infrastructure formats the results in TAP 13. This version doesn't support subtests and only the end result of each selftest is taken into account. It means that a single issue in a subtest of a selftest containing multiple subtests forces the whole selftest to be marked as failed. It also means that subtests results are not tracked by CIs executing selftests. MPTCP selftests run hundreds of various subtests. It is then important to track each of them and not one result per selftest. It is particularly interesting to do that when validating stable kernels with the last version of the test suite: tests might fail because a feature is not supported but the test didn't skip that part. In this case, if subtests are not tracked, the whole selftest will be marked as failed making the other subtests useless because their results are ignored. This patch formats subtests results in TAP in mptcp_join.sh selftest. In this selftest and before starting each subtest, the 'reset' function is called. We can then check if the previous test has passed, failed or has been skipped from there. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368Acked-by:
-
Matthieu Baerts authored
The current selftests infrastructure formats the results in TAP 13. This version doesn't support subtests and only the end result of each selftest is taken into account. It means that a single issue in a subtest of a selftest containing multiple subtests forces the whole selftest to be marked as failed. It also means that subtests results are not tracked by CIs executing selftests. MPTCP selftests run hundreds of various subtests. It is then important to track each of them and not one result per selftest. It is particularly interesting to do that when validating stable kernels with the last version of the test suite: tests might fail because a feature is not supported but the test didn't skip that part. In this case, if subtests are not tracked, the whole selftest will be marked as failed making the other subtests useless because their results are ignored. This patch formats subtests results in TAP in pm_netlink.sh selftest. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368Acked-by:
-
Matthieu Baerts authored
The current selftests infrastructure formats the results in TAP 13. This version doesn't support subtests and only the end result of each selftest is taken into account. It means that a single issue in a subtest of a selftest containing multiple subtests forces the whole selftest to be marked as failed. It also means that subtests results are not tracked by CIs executing selftests. MPTCP selftests run hundreds of various subtests. It is then important to track each of them and not one result per selftest. It is particularly interesting to do that when validating stable kernels with the last version of the test suite: tests might fail because a feature is not supported but the test didn't skip that part. In this case, if subtests are not tracked, the whole selftest will be marked as failed making the other subtests useless because their results are ignored. This patch formats subtests results in TAP in mptcp_connect.sh selftest. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368Acked-by:
-
Matthieu Baerts authored
The current selftests infrastructure formats the results in TAP 13. This version doesn't support subtests and only the end result of each selftest is taken into account. It means that a single issue in a subtest of a selftest containing multiple subtests forces the whole selftest to be marked as failed. It also means that subtests results are not tracked by CIs executing selftests. MPTCP selftests run hundreds of various subtests. It is then important to track each of them and not one result per selftest. It is particularly interesting to do that when validating stable kernels with the last version of the test suite: tests might fail because a feature is not supported but the test didn't skip that part. In this case, if subtests are not tracked, the whole selftest will be marked as failed making the other subtests useless because their results are ignored. This patch adds some helpers in mptcp_lib.sh to be able to easily format subtests results in TAP in the different MPTCP selftests. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/368Acked-by:
-
Matthieu Baerts authored
In this selftest, "printf" is always used with "stdbuf". With a new helper, it is possible to call "stdbuf" only from one place. This makes the code a bit clearer to read. Acked-by:
-
Matthieu Baerts authored
There are a few reasons to do that: - When the tabs are not printed as 8 spaces, some results were not properly aligned - Some lines printing the test name were very long due to the use of a lot of spaces/tabs at the end and stdbuf at the beginning. - To reduce duplicated code, e.g. to print what has failed and set the status But by centralising how the test results are printed, this also prepares future commits to avoid more duplicated code and ease the tracking of the different subtests. Acked-by:
-
Matthieu Baerts authored
shellcheck recently helped to find an issue where a wrong variable name was used. It is then good to fix the other harmless issues in order to spot "real" ones later. Here, three categories of warnings are ignored: - SC2317: Command appears to be unreachable. The cleanup() function is invoke indirectly via the EXIT trap. - SC2034: Variable appears unused. The check_expected_one() function takes the name of the variable in argument but it ends up reading the content: indirect usage. - SC2086: Double quote to prevent globbing and word splitting. This is recommended but the current usage is correct and there is no need to do all these modifications to be compliant with this rule. One error has been fixed with SC2181: Check exit code directly with e.g. 'if ! mycmd;', not indirectly with $?. Acked-by:
-
Matthieu Baerts authored
No more tests were executed after a failure but it is still interesting to get results for all the tests to better understand what's still OK and what's not after a modification. Now we only exit earlier if the two connections cannot be established. Acked-by:
-
Matthieu Baerts authored
No more tests were executed after a failure but it is still interesting to get results for all the tests to better understand what's still OK and what's not after a modification. Now we only exit earlier if the basic tests are failing: no ping going through namespaces or unable to transfer data on the loopback interface. Acked-by:
-
Rohan G Thomas authored
Get the exact count of L3L4 filters when the L3L4FNUM field of HW_FEATURE1 register is >= 8. If L3L4FNUM < 8, then the number of L3L4 filters supported by XGMAC is equal to L3L4FNUM. From L3L4FNUM >= 8 the number of L3L4 filters goes on like 8, 16, 32, ... Current maximum of L3L4FNUM = 10. Also, fix the XGMAC_IDDR bitmask of L3L4_ADDR_CTRL register. IDDR field starts from the 8th bit of the L3L4_ADDR_CTRL register. IDDR[3:0] indicates the type of L3L4 filter register while IDDR[8:4] indicates the filter number (0 to 31). So overall 9 bits are used for IDDR (i.e. L3L4_ADDR_CTRL[16:8]) to address the registers of all the filters. Currently, XGMAC_IDDR is GENMASK(15,8), causing issues accessing L3L4 filters above 15 for those XGMACs configured with more than 16 L3L4 filters. Signed-off-by:
Rohan G Thomas <rohan.g.thomas@intel.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== Add backup nexthop ID support tl;dr ===== This patchset adds a new bridge port attribute specifying the nexthop object ID to attach to a redirected skb as tunnel metadata. The ID is used by the VXLAN driver to choose the target VTEP for the skb. This is useful for EVPN multi-homing, where we want to redirect local (intra-rack) traffic upon carrier loss through one of the other VTEPs (ES peers) connected to the target host. Background ========== In a typical EVPN multi-homing setup each host is multi-homed using a set of links called ES (Ethernet Segment, i.e., LAG) to multiple leaf switches in a rack. These switches act as VTEPs and are not directly connected (as opposed to MLAG), but can communicate with each other (as well as with VTEPs in remote racks) via spine switches over L3. The control plane uses Type 1 routes [1] to create a mapping between an ES and VTEPs where the ES has active links. In addition, the control plane uses Type 2 routes [2] to create a mapping between {MAC, VLAN} and an ES. These tables are then used by the control plane to instruct VTEPs how to reach remote hosts. For example, assuming {MAC X, VLAN Y} is accessible via ES1 and this ES has active links to VTEP1 and VTEP2. The control plane will program the following entries to a remote VTEP: # ip nexthop add id 1 via $VTEP1_IP fdb # ip nexthop add id 2 via $VTEP2_IP fdb # ip nexthop add id 10 group 1/2 fdb # bridge fdb add $MAC_X dev vx0 master extern_learn vlan $VLAN_Y # bridge fdb add $MAC_Y dev vx0 self extern_learn nhid 10 src_vni $VNI_Y Remote traffic towards the host will be load balanced between VTEP1 and VTEP2. If the control plane notices a carrier loss on the ES1 link connected to VTEP1, it will issue a Type 1 route withdraw, prompting remote VTEPs to remove the effected nexthop from the group: # ip nexthop replace id 10 group 2 fdb Motivation ========== While remote traffic can be redirected to a VTEP with an active ES link by withdrawing a Type 1 route, the same is not true for local traffic. A host that is multi-homed to VTEP1 and VTEP2 via another ES (e.g., ES2) will send its traffic to {MAC X, VLAN Y} via one of these two switches, according to its LAG hash algorithm which is not under our control. If the traffic arrives at VTEP1 - which no longer has an active ES1 link - it will be dropped due to the carrier loss. In MLAG setups, the above problem is solved by redirecting the traffic through the peer link upon carrier loss. This is achieved by defining the peer link as the backup port of the host facing bond. For example: # bridge link set dev bond0 backup_port bond_peer Unlike MLAG, there is no peer link between the leaf switches in EVPN. Instead, upon carrier loss, local traffic should be redirected through one of the active ES peers. This can be achieved by defining the VXLAN port as the backup port of the host facing bonds. For example: # bridge link set dev es1_bond backup_port vx0 However, the VXLAN driver is not programmed with FDB entries for locally attached hosts and therefore does not know to which VTEP to redirect the traffic to. This will result in the traffic being replicated to all the VTEPs (potentially hundreds) in the network and each VTEP dropping the traffic, except for the active ES peer. Avoiding the flooding by programming local FDB entries in the VXLAN driver is not a viable solution as it requires to significantly increase the number of programmed FDB entries. Implementation ============== The proposed solution is to create an FDB nexthop group for each ES with the IP addresses of the active ES peers and set this ID as the backup nexthop ID (new bridge port attribute) of the ES link. For example, on VTEP1: # ip nexthop add id 1 via $VTEP2_IP fdb # ip nexthop add id 10 group 1 fdb # bridge link set dev es1_bond backup_nhid 10 # bridge link set dev es1_bond backup_port vx0 When the ES link loses its carrier, traffic will be redirected to the VXLAN port, but instead of only attaching the tunnel ID (i.e., VNI) as tunnel metadata to the skb, the backup nexthop ID will be attached as well. The VXLAN driver will then use this information to forward the skb via the nexthop object associated with the ID, as if the skb hit an FDB entry associated with this ID. Testing ======= A test for both the existing backup port attribute as well as the new backup nexthop ID attribute is added in patch #4. Patchset overview ================= Patch #1 extends the tunnel key structure with the new nexthop ID field. Patch #2 uses the new field in the VXLAN driver to forward packets via the specified nexthop ID. Patch #3 adds the new backup nexthop ID bridge port attribute and adjusts the bridge driver to attach the ID as tunnel metadata upon redirection. Patch #4 adds a selftest. iproute2 patches can be found here [3]. Changelog ========= Since RFC [4]: * Added Nik's tags. [1] https://datatracker.ietf.org/doc/html/rfc7432#section-7.1 [2] https://datatracker.ietf.org/doc/html/rfc7432#section-7.2 [3] https://github.com/idosch/iproute2/tree/submit/backup_nhid_v1 [4] https://lore.kernel.org/netdev/20230713070925.3955850-1-idosch@nvidia.com/ ==================== Acked-by:David Ahern <dsahern@kernel.org> Signed-off-by:
-
Ido Schimmel authored
Add test cases for bridge backup port and backup nexthop ID, testing both good and bad flows. Example truncated output: # ./test_bridge_backup_port.sh [...] Tests passed: 83 Tests failed: 0 Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Acked-by:
Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by:
-
Ido Schimmel authored
Add a new bridge port attribute that allows attaching a nexthop object ID to an skb that is redirected to a backup bridge port with VLAN tunneling enabled. Specifically, when redirecting a known unicast packet, read the backup nexthop ID from the bridge port that lost its carrier and set it in the bridge control block of the skb before forwarding it via the backup port. Note that reading the ID from the bridge port should not result in a cache miss as the ID is added next to the 'backup_port' field that was already accessed. After this change, the 'state' field still stays on the first cache line, together with other data path related fields such as 'flags and 'vlgrp': struct net_bridge_port { struct net_bridge * br; /* 0 8 */ struct net_device * dev; /* 8 8 */ netdevice_tracker dev_tracker; /* 16 0 */ struct list_head list; /* 16 16 */ long unsigned int flags; /* 32 8 */ struct net_bridge_vlan_group * vlgrp; /* 40 8 */ struct net_bridge_port * backup_port; /* 48 8 */ u32 backup_nhid; /* 56 4 */ u8 priority; /* 60 1 */ u8 state; /* 61 1 */ u16 port_no; /* 62 2 */ /* --- cacheline 1 boundary (64 bytes) --- */ [...] } __attribute__((__aligned__(8))); When forwarding an skb via a bridge port that has VLAN tunneling enabled, check if the backup nexthop ID stored in the bridge control block is valid (i.e., not zero). If so, instead of attaching the pre-allocated metadata (that only has the tunnel key set), allocate a new metadata, set both the tunnel key and the nexthop object ID and attach it to the skb. By default, do not dump the new attribute to user space as a value of zero is an invalid nexthop object ID. The above is useful for EVPN multihoming. When one of the links composing an Ethernet Segment (ES) fails, traffic needs to be redirected towards the host via one of the other ES peers. For example, if a host is multihomed to three different VTEPs, the backup port of each ES link needs to be set to the VXLAN device and the backup nexthop ID needs to point to an FDB nexthop group that includes the IP addresses of the other two VTEPs. The VXLAN driver will extract the ID from the metadata of the redirected skb, calculate its flow hash and forward it towards one of the other VTEPs. If the ID does not exist, or represents an invalid nexthop object, the VXLAN driver will drop the skb. This relieves the bridge driver from the need to validate the ID. Signed-off-by: -
Ido Schimmel authored
VXLAN FDB entries can point to FDB nexthop objects. Each such object includes the IP address(es) of remote VTEP(s) via which the target host is accessible. Example: # ip nexthop add id 1 via 192.0.2.1 fdb # ip nexthop add id 2 via 192.0.2.17 fdb # ip nexthop add id 1000 group 1/2 fdb # bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 1000 src_vni 10020 This is useful for EVPN multihoming where a single host can be connected to multiple VTEPs. The source VTEP will calculate the flow hash of the skb and forward it towards the IP address of one of the VTEPs member in the nexthop group. There are cases where an external entity (e.g., the bridge driver) can provide not only the tunnel ID (i.e., VNI) of the skb, but also the ID of the nexthop object via which the skb should be forwarded. Therefore, in order to support such cases, when the VXLAN device is in external / collect metadata mode and the tunnel info attached to the skb is of bridge type, extract the nexthop ID from the tunnel info. If the ID is valid (i.e., non-zero), forward the skb via the nexthop object associated with the ID, as if the skb hit an FDB entry associated with this ID. Signed-off-by:
-
Ido Schimmel authored
Extend the ip_tunnel_key structure with a field indicating the ID of the nexthop object via which the skb should be routed. The field is going to be populated in subsequent patches by the bridge driver in order to indicate to the VXLAN driver which FDB nexthop object to use in order to reach the target host. Signed-off-by:
-
Mao Zhu authored
Delete one of repeated word 'information' in comment. Signed-off-by:
Mao Zhu <zhumao001@208suo.com> Link: https://lore.kernel.org/all/20230718163718.461137-1-mkl@pengutronix.deSigned-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Jimmy Assarsson <extja@kvaser.com> says: This patch series adds support for a range of new Kvaser PCI Express devices based on the SmartFusion2 SoC, to the kvaser_pciefd driver. In the first patch, the hardware specific constants and functions are moved into a driver_data struct. In the second patch, we add the new devices and their hardware specific constants and functions. Changes in v2: - Rebased on can: kvaser_pciefd: Fixes and improvements https://lore.kernel.org/all/20230529134248.752036-1-extja@kvaser.com - Dropped can: kvaser_pciefd: Wrap register read and writes with macros https://lore.kernel.org/linux-can/20230523094354.83792-17-extja@kvaser.com since the driver became a lot cleaner when using FIELD_{GET,PREP} and GENMASK. Moved some parts of the patch into can: kvaser_pciefd: Move hardware specific constants and functions into a driver_data struct Removed macros reading/writing registers. - Link to v1: https://lore.kernel.org/all/20230523094354.83792-14-extja@kvaser.com Link: https://lore.kernel.org/all/20230622151153.294844-1-extja@kvaser.comSigned-off-by:
-
Jimmy Assarsson authored
Add support for new Kvaser pciefd devices, based on SmartFusion2 SoC. Signed-off-by:
Jimmy Assarsson <extja@kvaser.com> Link: https://lore.kernel.org/all/20230622151153.294844-3-extja@kvaser.com [mkl: mark structs as static] Signed-off-by:
-
Jimmy Assarsson authored
Move hardware specific address offsets, interrupt masks and DMA mapping function, into struct kvaser_pciefd_driver_data, as a step towards adding new devices based on different hardware. Co-developed-by:
Martin Jocic <majoc@kvaser.com> Signed-off-by:
-
Marc Kleine-Budde authored
Michal Simek <michal.simek@amd.com> says: IP core has option reset line which can be wired that's why add support for optional reset. Changes in v2: - Add Conor's ACK - Fix use-after-free in xcan_remove reported by Marc. - Link to v1: https://lore.kernel.org/all/cover.1689084227.git.michal.simek@amd.com Link: https://lore.kernel.org/all/cover.1689164442.git.michal.simek@amd.comSigned-off-by:
-
Rob Herring authored
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/all/20230714174757.4060748-1-robh@kernel.orgSigned-off-by:
-
Srinivas Neeli authored
Add support for an optional reset for the CAN controller using the reset driver. If the CAN node contains the "resets" property, then this logic will perform CAN controller reset. Signed-off-by:
Srinivas Neeli <srinivas.neeli@amd.com> Signed-off-by:
Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/all/ab7e6503aa3343e39ead03c1797e765be6c50de2.1689164442.git.michal.simek@amd.comSigned-off-by:
-
Michal Simek authored
IP core has input for reset signal which can be connected that's why describe optional reset property. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/all/bfaed896cc51af02fe5f290675313ab4dcab0d33.1689164442.git.michal.simek@amd.comSigned-off-by:
-
Jakub Kicinski authored
Wu Yunchuan says: ==================== Remove unnecessary (void*) conversions Remove (void*) conversions under "drivers/net" directory. PATCH v2 link: https://lore.kernel.org/all/20230710063828.172593-1-suhui@nfschina.com/ PATCH v1 link: https://lore.kernel.org/all/20230628024121.1439149-1-yunchuan@nfschina.com/ ==================== Link: https://lore.kernel.org/r/20230717030937.53818-1-yunchuan@nfschina.comSigned-off-by:
-
Wu Yunchuan authored
No need cast (void*) to (struct bnad_tx_info *) or (struct bnad_rx_info *). Signed-off-by:
Wu Yunchuan <yunchuan@nfschina.com> Link: https://lore.kernel.org/r/20230717031229.55169-1-yunchuan@nfschina.comSigned-off-by:
-
Wu Yunchuan authored
No need cast (void*) to (struct ems_pci_card *). Signed-off-by:
-
Wu Yunchuan authored
No need cast (void*) to (struct xgene_mdio_pdata *). Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20230717031212.54991-1-yunchuan@nfschina.comSigned-off-by:
-
Wu Yunchuan authored
No need cast (voidd*) to (struct smsc911x_data *) or (struct smsc9420_pdata *). Signed-off-by:
-
Wu Yunchuan authored
No need cast (void*) to (struct ice_ring_container *). Signed-off-by:
-
