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, ®);
+
+ 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
next prev parent 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).