aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/ibm/ibmvnic.h
AgeCommit message (Collapse)AuthorFilesLines
2020-09-28ibmvnic: set up 200GBPS speedLijun Pan1-1/+1
Set up the speed according to crq->query_phys_parms.rsp.speed. Fix IBMVNIC_10GBPS typo. Fixes: f8d6ae0d27ec ("ibmvnic: Report actual backing device speed and duplex values") Signed-off-by: Lijun Pan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-24ibmvnic: Fix use-after-free of VNIC login response bufferThomas Falcon1-0/+1
The login response buffer is freed after it is received and parsed, but other functions in the driver still attempt to read it, such as when the device is opened, causing the Oops below. Store relevant information in the driver's private data structures and use those instead. BUG: Kernel NULL pointer dereference on read at 0x00000010 Faulting instruction address: 0xc00800000050a900 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: pseries_rng rng_core vmx_crypto gf128mul binfmt_misc ip_tables x_tables ibmvnic ibmveth crc32c_vpmsum autofs4 CPU: 7 PID: 759 Comm: NetworkManager Not tainted 5.9.0-rc1-00124-gd0a84e1f38d9 #14 NIP: c00800000050a900 LR: c00800000050a8f0 CTR: 00000000005b1904 REGS: c0000001ed746d20 TRAP: 0300 Not tainted (5.9.0-rc1-00124-gd0a84e1f38d9) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24428484 XER: 00000001 CFAR: c0000000000101b0 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0 GPR00: c00800000050a8f0 c0000001ed746fb0 c008000000518e00 0000000000000000 GPR04: 00000000000000c0 0000000000000080 0003c366c60c4501 0000000000000352 GPR08: 000000000001f400 0000000000000010 0000000000000000 0000000000000000 GPR12: 0001cf0000000019 c00000001ec97680 00000001003dfd40 0000010008dbb22c GPR16: 0000000000000000 0000000000000000 0000000000000000 c000000000edb6c8 GPR20: c000000004e73e00 c000000004fd2448 c000000004e6d700 c000000004fd2448 GPR24: c000000004fd2400 c000000004a0cd20 c0000001ed961860 c0080000005029d8 GPR28: 0000000000000000 0000000000000003 c000000004a0c000 0000000000000000 NIP [c00800000050a900] init_resources+0x338/0xa00 [ibmvnic] LR [c00800000050a8f0] init_resources+0x328/0xa00 [ibmvnic] Call Trace: [c0000001ed746fb0] [c00800000050a8f0] init_resources+0x328/0xa00 [ibmvnic] (unreliable) [c0000001ed747090] [c00800000050b024] ibmvnic_open+0x5c/0x100 [ibmvnic] [c0000001ed747110] [c000000000bdcc0c] __dev_open+0x17c/0x250 [c0000001ed7471b0] [c000000000bdd1ec] __dev_change_flags+0x1dc/0x270 [c0000001ed747260] [c000000000bdd2bc] dev_change_flags+0x3c/0x90 [c0000001ed7472a0] [c000000000bf24b8] do_setlink+0x3b8/0x1280 [c0000001ed747450] [c000000000bf8cc8] __rtnl_newlink+0x5a8/0x980 [c0000001ed7478b0] [c000000000bf9110] rtnl_newlink+0x70/0xb0 [c0000001ed7478f0] [c000000000bf07c4] rtnetlink_rcv_msg+0x364/0x460 [c0000001ed747990] [c000000000c68b94] netlink_rcv_skb+0x84/0x1a0 [c0000001ed747a00] [c000000000bef758] rtnetlink_rcv+0x28/0x40 [c0000001ed747a20] [c000000000c68188] netlink_unicast+0x218/0x310 [c0000001ed747a80] [c000000000c6848c] netlink_sendmsg+0x20c/0x4e0 [c0000001ed747b20] [c000000000b9dc88] ____sys_sendmsg+0x158/0x360 [c0000001ed747bb0] [c000000000ba1c88] ___sys_sendmsg+0x98/0xf0 [c0000001ed747d10] [c000000000ba1db8] __sys_sendmsg+0x78/0x100 [c0000001ed747dc0] [c000000000033820] system_call_exception+0x160/0x280 [c0000001ed747e20] [c00000000000d740] system_call_common+0xf0/0x27c Instruction dump: 3be00000 38810068 b1410076 3941006a 93e10072 fbea0000 b1210068 4bff9915 eb9e0ca0 eabe0900 393c0010 3ab50048 <7fa04c2c> 7fba07b4 7b431764 7b4917a0 ---[ end trace fbc5949a28e103bd ]--- Fixes: f3ae59c0c015 ("ibmvnic: store RX and TX subCRQ handle array in ibmvnic_adapter struct") Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-19ibmvnic: store RX and TX subCRQ handle array in ibmvnic_adapter structCristobal Forno1-0/+1
Currently the driver reads RX and TX subCRQ handle array directly from a DMA-mapped buffer address when it needs to make a H_SEND_SUBCRQ hcall. This patch stores that information in the ibmvnic_sub_crq_queue structure instead of reading from the buffer received at login. The overall goal of this patch is to parse relevant information from the login response buffer and store it in the driver's private data structures so that we don't need to read directly from the buffer and can then free up that memory. Signed-off-by: Cristobal Forno <[email protected]> Reviewed-by: Jesse Brandeburg <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-03-10ibmvnic: Do not process device remove during device resetJuliet Kim1-1/+5
The ibmvnic driver does not check the device state when the device is removed. If the device is removed while a device reset is being processed, the remove may free structures needed by the reset, causing an oops. Fix this by checking the device state before processing device remove. Signed-off-by: Juliet Kim <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-26ibmvnic: Serialize device queriesThomas Falcon1-0/+2
Provide some serialization for device CRQ commands and queries to ensure that the shared variable used for storing return codes is properly synchronized. Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-09-25net/ibmvnic: prevent more than one thread from running in resetJuliet Kim1-1/+4
The current code allows more than one thread to run in reset. This can corrupt struct adapter data. Check adapter->resetting before performing a reset, if there is another reset running delay (100 msec) before trying again. Signed-off-by: Juliet Kim <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-09-25net/ibmvnic: unlock rtnl_lock in reset so linkwatch_event can runJuliet Kim1-0/+1
Commit a5681e20b541 ("net/ibmnvic: Fix deadlock problem in reset") made the change to hold the RTNL lock during a reset to avoid deadlock but linkwatch_event is fired during the reset and needs the RTNL lock. That keeps linkwatch_event process from proceeding until the reset is complete. The reset process cannot tolerate the linkwatch_event processing after reset completes, so release the RTNL lock during the process to allow a chance for linkwatch_event to run during reset. This does not guarantee that the linkwatch_event will be processed as soon as link state changes, but is an improvement over the current code where linkwatch_event processing is always delayed, which prevents transmissions on the device from being deactivated leading transmit watchdog timer to time-out. Release the RTNL lock before link state change and re-acquire after the link state change to allow linkwatch_event to grab the RTNL lock and run during the reset. Fixes: a5681e20b541 ("net/ibmnvic: Fix deadlock problem in reset") Signed-off-by: Juliet Kim <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-05-24treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 114Thomas Gleixner1-12/+1
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 8 file(s). Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Allison Randal <[email protected]> Reviewed-by: Richard Fontana <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-05-10net/ibmvnic: Update MAC address settings after adapter resetThomas Falcon1-2/+0
It was discovered in testing that the underlying hardware MAC address will revert to initial settings following a device reset, but the driver fails to resend the current OS MAC settings. This oversight can result in dropped packets should the scenario occur. Fix this by informing hardware of current MAC address settings following any adapter initialization or resets. Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-04-27ibmvnic: Add device identification to requested IRQsMurilo Fossa Vicentini1-0/+2
The ibmvnic driver currently uses the same fixed name when using request_irq, this makes it hard to parse when multiple VNIC devices are available at the same time. This patch adds the unit_address as the device identification along with an id for each queue. The original idea was to use the interface name as an identifier, but it is not feasible given these requests happen at adapter probe, and at this point netdev is not yet registered so it doesn't have the proper name assigned to it. Signed-off-by: Murilo Fossa Vicentini <[email protected]> Reviewed-by: Mauro S. M. Rodrigues <[email protected]> Reviewed-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-03-19ibmvnic: Report actual backing device speed and duplex valuesMurilo Fossa Vicentini1-5/+13
The ibmvnic driver currently reports a fixed value for both speed and duplex settings regardless of the actual backing device that is being used. By adding support to the QUERY_PHYS_PARMS command defined by the PAPR+ we can query the current physical port state and report the proper values for these feilds. Reported-by: Abdul Haleem <[email protected]> Signed-off-by: Murilo Fossa Vicentini <[email protected]> Reviewed-by: Mauro S. M. Rodrigues <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-12-10ibmvnic: Convert reset work item mutex to spin lockThomas Falcon1-1/+1
ibmvnic_reset can create and schedule a reset work item from an IRQ context, so do not use a mutex, which can sleep. Convert the reset work item mutex to a spin lock. Locking debugger generated the trace output below. BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908 in_atomic(): 1, irqs_disabled(): 1, pid: 120, name: kworker/8:1 4 locks held by kworker/8:1/120: #0: 0000000017c05720 ((wq_completion)"events"){+.+.}, at: process_one_work+0x188/0x710 #1: 00000000ace90706 ((linkwatch_work).work){+.+.}, at: process_one_work+0x188/0x710 #2: 000000007632871f (rtnl_mutex){+.+.}, at: rtnl_lock+0x30/0x50 #3: 00000000fc36813a (&(&crq->lock)->rlock){..-.}, at: ibmvnic_tasklet+0x88/0x2010 [ibmvnic] irq event stamp: 26293 hardirqs last enabled at (26292): [<c000000000122468>] tasklet_action_common.isra.12+0x78/0x1c0 hardirqs last disabled at (26293): [<c000000000befce8>] _raw_spin_lock_irqsave+0x48/0xf0 softirqs last enabled at (26288): [<c000000000a8ac78>] dev_deactivate_queue.constprop.28+0xc8/0x160 softirqs last disabled at (26289): [<c0000000000306e0>] call_do_softirq+0x14/0x24 CPU: 8 PID: 120 Comm: kworker/8:1 Kdump: loaded Not tainted 4.20.0-rc6 #6 Workqueue: events linkwatch_event Call Trace: [c0000003fffa7a50] [c000000000bc83e4] dump_stack+0xe8/0x164 (unreliable) [c0000003fffa7aa0] [c00000000015ba0c] ___might_sleep+0x2dc/0x320 [c0000003fffa7b20] [c000000000be960c] __mutex_lock+0x8c/0xb40 [c0000003fffa7c30] [d000000006202ac8] ibmvnic_reset+0x78/0x330 [ibmvnic] [c0000003fffa7cc0] [d0000000062097f4] ibmvnic_tasklet+0x1054/0x2010 [ibmvnic] [c0000003fffa7e00] [c0000000001224c8] tasklet_action_common.isra.12+0xd8/0x1c0 [c0000003fffa7e60] [c000000000bf1238] __do_softirq+0x1a8/0x64c [c0000003fffa7f90] [c0000000000306e0] call_do_softirq+0x14/0x24 [c0000003f3f87980] [c00000000001ba50] do_softirq_own_stack+0x60/0xb0 [c0000003f3f879c0] [c0000000001218a8] do_softirq+0xa8/0x100 [c0000003f3f879f0] [c000000000121a74] __local_bh_enable_ip+0x174/0x180 [c0000003f3f87a60] [c000000000bf003c] _raw_spin_unlock_bh+0x5c/0x80 [c0000003f3f87a90] [c000000000a8ac78] dev_deactivate_queue.constprop.28+0xc8/0x160 [c0000003f3f87ad0] [c000000000a8c8b0] dev_deactivate_many+0xd0/0x520 [c0000003f3f87b70] [c000000000a8cd40] dev_deactivate+0x40/0x60 [c0000003f3f87ba0] [c000000000a5e0c4] linkwatch_do_dev+0x74/0xd0 [c0000003f3f87bd0] [c000000000a5e694] __linkwatch_run_queue+0x1a4/0x1f0 [c0000003f3f87c30] [c000000000a5e728] linkwatch_event+0x48/0x60 [c0000003f3f87c50] [c0000000001444e8] process_one_work+0x238/0x710 [c0000003f3f87d20] [c000000000144a48] worker_thread+0x88/0x4e0 [c0000003f3f87db0] [c00000000014e3a8] kthread+0x178/0x1c0 [c0000003f3f87e20] [c00000000000bfd0] ret_from_kernel_thread+0x5c/0x6c Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-11-19net/ibmnvic: Fix deadlock problem in resetJuliet Kim1-1/+1
This patch changes to use rtnl_lock only during a reset to avoid deadlock that could occur when a thread operating close is holding rtnl_lock and waiting for reset_lock acquired by another thread, which is waiting for rtnl_lock in order to set the number of tx/rx queues during a reset. Also, we now setting the number of tx/rx queues during a soft reset for failover or LPM events. Signed-off-by: Juliet Kim <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-10-01ibmvnic: Add ethtool private flag for driver-defined queue limitsThomas Falcon1-0/+6
When choosing channel amounts and ring sizes, the maximums in the ibmvnic driver are defined by the virtual i/o server management partition. Even though they are defined as maximums, the client driver may in fact successfully request resources that exceed these limits, which are mostly dependent on a user's hardware With this in mind, provide an ethtool flag that when enabled will allow the user to request resources limited by driver-defined maximums instead of limits defined by the management partition. The driver will try to honor the user's request but may not allowed by the management partition. In this case, the driver requests as close as it can get to the desired amount until it succeeds. Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-10-01ibmvnic: Introduce driver limits for ring sizesThomas Falcon1-0/+1
Introduce driver-defined maximums for queue ring sizes. Devices available for IBM vNIC today will likely not allow this amount, but this should give us some leeway for future devices that may support larger ring sizes. Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-10-01ibmvnic: Increase maximum queue size limitThomas Falcon1-1/+1
Increase queue size limit to 16. Devices available for IBM vNIC today will not allow this amount, but this should give us some leeway for future devices that may support more RX or TX queues. Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-08-07ibmvnic: Remove code to request error informationThomas Falcon1-33/+0
When backing device firmware reports an error, it provides an error ID, which is meant to be queried for more detailed error information. Currently, however, an error ID is not provided by the Virtual I/O server and there are not any plans to do so. For now, it is always unfilled or zero, so request_error_information will never be called. Remove it. Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-05-24ibmvnic: Introduce hard reset recoveryThomas Falcon1-0/+1
Introduce a recovery hard reset to handle reset failure as a result of change of device context following a transport event, such as a backing device failover or partition migration. These operations reset the device context to its initial state. If this occurs during a reset, any initialization commands are likely to fail with an invalid state error as backing device firmware requests reinitialization. When this happens, make one more attempt by performing a hard reset, which frees any resources currently allocated and performs device initialization. If a transport event occurs during a device reset, a flag is set which will trigger a new hard reset following the completionof the current reset event. Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-05-24ibmvnic: Introduce active CRQ stateThomas Falcon1-0/+1
Introduce an "active" state for a IBM vNIC Command-Response Queue. A CRQ is considered active once it has initialized or linked with its partner by sending an initialization request and getting a successful response back from the management partition. Until this has happened, do not allow CRQ commands to be sent other than the initialization request. This change will avoid a protocol error in case of a device transport event occurring during a initialization. When the driver receives a transport event notification indicating that the backing hardware has changed and needs reinitialization, any further commands other than the initialization handshake with the VIOS management partition will result in an invalid state error. Instead of sending a command that will be returned with an error, print a warning and return an error that will be handled by the caller. Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-04-12ibmvnic: Handle all login error conditionsNathan Fontenot1-1/+0
There is a bug in handling the possible return codes from sending the login CRQ. The current code treats any non-success return value, minus failure to send the crq and a timeout waiting for a login response, as a need to re-send the login CRQ. This can put the drive in an infinite loop of trying to login when getting return values other that a partial success such as a return code of aborted. For these scenarios the login will not ever succeed at this point and the driver would need to be reset again. To resolve this loop trying to login is updated to only retry the login if the driver gets a return code of a partial success. Other return codes are treated as an error and the driver returns an error from ibmvnic_login(). To avoid infinite looping in the partial success return cases, the number of retries is capped at the maximum number of supported queues. This value was chosen because the driver does a renegotiation of capabilities which sets the number of queues possible and allows the driver to attempt a login for possible value for the number of queues supported. Signed-off-by: Nathan Fontenot <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-04-08ibmvnic: Fix failover case for non-redundant configurationThomas Falcon1-0/+1
There is a failover case for a non-redundant pseries VNIC configuration that was not being handled properly. The current implementation assumes that the driver will always have a redandant device to communicate with following a failover notification. There are cases, however, when a non-redundant configuration can receive a failover request. If that happens, the driver should wait until it receives a signal that the device is ready for operation. The driver is agnostic of its backing hardware configuration, so this fix necessarily affects all device failover management. The driver needs to wait until it receives a signal that the device is ready for resetting. A flag is introduced to track this intermediary state where the driver is waiting for an active device. Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-03-17ibmvnic: Remove unused TSO resources in TX pool structureThomas Falcon1-2/+0
Finally, remove the TSO-specific fields in the TX pool strcutures. These are no longer needed with the introduction of separate buffer pools for TSO transmissions. Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-03-17ibmvnic: Update TX and TX completion routinesThomas Falcon1-0/+1
Update TX and TX completion routines to account for TX pool restructuring. TX routine first chooses the pool depending on whether a packet is GSO or not, then uses it accordingly. For the completion routine to know which pool it needs to use, set the most significant bit of the correlator index to one if the packet uses the TSO pool. On completion, unset the bit and use the correlator index to release the buffer pool entry. Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-03-17ibmvnic: Generalize TX pool structureThomas Falcon1-2/+3
Remove some unused fields in the structure and include values describing the individual buffer size and number of buffers in a TX pool. This allows us to use these fields for TX pool buffer accounting as opposed to using hard coded values. Include a new pool array for TSO transmissions. Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-22ibmvnic: Split counters for scrq/pools/napiNathan Fontenot1-2/+5
The approach of one counter to rule them all when tracking the number of active sub-crqs, pools, and napi has problems handling some failover scenarios. This is due to the split in initializing the sub crqs, pools and napi in different places and the placement of updating the active counts. This patch simplifies this by having a counter for tx and rx sub-crqs, pools, and napi. Signed-off-by: Nathan Fontenot <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-21ibmvnic: Rename active queue count variablesNathan Fontenot1-2/+2
Rename the tx/rx active pool variables to be tx/rx active scrq counts. The tx/rx pools are per sub-crq so this is a more appropriate name. This also is a preparatory step for using thiese variables for handling updates to sub-crqs and napi based on the active count. Signed-off-by: Nathan Fontenot <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-20ibmvnic: Keep track of supplementary TX descriptorsThomas Falcon1-0/+1
Supplementary TX descriptors were not being accounted for, which was resulting in an overflow of the hardware device's transmit queue. Keep track of those descriptors now when determining how many entries remain on the TX queue. Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-01-23Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller1-0/+2
en_rx_am.c was deleted in 'net-next' but had a bug fixed in it in 'net'. The esp{4,6}_offload.c conflicts were overlapping changes. The 'out' label is removed so we just return ERR_PTR(-EINVAL) directly. Signed-off-by: David S. Miller <[email protected]>
2018-01-22ibmvnic: Modify buffer size and number of queues on failoverJohn Allen1-0/+2
Using newer backing devices can cause the required padding at the end of buffer as well as the number of queues to change after a failover. Since we currently assume that these values never change, after a failover to a backing device with different capabilities, we can get errors from the vnic server, attempt to free long term buffers that are no longer there, or not free long term buffers that should be freed. This patch resolves the issue by checking whether any of these values change, and if so perform the necessary re-allocations. Signed-off-by: John Allen <[email protected]> Reviewed-by: Nathan Fontenot <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-19ibmvnic: Increase maximum number of RX/TX queuesThomas Falcon1-1/+1
Increase the number of queues allocated to accommodate recent network adapter inclusions on the IBM vNIC platform. Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-12-19ibmvnic: Rename IBMVNIC_MAX_TX_QUEUES to IBMVNIC_MAX_QUEUESThomas Falcon1-1/+1
This value denotes the maximum number of TX queues but is used to allocate both RX and TX queues. Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-11-14ibmvnic: Feature implementation of Vital Product Data (VPD) for the ibmvnic ↵Desnes Augusto Nunes do Rosario1-2/+25
driver This patch implements and enables VDP support for the ibmvnic driver. Moreover, it includes the implementation of suitable structs, signal transmission/handling and functions which allows the retrival of firmware information from the ibmvnic card through the ethtool command. Signed-off-by: Desnes A. Nunes do Rosario <[email protected]> Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-11-11ibmvnic: Add vnic client data to login bufferNathan Fontenot1-0/+2
Update the login buffer to include client data for the vnic driver, this includes the OS name, LPAR name, and device name. This update allows this information to be available in the VIOS. Signed-off-by: Nathan Fontenot <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-10-28ibmvnic: Fix failover error path for non-fatal resetsJohn Allen1-0/+2
For all non-fatal reset conditions, the hypervisor will send a failover when we attempt to initialize the crq and the vnic client is expected to handle that failover instead of the existing non-fatal reset. To handle this, we need to return from init with a return code that indicates that we have hit this case. Signed-off-by: John Allen <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-10-28ibmvnic: Update reset infrastructure to support tunable parametersJohn Allen1-1/+23
Update ibmvnic reset infrastructure to include a new reset option that will allow changing of tunable parameters. There currently is no way to request different capabilities from the vnic server on the fly so this patch achieves this by resetting the driver and attempting to log in with the requested changes. If the reset operation fails, the old values of the tunable parameters are stored in the "fallback" struct and we attempt to login with the fallback values. Signed-off-by: John Allen <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-10-19ibmvnic: Enable TSO supportThomas Falcon1-0/+5
This patch enables TSO support. It includes additional buffers reserved exclusively for large packets. Throughput is greatly increased with TSO enabled, from about 1 Gb/s to 9 Gb/s on our test systems. Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-08-03ibmvnic: Implement per-queue statistics reportingJohn Allen1-0/+17
Add counters to report number of packets, bytes, and dropped packets for each transmit queue and number of packets, bytes, and interrupts for each receive queue. Modify ethtool callbacks to report the new statistics. Signed-off-by: John Allen <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-06-22ibmvnic: Fix error handling when registering long-term-mapped buffersThomas Falcon1-0/+1
The patch stores the return code of the REQUEST_MAP_RSP sub-CRQ command in the private data structure, where it can be later checked during device open or a reset. In the case of a reset, the mapping request to the vNIC Server may fail, especially in the case of a partition migration. The driver attempts to handle this by re-allocating the buffer and re-sending the mapping request. The original error handling implementation was removed. The separate function handling the REQUEST_MAP response message was also removed, since it is now simple enough to be handled in the ibmvnic_handle_crq function. Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-06-22ibmvnic: Fix incorrectly defined ibmvnic_request_map_rsp structureThomas Falcon1-1/+1
This reserved area should be eight bytes in length instead of four. As a result, the return codes in the REQUEST_MAP_RSP descriptors were not being properly handled. Signed-off-by: Thomas Falcon <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-05-26ibmvnic: Non-fatal error handlingJohn Allen1-0/+1
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 <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-05-26ibmvnic: Handle failover after failed init crqJohn Allen1-1/+1
Handle case where phyp sends a failover after failing to send the init crq. Signed-off-by: John Allen <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-05-26ibmvnic: Track state of adapter napisJohn Allen1-0/+1
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: John Allen <[email protected]> Signed-off-by: Nathan Fontenot <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-05-03ibmvnic: Updated reset handlingNathan Fontenot1-4/+15
The ibmvnic driver has multiple handlers for resetting the driver depending on the reason the reset is needed (failover, lpm, fatal erors,...). All of the reset handlers do essentially the same thing, this patch moves this work to a common reset handler. By doing this we also allow the driver to better handle situations where we can get a reset while handling a reset. The updated reset handling works by adding a reset work item to the list of resets and then scheduling work to perform the reset. This step is necessary because we can receive a reset in interrupt context and we want to handle the reset out of interrupt context. Signed-off-by: Nathan Fontenot <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-05-03ibmvnic: Replace is_closed with state fieldNathan Fontenot1-2/+10
Replace the is_closed flag in the ibmvnic adapter strcut with a more comprehensive state field that tracks the current state of the driver. Signed-off-by: Nathan Fontenot <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-04-24ibmvnic: Add set_link_state routine for setting adapter link stateNathan Fontenot1-0/+1
Create a common routine for setting the link state for the vnic adapter. This update moves the sending of the crq and waiting for the link state response to a common place. The new routine also adds handling of resending the crq in cases of getting a partial success response. Signed-off-by: Nathan Fontenot <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-04-24ibmvnic: Insert header on VLAN tagged received frameMurilo Fossa Vicentini1-0/+2
This patch addresses a modification in the PAPR+ specification which now defines a previously reserved value for vNIC capabilities. It indicates whether the system firmware performs a VLAN header stripping on all VLAN tagged received frames, in case it does, the behavior expected is for the ibmvnic driver to be responsible for inserting the VLAN header. Reported-by: Manvanthara B. Puttashankar <[email protected]> Signed-off-by: Murilo Fossa Vicentini <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-04-21ibmvnic: Remove unused bouce bufferNathan Fontenot1-4/+0
The bounce buffer is not used in the ibmvnic driver, just get rid of it. Signed-off-by: Nathan Fontenot <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-04-21ibmvnic: Remove inflight listNathan Fontenot1-9/+0
The inflight list used to track memory that is allocated for crq that are inflight is not needed. The one piece of the inflight list that does need to be cleaned at module exit is the error buffer list which is already attached to the adapter struct. This patch removes the inflight list and moves checking the error buffer list to ibmvnic_remove. Signed-off-by: Nathan Fontenot <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-04-21ibmvnic: Fix ibmvnic_change_mac_addr struct formatMurilo Fossa Vicentini1-1/+1
The ibmvnic_change_mac_addr struct alignment was not matching the defined format in PAPR+, it had the reserved and return code fields swapped. As a consequence, the CHANGE_MAC_ADDR_RSP commands were being improperly handled and executed even when the operation wasn't successfully completed by the system firmware. Also changing the endianness of the debug message to make it easier to parse the CRQ content. Signed-off-by: Murilo Fossa Vicentini <[email protected]> Signed-off-by: Nathan Fontenot <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-03-30ibmvnic: Remove debugfs supportNathan Fontenot1-30/+0
The debugfs support in the ibmvnic driver is not, and never has been, supported. Just remove it. The work done in the debugfs code for the driver was part of the original spec for the ibmvnic driver. The corresponding support for this from the server side was never supported and has been dropped. Signed-off-by: Nathan Fontenot <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.