All of lore.kernel.org
 help / color / mirror / Atom feed
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, &reg);
>  		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, &reg);
> @@ -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;



WARNING: multiple messages have this Message-ID (diff)
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@host1.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, &reg);
>  		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, &reg);
> @@ -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;



  reply	other threads:[~2009-10-15 20:08 UTC|newest]

Thread overview: 5+ 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 19:48 ` Thadeu Lima de Souza Cascardo
2009-10-15 20:07 ` Ivo van Doorn [this message]
2009-10-15 20:07   ` Ivo van Doorn
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.