From: Ivo van Doorn <ivdoorn@gmail.com>
To: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Cc: trivial@kernel.org, linville@tuxdriver.com,
johannes@sipsolutions.net, users@rt2x00.serialmonkey.com,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: [PATCH 4/8] trivial: fix some typos and punctuation in comments
Date: Thu, 15 Oct 2009 22:07:40 +0200 [thread overview]
Message-ID: <200910152207.41996.IvDoorn@gmail.com> (raw)
In-Reply-To: <1255636103-5817-1-git-send-email-cascardo@holoscopio.com>
On Thursday 15 October 2009, Thadeu Lima de Souza Cascardo wrote:
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt61pci.c | 36 ++++++++++++++++----------------
> 1 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
> index b20e3ea..343e565 100644
> --- a/drivers/net/wireless/rt2x00/rt61pci.c
> +++ b/drivers/net/wireless/rt2x00/rt61pci.c
> @@ -51,7 +51,7 @@ MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
> * These indirect registers work with busy bits,
> * and we will try maximal REGISTER_BUSY_COUNT times to access
> * the register while taking a REGISTER_BUSY_DELAY us delay
> - * between each attampt. When the busy bit is still set at that time,
> + * between each attempt. When the busy bit is still set at that time,
> * the access attempt is considered to have failed,
> * and we will print an error.
> */
> @@ -386,7 +386,7 @@ static int rt61pci_config_shared_key(struct rt2x00_dev *rt2x00dev,
> * The driver does not support the IV/EIV generation
> * in hardware. However it doesn't support the IV/EIV
> * inside the ieee80211 frame either, but requires it
> - * to be provided seperately for the descriptor.
> + * to be provided separately for the descriptor.
> * rt2x00lib will cut the IV/EIV data out of all frames
> * given to us by mac80211, but we must tell mac80211
> * to generate the IV/EIV data.
> @@ -397,7 +397,7 @@ static int rt61pci_config_shared_key(struct rt2x00_dev *rt2x00dev,
> /*
> * SEC_CSR0 contains only single-bit fields to indicate
> * a particular key is valid. Because using the FIELD32()
> - * defines directly will cause a lot of overhead we use
> + * defines directly will cause a lot of overhead, we use
> * a calculation to determine the correct bit directly.
> */
> mask = 1 << key->hw_key_idx;
> @@ -425,11 +425,11 @@ static int rt61pci_config_pairwise_key(struct rt2x00_dev *rt2x00dev,
> /*
> * rt2x00lib can't determine the correct free
> * key_idx for pairwise keys. We have 2 registers
> - * with key valid bits. The goal is simple, read
> - * the first register, if that is full move to
> + * with key valid bits. The goal is simple: read
> + * the first register. If that is full, move to
> * the next register.
> - * When both registers are full, we drop the key,
> - * otherwise we use the first invalid entry.
> + * When both registers are full, we drop the key.
> + * Otherwise, we use the first invalid entry.
> */
> rt2x00pci_register_read(rt2x00dev, SEC_CSR2, ®);
> if (reg && reg == ~0) {
> @@ -464,8 +464,8 @@ static int rt61pci_config_pairwise_key(struct rt2x00_dev *rt2x00dev,
> &addr_entry, sizeof(addr_entry));
>
> /*
> - * Enable pairwise lookup table for given BSS idx,
> - * without this received frames will not be decrypted
> + * Enable pairwise lookup table for given BSS idx.
> + * Without this, received frames will not be decrypted
> * by the hardware.
> */
> rt2x00pci_register_read(rt2x00dev, SEC_CSR4, ®);
> @@ -487,7 +487,7 @@ static int rt61pci_config_pairwise_key(struct rt2x00_dev *rt2x00dev,
> /*
> * SEC_CSR2 and SEC_CSR3 contain only single-bit fields to indicate
> * a particular key is valid. Because using the FIELD32()
> - * defines directly will cause a lot of overhead we use
> + * defines directly will cause a lot of overhead, we use
> * a calculation to determine the correct bit directly.
> */
> if (key->hw_key_idx < 32) {
> @@ -556,7 +556,7 @@ static void rt61pci_config_intf(struct rt2x00_dev *rt2x00dev,
> if (flags & CONFIG_UPDATE_TYPE) {
> /*
> * Clear current synchronisation setup.
> - * For the Beacon base registers we only need to clear
> + * For the Beacon base registers, we only need to clear
> * the first byte since that byte contains the VALID and OWNER
> * bits which (when set to 0) will invalidate the entire beacon.
> */
> @@ -1168,8 +1168,8 @@ static int rt61pci_check_firmware(struct rt2x00_dev *rt2x00dev,
> return FW_BAD_LENGTH;
>
> /*
> - * The last 2 bytes in the firmware array are the crc checksum itself,
> - * this means that we should never pass those 2 bytes to the crc
> + * The last 2 bytes in the firmware array are the crc checksum itself.
> + * This means that we should never pass those 2 bytes to the crc
> * algorithm.
> */
> fw_crc = (data[len - 2] << 8 | data[len - 1]);
> @@ -1986,7 +1986,7 @@ static void rt61pci_fill_rxdone(struct queue_entry *entry,
>
> /*
> * Hardware has stripped IV/EIV data from 802.11 frame during
> - * decryption. It has provided the data seperately but rt2x00lib
> + * decryption. It has provided the data separately but rt2x00lib
> * should decide if it should be reinserted.
> */
> rxdesc->flags |= RX_FLAG_IV_STRIPPED;
> @@ -2042,7 +2042,7 @@ static void rt61pci_txdone(struct rt2x00_dev *rt2x00dev)
> * During each loop we will compare the freshly read
> * STA_CSR4 register value with the value read from
> * the previous loop. If the 2 values are equal then
> - * we should stop processing because the chance it
> + * we should stop processing because the chance is
> * quite big that the device has been unplugged and
> * we risk going into an endless loop.
> */
> @@ -2330,7 +2330,7 @@ static int rt61pci_init_eeprom(struct rt2x00_dev *rt2x00dev)
> __set_bit(CONFIG_FRAME_TYPE, &rt2x00dev->flags);
>
> /*
> - * Detect if this device has an hardware controlled radio.
> + * Detect if this device has a hardware controlled radio.
> */
> if (rt2x00_get_field16(eeprom, EEPROM_ANTENNA_HARDWARE_RADIO))
> __set_bit(CONFIG_SUPPORT_HW_BUTTON, &rt2x00dev->flags);
> @@ -2355,7 +2355,7 @@ static int rt61pci_init_eeprom(struct rt2x00_dev *rt2x00dev)
> __set_bit(CONFIG_EXTERNAL_LNA_BG, &rt2x00dev->flags);
>
> /*
> - * When working with a RF2529 chip without double antenna
> + * When working with a RF2529 chip without double antenna,
> * the antenna settings should be gathered from the NIC
> * eeprom word.
> */
> @@ -2668,7 +2668,7 @@ static int rt61pci_conf_tx(struct ieee80211_hw *hw, u16 queue_idx,
>
> /*
> * We only need to perform additional register initialization
> - * for WMM queues/
> + * for WMM queues.
> */
> if (queue_idx >= 4)
> return 0;
next prev parent reply other threads:[~2009-10-15 20:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-15 19:48 [PATCH 4/8] trivial: fix some typos and punctuation in comments Thadeu Lima de Souza Cascardo
2009-10-15 20:07 ` Ivo van Doorn [this message]
2009-10-16 13:27 ` Jiri Kosina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200910152207.41996.IvDoorn@gmail.com \
--to=ivdoorn@gmail.com \
--cc=cascardo@holoscopio.com \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=netdev@vger.kernel.org \
--cc=trivial@kernel.org \
--cc=users@rt2x00.serialmonkey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).