* Re: [PATCH 3/3] mwifiex: wake system up when receives a wake irq
From: Kalle Valo @ 2017-02-24 11:01 UTC (permalink / raw)
To: Jeffy Chen
Cc: Amitkumar Karwar, Brian Norris, Rajat Jain, netdev,
linux-wireless, linux-kernel, Nishant Sarmukadam
In-Reply-To: <1487917471-5501-3-git-send-email-jeffy.chen@rock-chips.com>
Jeffy Chen <jeffy.chen@rock-chips.com> writes:
> Currrently we are disabling this wake irq after receiving it. If this
> happens before we finish suspend and the pm event check is disabled,
> the system will continue suspending, and this irq would not work again.
>
> We may need to abort system suspend to avoid that.
>
> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
I only see patch 3 in patchwork. Where are patches 1 and 2?
--
Kalle Valo
^ permalink raw reply
* Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362
From: Jörg Krause @ 2017-02-24 10:26 UTC (permalink / raw)
To: Arend Van Spriel, linux-wireless@vger.kernel.org
Cc: brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <ce3bf3a5-2cd7-eb77-bb7d-57df8388e1ba@broadcom.com>
Hi Arend,
On Fri, 2017-02-24 at 10:58 +0100, Arend Van Spriel wrote:
> On 24-2-2017 10:43, Jörg Krause wrote:
> > Hi Arend,
> >
> > On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote:
> > >
> > > On 23-2-2017 21:21, Jörg Krause wrote:
> > > > Hi,
> > > >
> > > > I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When
> > > > running
> > > > 'wpa_cli wps_pin any', the following messages are printed:
> > > >
> > > > """
> > > > > wps_pin any
> > > >
> > > > [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set
> > > > error :
> > > > -30
> > > > [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE
> > > > Failed
> > > > """
> > > >
> > > > .. and nothing happens. The data sheet for the BCM43362 states
> > > > that
> > > > the
> > > > module supports WPS.
> > >
> > > Hi Jörg,
> > >
> > > We have never tested WPS with brcmfmac. Most of it is in firmware
> > > so
> > > it
> > > might work. We had some fixes related to setting management IE,
> > > but
> > > it
> > > should be in 4.9. I did not check it (yet).
> >
> > As it turns out, WPS does not work if a network configuration in
> > wpa_supplicant has the flag `mode=2` (access point mode) set:
> >
> > """
> > ctrl_interface=/var/run/wpa_supplicant
> > update_config=1
> >
> > network={
> > ssid="AP"
> > key_mgmt=NONE
> > mode=2
> > id_str="ap"
> > }
> > """
> >
> > Setting mode=2 for a network and having ap_scan=1 (default) means
> > if no
> > APs matching to the currently enabled networks are found, a new
> > network
> > (IBSS or AP mode operation) may be initialized (if configured).
> >
> > So, WPS does not work if the interface is operating in AP mode. I
> > wonder, if this is a desired behavior? At least, wpa_supplicant
> > does
> > not complain, but prints "WPS-PBC-ACTIVE", but no messages are
> > following, until "WPS-TIMEOUT".
>
> So what do you expect exactly? Are you trying to connect with some
> other
> device to this AP interface?
Sorry, I got confused. The device operating in AP mode shall be
connected to some other AP as a station. Of course, WPS cannot be used
to do so as long as the interface is operation in AP mode, as the
device should be the WPS enrollee and not the registrar. My bad! Thanks
for pointing that out.
So, to use WPS for connecting the device to another AP I have to bring
the interface into an non-AP mode first.
So, I can confirm that using WPS works when the interface is
unconfigured. However, if the in the interface is in AP mode and WPS is
started the error messages pop up.
Jörg
^ permalink raw reply
* Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362
From: Arend Van Spriel @ 2017-02-24 9:58 UTC (permalink / raw)
To: Jörg Krause, linux-wireless@vger.kernel.org
Cc: brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <1487929408.3812.3.camel@embedded.rocks>
On 24-2-2017 10:43, Jörg Krause wrote:
> Hi Arend,
>
> On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote:
>>
>> On 23-2-2017 21:21, Jörg Krause wrote:
>>> Hi,
>>>
>>> I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When running
>>> 'wpa_cli wps_pin any', the following messages are printed:
>>>
>>> """
>>>> wps_pin any
>>>
>>> [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set error :
>>> -30
>>> [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE
>>> Failed
>>> """
>>>
>>> .. and nothing happens. The data sheet for the BCM43362 states that
>>> the
>>> module supports WPS.
>>
>> Hi Jörg,
>>
>> We have never tested WPS with brcmfmac. Most of it is in firmware so
>> it
>> might work. We had some fixes related to setting management IE, but
>> it
>> should be in 4.9. I did not check it (yet).
>
> As it turns out, WPS does not work if a network configuration in
> wpa_supplicant has the flag `mode=2` (access point mode) set:
>
> """
> ctrl_interface=/var/run/wpa_supplicant
> update_config=1
>
> network={
> ssid="AP"
> key_mgmt=NONE
> mode=2
> id_str="ap"
> }
> """
>
> Setting mode=2 for a network and having ap_scan=1 (default) means if no
> APs matching to the currently enabled networks are found, a new network
> (IBSS or AP mode operation) may be initialized (if configured).
>
> So, WPS does not work if the interface is operating in AP mode. I
> wonder, if this is a desired behavior? At least, wpa_supplicant does
> not complain, but prints "WPS-PBC-ACTIVE", but no messages are
> following, until "WPS-TIMEOUT".
So what do you expect exactly? Are you trying to connect with some other
device to this AP interface?
Regards,
Arend
^ permalink raw reply
* Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362
From: Jörg Krause @ 2017-02-24 9:43 UTC (permalink / raw)
To: Arend Van Spriel, linux-wireless@vger.kernel.org
Cc: brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <dd241eff-7e0d-26c1-1758-b3f4d51bc359@broadcom.com>
Hi Arend,
On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote:
>
> On 23-2-2017 21:21, Jörg Krause wrote:
> > Hi,
> >
> > I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When running
> > 'wpa_cli wps_pin any', the following messages are printed:
> >
> > """
> > > wps_pin any
> >
> > [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set error :
> > -30
> > [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE
> > Failed
> > """
> >
> > .. and nothing happens. The data sheet for the BCM43362 states that
> > the
> > module supports WPS.
>
> Hi Jörg,
>
> We have never tested WPS with brcmfmac. Most of it is in firmware so
> it
> might work. We had some fixes related to setting management IE, but
> it
> should be in 4.9. I did not check it (yet).
As it turns out, WPS does not work if a network configuration in
wpa_supplicant has the flag `mode=2` (access point mode) set:
"""
ctrl_interface=/var/run/wpa_supplicant
update_config=1
network={
ssid="AP"
key_mgmt=NONE
mode=2
id_str="ap"
}
"""
Setting mode=2 for a network and having ap_scan=1 (default) means if no
APs matching to the currently enabled networks are found, a new network
(IBSS or AP mode operation) may be initialized (if configured).
So, WPS does not work if the interface is operating in AP mode. I
wonder, if this is a desired behavior? At least, wpa_supplicant does
not complain, but prints "WPS-PBC-ACTIVE", but no messages are
following, until "WPS-TIMEOUT".
Jörg
^ permalink raw reply
* Re: Request for brcmfmac4366c-pcie.bin
From: Arend Van Spriel @ 2017-02-24 9:07 UTC (permalink / raw)
To: Rafał Miłecki, Hante Meuleman, bcm-kernel-feedback-list
Cc: linux-wireless@vger.kernel.org, Hauke Mehrtens, Nathan Grennan
In-Reply-To: <CACna6rywt_U+SSLRGAgnqZiwO8TmY8z406m8o5gCOsGiyUc+oQ@mail.gmail.com>
On 23-2-2017 21:53, Rafał Miłecki wrote:
> Hi guys,
>
> On 12 September 2016 at 07:22, Rafał Miłecki <zajec5@gmail.com> wrote:
>> Few months ago Hante added support for 4366c0 to the brcmfmac. There
>> are already few devices with this chipset on the market. We even have
>> some related bug report at kernel:
>> https://bugzilla.kernel.org/show_bug.cgi?id=135321
>>
>> Unfortunately the firmware for this chipset is still missing. Can you
>> build it and submit to linux-firmware.git, please?
>
> Last answer I got from Arend was "Router group still working on a
> solution. Will ask about status again :-(" in December.
> Are there any news on 4366c1 firmware?
There have been some firmware changes being made, but these need to be
validated. As the validation is in DFS area it may take some time and we
have to free up resources to actually do the validation.
Regards,
Arend
^ permalink raw reply
* Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362
From: Jörg Krause @ 2017-02-24 8:51 UTC (permalink / raw)
To: Arend Van Spriel, linux-wireless@vger.kernel.org
Cc: brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <dd241eff-7e0d-26c1-1758-b3f4d51bc359@broadcom.com>
Hi Arend,
On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote:
>
> On 23-2-2017 21:21, Jörg Krause wrote:
> > Hi,
> >
> > I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When running
> > 'wpa_cli wps_pin any', the following messages are printed:
> >
> > """
> > > wps_pin any
> >
> > [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set error :
> > -30
> > [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE
> > Failed
> > """
> >
> > .. and nothing happens. The data sheet for the BCM43362 states that
> > the
> > module supports WPS.
>
> Hi Jörg,
>
> We have never tested WPS with brcmfmac. Most of it is in firmware so
> it
> might work. We had some fixes related to setting management IE, but
> it
> should be in 4.9. I did not check it (yet).
I've tested WPS on another board, the Banana Pro, which also has the
BCM43362 and it works with Linux v4.9.12. So, I'll look why it does not
work on my custom board.
Jörg
^ permalink raw reply
* Re: [PATCH 162/306] mac80211-hwsim: add length checks before allocating skb.
From: Andrew Zaborowski @ 2017-02-24 8:45 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless
In-Reply-To: <1487896109-23851-7-git-send-email-greearb@candelatech.com>
On 24 February 2017 at 01:28, <greearb@candelatech.com> wrote:
> Modify the receive-from-user-space logic to do length
> and 'is-down' checks before trying to allocate an skb.
>
> And, if we are going to ignore the pkt due to radio idle,
> then do not return an error code to user-space. User-space
> cannot reliably know exactly when a radio is idle or not.
You probably want to return some error code anyway because 0, if you
compare to the kernel medium, currently maps to the ack returned bit
and is possibly the only way for userspace to set the
HWSIM_TX_STAT_ACK flag in a meaningful way.
Best regards
^ permalink raw reply
* Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362
From: Arend Van Spriel @ 2017-02-24 8:16 UTC (permalink / raw)
To: Jörg Krause, linux-wireless@vger.kernel.org
Cc: brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <1487881302.20481.3.camel@embedded.rocks>
On 23-2-2017 21:21, Jörg Krause wrote:
> Hi,
>
> I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When running
> 'wpa_cli wps_pin any', the following messages are printed:
>
> """
>> wps_pin any
> [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set error : -30
> [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE Failed
> """
>
> .. and nothing happens. The data sheet for the BCM43362 states that the
> module supports WPS.
Hi Jörg,
We have never tested WPS with brcmfmac. Most of it is in firmware so it
might work. We had some fixes related to setting management IE, but it
should be in 4.9. I did not check it (yet).
Regards,
Arend
^ permalink raw reply
* Re: [RFC v2 2/2] cfg80211: support 4-way handshake offloading for 802.1X
From: Arend Van Spriel @ 2017-02-24 8:08 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: Avraham Stern
In-Reply-To: <20170221123758.5339-2-johannes@sipsolutions.net>
On 21-2-2017 13:37, Johannes Berg wrote:
> From: Avraham Stern <avraham.stern@intel.com>
>
> Add API for setting the PMK to the driver. For FT support, allow
> setting also the PMK-R0 Name.
>
> This can be used by drivers that support 4-Way handshake offload
> while IEEE802.1X authentication is managed by upper layers.
>
> Signed-off-by: Avraham Stern <avraham.stern@intel.com>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> include/linux/ieee80211.h | 3 ++
> include/net/cfg80211.h | 27 ++++++++++++
> include/uapi/linux/nl80211.h | 24 ++++++++++-
> net/wireless/core.c | 5 +++
> net/wireless/nl80211.c | 99 ++++++++++++++++++++++++++++++++++++++++++++
> net/wireless/rdev-ops.h | 25 +++++++++++
> net/wireless/trace.h | 60 +++++++++++++++++++++++++++
> 7 files changed, 241 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
> index 2049e983a994..fb1f533e75b3 100644
> --- a/include/linux/ieee80211.h
> +++ b/include/linux/ieee80211.h
> @@ -2356,8 +2356,11 @@ enum ieee80211_sa_query_action {
>
> #define WLAN_MAX_KEY_LEN 32
>
> +#define WLAN_PMK_NAME_LEN 16
> #define WLAN_PMKID_LEN 16
> +#define WLAN_PMK_LEN_EAP_LEAP 16
> #define WLAN_PMK_LEN 32
> +#define WLAN_PMK_LEN_SUITE_B_192 48
>
> #define WLAN_OUI_WFA 0x506f9a
> #define WLAN_OUI_TYPE_WFA_P2P 9
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 4ca968927d60..a68c6db6ac55 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -2507,6 +2507,23 @@ struct cfg80211_nan_func {
> };
>
> /**
> + * struct cfg80211_pmk_conf - PMK configuration
> + *
> + * @aa: authenticator address
> + * @pmk_len: PMK length in bytes.
> + * @pmk: the PMK material
> + * @pmk_r0_name: PMK-R0 Name. NULL if not applicable (i.e., the PMK
> + * is not PMK-R0). When pmk_r0_name is not NULL, the pmk field
> + * holds PMK-R0.
> + */
> +struct cfg80211_pmk_conf {
> + const u8 *aa;
> + u8 pmk_len;
> + const u8 *pmk;
> + const u8 *pmk_r0_name;
> +};
> +
> +/**
> * struct cfg80211_ops - backend description for wireless configuration
> *
> * This struct is registered by fullmac card drivers and/or wireless stacks
> @@ -2823,6 +2840,11 @@ struct cfg80211_nan_func {
> * All other parameters must be ignored.
> *
> * @set_multicast_to_unicast: configure multicast to unicast conversion for BSS
> + *
> + * @set_pmk: configure the PMK to be used for offloaded 4-Way handshake.
> + * (invoked with the wireless_dev mutex held)
> + * @del_pmk: delete the previously configured PMK for the given authenticator.
> + * (invoked with the wireless_dev mutex held)
> */
> struct cfg80211_ops {
> int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
> @@ -3111,6 +3133,11 @@ struct cfg80211_ops {
> int (*set_multicast_to_unicast)(struct wiphy *wiphy,
> struct net_device *dev,
> const bool enabled);
> +
> + int (*set_pmk)(struct wiphy *wiphy, struct net_device *dev,
> + const struct cfg80211_pmk_conf *conf);
> + int (*del_pmk)(struct wiphy *wiphy, struct net_device *dev,
> + const u8 *aa);
Minor nit, but prefer clr_pmk to clear the pmk.
> };
>
> /*
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index bb5e1904a107..89295fc2336b 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -901,6 +901,14 @@
> * does not result in a change for the current association. Currently,
> * only the %NL80211_ATTR_IE data is used and updated with this command.
> *
> + * @NL80211_CMD_SET_PMK: For offloaded 4-Way handshake, set the PMK or PMK-R0
> + * for the given authenticator address (specified with &NL80211_ATTR_MAC).
> + * When &NL80211_ATTR_PMKR0_NAME is set, &NL80211_ATTR_PMK specifies the
> + * PMK-R0, otherwise it specifies the PMK.
> + * @NL80211_CMD_DEL_PMK: For offloaded 4-Way handshake, delete the previously
> + * configured PMK for the authenticator address identified by
> + * &NL80211_ATTR_MAC.
Maybe better to indicate it is for 802.1X. Here also preference for
NL80211_CMD_CLR_PMK.
> + *
> * @NL80211_CMD_MAX: highest used command number
> * @__NL80211_CMD_AFTER_LAST: internal use
> */
> @@ -1100,6 +1108,9 @@ enum nl80211_commands {
>
> NL80211_CMD_UPDATE_CONNECT_PARAMS,
>
> + NL80211_CMD_SET_PMK,
> + NL80211_CMD_DEL_PMK,
> +
> /* add new commands above here */
>
> /* used to define NL80211_CMD_MAX below */
> @@ -2012,8 +2023,12 @@ enum nl80211_commands {
> * u32 attribute with an &enum nl80211_timeout_reason value. This is used,
> * e.g., with %NL80211_CMD_CONNECT event.
> *
> - * @NL80211_ATTR_PMK: PSK for offloaded 4-Way Handshake. Relevant only
> - * with %NL80211_CMD_CONNECT (for WPA/WPA2-PSK networks).
> + * @NL80211_ATTR_PMK: PMK for offloaded 4-Way Handshake. Relevant with
> + * %NL80211_CMD_CONNECT (for WPA/WPA2-PSK networks) when PSK is used, or
> + * with %NL80211_CMD_SET_PMK when 802.1X authentication is used.
> + * When &NL80211_ATTR_PMKR0_NAME is specified, this attribute specifies
> + * the PMK-R0.
> + * @NL80211_ATTR_PMKR0_NAME: PMK-R0 Name for offloaded FT.
> *
> * @NUM_NL80211_ATTR: total number of nl80211_attrs available
> * @NL80211_ATTR_MAX: highest attribute number currently defined
> @@ -2427,6 +2442,7 @@ enum nl80211_attrs {
> NL80211_ATTR_TIMEOUT_REASON,
>
> NL80211_ATTR_PMK,
> + NL80211_ATTR_PMKR0_NAME,
>
> /* add attributes here, update the policy in nl80211.c */
>
> @@ -4767,6 +4783,9 @@ enum nl80211_feature_flags {
> * @NL80211_EXT_FEATURE_4WAY_HANDSHAKE_STA_PSK: Device supports doing 4-way
> * handshake with PSK in station mode (PSK is passed as part of the connect
> * and associate commands).
> + * @NL80211_EXT_FEATURE_4WAY_HANDSHAKE_STA_1X: Device supports doing 4-way
> + * handshake with 802.1X in station mode (needs to pass EAP frames to
> + * the host and accept the set_pmk/del_pmk commands).
> *
> * @NUM_NL80211_EXT_FEATURES: number of extended features.
> * @MAX_NL80211_EXT_FEATURES: highest extended feature index.
> @@ -4787,6 +4806,7 @@ enum nl80211_ext_feature_index {
> NL80211_EXT_FEATURE_SCHED_SCAN_RELATIVE_RSSI,
> NL80211_EXT_FEATURE_CQM_RSSI_LIST,
> NL80211_EXT_FEATURE_4WAY_HANDSHAKE_STA_PSK,
> + NL80211_EXT_FEATURE_4WAY_HANDSHAKE_STA_1X,
So do we need this flag. Is the fact that the driver implements the
set_pmk and del_pmk (or clr_pmk) callbacks not sufficient provided they
are listed in the "supported commands" message of wiphy dump (not in
this patch). Which reminds me, is "supported commands" no longer
preferred because that list does not seem complete?
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 099/306] mac80211-hwsim: notify user-space about channel change.
From: Johannes Berg @ 2017-02-24 6:36 UTC (permalink / raw)
To: greearb, linux-wireless
In-Reply-To: <1487896109-23851-1-git-send-email-greearb@candelatech.com>
> + msg_head = genlmsg_put(skb, 0, 0, &hwsim_genl_family, 0,
> + HWSIM_CMD_NOTIFY);
I think you should use a more specific command name.
> + if (nla_put(skb, HWSIM_ATTR_ADDR_TRANSMITTER,
> + ETH_ALEN, data->addresses[1].addr))
> + goto nla_put_failure;
and at least also add a more specific identifier like the radio ID.
> + if (data->channel)
> + center_freq = data->channel->center_freq;
> +
> + if (nla_put_u32(skb, HWSIM_ATTR_FREQ, center_freq))
> + goto nla_put_failure;
and have the full channel definition
Also the indentation in the documentation didn't match the convention
used there.
johannes
^ permalink raw reply
* Re: [PATCH 162/306] mac80211-hwsim: add length checks before allocating skb.
From: Johannes Berg @ 2017-02-24 6:43 UTC (permalink / raw)
To: greearb, linux-wireless
In-Reply-To: <1487896109-23851-7-git-send-email-greearb@candelatech.com>
And here's the third patch in a row modifying the same code ...
johannes
^ permalink raw reply
* Re: [PATCH 161/306] mac80211-hwsim: Improve logging.
From: Johannes Berg @ 2017-02-24 6:42 UTC (permalink / raw)
To: greearb, linux-wireless
In-Reply-To: <1487896109-23851-6-git-send-email-greearb@candelatech.com>
> + static unsigned int cnt = 0;
> + /* This is fairly common, and usually not a
> bug. So, print errors
> + rarely. */
> + if (((cnt++ & 0x3FF) == 0x3FF) && net_ratelimit())
> + printk(KERN_DEBUG " hwsim rx-nl: radio %pM
> idle: %d or not started: %d cnt: %d\n",
> + dst, data2->idle, !data2->started,
> cnt);
> goto out;
> }
You just added that in the previous patch...
Please take a bit more care, or I'll eventually stop looking at your
patches since things like that seem to happen over and over again. I
don't get a feeling that you actually care about getting things
upstream much anyway.
johannes
^ permalink raw reply
* Re: [Outreachy kernel] [PATCH v3 1/3] staging: wilc1000: Rename struct tstrRSSI to rssi_history_buffer
From: Julia Lawall @ 2017-02-24 6:40 UTC (permalink / raw)
To: Tahia Khan
Cc: outreachy-kernel, aditya.shankar, ganesh.krishna, gregkh,
linux-wireless, devel, linux-kernel
In-Reply-To: <da73d1aef379243ba94a5c1a4e1d6663160451fd.1487912400.git.tahia.khan@gmail.com>
On Fri, 24 Feb 2017, Tahia Khan wrote:
> Rename struct tstrRSSI to rssi_history_buffer for clarity and to remove camel casing.
Here the commit log messge line is definitely too long.
julia
>
> Signed-off-by: Tahia Khan <tahia.khan@gmail.com>
> ---
> drivers/staging/wilc1000/coreconfigurator.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/coreconfigurator.h b/drivers/staging/wilc1000/coreconfigurator.h
> index cff1698..1c77529 100644
> --- a/drivers/staging/wilc1000/coreconfigurator.h
> +++ b/drivers/staging/wilc1000/coreconfigurator.h
> @@ -70,7 +70,7 @@ enum connect_status {
> CONNECT_STS_FORCE_16_BIT = 0xFFFF
> };
>
> -struct tstrRSSI {
> +struct rssi_history_buffer {
> u8 u8Full;
> u8 u8Index;
> s8 as8RSSI[NUM_RSSI];
> @@ -93,7 +93,7 @@ struct network_info {
> u8 *ies;
> u16 ies_len;
> void *join_params;
> - struct tstrRSSI str_rssi;
> + struct rssi_history_buffer str_rssi;
> u64 tsf_hi;
> };
>
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com.
> To post to this group, send email to outreachy-kernel@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/da73d1aef379243ba94a5c1a4e1d6663160451fd.1487912400.git.tahia.khan%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
^ permalink raw reply
* Re: [Outreachy kernel] [PATCH v3 2/3] staging: wilc1000: Rename tstrRSSI members and change type of u8Full to bool
From: Julia Lawall @ 2017-02-24 6:40 UTC (permalink / raw)
To: Tahia Khan
Cc: outreachy-kernel, aditya.shankar, ganesh.krishna, gregkh,
linux-wireless, devel, linux-kernel
In-Reply-To: <e4e0e4da09635d0cb7ef43223022490b6de739a8.1487912400.git.tahia.khan@gmail.com>
On Fri, 24 Feb 2017, Tahia Khan wrote:
> Remove Hungarian notation and camel casing from all tstrRSSI members' names.
> Additionally, change type of u8Full to bool since it only takes values 1 or 0.
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Maybe the second line of the commit message is a little too long. It is
under 80 characters, but they come out a bit indented in the git log, so a
little shorter is better.
julia
>
> Signed-off-by: Tahia Khan <tahia.khan@gmail.com>
> ---
> drivers/staging/wilc1000/coreconfigurator.h | 6 +++---
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 14 +++++++-------
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/coreconfigurator.h b/drivers/staging/wilc1000/coreconfigurator.h
> index 1c77529..9712d89 100644
> --- a/drivers/staging/wilc1000/coreconfigurator.h
> +++ b/drivers/staging/wilc1000/coreconfigurator.h
> @@ -71,9 +71,9 @@ enum connect_status {
> };
>
> struct rssi_history_buffer {
> - u8 u8Full;
> - u8 u8Index;
> - s8 as8RSSI[NUM_RSSI];
> + bool full;
> + u8 index;
> + s8 samples[NUM_RSSI];
> };
>
> struct network_info {
> diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> index f7ce47c..9601ab8 100644
> --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> @@ -205,11 +205,11 @@ static u32 get_rssi_avg(struct network_info *network_info)
> {
> u8 i;
> int rssi_v = 0;
> - u8 num_rssi = (network_info->str_rssi.u8Full) ?
> - NUM_RSSI : (network_info->str_rssi.u8Index);
> + u8 num_rssi = (network_info->str_rssi.full) ?
> + NUM_RSSI : (network_info->str_rssi.index);
>
> for (i = 0; i < num_rssi; i++)
> - rssi_v += network_info->str_rssi.as8RSSI[i];
> + rssi_v += network_info->str_rssi.samples[i];
>
> rssi_v /= num_rssi;
> return rssi_v;
> @@ -346,13 +346,13 @@ static void add_network_to_shadow(struct network_info *pstrNetworkInfo,
> } else {
> ap_index = ap_found;
> }
> - rssi_index = last_scanned_shadow[ap_index].str_rssi.u8Index;
> - last_scanned_shadow[ap_index].str_rssi.as8RSSI[rssi_index++] = pstrNetworkInfo->rssi;
> + rssi_index = last_scanned_shadow[ap_index].str_rssi.index;
> + last_scanned_shadow[ap_index].str_rssi.samples[rssi_index++] = pstrNetworkInfo->rssi;
> if (rssi_index == NUM_RSSI) {
> rssi_index = 0;
> - last_scanned_shadow[ap_index].str_rssi.u8Full = 1;
> + last_scanned_shadow[ap_index].str_rssi.full = true;
> }
> - last_scanned_shadow[ap_index].str_rssi.u8Index = rssi_index;
> + last_scanned_shadow[ap_index].str_rssi.index = rssi_index;
> last_scanned_shadow[ap_index].rssi = pstrNetworkInfo->rssi;
> last_scanned_shadow[ap_index].cap_info = pstrNetworkInfo->cap_info;
> last_scanned_shadow[ap_index].ssid_len = pstrNetworkInfo->ssid_len;
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com.
> To post to this group, send email to outreachy-kernel@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/e4e0e4da09635d0cb7ef43223022490b6de739a8.1487912400.git.tahia.khan%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
^ permalink raw reply
* Re: [PATCH 160/306] mac80211-hwsim: add rate-limited debugging for rx-netlink
From: Johannes Berg @ 2017-02-24 6:39 UTC (permalink / raw)
To: greearb, linux-wireless
In-Reply-To: <1487896109-23851-5-git-send-email-greearb@candelatech.com>
> + !info->attrs[HWSIM_ATTR_SIGNAL]) {
> + if (net_ratelimit())
> + printk(KERN_DEBUG " hwsim rx-nl: Missing
> required attribute\n");
I'm not convinced net_ratelimit() is a good idea, that's a global rate
limiter.
johannes
^ permalink raw reply
* Re: [Outreachy kernel] [PATCH v3 3/3] staging: wilc1000: Rename network_info member str_rssi to rssi_history
From: Julia Lawall @ 2017-02-24 6:39 UTC (permalink / raw)
To: Tahia Khan
Cc: outreachy-kernel, aditya.shankar, ganesh.krishna, gregkh,
linux-wireless, devel, linux-kernel
In-Reply-To: <6fd3f34baa31c00a77e2805d5d8a820b3ac7a43f.1487912400.git.tahia.khan@gmail.com>
On Fri, 24 Feb 2017, Tahia Khan wrote:
> Change name of str_rssi to rssi_history within the network_info struct for clarity.
>
> Signed-off-by: Tahia Khan <tahia.khan@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Good job at cutting up the patch in a meaningful way.
julia
> ---
> drivers/staging/wilc1000/coreconfigurator.h | 2 +-
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 14 +++++++-------
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/coreconfigurator.h b/drivers/staging/wilc1000/coreconfigurator.h
> index 9712d89..10101f8 100644
> --- a/drivers/staging/wilc1000/coreconfigurator.h
> +++ b/drivers/staging/wilc1000/coreconfigurator.h
> @@ -93,7 +93,7 @@ struct network_info {
> u8 *ies;
> u16 ies_len;
> void *join_params;
> - struct rssi_history_buffer str_rssi;
> + struct rssi_history_buffer rssi_history;
> u64 tsf_hi;
> };
>
> diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> index 9601ab8..4a6fe90 100644
> --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> @@ -205,11 +205,11 @@ static u32 get_rssi_avg(struct network_info *network_info)
> {
> u8 i;
> int rssi_v = 0;
> - u8 num_rssi = (network_info->str_rssi.full) ?
> - NUM_RSSI : (network_info->str_rssi.index);
> + u8 num_rssi = (network_info->rssi_history.full) ?
> + NUM_RSSI : (network_info->rssi_history.index);
>
> for (i = 0; i < num_rssi; i++)
> - rssi_v += network_info->str_rssi.samples[i];
> + rssi_v += network_info->rssi_history.samples[i];
>
> rssi_v /= num_rssi;
> return rssi_v;
> @@ -346,13 +346,13 @@ static void add_network_to_shadow(struct network_info *pstrNetworkInfo,
> } else {
> ap_index = ap_found;
> }
> - rssi_index = last_scanned_shadow[ap_index].str_rssi.index;
> - last_scanned_shadow[ap_index].str_rssi.samples[rssi_index++] = pstrNetworkInfo->rssi;
> + rssi_index = last_scanned_shadow[ap_index].rssi_history.index;
> + last_scanned_shadow[ap_index].rssi_history.samples[rssi_index++] = pstrNetworkInfo->rssi;
> if (rssi_index == NUM_RSSI) {
> rssi_index = 0;
> - last_scanned_shadow[ap_index].str_rssi.full = true;
> + last_scanned_shadow[ap_index].rssi_history.full = true;
> }
> - last_scanned_shadow[ap_index].str_rssi.index = rssi_index;
> + last_scanned_shadow[ap_index].rssi_history.index = rssi_index;
> last_scanned_shadow[ap_index].rssi = pstrNetworkInfo->rssi;
> last_scanned_shadow[ap_index].cap_info = pstrNetworkInfo->cap_info;
> last_scanned_shadow[ap_index].ssid_len = pstrNetworkInfo->ssid_len;
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com.
> To post to this group, send email to outreachy-kernel@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/6fd3f34baa31c00a77e2805d5d8a820b3ac7a43f.1487912400.git.tahia.khan%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
^ permalink raw reply
* Re: [PATCH 102/306] mac80211-hwsim: enable better rx-status when using netlink.
From: Johannes Berg @ 2017-02-24 6:38 UTC (permalink / raw)
To: greearb, linux-wireless
In-Reply-To: <1487896109-23851-4-git-send-email-greearb@candelatech.com>
> +/**
> + * This relates to the ieee80211_rx_status struct in mac80211.h
> + * @rx_flags: %RX_FLAG_* (see mac80211_rx_flags)
> + * @vht_flags: %RX_VHT_FLAG_*
> + * @vht_nss: number of streams (VHT only)
> + * @ampdu_reference: A-MPDU reference number, must be a different
> value for
> + * each A-MPDU but the same for each subframe within one A-
> MPDU
> + */
> +struct hwsim_rx_info {
> + u32 rx_flags;
> + u8 vht_flags;
> + u8 vht_nss;
> + u16 unused_pad; /* pad to 32-bits, and space for growth */
> + u32 ampdu_reference;
> +} __packed;
Same as in the previous patch.
johannes
^ permalink raw reply
* Re: [PATCH 101/306] mac80211-hwsim: Pass rate-ctrl flags and tx-power to user-space
From: Johannes Berg @ 2017-02-24 6:37 UTC (permalink / raw)
To: greearb, linux-wireless
In-Reply-To: <1487896109-23851-3-git-send-email-greearb@candelatech.com>
> +/* Auxilary info to allow user-space to better understand the rate
> */
> +struct hwsim_tx_rate2 {
> + u16 rc_flags; /* rate-ctrl flags (see
> mac80211_rate_control_flags) */
> + s16 power_level;
> +} __packed;
Nope, not going to happen - I'm not tying the user-space visible API to
the mac80211 internals that directly.
johannes
^ permalink raw reply
* Re: [PATCH 100/306] mac80211-hwsim: remove dmesg spam about get-survey.
From: Johannes Berg @ 2017-02-24 6:36 UTC (permalink / raw)
To: greearb, linux-wireless
In-Reply-To: <1487896109-23851-2-git-send-email-greearb@candelatech.com>
On Thu, 2017-02-23 at 16:28 -0800, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> This message just fills up dmesg and/or kernel logs and does
> not provide any useful information.
Fine, but don't just comment it out.
johannes
^ permalink raw reply
* [PATCH 3/3] mwifiex: wake system up when receives a wake irq
From: Jeffy Chen @ 2017-02-24 6:24 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Brian Norris, Rajat Jain, Jeffy Chen, Kalle Valo, netdev,
linux-wireless, linux-kernel, Nishant Sarmukadam
In-Reply-To: <1487917471-5501-1-git-send-email-jeffy.chen@rock-chips.com>
Currrently we are disabling this wake irq after receiving it. If this
happens before we finish suspend and the pm event check is disabled,
the system will continue suspending, and this irq would not work again.
We may need to abort system suspend to avoid that.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
---
drivers/net/wireless/marvell/mwifiex/main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index 5ebca1d..30f4994 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -17,6 +17,8 @@
* this warranty disclaimer.
*/
+#include <linux/suspend.h>
+
#include "main.h"
#include "wmm.h"
#include "cfg80211.h"
@@ -1509,6 +1511,7 @@ static irqreturn_t mwifiex_irq_wakeup_handler(int irq, void *priv)
/* Notify PM core we are wakeup source */
pm_wakeup_event(adapter->dev, 0);
+ pm_system_wakeup();
return IRQ_HANDLED;
}
--
2.1.4
^ permalink raw reply related
* [PATCH v3 3/3] staging: wilc1000: Rename network_info member str_rssi to rssi_history
From: Tahia Khan @ 2017-02-24 5:35 UTC (permalink / raw)
To: outreachy-kernel, aditya.shankar, ganesh.krishna, gregkh,
linux-wireless, devel, linux-kernel
In-Reply-To: <cover.1487912400.git.tahia.khan@gmail.com>
Change name of str_rssi to rssi_history within the network_info struct for clarity.
Signed-off-by: Tahia Khan <tahia.khan@gmail.com>
---
drivers/staging/wilc1000/coreconfigurator.h | 2 +-
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 14 +++++++-------
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/wilc1000/coreconfigurator.h b/drivers/staging/wilc1000/coreconfigurator.h
index 9712d89..10101f8 100644
--- a/drivers/staging/wilc1000/coreconfigurator.h
+++ b/drivers/staging/wilc1000/coreconfigurator.h
@@ -93,7 +93,7 @@ struct network_info {
u8 *ies;
u16 ies_len;
void *join_params;
- struct rssi_history_buffer str_rssi;
+ struct rssi_history_buffer rssi_history;
u64 tsf_hi;
};
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 9601ab8..4a6fe90 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -205,11 +205,11 @@ static u32 get_rssi_avg(struct network_info *network_info)
{
u8 i;
int rssi_v = 0;
- u8 num_rssi = (network_info->str_rssi.full) ?
- NUM_RSSI : (network_info->str_rssi.index);
+ u8 num_rssi = (network_info->rssi_history.full) ?
+ NUM_RSSI : (network_info->rssi_history.index);
for (i = 0; i < num_rssi; i++)
- rssi_v += network_info->str_rssi.samples[i];
+ rssi_v += network_info->rssi_history.samples[i];
rssi_v /= num_rssi;
return rssi_v;
@@ -346,13 +346,13 @@ static void add_network_to_shadow(struct network_info *pstrNetworkInfo,
} else {
ap_index = ap_found;
}
- rssi_index = last_scanned_shadow[ap_index].str_rssi.index;
- last_scanned_shadow[ap_index].str_rssi.samples[rssi_index++] = pstrNetworkInfo->rssi;
+ rssi_index = last_scanned_shadow[ap_index].rssi_history.index;
+ last_scanned_shadow[ap_index].rssi_history.samples[rssi_index++] = pstrNetworkInfo->rssi;
if (rssi_index == NUM_RSSI) {
rssi_index = 0;
- last_scanned_shadow[ap_index].str_rssi.full = true;
+ last_scanned_shadow[ap_index].rssi_history.full = true;
}
- last_scanned_shadow[ap_index].str_rssi.index = rssi_index;
+ last_scanned_shadow[ap_index].rssi_history.index = rssi_index;
last_scanned_shadow[ap_index].rssi = pstrNetworkInfo->rssi;
last_scanned_shadow[ap_index].cap_info = pstrNetworkInfo->cap_info;
last_scanned_shadow[ap_index].ssid_len = pstrNetworkInfo->ssid_len;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/3] staging: wilc1000: Rename tstrRSSI members and change type of u8Full to bool
From: Tahia Khan @ 2017-02-24 5:35 UTC (permalink / raw)
To: outreachy-kernel, aditya.shankar, ganesh.krishna, gregkh,
linux-wireless, devel, linux-kernel
In-Reply-To: <cover.1487912400.git.tahia.khan@gmail.com>
Remove Hungarian notation and camel casing from all tstrRSSI members' names.
Additionally, change type of u8Full to bool since it only takes values 1 or 0.
Signed-off-by: Tahia Khan <tahia.khan@gmail.com>
---
drivers/staging/wilc1000/coreconfigurator.h | 6 +++---
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 14 +++++++-------
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/wilc1000/coreconfigurator.h b/drivers/staging/wilc1000/coreconfigurator.h
index 1c77529..9712d89 100644
--- a/drivers/staging/wilc1000/coreconfigurator.h
+++ b/drivers/staging/wilc1000/coreconfigurator.h
@@ -71,9 +71,9 @@ enum connect_status {
};
struct rssi_history_buffer {
- u8 u8Full;
- u8 u8Index;
- s8 as8RSSI[NUM_RSSI];
+ bool full;
+ u8 index;
+ s8 samples[NUM_RSSI];
};
struct network_info {
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index f7ce47c..9601ab8 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -205,11 +205,11 @@ static u32 get_rssi_avg(struct network_info *network_info)
{
u8 i;
int rssi_v = 0;
- u8 num_rssi = (network_info->str_rssi.u8Full) ?
- NUM_RSSI : (network_info->str_rssi.u8Index);
+ u8 num_rssi = (network_info->str_rssi.full) ?
+ NUM_RSSI : (network_info->str_rssi.index);
for (i = 0; i < num_rssi; i++)
- rssi_v += network_info->str_rssi.as8RSSI[i];
+ rssi_v += network_info->str_rssi.samples[i];
rssi_v /= num_rssi;
return rssi_v;
@@ -346,13 +346,13 @@ static void add_network_to_shadow(struct network_info *pstrNetworkInfo,
} else {
ap_index = ap_found;
}
- rssi_index = last_scanned_shadow[ap_index].str_rssi.u8Index;
- last_scanned_shadow[ap_index].str_rssi.as8RSSI[rssi_index++] = pstrNetworkInfo->rssi;
+ rssi_index = last_scanned_shadow[ap_index].str_rssi.index;
+ last_scanned_shadow[ap_index].str_rssi.samples[rssi_index++] = pstrNetworkInfo->rssi;
if (rssi_index == NUM_RSSI) {
rssi_index = 0;
- last_scanned_shadow[ap_index].str_rssi.u8Full = 1;
+ last_scanned_shadow[ap_index].str_rssi.full = true;
}
- last_scanned_shadow[ap_index].str_rssi.u8Index = rssi_index;
+ last_scanned_shadow[ap_index].str_rssi.index = rssi_index;
last_scanned_shadow[ap_index].rssi = pstrNetworkInfo->rssi;
last_scanned_shadow[ap_index].cap_info = pstrNetworkInfo->cap_info;
last_scanned_shadow[ap_index].ssid_len = pstrNetworkInfo->ssid_len;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/3] staging: wilc1000: Rename struct tstrRSSI to rssi_history_buffer
From: Tahia Khan @ 2017-02-24 5:35 UTC (permalink / raw)
To: outreachy-kernel, aditya.shankar, ganesh.krishna, gregkh,
linux-wireless, devel, linux-kernel
In-Reply-To: <cover.1487912400.git.tahia.khan@gmail.com>
Rename struct tstrRSSI to rssi_history_buffer for clarity and to remove camel casing.
Signed-off-by: Tahia Khan <tahia.khan@gmail.com>
---
drivers/staging/wilc1000/coreconfigurator.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/wilc1000/coreconfigurator.h b/drivers/staging/wilc1000/coreconfigurator.h
index cff1698..1c77529 100644
--- a/drivers/staging/wilc1000/coreconfigurator.h
+++ b/drivers/staging/wilc1000/coreconfigurator.h
@@ -70,7 +70,7 @@ enum connect_status {
CONNECT_STS_FORCE_16_BIT = 0xFFFF
};
-struct tstrRSSI {
+struct rssi_history_buffer {
u8 u8Full;
u8 u8Index;
s8 as8RSSI[NUM_RSSI];
@@ -93,7 +93,7 @@ struct network_info {
u8 *ies;
u16 ies_len;
void *join_params;
- struct tstrRSSI str_rssi;
+ struct rssi_history_buffer str_rssi;
u64 tsf_hi;
};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/3] staging: wilc1000: multiple coding style changes to struct tstrRSSI
From: Tahia Khan @ 2017-02-24 5:34 UTC (permalink / raw)
To: outreachy-kernel, aditya.shankar, ganesh.krishna, gregkh,
linux-wireless, devel, linux-kernel
Multiple coding style changes to struct tstrRSSI. Initially reported by checkpath.pl:
Avoid CamelCase: <tstrRSSI>
Avoid CamelCase: <u8Full>
Avoid CamelCase: <u8Index>
Changes since v2: Renaming tstrRSSI and members with more descriptive names,
as suggested by Arend Van Spriel <arend.vanspriel@broadcom.com>
Tahia Khan (3):
staging: wilc1000: Rename struct tstrRSSI to rssi_history_buffer for
clarity and to remove camel casing.
staging: wilc1000: Remove Hungarian notation and camel casing from all
tstrRSSI members’ names. Additionally, change type of u8Full to bool
since it only takes values 1 or 0.
staging: wilc1000: Change name of str_rssi to rssi_history within the
network_info struct for clarity.
drivers/staging/wilc1000/coreconfigurator.h | 10 +++++-----
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 14 +++++++-------
2 files changed, 12 insertions(+), 12 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH v2] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules
From: Ryan Mounce @ 2017-02-24 2:50 UTC (permalink / raw)
To: Seth Forshee; +Cc: wireless-regdb, linux-wireless, Johannes Berg
In-Reply-To: <20170223153532.GA3479@ubuntu-hedt>
On 24 February 2017 at 02:05, Seth Forshee <seth.forshee@canonical.com> wrote:
> On Fri, Feb 24, 2017 at 12:22:53AM +1030, Ryan Mounce wrote:
>> Sourced from the current legislation at
>> https://www.legislation.gov.au/Details/F2016C00432
>>
>> The current rules exceed legal limits between 5250-5330MHz, and permit
>> illegal operation in 5600-5650MHz (disallowed regardless of DFS).
>>
>> Frequency ranges and EIRP limits for all ranges have been updated to
>> match items 59-63, 65 in the linked document. As the rules for AU have
>> never previously mirrored local regulations, changes include a
>> significant increase in the allowable 2.4GHz EIRP and smaller increases
>> in most other bands.
>>
>> In order to allow 80MHz operation between 5650-5730MHz (bordering two
>> bands) the lower, more restrictive band has been rounded up by 5MHz.
>>
>> Signed-off-by: Ryan Mounce <ryan@mounce.com.au>
>> ---
>> db.txt | 15 ++++++++++-----
>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/db.txt b/db.txt
>> index 05108e0..00e81b6 100644
>> --- a/db.txt
>> +++ b/db.txt
>> @@ -85,12 +85,17 @@ country AT: DFS-ETSI
>> # 60 GHz band channels 1-4, ref: Etsi En 302 567
>> (57000 - 66000 @ 2160), (40)
>>
>> +# Source:
>> +# https://www.legislation.gov.au/Details/F2016C00432
>> +# Both DFS-ETSI and DFS-FCC are acceptable per AS/NZS 4268 Appendix B
>> country AU: DFS-ETSI
>> - (2402 - 2482 @ 40), (20)
>> - (5170 - 5250 @ 80), (17), AUTO-BW
>> - (5250 - 5330 @ 80), (24), DFS, AUTO-BW
>> - (5490 - 5710 @ 160), (24), DFS
>> - (5735 - 5835 @ 80), (30)
>> + (2400 - 2483.5 @ 40), (36)
>
> The mention of ETSI EN 300 328 in item 55 (a) leads me to believe that
> this is the limit we should be using, i.e. 500 mW. It is a bit confusing
> though since it seems like such devices would also fall under "digital
> modulation transmitters."
Item 55 applies only to frequency hopping transmitters e.g. Bluetooth.
As a local, I can say with some degree of certainty that 4W/36dBm is
the correct 2.4GHz ISM EIRP for Australia. It is advertised as the
EIRP in the 802.11d IE of commercial devices e.g. Cisco Aironet APs
and widely deployed ISP gateways in Australia, among other devices
that have received relevant approvals.
>> + (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
>
> This looks correct.
>
>> + (5250 - 5350 @ 80), (23), NO-OUTDOOR, AUTO-BW, DFS
>
> Since this range requires TPC we need to set the power limit at 100 mW.
>
>> + (5470 - 5600 @ 80), (30), DFS
>> + (5650 - 5730 @ 80), (30), DFS
>
> These ranges also require TPC so we need to set the limit at 500 mW.
I was unsure about this one. Setting this to 27dBm also affects the
802.11d country information IE, however when the DFS flag is set a 3dB
802.11h power constraint IE is also advertised so stations will limit
themselves to (27-3)=24dBm/250mW.
Given the choice between unnecessarily halving transmit power on
stations and potentially transmitting at twice the permissible power
on APs without TPC I agree that the conservative approach should be
taken for now. Ideally I think that the actual EIRP limits should be
in the regdb and a 3dB constraint should be applied automatically on
APs that cannot support TPC when the DFS flag is set.
>> + (5730 - 5850 @ 80), (36)
>
> In the document the ranges are 5650-5725 MHz and 5725-5850 MHz. I
> suspect that the existing rules fudge that to line up with the wifi
> channels, which technically is okay because the rules in the former
> range are more restrictive. I wonder if we shouldn't be recording them
> here as per the document and adding AUTO-BW. Johannes, any thoughts?
I've tested with AUTO-BW and it doesn't work in this case as channel
144 will be disabled if it doesn't exist entirely within one band.
Fudging the more restrictive rules by a mere 5MHz to fit 802.11
channels seems to be the status quo.
>> + (57000 - 66000 @ 2160), (43), NO-OUTDOOR
>
> This looks correct.
>
> Thanks,
> Seth
Regards,
Ryan Mounce
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox