From: Johannes Berg <johannes@sipsolutions.net>
To: igor.mitsyanko.os@quantenna.com, kvalo@codeaurora.org
Cc: linux-wireless@vger.kernel.org,
Avinash Patil <avinashp@quantenna.com>,
Dmitrii Lebed <dlebed@quantenna.com>,
Sergei Maksimenko <smaksimenko@quantenna.com>,
Sergey Matyukevich <smatyukevich@quantenna.com>,
Bindu Therthala <btherthala@quantenna.com>,
Huizhao Wang <hwang@quantenna.com>,
Kamlesh Rath <krath@quantenna.com>
Subject: Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets
Date: Tue, 21 Jun 2016 14:22:06 +0200 [thread overview]
Message-ID: <1466511726.3170.33.camel@sipsolutions.net> (raw)
In-Reply-To: <1466460688-28160-1-git-send-email-igor.mitsyanko.os@quantenna.com>
Very brief review:
> +/* */
That seems slightly odd.
> + /* bus private data */
> + char bus_priv[0];
You might want to - for future proofing - add some aligned() attribute.
Otherwise, if struct mutex doesn't have a size that's a multiple of the
pointer size, fields in here will not be aligned right.
> +static inline void *get_bus_priv(struct qtnf_bus *bus)
> +{
> + if (WARN_ON(!bus)) {
> + pr_err("qtnfmac: invalid bus pointer!\n");
> + return NULL;
Better to just use "WARN(!bus, "qtnfmac: invalid bus pointer!\n");"
Also, for pr_* the "qtnfmac: " prefix should be done with pr_fmt, not
manually.
> +#define QLINK_HT_MCS_MASK_LEN 10
> +#define QLINK_ETH_ALEN 6
> +#define QLINK_MAX_SSID_LEN 32
These seem a bit strange? Why bother? They are standard values.
(not entirely sure what the MCS_MASK_LEN is used for though)
> +/*
> + * struct qlink_ht_mcs_info - MCS information
> + *
> + * See &struct ieee80211_mcs_info.
> + */
> +struct qlink_ht_mcs_info {
> + u8 rx_mask[QLINK_HT_MCS_MASK_LEN];
> + __le16 rx_highest;
> + u8 tx_params;
> + u8 reserved[3];
> +} __packed;
> +
> +/*
> + * struct qlink_ht_cap - HT capabilities
> + *
> + * "HT capabilities element", see &struct ieee80211_ht_cap.
> + */
> +struct qlink_ht_cap {
> + struct qlink_ht_mcs_info mcs;
> + __le32 tx_BF_cap_info;
> + __le16 cap_info;
> + __le16 extended_ht_cap_info;
> + u8 ampdu_params_info;
> + u8 antenna_selection_info;
> +} __packed;
> +
> +/*
> + * struct qlink_vht_mcs_info - VHT MCS information
> + *
> + * See &struct ieee80211_vht_mcs_info.
> + */
> +struct qlink_vht_mcs_info {
> + __le16 rx_mcs_map;
> + __le16 rx_highest;
> + __le16 tx_mcs_map;
> + __le16 tx_highest;
> +} __packed;
> +
> +/*
> + * struct qlink_vht_cap - VHT capabilities
> + *
> + * "VHT capabilities element", see &struct ieee80211_vht_cap.
> + */
> +struct qlink_vht_cap {
> + __le32 vht_cap_info;
> + struct qlink_vht_mcs_info supp_mcs;
> +} __packed;
I think you shouldn't duplicate these, there's no sane way they can
ever be changed in ieee80211.h
> +enum qlink_iface_type {
> + QLINK_IFTYPE_AP = BIT(0),
> + QLINK_IFTYPE_STATION = BIT(1),
> + QLINK_IFTYPE_ADHOC = BIT(2),
> + QLINK_IFTYPE_MONITOR = BIT(3),
> + QLINK_IFTYPE_WDS = BIT(4),
> +};
Not sure how you use these, but BIT() doesn't make a lot of sense for
something that's mutually exclusive?
> +/**
> + * Copyright (c) 2015-2016 Quantenna Communications, Inc.
> + * All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + **/
You should probably not have those double asterisks since they're
reserved for kernel-doc.
> + if (qtnf_cmd_send_start_ap(vif)) {
> + pr_err("failed to issue start AP command\n");
> + return -EFAULT;
> + }
> +
> + if (!(vif->bss_status & QTNF_STATE_AP_START)) {
> + pr_err("failed to start AP operations in FW\n");
> + return -EFAULT;
> + }
This is strange - I'd expect send_start_ap() to not actually just send
it, but also wait for a response, and then it can return an error if
the flag didn't get set. If it doesn't, then it's racy, no?
> +static int
> +qtnf_connect(struct wiphy *wiphy, struct net_device *dev,
> + struct cfg80211_connect_params *sme)
> +{
> + struct qtnf_vif *vif;
> + struct qtnf_bss_config *bss_cfg;
> +
> + vif = qtnf_netdev_get_priv(dev);
> + if (!vif) {
> + pr_err("core_attach: could not get valid vif
> pointer\n");
> + return -EFAULT;
> + }
It seems that you're overdoing the error checks a bit - I don't see how
this could possibly fail?
> + memcpy(&bss_cfg->crypto, &sme->crypto, sizeof(bss_cfg-
> >crypto));
This makes no sense at all - you have to convert the format of this
somehow to make it work - at least endianness has to be fixed, even if
you copied all of the cfg80211 struct.
[snip - lots of stuff I didn't really look at]
> +/* sysfs knobs: stats and other diagnistics */
I think you should not have these - maybe add those with separate
patches later that really can't be done otherwise, and then give very
good rationale for it. Having driver-specific sysfs is not a good idea
in general.
> +static inline u64 qtnf_get_unaligned_le64(const __le64 *ptr)
> +{
> + return le64_to_cpu(get_unaligned(ptr));
> +}
> +
> +static inline u32 qtnf_get_unaligned_le32(const __le32 *ptr)
> +{
> + return le32_to_cpu(get_unaligned(ptr));
> +}
> +
> +static inline u16 qtnf_get_unaligned_le16(const __le16 *ptr)
> +{
> + return le16_to_cpu(get_unaligned(ptr));
> +}
Huh, what? These exist, or should exist, already.
[snip more]
johannes
next prev parent reply other threads:[~2016-06-21 12:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-20 22:11 [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets igor.mitsyanko.os
2016-06-21 2:12 ` kbuild test robot
2016-06-21 12:22 ` Johannes Berg [this message]
2016-07-11 18:57 ` Igor Mitsyanko
2016-08-01 9:37 ` Johannes Berg
2016-09-17 13:59 ` Kalle Valo
2016-07-19 7:39 ` [v2, " Kalle Valo
2016-09-17 13:46 ` [PATCH v2 " Kalle Valo
2016-09-17 14:50 ` Johannes Berg
2016-09-17 15:01 ` Kalle Valo
2016-09-17 15:11 ` Johannes Berg
2016-09-17 15:14 ` Kalle Valo
2016-09-20 18:51 ` IgorMitsyanko
2016-09-20 18:51 ` IgorMitsyanko
2016-09-26 10:56 ` Kalle Valo
2016-09-26 12:45 ` IgorMitsyanko
2016-09-26 18:16 ` Kalle Valo
2016-09-17 13:56 ` Kalle Valo
2016-09-20 19:05 ` IgorMitsyanko
2016-09-26 10:45 ` Kalle Valo
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=1466511726.3170.33.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=avinashp@quantenna.com \
--cc=btherthala@quantenna.com \
--cc=dlebed@quantenna.com \
--cc=hwang@quantenna.com \
--cc=igor.mitsyanko.os@quantenna.com \
--cc=krath@quantenna.com \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
--cc=smaksimenko@quantenna.com \
--cc=smatyukevich@quantenna.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.