summaryrefslogtreecommitdiffstats
path: root/src/include
Commit message (Collapse)AuthorAgeFilesLines
* [pci] Add generic configuration space backup/restore facilityMichael Brown2009-10-141-0/+33
| | | | | | Some devices can only be reset via a mechanism that also resets the card's PCI core, thus necessitating a backup and restore of all or part of the PCI configuration space across a reset.
* [job] Add missing job_progress() interface methodMichael Brown2009-08-311-0/+2
|
* [802.11] Support multicast hashingMichael Brown2009-08-121-0/+2
| | | | | | | 802.11 multicast hashing is the same as standard Ethernet hashing, so just expose and use eth_mc_hash(). Signed-off-by: Joshua Oreman <oremanj@rwcr.net>
* [dhcp] Fall back to using the hardware address to populate the chaddr fieldMichael Brown2009-08-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | For IPoIB, the chaddr field is too small (16 bytes) to contain the 20-byte IPoIB link-layer address. RFC4390 mandates that we should pass an empty chaddr field and rely on the DHCP client identifier instead. This has many problems, not least of which is that a client identifier containing an IPoIB link-layer address is not very useful from the point of view of creating DHCP reservations, since the QPN component is assigned at runtime and may vary between boots. Leave the DHCP client identifier as-is, to avoid breaking existing setups as far as possible, but expose the real hardware address (the port GUID) via the DHCP chaddr field, using the broadcast flag to instruct the DHCP server not to use this chaddr value as a link-layer address. This makes it possible (at least with ISC dhcpd) to create DHCP reservations using host declarations such as: host duckling { fixed-address 10.252.252.99; hardware unknown-32 00:02:c9:02:00:25:a1:b5; }
* [netdevice] Allow the hardware and link-layer addresses to differ in sizeMichael Brown2009-08-122-2/+21
| | | | | | | | | | IPoIB has a 20-byte link-layer address, of which only eight bytes represent anything relating to a "hardware address". The PXE and EFI SNP APIs expect the permanent address to be the same size as the link-layer address, so fill in the "permanent address" field with the initial link layer address (as generated by register_netdev() based upon the real hardware address).
* [netdevice] Separate out the concept of hardware and link-layer addressesMichael Brown2009-08-121-4/+11
| | | | | | | | | | | The hardware address is an intrinsic property of the hardware, while the link-layer address can be changed at runtime. This separation is exposed via APIs such as PXE and EFI, but is currently elided by gPXE. Expose the hardware and link-layer addresses as separate properties within a net device. Drivers should now fill in hw_addr, which will be used to initialise ll_addr at the time of calling register_netdev().
* [infiniband] Disambiguate CM connection rejection reasonsMichael Brown2009-08-101-0/+5
| | | | | | | | | | | | | There is diagnostic value in being able to disambiguate between the various reasons why an IB CM has rejected a connection attempt. In particular, reason 8 "invalid service ID" can be used to identify an incorrect SRP service_id root-path component, and reason 28 "consumer reject" corresponds to a genuine SRP login rejection IU, which can be passed up to the SRP layer. For rejection reasons other than "consumer reject", we should not pass through the private data, since it is most likely generated by the CM without any protocol-specific knowledge.
* [infiniband] Allow SRP reconnection attempts even after reporting failuresMichael Brown2009-08-101-6/+0Star
| | | | | | | | | With iSCSI, connection attempts are expensive; it may take many seconds to determine that a connection will fail. SRP connection attempts are much less expensive, so we may as well avoid the "optimisation" of declaring a state of permanent failure after a certain number of attempts. This allows a gPXE SRP initiator to resume operations after an arbitrary amount of SRP target downtime.
* [infiniband] Add support for SRP over InfinibandMichael Brown2009-08-104-0/+957
| | | | | | | | SRP is the SCSI RDMA Protocol. It allows for a method of SAN booting whereby the target is responsible for reading and writing data using Remote DMA directly to the initiator's memory. The software initiator merely sends and receives SCSI commands; it never has to touch the actual data.
* [infiniband] Add last_opened_ibdev(), analogous to last_opened_netdev()Michael Brown2009-08-101-0/+3
| | | | | | | The minimal-surprise behaviour, when no explicit SRP initiator device is specified, will probably be to use the most recently opened Infiniband device. This matches our behaviour with using the most recently opened net device for PXE, iSCSI, AoE, NBI, etc.
* [infiniband] Add find_ibdev()Michael Brown2009-08-101-0/+1
|
* [infiniband] Add a "communication-managed reliable connection" protocolMichael Brown2009-08-102-0/+21
| | | | | | | SRP over Infiniband uses a protocol whereby data is sent via a combination of the CM private data fields and the RC queue pair itself. This seems sufficiently generic that it's worth having available as a separate protocol.
* [scsi] Make LUN a property of the SCSI backend onlyMichael Brown2009-08-101-2/+0Star
| | | | | Nothing within the SCSI core actually refers to the LUN, so we can simplify matters by treating it as purely a property of the backend.
* [scsi] Generalise iscsi_parse_lun() to scsi_parse_lun()Michael Brown2009-08-102-11/+17
|
* [scsi] Generalise iscsi_detached_command() to scsi_detached_command()Michael Brown2009-08-101-0/+2
|
* [process] Make it safe to call process_add() multiple timesMichael Brown2009-08-101-0/+1
|
* [infiniband] Handle duplicate Communication Management REPsMichael Brown2009-08-091-0/+3
| | | | | | | | | | | We will terminate our transaction as soon as we receive the first CM REP, since that provides all the state that we need. However, the peer may resend the REP if it didn't see our RTU, and if we don't respond with another RTU we risk being disconnected. (This protocol appears not to handle retries gracefully.) Fix by adding a management agent that will listen for these duplicate REPs and send back an RTU.
* [ath5k] Add support for non-802.11n Atheros wireless NICsJoshua Oreman2009-08-091-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@etherboot.org>
* [legal] Add MIT licence declarationJoshua Oreman2009-08-091-0/+10
| | | | Signed-off-by: Michael Brown <mcb30@etherboot.org>
* [802.11] Fix maximum packet lengthJoshua Oreman2009-08-091-5/+13
| | | | | | | | | | | | | Previously the maximum packet length was computed using an erroneous understanding of the role of the MIC field in TKIP-encrypted packets. The field is actually considered to be part of the MSDU (encrypted and fragmented data), not the MPDU (container for each encrypted fragment). As such its size does not contribute to cryptographic overhead outside the data field's size limitations. The net result is that the previous maximum packet length value was 4 bytes too long; fix it to the correct value of 2352. Signed-off-by: Michael Brown <mcb30@etherboot.org>
* [802.11] Enhance support for driver PHY differencesJoshua Oreman2009-08-091-6/+39
| | | | | | | | | | | | | | | | | The prior net80211 model of physical-layer behavior for drivers was overly simplistic and limited the drivers that could be written. To be more flexible, split the driver-provided list of supported rates by band, and add a means for specifying a list of supported channels. Allow drivers to specify a hardware channel value that will be tied to uses of the channel. Expose net80211_duration() to drivers, and make the rate it uses in its computations configurable, so that it can be used in calculating durations that must be set in hardware for ACK and CTS packets. Add net80211_cts_duration() for the common case of calculating the duration for a CTS packet. Signed-off-by: Michael Brown <mcb30@etherboot.org>
* [infiniband] Update all other MAD users to use a management interfaceMichael Brown2009-08-096-76/+157
|
* [infiniband] Update subnet management agent to use a management interfaceMichael Brown2009-08-094-6/+28
|
* [infiniband] Add the concept of a management interfaceMichael Brown2009-08-093-1/+139
| | | | | | | | | A management interface is the component through which both local and remote management agents are accessed. This new implementation of a management interface allows for the user to react to timed-out transactions, and also allows for cancellation of in-progress transactions.
* [infiniband] Change IB_{QPN,QKEY,QPT} names from {SMA,GMA} to {SMI,GSI}Michael Brown2009-08-061-10/+10
| | | | | | | | | | The IBA specification refers to management "interfaces" and "agents". The interface is the component that connects to the queue pair and sends and receives MADs; the agent is the component that constructs the reply to the MAD. Rename the IB_{QPN,QKEY,QPT} constants as a first step towards making this separation in gPXE.
* [sky2] Add support for Marvell Yukon-II gigabit Ethernet cardsJoshua Oreman2009-08-031-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@etherboot.org>
* [pci] Add definitions for Advanced Error Reporting registersJoshua Oreman2009-08-031-0/+27
| | | | Signed-off-by: Michael Brown <mcb30@etherboot.org>
* [rtl818x] Add driver for Realtek 8180/8185 wireless cardsJoshua Oreman2009-08-011-0/+1
|
* [802.11] Add support for 802.11 devices with software MAC layerJoshua Oreman2009-08-014-0/+2177
| | | | | | | | | This is required for all modern 802.11 devices, and allows drivers to be written for them with minimally more effort than is required for a wired NIC. Signed-off-by: Michael Brown <mcb30@etherboot.org> Modified-by: Michael Brown <mcb30@etherboot.org>
* [infiniband] Add Communication Manager (CM)Michael Brown2009-07-183-0/+195
| | | | | The Communication Manager is responsible for handling the setup and teardown of RC connections.
* [infiniband] Add infrastructure for RC queue pairsMichael Brown2009-07-181-51/+63
| | | | | | | | | | | | | | | | | | Queue pairs are now assumed to be created in the INIT state, with a call to ib_modify_qp() required to bring the queue pair to the RTS state. ib_modify_qp() no longer takes a modification list; callers should modify the relevant queue pair parameters (e.g. qkey) directly and then call ib_modify_qp() to synchronise the changes to the hardware. The packet sequence number is now a property of the queue pair, rather than of the device. Each queue pair may have an associated address vector. For RC queue pairs, this is the address vector that will be programmed in to the hardware as the remote address. For UD queue pairs, it will be used as the default address vector if none is supplied to ib_post_send().
* [infiniband] Pass a generic MAD to ib_set_port_info()Michael Brown2009-07-181-5/+3Star
|
* [infiniband] Expose supported and enabled link speeds and widthsMichael Brown2009-07-181-4/+12
|
* [infiniband] Allow MAD handlers to indicate response via return valueMichael Brown2009-07-181-9/+4Star
| | | | | | | | Now that MAD handlers no longer return a status code, we can allow them to return a pointer to a MAD structure if and only if they want to send a response. This provides a more natural and flexible approach than using a "response method" field within the handler's descriptor.
* [infiniband] Remove the return status code from MAD handlersMichael Brown2009-07-181-2/+1Star
| | | | | | | | | | | | | MAD handlers have to set the status fields within the MAD itself anyway, in order to provide a meaningful response MAD; the additional gPXE return status code is just noise. Note that we probably don't need to ever explicitly set the status to IB_MGMT_STATUS_OK, since it should already have this value from the request. (By not explicitly setting the status in this way, we can safely have ib_sma_set_xxx() call ib_sma_get_xxx() in order to generate the GetResponse MAD without worrying that ib_sma_get_xxx() will clear any error status set by ib_sma_set_xxx().)
* [infiniband] Allow external QPN to differ from real QPNMichael Brown2009-07-181-1/+8
| | | | | | | Most IB hardware seems not to allow allocation of the genuine QPNs 0 and 1, so allow for the externally-visible QPN (as constructed and parsed by ib_packet, where used) to differ from the real hardware-allocated QPN.
* [infiniband] Always create an SMA and a GMAMichael Brown2009-07-183-33/+7Star
|
* [infiniband] Add notion of a queue pair typeMichael Brown2009-07-182-4/+15
|
* [infiniband] Implement SMA as an instance of a GMAMichael Brown2009-07-184-39/+21Star
| | | | | The GMA code was based upon the SMA code. We can save space by making the SMA simply an instance of the GMA.
* [infiniband] Pass GMA as a parameter to GMA MAD handlersMichael Brown2009-07-181-8/+9
|
* [ipoib] Remove the queue set abstractionMichael Brown2009-07-181-31/+0Star
| | | | | Now that IPoIB has to deal with only one set of queues, the queue set abstraction becomes merely an inconvenient wrapper.
* [infiniband] Provide a general mechanism for multicast group joinsMichael Brown2009-07-183-0/+22
| | | | Generalise out the multicast group membership record code from IPoIB.
* [infiniband] Allow for sending MADs via GMA without retransmissionMichael Brown2009-07-181-1/+1
|
* [infiniband] Provide a general mechanism for path record lookupsMichael Brown2009-07-182-0/+18
| | | | Generalise out the path record lookup code from IPoIB.
* [infiniband] Create a general management agentMichael Brown2009-07-184-0/+91
| | | | | | Generalise the subnet management agent into a general management agent capable of sending and responding to MADs, including support for retransmissions as necessary.
* [infiniband] Centralise SMA and GMA queue constantsMichael Brown2009-07-182-11/+14
|
* [infiniband] Poll completion queues automaticallyMichael Brown2009-07-183-18/+11Star
| | | | | | | | | | | | | | | | | Currently, all Infiniband users must create a process for polling their completion queues (or rely on a regular hook such as netdev_poll() in ipoib.c). Move instead to a model whereby the Infiniband core maintains a single process calling ib_poll_eq(), and polling the event queue triggers polls of the applicable completion queues. (At present, the Infiniband core simply polls all of the device's completion queues.) Polling a completion queue will now implicitly refill all attached receive work queues; this is analogous to the way that netdev_poll() implicitly refills the RX ring. Infiniband users no longer need to create a process just to poll their completion queues and refill their receive rings.
* [infiniband] Centralise assumption of 2048-byte payloadsMichael Brown2009-07-184-10/+9Star
| | | | | | | | | | IPoIB and the SMA have separate constants for the packet size to be used to I/O buffer allocations. Merge these into the single IB_MAX_PAYLOAD_SIZE constant. (Various other points in the Infiniband stack have hard-coded assumptions of a 2048-byte payload; we don't currently support variable MTUs.)
* [infiniband] Provide ib_get_hca_info() as a commonly-available functionMichael Brown2009-07-182-3/+5
|
* [infiniband] Split queue set functionality out of ipoib.c to ib_qset.cMichael Brown2009-07-182-0/+39
|
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-03-20 14:02:46 +0100