cxgb4: Fix spelling typos
Fix several spelling typos in comments in t4_hw.c. Signed-off-by: Arkadiusz Drabczyk <arkadiusz@drabczyk.org> Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
Arkadiusz Drabczyk
David S. Miller
parent
837636f586
commit
172ca8308b
|
|
@ -329,7 +329,7 @@ int t4_wr_mbox_meat_timeout(struct adapter *adap, int mbox, const void *cmd,
|
|||
for (i = 0; ; i += ms) {
|
||||
/* If we've waited too long, return a busy indication. This
|
||||
* really ought to be based on our initial position in the
|
||||
* mailbox access list but this is a start. We very rearely
|
||||
* mailbox access list but this is a start. We very rarely
|
||||
* contend on access to the mailbox ...
|
||||
*/
|
||||
pcie_fw = t4_read_reg(adap, PCIE_FW_A);
|
||||
|
|
@ -606,7 +606,7 @@ void t4_memory_rw_residual(struct adapter *adap, u32 off, u32 addr, u8 *buf,
|
|||
*
|
||||
* Reads/writes an [almost] arbitrary memory region in the firmware: the
|
||||
* firmware memory address and host buffer must be aligned on 32-bit
|
||||
* boudaries; the length may be arbitrary. The memory is transferred as
|
||||
* boundaries; the length may be arbitrary. The memory is transferred as
|
||||
* a raw byte sequence from/to the firmware's memory. If this memory
|
||||
* contains data structures which contain multi-byte integers, it's the
|
||||
* caller's responsibility to perform appropriate byte order conversions.
|
||||
|
|
@ -3774,7 +3774,7 @@ int t4_phy_fw_ver(struct adapter *adap, int *phy_fw_ver)
|
|||
* A negative error number will be returned if an error occurs. If
|
||||
* version number support is available and there's no need to upgrade
|
||||
* the firmware, 0 will be returned. If firmware is successfully
|
||||
* transferred to the adapter, 1 will be retured.
|
||||
* transferred to the adapter, 1 will be returned.
|
||||
*
|
||||
* NOTE: some adapters only have local RAM to store the PHY firmware. As
|
||||
* a result, a RESET of the adapter would cause that RAM to lose its
|
||||
|
|
@ -3808,7 +3808,7 @@ int t4_load_phy_fw(struct adapter *adap,
|
|||
}
|
||||
|
||||
/* Ask the firmware where it wants us to copy the PHY firmware image.
|
||||
* The size of the file requires a special version of the READ coommand
|
||||
* The size of the file requires a special version of the READ command
|
||||
* which will pass the file size via the values field in PARAMS_CMD and
|
||||
* retrieve the return value from firmware and place it in the same
|
||||
* buffer values
|
||||
|
|
@ -4082,7 +4082,7 @@ static inline fw_port_cap32_t cc_to_fwcap_pause(enum cc_pause cc_pause)
|
|||
fw_pause |= FW_PORT_CAP32_FORCE_PAUSE;
|
||||
|
||||
/* Translate orthogonal Pause controls into IEEE 802.3 Pause,
|
||||
* Asymetrical Pause for use in reporting to upper layer OS code, etc.
|
||||
* Asymmetrical Pause for use in reporting to upper layer OS code, etc.
|
||||
* Note that these bits are ignored in L1 Configure commands.
|
||||
*/
|
||||
if (cc_pause & PAUSE_RX) {
|
||||
|
|
@ -4151,7 +4151,7 @@ fw_port_cap32_t t4_link_acaps(struct adapter *adapter, unsigned int port,
|
|||
/* Convert Common Code Forward Error Control settings into the
|
||||
* Firmware's API. If the current Requested FEC has "Automatic"
|
||||
* (IEEE 802.3) specified, then we use whatever the Firmware
|
||||
* sent us as part of it's IEEE 802.3-based interpratation of
|
||||
* sent us as part of its IEEE 802.3-based interpretation of
|
||||
* the Transceiver Module EPROM FEC parameters. Otherwise we
|
||||
* use whatever is in the current Requested FEC settings.
|
||||
*/
|
||||
|
|
@ -4248,7 +4248,7 @@ int t4_link_l1cfg_core(struct adapter *adapter, unsigned int mbox,
|
|||
|
||||
/* Unfortunately, even if the Requested Port Capabilities "fit" within
|
||||
* the Physical Port Capabilities, some combinations of features may
|
||||
* still not be leagal. For example, 40Gb/s and Reed-Solomon Forward
|
||||
* still not be legal. For example, 40Gb/s and Reed-Solomon Forward
|
||||
* Error Correction. So if the Firmware rejects the L1 Configure
|
||||
* request, flag that here.
|
||||
*/
|
||||
|
|
@ -6797,7 +6797,7 @@ int t4_sge_ctxt_flush(struct adapter *adap, unsigned int mbox, int ctxt_type)
|
|||
}
|
||||
|
||||
/**
|
||||
* t4_read_sge_dbqtimers - reag SGE Doorbell Queue Timer values
|
||||
* t4_read_sge_dbqtimers - read SGE Doorbell Queue Timer values
|
||||
* @adap - the adapter
|
||||
* @ndbqtimers: size of the provided SGE Doorbell Queue Timer table
|
||||
* @dbqtimers: SGE Doorbell Queue Timer table
|
||||
|
|
@ -6925,8 +6925,8 @@ retry:
|
|||
waiting -= 50;
|
||||
|
||||
/*
|
||||
* If neither Error nor Initialialized are indicated
|
||||
* by the firmware keep waiting till we exaust our
|
||||
* If neither Error nor Initialized are indicated
|
||||
* by the firmware keep waiting till we exhaust our
|
||||
* timeout ... and then retry if we haven't exhausted
|
||||
* our retries ...
|
||||
*/
|
||||
|
|
@ -7238,7 +7238,7 @@ int t4_fl_pkt_align(struct adapter *adap)
|
|||
* separately. The actual Ingress Packet Data alignment boundary
|
||||
* within Packed Buffer Mode is the maximum of these two
|
||||
* specifications. (Note that it makes no real practical sense to
|
||||
* have the Pading Boudary be larger than the Packing Boundary but you
|
||||
* have the Padding Boundary be larger than the Packing Boundary but you
|
||||
* could set the chip up that way and, in fact, legacy T4 code would
|
||||
* end doing this because it would initialize the Padding Boundary and
|
||||
* leave the Packing Boundary initialized to 0 (16 bytes).)
|
||||
|
|
@ -8973,10 +8973,10 @@ static int t4_get_flash_params(struct adapter *adap)
|
|||
goto found;
|
||||
}
|
||||
|
||||
/* Decode Flash part size. The code below looks repetative with
|
||||
/* Decode Flash part size. The code below looks repetitive with
|
||||
* common encodings, but that's not guaranteed in the JEDEC
|
||||
* specification for the Read JADEC ID command. The only thing that
|
||||
* we're guaranteed by the JADEC specification is where the
|
||||
* specification for the Read JEDEC ID command. The only thing that
|
||||
* we're guaranteed by the JEDEC specification is where the
|
||||
* Manufacturer ID is in the returned result. After that each
|
||||
* Manufacturer ~could~ encode things completely differently.
|
||||
* Note, all Flash parts must have 64KB sectors.
|
||||
|
|
@ -9317,7 +9317,7 @@ int t4_init_devlog_params(struct adapter *adap)
|
|||
struct fw_devlog_cmd devlog_cmd;
|
||||
int ret;
|
||||
|
||||
/* If we're dealing with newer firmware, the Device Log Paramerters
|
||||
/* If we're dealing with newer firmware, the Device Log Parameters
|
||||
* are stored in a designated register which allows us to access the
|
||||
* Device Log even if we can't talk to the firmware.
|
||||
*/
|
||||
|
|
|
|||
Loading…
Reference in New Issue