- 02 Jan, 2013 34 commits
-
-
Sony Chacko authored
83xx ethtool interface routines Signed-off-by:
Anirban Chakraborty <anirban.chakraborty@qlogic.com> Signed-off-by:
Sucheta Chakraborty <sucheta.chakraborty@qlogic.com> Signed-off-by:
Jitendra Kalsaria <jitendra.kalsaria@qlogic.com> Signed-off-by:
Sony Chacko <sony.chacko@qlogic.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sony Chacko authored
Add 83xx register dump routines Update 82xx register dump routines Signed-off-by:
Rajesh Borundia <rajesh.borundia@qlogic.com> Signed-off-by:
Sritej Velaga <sritej.velaga@qlogic.com> Signed-off-by:
-
Sony Chacko authored
Enable 83xx virtual NIC mode Signed-off-by:
-
Sony Chacko authored
Flash template provides instructions to stop, restart and initalize the firmware. These instructions are abstracted as a series of read, write and poll operations on hardware registers. Register information and operation specifics are not exposed to the driver. Driver reads the template from flash and executes the instructions located at pre-defined offsets. Template based firmware reset recovery and initialization mechanism minimize driver changes as firmware evolves. Signed-off-by:
-
Sony Chacko authored
Inter Driver Communication (IDC) module. CNA function drivers(ISCSI, FCOE and NIC) which shares the adapter relies on IDC mechanism for gracefull shut down, restart and firmware error recovery. Signed-off-by:
-
Sony Chacko authored
83xx adapter flash memory map, data structures and interface routines Signed-off-by:
Himanshu Madhani <himanshu.madhani@qlogic.com> Signed-off-by:
-
Sony Chacko authored
Add 83xx sysfs interface routines Update 82xx sysfs interface routines Signed-off-by:
-
Sony Chacko authored
Enable base 83xx adapter driver. Common driver interface routines like probe, interface up/down routines, irq and resource allocation routines are modified to add support for 83xx adapter. Signed-off-by:
-
Sony Chacko authored
Add 83xx adapter data path routines Update few 82xx adapter data path routines Modify datapath resource allocation routines Signed-off-by:
-
Sony Chacko authored
83xx adapter register map. 83xx hardware interface routines. Signed-off-by:
-
Himanshu Madhani authored
Refactor 82xx driver to support new adapter - Qlogic 83XX CNA Use QLC_SHARED_REG_RD32 and QLC__SHARED_REG_WR32 macros for 82xx and 83xx common register access. Signed-off-by:
-
Sony Chacko authored
Refactor 82xx driver to support new adapter - Qlogic 83XX CNA Create adapter abstraction layer and seperate 82xx hardware access routines. Create mailbox based HW interface mechanism Signed-off-by:
-
Ariel Elior authored
Add the various VF device ids (of all supported hardware) Add the calls to enable_sriov and disable_sriov to enable the SR-IOV feature. This patch also advances the version and release date of the bnx2x module. Signed-off-by:
Ariel Elior <ariele@broadcom.com> Signed-off-by:
Eilon Greenstein <eilong@broadcom.com> Signed-off-by:
-
Ariel Elior authored
The PF <-> VF Bulletin Board is a simple interface between the PF and the VF. The main reason for the Bulletin Board is to allow the PF to be the initiator. The VF publishes at 'acquire' stage the GPA of a Bulletin Board structure it has allocated. The PF notes this GPA in the VF database. The VF samples the Bulletin Board periodically for new messages. The latest version of the BB is always used. Signed-off-by:
-
Ariel Elior authored
The FLR indication arrives as an attention from the management processor. Upon VF flr all FLRed function in the indication have already been released by Firmware and now we basically need to free the resources allocated to those VFs, and clean any remainders from the device (FLR final cleanup). Signed-off-by:
-
Ariel Elior authored
The 'release' request is the opposite of the 'acquire' request. At release, all the resources allocated to the VF are reclaimed. The release flow applies the close flow if applicable. Note that there are actually two types of release: 1. The VF has been removed, and so issued a 'release' request over the VF <-> PF Channel. 2. The PF is going down and so has to release all of it's VFs. Signed-off-by:
-
Ariel Elior authored
The 'close' command is the opposite of an init request. Here the queues of the VF are closed (if any are opened) and released. This flow applies the 'q_teardown' flow on all the queues. The VF state is changed by this request. Interrupts are disabled for the VF when closed. Signed-off-by:
-
Ariel Elior authored
The 'q_teardown' request is basically the opposite of the 'q_setup'. Here the PF driver removes from the device the queue it opened against the VF fastpath ring at 'setup_q' stage, along with all related rx_mode info. Signed-off-by:
-
Ariel Elior authored
The VF driver uses the 'q_filters' message on the VF <-> PF channel for configuring an open queue, for example when the rxmode changes. Signed-off-by:
-
Ariel Elior authored
Upon receiving a 'setup_q' request from the VF over the VF <-> PF channel the PF driver will open a corresponding queue in the device. The PF driver configures the queue with appropriate mac address, vlan configuration, etc from the VF. Signed-off-by:
-
Ariel Elior authored
Statistics are collected by the PF driver. The collection is performed via a query sent to the device which is basically an array of 3-tuples of the form (statistics client, function, DMAE address). In this patch the PF driver adds to the query, on top of the statistics clients it is maintaining for itself (rss queues, storage, etc), the 3-tuples for the VFs it is maintaining. The addresses used are the GPAs of the statistics buffers supplied by the VF in the init message on the VF <-> PF channel. The function parameter ensures that the iommu will translate the GPA to the correct physical address. Signed-off-by:
-
Ariel Elior authored
The VF driver will send an 'init' request as part of its nic load flow. This message is used by the VF to publish the GPA's of its status blocks, slow path ring and statistics buffer. The PF driver notes all this down in the VF database, and also uses this message to transfer the VF to VF_INIT state internally. Signed-off-by:
-
Ariel Elior authored
When a VF is probed by the VF driver, the VF driver sends an 'acquire' request over the VF <-> PF channel for the resources it needs to operate (interrupts, queues, etc). The PF driver either ratifies the request and allocates the resources, responds with the maximum values it will allow the VF to acquire, or fails the request entirely if there is a problem. Signed-off-by:
-
Ariel Elior authored
Support interrupt from device which indicates VF has placed A request on the VF <-> PF channel. The PF driver issues a DMAE to retrieve the request from the VM memory (the Ghost Physical Address of the request is contained in the interrupt. The PF driver uses the GPA in the DMAE request, which is translated by the IOMMU to the correct physical address). The request which arrives is examined to recognize the sending VF. The PF driver allocates a workitem to handle the VF Operation (vfop). Signed-off-by:
-
Ariel Elior authored
At nic load of the PF, if VFs may be present, prepare the device for the VFs. Initialize the VF database in preparation of VF arrival. Signed-off-by:
-
Ariel Elior authored
When A PF determines that it may have to manage SRIOV VFs it allocates a database for this purpose. The database is intended to keep track of the VF state, the resources allocated for each VF (queues, interrupt vectors, etc), the state of the VF's queues. When the VF loads the database is updated accordingly. When A VF closes the database is consulted to determine which resources need to be released (close queues against device, reclaim interrupt vectors, etc). Signed-off-by:
-
Ariel Elior authored
When VF driver is transmitting it must supply the correct mac address in the parsing BD. This is used for firmware validation and enforcement and also for tx-switching. Refactor interrupt ack flow to allow for different BAR addresses of the hardware in the PF BAR vs the VF BAR. Signed-off-by:
-
Ariel Elior authored
The VF driver uses the 'q_filter' request in the VF <-> PF channel to have the PF configure the requested rxmode to device. ndo_set_rxmode is called under bottom half lock, so sleeping until the response arrives over the VF <-> PF channel is out of the question. For this reason the VF driver returns from the ndo after scheduling a work item, which in turn processes the rx mode request and adds the classification information through the VF <-> PF channel accordingly. Signed-off-by:
-
Ariel Elior authored
When a VF is being closed its queues are released via the 'teardown_q' and the VF itself is closed with 'close'. These are essentially the unload counterparts of 'init' and 'setup_q' from the load flow. Signed-off-by:
-
Ariel Elior authored
'init' - init an acquired VF. Supply allocation GPAs to PF. 'setup_q' - PF to allocate a queue in device on behalf of the VF. 'set_mac' - PF to configure a mac in device on behalf of the VF. VF driver uses these requests in the VF <-> PF channel in nic_load flow. Signed-off-by:
-
Ariel Elior authored
Generally, the VF driver cannot access the chip, except by the narrow window its BAR allows. Care had to be taken so the VF driver will not reach code which accesses the chip elsewhere. Refactor the nic_load flow into parts so it would be easier to separate the VF-only logic from the PF-only logic. Signed-off-by:
-
Ariel Elior authored
VF driver uses this request when removed. The PF driver reclaims all resources allocated for that VF at this time. Signed-off-by:
-
Ariel Elior authored
Add the 'acquire' request to VF <-> PF channel and use it at VF probe. In the acquire request the VF driver lists the resources it would like to have. In the response the PF either ratifies the request, or denies it and supplies the maximum values supported. The VF may then attempt another acquire request. This patch adds the bnx2x_vfpf.c file which contains the implementation of the VF to PF hardware channel. Signed-off-by:
-
Ariel Elior authored
To support probing and removing of a bnx2x virtual function the following were added: 1. add bnx2x_vfpf.h: defines the VF to PF channel 2. add bnx2x_sriov.h: header for bnx2x SR-IOV functionality 3. enumerate VF hw types (identify VFs) 4. if driving a VF, map VF bar 5. if driving a VF, allocate Vf to PF channel 6. refactor interrupt flows to include VF Signed-off-by:
-
- 30 Dec, 2012 6 commits
-
-
Flavio Leitner authored
This patch adds few ethtool operations to team driver. Signed-off-by:
Flavio Leitner <fbl@redhat.com> Acked-by:
Jiri Pirko <jiri@resnulli.us> Signed-off-by:
-
Eric Dumazet authored
veth is lacking most modern facilities, like SG, checksums, TSO. It makes sense to extend dev->features to get them, or GRO aggregation is defeated by a forced segmentation. Reported-by:
Andrew Vagin <avagin@parallels.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by:
-
Eric Dumazet authored
veth stats are a bit bloated. There is no need to account transmit and receive stats, since they are absolutely symmetric. Also use a per device atomic64_t for the dropped counter, as it should never be used in fast path. Signed-off-by:
-
Flavio Leitner authored
The user space teamd daemon may need to control the master's carrier state depending on the selected mode. Signed-off-by:
-
stephen hemminger authored
The bridge link detection should follow the operational state of the lower device, rather than the carrier bit. This allows devices like tunnels that are controlled by userspace control plane to work with bridge STP link management. Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Reviewed-by:
-
Daniel Borkmann authored
Currently, we return -EINVAL for malformed or wrong BPF filters. However, this is not done for BPF_S_ANC* operations, which makes it more difficult to detect if it's actually supported or not by the BPF machine. Therefore, we should also return -EINVAL if K is within the SKF_AD_OFF universe and the ancillary operation did not match. Why exactly is it needed? If tools such as libpcap/tcpdump want to make use of new ancillary operations (like filtering VLAN in kernel space), there is currently no sane way to test if this feature / BPF_S_ANC* op is present or not, since no error is returned. This patch will make life easier for that and allow for a proper usage for user space applications. There was concern, if this patch will break userland. Short answer: Yes and no. Long answer: It will "break" only for code that calls ... { BPF_LD | BPF_(W|H|B) | BPF_ABS, 0, 0, <K> }, ... where <K> is in [0xfffff000, 0xffffffff] _and_ <K> is *not* an ancillary. And here comes the BUT: assuming some *old* code will have such an instruction where <K> is between [0xfffff000, 0xffffffff] and it doesn't know ancillary operations, then this will give a non-expected / unwanted behavior as well (since we do not return the BPF machine with 0 after a failed load_pointer(), which was the case before introducing ancillary operations, but load sth. into the accumulator instead, and continue with the next instruction, for instance). Thus, user space code would already have been broken by introducing ancillary operations into the BPF machine per se. Code that does such a direct load, e.g. "load word at packet offset 0xffffffff into accumulator" ("ld [0xffffffff]") is quite broken, isn't it? The whole assumption of ancillary operations is that no-one intentionally calls things like "ld [0xffffffff]" and expect this word to be loaded from such a packet offset. Hence, we can also safely make use of this feature testing patch and facilitate application development. Therefore, at least from this patch onwards, we have *for sure* a check whether current or in future implemented BPF_S_ANC* ops are supported in the kernel. Patch was tested on x86_64. (Thanks to Eric for the previous review.) Cc: Eric Dumazet <eric.dumazet@gmail.com> Reported-by:Ani Sinha <ani@aristanetworks.com> Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Signed-off-by:
-
