linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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 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).