Re: [PATCH 03/12] staging:rtl8192u: Remove blank lines before '}' and after '{' characters
On Mon, Jul 09, 2018 at 10:29:54AM +0100, John Whitmore wrote: > On Sun, Jul 08, 2018 at 05:38:11PM +0200, Greg KH wrote: > > On Sat, Jul 07, 2018 at 03:55:04PM +0100, John Whitmore wrote: > > > Coding style change to simply remove the unrequired spaces before a > > > closing > > > brace or before an opening brace. > > > > That would be good, but that's not what this patch does :( > > > > It removes lines, not spaces, as the subject line said. You also fix up > > an indentation as well. > > > > thanks, > > > > greg k-h > > Just for clarification, before I assume something and make a mistake, I'm > wondering about this patch set. I got auto notification to say that patches 1, > 2, 4, & 6 had been accepted and merged with staging-next. And I got this email > to explain why patch number 3 wasn't up to scratch. > > But that leaves 5, 7, 8, 9, 10, 11 & 12. I'm assuming that they didn't apply > and I that I can resubmit them with a fixed up patch number 3. That seems > logical to me so I'll work on that basis for the moment. Thought I'd better > check, before I confuse people, with an erroneous assumption. Yes, that is correct. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 03/12] staging:rtl8192u: Remove blank lines before '}' and after '{' characters
On Sun, Jul 08, 2018 at 05:38:11PM +0200, Greg KH wrote: > On Sat, Jul 07, 2018 at 03:55:04PM +0100, John Whitmore wrote: > > Coding style change to simply remove the unrequired spaces before a closing > > brace or before an opening brace. > > That would be good, but that's not what this patch does :( > > It removes lines, not spaces, as the subject line said. You also fix up > an indentation as well. > > thanks, > > greg k-h Just for clarification, before I assume something and make a mistake, I'm wondering about this patch set. I got auto notification to say that patches 1, 2, 4, & 6 had been accepted and merged with staging-next. And I got this email to explain why patch number 3 wasn't up to scratch. But that leaves 5, 7, 8, 9, 10, 11 & 12. I'm assuming that they didn't apply and I that I can resubmit them with a fixed up patch number 3. That seems logical to me so I'll work on that basis for the moment. Thought I'd better check, before I confuse people, with an erroneous assumption. John Whitmore ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 03/12] staging:rtl8192u: Remove blank lines before '}' and after '{' characters
On Sun, Jul 08, 2018 at 05:38:11PM +0200, Greg KH wrote: > On Sat, Jul 07, 2018 at 03:55:04PM +0100, John Whitmore wrote: > > Coding style change to simply remove the unrequired spaces before a closing > > brace or before an opening brace. > > That would be good, but that's not what this patch does :( > > It removes lines, not spaces, as the subject line said. You also fix up > an indentation as well. > > thanks, > > greg k-h Oops sorry. I'll fix it up in another pass. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 03/12] staging:rtl8192u: Remove blank lines before '}' and after '{' characters
On Sat, Jul 07, 2018 at 03:55:04PM +0100, John Whitmore wrote: > Coding style change to simply remove the unrequired spaces before a closing > brace or before an opening brace. That would be good, but that's not what this patch does :( It removes lines, not spaces, as the subject line said. You also fix up an indentation as well. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 03/12] staging:rtl8192u: Remove blank lines before '}' and after '{' characters
Coding style change to simply remove the unrequired spaces before a closing
brace or before an opening brace.
Signed-off-by: John Whitmore
---
.../rtl8192u/ieee80211/ieee80211_softmac.c| 44 ++-
1 file changed, 13 insertions(+), 31 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
index 1f6d0fb3c5bd..e046cc49f3d7 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
@@ -77,8 +77,7 @@ static void ieee80211_MFIE_Grate(struct ieee80211_device
*ieee, u8 **tag_p)
{
u8 *tag = *tag_p;
- if (ieee->modulation & IEEE80211_OFDM_MODULATION) {
-
+ if (ieee->modulation & IEEE80211_OFDM_MODULATION) {
*tag++ = MFIE_TYPE_RATES_EX;
*tag++ = 8;
*tag++ = IEEE80211_BASIC_RATE_MASK | IEEE80211_OFDM_RATE_6MB;
@@ -89,7 +88,6 @@ static void ieee80211_MFIE_Grate(struct ieee80211_device
*ieee, u8 **tag_p)
*tag++ = IEEE80211_BASIC_RATE_MASK | IEEE80211_OFDM_RATE_36MB;
*tag++ = IEEE80211_BASIC_RATE_MASK | IEEE80211_OFDM_RATE_48MB;
*tag++ = IEEE80211_BASIC_RATE_MASK | IEEE80211_OFDM_RATE_54MB;
-
}
/* We may add an option for custom rates that specific HW might support
*/
@@ -301,7 +299,6 @@ softmac_ps_mgmt_xmit(struct sk_buff *skb, struct
ieee80211_device *ieee)
netif_trans_update(ieee->dev);
ieee->softmac_data_hard_start_xmit(skb, ieee->dev,
ieee->basic_rate);
}else{
-
header->seq_ctl = cpu_to_le16(ieee->seq_ctrl[0] << 4);
if (ieee->seq_ctrl[0] == 0xFFF)
@@ -1473,7 +1470,6 @@ void ieee80211_softmac_check_all_nets(struct
ieee80211_device *ieee)
spin_lock_irqsave(>lock, flags);
list_for_each_entry(target, >network_list, list) {
-
/* if the state become different that NOLINK means
* we had found what we are searching for
*/
@@ -1572,8 +1568,7 @@ static int assoc_rq_parse(struct sk_buff *skb, u8 *dest)
struct ieee80211_assoc_request_frame *a;
if (skb->len < (sizeof(struct ieee80211_assoc_request_frame) -
- sizeof(struct ieee80211_info_element))) {
-
+ sizeof(struct ieee80211_info_element))) {
IEEE80211_DEBUG_MGMT("invalid len in auth request:%d \n",
skb->len);
return -1;
}
@@ -1640,7 +1635,6 @@ ieee80211_rx_auth_rq(struct ieee80211_device *ieee,
struct sk_buff *skb)
ieee80211_resp_to_auth(ieee, status, dest);
}
//DMESG("Dest is "MACSTR, MAC2STR(dest));
-
}
static inline void
@@ -1665,7 +1659,6 @@ static void ieee80211_sta_ps_send_null_frame(struct
ieee80211_device *ieee,
if (buf)
softmac_ps_mgmt_xmit(buf, ieee);
-
}
/* EXPORT_SYMBOL(ieee80211_sta_ps_send_null_frame); */
@@ -1726,10 +1719,9 @@ static inline void ieee80211_sta_ps(struct
ieee80211_device *ieee)
spin_lock_irqsave(>lock, flags);
if ((ieee->ps == IEEE80211_PS_DISABLED ||
- ieee->iw_mode != IW_MODE_INFRA ||
- ieee->state != IEEE80211_LINKED)){
-
- // #warning CHECK_LOCK_HERE
+ieee->iw_mode != IW_MODE_INFRA ||
+ieee->state != IEEE80211_LINKED)){
+ // #warning CHECK_LOCK_HERE
spin_lock_irqsave(>mgmt_tx_lock, flags2);
ieee80211_sta_wakeup(ieee, 1);
@@ -1999,8 +1991,7 @@ ieee80211_rx_frame_softmac(struct ieee80211_device *ieee,
struct sk_buff *skb,
case IEEE80211_STYPE_AUTH:
if (ieee->softmac_features & IEEE_SOFTMAC_ASSOCIATE) {
if (ieee->state == IEEE80211_ASSOCIATING_AUTHENTICATING
- && ieee->iw_mode == IW_MODE_INFRA) {
-
+ && ieee->iw_mode == IW_MODE_INFRA) {
IEEE80211_DEBUG_MGMT("Received auth response");
ieee80211_check_auth_response(ieee, skb);
} else if (ieee->iw_mode == IW_MODE_MASTER) {
@@ -2011,9 +2002,9 @@ ieee80211_rx_frame_softmac(struct ieee80211_device *ieee,
struct sk_buff *skb,
case IEEE80211_STYPE_PROBE_REQ:
if ((ieee->softmac_features & IEEE_SOFTMAC_PROBERS) &&
- ((ieee->iw_mode == IW_MODE_ADHOC ||
- ieee->iw_mode == IW_MODE_MASTER) &&
- ieee->state == IEEE80211_LINKED)){
+ ((ieee->iw_mode == IW_MODE_ADHOC ||
+ ieee->iw_mode == IW_MODE_MASTER) &&
+ieee->state == IEEE80211_LINKED)){
ieee80211_rx_probe_rq(ieee, skb);
}
break;
@@ -2024,9 +2015,8 @@ ieee80211_rx_frame_softmac(struct ieee80211_device *ieee,
