- 09 Aug, 2017 10 commits
-
-
Arvind Yadav authored
usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by <linux/usb.h> work with const usb_device_id. So mark the non-const structs as const. Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arvind Yadav authored
usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by <linux/usb.h> work with const usb_device_id. So mark the non-const structs as const. Signed-off-by:
-
Arvind Yadav authored
usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by <linux/usb.h> work with const usb_device_id. So mark the non-const structs as const. Signed-off-by:
-
Arvind Yadav authored
usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by <linux/usb.h> work with const usb_device_id. So mark the non-const structs as const. Fix checkpatch.pl error: ERROR: space prohibited before open square bracket '['. Signed-off-by:
-
Arvind Yadav authored
usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by <linux/usb.h> work with const usb_device_id. So mark the non-const structs as const. Signed-off-by:
-
Arvind Yadav authored
usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by <linux/usb.h> work with const usb_device_id. So mark the non-const structs as const. Signed-off-by:
-
Arvind Yadav authored
usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by <linux/usb.h> work with const usb_device_id. So mark the non-const structs as const. Signed-off-by:
-
Arvind Yadav authored
usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by <linux/usb.h> work with const usb_device_id. So mark the non-const structs as const. Signed-off-by:
-
Arvind Yadav authored
usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by <linux/usb.h> work with const usb_device_id. So mark the non-const structs as const. Signed-off-by:
-
Arvind Yadav authored
usb_device_id are not supposed to change at runtime. All functions working with usb_device_id provided by <linux/usb.h> work with const usb_device_id. So mark the non-const structs as const. Signed-off-by:
-
- 07 Aug, 2017 30 commits
-
-
David Ahern authored
Add extack error messages for failure paths creating vrf devices. Once extack support is added to iproute2, we go from the unhelpful: $ ip li add foobar type vrf RTNETLINK answers: Invalid argument to: $ ip li add foobar type vrf Error: VRF table id is missing Signed-off-by:David Ahern <dsahern@gmail.com> Signed-off-by:
-
Bhumika Goyal authored
Declare this structure as const as it is only used during a copy operation. Signed-off-by:
Bhumika Goyal <bhumirks@gmail.com> Signed-off-by:
-
David S. Miller authored
Arkadi Sharshevsky says: ==================== Update DSA's FDB API and perform switchdev cleanup The patchset adds support for configuring static FDB entries via the switchdev notification chain. The current method for FDB configuration uses the switchdev's bridge bypass implementation. In order to support this legacy way and to perform the switchdev cleanup, the implementation is moved inside DSA. The DSA drivers cannot sync the software bridge with hardware learned entries and use the switchdev's implementation of bypass FDB dumping. Because they are the only ones using this functionality, the fdb_dump implementation is moved from switchdev code into DSA. Finally after this changes a major cleanup in switchdev can be done. Please see individual patches for patch specific change logs. v1->v2 - Split MDB/vlan dump removal into core/driver removal. v2->v3 - The self implementation for FDB add/del is moved inside DSA. ==================== Tested-by:
Vivien Didelot <vivien.didelot@savoirfairelinux.com> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Arkadi Sharshevsky authored
Currently the bridge port flags, vlans, FDBs and MDBs can be offloaded through the bridge code, making the switchdev's SELF bridge bypass implementation to be redundant. This implies several changes: - No need for dump infra in switchdev, DSA's special case is handled privately. - Remove obj_dump from switchdev_ops. - FDBs are removed from obj_add/del routines, due to the fact that they are offloaded through the bridge notification chain. - The switchdev_port_bridge_xx() and switchdev_port_fdb_xx() functions can be removed. Signed-off-by:
Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Reviewed-by:
Ivan Vecera <ivecera@redhat.com> Reviewed-by:
-
Arkadi Sharshevsky authored
At this point no driver supports FDB add/del through switchdev object but rather via notification chain, thus, it is removed. Signed-off-by:
-
Arkadi Sharshevsky authored
>From all switchdev devices only DSA requires special FDB dump. This is due to lack of ability for syncing the hardware learned FDBs with the bridge. Due to this it is removed from switchdev and moved inside DSA. Signed-off-by:
-
Arkadi Sharshevsky authored
Currently the MDB HW database is synced with the bridge's one, thus, There is no need to support special dump functionality. Signed-off-by:
-
Arkadi Sharshevsky authored
This is done as a preparation before removing support for MDB dump from DSA core. The MDBs are synced with the bridge and thus there is no need for special dump operation support. Signed-off-by:
-
Arkadi Sharshevsky authored
The bridge port attributes/vlan for DSA devices should be set only from bridge code. Furthermore, The vlans are synced totally with the bridge so there is no need for special dump support. Signed-off-by:
-
Arkadi Sharshevsky authored
This is done as a preparation before removing support for vlan dump from DSA core. The vlans are synced with the bridge and thus there is no need for special dump operation support. Signed-off-by:
-
Arkadi Sharshevsky authored
The DSA drivers do not support bridge flags offload. Yet, this attribute should be added in order for the bridge to fail when one tries set a flag on the port, as explained in commit dc0ecabd ("net: switchdev: Add support for querying supported bridge flags by hardware"). Signed-off-by:
-
Arkadi Sharshevsky authored
Currently DSA uses switchdev's implementation of FDB add/del ndos. This patch moves the implementation inside DSA in order to support the legacy way for static FDB configuration. Signed-off-by:
-
Arkadi Sharshevsky authored
Add support for learning FDB through notification. The driver defers the hardware update via ordered work queue. In case of a successful FDB add a notification is sent back to bridge. In case of hw FDB del failure the static FDB will be deleted from the bridge, thus, the interface is moved to down state in order to indicate inconsistent situation. Signed-off-by:
-
Arkadi Sharshevsky authored
Currently, the switchdev objects are embedded inside the DSA notifier info. This patch removes this dependency. This is done as a preparation stage before adding support for learning FDB through the switchdev notification chain. Signed-off-by:
-
Arkadi Sharshevsky authored
The prepare phase for FDB add is unneeded because most of DSA devices can have failures during bus transactions (SPI, I2C, etc.), thus, the prepare phase cannot guarantee success of the commit stage. The support for learning FDB through notification chain, which will be introduced in the following patches, will provide the ability to notify back the bridge about successful offload. Signed-off-by:
-
Arkadi Sharshevsky authored
In order to support FDB add/del to be on a notifier chain the slave API need to be changed to be switchdev independent. Signed-off-by:
-
Bhumika Goyal authored
Make hdlcdrv_ops structures const as they are only passed to hdlcdrv_register function. The corresponding argument is of type const, so make the structures const. Signed-off-by:
-
Florian Westphal authored
Quoting Ilan Tayari: 1. Set up a host-to-host IPSec tunnel (or transport, doesn't matter) 2. Ping over IPSec, or do something to populate the pcpu cache 3. Join a MC group, then leave MC group 4. Try to ping again using same CPU as before -> traffic doesn't egress the machine at all Ilan debugged the problem down to the fact that one of the path dsts devices point to lo due to earlier dst_dev_put(). In this case, dst is marked as DEAD and we cannot reuse the bundle. The cache only asserted that the requested policy and that of the cached bundle match, but its not enough - also verify the path is still valid. Fixes: ec30d78c ("xfrm: add xdst pcpu cache") Reported-by:Ayham Masood <ayhamm@mellanox.com> Tested-by:
Ilan Tayari <ilant@mellanox.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
David S. Miller authored
Vivien Didelot says: ==================== net: dsa: remove useless arguments Several DSA core setup functions take many arguments, mostly because of the legacy code. This patch series removes the useless args of these functions, where either the dsa_switch or dsa_port argument is enough. Changes in v2: - ds->dev is already assigned by dsa_switch_alloc ==================== Signed-off-by: -
Vivien Didelot authored
dsa_slave_create currently takes 4 arguments while it only needs the related dsa_port and its name. Remove all other arguments. Signed-off-by:
-
Vivien Didelot authored
dsa_cpu_dsa_setup currently takes 4 arguments but they are all available from the dsa_port argument. Remove all others. Signed-off-by:
-
Vivien Didelot authored
dsa_switch_alloc() already assigns ds-dev, which can be used in dsa_switch_setup_one and dsa_cpu_dsa_setups instead of requiring an additional struct device argument. Signed-off-by:
-
Colin Ian King authored
Trivial fix to spelling mistake in dev_err error message and also split overly long line to avoid a checkpatch warning. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
David S. Miller authored
Egil Hjelmeland says: ==================== Refactor lan9303_xxx_packet_processing This series is purely non functional. It changes the lan9303_enable_packet_processing, lan9303_disable_packet_processing() to pass port number (0,1,2) as parameter instead of port offset. This aligns them with other functions in the module, and makes it possible to simplify the code. The lan9303_enable_packet_processing, lan9303_disable_packet_processing functions operate on port. Therefore rename the functions to reflect that as well. Reviewer pointed out lan9303_get_ethtool_stats would be better off with the use of a lan9303_read_switch_port(). So that was added to the series. Changes v3 -> v4: - Whitespace adjustments. Changes v2 -> v3: - Patch 1: Removed the change in lan9303_get_ethtool_stats - Added patch 4: rename lan9303_xxx_packet_processing - Added patch 5: refactor lan9303_get_ethtool_stats Changes v1 -> v2: - introduced lan9303_write_switch_port() in first patch - inserted LAN9303_NUM_PORTS patch - Use LAN9303_NUM_PORTS in last patch. Plus whitespace change. ==================== Signed-off-by: -
Egil Hjelmeland authored
In lan9303_get_ethtool_stats: Get rid of 0x400 constant magic by using new lan9303_read_switch_reg() inside loop. Reduced scope of two variables. Signed-off-by:
Egil Hjelmeland <privat@egil-hjelmeland.no> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
-
Egil Hjelmeland authored
The lan9303_enable_packet_processing, lan9303_disable_packet_processing functions operate on port, so the names should reflect that. And to align with lan9303_disable_processing(), rename: lan9303_enable_packet_processing -> lan9303_enable_processing_port lan9303_disable_packet_processing -> lan9303_disable_processing_port Signed-off-by:
-
Egil Hjelmeland authored
Simplify usage of lan9303_enable_packet_processing, lan9303_disable_packet_processing() Signed-off-by:
-
Egil Hjelmeland authored
Will be used instead of '3' in upcomming patches. Signed-off-by:
-
Egil Hjelmeland authored
lan9303_enable_packet_processing, lan9303_disable_packet_processing() Pass port number (0,1,2) as parameter instead of port offset. Because other functions in the module pass port numbers. And to enable simplifications in following patch. Introduce lan9303_write_switch_port(). Signed-off-by:
-
David S. Miller authored
David Lebrun says: ==================== ipv6: sr: add support for advanced local segment processing v2: use EXPORT_SYMBOL_GPL The current implementation of IPv6 SR supports SRH insertion/encapsulation and basic segment endpoint behavior (i.e., processing of an SRH contained in a packet whose active segment (IPv6 DA) is routed to the local node). This behavior simply consists of updating the DA to the next segment and forwarding the packet accordingly. This processing is realised for all such packets, regardless of the active segment. The most recent specifications of IPv6 SR [1] [2] extend the SRH processing features as follows. Each segment endpoint defines a MyLocalSID table. This table maps segments to operations to perform. For each ingress IPv6 packet whose DA is part of a given prefix, the segment endpoint looks up the active segment (i.e., the IPv6 DA) in the MyLocalSID table and applies the corresponding operation. Such specifications enable to specify arbitrary operations besides the basic SRH processing and allow for a more fine-grained classification. This patch series implements those extended specifications by leveraging a new type of lightweight tunnel, seg6local. The MyLocalSID table is simply an arbitrary routing table (using CONFIG_IPV6_MULTIPLE_TABLES). The following commands would assign the prefix fc00::/64 to the MyLocalSID table, map the segment fc00::42 to the regular SRH processing function (named "End"), and drop all packets received with an undefined active segment: ip -6 rule add fc00::/64 lookup 100 ip -6 route add fc00::42 encap seg6local action End dev eth0 table 100 ip -6 route add blackhole default table 100 As another example, the following command would assign the segment fc00::1234 to the regular SRH processing function, except that the processed packet must be forwarded to the next-hop fc42::1 (this operation is named "End.X"): ip -6 route add fc00::1234 encap seg6local action End.X nh6 fc42::1 dev eth0 table 100 Those two basic operations (End and End.X) are defined in [1]. A more extensive list of advanced operations is defined in [2]. The first two patches of the series are preliminary work that remove an assumption about initial SRH format, and export the two functions used to insert and encapsulate an SRH onto packets. The third patch defines the new seg6local lightweight tunnel and implement the core functions. The fourth patch implements the operations needed to handle the newly defined rtnetlink attributes. The fifth patch implements a few SRH processing operations, including End and End.X. [1] https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-07 [2] https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-01 ==================== Signed-off-by:
-
