linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: <Ajay.Kathat@microchip.com>
Cc: <linux-wireless@vger.kernel.org>, <gregkh@linuxfoundation.org>,
	<johannes@sipsolutions.net>, <Adham.Abozaeid@microchip.com>,
	<Venkateswara.Kaja@microchip.com>, <Nicolas.Ferre@microchip.com>,
	<Claudiu.Beznea@microchip.com>, <Ajay.Kathat@microchip.com>
Subject: Re: [PATCH v2 01/16] wilc1000: add wilc_hif.h
Date: Wed, 23 Oct 2019 10:03:12 +0000 (UTC)	[thread overview]
Message-ID: <20191023100313.52B3F606CF@smtp.codeaurora.org> (raw)
In-Reply-To: <1562896697-8002-2-git-send-email-ajay.kathat@microchip.com>

<Ajay.Kathat@microchip.com> wrote:

> From: Ajay Singh <ajay.kathat@microchip.com>
> 
> Moved '/driver/staging/wilc1000/wilc_hif.h' to
> '/driver/net/wireless/mirochip/wilc1000/wilc_hif.h'.
> 
> Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>

(My patchwork script doesn't support cover letters, yet, so I need to reply to
the first patch)

I was supposed to do a quick 15 minute review, but I got overboard and used
over an hour for this :) But anyway, below are my comments. Mostly looks good
but some work still to do.

+#ifndef HOST_INT_H

Add WILC prefix?

+struct assoc_resp {
+	__le16 capab_info;
+	__le16 status_code;
+	__le16 aid;
+} __packed;

use struct ieee80211_mgmt?

+   	   //extract RSN capabilities

No C++ style comments, please.

+  wid_list[1].val = (s8 *)&auth_type;

A little bit too much of casting, like in this example, for my taste
but I guess it's not that a bit of problem. Didn't investigate why
this particular cast was need, but I think Johannes already commented
how odd this wid_list looks like. And why sometimes it's (s8 *) and
others (u8 *)?

+      case 'S':

Isn't a proper define much more readable and as a bonus it would
document the meaning of this value? For example, it could
WILC_RESPONSE_TYPE_SCAN or whatever it means. Oh, and the same for
'R', 'I' and others.

do {
    ....
} while (1);

I see quite a lot of these unconditonal loops in the driver:

wilc_netdev.c:157:   while (1) {
wilc_wlan.c:532:     } while (1);
wilc_wlan.c:602:     } while (1);
wilc_wlan.c:730:     } while (1);
wilc_wlan.c:753:     } while (1);
wilc_wlan.c:1002:    } while (1);
wilc_wlan.c:1009:    } while (1);
wilc_wlan_cfg.c:151:   	     } while (1);
wilc_wlan_cfg.c:167:	       	     } while (1);
wilc_wlan_cfg.c:183:		       	     } while (1);
wilc_wlan_cfg.c:198:			       	     } while (1);
wilc_wlan_cfg.c:230:				       } while (1);
wilc_wlan_cfg.c:303:				       	 } while (1);
wilc_wlan_cfg.c:315:					   } while
(1);
wilc_wlan_cfg.c:327:		} while (1);
wilc_wlan_cfg.c:346:		  } while (1);

This is not recommended in kernel code because a small bug can cause a
never ending loop in kernel. Put some kind of limit to the loop,
either counter or time based, for example:

count = 0;

do {
    ....
} while (count++ < 100);

Or even some of the while loops could be replaced with for loop, like
the one in wilc_wlan_parse_info_frame().

+   u8 type = (id >> 12) & 0xf;

No magic values, please. My recommendation is to use GENMASK() and
friends, maybe u16_get_bits()?

I also see identical magic values elsewhere, which should be a strong
indication that this needs to be implemented with a proper define.

+int wilc_wlan_cfg_get_wid(u8 *frame, u32 offset, u16 id)
+{
+	u8 *buf;
+
+	if ((offset + 2) >= WILC_MAX_CFG_FRAME_SIZE)
+	   return 0;
+
+	buf = &frame[offset];
+
+	buf[0] = (u8)id;
+	buf[1] = (u8)(id >> 8);

In general a struct is MUCH better than manually playing with bytes
using 'u8 buf[]', but I think Johannes told you already that. Here you
could just have a simple '__le16 id' and you could assign to it with
cpu_to_le16(id), a lot cleaner than what's above.

+		  /*call host interface info parse as well*/

A space after '/*' and before '*/'. Have you run checkpatch? It should
catch these simple style issues? And you can run with --file directly
on the source tree. Not of course all checkpatch warnings need to be
fixed, but obvious ones like this for sure.

+#define GET_PKT_OFFSET(a) (((a) >> 22) & 0x1ff)

GENMASK() & co

+/*Parameters needed for host interface for  remaining on channel*/

checkpatch

+	struct wilc_vif *vif[WILC_NUM_CONCURRENT_IFC];
+	/*protect vif list*/
+	struct mutex vif_mutex;

I would add a newline before the comment, that would make wilc_wfi_netdevice.h
a lot more readable. But that's a style issue and up to you.

+  if (ch_list_attr_idx) {
+     u8 limit = ch_list_attr_idx + 3 + buf[ch_list_attr_idx + 1];
+
+		for (i = ch_list_attr_idx + 3; i < limit; i++) {
+		       if (buf[i] == 0x51) {
+		       	  	     for (j = i + 2; j < ((i + 2) +
buf[i + 1]); j++)
+			buf[j] = sta_ch;
+					break;
+							}
+								}
+								}

No magic values like 0x51, please. And I think this loop needs a
comment what's happening. But I suspect that if you had proper structs
(and not this ugly buf[] stuff) the code would be self-explanatory and
there would be no need for comments.

+  if (op_ch_attr_idx) {
+     buf[op_ch_attr_idx + 6] = 0x51;
+     			 buf[op_ch_attr_idx + 7] = sta_ch;
+			 }

Ditto. And even more of that in wilc_wfi_cfgoperations.c.

+static struct net_device *get_if_handler(struct wilc *wilc, u8
*mac_header)
+{
+	u8 *bssid, *bssid1;
+	int i = 0;
+	struct net_device *ndev = NULL;
+
+	bssid = mac_header + 10;
+	bssid1 = mac_header + 4;

And here a proper struct for mac_header would be so much cleaner.

+static u8 crc7(u8 crc, const u8 *buffer, u32 len)
+{
+	while (len--)
+	      crc = crc7_byte(crc, *buffer++);
+	      return crc;
+}

What's wrong with <linux/crc7.h>? Why reinvent the wheel?

I see so much this u8 buf[] stuff that I'll stop commenting about it
now. But, for example, spi_cmd_complete() would be a lot cleaner with
proper structs and some refactoring (one function per command or
something like that).

+	  if (addr < 0x30) {

Proper defines for magic values, please. This was even used multiple
times.

+	wilc->hif_func->hif_read_reg(wilc, 0xf0, &reg);
+
+	wilc->hif_func->hif_write_reg(wilc, 0xf0, reg & ~BIT(0));
+	wilc->hif_func->hif_write_reg(wilc, 0xfa, 0);

Magic values. I'll also stop commenting about magic values, I think you got
the point already :)

+#ifdef WILC_DISABLE_PMU
+#else
+	reg |= WILC_HAVE_USE_PMU;
+#endif
+
+#ifdef WILC_SLEEP_CLK_SRC_XO
+	reg |= WILC_HAVE_SLEEP_CLK_SRC_XO;
+#elif defined WILC_SLEEP_CLK_SRC_RTC
+      reg |= WILC_HAVE_SLEEP_CLK_SRC_RTC;
+#endif
+
+#ifdef WILC_EXT_PA_INV_TX_RX
+	reg |= WILC_HAVE_EXT_PA_INV_TX_RX;
+#endif
+	reg |= WILC_HAVE_USE_IRQ_AS_HOST_WAKE;
+	reg |= WILC_HAVE_LEGACY_RF_SETTINGS;
+#ifdef XTAL_24
+	reg |= WILC_HAVE_XTAL_24;
+#endif
+#ifdef DISABLE_WILC_UART
+	reg |= WILC_HAVE_DISABLE_WILC_UART;
+#endif

This kind of configuration should happen on runtime, not compile time.
In other words, the same kernel module should work on _all_ hardware
without recompilation.

+	reg = (BIT(0) | BIT(1) | BIT(2) | BIT(3) | BIT(8) | BIT(9) | BIT(26) |
+	       BIT(29) | BIT(30) | BIT(31));

I said I would stop commenting about magic values, but here I really
have to comment about it :)

Device tree bindings were not visible. And CC
devicetree@vger.kernel.org as we need an ack from the DT maintainers. Also
I have understood that they require the bindings in YAML format now,
at least that was the comment I got with ath11k.

Please remove the 'wilc_' prefix from the filenames, the directory
name is already wilc1000 so no need to replicate that. For example, rename
wilc_hif.c to just hif.c.

+config WILC1000_HW_OOB_INTR
+	bool "WILC1000 out of band interrupt"
+	depends on WILC1000_SDIO
+	help
+	  This option enables out-of-band interrupt support for the WILC1000
+	  chipset. This OOB interrupt is intended to provide a faster interrupt
+	  mechanism for SDIO host controllers that don't support SDIO interrupt.
+	  Select this option If the SDIO host controller in your platform
+	  doesn't support SDIO time devision interrupt.

I think this should be a runtime setting (see my comment about other
compile time settings), for example a module parameter. Would that
work?

-- 
https://patchwork.kernel.org/patch/11040999/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


  reply	other threads:[~2019-10-23 10:03 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-12  1:58 [PATCH v2 00/16] wilc1000: move out of staging Ajay.Kathat
2019-07-12  1:58 ` [PATCH v2 01/16] wilc1000: add wilc_hif.h Ajay.Kathat
2019-10-23 10:03   ` Kalle Valo [this message]
     [not found]   ` <20191023100312.B1D2760A7E@smtp.codeaurora.org>
2019-10-29  3:06     ` Adham.Abozaeid
2019-07-12  1:58 ` [PATCH v2 02/16] wilc1000: add wilc_hif.c Ajay.Kathat
2019-07-12  7:42   ` Johannes Berg
2019-07-12 14:52     ` Ajay.Kathat
2019-07-12  1:58 ` [PATCH v2 03/16] wilc1000: add wilc_wlan_if.h Ajay.Kathat
2019-07-12  1:58 ` [PATCH v2 04/16] wilc1000: add wilc_wlan_cfg.h Ajay.Kathat
2019-07-12  1:58 ` [PATCH v2 05/16] wilc1000: add wilc_wlan_cfg.c Ajay.Kathat
2019-07-12  7:31   ` Johannes Berg
2019-07-12 10:58     ` Ajay.Kathat
2019-07-12  1:58 ` [PATCH v2 06/16] wilc1000: add wilc_wfi_netdevice.h Ajay.Kathat
2019-07-12  1:59 ` [PATCH v2 07/16] wilc1000: add wilc_wfi_cfgoperations.h Ajay.Kathat
2019-07-12  1:59 ` [PATCH v2 08/16] wilc1000: add wilc_wfi_cfgoperations.c Ajay.Kathat
2019-07-12  1:59 ` [PATCH v2 09/16] wilc1000: add wilc_netdev.c Ajay.Kathat
2019-07-12  1:59 ` [PATCH v2 10/16] wilc1000: add wilc_mon.c Ajay.Kathat
2019-07-12  1:59 ` [PATCH v2 11/16] wilc1000: add wilc_spi.c Ajay.Kathat
2019-07-12  1:59 ` [PATCH v2 12/16] wilc1000: add wilc_wlan.c Ajay.Kathat
2019-07-12  1:59 ` [PATCH v2 13/16] wilc1000: add wilc_wlan.h Ajay.Kathat
2019-07-12  1:59 ` [PATCH v2 14/16] wilc1000: add wilc_sdio.c Ajay.Kathat
2019-07-12  1:59 ` [PATCH v2 15/16] wilc1000: updated DT device binding for wilc1000 device Ajay.Kathat
2019-07-12  1:59 ` [PATCH v2 16/16] wilc1000: add Makefile and Kconfig files for wilc1000 compilation Ajay.Kathat

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=20191023100313.52B3F606CF@smtp.codeaurora.org \
    --to=kvalo@codeaurora.org \
    --cc=Adham.Abozaeid@microchip.com \
    --cc=Ajay.Kathat@microchip.com \
    --cc=Claudiu.Beznea@microchip.com \
    --cc=Nicolas.Ferre@microchip.com \
    --cc=Venkateswara.Kaja@microchip.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).