- 30 May, 2017 6 commits
-
-
Jakub Kicinski authored
nfp_cpp_{read,write}() helpers perform device memory mapping (setting the PCIe -> NOC translation BARs) and accessing it. They, however, currently implicitly expect that the length of entire operation will fit in one BAR translation window. There is a number of 16MB windows available, and we don't really need to access such large areas today. If the user, however, manages to trick the driver into making a big mapping (e.g. by providing a huge fake FW file), the driver will print a warning saying "No suitable BAR found for request" and a stack trace - which most users find concerning. To be future-proof and not scare users with warnings, make the nfp_cpp_{read,write}() helpers do accesses chunk by chunk if the area size is large. Set the notion of "large" to 2MB, which is the size of the smallest BAR window. Signed-off-by:Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
For accessing PCIe ctrl memory we depend on the BAR aperture being large enough to reach all registers. Since the BAR aperture can be set in the flash make sure the driver won't oops the kernel when the PCIe configuration is unusual. Signed-off-by:
-
Jakub Kicinski authored
If ioremap of PCIe ctrl memory failed we can still get to it through PCI config space, therefore we allow ioremap() to fail. When if fails, however, we must leave all the IOMEM pointers as NULL. Currently we would calculate csr and em pointers, adding offsets to the potential NULL value and therefore making the NULL-checks throughout the code ineffective. Signed-off-by:
-
Jakub Kicinski authored
PCI subsystem has support for drivers limiting the number of VFs available below what the IOV capability claims. Make use of it. While at it remove the #ifdef/#endif on CONFIG_PCI_IOV, it was there to avoid unnecessary warnings in case device read failed but kernel doesn't have SR-IOV support anyway. Device reads should not fail. Note that we still need the driver-internal check for the case where max VFs is 0 since PCI subsystem treats 0 as limit not set. Signed-off-by:
-
Pablo Cascón authored
Expose FW app ability to change MAC address at runtime. Make sure we only depend on it if FW app advertised the right capability. Signed-off-by:
Pablo Cascón <pablo.cascon@netronome.com> Reviewed-by:
-
Jakub Kicinski authored
Fix build with DEVLINK=m and NFP=y. Fixes: 1851f93f ("nfp: add devlink support") Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
- 27 May, 2017 6 commits
-
-
Florian Fainelli authored
Some Ethernet drivers will attach/connect to a PHY device before calling register_netdevice() which is responsible for calling netdev_register_kobject() which would do the network device's kobject initialization. In such a case, sysfs_create_link() would return -ENOENT because the network device's kobject is not ready yet, and we would fail to connect to the PHY device. In order to keep things simple and symetrical, we just take the success path as indicative of the ability to access the network device's kobject, and create the second link if that's the case. Fixes: 5568363f ("net: phy: Create sysfs reciprocal links for attached_dev/phydev") Reported-by:
Woojung Hung <Woojung.Huh@microchip.com> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vivien Didelot authored
mv88e6xxx_serdes_power returns an error, so no need to print an error message inside of it. Rather print it in its caller when the error is ignored, which is in the mv88e6xxx_port_disable void function. Catch and return its error in the counterpart mv88e6xxx_port_enable. Fixes: 04aca993 ("dsa: mv88e6xxx: Enable/Disable SERDES on port enable/disable") Signed-off-by:
Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by:
-
David S. Miller authored
Vladislav Yasevich says: ==================== rtnetlink: Updates to rtnetlink_event() First is the patch to add IFLA_EVENT attribute to the netlink message. It supports only currently white-listed events. Like before, this is just an attribute that gets added to the rtnetlink message only when the messaged was generated as a result of a netdev event. In my case, this is necessary since I want to trap NETDEV_NOTIFY_PEERS event (also possibly NETDEV_RESEND_IGMP event) and perform certain actions in user space. This is not possible since the messages generated as a result of netdev events do not usually contain any changed data. They are just notifications. This patch exposes this notification type to userspace. Second, I remove duplicate messages that a result of a change to bonding options. If netlink is used to configure bonding options, 2 messages are generated, one as a result NETDEV_CHANGEINFODATA event triggered by bonding code and one a result of device state changes triggered by netdev_state_change (called from do_setlink). V6: Updated names and refactored to make it less tied to netdev events. (From David Ahern) V5: Rebased. Added iproute2 patch to the series. V4: * Removed the patch the removed NETDEV_CHANGENAME from event whitelist. It doesn't trigger duplicate messages since name changes can only be done while device is down and netdev_state_change() doesn't report changes while device is down. * Added a patch to clean-up duplicate messages on bonding option changes. V3: Rebased. Cleaned-up duplicate event. V2: Added missed events (from David Ahern) ==================== Signed-off-by: -
Vlad Yasevich authored
Whenever a user changes bonding options, a NETDEV_CHANGEINFODATA notificatin is generated which results in a rtnelink message to be sent. While runnig 'ip monitor', we can actually see 2 messages, one a result of the event, and the other a result of state change that is generated bo netdev_state_change(). However, this is not always the case. If bonding changes were done via sysfs or ifenslave (old ioctl interface), then only 1 message is seen. This patch removes duplicate messages in the case of using netlink to configure bonding. It introduceds a separte function that triggers a netdev event and uses that function in the syfs and ioctl cases. This was discovered while auditing all the different envents and continues the effort of cleaning up duplicated netlink messages. CC: David Ahern <dsa@cumulusnetworks.com> CC: Jiri Pirko <jiri@resnulli.us> Signed-off-by:
Vladislav Yasevich <vyasevic@redhat.com> Acked-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Vlad Yasevich authored
When netdev events happen, a rtnetlink_event() handler will send messages for every event in it's white list. These messages contain current information about a particular device, but they do not include the iformation about which event just happened. So, it is impossible to tell what just happend for these events. This patch adds a new extension to RTM_NEWLINK message called IFLA_EVENT that would have an encoding of event that triggered this message. This would allow the the message consumer to easily determine if it needs to perform certain actions. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller authored
Overlapping changes in drivers/net/phy/marvell.c, bug fix in 'net' restricting a HW workaround alongside cleanups in 'net-next'. Signed-off-by:
-
- 26 May, 2017 28 commits
-
-
Linus Torvalds authored
Merge tag 'led_fixes_for_4-12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds Pull LED fix from Jacek Anaszewski: "A single LED fix for 4.12-rc3. leds-pca955x driver uses only i2c_smbus API and thus it should pass I2C_FUNC_SMBUS_BYTE_DATA flag to i2c_check_functionality" * tag 'led_fixes_for_4-12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds: leds: pca955x: Correct I2C Functionality
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds authored
Pull networking fixes from David Miller: 1) Fix state pruning in bpf verifier wrt. alignment, from Daniel Borkmann. 2) Handle non-linear SKBs properly in SCTP ICMP parsing, from Davide Caratti. 3) Fix bit field definitions for rss_hash_type of descriptors in mlx5 driver, from Jesper Brouer. 4) Defer slave->link updates until bonding is ready to do a full commit to the new settings, from Nithin Sujir. 5) Properly reference count ipv4 FIB metrics to avoid use after free situations, from Eric Dumazet and several others including Cong Wang and Julian Anastasov. 6) Fix races in llc_ui_bind(), from Lin Zhang. 7) Fix regression of ESP UDP encapsulation for TCP packets, from Steffen Klassert. 8) Fix mdio-octeon driver Kconfig deps, from Randy Dunlap. 9) Fix regression in setting DSCP on ipv6/GRE encapsulation, from Peter Dawson. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (43 commits) ipv4: add reference counting to metrics net: ethernet: ax88796: don't call free_irq without request_irq first ip6_tunnel, ip6_gre: fix setting of DSCP on encapsulated packets sctp: fix ICMP processing if skb is non-linear net: llc: add lock_sock in llc_ui_bind to avoid a race condition bonding: Don't update slave->link until ready to commit test_bpf: Add a couple of tests for BPF_JSGE. bpf: add various verifier test cases bpf: fix wrong exposure of map_flags into fdinfo for lpm bpf: add bpf_clone_redirect to bpf_helper_changes_pkt_data bpf: properly reset caller saved regs after helper call and ld_abs/ind bpf: fix incorrect pruning decision when alignment must be tracked arp: fixed -Wuninitialized compiler warning tcp: avoid fastopen API to be used on AF_UNSPEC net: move somaxconn init from sysctl code net: fix potential null pointer dereference geneve: fix fill_info when using collect_metadata virtio-net: enable TSO/checksum offloads for Q-in-Q vlans be2net: Fix offload features for Q-in-Q packets vlan: Fix tcp checksum offloads in Q-in-Q vlans ... -
David S. Miller authored
Nathan Fontenot says: ==================== ibmvnic: Driver updates This set of patches implements several updates to the ibmvnic driver to fix issues that have been found in testing. Most of the updates invovle updating queue handling during driver close and reset operations. ==================== Signed-off-by: -
Nathan Fontenot authored
When the ibmvnic driver is resetting, we can just reset the sub crqs instead of releasing all of their resources and re-allocting them. Signed-off-by:
Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by:
-
Nathan Fontenot authored
When resetting the ibmvnic driver there is not a need to release and re-allocate the resources for the tx and rx pools. These resources can just be reset to avoid the re-allocations. Signed-off-by:
-
Nathan Fontenot authored
When a driver reset operation occurs there is not a need to release the CRQ resources and re-allocate them. Instead a reset of the CRQ will suffice. Signed-off-by:
-
Nathan Fontenot authored
We do not want to process any receive frames if the ibmvnic_poll routine is invoked while a reset is in process. Also, before replenishing the rx pools in the ibmvnic_poll, we want to make sure the adapter is not in the process of closing. Signed-off-by:
-
Thomas Falcon authored
If H_CLOSED is returned, halt RX buffer replenishment activity until firmware sends a notification that the driver can reset. Signed-off-by:
Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by:
-
Thomas Falcon authored
This patch disables transmissions and reports carrier off if xmit function returns that the hardware TX queue is closed. The driver can then await a signal from firmware to determine the correct reset method. Signed-off-by:
-
John Allen authored
Handle non-fatal error conditions. The process to do this when resetting the driver is to just do __ibmvnic_close followed by __ibmvnic_open. Signed-off-by:
John Allen <jallen@linux.vnet.ibm.com> Signed-off-by:
-
Thomas Falcon authored
A race condition occurs when closing the driver. Free'ing of skb's can race between the close routine and ibmvnic_tx_interrupt. To fix this we move the claenup of tx pools during close to after the sub-CRQ interrupts are disabled. Signed-off-by:
-
John Allen authored
Send gratuitous arp after any reset. Signed-off-by:
-
John Allen authored
Handle case where phyp sends a failover after failing to send the init crq. Signed-off-by:
-
John Allen authored
Track the state of ibmvnic napis. The driver can get into states where it can be reset when napis are already disabled and attempting to disable them again will cause the driver to hang. Signed-off-by:
-
David S. Miller authored
Jiri Pirko says: ==================== mlxsw: Improve extensibility Ido says: Since the initial introduction of the bridge offload in commit 56ade8fe ("mlxsw: spectrum: Add initial support for Spectrum ASIC") the per-port struct was used to store both physical properties of the port as well as logical bridge properties such as learning and active VLANs in the VLAN-aware bridge. The above resulted in a bloated struct and code that is getting increasingly difficult to extend when stacked devices are taken into account as well as more advanced use cases such as IGMP snooping. Due to the incremental development nature of this driver as well as the complexity of the underlying hardware, subsequent design decisions failed to generalize the FID and RIF resources, which could've benefited from a more generic design, resulting in consolidated code paths and better extensibility with regards to future ASICs and use cases. This patchset tries to solve both of these design problems, as they're tightly coupled. To ease the code review, the changes are done in a bottom-up manner, in which the port struct is the first to be patched, then the FIDs the ports are mapped to and finally the RIFs configured on top. The first half of the patchset gradually moves away from the previous design to a design that is more in sync with the underlying hardware and which clearly separates between hardware-specific structs and logical ones such as a bridge port. All the bridge-specific information is removed from the port struct, as well as the list of VLAN devices ("vPorts") configured on top of it. Instead, a linked list of VLANs is introduced, which allows each VLAN to hold a state, such as mapping to a particular FID and membership in a bridge. The data structures are depicted in the following figure: mlxsw_sp_bridge_device +----------+ | | +----+ | | | | | +----------+ | mlxsw_sp_bridge_port | +----------+ | | | | +--> +-----+--> .. | | | | +----+-----+ | | | v | mlxsw_sp_bridge_vlan | +----------+ | | vid X | | | +--> .. | | | | +----+-----+ | | +--+----v-----+ | vid X | +--+ +--> .. | | | mlxsw_sp_port | +----------+ +----------+ | mlxsw_sp_port_vlan | | | | +--+ | | +----------+ This model allows us to consolidate many of the code paths relating to VLAN-aware and VLAN-unaware bridges, as the latter is simply represented using a bridge port with a VLAN list size of one. Another advantage of the model is that it's easy to extend it with future per-VLAN attributes - such as mrouter indication - by merely pushing these down from the bridge port struct to the bridge VLAN one. The second half of the patchset builds on top of previous work and prepares the driver for the common FID and RIF cores, which are finally implemented in the last two patches. These exploit the fact that despite the different kinds of FIDs and RIFs, they do share a common object on which the core operations can operate on. By hiding both objects from the rest of the driver and modeling their operations using a VFT, it'll be easier to extend the driver for future use cases such as VXLAN. Tested using following LNST recipes: https://github.com/jpirko/lnst/tree/master/recipes/switchdev ==================== Signed-off-by:
-
Ido Schimmel authored
The mlxsw driver currently implements three types of RIFs. VLAN and FID RIFs for L3 interfaces on top of VLAN-aware and VLAN-unaware bridges (respectively) and Subport RIFs for all other L3 interfaces. All the RIF types follow a common configuration procedure, which only differs in the type-specific bits. The patch exploits this fact and consolidates the common code paths, thereby simplifying the code and making it more extensible. This work also prepares the driver for use with future ASICs, where the range of the Subport RIFs will be extended and their configuration modified accordingly. By merely implementing a new RIF operations and selecting it during initialization, the same driver could be re-used. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Ido Schimmel authored
The device supports three types of FIDs. 802.1Q and 802.1D FIDs for VLAN-aware and VLAN-unaware bridges (respectively) and rFIDs to transport packets to the router block. The different users (e.g., bridge, router, ACLs) of the FIDs infrastructure need not know about the internal FIDs implementation and can therefore interact with it using a restricted set of exported functions. By encapsulating the entire FID logic and hiding it from the rest of the driver we get a code base that it much simpler and easier to work with and extend. For example, in the current Spectrum ASIC only 802.1D FIDs can be assigned a VNI, but future ASICs will also support 802.1Q FIDs. With this patch in place, support for future ASICs can be easily added by implementing a new FID operations according to their capabilities. Signed-off-by:
-
Ido Schimmel authored
All RIF types are associated with a virtual router (VR), so determine VR first when creating a RIF. That way, we can more easily integrate the common RIF core in the following patches. Signed-off-by:
-
Ido Schimmel authored
If a packet ingress the router but can't be assigned an ingress RIF, it's dropped. Therefore, in the case of RIF configured on top of a bridge, it makes sense to start flooding broadcast packets to the router only after the RIF was created. Signed-off-by:
-
Ido Schimmel authored
Now that all the information to create a RIF is contained within the RIF struct itself, we can also simplify the destruction logic. Signed-off-by:
-
Ido Schimmel authored
All the information necessary for the configuration of RIFs can now be found in the RIF struct itself, so reduce the arguments list. This gets us one step closer to the common RIF core. Signed-off-by:
-
Ido Schimmel authored
Currently, when a Subport RIF is configured, the LAG status and VLAN of the underlying port are read from the port itself. This is problematic, as we would like to have common code to configure all types of RIFs, which aren't necessarily bound to a port. Instead, embed the RIF in a struct specific to the Subport type, which contains all the necessary information. Signed-off-by:
-
Ido Schimmel authored
In the following patches the RIF's configuration function is going to expect a RIF struct with all the necessary information. Therefore, allocate the RIF just before it's configured to the device. Signed-off-by:
-
Ido Schimmel authored
The following patches are going to re-arrange the FID and RIF code, so that when the RIF is configured to the device based on the information present in the RIF struct (which points to a FID). For this reason, move the FID allocation to just before the RIF configuration. Signed-off-by:
-
Ido Schimmel authored
As explained in the cover letter, since the introduction of the bridge offload in the mlxsw driver, information related to the offloaded bridge and bridge ports was stored in the individual port struct, mlxsw_sp_port. This lead to a bloated struct storing both physical properties of the port (e.g., autoneg status) as well as logical properties of an upper bridge port (e.g., learning, mrouter indication). While this might work well for simple devices, it proved to be hard to extend when stacked devices were taken into account and more advanced use-cases (e.g., IGMP snooping) considered. This patch removes the excess information from the above struct and instead stores it in more appropriate structs that represent the bridge port, the bridge itself and a VLAN configured on the bridge port. The membership of a port in a bridge is denoted using the Port-VLAN struct, which points to the bridge port and also member in the bridge VLAN group of the VLAN it represents. This allows us to completely remove the vPort abstraction and consolidate many of the code paths relating to VLAN-aware and unaware bridges. Note that the FID / vFID code is currently duplicated, but this will soon go away when the common FID core will be introduced. Signed-off-by:
-
Ido Schimmel authored
Up until now we used to create FIDs upon the creation of VLAN uppers on top of the VLAN-aware bridge. This was done so that in case a router interface (RIF) was configured on top of the bridge, the FID would already be there. Instead, simplify the code and only create the FID upon RIF creation. This is an intermediary step towards the introduction of the common FID core, in which this code would be completely removed. Signed-off-by:
-
Ido Schimmel authored
Currently, when port netdevs (or their uppers) are enslaved to a bridge, we simply propagate the CHANGEUPPER event all the way down and lose the context of the actual netdevice used as the bridge port. This leads to a lot of information hanging off the ports (and vPorts), which doesn't logically belong there, such as mrouter indication and unknown unicast flood state. Following patches are going to put the mlxsw_sp_port struct on diet and instead introduce a bridge port struct, where the above mentioned information belongs. But in order to do that, we need to be able to determine the bridge port netdevice, so propagate it down. Signed-off-by:
-
Ido Schimmel authored
We're going to get rid of vPorts completely later in the patchset, but the router code is self-contained, so it's a good candidate to start the transition with. Convert all the functions that expects to operate on a vPort to operate on a Port-VLAN instead. Signed-off-by:
-
