* Re: [PATCH] iwlwifi: add missing type declaration
From: Luca Coelho @ 2016-07-12 8:14 UTC (permalink / raw)
To: Arnd Bergmann, Johannes Berg, kvalo
Cc: Emmanuel Grumbach, Intel Linux Wireless, Kalle Valo, Eliad Peller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20160711205020.1587254-1-arnd@arndb.de>
On Mon, 2016-07-11 at 22:49 +0200, Arnd Bergmann wrote:
> The iwl-debug.h header relies in implicit inclusion of linux/device.h
> and
> we get a lot of warnings without that:
>
> drivers/net/wireless/intel/iwlwifi/iwl-debug.h:44:23: error: 'struct
> device' declared inside parameter list will not be visible outside of
> this definition or declaration [-Werror]
> void __iwl_err(struct device *dev, bool rfkill_prefix, bool
> only_trace,
> ^~~~~~
> In file included from drivers/net/wireless/intel/iwlwifi/iwl-eeprom-
> read.h:66:0,
> from drivers/net/wireless/intel/iwlwifi/iwl-eeprom-
> read.c:68:
> drivers/net/wireless/intel/iwlwifi/iwl-trans.h: In function
> 'iwl_trans_tx':
> drivers/net/wireless/intel/iwlwifi/iwl-trans.h:1030:348: error:
> passing argument 1 of '__iwl_err' from incompatible pointer type [-
> Werror=incompatible-pointer-types]
> IWL_ERR(trans, "%s bad state = %d\n", __func__, trans->state);
>
>
>
>
>
> ^
> In file included from drivers/net/wireless/intel/iwlwifi/iwl-eeprom-
> read.c:67:0:
> drivers/net/wireless/intel/iwlwifi/iwl-debug.h:44:6: note: expected
> 'struct device *' but argument is of type 'struct device *'
> void __iwl_err(struct device *dev, bool rfkill_prefix, bool
> only_trace,
> ^~~~~~~~~
>
> The easiest workaround is to just declare 'struct device' before its
> first use,
> rather than including the entire header file.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 21cb3222fe56 ("iwlwifi: decouple PCIe transport from
> mac80211")
> ---
Acked-by: Luca Coelho <luciano.coelho@intel.com>
Agree with Kalle that he will take this directly to wireless-drivers-
next.
--
Cheers,
Luca.
^ permalink raw reply
* Re: + maintainers-remove-unreachable-people-that-have-left-atmel.patch added to -mm tree
From: Luis de Bethencourt @ 2016-07-11 23:17 UTC (permalink / raw)
To: akpm, David Miller, mm-commits, Greg KH; +Cc: linux-wireless, nicolas.ferre
In-Reply-To: <578424eb.gTszFlACY5dPKGsR%akpm@linux-foundation.org>
On 11/07/16 23:59, akpm@linux-foundation.org wrote:
>
> The patch titled
> Subject: MAINTAINERS: remove unreachable people that have left Atmel
> has been added to the -mm tree. Its filename is
> maintainers-remove-unreachable-people-that-have-left-atmel.patch
>
> This patch should soon appear at
> http://ozlabs.org/~akpm/mmots/broken-out/maintainers-remove-unreachable-people-that-have-left-atmel.patch
> and later at
> http://ozlabs.org/~akpm/mmotm/broken-out/maintainers-remove-unreachable-people-that-have-left-atmel.patch
>
> Before you just go and hit "reply", please:
> a) Consider who else should be cc'ed
> b) Prefer to cc a suitable mailing list as well
> c) Ideally: find the original patch on the mailing list and do a
> reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> The -mm tree is included into linux-next and is updated
> there every 3-4 working days
>
> ------------------------------------------------------
> From: Luis de Bethencourt <luisbg@osg.samsung.com>
> Subject: MAINTAINERS: remove unreachable people that have left Atmel
>
> When sending an email regarding a patch to wilc1000, you get the following
> automatic replies:
> "Sung_hoon Cho is no longer with Atmel Corporation."
> "Kang_hee Park is no longer with Atmel Corporation."
> "Dong_ho Shin is no longer with Atmel Corporation."
> "Bo_moon Kim is no longer with Atmel Corporation."
> "Min_su Kim is no longer with Atmel Corporation."
> "Jun_hyuk Lee is no longer with Atmel Corporation."
>
> Removing this entry since none of the maintainers are reachable.
>
> Link: http://lkml.kernel.org/r/1467033373-20967-1-git-send-email-luisbg@osg.samsung.com
> Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
> Cc: Greg KH <greg@kroah.com>
> Cc: David Miller <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> MAINTAINERS | 11 -----------
> 1 file changed, 11 deletions(-)
>
> diff -puN MAINTAINERS~maintainers-remove-unreachable-people-that-have-left-atmel MAINTAINERS
> --- a/MAINTAINERS~maintainers-remove-unreachable-people-that-have-left-atmel
> +++ a/MAINTAINERS
> @@ -11131,17 +11131,6 @@ M: Forest Bond <forest@alittletooquiet.n
> S: Odd Fixes
> F: drivers/staging/vt665?/
>
> -STAGING - WILC1000 WIFI DRIVER
> -M: Johnny Kim <johnny.kim@atmel.com>
> -M: Austin Shin <austin.shin@atmel.com>
> -M: Chris Park <chris.park@atmel.com>
> -M: Tony Cho <tony.cho@atmel.com>
> -M: Glen Lee <glen.lee@atmel.com>
> -M: Leo Kim <leo.kim@atmel.com>
> -L: linux-wireless@vger.kernel.org
> -S: Supported
> -F: drivers/staging/wilc1000/
> -
> STAGING - XGI Z7,Z9,Z11 PCI DISPLAY DRIVER
> M: Arnaud Patard <arnaud.patard@rtp-net.org>
> S: Odd Fixes
> _
>
> Patches currently in -mm which might be from luisbg@osg.samsung.com are
>
> befs-check-return-of-sb_min_blocksize.patch
> befs-fix-function-name-in-documentation.patch
> befs-remove-unused-functions.patch
> maintainers-remove-unreachable-people-that-have-left-atmel.patch
>
Hi Andrew,
Nicolas Ferre proposed the following people instead in this reply patch:
https://lkml.org/lkml/2016/6/27/382
Sounds better than making the driver orphan. But I am not sure if this has
been approved by Greg or not. Just a heads up since I thought you might want
to know.
Thanks,
Luis
^ permalink raw reply
* Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets
From: Igor Mitsyanko @ 2016-07-11 18:57 UTC (permalink / raw)
To: Johannes Berg, kvalo
Cc: linux-wireless, Avinash Patil, Dmitrii Lebed, Sergei Maksimenko,
Sergey Matyukevich, Bindu Therthala, Huizhao Wang, Kamlesh Rath
In-Reply-To: <1466511726.3170.33.camel@sipsolutions.net>
Hi Johannes,
thank for review and sorry for long delays in replies. A parallel thread
with Dave a discussion was initiated regarding HW platform samples
availability. Current driver implementation supports a newer QSR10G
platform, which availability is limited due to the platform still being
in development stage. We're working on supporting Quantenna's current
QSR1000 platform too, what would be the best approach to this:
- have QSR1000 platform support ready, amend it to current patch and
post it as a new patch revision (there should be a certain amount of new
code);
- have current patch accepted by community first, and then post a new
patch (adding new platform support) one on top of it.
More answers bellow.
On 06/21/2016 03:22 PM, Johannes Berg wrote:
> Very brief review:
>
>> +/* */
> That seems slightly odd.
Will remove.
>
>> + /* 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.
Right, thanks for pointing this out. Probably even better approach here
would be to take an object-oriented approach and make "bus" a base
structure with pcie_bus an inheriting structure.
>
>> +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.
Ok
>
>> +#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)
The idea was to make protocol definition an independent entity, which
does not depend on actual values which happened to be used in current
kernel. And so that we can be sure that both sides of protocol
communication entities use the same length values.
We actually had discussions regarding this locally too: it was not clear
whether we should use existing Linux definitions for standard things
like MAC length, 802.11 header fields, IEs definitions etc. It does make
a lot of sense to think that they will never change and can not be
different on opposite sides of protocol, but we went with approach to
define everything manually.
>
>> +/*
>> + * 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
Ok, that makes sense of course. Will discuss this locally.
>
>
>> +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?
You're right, will change to simple enumeration.
>
>> +/**
>> + * 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.
Ok
>
>> + 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?
COMMAND_SEND/REPLY_PROCESS procedure is "atomic" in the driver, meaning
once one command is sent, next one will not be sent until previous
command response is received and processed completely (we rely on RTNL
mutex taken by cfg80211 layer here). Currently every command requires a
response.
In this particular case QTNF_STATE_AP_START will be set only after a
response for send_start_ap is received and response indicated successful
command execution by another side.
>
>> +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?
Agree
>
>> + 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.
In this particular place we're making a local copy of cfg80211 struct to
local data structure (per each virtual interface). Conversion before
sending to another side is done in qtnf_cmd_send_connect(), it is
converted into struct qlink_auth_encr.
>
> [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.
Ok, got it.
>
>> +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.
Will change to existing ones.
>
> [snip more]
>
> johannes
^ permalink raw reply
* Re: [PATCH v4 1/3] Documentation: dt: net: add ath9k wireless device binding
From: Martin Blumenstingl @ 2016-07-11 21:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: ath9k-devel, devicetree, linux-wireless, ath9k-devel, mcgrof,
galak, ijc+devicetree, mark.rutland, pawel.moll, robh+dt, kvalo,
chunkeey, arend.vanspriel, julian.calaby
In-Reply-To: <1877260.9mAQ7eY9me@wuerfel>
On Mon, Jul 11, 2016 at 12:01 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> ath9k reads the data from the EEPROM into memory. With that property
>> disabled ath9k simply assumes that the endianness of the values in the
>> EEPROM are having the correct endianness for the host system (in other
>> words: no swap is being applied).
>> I am not sure I understand you correctly, but isn't what you are
>> explaining an issue in the ath9k code, rather than in this
>> documentation?
>
> I looked at the code more to find that out now, but I'm more confused
> now, as the eeprom seems to be read as a byte stream, and the endianess
> conversion that the driver performs is not on the data values in it,
> but seems to instead swap the bytes in each 16-bit word, regardless
> of the contents (the values inside of the byte stream are always
> interpreted as big-endian). Is that a correct observation?
that seems to be the case for the ar9003 eeprom. Other implementations
are doing it different, look at ath9k_hw_ar9287_check_eeprom for
example: first ath9k_hw_nvram_swap_data checks the two magic bytes at
the beginning of the data and swaps the bytes in each 16-bit word if
the magic bytes don't match the magic bytes for the "native system
endianness" (see AR5416_EEPROM_MAGIC). Then more swapping is applied.
I asked for more details about the EEPROM format (specifically the
endianness part) here [0] as I don't have access to the datasheets
(all I have is the ath9k code)
> What I see in ath_pci_eeprom_read() is that the 16-bit words are taken
> from the lower 16 bit of the little-endian AR_EEPROM_STATUS_DATA
> register. As this is coming from a PCI register, it must have a device
> specific endianess that is identical on all CPUs, so in the description
> above, mentioning CPU endianess is a bit confusing. I could not find
> the code that does the conditional byteswap, instead this function
>
> static bool ar9300_eeprom_read_byte(struct ath_hw *ah, int address,
> u8 *buffer)
> {
> u16 val;
>
> if (unlikely(!ath9k_hw_nvram_read(ah, address / 2, &val)))
> return false;
>
> *buffer = (val >> (8 * (address % 2))) & 0xff;
> return true;
> }
>
> evidently assumes that the lower 8 bit of the 16-bit data from PCI
> come first, i.e. it byteswaps on big-endian CPUs to get the bytestream
> back into the order in which it is stored in the EEPROM.
Please have a look at the ath9k_hw_nvram_swap_data function and
eeprom_ops.check_eeprom (for example ath9k_hw_ar9287_check_eeprom).
These are performing the conditional swapping (in addition to whatever
previous swapping there was).
The basic code works like this: read the full EEPROM data into memory
(either from PCI bus, ath9k_platform_data or request_firmware), then
eeprom_ops.check_eeprom will call ath9k_hw_nvram_swap_data for 16-bit
word swapping and afterwards the check_eeprom implementation will doe
further swapping.
Apart from that your findings seem correct (at least this is identical
to how I would interpret the code).
> Interestingly, this also seems to happen for ath_ahb_eeprom_read()
> even though on that one the value does not get swapped by the bus
> accessor, so presumably big-endian machines with a ahb based ath9k
> store their eeprom byte-reversed?
on AHB the eeprom data has to be provided via ath9k_platform_data /
request_firmware mechanism. Thus there is no bus specific swapping,
only the ath9k_hw_nvram_swap_data / eeprom_ops.check_eeprom swapping
is applied in this case.
[0] http://thread.gmane.org/gmane.linux.kernel.wireless.general/153569
^ permalink raw reply
* [PATCH FIX 4.6+] bcma: add PCI ID for Foxconn's BCM43142 device
From: Rafał Miłecki @ 2016-07-11 21:01 UTC (permalink / raw)
To: Kalle Valo
Cc: Igor Mammedov, Rafał Miłecki, Stable,
open list:BROADCOM SPECIFIC AMBA DRIVER (BCMA), open list
After discovering there are 2 very different 14e4:4365 PCI devices we
made ID tables less generic. Back then we believed there are only 2 such
devices:
1) 14e4:4365 1028:0016 with SoftMAC BCM43142 chipset
2) 14e4:4365 14e4:4365 with FullMAC BCM4366 chipset
>From the recent report it appears there is also 14e4:4365 105b:e092
which should be claimed by bcma. Add back support for it.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=121881
Fixes: 515b399c9a20 ("bcma: claim only 14e4:4365 PCI Dell card with SoftMAC BCM43142")
Reported-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Cc: Stable <stable@vger.kernel.org> [4.6+]
---
drivers/bcma/host_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bcma/host_pci.c b/drivers/bcma/host_pci.c
index cae5385..bd46569 100644
--- a/drivers/bcma/host_pci.c
+++ b/drivers/bcma/host_pci.c
@@ -295,6 +295,7 @@ static const struct pci_device_id bcma_pci_bridge_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4359) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4360) },
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_BROADCOM, 0x4365, PCI_VENDOR_ID_DELL, 0x0016) },
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_BROADCOM, 0x4365, PCI_VENDOR_ID_FOXCONN, 0xe092) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x43a0) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x43a9) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x43aa) },
--
1.8.4.5
^ permalink raw reply related
* Re: [PATCH][V2] nfp: check idx is -ENOSPC before using it is an index
From: David Miller @ 2016-07-11 20:52 UTC (permalink / raw)
To: colin.king
Cc: jakub.kicinski, lauro.venancio, aloisio.almeida, sameo,
rolf.neugebauer, christophe.ricard, robert.dolca, oss-drivers,
netdev, linux-wireless
In-Reply-To: <1468252460-15117-1-git-send-email-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Mon, 11 Jul 2016 16:54:20 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> idx can be returned as -ENOSPC, so we should check for this first
> before using it as an index into nn->vxlan_usecnt[] to avoid an
> out of bounds array offset read.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied to net-next.
^ permalink raw reply
* [PATCH] iwlwifi: add missing type declaration
From: Arnd Bergmann @ 2016-07-11 20:49 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Kalle Valo, Eliad Peller, linux-wireless,
netdev, linux-kernel
The iwl-debug.h header relies in implicit inclusion of linux/device.h and
we get a lot of warnings without that:
drivers/net/wireless/intel/iwlwifi/iwl-debug.h:44:23: error: 'struct device' declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
void __iwl_err(struct device *dev, bool rfkill_prefix, bool only_trace,
^~~~~~
In file included from drivers/net/wireless/intel/iwlwifi/iwl-eeprom-read.h:66:0,
from drivers/net/wireless/intel/iwlwifi/iwl-eeprom-read.c:68:
drivers/net/wireless/intel/iwlwifi/iwl-trans.h: In function 'iwl_trans_tx':
drivers/net/wireless/intel/iwlwifi/iwl-trans.h:1030:348: error: passing argument 1 of '__iwl_err' from incompatible pointer type [-Werror=incompatible-pointer-types]
IWL_ERR(trans, "%s bad state = %d\n", __func__, trans->state);
^
In file included from drivers/net/wireless/intel/iwlwifi/iwl-eeprom-read.c:67:0:
drivers/net/wireless/intel/iwlwifi/iwl-debug.h:44:6: note: expected 'struct device *' but argument is of type 'struct device *'
void __iwl_err(struct device *dev, bool rfkill_prefix, bool only_trace,
^~~~~~~~~
The easiest workaround is to just declare 'struct device' before its first use,
rather than including the entire header file.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 21cb3222fe56 ("iwlwifi: decouple PCIe transport from mac80211")
---
drivers/net/wireless/intel/iwlwifi/iwl-debug.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-debug.h b/drivers/net/wireless/intel/iwlwifi/iwl-debug.h
index 110333208450..cd77c6971753 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-debug.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-debug.h
@@ -41,6 +41,7 @@ static inline bool iwl_have_debug_level(u32 level)
#endif
}
+struct device;
void __iwl_err(struct device *dev, bool rfkill_prefix, bool only_trace,
const char *fmt, ...) __printf(4, 5);
void __iwl_warn(struct device *dev, const char *fmt, ...) __printf(2, 3);
--
2.9.0
^ permalink raw reply related
* Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded
From: Prarit Bhargava @ 2016-07-11 20:31 UTC (permalink / raw)
To: Grumbach, Emmanuel
Cc: linux-kernel@vger.kernel.org, linuxwifi, Coelho, Luciano,
Berg, Johannes, kvalo@codeaurora.org, Ivgi, Chaya Rachel,
netdev@vger.kernel.org, Sharon, Sara,
linux-wireless@vger.kernel.org
In-Reply-To: <1468261650.20877.14.camel@intel.com>
On 07/11/2016 02:27 PM, Grumbach, Emmanuel wrote:
> On Mon, 2016-07-11 at 14:19 -0400, Prarit Bhargava wrote:
>>
>> On 07/11/2016 02:00 PM, Emmanuel Grumbach wrote:
>>> On Mon, Jul 11, 2016 at 6:18 PM, Prarit Bhargava <prarit@redhat.com
>>>> wrote:
>>>>
>>>> Didn't get any feedback or review comments on this patch.
>>>> Resending ...
>>>>
>>>> P.
>>>
>>> This change is obviously completely broken. It simply disables the
>>> registration to thermal zone core.
>>
>> No it is not broken, and yes, that is exactly what should happen IMO.
>>
>> The problem is that the iwlwifi driver implements the thermal zone
>> even when the
>> device doesn't support it.
>
> We implement thermal zone because we do support it, but the problem is
> that we need the firmware to be loaded for that. So you can argue that
> we should register *later* when the firmware is loaded. But this is
> really not helping all that much because the firmware can also be
> stopped at any time. So you'd want us to register / unregister the
> thermal zone anytime the firmware is loaded / unloaded?
You might have to do that. I think that if the firmware enables a feature then
the act of loading the firmware should run the code that enables the feature.
IMO of course.
> I guess that works, but it seems wrong to me. Usually, registration
> should happen only upon INIT, and yes, at that time the firmware is not
> ready to provide the information yet.
> Maybe returning -EBUSY would help lm-sensors not to get confused?
I'll give that a shot, but I expect that won't work either as an error message
will still be displayed.
>
>>
>> As can be seen in the current code base, iwl_mvm_tzone_get_temp()
>> will return
>> -EIO 100% of the time when the firmware doesn't support reading the
>> temperature[1]. In this case a read of sysfs will result in a return
>> of -EIO,
>> and this breaks existing userspace programs such as lm-sensors (which
>> by all
>> accounts is bad to do).
>
> Right, but I don't understand why the userspace is broken because of
> that?
Before the iwlwifi change, sensors successfully returned. Now, because of the
error, it doesn't.
Unless we register / unregister anytime the firmware is loaded, I
> don't see any proper way to fix this. And yes, I'd expect the userspace
> to handle gracefully failures in its requests.
I agree with you in principle *and there's a great many things I wish userspace
would do gracefully* but updating the kernel shouldn't result in userspace
programs failing.
>
>>
>> Note that in my patch I have removed the -EIO return in favor of not
>> registering
>> the non-existent thermal zone. I'm not removing any functionality by
>> changing
>> this, nor am I adding functionality. In both cases the thermal zone
>> is not
>> functional, and with my patch userspace continues to work.
>
> You are removing the thermal zone functionality since even when the
> firmware will be loaded (which typically happens fairly quickly),
> thermal zone won't work.
Then I agree with your suggestion above that you need to enable the thermal zone
on a successful load of the firmware. [Aside: I wonder what other drivers do in
this situation? While this does seem like an odd case, I can't believe that the
iwlwifi driver is the only driver to enable features based on firmware.]
P.
^ permalink raw reply
* Re: pull request: new firmware files for all mvm wireless devices
From: Kyle McMartin @ 2016-07-11 18:57 UTC (permalink / raw)
To: Grumbach, Emmanuel; +Cc: linux-wireless@vger.kernel.org, linux-firmware
In-Reply-To: <1468164649.8394.3.camel@intel.com>
On Sun, Jul 10, 2016 at 03:30:49PM +0000, Grumbach, Emmanuel wrote:
> Hi Kyle,
>
> Intel is releasing new firmware versions for all its mvm wireless
> devices.
> For devices 7260, 7265 and 3160, this is the last firmware updates. We
> may still have critical bug fixes, but those won't get any new major
> releases. They will stay with -17.ucode.
> For 7265D and up, we release here the -22.ucode version.
>
> Please pull.
>
> Thanks!
>
> The following changes since commit a14150061388f4bcbf3c3499f1b12e3f0d5c0e7b:
>
> linux-firmware: Fix the filename for WsP to align with device HW_VARIANT (2016-07-08 18:07:02 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git tags/iwlwifi-fw-2016-07-10
Pulled, thanks Emmanuel.
regards, --Kyle
>
> for you to fetch changes up to b224bd0c77370a58b996a7be2c322b9fb4849398:
>
> iwlwifi: add new -22 firmware for 7265D and up (2016-07-10 09:41:14 +0300)
>
> ----------------------------------------------------------------
> Release -21.ucode for 7265D and up
> Release -17.ucode for 7260 / 7265 and 3160
>
> ----------------------------------------------------------------
> Emmanuel Grumbach (2):
> iwlwifi: add new -17 firmware for iwlmvm devices
> iwlwifi: add new -22 firmware for 7265D and up
>
> WHENCE | 24 ++++++++++++++++++++++++
> iwlwifi-3160-17.ucode | Bin 0 -> 918268 bytes
> iwlwifi-3168-22.ucode | Bin 0 -> 1028032 bytes
> iwlwifi-7260-17.ucode | Bin 0 -> 1049340 bytes
> iwlwifi-7265-17.ucode | Bin 0 -> 1180412 bytes
> iwlwifi-7265D-17.ucode | Bin 0 -> 1383604 bytes
> iwlwifi-7265D-22.ucode | Bin 0 -> 1028316 bytes
> iwlwifi-8000C-22.ucode | Bin 0 -> 2120860 bytes
> iwlwifi-8265-22.ucode | Bin 0 -> 1811984 bytes
> 9 files changed, 24 insertions(+)
> create mode 100644 iwlwifi-3160-17.ucode
> create mode 100644 iwlwifi-3168-22.ucode
> create mode 100644 iwlwifi-7260-17.ucode
> create mode 100644 iwlwifi-7265-17.ucode
> create mode 100644 iwlwifi-7265D-17.ucode
> create mode 100644 iwlwifi-7265D-22.ucode
> create mode 100644 iwlwifi-8000C-22.ucode
> create mode 100644 iwlwifi-8265-22.ucode
>
> diff --git a/WHENCE b/WHENCE
> index c3d98f6..4c41f21 100644
> --- a/WHENCE
> +++ b/WHENCE
> @@ -848,6 +848,9 @@ Version: 25.30.13.0
> File: iwlwifi-7260-16.ucode
> Version 16.242414.0
>
> +File: iwlwifi-7260-17.ucode
> +Version 17.352738.0
> +
> File: iwlwifi-3160-7.ucode
> Version: 22.1.7.0
>
> @@ -869,6 +872,9 @@ Version: 25.30.13.0
> File: iwlwifi-3160-16.ucode
> Version 16.242414.0
>
> +File: iwlwifi-3160-17.ucode
> +Version 17.352738.0
> +
> File: iwlwifi-7265-8.ucode
> Version: 22.24.8.0
>
> @@ -887,6 +893,9 @@ Version: 25.30.13.0
> File: iwlwifi-7265-16.ucode
> Version 16.242414.0
>
> +File: iwlwifi-7265-17.ucode
> +Version 17.352738.0
> +
> File: iwlwifi-7265D-10.ucode
> Version: 23.15.10.0
>
> @@ -899,12 +908,21 @@ Version: 25.30.13.0
> File: iwlwifi-7265D-16.ucode
> Version 16.242414.0
>
> +File: iwlwifi-7265D-17.ucode
> +Version 17.352738.0
> +
> File: iwlwifi-7265D-21.ucode
> Version 21.302800.0
>
> +File: iwlwifi-7265D-22.ucode
> +Version 22.361476.0
> +
> File: iwlwifi-3168-21.ucode
> Version 21.302800.0
>
> +File: iwlwifi-3168-22.ucode
> +Version 22.361476.0
> +
> File: iwlwifi-8000C-13.ucode
> Version: 25.30.13.0
>
> @@ -914,9 +932,15 @@ Version 16.242414.0
> File: iwlwifi-8000C-21.ucode
> Version 21.302800.0
>
> +File: iwlwifi-8000C-22.ucode
> +Version 22.361476.0
> +
> File: iwlwifi-8265-21.ucode
> Version 21.302800.0
>
> +File: iwlwifi-8265-22.ucode
> +Version 22.361476.0
> +
> Licence: Redistributable. See LICENCE.iwlwifi_firmware for details
>
> Also available from http://wireless.kernel.org/en/users/Drivers/iwlwifi#Firmware
> diff --git a/iwlwifi-3160-17.ucode b/iwlwifi-3160-17.ucode
> new file mode 100644
> index 0000000..e58f715
> Binary files /dev/null and b/iwlwifi-3160-17.ucode differ
> diff --git a/iwlwifi-3168-22.ucode b/iwlwifi-3168-22.ucode
> new file mode 100644
> index 0000000..d969aed
> Binary files /dev/null and b/iwlwifi-3168-22.ucode differ
> diff --git a/iwlwifi-7260-17.ucode b/iwlwifi-7260-17.ucode
> new file mode 100644
> index 0000000..6f5d713
> Binary files /dev/null and b/iwlwifi-7260-17.ucode differ
> diff --git a/iwlwifi-7265-17.ucode b/iwlwifi-7265-17.ucode
> new file mode 100644
> index 0000000..f2bf30e
> Binary files /dev/null and b/iwlwifi-7265-17.ucode differ
> diff --git a/iwlwifi-7265D-17.ucode b/iwlwifi-7265D-17.ucode
> new file mode 100644
> index 0000000..66940c4
> Binary files /dev/null and b/iwlwifi-7265D-17.ucode differ
> diff --git a/iwlwifi-7265D-22.ucode b/iwlwifi-7265D-22.ucode
> new file mode 100644
> index 0000000..26ca1bd
> Binary files /dev/null and b/iwlwifi-7265D-22.ucode differ
> diff --git a/iwlwifi-8000C-22.ucode b/iwlwifi-8000C-22.ucode
> new file mode 100644
> index 0000000..93a828b
> Binary files /dev/null and b/iwlwifi-8000C-22.ucode differ
> diff --git a/iwlwifi-8265-22.ucode b/iwlwifi-8265-22.ucode
> new file mode 100644
> index 0000000..3dbeb83
> Binary files /dev/null and b/iwlwifi-8265-22.ucode differ
^ permalink raw reply
* Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded
From: Grumbach, Emmanuel @ 2016-07-11 18:27 UTC (permalink / raw)
To: prarit@redhat.com
Cc: linux-kernel@vger.kernel.org, linuxwifi, Coelho, Luciano,
Berg, Johannes, kvalo@codeaurora.org, Ivgi, Chaya Rachel,
netdev@vger.kernel.org, Sharon, Sara,
linux-wireless@vger.kernel.org
In-Reply-To: <5783E33E.7090205@redhat.com>
T24gTW9uLCAyMDE2LTA3LTExIGF0IDE0OjE5IC0wNDAwLCBQcmFyaXQgQmhhcmdhdmEgd3JvdGU6
DQo+IA0KPiBPbiAwNy8xMS8yMDE2IDAyOjAwIFBNLCBFbW1hbnVlbCBHcnVtYmFjaCB3cm90ZToN
Cj4gPiBPbiBNb24sIEp1bCAxMSwgMjAxNiBhdCA2OjE4IFBNLCBQcmFyaXQgQmhhcmdhdmEgPHBy
YXJpdEByZWRoYXQuY29tDQo+ID4gPiB3cm90ZToNCj4gPiA+IA0KPiA+ID4gRGlkbid0IGdldCBh
bnkgZmVlZGJhY2sgb3IgcmV2aWV3IGNvbW1lbnRzIG9uIHRoaXMgcGF0Y2guIA0KPiA+ID4gIFJl
c2VuZGluZyAuLi4NCj4gPiA+IA0KPiA+ID4gUC4NCj4gPiANCj4gPiBUaGlzIGNoYW5nZSBpcyBv
YnZpb3VzbHkgY29tcGxldGVseSBicm9rZW4uIEl0IHNpbXBseSBkaXNhYmxlcyB0aGUNCj4gPiBy
ZWdpc3RyYXRpb24gdG8gdGhlcm1hbCB6b25lIGNvcmUuDQo+IA0KPiBObyBpdCBpcyBub3QgYnJv
a2VuLCBhbmQgeWVzLCB0aGF0IGlzIGV4YWN0bHkgd2hhdCBzaG91bGQgaGFwcGVuIElNTy4NCj4g
DQo+IFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIGl3bHdpZmkgZHJpdmVyIGltcGxlbWVudHMgdGhl
IHRoZXJtYWwgem9uZQ0KPiBldmVuIHdoZW4gdGhlDQo+IGRldmljZSBkb2Vzbid0IHN1cHBvcnQg
aXQuDQoNCldlIGltcGxlbWVudCB0aGVybWFsIHpvbmUgYmVjYXVzZSB3ZSBkbyBzdXBwb3J0IGl0
LCBidXQgdGhlIHByb2JsZW0gaXMNCnRoYXQgd2UgbmVlZCB0aGUgZmlybXdhcmUgdG8gYmUgbG9h
ZGVkIGZvciB0aGF0LiBTbyB5b3UgY2FuIGFyZ3VlIHRoYXQNCndlIHNob3VsZCByZWdpc3RlciAq
bGF0ZXIqIHdoZW4gdGhlIGZpcm13YXJlIGlzIGxvYWRlZC4gQnV0IHRoaXMgaXMNCnJlYWxseSBu
b3QgaGVscGluZyBhbGwgdGhhdCBtdWNoIGJlY2F1c2UgdGhlIGZpcm13YXJlIGNhbiBhbHNvIGJl
DQpzdG9wcGVkIGF0IGFueSB0aW1lLiBTbyB5b3UnZCB3YW50IHVzIHRvIHJlZ2lzdGVyIC8gdW5y
ZWdpc3RlciB0aGUNCnRoZXJtYWwgem9uZSBhbnl0aW1lIHRoZSBmaXJtd2FyZSBpcyBsb2FkZWQg
LyB1bmxvYWRlZD8NCkkgZ3Vlc3MgdGhhdCB3b3JrcywgYnV0IGl0IHNlZW1zIHdyb25nIHRvIG1l
LiBVc3VhbGx5LCByZWdpc3RyYXRpb24NCnNob3VsZCBoYXBwZW4gb25seSB1cG9uIElOSVQsIGFu
ZCB5ZXMsIGF0IHRoYXQgdGltZSB0aGUgZmlybXdhcmUgaXMgbm90DQpyZWFkeSB0byBwcm92aWRl
IHRoZSBpbmZvcm1hdGlvbiB5ZXQuDQpNYXliZSByZXR1cm5pbmcgLUVCVVNZIHdvdWxkIGhlbHAg
bG0tc2Vuc29ycyBub3QgdG8gZ2V0IGNvbmZ1c2VkPw0KDQo+IA0KPiBBcyBjYW4gYmUgc2VlbiBp
biB0aGUgY3VycmVudCBjb2RlIGJhc2UsIGl3bF9tdm1fdHpvbmVfZ2V0X3RlbXAoKQ0KPiB3aWxs
IHJldHVybg0KPiAtRUlPIDEwMCUgb2YgdGhlIHRpbWUgd2hlbiB0aGUgZmlybXdhcmUgZG9lc24n
dCBzdXBwb3J0IHJlYWRpbmcgdGhlDQo+IHRlbXBlcmF0dXJlWzFdLiAgSW4gdGhpcyBjYXNlIGEg
cmVhZCBvZiBzeXNmcyB3aWxsIHJlc3VsdCBpbiBhIHJldHVybg0KPiBvZiAtRUlPLA0KPiBhbmQg
dGhpcyBicmVha3MgZXhpc3RpbmcgdXNlcnNwYWNlIHByb2dyYW1zIHN1Y2ggYXMgbG0tc2Vuc29y
cyAod2hpY2gNCj4gYnkgYWxsDQo+IGFjY291bnRzIGlzIGJhZCB0byBkbykuDQoNClJpZ2h0LCBi
dXQgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB0aGUgdXNlcnNwYWNlIGlzIGJyb2tlbiBiZWNhdXNl
IG9mDQp0aGF0PyBVbmxlc3Mgd2UgcmVnaXN0ZXIgLyB1bnJlZ2lzdGVyIGFueXRpbWUgdGhlIGZp
cm13YXJlIGlzIGxvYWRlZCwgSQ0KZG9uJ3Qgc2VlIGFueSBwcm9wZXIgd2F5IHRvIGZpeCB0aGlz
LiBBbmQgeWVzLCBJJ2QgZXhwZWN0IHRoZSB1c2Vyc3BhY2UNCnRvIGhhbmRsZSBncmFjZWZ1bGx5
IGZhaWx1cmVzIGluIGl0cyByZXF1ZXN0cy4NCg0KPiANCj4gTm90ZSB0aGF0IGluIG15IHBhdGNo
IEkgaGF2ZSByZW1vdmVkIHRoZSAtRUlPIHJldHVybiBpbiBmYXZvciBvZiBub3QNCj4gcmVnaXN0
ZXJpbmcNCj4gdGhlIG5vbi1leGlzdGVudCB0aGVybWFsIHpvbmUuICBJJ20gbm90IHJlbW92aW5n
IGFueSBmdW5jdGlvbmFsaXR5IGJ5DQo+IGNoYW5naW5nDQo+IHRoaXMsIG5vciBhbSBJIGFkZGlu
ZyBmdW5jdGlvbmFsaXR5LiAgSW4gYm90aCBjYXNlcyB0aGUgdGhlcm1hbCB6b25lDQo+IGlzIG5v
dA0KPiBmdW5jdGlvbmFsLCBhbmQgd2l0aCBteSBwYXRjaCB1c2Vyc3BhY2UgY29udGludWVzIHRv
IHdvcmsuDQoNCllvdSBhcmUgcmVtb3ZpbmcgdGhlIHRoZXJtYWwgem9uZSBmdW5jdGlvbmFsaXR5
IHNpbmNlIGV2ZW4gd2hlbiB0aGUNCmZpcm13YXJlIHdpbGwgYmUgbG9hZGVkICh3aGljaCB0eXBp
Y2FsbHkgaGFwcGVucyBmYWlybHkgcXVpY2tseSksDQp0aGVybWFsIHpvbmUgd29uJ3Qgd29yay4N
Cg0KPiANCj4gUC4NCj4gDQo+IFsxXSBpd2xfbXZtX3R6b25lX3NldF90cmlwX3RlbXAoKSBhbHNv
IHJldHVybnMgLUVJTywgc28gc2V0dGluZyBhbmQNCj4gZ2V0dGluZyBvZg0KPiB0aGUgdGVtcGVy
YXR1cmUgaXMgbm9uLWZ1bmN0aW9uYWwuDQo+IA0KPiANCj4gPiANCj4gPiA+IA0KPiA+ID4gLS0t
ODwtLS0NCj4gPiA+IA0KPiA+ID4gVGhlIGl3bHdpZmkgZHJpdmVyIGltcGxlbWVudHMgYSB0aGVy
bWFsIHpvbmUgYW5kIGh3bW9uIGRldmljZSwNCj4gPiA+IGJ1dA0KPiA+ID4gcmV0dXJucyAtRUlP
IG9uIHRlbXBlcmF0dXJlIHJlYWRzIGlmIHRoZSBmaXJtd2FyZSBpc24ndCBsb2FkZWQuIA0KPiA+
ID4gIFRoaXMNCj4gPiA+IHJlc3VsdHMgaW4gdGhlIGVycm9yDQo+ID4gPiANCj4gPiA+IGl3bHdp
ZmktdmlydHVhbC0wDQo+ID4gPiBBZGFwdGVyOiBWaXJ0dWFsIGRldmljZQ0KPiA+ID4gRVJST1I6
IENhbid0IGdldCB2YWx1ZSBvZiBzdWJmZWF0dXJlIHRlbXAxX2lucHV0OiBJL08gZXJyb3INCj4g
PiA+IHRlbXAxOiAgICAgICAgICAgIE4vQQ0KPiA+ID4gDQo+ID4gPiBiZWluZyBvdXRwdXQgd2hl
biB1c2luZyBzZW5zb3JzIGZyb20gdGhlIGxtLXNlbnNvcnMgcGFja2FnZS4gDQo+ID4gPiAgU2lu
Y2UNCj4gPiA+IHRoZSB0ZW1wZXJhdHVyZSBjYW5ub3QgYmUgcmVhZCB1bmxlc3MgdGhlIHVjb2Rl
IGlzIGxvYWRlZCB0aGVyZQ0KPiA+ID4gaXMgbm8NCj4gPiA+IHJlYXNvbiB0byBhZGQgdGhlIGlu
dGVyZmFjZSBvbmx5IHRvIGhhdmUgaXQgcmV0dXJuIGFuIGVycm9yIDEwMCUNCj4gPiA+IG9mDQo+
ID4gPiB0aGUgdGltZS4NCj4gPiA+IA0KPiA+ID4gVGhpcyBwYXRjaCBtb3ZlcyB0aGUgZmlybXdh
cmUgY2hlY2sgdG8NCj4gPiA+IGl3bF9tdm1fdGhlcm1hbF96b25lX3JlZ2lzdGVyKCkgYW5kDQo+
ID4gPiBzdG9wcyB0aGUgdGhlcm1hbCB6b25lIGZyb20gYmVpbmcgY3JlYXRlZCBpZiB0aGUgdWNv
ZGUgaGFzbid0DQo+ID4gPiBiZWVuIGxvYWRlZC4NCj4gPiA+IA0KPiA+ID4gU2lnbmVkLW9mZi1i
eTogUHJhcml0IEJoYXJnYXZhIDxwcmFyaXRAcmVkaGF0LmNvbT4NCj4gPiA+IENjOiBKb2hhbm5l
cyBCZXJnIDxqb2hhbm5lcy5iZXJnQGludGVsLmNvbT4NCj4gPiA+IENjOiBFbW1hbnVlbCBHcnVt
YmFjaCA8ZW1tYW51ZWwuZ3J1bWJhY2hAaW50ZWwuY29tPg0KPiA+ID4gQ2M6IEx1Y2EgQ29lbGhv
IDxsdWNpYW5vLmNvZWxob0BpbnRlbC5jb20+DQo+ID4gPiBDYzogSW50ZWwgTGludXggV2lyZWxl
c3MgPGxpbnV4d2lmaUBpbnRlbC5jb20+DQo+ID4gPiBDYzogS2FsbGUgVmFsbyA8a3ZhbG9AY29k
ZWF1cm9yYS5vcmc+DQo+ID4gPiBDYzogQ2hheWEgUmFjaGVsIEl2Z2kgPGNoYXlhLnJhY2hlbC5p
dmdpQGludGVsLmNvbT4NCj4gPiA+IENjOiBTYXJhIFNoYXJvbiA8c2FyYS5zaGFyb25AaW50ZWwu
Y29tPg0KPiA+ID4gQ2M6IGxpbnV4LXdpcmVsZXNzQHZnZXIua2VybmVsLm9yZw0KPiA+ID4gQ2M6
IG5ldGRldkB2Z2VyLmtlcm5lbC5vcmcNCj4gPiA+IC0tLQ0KPiA+ID4gIGRyaXZlcnMvbmV0L3dp
cmVsZXNzL2ludGVsL2l3bHdpZmkvbXZtL3R0LmMgfCAgIDEzICsrKy0tLS0tLS0tLS0NCj4gPiA+
ICAxIGZpbGUgY2hhbmdlZCwgMyBpbnNlcnRpb25zKCspLCAxMCBkZWxldGlvbnMoLSkNCj4gPiA+
IA0KPiA+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvbmV0L3dpcmVsZXNzL2ludGVsL2l3bHdpZmkv
bXZtL3R0LmMNCj4gPiA+IGIvZHJpdmVycy9uZXQvd2lyZWxlc3MvaW50ZWwvaXdsd2lmaS9tdm0v
dHQuYw0KPiA+ID4gaW5kZXggNThmYzdiM2M3MTFjLi42NDgwMjY1OTcxMWYgMTAwNjQ0DQo+ID4g
PiAtLS0gYS9kcml2ZXJzL25ldC93aXJlbGVzcy9pbnRlbC9pd2x3aWZpL212bS90dC5jDQo+ID4g
PiArKysgYi9kcml2ZXJzL25ldC93aXJlbGVzcy9pbnRlbC9pd2x3aWZpL212bS90dC5jDQo+ID4g
PiBAQCAtNjM0LDExICs2MzQsNiBAQCBzdGF0aWMgaW50IGl3bF9tdm1fdHpvbmVfZ2V0X3RlbXAo
c3RydWN0DQo+ID4gPiB0aGVybWFsX3pvbmVfZGV2aWNlICpkZXZpY2UsDQo+ID4gPiANCj4gPiA+
ICAgICAgICAgbXV0ZXhfbG9jaygmbXZtLT5tdXRleCk7DQo+ID4gPiANCj4gPiA+IC0gICAgICAg
aWYgKCFtdm0tPnVjb2RlX2xvYWRlZCB8fCAhKG12bS0+Y3VyX3Vjb2RlID09DQo+ID4gPiBJV0xf
VUNPREVfUkVHVUxBUikpIHsNCj4gPiA+IC0gICAgICAgICAgICAgICByZXQgPSAtRUlPOw0KPiA+
ID4gLSAgICAgICAgICAgICAgIGdvdG8gb3V0Ow0KPiA+ID4gLSAgICAgICB9DQo+ID4gPiAtDQo+
ID4gPiAgICAgICAgIHJldCA9IGl3bF9tdm1fZ2V0X3RlbXAobXZtLCAmdGVtcCk7DQo+ID4gPiAg
ICAgICAgIGlmIChyZXQpDQo+ID4gPiAgICAgICAgICAgICAgICAgZ290byBvdXQ7DQo+ID4gPiBA
QCAtNjg0LDExICs2NzksNiBAQCBzdGF0aWMgaW50DQo+ID4gPiBpd2xfbXZtX3R6b25lX3NldF90
cmlwX3RlbXAoc3RydWN0IHRoZXJtYWxfem9uZV9kZXZpY2UgKmRldmljZSwNCj4gPiA+IA0KPiA+
ID4gICAgICAgICBtdXRleF9sb2NrKCZtdm0tPm11dGV4KTsNCj4gPiA+IA0KPiA+ID4gLSAgICAg
ICBpZiAoIW12bS0+dWNvZGVfbG9hZGVkIHx8ICEobXZtLT5jdXJfdWNvZGUgPT0NCj4gPiA+IElX
TF9VQ09ERV9SRUdVTEFSKSkgew0KPiA+ID4gLSAgICAgICAgICAgICAgIHJldCA9IC1FSU87DQo+
ID4gPiAtICAgICAgICAgICAgICAgZ290byBvdXQ7DQo+ID4gPiAtICAgICAgIH0NCj4gPiA+IC0N
Cj4gPiA+ICAgICAgICAgaWYgKHRyaXAgPCAwIHx8IHRyaXAgPj0gSVdMX01BWF9EVFNfVFJJUFMp
IHsNCj4gPiA+ICAgICAgICAgICAgICAgICByZXQgPSAtRUlOVkFMOw0KPiA+ID4gICAgICAgICAg
ICAgICAgIGdvdG8gb3V0Ow0KPiA+ID4gQEAgLTc1MCw2ICs3NDAsOSBAQCBzdGF0aWMgdm9pZA0K
PiA+ID4gaXdsX212bV90aGVybWFsX3pvbmVfcmVnaXN0ZXIoc3RydWN0IGl3bF9tdm0gKm12bSkN
Cj4gPiA+ICAgICAgICAgICAgICAgICByZXR1cm47DQo+ID4gPiAgICAgICAgIH0NCj4gPiA+IA0K
PiA+ID4gKyAgICAgICBpZiAoIW12bS0+dWNvZGVfbG9hZGVkIHx8ICEobXZtLT5jdXJfdWNvZGUg
PT0NCj4gPiA+IElXTF9VQ09ERV9SRUdVTEFSKSkNCj4gPiA+ICsgICAgICAgICAgICAgICByZXR1
cm47DQo+ID4gPiArDQo+ID4gPiAgICAgICAgIEJVSUxEX0JVR19PTihBUlJBWV9TSVpFKG5hbWUp
ID49IFRIRVJNQUxfTkFNRV9MRU5HVEgpOw0KPiA+ID4gDQo+ID4gPiAgICAgICAgIG12bS0+dHpf
ZGV2aWNlLnR6b25lID0gdGhlcm1hbF96b25lX2RldmljZV9yZWdpc3RlcihuYW1lLA0KPiA+ID4g
LS0NCj4gPiA+IDEuNy45LjMNCj4gPiA+IA0KPiA+ID4gLS0NCj4gPiA+IFRvIHVuc3Vic2NyaWJl
IGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1YnNjcmliZSBsaW51eA0KPiA+ID4g
LXdpcmVsZXNzIiBpbg0KPiA+ID4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2
Z2VyLmtlcm5lbC5vcmcNCj4gPiA+IE1vcmUgbWFqb3Jkb21vIGluZm8gYXQgIA0KPiA+ID4gaHR0
cDovL3ZnZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1s
^ permalink raw reply
* Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded
From: Prarit Bhargava @ 2016-07-11 18:19 UTC (permalink / raw)
To: Emmanuel Grumbach
Cc: linux-kernel@vger.kernel.org, Johannes Berg, Emmanuel Grumbach,
Luca Coelho, Intel Linux Wireless, Kalle Valo, Chaya Rachel Ivgi,
Sara Sharon, linux-wireless, netdev@vger.kernel.org
In-Reply-To: <CANUX_P0AFoM5VEDWDjtvOhNbExu4T1bLWU+uS-EYqoGtu5h2bw@mail.gmail.com>
On 07/11/2016 02:00 PM, Emmanuel Grumbach wrote:
> On Mon, Jul 11, 2016 at 6:18 PM, Prarit Bhargava <prarit@redhat.com> wrote:
>>
>> Didn't get any feedback or review comments on this patch. Resending ...
>>
>> P.
>
> This change is obviously completely broken. It simply disables the
> registration to thermal zone core.
No it is not broken, and yes, that is exactly what should happen IMO.
The problem is that the iwlwifi driver implements the thermal zone even when the
device doesn't support it.
As can be seen in the current code base, iwl_mvm_tzone_get_temp() will return
-EIO 100% of the time when the firmware doesn't support reading the
temperature[1]. In this case a read of sysfs will result in a return of -EIO,
and this breaks existing userspace programs such as lm-sensors (which by all
accounts is bad to do).
Note that in my patch I have removed the -EIO return in favor of not registering
the non-existent thermal zone. I'm not removing any functionality by changing
this, nor am I adding functionality. In both cases the thermal zone is not
functional, and with my patch userspace continues to work.
P.
[1] iwl_mvm_tzone_set_trip_temp() also returns -EIO, so setting and getting of
the temperature is non-functional.
>
>>
>> ---8<---
>>
>> The iwlwifi driver implements a thermal zone and hwmon device, but
>> returns -EIO on temperature reads if the firmware isn't loaded. This
>> results in the error
>>
>> iwlwifi-virtual-0
>> Adapter: Virtual device
>> ERROR: Can't get value of subfeature temp1_input: I/O error
>> temp1: N/A
>>
>> being output when using sensors from the lm-sensors package. Since
>> the temperature cannot be read unless the ucode is loaded there is no
>> reason to add the interface only to have it return an error 100% of
>> the time.
>>
>> This patch moves the firmware check to iwl_mvm_thermal_zone_register() and
>> stops the thermal zone from being created if the ucode hasn't been loaded.
>>
>> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>> Cc: Johannes Berg <johannes.berg@intel.com>
>> Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>> Cc: Luca Coelho <luciano.coelho@intel.com>
>> Cc: Intel Linux Wireless <linuxwifi@intel.com>
>> Cc: Kalle Valo <kvalo@codeaurora.org>
>> Cc: Chaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
>> Cc: Sara Sharon <sara.sharon@intel.com>
>> Cc: linux-wireless@vger.kernel.org
>> Cc: netdev@vger.kernel.org
>> ---
>> drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 13 +++----------
>> 1 file changed, 3 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
>> index 58fc7b3c711c..64802659711f 100644
>> --- a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
>> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
>> @@ -634,11 +634,6 @@ static int iwl_mvm_tzone_get_temp(struct thermal_zone_device *device,
>>
>> mutex_lock(&mvm->mutex);
>>
>> - if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR)) {
>> - ret = -EIO;
>> - goto out;
>> - }
>> -
>> ret = iwl_mvm_get_temp(mvm, &temp);
>> if (ret)
>> goto out;
>> @@ -684,11 +679,6 @@ static int iwl_mvm_tzone_set_trip_temp(struct thermal_zone_device *device,
>>
>> mutex_lock(&mvm->mutex);
>>
>> - if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR)) {
>> - ret = -EIO;
>> - goto out;
>> - }
>> -
>> if (trip < 0 || trip >= IWL_MAX_DTS_TRIPS) {
>> ret = -EINVAL;
>> goto out;
>> @@ -750,6 +740,9 @@ static void iwl_mvm_thermal_zone_register(struct iwl_mvm *mvm)
>> return;
>> }
>>
>> + if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR))
>> + return;
>> +
>> BUILD_BUG_ON(ARRAY_SIZE(name) >= THERMAL_NAME_LENGTH);
>>
>> mvm->tz_device.tzone = thermal_zone_device_register(name,
>> --
>> 1.7.9.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded
From: Emmanuel Grumbach @ 2016-07-11 18:00 UTC (permalink / raw)
To: Prarit Bhargava
Cc: linux-kernel@vger.kernel.org, Johannes Berg, Emmanuel Grumbach,
Luca Coelho, Intel Linux Wireless, Kalle Valo, Chaya Rachel Ivgi,
Sara Sharon, linux-wireless, netdev@vger.kernel.org
In-Reply-To: <1468250301-10357-1-git-send-email-prarit@redhat.com>
On Mon, Jul 11, 2016 at 6:18 PM, Prarit Bhargava <prarit@redhat.com> wrote:
>
> Didn't get any feedback or review comments on this patch. Resending ...
>
> P.
This change is obviously completely broken. It simply disables the
registration to thermal zone core.
>
> ---8<---
>
> The iwlwifi driver implements a thermal zone and hwmon device, but
> returns -EIO on temperature reads if the firmware isn't loaded. This
> results in the error
>
> iwlwifi-virtual-0
> Adapter: Virtual device
> ERROR: Can't get value of subfeature temp1_input: I/O error
> temp1: N/A
>
> being output when using sensors from the lm-sensors package. Since
> the temperature cannot be read unless the ucode is loaded there is no
> reason to add the interface only to have it return an error 100% of
> the time.
>
> This patch moves the firmware check to iwl_mvm_thermal_zone_register() and
> stops the thermal zone from being created if the ucode hasn't been loaded.
>
> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
> Cc: Johannes Berg <johannes.berg@intel.com>
> Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> Cc: Luca Coelho <luciano.coelho@intel.com>
> Cc: Intel Linux Wireless <linuxwifi@intel.com>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: Chaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
> Cc: Sara Sharon <sara.sharon@intel.com>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> ---
> drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 13 +++----------
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
> index 58fc7b3c711c..64802659711f 100644
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
> @@ -634,11 +634,6 @@ static int iwl_mvm_tzone_get_temp(struct thermal_zone_device *device,
>
> mutex_lock(&mvm->mutex);
>
> - if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR)) {
> - ret = -EIO;
> - goto out;
> - }
> -
> ret = iwl_mvm_get_temp(mvm, &temp);
> if (ret)
> goto out;
> @@ -684,11 +679,6 @@ static int iwl_mvm_tzone_set_trip_temp(struct thermal_zone_device *device,
>
> mutex_lock(&mvm->mutex);
>
> - if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR)) {
> - ret = -EIO;
> - goto out;
> - }
> -
> if (trip < 0 || trip >= IWL_MAX_DTS_TRIPS) {
> ret = -EINVAL;
> goto out;
> @@ -750,6 +740,9 @@ static void iwl_mvm_thermal_zone_register(struct iwl_mvm *mvm)
> return;
> }
>
> + if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR))
> + return;
> +
> BUILD_BUG_ON(ARRAY_SIZE(name) >= THERMAL_NAME_LENGTH);
>
> mvm->tz_device.tzone = thermal_zone_device_register(name,
> --
> 1.7.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded
From: Prarit Bhargava @ 2016-07-11 17:00 UTC (permalink / raw)
To: Coelho, Luciano, linux-kernel@vger.kernel.org
Cc: linuxwifi, Berg, Johannes, kvalo@codeaurora.org,
Ivgi, Chaya Rachel, netdev@vger.kernel.org, Sharon, Sara,
linux-wireless@vger.kernel.org, Grumbach, Emmanuel
In-Reply-To: <1468253261.25088.126.camel@intel.com>
On 07/11/2016 12:07 PM, Coelho, Luciano wrote:
> On Mon, 2016-07-11 at 11:18 -0400, Prarit Bhargava wrote:
>> Didn't get any feedback or review comments on this patch. Resending
>> ...
>>
>> P.
>
> Sorry, this got flooded down my inbox.
NP, Luciano -- My worry was that it hadn't been seen or didn't make it out to
the list.
I'm being a bit impatient too ;)
P.
>
>
>> ---8<---
>>
>> The iwlwifi driver implements a thermal zone and hwmon device, but
>> returns -EIO on temperature reads if the firmware isn't loaded. This
>> results in the error
>>
>> iwlwifi-virtual-0
>> Adapter: Virtual device
>> ERROR: Can't get value of subfeature temp1_input: I/O error
>> temp1: N/A
>>
>> being output when using sensors from the lm-sensors package. Since
>> the temperature cannot be read unless the ucode is loaded there is no
>> reason to add the interface only to have it return an error 100% of
>> the time.
>>
>> This patch moves the firmware check to
>> iwl_mvm_thermal_zone_register() and
>> stops the thermal zone from being created if the ucode hasn't been
>> loaded.
>>
>> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>> Cc: Johannes Berg <johannes.berg@intel.com>
>> Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>> Cc: Luca Coelho <luciano.coelho@intel.com>
>> Cc: Intel Linux Wireless <linuxwifi@intel.com>
>> Cc: Kalle Valo <kvalo@codeaurora.org>
>> Cc: Chaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
>> Cc: Sara Sharon <sara.sharon@intel.com>
>> Cc: linux-wireless@vger.kernel.org
>> Cc: netdev@vger.kernel.org
>> ---
>
> I have now sent it for review on our internal tree.
>
> --
> Luca.
>
^ permalink raw reply
* Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded
From: Coelho, Luciano @ 2016-07-11 16:07 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, prarit@redhat.com
Cc: linuxwifi, Berg, Johannes, kvalo@codeaurora.org,
Ivgi, Chaya Rachel, netdev@vger.kernel.org, Sharon, Sara,
linux-wireless@vger.kernel.org, Grumbach, Emmanuel
In-Reply-To: <1468250301-10357-1-git-send-email-prarit@redhat.com>
T24gTW9uLCAyMDE2LTA3LTExIGF0IDExOjE4IC0wNDAwLCBQcmFyaXQgQmhhcmdhdmEgd3JvdGU6
DQo+IERpZG4ndCBnZXQgYW55IGZlZWRiYWNrIG9yIHJldmlldyBjb21tZW50cyBvbiB0aGlzIHBh
dGNoLsKgwqBSZXNlbmRpbmcNCj4gLi4uDQo+IA0KPiBQLg0KDQpTb3JyeSwgdGhpcyBnb3QgZmxv
b2RlZCBkb3duIG15IGluYm94Lg0KDQoNCj4gLS0tODwtLS0NCj4gDQo+IFRoZSBpd2x3aWZpIGRy
aXZlciBpbXBsZW1lbnRzIGEgdGhlcm1hbCB6b25lIGFuZCBod21vbiBkZXZpY2UsIGJ1dA0KPiBy
ZXR1cm5zIC1FSU8gb24gdGVtcGVyYXR1cmUgcmVhZHMgaWYgdGhlIGZpcm13YXJlIGlzbid0IGxv
YWRlZC7CoMKgVGhpcw0KPiByZXN1bHRzIGluIHRoZSBlcnJvcg0KPiANCj4gaXdsd2lmaS12aXJ0
dWFsLTANCj4gQWRhcHRlcjogVmlydHVhbCBkZXZpY2UNCj4gRVJST1I6IENhbid0IGdldCB2YWx1
ZSBvZiBzdWJmZWF0dXJlIHRlbXAxX2lucHV0OiBJL08gZXJyb3INCj4gdGVtcDE6wqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgTi9BDQo+IA0KPiBiZWluZyBvdXRwdXQgd2hlbiB1c2luZyBzZW5zb3Jz
IGZyb20gdGhlIGxtLXNlbnNvcnMgcGFja2FnZS7CoMKgU2luY2UNCj4gdGhlIHRlbXBlcmF0dXJl
IGNhbm5vdCBiZSByZWFkIHVubGVzcyB0aGUgdWNvZGUgaXMgbG9hZGVkIHRoZXJlIGlzIG5vDQo+
IHJlYXNvbiB0byBhZGQgdGhlIGludGVyZmFjZSBvbmx5IHRvIGhhdmUgaXQgcmV0dXJuIGFuIGVy
cm9yIDEwMCUgb2YNCj4gdGhlIHRpbWUuDQo+IA0KPiBUaGlzIHBhdGNoIG1vdmVzIHRoZSBmaXJt
d2FyZSBjaGVjayB0bw0KPiBpd2xfbXZtX3RoZXJtYWxfem9uZV9yZWdpc3RlcigpIGFuZA0KPiBz
dG9wcyB0aGUgdGhlcm1hbCB6b25lIGZyb20gYmVpbmcgY3JlYXRlZCBpZiB0aGUgdWNvZGUgaGFz
bid0IGJlZW4NCj4gbG9hZGVkLg0KPiANCj4gU2lnbmVkLW9mZi1ieTogUHJhcml0IEJoYXJnYXZh
IDxwcmFyaXRAcmVkaGF0LmNvbT4NCj4gQ2M6IEpvaGFubmVzIEJlcmcgPGpvaGFubmVzLmJlcmdA
aW50ZWwuY29tPg0KPiBDYzogRW1tYW51ZWwgR3J1bWJhY2ggPGVtbWFudWVsLmdydW1iYWNoQGlu
dGVsLmNvbT4NCj4gQ2M6IEx1Y2EgQ29lbGhvIDxsdWNpYW5vLmNvZWxob0BpbnRlbC5jb20+DQo+
IENjOiBJbnRlbCBMaW51eCBXaXJlbGVzcyA8bGludXh3aWZpQGludGVsLmNvbT4NCj4gQ2M6IEth
bGxlIFZhbG8gPGt2YWxvQGNvZGVhdXJvcmEub3JnPg0KPiBDYzogQ2hheWEgUmFjaGVsIEl2Z2kg
PGNoYXlhLnJhY2hlbC5pdmdpQGludGVsLmNvbT4NCj4gQ2M6IFNhcmEgU2hhcm9uIDxzYXJhLnNo
YXJvbkBpbnRlbC5jb20+DQo+IENjOiBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmcNCj4g
Q2M6IG5ldGRldkB2Z2VyLmtlcm5lbC5vcmcNCj4gLS0tDQoNCkkgaGF2ZSBub3cgc2VudCBpdCBm
b3IgcmV2aWV3IG9uIG91ciBpbnRlcm5hbCB0cmVlLg0KDQotLQ0KTHVjYS4=
^ permalink raw reply
* Re: [PATCH] nfp: check idx is -ENOSPC before using it is an index
From: Samuel Ortiz @ 2016-07-11 15:59 UTC (permalink / raw)
To: Colin King
Cc: Jakub Kicinski, Lauro Ramos Venancio, Aloisio Almeida Jr,
David S . Miller, Rolf Neugebauer, Christophe Ricard,
Robert Dolca, oss-drivers, netdev, linux-wireless
In-Reply-To: <1468252017-14864-1-git-send-email-colin.king@canonical.com>
Hi Colin,
On Mon, Jul 11, 2016 at 04:46:57PM +0100, Colin King wrote:
> diff --git a/drivers/nfc/fdp/fdp.c b/drivers/nfc/fdp/fdp.c
> index e44a7a2..d93d314 100644
> --- a/drivers/nfc/fdp/fdp.c
> +++ b/drivers/nfc/fdp/fdp.c
> @@ -345,7 +345,7 @@ static void fdp_nci_release_firmware(struct nci_dev *ndev)
>
> if (info->ram_patch) {
> release_firmware(info->ram_patch);
> - info->otp_patch = NULL;
> + info->ram_patch = NULL;
> }
> }
This chunk is unrelated and also already applied to my nfc-next tree.
Cheers,
Samuel.
^ permalink raw reply
* Re: [oss-drivers] [PATCH][V2] nfp: check idx is -ENOSPC before using it is an index
From: Jakub Kicinski @ 2016-07-11 15:59 UTC (permalink / raw)
To: Colin King
Cc: Lauro Ramos Venancio, Aloisio Almeida Jr, Samuel Ortiz,
David S . Miller, Rolf Neugebauer, Christophe Ricard,
Robert Dolca, oss-drivers, netdev, linux-wireless
In-Reply-To: <1468252460-15117-1-git-send-email-colin.king@canonical.com>
On Mon, 11 Jul 2016 16:54:20 +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> idx can be returned as -ENOSPC, so we should check for this first
> before using it as an index into nn->vxlan_usecnt[] to avoid an
> out of bounds array offset read.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Thanks!
^ permalink raw reply
* [PATCH][V2] nfp: check idx is -ENOSPC before using it is an index
From: Colin King @ 2016-07-11 15:54 UTC (permalink / raw)
To: Jakub Kicinski, Lauro Ramos Venancio, Aloisio Almeida Jr,
Samuel Ortiz, David S . Miller, Rolf Neugebauer,
Christophe Ricard, Robert Dolca, oss-drivers, netdev,
linux-wireless
From: Colin Ian King <colin.king@canonical.com>
idx can be returned as -ENOSPC, so we should check for this first
before using it as an index into nn->vxlan_usecnt[] to avoid an
out of bounds array offset read.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index 1e74b91..88678c1 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -2578,7 +2578,7 @@ static void nfp_net_del_vxlan_port(struct net_device *netdev,
return;
idx = nfp_net_find_vxlan_idx(nn, ti->port);
- if (!nn->vxlan_usecnt[idx] || idx == -ENOSPC)
+ if (idx == -ENOSPC || !nn->vxlan_usecnt[idx])
return;
if (!--nn->vxlan_usecnt[idx])
--
2.8.1
^ permalink raw reply related
* NACK: [PATCH] nfp: check idx is -ENOSPC before using it is an index
From: Colin Ian King @ 2016-07-11 15:52 UTC (permalink / raw)
To: Jakub Kicinski, Lauro Ramos Venancio, Aloisio Almeida Jr,
Samuel Ortiz, David S . Miller, Rolf Neugebauer,
Christophe Ricard, Robert Dolca, oss-drivers, netdev,
linux-wireless
In-Reply-To: <1468252017-14864-1-git-send-email-colin.king@canonical.com>
Ignore this, got some other fix included by mistake. Will resend.
On 11/07/16 16:46, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> idx can be returned as -ENOSPC, so we should check for this first
> before using it as an index into nn->vxlan_usecnt[] to avoid an
> out of bounds array offset read.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 2 +-
> drivers/nfc/fdp/fdp.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
> index 1e74b91..88678c1 100644
> --- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
> +++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
> @@ -2578,7 +2578,7 @@ static void nfp_net_del_vxlan_port(struct net_device *netdev,
> return;
>
> idx = nfp_net_find_vxlan_idx(nn, ti->port);
> - if (!nn->vxlan_usecnt[idx] || idx == -ENOSPC)
> + if (idx == -ENOSPC || !nn->vxlan_usecnt[idx])
> return;
>
> if (!--nn->vxlan_usecnt[idx])
> diff --git a/drivers/nfc/fdp/fdp.c b/drivers/nfc/fdp/fdp.c
> index e44a7a2..d93d314 100644
> --- a/drivers/nfc/fdp/fdp.c
> +++ b/drivers/nfc/fdp/fdp.c
> @@ -345,7 +345,7 @@ static void fdp_nci_release_firmware(struct nci_dev *ndev)
>
> if (info->ram_patch) {
> release_firmware(info->ram_patch);
> - info->otp_patch = NULL;
> + info->ram_patch = NULL;
> }
> }
>
>
^ permalink raw reply
* [PATCH] nfp: check idx is -ENOSPC before using it is an index
From: Colin King @ 2016-07-11 15:46 UTC (permalink / raw)
To: Jakub Kicinski, Lauro Ramos Venancio, Aloisio Almeida Jr,
Samuel Ortiz, David S . Miller, Rolf Neugebauer,
Christophe Ricard, Robert Dolca, oss-drivers, netdev,
linux-wireless
From: Colin Ian King <colin.king@canonical.com>
idx can be returned as -ENOSPC, so we should check for this first
before using it as an index into nn->vxlan_usecnt[] to avoid an
out of bounds array offset read.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 2 +-
drivers/nfc/fdp/fdp.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index 1e74b91..88678c1 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -2578,7 +2578,7 @@ static void nfp_net_del_vxlan_port(struct net_device *netdev,
return;
idx = nfp_net_find_vxlan_idx(nn, ti->port);
- if (!nn->vxlan_usecnt[idx] || idx == -ENOSPC)
+ if (idx == -ENOSPC || !nn->vxlan_usecnt[idx])
return;
if (!--nn->vxlan_usecnt[idx])
diff --git a/drivers/nfc/fdp/fdp.c b/drivers/nfc/fdp/fdp.c
index e44a7a2..d93d314 100644
--- a/drivers/nfc/fdp/fdp.c
+++ b/drivers/nfc/fdp/fdp.c
@@ -345,7 +345,7 @@ static void fdp_nci_release_firmware(struct nci_dev *ndev)
if (info->ram_patch) {
release_firmware(info->ram_patch);
- info->otp_patch = NULL;
+ info->ram_patch = NULL;
}
}
--
2.8.1
^ permalink raw reply related
* [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded
From: Prarit Bhargava @ 2016-07-11 15:18 UTC (permalink / raw)
To: linux-kernel
Cc: Prarit Bhargava, Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Kalle Valo, Chaya Rachel Ivgi, Sara Sharon,
linux-wireless, netdev
Didn't get any feedback or review comments on this patch. Resending ...
P.
---8<---
The iwlwifi driver implements a thermal zone and hwmon device, but
returns -EIO on temperature reads if the firmware isn't loaded. This
results in the error
iwlwifi-virtual-0
Adapter: Virtual device
ERROR: Can't get value of subfeature temp1_input: I/O error
temp1: N/A
being output when using sensors from the lm-sensors package. Since
the temperature cannot be read unless the ucode is loaded there is no
reason to add the interface only to have it return an error 100% of
the time.
This patch moves the firmware check to iwl_mvm_thermal_zone_register() and
stops the thermal zone from being created if the ucode hasn't been loaded.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Cc: Intel Linux Wireless <linuxwifi@intel.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: Chaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
Cc: Sara Sharon <sara.sharon@intel.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
---
drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
index 58fc7b3c711c..64802659711f 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
@@ -634,11 +634,6 @@ static int iwl_mvm_tzone_get_temp(struct thermal_zone_device *device,
mutex_lock(&mvm->mutex);
- if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR)) {
- ret = -EIO;
- goto out;
- }
-
ret = iwl_mvm_get_temp(mvm, &temp);
if (ret)
goto out;
@@ -684,11 +679,6 @@ static int iwl_mvm_tzone_set_trip_temp(struct thermal_zone_device *device,
mutex_lock(&mvm->mutex);
- if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR)) {
- ret = -EIO;
- goto out;
- }
-
if (trip < 0 || trip >= IWL_MAX_DTS_TRIPS) {
ret = -EINVAL;
goto out;
@@ -750,6 +740,9 @@ static void iwl_mvm_thermal_zone_register(struct iwl_mvm *mvm)
return;
}
+ if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR))
+ return;
+
BUILD_BUG_ON(ARRAY_SIZE(name) >= THERMAL_NAME_LENGTH);
mvm->tz_device.tzone = thermal_zone_device_register(name,
--
1.7.9.3
^ permalink raw reply related
* [PATCH 9/9] mwifiex: fix radar detection issue
From: Amitkumar Karwar @ 2016-07-11 14:53 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Ganapathi Bhat, Amitkumar Karwar
In-Reply-To: <1468248832-21969-1-git-send-email-akarwar@marvell.com>
From: Ganapathi Bhat <gbhat@marvell.com>
It's been observed that firmware sends RADAR detected event without
specifying bss_num/bss_type. Also, the event body is empty.
Currently the event is being ignored by driver.
This patch checks on which interface 11H is active, accordingly fills
bss_num/bss_type and handles the event. Condition
"if (le32_to_cpu(rdr_event->passed))" which always fails is also removed.
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/11h.c | 27 +++++++++++----------------
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 18 ++++++++++++++++--
2 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/11h.c b/drivers/net/wireless/marvell/mwifiex/11h.c
index 81c60d0..43dccd5 100644
--- a/drivers/net/wireless/marvell/mwifiex/11h.c
+++ b/drivers/net/wireless/marvell/mwifiex/11h.c
@@ -260,22 +260,17 @@ int mwifiex_11h_handle_radar_detected(struct mwifiex_private *priv,
rdr_event = (void *)(skb->data + sizeof(u32));
- if (le32_to_cpu(rdr_event->passed)) {
- mwifiex_dbg(priv->adapter, MSG,
- "radar detected; indicating kernel\n");
- if (mwifiex_stop_radar_detection(priv, &priv->dfs_chandef))
- mwifiex_dbg(priv->adapter, ERROR,
- "Failed to stop CAC in FW\n");
- cfg80211_radar_event(priv->adapter->wiphy, &priv->dfs_chandef,
- GFP_KERNEL);
- mwifiex_dbg(priv->adapter, MSG, "regdomain: %d\n",
- rdr_event->reg_domain);
- mwifiex_dbg(priv->adapter, MSG, "radar detection type: %d\n",
- rdr_event->det_type);
- } else {
- mwifiex_dbg(priv->adapter, MSG,
- "false radar detection event!\n");
- }
+ mwifiex_dbg(priv->adapter, MSG,
+ "radar detected; indicating kernel\n");
+ if (mwifiex_stop_radar_detection(priv, &priv->dfs_chandef))
+ mwifiex_dbg(priv->adapter, ERROR,
+ "Failed to stop CAC in FW\n");
+ cfg80211_radar_event(priv->adapter->wiphy, &priv->dfs_chandef,
+ GFP_KERNEL);
+ mwifiex_dbg(priv->adapter, MSG, "regdomain: %d\n",
+ rdr_event->reg_domain);
+ mwifiex_dbg(priv->adapter, MSG, "radar detection type: %d\n",
+ rdr_event->det_type);
return 0;
}
diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index c29f26d..d433aa0 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -480,13 +480,27 @@ int mwifiex_free_cmd_buffer(struct mwifiex_adapter *adapter)
*/
int mwifiex_process_event(struct mwifiex_adapter *adapter)
{
- int ret;
+ int ret, i;
struct mwifiex_private *priv =
mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_ANY);
struct sk_buff *skb = adapter->event_skb;
- u32 eventcause = adapter->event_cause;
+ u32 eventcause;
struct mwifiex_rxinfo *rx_info;
+ if ((adapter->event_cause & EVENT_ID_MASK) == EVENT_RADAR_DETECTED) {
+ for (i = 0; i < adapter->priv_num; i++) {
+ priv = adapter->priv[i];
+ if (priv && mwifiex_is_11h_active(priv)) {
+ adapter->event_cause |=
+ ((priv->bss_num & 0xff) << 16) |
+ ((priv->bss_type & 0xff) << 24);
+ break;
+ }
+ }
+ }
+
+ eventcause = adapter->event_cause;
+
/* Save the last event to debug log */
adapter->dbg.last_event_index =
(adapter->dbg.last_event_index + 1) % DBG_CMD_NUM;
--
1.9.1
^ permalink raw reply related
* [PATCH 8/9] mwifiex: add HT aggregation support for adhoc mode
From: Amitkumar Karwar @ 2016-07-11 14:53 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1468248832-21969-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
This patch adds HT support for adhoc station. Firmware will upload
ibss sta connect event with beacon data, whenever new station joins
the adhoc network. Driver will check the HT IE and decide whether to
support HT aggreagation or not.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/11n.h | 7 +-
drivers/net/wireless/marvell/mwifiex/fw.h | 9 ++
drivers/net/wireless/marvell/mwifiex/sta_event.c | 132 ++++++++++++++++++++++-
3 files changed, 144 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/11n.h b/drivers/net/wireless/marvell/mwifiex/11n.h
index afdd58a..ea0fa68 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n.h
+++ b/drivers/net/wireless/marvell/mwifiex/11n.h
@@ -171,9 +171,10 @@ mwifiex_find_stream_to_delete(struct mwifiex_private *priv, int ptr_tid,
static inline int mwifiex_is_sta_11n_enabled(struct mwifiex_private *priv,
struct mwifiex_sta_node *node)
{
-
- if (!node || (priv->bss_role != MWIFIEX_BSS_ROLE_UAP) ||
- !priv->ap_11n_enabled)
+ if (!node || ((priv->bss_role == MWIFIEX_BSS_ROLE_UAP) &&
+ !priv->ap_11n_enabled) ||
+ ((priv->bss_mode == NL80211_IFTYPE_ADHOC) &&
+ !priv->adapter->adhoc_11n_enabled))
return 0;
return node->is_11n_enabled;
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h
index 3b40e0d..a88030a 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -210,6 +210,7 @@ enum MWIFIEX_802_11_PRIVACY_FILTER {
#define MWIFIEX_TX_DATA_BUF_SIZE_4K 4096
#define MWIFIEX_TX_DATA_BUF_SIZE_8K 8192
+#define MWIFIEX_TX_DATA_BUF_SIZE_12K 12288
#define ISSUPP_11NENABLED(FwCapInfo) (FwCapInfo & BIT(11))
#define ISSUPP_TDLS_ENABLED(FwCapInfo) (FwCapInfo & BIT(14))
@@ -506,6 +507,8 @@ enum P2P_MODES {
#define EVENT_RSSI_HIGH 0x0000001c
#define EVENT_SNR_HIGH 0x0000001d
#define EVENT_IBSS_COALESCED 0x0000001e
+#define EVENT_IBSS_STA_CONNECT 0x00000020
+#define EVENT_IBSS_STA_DISCONNECT 0x00000021
#define EVENT_DATA_RSSI_LOW 0x00000024
#define EVENT_DATA_SNR_LOW 0x00000025
#define EVENT_DATA_RSSI_HIGH 0x00000026
@@ -1686,6 +1689,12 @@ struct mwifiex_ie_types_wmm_param_set {
u8 wmm_ie[1];
};
+struct mwifiex_ie_types_mgmt_frame {
+ struct mwifiex_ie_types_header header;
+ __le16 frame_control;
+ u8 frame_contents[0];
+};
+
struct mwifiex_ie_types_wmm_queue_status {
struct mwifiex_ie_types_header header;
u8 queue_index;
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_event.c b/drivers/net/wireless/marvell/mwifiex/sta_event.c
index b973ee8..9df0c4d 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_event.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_event.c
@@ -25,6 +25,99 @@
#include "wmm.h"
#include "11n.h"
+#define MWIFIEX_IBSS_CONNECT_EVT_FIX_SIZE 12
+
+static int mwifiex_check_ibss_peer_capabilties(struct mwifiex_private *priv,
+ struct mwifiex_sta_node *sta_ptr,
+ struct sk_buff *event)
+{
+ int evt_len, ele_len;
+ u8 *curr;
+ struct ieee_types_header *ele_hdr;
+ struct mwifiex_ie_types_mgmt_frame *tlv_mgmt_frame;
+ const struct ieee80211_ht_cap *ht_cap;
+ const struct ieee80211_vht_cap *vht_cap;
+
+ skb_pull(event, MWIFIEX_IBSS_CONNECT_EVT_FIX_SIZE);
+ evt_len = event->len;
+ curr = event->data;
+
+ mwifiex_dbg_dump(priv->adapter, EVT_D, "ibss peer capabilties:",
+ event->data, event->len);
+
+ skb_push(event, MWIFIEX_IBSS_CONNECT_EVT_FIX_SIZE);
+
+ tlv_mgmt_frame = (void *)curr;
+ if (evt_len >= sizeof(*tlv_mgmt_frame) &&
+ le16_to_cpu(tlv_mgmt_frame->header.type) ==
+ TLV_TYPE_UAP_MGMT_FRAME) {
+ /* Locate curr pointer to the start of beacon tlv,
+ * timestamp 8 bytes, beacon intervel 2 bytes,
+ * capability info 2 bytes, totally 12 byte beacon header
+ */
+ evt_len = le16_to_cpu(tlv_mgmt_frame->header.len);
+ curr += (sizeof(*tlv_mgmt_frame) + 12);
+ } else {
+ mwifiex_dbg(priv->adapter, MSG,
+ "management frame tlv not found!\n");
+ return 0;
+ }
+
+ while (evt_len >= sizeof(*ele_hdr)) {
+ ele_hdr = (struct ieee_types_header *)curr;
+ ele_len = ele_hdr->len;
+
+ if (evt_len < ele_len + sizeof(*ele_hdr))
+ break;
+
+ switch (ele_hdr->element_id) {
+ case WLAN_EID_HT_CAPABILITY:
+ sta_ptr->is_11n_enabled = true;
+ ht_cap = (void *)(ele_hdr + 2);
+ sta_ptr->max_amsdu = le16_to_cpu(ht_cap->cap_info) &
+ IEEE80211_HT_CAP_MAX_AMSDU ?
+ MWIFIEX_TX_DATA_BUF_SIZE_8K :
+ MWIFIEX_TX_DATA_BUF_SIZE_4K;
+ mwifiex_dbg(priv->adapter, INFO,
+ "11n enabled!, max_amsdu : %d\n",
+ sta_ptr->max_amsdu);
+ break;
+
+ case WLAN_EID_VHT_CAPABILITY:
+ sta_ptr->is_11ac_enabled = true;
+ vht_cap = (void *)(ele_hdr + 2);
+ /* check VHT MAXMPDU capability */
+ switch (le32_to_cpu(vht_cap->vht_cap_info) & 0x3) {
+ case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454:
+ sta_ptr->max_amsdu =
+ MWIFIEX_TX_DATA_BUF_SIZE_12K;
+ break;
+ case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991:
+ sta_ptr->max_amsdu =
+ MWIFIEX_TX_DATA_BUF_SIZE_8K;
+ break;
+ case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895:
+ sta_ptr->max_amsdu =
+ MWIFIEX_TX_DATA_BUF_SIZE_4K;
+ default:
+ break;
+ }
+
+ mwifiex_dbg(priv->adapter, INFO,
+ "11ac enabled!, max_amsdu : %d\n",
+ sta_ptr->max_amsdu);
+ break;
+ default:
+ break;
+ }
+
+ curr += (ele_len + sizeof(*ele_hdr));
+ evt_len -= (ele_len + sizeof(*ele_hdr));
+ }
+
+ return 0;
+}
+
/*
* This function resets the connection state.
*
@@ -519,6 +612,8 @@ void mwifiex_bt_coex_wlan_param_update_event(struct mwifiex_private *priv,
* - EVENT_LINK_QUALITY
* - EVENT_PRE_BEACON_LOST
* - EVENT_IBSS_COALESCED
+ * - EVENT_IBSS_STA_CONNECT
+ * - EVENT_IBSS_STA_DISCONNECT
* - EVENT_WEP_ICV_ERR
* - EVENT_BW_CHANGE
* - EVENT_HOSTWAKE_STAIE
@@ -547,9 +642,11 @@ void mwifiex_bt_coex_wlan_param_update_event(struct mwifiex_private *priv,
int mwifiex_process_sta_event(struct mwifiex_private *priv)
{
struct mwifiex_adapter *adapter = priv->adapter;
- int ret = 0;
+ int ret = 0, i;
u32 eventcause = adapter->event_cause;
u16 ctrl, reason_code;
+ u8 ibss_sta_addr[ETH_ALEN];
+ struct mwifiex_sta_node *sta_ptr;
switch (eventcause) {
case EVENT_DUMMY_HOST_WAKEUP_SIGNAL:
@@ -775,6 +872,39 @@ int mwifiex_process_sta_event(struct mwifiex_private *priv)
HostCmd_CMD_802_11_IBSS_COALESCING_STATUS,
HostCmd_ACT_GEN_GET, 0, NULL, false);
break;
+ case EVENT_IBSS_STA_CONNECT:
+ ether_addr_copy(ibss_sta_addr, adapter->event_body + 2);
+ mwifiex_dbg(adapter, EVENT, "event: IBSS_STA_CONNECT %pM\n",
+ ibss_sta_addr);
+ sta_ptr = mwifiex_add_sta_entry(priv, ibss_sta_addr);
+ if (sta_ptr && adapter->adhoc_11n_enabled) {
+ mwifiex_check_ibss_peer_capabilties(priv, sta_ptr,
+ adapter->event_skb);
+ if (sta_ptr->is_11n_enabled)
+ for (i = 0; i < MAX_NUM_TID; i++)
+ sta_ptr->ampdu_sta[i] =
+ priv->aggr_prio_tbl[i].ampdu_user;
+ else
+ for (i = 0; i < MAX_NUM_TID; i++)
+ sta_ptr->ampdu_sta[i] =
+ BA_STREAM_NOT_ALLOWED;
+ memset(sta_ptr->rx_seq, 0xff, sizeof(sta_ptr->rx_seq));
+ }
+
+ break;
+ case EVENT_IBSS_STA_DISCONNECT:
+ ether_addr_copy(ibss_sta_addr, adapter->event_body + 2);
+ mwifiex_dbg(adapter, EVENT, "event: IBSS_STA_DISCONNECT %pM\n",
+ ibss_sta_addr);
+ sta_ptr = mwifiex_get_sta_entry(priv, ibss_sta_addr);
+ if (sta_ptr && sta_ptr->is_11n_enabled) {
+ mwifiex_11n_del_rx_reorder_tbl_by_ta(priv,
+ ibss_sta_addr);
+ mwifiex_del_tx_ba_stream_tbl_by_ra(priv, ibss_sta_addr);
+ }
+ mwifiex_wmm_del_peer_ra_list(priv, ibss_sta_addr);
+ mwifiex_del_sta_entry(priv, ibss_sta_addr);
+ break;
case EVENT_ADDBA:
mwifiex_dbg(adapter, EVENT, "event: ADDBA Request\n");
mwifiex_send_cmd(priv, HostCmd_CMD_11N_ADDBA_RSP,
--
1.9.1
^ permalink raw reply related
* [PATCH 7/9] mwifiex: remove misleading disconnect message
From: Amitkumar Karwar @ 2016-07-11 14:53 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1468248832-21969-1-git-send-email-akarwar@marvell.com>
Disconnect message in mwifiex_reset_connect_state() would displays
necessary information. We unnecessarily have exactly same message in
cfg80211_disconnect(). As priv->cfg_bssid is cleared at this point of
time, it prints incorrect(all zero) MAC.
This message is removed here.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index bf95cca..73dd39d 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -2022,10 +2022,6 @@ mwifiex_cfg80211_disconnect(struct wiphy *wiphy, struct net_device *dev,
if (mwifiex_deauthenticate(priv, NULL))
return -EFAULT;
- mwifiex_dbg(priv->adapter, MSG,
- "info: successfully disconnected from %pM:\t"
- "reason code %d\n", priv->cfg_bssid, reason_code);
-
eth_zero_addr(priv->cfg_bssid);
priv->hs2_enabled = false;
--
1.9.1
^ permalink raw reply related
* [PATCH 5/9] mwifiex: cfg80211 set_default_mgmt_key handler
From: Amitkumar Karwar @ 2016-07-11 14:53 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1468248832-21969-1-git-send-email-akarwar@marvell.com>
It is observed that hostapd fails to setup with management frame
protection mode enabled when using mwifiex. This patch adds
cfg80211_set_default_mgmt_key handler to resolve the problem.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 8955f8c..bf95cca 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -484,6 +484,18 @@ mwifiex_cfg80211_add_key(struct wiphy *wiphy, struct net_device *netdev,
}
/*
+ * CFG802.11 operation handler to set default mgmt key.
+ */
+static int
+mwifiex_cfg80211_set_default_mgmt_key(struct wiphy *wiphy,
+ struct net_device *netdev,
+ u8 key_index)
+{
+ wiphy_dbg(wiphy, "set default mgmt key, key index=%d\n", key_index);
+ return 0;
+}
+
+/*
* This function sends domain information to the firmware.
*
* The following information are passed to the firmware -
@@ -4002,6 +4014,7 @@ static struct cfg80211_ops mwifiex_cfg80211_ops = {
.leave_ibss = mwifiex_cfg80211_leave_ibss,
.add_key = mwifiex_cfg80211_add_key,
.del_key = mwifiex_cfg80211_del_key,
+ .set_default_mgmt_key = mwifiex_cfg80211_set_default_mgmt_key,
.mgmt_tx = mwifiex_cfg80211_mgmt_tx,
.mgmt_frame_register = mwifiex_cfg80211_mgmt_frame_register,
.remain_on_channel = mwifiex_cfg80211_remain_on_channel,
--
1.9.1
^ permalink raw reply related
* [PATCH 6/9] mwifiex: process rxba_sync event
From: Amitkumar Karwar @ 2016-07-11 14:53 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1468248832-21969-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
Firmware may filter and drop packets under certain condition, for
example, ARP SA=DA packet. this event will be used to synchronize
the Rx Block Acknowledgment (BA) window bitmap and to fill any holes
in driver side.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
.../net/wireless/marvell/mwifiex/11n_rxreorder.c | 79 +++++++++++++++++++++-
.../net/wireless/marvell/mwifiex/11n_rxreorder.h | 6 +-
drivers/net/wireless/marvell/mwifiex/fw.h | 12 ++++
drivers/net/wireless/marvell/mwifiex/sta_event.c | 6 ++
drivers/net/wireless/marvell/mwifiex/uap_event.c | 7 +-
5 files changed, 107 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
index a74cc43..96b411e 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
+++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
@@ -78,8 +78,15 @@ static int mwifiex_11n_dispatch_amsdu_pkt(struct mwifiex_private *priv,
*/
static int mwifiex_11n_dispatch_pkt(struct mwifiex_private *priv, void *payload)
{
- int ret = mwifiex_11n_dispatch_amsdu_pkt(priv, payload);
+ int ret;
+
+ if (payload == (void *)MWIFIEX_RX_PKT_DROPPED_IN_FW) {
+ mwifiex_dbg(priv->adapter, INFO, "info: fw drop data\n");
+ return 0;
+ }
+
+ ret = mwifiex_11n_dispatch_amsdu_pkt(priv, payload);
if (!ret)
return 0;
@@ -921,3 +928,73 @@ void mwifiex_coex_ampdu_rxwinsize(struct mwifiex_adapter *adapter)
else
mwifiex_update_ampdu_rxwinsize(adapter, false);
}
+
+/* This function handles rxba_sync event
+ */
+void mwifiex_11n_rxba_sync_event(struct mwifiex_private *priv,
+ u8 *event_buf, u16 len)
+{
+ struct mwifiex_ie_types_rxba_sync *tlv_rxba = (void *)event_buf;
+ u16 tlv_type, tlv_len;
+ struct mwifiex_rx_reorder_tbl *rx_reor_tbl_ptr;
+ u8 i, j;
+ u16 seq_num, tlv_seq_num, tlv_bitmap_len;
+ int tlv_buf_left = len;
+ int ret;
+ u8 *tmp;
+
+ mwifiex_dbg_dump(priv->adapter, EVT_D, "RXBA_SYNC event:",
+ event_buf, len);
+ while (tlv_buf_left >= sizeof(*tlv_rxba)) {
+ tlv_type = le16_to_cpu(tlv_rxba->header.type);
+ tlv_len = le16_to_cpu(tlv_rxba->header.len);
+ if (tlv_type != TLV_TYPE_RXBA_SYNC) {
+ mwifiex_dbg(priv->adapter, ERROR,
+ "Wrong TLV id=0x%x\n", tlv_type);
+ return;
+ }
+
+ tlv_seq_num = le16_to_cpu(tlv_rxba->seq_num);
+ tlv_bitmap_len = le16_to_cpu(tlv_rxba->bitmap_len);
+ mwifiex_dbg(priv->adapter, INFO,
+ "%pM tid=%d seq_num=%d bitmap_len=%d\n",
+ tlv_rxba->mac, tlv_rxba->tid, tlv_seq_num,
+ tlv_bitmap_len);
+
+ rx_reor_tbl_ptr =
+ mwifiex_11n_get_rx_reorder_tbl(priv, tlv_rxba->tid,
+ tlv_rxba->mac);
+ if (!rx_reor_tbl_ptr) {
+ mwifiex_dbg(priv->adapter, ERROR,
+ "Can not find rx_reorder_tbl!");
+ return;
+ }
+
+ for (i = 0; i < tlv_bitmap_len; i++) {
+ for (j = 0 ; j < 8; j++) {
+ if (tlv_rxba->bitmap[i] & (1 << j)) {
+ seq_num = (MAX_TID_VALUE - 1) &
+ (tlv_seq_num + i * 8 + j);
+
+ mwifiex_dbg(priv->adapter, ERROR,
+ "drop packet,seq=%d\n",
+ seq_num);
+
+ ret = mwifiex_11n_rx_reorder_pkt
+ (priv, seq_num, tlv_rxba->tid,
+ tlv_rxba->mac, 0,
+ (void *)MWIFIEX_RX_PKT_DROPPED_IN_FW);
+
+ if (ret)
+ mwifiex_dbg(priv->adapter,
+ ERROR,
+ "Fail to drop packet");
+ }
+ }
+ }
+
+ tlv_buf_left -= (sizeof(*tlv_rxba) + tlv_len);
+ tmp = (u8 *)tlv_rxba + tlv_len + sizeof(*tlv_rxba);
+ tlv_rxba = (struct mwifiex_ie_types_rxba_sync *)tmp;
+ }
+}
diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.h b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.h
index 63ecea8..05c2243 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.h
+++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.h
@@ -43,6 +43,9 @@
#define BA_SETUP_MAX_PACKET_THRESHOLD 16
#define BA_SETUP_PACKET_OFFSET 16
+/* Indicate packet has been dropped in FW */
+#define MWIFIEX_RX_PKT_DROPPED_IN_FW 0xffffffff
+
enum mwifiex_rxreor_flags {
RXREOR_FORCE_NO_DROP = 1<<0,
RXREOR_INIT_WINDOW_SHIFT = 1<<1,
@@ -81,5 +84,6 @@ struct mwifiex_rx_reorder_tbl *
mwifiex_11n_get_rx_reorder_tbl(struct mwifiex_private *priv, int tid, u8 *ta);
void mwifiex_11n_del_rx_reorder_tbl_by_ta(struct mwifiex_private *priv, u8 *ta);
void mwifiex_update_rxreor_flags(struct mwifiex_adapter *adapter, u8 flags);
-
+void mwifiex_11n_rxba_sync_event(struct mwifiex_private *priv,
+ u8 *event_buf, u16 len);
#endif /* _MWIFIEX_11N_RXREORDER_H_ */
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h
index 3797ef4..3b40e0d 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -176,6 +176,7 @@ enum MWIFIEX_802_11_PRIVACY_FILTER {
#define TLV_TYPE_PWK_CIPHER (PROPRIETARY_TLV_BASE_ID + 145)
#define TLV_TYPE_GWK_CIPHER (PROPRIETARY_TLV_BASE_ID + 146)
#define TLV_TYPE_TX_PAUSE (PROPRIETARY_TLV_BASE_ID + 148)
+#define TLV_TYPE_RXBA_SYNC (PROPRIETARY_TLV_BASE_ID + 153)
#define TLV_TYPE_COALESCE_RULE (PROPRIETARY_TLV_BASE_ID + 154)
#define TLV_TYPE_KEY_PARAM_V2 (PROPRIETARY_TLV_BASE_ID + 156)
#define TLV_TYPE_REPEAT_COUNT (PROPRIETARY_TLV_BASE_ID + 176)
@@ -532,6 +533,7 @@ enum P2P_MODES {
#define EVENT_CHANNEL_REPORT_RDY 0x00000054
#define EVENT_TX_DATA_PAUSE 0x00000055
#define EVENT_EXT_SCAN_REPORT 0x00000058
+#define EVENT_RXBA_SYNC 0x00000059
#define EVENT_BG_SCAN_STOPPED 0x00000065
#define EVENT_REMAIN_ON_CHAN_EXPIRED 0x0000005f
#define EVENT_MULTI_CHAN_INFO 0x0000006a
@@ -735,6 +737,16 @@ struct mwifiex_ie_types_chan_list_param_set {
struct mwifiex_chan_scan_param_set chan_scan_param[1];
} __packed;
+struct mwifiex_ie_types_rxba_sync {
+ struct mwifiex_ie_types_header header;
+ u8 mac[ETH_ALEN];
+ u8 tid;
+ u8 reserved;
+ __le16 seq_num;
+ __le16 bitmap_len;
+ u8 bitmap[1];
+} __packed;
+
struct chan_band_param_set {
u8 radio_type;
u8 chan_number;
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_event.c b/drivers/net/wireless/marvell/mwifiex/sta_event.c
index 7e394d4..b973ee8 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_event.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_event.c
@@ -873,6 +873,12 @@ int mwifiex_process_sta_event(struct mwifiex_private *priv)
mwifiex_bt_coex_wlan_param_update_event(priv,
adapter->event_skb);
break;
+ case EVENT_RXBA_SYNC:
+ dev_dbg(adapter->dev, "EVENT: RXBA_SYNC\n");
+ mwifiex_11n_rxba_sync_event(priv, adapter->event_body,
+ adapter->event_skb->len -
+ sizeof(eventcause));
+ break;
default:
mwifiex_dbg(adapter, ERROR, "event: unknown event id: %#x\n",
eventcause);
diff --git a/drivers/net/wireless/marvell/mwifiex/uap_event.c b/drivers/net/wireless/marvell/mwifiex/uap_event.c
index 86ff542..d24eca3 100644
--- a/drivers/net/wireless/marvell/mwifiex/uap_event.c
+++ b/drivers/net/wireless/marvell/mwifiex/uap_event.c
@@ -306,7 +306,12 @@ int mwifiex_process_uap_event(struct mwifiex_private *priv)
mwifiex_dbg(adapter, EVENT, "event: multi-chan info\n");
mwifiex_process_multi_chan_event(priv, adapter->event_skb);
break;
-
+ case EVENT_RXBA_SYNC:
+ dev_dbg(adapter->dev, "EVENT: RXBA_SYNC\n");
+ mwifiex_11n_rxba_sync_event(priv, adapter->event_body,
+ adapter->event_skb->len -
+ sizeof(eventcause));
+ break;
default:
mwifiex_dbg(adapter, EVENT,
"event: unknown event id: %#x\n", eventcause);
--
1.9.1
^ permalink raw reply related
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