linux-kernel - Re: [PATCH v3] staging: rtl8192e: Fix spelling mistakes in rtllib

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5f591c67-235c-4afa-bf87-8fd01dc0e5af@gmail.com>
Date: Sat, 25 May 2024 21:53:16 +0200
From: Philipp Hortmann <philipp.g.hortmann@...il.com>
To: Roshan Khatri <topofeverest8848@...il.com>, gregkh@...uxfoundation.org,
 tdavies@...kphysics.net, garyrookard@...tmail.org
Cc: linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] staging: rtl8192e: Fix spelling mistakes in
 rtllib_softmac.c

On 24.05.24 06:12, Roshan Khatri wrote:
> This patch corrects some misspellings to increase code readability and
> searching.
> 
> Signed-off-by: Roshan Khatri <topofeverest8848@...il.com>
> ---
> v3:
>   - Added the missing patch history on v2 patch
> v2:
>   - Updated the patch description as suggested by Phillips
>   - https://lore.kernel.org/all/1aefa708-b1fe-4246-bb67-36f25919c766@gmail.com/
> v1: https://lore.kernel.org/all/20240523035952.59724-1-topofeverest8848@gmail.com/
> 
>   drivers/staging/rtl8192e/rtllib_softmac.c | 8 ++++----
>   1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c b/drivers/staging/rtl8192e/rtllib_softmac.c
> index 97fdca828da7..0fc97c868f81 100644
> --- a/drivers/staging/rtl8192e/rtllib_softmac.c
> +++ b/drivers/staging/rtl8192e/rtllib_softmac.c
> @@ -421,7 +421,7 @@ static void rtllib_softmac_scan_syncro(struct rtllib_device *ieee)
>   		 *    So we switch to MAC80211_LINKED_SCANNING to remember
>   		 *    that we are still logically linked (not interested in
>   		 *    new network events, despite for updating the net list,
> -		 *    but we are temporarly 'unlinked' as the driver shall
> +		 *    but we are temporarily 'unlinked' as the driver shall
>   		 *    not filter RX frames and the channel is changing.
>   		 * So the only situation in which are interested is to check
>   		 * if the state become LINKED because of the #1 situation
> @@ -934,7 +934,7 @@ static void rtllib_associate_abort(struct rtllib_device *ieee)
>   
>   	ieee->associate_seq++;
>   
> -	/* don't scan, and avoid to have the RX path possibily
> +	/* don't scan, and avoid to have the RX path possibly
>   	 * try again to associate. Even do not react to AUTH or
>   	 * ASSOC response. Just wait for the retry wq to be scheduled.
>   	 * Here we will check if there are good nets to associate
> @@ -1359,7 +1359,7 @@ static short rtllib_sta_ps_sleep(struct rtllib_device *ieee, u64 *time)
>   		return 0;
>   	timeout = ieee->current_network.beacon_interval;
>   	ieee->current_network.dtim_data = RTLLIB_DTIM_INVALID;
> -	/* there's no need to nofity AP that I find you buffered
> +	/* there's no need to notify AP that I find you buffered
>   	 * with broadcast packet
>   	 */
>   	if (dtim & (RTLLIB_DTIM_UCAST & ieee->ps))
> @@ -1806,7 +1806,7 @@ void rtllib_softmac_xmit(struct rtllib_txb *txb, struct rtllib_device *ieee)
>   
>   	spin_lock_irqsave(&ieee->lock, flags);
>   
> -	/* called with 2nd parm 0, no tx mgmt lock required */
> +	/* called with 2nd param 0, no tx mgmt lock required */
>   	rtllib_sta_wakeup(ieee, 0);
>   
>   	/* update the tx status */

Reviewed-by: Philipp Hortmann <philipp.g.hortmann@...il.com>