'if (true) { ... }' will always evaluate to true. Remove it and
save a few tabs for somewhere else.
Signed-off-by: Bryan Brattlof <[email protected]>
---
drivers/staging/rtl8723bs/core/rtw_ap.c | 159 ++++++++++++------------
1 file changed, 78 insertions(+), 81 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c b/drivers/staging/rtl8723bs/core/rtw_ap.c
index 9df4476b2e2d..98b1bec67999 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ap.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ap.c
@@ -59,112 +59,109 @@ static void update_BCNTIM(struct adapter *padapter)
unsigned char *pie = pnetwork_mlmeext->IEs;
/* update TIM IE */
- /* if (pstapriv->tim_bitmap) */
- if (true) {
- u8 *p, *dst_ie, *premainder_ie = NULL, *pbackup_remainder_ie = NULL;
- __le16 tim_bitmap_le;
- uint offset, tmp_len, tim_ielen, tim_ie_offset, remainder_ielen;
-
- tim_bitmap_le = cpu_to_le16(pstapriv->tim_bitmap);
-
- p = rtw_get_ie(pie + _FIXED_IE_LENGTH_,
- WLAN_EID_TIM,
- &tim_ielen,
- pnetwork_mlmeext->IELength - _FIXED_IE_LENGTH_
- );
- if (p && tim_ielen > 0) {
- tim_ielen += 2;
+ u8 *p, *dst_ie, *premainder_ie = NULL, *pbackup_remainder_ie = NULL;
+ __le16 tim_bitmap_le;
+ uint offset, tmp_len, tim_ielen, tim_ie_offset, remainder_ielen;
- premainder_ie = p + tim_ielen;
+ tim_bitmap_le = cpu_to_le16(pstapriv->tim_bitmap);
- tim_ie_offset = (signed int)(p - pie);
+ p = rtw_get_ie(pie + _FIXED_IE_LENGTH_,
+ WLAN_EID_TIM,
+ &tim_ielen,
+ pnetwork_mlmeext->IELength - _FIXED_IE_LENGTH_
+ );
+ if (p && tim_ielen > 0) {
+ tim_ielen += 2;
- remainder_ielen = pnetwork_mlmeext->IELength - tim_ie_offset - tim_ielen;
+ premainder_ie = p + tim_ielen;
- /* append TIM IE from dst_ie offset */
- dst_ie = p;
- } else {
- tim_ielen = 0;
+ tim_ie_offset = (signed int)(p - pie);
- /* calculate head_len */
- offset = _FIXED_IE_LENGTH_;
+ remainder_ielen = pnetwork_mlmeext->IELength - tim_ie_offset - tim_ielen;
- /* get ssid_ie len */
- p = rtw_get_ie(pie + _BEACON_IE_OFFSET_,
- WLAN_EID_SSID,
- &tmp_len,
- (pnetwork_mlmeext->IELength - _BEACON_IE_OFFSET_)
- );
- if (p)
- offset += tmp_len + 2;
+ /* append TIM IE from dst_ie offset */
+ dst_ie = p;
+ } else {
+ tim_ielen = 0;
- /* get supported rates len */
- p = rtw_get_ie(pie + _BEACON_IE_OFFSET_,
- WLAN_EID_SUPP_RATES, &tmp_len,
- (pnetwork_mlmeext->IELength - _BEACON_IE_OFFSET_)
- );
- if (p)
- offset += tmp_len + 2;
+ /* calculate head_len */
+ offset = _FIXED_IE_LENGTH_;
- /* DS Parameter Set IE, len =3 */
- offset += 3;
+ /* get ssid_ie len */
+ p = rtw_get_ie(pie + _BEACON_IE_OFFSET_,
+ WLAN_EID_SSID,
+ &tmp_len,
+ (pnetwork_mlmeext->IELength - _BEACON_IE_OFFSET_)
+ );
+ if (p)
+ offset += tmp_len + 2;
- premainder_ie = pie + offset;
+ /* get supported rates len */
+ p = rtw_get_ie(pie + _BEACON_IE_OFFSET_,
+ WLAN_EID_SUPP_RATES, &tmp_len,
+ (pnetwork_mlmeext->IELength - _BEACON_IE_OFFSET_)
+ );
+ if (p)
+ offset += tmp_len + 2;
- remainder_ielen = pnetwork_mlmeext->IELength - offset - tim_ielen;
+ /* DS Parameter Set IE, len =3 */
+ offset += 3;
- /* append TIM IE from offset */
- dst_ie = pie + offset;
- }
+ premainder_ie = pie + offset;
- if (remainder_ielen > 0) {
- pbackup_remainder_ie = rtw_malloc(remainder_ielen);
- if (pbackup_remainder_ie && premainder_ie)
- memcpy(pbackup_remainder_ie, premainder_ie, remainder_ielen);
- }
+ remainder_ielen = pnetwork_mlmeext->IELength - offset - tim_ielen;
- *dst_ie++ = WLAN_EID_TIM;
+ /* append TIM IE from offset */
+ dst_ie = pie + offset;
+ }
- if ((pstapriv->tim_bitmap & 0xff00) && (pstapriv->tim_bitmap & 0x00fe))
- tim_ielen = 5;
- else
- tim_ielen = 4;
+ if (remainder_ielen > 0) {
+ pbackup_remainder_ie = rtw_malloc(remainder_ielen);
+ if (pbackup_remainder_ie && premainder_ie)
+ memcpy(pbackup_remainder_ie, premainder_ie, remainder_ielen);
+ }
- *dst_ie++ = tim_ielen;
+ *dst_ie++ = WLAN_EID_TIM;
- *dst_ie++ = 0;/* DTIM count */
- *dst_ie++ = 1;/* DTIM period */
+ if ((pstapriv->tim_bitmap & 0xff00) && (pstapriv->tim_bitmap & 0x00fe))
+ tim_ielen = 5;
+ else
+ tim_ielen = 4;
- if (pstapriv->tim_bitmap & BIT(0))/* for bc/mc frames */
- *dst_ie++ = BIT(0);/* bitmap ctrl */
- else
- *dst_ie++ = 0;
+ *dst_ie++ = tim_ielen;
- if (tim_ielen == 4) {
- __le16 pvb;
+ *dst_ie++ = 0;/* DTIM count */
+ *dst_ie++ = 1;/* DTIM period */
- if (pstapriv->tim_bitmap & 0xff00)
- pvb = cpu_to_le16(pstapriv->tim_bitmap >> 8);
- else
- pvb = tim_bitmap_le;
+ if (pstapriv->tim_bitmap & BIT(0))/* for bc/mc frames */
+ *dst_ie++ = BIT(0);/* bitmap ctrl */
+ else
+ *dst_ie++ = 0;
- *dst_ie++ = le16_to_cpu(pvb);
+ if (tim_ielen == 4) {
+ __le16 pvb;
- } else if (tim_ielen == 5) {
- memcpy(dst_ie, &tim_bitmap_le, 2);
- dst_ie += 2;
- }
+ if (pstapriv->tim_bitmap & 0xff00)
+ pvb = cpu_to_le16(pstapriv->tim_bitmap >> 8);
+ else
+ pvb = tim_bitmap_le;
- /* copy remainder IE */
- if (pbackup_remainder_ie) {
- memcpy(dst_ie, pbackup_remainder_ie, remainder_ielen);
+ *dst_ie++ = le16_to_cpu(pvb);
- kfree(pbackup_remainder_ie);
- }
+ } else if (tim_ielen == 5) {
+ memcpy(dst_ie, &tim_bitmap_le, 2);
+ dst_ie += 2;
+ }
+
+ /* copy remainder IE */
+ if (pbackup_remainder_ie) {
+ memcpy(dst_ie, pbackup_remainder_ie, remainder_ielen);
- offset = (uint)(dst_ie - pie);
- pnetwork_mlmeext->IELength = offset + remainder_ielen;
+ kfree(pbackup_remainder_ie);
}
+
+ offset = (uint)(dst_ie - pie);
+ pnetwork_mlmeext->IELength = offset + remainder_ielen;
}
u8 chk_sta_is_alive(struct sta_info *psta);
--
2.27.0
Hi Bryan,
On Tue, May 18, 2021 at 02:45:19PM +0000, Bryan Brattlof wrote:
> 'if (true) { ... }' will always evaluate to true. Remove it and
> save a few tabs for somewhere else.
>
> Signed-off-by: Bryan Brattlof <[email protected]>
> ---
> drivers/staging/rtl8723bs/core/rtw_ap.c | 159 ++++++++++++------------
> 1 file changed, 78 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c b/drivers/staging/rtl8723bs/core/rtw_ap.c
> index 9df4476b2e2d..98b1bec67999 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_ap.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_ap.c
> @@ -59,112 +59,109 @@ static void update_BCNTIM(struct adapter *padapter)
>
I was wondering why are you using the first patch of a nine patch
series as a 'cover letter' of an eight patch patchset.
In other words, why putting the In-Reply-To field of all patches subsequent
to the first one ponting to the first patch itself as a cover letter,
is it a recommened practice?
thank you,
fabio
On Wed, May 19, 2021 at 04:25:29PM +0300, Dan Carpenter wrote:
> On Wed, May 19, 2021 at 02:44:38PM +0200, Fabio Aiuto wrote:
> > Hi Bryan,
> >
> > On Tue, May 18, 2021 at 02:45:19PM +0000, Bryan Brattlof wrote:
> > > 'if (true) { ... }' will always evaluate to true. Remove it and
> > > save a few tabs for somewhere else.
> > >
> > > Signed-off-by: Bryan Brattlof <[email protected]>
> > > ---
> > > drivers/staging/rtl8723bs/core/rtw_ap.c | 159 ++++++++++++------------
> > > 1 file changed, 78 insertions(+), 81 deletions(-)
> > >
> > > diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c b/drivers/staging/rtl8723bs/core/rtw_ap.c
> > > index 9df4476b2e2d..98b1bec67999 100644
> > > --- a/drivers/staging/rtl8723bs/core/rtw_ap.c
> > > +++ b/drivers/staging/rtl8723bs/core/rtw_ap.c
> > > @@ -59,112 +59,109 @@ static void update_BCNTIM(struct adapter *padapter)
> > >
> >
> > I was wondering why are you using the first patch of a nine patch
> > series as a 'cover letter' of an eight patch patchset.
> >
> > In other words, why putting the In-Reply-To field of all patches subsequent
> > to the first one ponting to the first patch itself as a cover letter,
> > is it a recommened practice?
>
> It's fine. It doesn't matter. It's not recommended. I do it normally
> if I have to send patches in certain order. I never write cover letters
> because my patches are all independent bug fixes and not new features.
Wait, this was just a mistake I think. It's not a cover letter. It's
not part of the eight patch series but it probably was intended to be as
you suggest.
The patches are basically okay. Greg applies patches in the order that
he recieves them so it should all apply fine. And if it doesn't Greg
will just ask for a resend. No big deal.
regards,
dan carpenter
On Wed, May 19, 2021 at 02:44:38PM +0200, Fabio Aiuto wrote:
> Hi Bryan,
>
> On Tue, May 18, 2021 at 02:45:19PM +0000, Bryan Brattlof wrote:
> > 'if (true) { ... }' will always evaluate to true. Remove it and
> > save a few tabs for somewhere else.
> >
> > Signed-off-by: Bryan Brattlof <[email protected]>
> > ---
> > drivers/staging/rtl8723bs/core/rtw_ap.c | 159 ++++++++++++------------
> > 1 file changed, 78 insertions(+), 81 deletions(-)
> >
> > diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c b/drivers/staging/rtl8723bs/core/rtw_ap.c
> > index 9df4476b2e2d..98b1bec67999 100644
> > --- a/drivers/staging/rtl8723bs/core/rtw_ap.c
> > +++ b/drivers/staging/rtl8723bs/core/rtw_ap.c
> > @@ -59,112 +59,109 @@ static void update_BCNTIM(struct adapter *padapter)
> >
>
> I was wondering why are you using the first patch of a nine patch
> series as a 'cover letter' of an eight patch patchset.
>
> In other words, why putting the In-Reply-To field of all patches subsequent
> to the first one ponting to the first patch itself as a cover letter,
> is it a recommened practice?
It's fine. It doesn't matter. It's not recommended. I do it normally
if I have to send patches in certain order. I never write cover letters
because my patches are all independent bug fixes and not new features.
regards,
dan carpenter
On Wed, May 19, 2021 at 04:31:08PM +0300, Dan Carpenter wrote:
> On Wed, May 19, 2021 at 04:25:29PM +0300, Dan Carpenter wrote:
> > On Wed, May 19, 2021 at 02:44:38PM +0200, Fabio Aiuto wrote:
> > > Hi Bryan,
> > >
> > > On Tue, May 18, 2021 at 02:45:19PM +0000, Bryan Brattlof wrote:
> > > > 'if (true) { ... }' will always evaluate to true. Remove it and
> > > > save a few tabs for somewhere else.
> > > >
> > > > Signed-off-by: Bryan Brattlof <[email protected]>
> > > > ---
> > > > drivers/staging/rtl8723bs/core/rtw_ap.c | 159 ++++++++++++------------
> > > > 1 file changed, 78 insertions(+), 81 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c b/drivers/staging/rtl8723bs/core/rtw_ap.c
> > > > index 9df4476b2e2d..98b1bec67999 100644
> > > > --- a/drivers/staging/rtl8723bs/core/rtw_ap.c
> > > > +++ b/drivers/staging/rtl8723bs/core/rtw_ap.c
> > > > @@ -59,112 +59,109 @@ static void update_BCNTIM(struct adapter *padapter)
> > > >
> > >
> > > I was wondering why are you using the first patch of a nine patch
> > > series as a 'cover letter' of an eight patch patchset.
> > >
> > > In other words, why putting the In-Reply-To field of all patches subsequent
> > > to the first one ponting to the first patch itself as a cover letter,
> > > is it a recommened practice?
> >
> > It's fine. It doesn't matter. It's not recommended. I do it normally
> > if I have to send patches in certain order. I never write cover letters
> > because my patches are all independent bug fixes and not new features.
>
> Wait, this was just a mistake I think. It's not a cover letter. It's
> not part of the eight patch series but it probably was intended to be as
> you suggest.
>
> The patches are basically okay. Greg applies patches in the order that
> he recieves them so it should all apply fine. And if it doesn't Greg
> will just ask for a resend. No big deal.
>
Yep this is due to my inexperience with git over email :)
I wanted to send the patches in order to avoid conflicts when applying
because they deal with the same area of the file, but didn't feel they
deserved a cover letter to remove some unused definitions.
I was using 'git-series' to manage the patch set which generated an
empty cover letter that I didn't send out. I should have known that
In-Reply-To would have been set for all the remaining emails.
Going forward I'll probably just stick with 'git-send-email' and write a
proper cover letter, especially while I'm still getting used to sending
patches over email. :)
--
~Bryan
> regards,
> dan carpenter
>