From: Joash Naidoo <joash.n09@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Larry.Finger@lwfinger.net, phil@philpotter.co.uk,
dan.carpenter@oracle.com, straube.linux@gmail.com,
paskripkin@gmail.com, linux-staging@lists.linux.dev
Subject: Re: [PATCH v4] staging: r8188eu: fix too many leading tabs
Date: Wed, 28 Sep 2022 18:20:28 +0200 [thread overview]
Message-ID: <87r0zva18v.fsf@gmail.com> (raw)
In-Reply-To: <YzQALwjz5VT0uCyB@kroah.com>
Greg KH <gregkh@linuxfoundation.org> writes:
> On Wed, Sep 28, 2022 at 09:53:24AM +0200, Joash Naidoo wrote:
>> Coding style fix. Fix too many leading tabs and line length.
>>
>> Signed-off-by: Joash Naidoo <joash.n09@gmail.com>
>> ---
>> Changes in V4:
>> - Fix compiler warning introduced: mixing declarations and
>> code
>> Changes in v3:
>> - Fix flipped condition mistake
>> - move skb NULL check before dereferencing it
>> Changes in v2:
>> - Flip additional nested if conditions and don't reverse
>> the last if statement
>> - Move declarations to start of function
>> - Separate converting __constant_htons to htons to another
>> patch
>> ---
>> drivers/staging/r8188eu/core/rtw_br_ext.c | 75
>> +++++++++++++----------
>> 1 file changed, 42 insertions(+), 33 deletions(-)
>>
>> diff --git a/drivers/staging/r8188eu/core/rtw_br_ext.c
>> b/drivers/staging/r8188eu/core/rtw_br_ext.c
>> index bca20fe5c..d4bcec152 100644
>> --- a/drivers/staging/r8188eu/core/rtw_br_ext.c
>> +++ b/drivers/staging/r8188eu/core/rtw_br_ext.c
>> @@ -601,42 +601,51 @@ struct dhcpMessage {
>>
>> void dhcp_flag_bcast(struct adapter *priv, struct sk_buff
>> *skb)
>> {
>> + __be16 protocol;
>> + struct iphdr *iph;
>> + struct udphdr *udph;
>> + struct dhcpMessage *dhcph;
>> + u32 cookie;
>> +
>> if (!skb)
>> return;
>>
>> - if (!priv->ethBrExtInfo.dhcp_bcst_disable) {
>> - __be16 protocol = *((__be16 *)(skb->data + 2 *
>> ETH_ALEN));
>> -
>> - if (protocol == __constant_htons(ETH_P_IP)) { /* IP
>> */
>> - struct iphdr *iph = (struct iphdr *)(skb->data +
>> ETH_HLEN);
>> -
>> - if (iph->protocol == IPPROTO_UDP) { /* UDP */
>> - struct udphdr *udph = (struct udphdr
>> *)((size_t)iph + (iph->ihl << 2));
>> -
>> - if ((udph->source ==
>> __constant_htons(CLIENT_PORT)) &&
>> - (udph->dest ==
>> __constant_htons(SERVER_PORT))) { /* DHCP request */
>> - struct dhcpMessage *dhcph =
>> - (struct dhcpMessage *)((size_t)udph +
>> sizeof(struct udphdr));
>> - u32 cookie =
>> be32_to_cpu((__be32)dhcph->cookie);
>> -
>> - if (cookie == DHCP_MAGIC) { /* match
>> magic word */
>> - if (!(dhcph->flags &
>> htons(BROADCAST_FLAG))) {
>> - /* if not broadcast */
>> - register int sum = 0;
>> -
>> - /* or BROADCAST flag */
>> - dhcph->flags |=
>> htons(BROADCAST_FLAG);
>> - /* recalculate checksum */
>> - sum = ~(udph->check) & 0xffff;
>> - sum += be16_to_cpu(dhcph->flags);
>> - while (sum >> 16)
>> - sum = (sum & 0xffff) + (sum >>
>> 16);
>> - udph->check = ~sum;
>> - }
>> - }
>> - }
>> - }
>> - }
>> + protocol = *((__be16 *)(skb->data + 2 * ETH_ALEN));
>> + iph = (struct iphdr *)(skb->data + ETH_HLEN);
>> + udph = (struct udphdr *)((size_t)iph + (iph->ihl << 2));
>> + /* DHCP request */
>> + dhcph =
>> + (struct dhcpMessage *)((size_t)udph + sizeof(struct
>> udphdr));
>
> Very odd formatting, why split that line?
>
>> + cookie = be32_to_cpu((__be32)dhcph->cookie);
>> +
>> + if (priv->ethBrExtInfo.dhcp_bcst_disable)
>> + return;
>
> Why are you not checking for this _before_ all of the above
> assignments?
>
>
>
>> +
>> + if (protocol != htons(ETH_P_IP)) /* IP */
>> + return;
>
> You can check for this right after assigning the protocol
> variable.
>
>> +
>> + if (iph->protocol != IPPROTO_UDP) /* UDP */
>> + return;
>
> You can check for this right after setting iph.
Thank you for your time and feedback. I agree with your comments.
My rationale for having the way it is stems from my inclination to
stuck to the original code as close as possible. In hindsight, the
ordering could be better. I will submit another revision.
> But also, shouldn't you just be using the ip_hdr() call instead
> of doing
> the crazy cast above?
I would need to investigate and test first before commenting. If a
change had to be made, I believe it will go in a separate patch?
> thanks,
>
> greg k-h
next prev parent reply other threads:[~2022-09-28 17:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-28 7:53 [PATCH v4] staging: r8188eu: fix too many leading tabs Joash Naidoo
2022-09-28 8:05 ` Greg KH
2022-09-28 16:20 ` Joash Naidoo [this message]
2022-09-28 17:24 ` Greg KH
2022-10-01 17:48 ` Joash Naidoo
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=87r0zva18v.fsf@gmail.com \
--to=joash.n09@gmail.com \
--cc=Larry.Finger@lwfinger.net \
--cc=dan.carpenter@oracle.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-staging@lists.linux.dev \
--cc=paskripkin@gmail.com \
--cc=phil@philpotter.co.uk \
--cc=straube.linux@gmail.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.