* [PATCH 2/3] NFC: pn533: improve cmd queue handling
From: Andrey Rusalin @ 2016-12-28 17:10 UTC (permalink / raw)
To: lauro.venancio, aloisio.almeida, sameo, michael.thalmeier,
linux-wireless, linux-nfc
Cc: Andrey Rusalin
In-Reply-To: <1482945059-12249-1-git-send-email-arusalin@dev.rtsoft.ru>
Make sure cmd is set before a frame is passed to the transport layer for
sending. In addition pn533_send_async_complete checks if cmd is set before
accessing its members.
Signed-off-by: Michael Thalmeier <michael.thalmeier@hale.at>
Rework a little bit changes in pn532_send_async_complete.
Signed-off-by: Andrey Rusalin <arusalin@dev.rtsoft.ru>
---
drivers/nfc/pn533/pn533.c | 40 +++++++++++++++++++++++++++-------------
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c
index 2f817b3..c67150f 100644
--- a/drivers/nfc/pn533/pn533.c
+++ b/drivers/nfc/pn533/pn533.c
@@ -383,14 +383,18 @@ static void pn533_build_cmd_frame(struct pn533 *dev, u8 cmd_code,
static int pn533_send_async_complete(struct pn533 *dev)
{
struct pn533_cmd *cmd = dev->cmd;
- int status = cmd->status;
+ struct sk_buff *resp;
+ int status, rc = 0;
- struct sk_buff *req = cmd->req;
- struct sk_buff *resp = cmd->resp;
+ if (!cmd) {
+ dev_dbg(dev->dev, "%s: cmd not set\n", __func__);
+ goto done;
+ }
- int rc;
+ dev_kfree_skb(cmd->req);
- dev_kfree_skb(req);
+ status = cmd->status;
+ resp = cmd->resp;
if (status < 0) {
rc = cmd->complete_cb(dev, cmd->complete_cb_context,
@@ -399,8 +403,14 @@ static int pn533_send_async_complete(struct pn533 *dev)
goto done;
}
- skb_pull(resp, dev->ops->rx_header_len);
- skb_trim(resp, resp->len - dev->ops->rx_tail_len);
+ /* when no response is set we got interrupted */
+ if (!resp)
+ resp = ERR_PTR(-EINTR);
+
+ if (!IS_ERR(resp)) {
+ skb_pull(resp, dev->ops->rx_header_len);
+ skb_trim(resp, resp->len - dev->ops->rx_tail_len);
+ }
rc = cmd->complete_cb(dev, cmd->complete_cb_context, resp);
@@ -434,12 +444,14 @@ static int __pn533_send_async(struct pn533 *dev, u8 cmd_code,
mutex_lock(&dev->cmd_lock);
if (!dev->cmd_pending) {
+ dev->cmd = cmd;
rc = dev->phy_ops->send_frame(dev, req);
- if (rc)
+ if (rc) {
+ dev->cmd = NULL;
goto error;
+ }
dev->cmd_pending = 1;
- dev->cmd = cmd;
goto unlock;
}
@@ -511,11 +523,12 @@ static int pn533_send_cmd_direct_async(struct pn533 *dev, u8 cmd_code,
pn533_build_cmd_frame(dev, cmd_code, req);
+ dev->cmd = cmd;
rc = dev->phy_ops->send_frame(dev, req);
- if (rc < 0)
+ if (rc < 0) {
+ dev->cmd = NULL;
kfree(cmd);
- else
- dev->cmd = cmd;
+ }
return rc;
}
@@ -550,14 +563,15 @@ static void pn533_wq_cmd(struct work_struct *work)
mutex_unlock(&dev->cmd_lock);
+ dev->cmd = cmd;
rc = dev->phy_ops->send_frame(dev, cmd->req);
if (rc < 0) {
+ dev->cmd = NULL;
dev_kfree_skb(cmd->req);
kfree(cmd);
return;
}
- dev->cmd = cmd;
}
struct pn533_sync_cmd_response {
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] NFC: pn533: change order of free_irq and dev unregistration
From: Andrey Rusalin @ 2016-12-28 17:10 UTC (permalink / raw)
To: lauro.venancio, aloisio.almeida, sameo, michael.thalmeier,
linux-wireless, linux-nfc
Cc: Andrey Rusalin
In-Reply-To: <1482945059-12249-1-git-send-email-arusalin@dev.rtsoft.ru>
Change order of free_irq and dev unregistration.
It fixes situation when device already unregistered and
an interrupt happens and nobody can handle it.
Signed-off-by: Andrey Rusalin <arusalin@dev.rtsoft.ru>
---
drivers/nfc/pn533/i2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c
index 5de5a49..e2848e4 100644
--- a/drivers/nfc/pn533/i2c.c
+++ b/drivers/nfc/pn533/i2c.c
@@ -242,10 +242,10 @@ static int pn533_i2c_remove(struct i2c_client *client)
dev_dbg(&client->dev, "%s\n", __func__);
- pn533_unregister_device(phy->priv);
-
free_irq(client->irq, phy);
+ pn533_unregister_device(phy->priv);
+
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 0/3] NFC: pn533: fixes for i2c driver
From: Andrey Rusalin @ 2016-12-28 17:10 UTC (permalink / raw)
To: lauro.venancio, aloisio.almeida, sameo, michael.thalmeier,
linux-wireless, linux-nfc
Cc: Andrey Rusalin
Each of these patches fix some oops that I met during
tests of the driver with itead pn532 nfc module.
First and third patches related to order of initialization driver,
where interrupt handler was registered before work queues
were ready to handle it.
Also iqr was freed already after work queues were deinitialized.
Second patch originally sent by Michael Thalmeier.
I reworked a little bit to make it more readable.
Andrey Rusalin (3):
NFC: pn533: change order of free_irq and dev unregistration
NFC: pn533: improve cmd queue handling
NFC: pn533: change order operations in dev registation
drivers/nfc/pn533/i2c.c | 32 +++++++++++-------
drivers/nfc/pn533/pn533.c | 82 ++++++++++++++++++++++++++++++-----------------
drivers/nfc/pn533/pn533.h | 1 +
drivers/nfc/pn533/usb.c | 4 +++
4 files changed, 77 insertions(+), 42 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 3/3] NFC: pn533: change order operations in dev registation
From: Andrey Rusalin @ 2016-12-28 17:10 UTC (permalink / raw)
To: lauro.venancio, aloisio.almeida, sameo, michael.thalmeier,
linux-wireless, linux-nfc
Cc: Andrey Rusalin
In-Reply-To: <1482945059-12249-1-git-send-email-arusalin@dev.rtsoft.ru>
Sometimes during probing and registration of pn533_i2c
NULL pointer dereference happens.
Reproduced in cycle of inserting and removing pn533_i2c
and pn533 modules.
Backtrace:
[<8004205c>] (__queue_work) from [<80042324>] (queue_work_on+0x50/0x5c)
r10:acdc7c80 r9:8006b330 r8:ac0dfb40 r7:ac50c600 r6:00000004 r5:acbbee40 r4:600f0113
[<800422d4>] (queue_work_on) from [<7f7d5b6c>] (pn533_recv_frame+0x158/0x1fc [pn533])
r7:ffffff87 r6:00000000 r5:acbbee40 r4:acbbee00
[<7f7d5a14>] (pn533_recv_frame [pn533]) from [<7f7df4b8>] (pn533_i2c_irq_thread_fn+0x184/0x)
r6:acb2a000 r5:00000000 r4:acdc7b90
[<7f7df334>] (pn533_i2c_irq_thread_fn [pn533_i2c]) from [<8006b354>] (irq_thread_fn+0x24/0x)
r7:00000000 r6:accde000 r5:ac0dfb40 r4:acdc7c80
...
Seems there is some race condition due registration of
irq handler until all data stuctures that could be needed
are ready. So I re-ordered some ops. After this, problem has gone.
Changes in USB part was not tested, but it should not break
anything.
Signed-off-by: Andrey Rusalin <arusalin@dev.rtsoft.ru>
---
drivers/nfc/pn533/i2c.c | 28 ++++++++++++++++++----------
drivers/nfc/pn533/pn533.c | 42 +++++++++++++++++++++++++-----------------
drivers/nfc/pn533/pn533.h | 1 +
drivers/nfc/pn533/usb.c | 4 ++++
4 files changed, 48 insertions(+), 27 deletions(-)
diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c
index e2848e4..c1302de 100644
--- a/drivers/nfc/pn533/i2c.c
+++ b/drivers/nfc/pn533/i2c.c
@@ -206,14 +206,6 @@ static int pn533_i2c_probe(struct i2c_client *client,
phy->i2c_dev = client;
i2c_set_clientdata(client, phy);
- r = request_threaded_irq(client->irq, NULL, pn533_i2c_irq_thread_fn,
- IRQF_TRIGGER_FALLING |
- IRQF_SHARED | IRQF_ONESHOT,
- PN533_I2C_DRIVER_NAME, phy);
-
- if (r < 0)
- nfc_err(&client->dev, "Unable to register IRQ handler\n");
-
priv = pn533_register_device(PN533_DEVICE_PN532,
PN533_NO_TYPE_B_PROTOCOLS,
PN533_PROTO_REQ_ACK_RESP,
@@ -223,16 +215,32 @@ static int pn533_i2c_probe(struct i2c_client *client,
if (IS_ERR(priv)) {
r = PTR_ERR(priv);
- goto err_register;
+ return r;
}
phy->priv = priv;
+ r = request_threaded_irq(client->irq, NULL, pn533_i2c_irq_thread_fn,
+ IRQF_TRIGGER_FALLING |
+ IRQF_SHARED | IRQF_ONESHOT,
+ PN533_I2C_DRIVER_NAME, phy);
+ if (r < 0) {
+ nfc_err(&client->dev, "Unable to register IRQ handler\n");
+ goto irq_rqst_err;
+ }
+
+ r = pn533_finalize_setup(priv);
+ if (r)
+ goto fn_setup_err;
+
return 0;
-err_register:
+fn_setup_err:
free_irq(client->irq, phy);
+irq_rqst_err:
+ pn533_unregister_device(phy->priv);
+
return r;
}
diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c
index c67150f..bbae44b 100644
--- a/drivers/nfc/pn533/pn533.c
+++ b/drivers/nfc/pn533/pn533.c
@@ -2570,6 +2570,31 @@ static int pn533_setup(struct pn533 *dev)
return 0;
}
+int pn533_finalize_setup(struct pn533 *dev)
+{
+
+ struct pn533_fw_version fw_ver;
+ int rc;
+
+ memset(&fw_ver, 0, sizeof(fw_ver));
+
+ rc = pn533_get_firmware_version(dev, &fw_ver);
+ if (rc) {
+ nfc_err(dev->dev, "Unable to get FW version\n");
+ return rc;
+ }
+
+ nfc_info(dev->dev, "NXP PN5%02X firmware ver %d.%d now attached\n",
+ fw_ver.ic, fw_ver.ver, fw_ver.rev);
+
+ rc = pn533_setup(dev);
+ if (rc)
+ return rc;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pn533_finalize_setup);
+
struct pn533 *pn533_register_device(u32 device_type,
u32 protocols,
enum pn533_protocol_type protocol_type,
@@ -2579,7 +2604,6 @@ struct pn533 *pn533_register_device(u32 device_type,
struct device *dev,
struct device *parent)
{
- struct pn533_fw_version fw_ver;
struct pn533 *priv;
int rc = -ENOMEM;
@@ -2622,15 +2646,6 @@ struct pn533 *pn533_register_device(u32 device_type,
INIT_LIST_HEAD(&priv->cmd_queue);
- memset(&fw_ver, 0, sizeof(fw_ver));
- rc = pn533_get_firmware_version(priv, &fw_ver);
- if (rc < 0)
- goto destroy_wq;
-
- nfc_info(dev, "NXP PN5%02X firmware ver %d.%d now attached\n",
- fw_ver.ic, fw_ver.ver, fw_ver.rev);
-
-
priv->nfc_dev = nfc_allocate_device(&pn533_nfc_ops, protocols,
priv->ops->tx_header_len +
PN533_CMD_DATAEXCH_HEAD_LEN,
@@ -2647,15 +2662,8 @@ struct pn533 *pn533_register_device(u32 device_type,
if (rc)
goto free_nfc_dev;
- rc = pn533_setup(priv);
- if (rc)
- goto unregister_nfc_dev;
-
return priv;
-unregister_nfc_dev:
- nfc_unregister_device(priv->nfc_dev);
-
free_nfc_dev:
nfc_free_device(priv->nfc_dev);
diff --git a/drivers/nfc/pn533/pn533.h b/drivers/nfc/pn533/pn533.h
index e26d634..12ea04e 100644
--- a/drivers/nfc/pn533/pn533.h
+++ b/drivers/nfc/pn533/pn533.h
@@ -231,6 +231,7 @@ struct pn533 *pn533_register_device(u32 device_type,
struct device *dev,
struct device *parent);
+int pn533_finalize_setup(struct pn533 *dev);
void pn533_unregister_device(struct pn533 *priv);
void pn533_recv_frame(struct pn533 *dev, struct sk_buff *skb, int status);
diff --git a/drivers/nfc/pn533/usb.c b/drivers/nfc/pn533/usb.c
index bcf3f54..909806f 100644
--- a/drivers/nfc/pn533/usb.c
+++ b/drivers/nfc/pn533/usb.c
@@ -543,6 +543,10 @@ static int pn533_usb_probe(struct usb_interface *interface,
phy->priv = priv;
+ rc = pn533_finalize_setup(priv);
+ if (rc)
+ goto error;
+
usb_set_intfdata(interface, phy);
return 0;
--
2.7.4
^ permalink raw reply related
* BCM43602 -- Bluetooth while WiFi on 2.4GHz networks
From: Greg Oliver @ 2016-12-28 16:59 UTC (permalink / raw)
To: linux-wireless
I have been fighting this laptop (MacBookPro11,5) for a year now with
linux (mainly on Thunderbolt and power issues), but this is one of the
last ones that remains.
The system contains a BCM 43602 (rebranded by Apple of course):
04:00.0 Network controller [0280]: Broadcom Limited BCM43602 802.11ac
Wireless LAN SoC [14e4:43ba] (rev 01)
Subsystem: Apple Inc. Device [106b:0152]
Flags: bus master, fast devsel, latency 0, IRQ 49
Memory at b0800000 (64-bit, non-prefetchable) [size=32K]
Memory at b0400000 (64-bit, non-prefetchable) [size=4M]
Capabilities: [48] Power Management version 3
Capabilities: [58] MSI: Enable+ Count=1/16 Maskable- 64bit+
Capabilities: [68] Vendor Specific Information: Len=44 <?>
Capabilities: [ac] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [13c] Device Serial Number cd-97-9b-ff-ff-0b-a0-99
Capabilities: [150] Power Budgeting <?>
Capabilities: [160] Virtual Channel
Capabilities: [1b0] Latency Tolerance Reporting
Capabilities: [220] #15
Capabilities: [240] L1 PM Substates
Kernel driver in use: brcmfmac
Kernel modules: brcmfmac
Modules options in use:
alternative_fw_path ::
debug :: 0
roamoff :: 1
Linux macbook 4.8.14-301.fc25.x86_64 #1 SMP Sun Dec 25 12:49:05 CST
2016 x86_64 x86_64 x86_64 GNU/Linux
Basically when wifi is on a 2.4G frequency, bluetooth (my keyboard and
mouse) are erratic (all over the place) - mouse stutters and keyboard
loses / repeats keys constantly. In the past I have used atheros and
intel nics with their bt coexistent modes, but I do not see that
option for broadcom modules.
Is there a trick to getting them to play nice? At home, it is not an
issue as I use 5GHz bands, but many times at customers they only have
2.4 on their "vendor supported" APs for me to use, so my mouse is a
no-go (and I truly hate trackpads).
Thanks for any help, and I can provide any info needed. This seems to
be a common issue, but I do not see where anyone has fixed it or
posted to linux-wireless as of yet.
Thanks
-Greg
^ permalink raw reply
* [PATCH 2/2] cfg80211: reg: support ieee80211-(min|max)-center-freq DT properties
From: Rafał Miłecki @ 2016-12-28 15:59 UTC (permalink / raw)
To: Kalle Valo, linux-wireless
Cc: Martin Blumenstingl, Felix Fietkau, Arnd Bergmann, devicetree,
Rafał Miłecki
In-Reply-To: <20161228155955.25518-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
They allow specifying hardware limitations of supported channels. This
may be useful for specifying single band devices or devices that support
only some part of the whole band.
E.g. some tri-band routers have separated radios for lower and higher
part of 5 GHz band.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
net/wireless/reg.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..35ba5c7 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1123,6 +1123,26 @@ const char *reg_initiator_name(enum nl80211_reg_initiator initiator)
}
EXPORT_SYMBOL(reg_initiator_name);
+static bool reg_center_freq_of_valid(struct wiphy *wiphy,
+ struct ieee80211_channel *chan)
+{
+ struct device_node *np = wiphy_dev(wiphy)->of_node;
+ u32 val;
+
+ if (!np)
+ return true;
+
+ if (!of_property_read_u32(np, "ieee80211-min-center-freq", &val) &&
+ chan->center_freq < KHZ_TO_MHZ(val))
+ return false;
+
+ if (!of_property_read_u32(np, "ieee80211-max-center-freq", &val) &&
+ chan->center_freq > KHZ_TO_MHZ(val))
+ return false;
+
+ return true;
+}
+
static uint32_t reg_rule_to_chan_bw_flags(const struct ieee80211_regdomain *regd,
const struct ieee80211_reg_rule *reg_rule,
const struct ieee80211_channel *chan)
@@ -1209,6 +1229,13 @@ static void handle_channel(struct wiphy *wiphy,
return;
}
+ if (!reg_center_freq_of_valid(wiphy, chan)) {
+ pr_debug("Disabling freq %d MHz as it's out of OF limits\n",
+ chan->center_freq);
+ chan->flags |= IEEE80211_CHAN_DISABLED;
+ return;
+ }
+
regd = reg_get_regdomain(wiphy);
power_rule = ®_rule->power_rule;
@@ -1741,6 +1768,13 @@ static void handle_channel_custom(struct wiphy *wiphy,
return;
}
+ if (!reg_center_freq_of_valid(wiphy, chan)) {
+ pr_debug("Disabling freq %d MHz as it's out of OF limits\n",
+ chan->center_freq);
+ chan->flags |= IEEE80211_CHAN_DISABLED;
+ return;
+ }
+
power_rule = ®_rule->power_rule;
bw_flags = reg_rule_to_chan_bw_flags(regd, reg_rule, chan);
--
2.10.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: document common IEEE 802.11 frequency properties
From: Rafał Miłecki @ 2016-12-28 15:59 UTC (permalink / raw)
To: Kalle Valo, linux-wireless
Cc: Martin Blumenstingl, Felix Fietkau, Arnd Bergmann, devicetree,
Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
This new file should be used for properties handled at higher level and
so usable with all drivers.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
.../devicetree/bindings/net/wireless/ieee80211.txt | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee80211.txt
diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
new file mode 100644
index 0000000..c762769
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
@@ -0,0 +1,16 @@
+Common IEEE 802.11 properties
+
+This provides documentation of common properties that are handled by a proper
+net layer and don't require extra driver code.
+
+Optional properties:
+ - ieee80211-min-center-freq : minimal supported frequency in KHz
+ - ieee80211-max-center-freq : maximal supported frequency in KHz
+
+Example:
+
+pcie@0,0 {
+ reg = <0x0000 0 0 0 0>;
+ ieee80211-min-center-freq = <2437000>;
+ ieee80211-max-center-freq = <2457000>;
+};
--
2.10.1
^ permalink raw reply related
* Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding
From: Rafał Miłecki @ 2016-12-28 13:51 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Kalle Valo, Arnd Bergmann, Felix Fietkau,
linux-wireless@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <CACna6rzKc8kAnc2_Ca8pXtuu9Rw2mjqfV8VNumoF_E7GdvJx-g@mail.gmail.com>
On 28 December 2016 at 14:28, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> wr=
ote:
> On 28 December 2016 at 11:43, Martin Blumenstingl
> <martin.blumenstingl@googlemail.com> wrote:
>> should we describe the center freq in Hz or MHz (cfg80211's
>> ieee80211_channel uses the latter)?
>
> Is there any case that may require HZ accuracy? I was thinking about usin=
g MHz.
Regulatory code uses KHz, so we may better do the same.
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding
From: Rafał Miłecki @ 2016-12-28 13:28 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Kalle Valo, Arnd Bergmann, Felix Fietkau,
linux-wireless@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <CAFBinCBzz0Jvk_jcWAJ1jEz17r-NYEE87xLUACTybRSHGE7uGA@mail.gmail.com>
On 28 December 2016 at 11:43, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
> On Wed, Dec 28, 2016 at 11:08 AM, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.c=
om> wrote:
>> On 3 October 2016 at 15:29, Kalle Valo <kvalo@codeaurora.org> wrote:
>>> Arnd Bergmann <arnd@arndb.de> writes:
>>>
>>>> On Friday 30 September 2016, Felix Fietkau wrote:
>>>>> >> >> >> + device_type =3D "pci";
>>>>> >> >> >> + mediatek,mtd-eeprom =3D <&factory 0x8000>;
>>>>> >> >> >> + mediatek,2ghz =3D <0>;
>>>>> >> >
>>>>> >> > It's not clear what the possible values for the 2ghz property ar=
e,
>>>>> >> > can you be more verbose in the description? How is <0> different
>>>>> >> > from no property?
>>>>> >> 0 means disabled, no property means unchanged (compared to EEPROM)=
.
>>>>> >
>>>>> > Maybe have a boolean property instead then to say "mediatek,2ghz-di=
sabled" ?
>>>>> >
>>>>> > If zero is the only possible value, there is no need to put a numbe=
r in there.
>>>>> 1 is also possible, which will force-enable the capability.
>>>>
>>>> Ok, then both those values should be documented in the binding.
>>>
>>> Related to this, Martin sent patches which add generic bindings for
>>> enabling 2 Ghz and 5 Ghz bands.
>>>
>>> [RFC,1/3] Documentation: dt-bindings: add IEEE 802.11 binding documenta=
tion
>>> https://patchwork.kernel.org/patch/9359833/
>>>
>>> [RFC,2/3] of: add IEEE 802.11 device configuration support code
>>> https://patchwork.kernel.org/patch/9359837/
>>
>> I would prefer something more generic. Many tri-band routers split 5
>> GHz band into 2 sets of channels and they have separated radios for
>> them.
>>
>> E.g. Netgear R8000 has phy0 which should be used for higher part of 5
>> GHz band (channels 149+) and phy2 which should be used for lower part
>> of 5 GHz band (channels from 36 to 48 or 64).
>>
>> What do you think about some more flexible properties like:
>> ieee80211-min-center-freq
>> ieee80211-max-center-freq
> what would happen if only one of these properties was given or would
> we forbid that (because the .dts should always describe the hardware,
> and if we describe a lower bound then we should also describe the
> upper bound)?
I didn't think about requiring both properties to be set, but if this
is more correct from DT point of view, we can always require that.
Let's see if we get DT guys opinion.
> the benefits of your solution are:
> - this would allow *enabling* bands as well (my proposal allows this
> as well, but the .dts is indeed a bit hard to read - unlike your
> solution which looks nice to me)
> - we could handle this within generic cfg80211/mac80211 code instead
> of "duplicating" it per driver
i'm happy to hear that :)
> should we describe the center freq in Hz or MHz (cfg80211's
> ieee80211_channel uses the latter)?
Is there any case that may require HZ accuracy? I was thinking about using =
MHz.
^ permalink raw reply
* Re: Intel Wireless 7260 failed to work
From: Kalle Valo @ 2016-12-28 12:13 UTC (permalink / raw)
To: Luca Coelho; +Cc: Peter Xu, Linux Kernel Mailing List, linux-wireless
In-Reply-To: <1482910035.8602.3.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> On Wed, 2016-12-28 at 11:59 +0800, Peter Xu wrote:
>> On Tue, Dec 27, 2016 at 09:46:55PM +0200, Kalle Valo wrote:
>> > Peter Xu <peterx@redhat.com> writes:
>> >
>> > > Looks like latest Linux master (4.10-rc1, 7ce7d89f) cannot work well
>> > > with my wireless card, which is:
>> > >
>> > > Intel Corporation Wireless 7260 (rev bb)
>> > >
>> > > Boot message shows that no suitable firmware found:
>> > >
>> > > # journalctl -kp3
>> > > Dec 27 16:38:00 kernel: Error parsing PCC subspaces from PCCT
>> > > Dec 27 16:38:00 kernel: mmc0: Unknown controller version (3). You may experience problems.
>> > > Dec 27 16:38:02 kernel: DMAR: DRHD: handling fault status reg 2
>> > > Dec 27 16:38:02 kernel: DMAR: [DMA Write] Request device [00:02.0] fault addr 7200000000 [fault reason 05] PTE Write a
>> > > Dec 27 16:38:03 kernel: tpm tpm0: A TPM error (6) occurred attempting to read a pcr value
>> > > Dec 27 16:38:04 kernel: iwlwifi 0000:03:00.0: no suitable firmware found!
>> > >
>> > > Linux stable/master (Linux 4.8-rc8, 08895a8b6b) works for me. And no
>> > > further tests have been done yet.
>> > >
>> > > Is this a known issue? Please let me know if anyone wants more info or
>> > > logs, since this error triggers easily (everytime I boot).
>> >
>> > The error message isn't really telling much to the user (hint hint) but
>> > I suspect this is by design:
>> >
>> > "iwlwifi: remove support for fw older than -17 and -22
>
> Right, we only maintain support for a certain number of firmware
> versions. The FW APIs change with time and we don't want to keep all
> legacy code supporting old firmwares in the driver forever.
>
> I agree that "no suitable firmware found!" is a bit scarce. I'll see
> if we can improve that with something: "no suitable firmware found! You
> need iwlwifi-7260-17.ucode (<link to git>)".
Yeah, something like that would be much more helpful for the user.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding
From: Martin Blumenstingl @ 2016-12-28 10:43 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Kalle Valo, Arnd Bergmann, Felix Fietkau,
linux-wireless@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <CACna6ryikdd0Yt2FWB_JT27N5uuh9XU+JUWNRjs4H5YcD5PVpw@mail.gmail.com>
On Wed, Dec 28, 2016 at 11:08 AM, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com=
> wrote:
> On 3 October 2016 at 15:29, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>>
>>> On Friday 30 September 2016, Felix Fietkau wrote:
>>>> >> >> >> + device_type =3D "pci";
>>>> >> >> >> + mediatek,mtd-eeprom =3D <&factory 0x8000>;
>>>> >> >> >> + mediatek,2ghz =3D <0>;
>>>> >> >
>>>> >> > It's not clear what the possible values for the 2ghz property are=
,
>>>> >> > can you be more verbose in the description? How is <0> different
>>>> >> > from no property?
>>>> >> 0 means disabled, no property means unchanged (compared to EEPROM).
>>>> >
>>>> > Maybe have a boolean property instead then to say "mediatek,2ghz-dis=
abled" ?
>>>> >
>>>> > If zero is the only possible value, there is no need to put a number=
in there.
>>>> 1 is also possible, which will force-enable the capability.
>>>
>>> Ok, then both those values should be documented in the binding.
>>
>> Related to this, Martin sent patches which add generic bindings for
>> enabling 2 Ghz and 5 Ghz bands.
>>
>> [RFC,1/3] Documentation: dt-bindings: add IEEE 802.11 binding documentat=
ion
>> https://patchwork.kernel.org/patch/9359833/
>>
>> [RFC,2/3] of: add IEEE 802.11 device configuration support code
>> https://patchwork.kernel.org/patch/9359837/
>
> I would prefer something more generic. Many tri-band routers split 5
> GHz band into 2 sets of channels and they have separated radios for
> them.
>
> E.g. Netgear R8000 has phy0 which should be used for higher part of 5
> GHz band (channels 149+) and phy2 which should be used for lower part
> of 5 GHz band (channels from 36 to 48 or 64).
>
> What do you think about some more flexible properties like:
> ieee80211-min-center-freq
> ieee80211-max-center-freq
what would happen if only one of these properties was given or would
we forbid that (because the .dts should always describe the hardware,
and if we describe a lower bound then we should also describe the
upper bound)?
the benefits of your solution are:
- this would allow *enabling* bands as well (my proposal allows this
as well, but the .dts is indeed a bit hard to read - unlike your
solution which looks nice to me)
- we could handle this within generic cfg80211/mac80211 code instead
of "duplicating" it per driver
should we describe the center freq in Hz or MHz (cfg80211's
ieee80211_channel uses the latter)?
@Arnd: what do you think from devicetree perspective?
Regards,
Martin
[0] http://lxr.free-electrons.com/source/include/net/cfg80211.h#L130
^ permalink raw reply
* Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding
From: Rafał Miłecki @ 2016-12-28 10:08 UTC (permalink / raw)
To: Kalle Valo
Cc: Arnd Bergmann, Felix Fietkau, linux-wireless@vger.kernel.org,
devicetree@vger.kernel.org, Martin Blumenstingl
In-Reply-To: <87vax9r26s.fsf@kamboji.qca.qualcomm.com>
On 3 October 2016 at 15:29, Kalle Valo <kvalo@codeaurora.org> wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
>> On Friday 30 September 2016, Felix Fietkau wrote:
>>> >> >> >> + device_type =3D "pci";
>>> >> >> >> + mediatek,mtd-eeprom =3D <&factory 0x8000>;
>>> >> >> >> + mediatek,2ghz =3D <0>;
>>> >> >
>>> >> > It's not clear what the possible values for the 2ghz property are,
>>> >> > can you be more verbose in the description? How is <0> different
>>> >> > from no property?
>>> >> 0 means disabled, no property means unchanged (compared to EEPROM).
>>> >
>>> > Maybe have a boolean property instead then to say "mediatek,2ghz-disa=
bled" ?
>>> >
>>> > If zero is the only possible value, there is no need to put a number =
in there.
>>> 1 is also possible, which will force-enable the capability.
>>
>> Ok, then both those values should be documented in the binding.
>
> Related to this, Martin sent patches which add generic bindings for
> enabling 2 Ghz and 5 Ghz bands.
>
> [RFC,1/3] Documentation: dt-bindings: add IEEE 802.11 binding documentati=
on
> https://patchwork.kernel.org/patch/9359833/
>
> [RFC,2/3] of: add IEEE 802.11 device configuration support code
> https://patchwork.kernel.org/patch/9359837/
I would prefer something more generic. Many tri-band routers split 5
GHz band into 2 sets of channels and they have separated radios for
them.
E.g. Netgear R8000 has phy0 which should be used for higher part of 5
GHz band (channels 149+) and phy2 which should be used for lower part
of 5 GHz band (channels from 36 to 48 or 64).
What do you think about some more flexible properties like:
ieee80211-min-center-freq
ieee80211-max-center-freq
--=20
Rafa=C5=82
^ permalink raw reply
* Re: Intel Wireless 7260 failed to work
From: Luca Coelho @ 2016-12-28 8:37 UTC (permalink / raw)
To: Emmanuel Grumbach, Peter Xu
Cc: Kalle Valo, Linux Kernel Mailing List, linux-wireless
In-Reply-To: <CANUX_P2ivxo6K6sy9d-OK5DAkcYeGb_43XQwazj+QPGk83EG1g@mail.gmail.com>
On Wed, 2016-12-28 at 10:17 +0200, Emmanuel Grumbach wrote:
> On Wed, Dec 28, 2016 at 10:10 AM, Peter Xu <peterx@redhat.com> wrote:
> > On Wed, Dec 28, 2016 at 09:27:15AM +0200, Luca Coelho wrote:
> >
> > [...]
> >
> > > > > > Is this a known issue? Please let me know if anyone wants more info or
> > > > > > logs, since this error triggers easily (everytime I boot).
> > > > >
> > > > > The error message isn't really telling much to the user (hint hint) but
> > > > > I suspect this is by design:
> > > > >
> > > > > "iwlwifi: remove support for fw older than -17 and -22
> > >
> > > Right, we only maintain support for a certain number of firmware
> > > versions. The FW APIs change with time and we don't want to keep all
> > > legacy code supporting old firmwares in the driver forever.
> > >
> > > I agree that "no suitable firmware found!" is a bit scarce. I'll see
> > > if we can improve that with something: "no suitable firmware found! You
> > > need iwlwifi-7260-17.ucode (<link to git>)".
> >
> > That'll be great if we can have this info in the log. Maybe no need
> > for a full URL, the firmware name would suffice at least for me.
>
> In this case, I think we should also print the range that is supported
> when we fail to find any suitable firmware.
Sure, I'll do that. I just wanted to keep it simple in this thread. ;)
--
Luca.
^ permalink raw reply
* Re: Intel Wireless 7260 failed to work
From: Emmanuel Grumbach @ 2016-12-28 8:17 UTC (permalink / raw)
To: Peter Xu; +Cc: Luca Coelho, Kalle Valo, Linux Kernel Mailing List,
linux-wireless
In-Reply-To: <20161228081039.GA3874@pxdev.xzpeter.org>
On Wed, Dec 28, 2016 at 10:10 AM, Peter Xu <peterx@redhat.com> wrote:
> On Wed, Dec 28, 2016 at 09:27:15AM +0200, Luca Coelho wrote:
>
> [...]
>
>> > > > Is this a known issue? Please let me know if anyone wants more info or
>> > > > logs, since this error triggers easily (everytime I boot).
>> > >
>> > > The error message isn't really telling much to the user (hint hint) but
>> > > I suspect this is by design:
>> > >
>> > > "iwlwifi: remove support for fw older than -17 and -22
>>
>> Right, we only maintain support for a certain number of firmware
>> versions. The FW APIs change with time and we don't want to keep all
>> legacy code supporting old firmwares in the driver forever.
>>
>> I agree that "no suitable firmware found!" is a bit scarce. I'll see
>> if we can improve that with something: "no suitable firmware found! You
>> need iwlwifi-7260-17.ucode (<link to git>)".
>
> That'll be great if we can have this info in the log. Maybe no need
> for a full URL, the firmware name would suffice at least for me.
In this case, I think we should also print the range that is supported
when we fail to find any suitable firmware.
>
> [...]
>
>> I don't think we are very aggressive, we have been supporting -17 since
>> v4.3:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5865f3658ba37c54e346b0fdee08a1c7a152681b
>>
>> And we have published the firmware about half a year ago:
>>
>> http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/iwlwifi-7260-17.ucode?id=f2cf4d67e8eced29c8a473d3a27057aa2df57c42
>>
>> I understand your concern, but if you want to be on the bleeding-edge
>> kernel, you should be on the bleeding-edge linux-firmware as well. ;)
>
> Fair enough. :-)
>
>>
>> But as I said, I'll try to improve the error message, as that should
>> make it easier to figure out.
>
> Thank you!
>
> -- peterx
^ permalink raw reply
* Re: Intel Wireless 7260 failed to work
From: Peter Xu @ 2016-12-28 8:10 UTC (permalink / raw)
To: Luca Coelho; +Cc: Kalle Valo, Linux Kernel Mailing List, linux-wireless
In-Reply-To: <1482910035.8602.3.camel@coelho.fi>
On Wed, Dec 28, 2016 at 09:27:15AM +0200, Luca Coelho wrote:
[...]
> > > > Is this a known issue? Please let me know if anyone wants more info or
> > > > logs, since this error triggers easily (everytime I boot).
> > >
> > > The error message isn't really telling much to the user (hint hint) but
> > > I suspect this is by design:
> > >
> > > "iwlwifi: remove support for fw older than -17 and -22
>
> Right, we only maintain support for a certain number of firmware
> versions. The FW APIs change with time and we don't want to keep all
> legacy code supporting old firmwares in the driver forever.
>
> I agree that "no suitable firmware found!" is a bit scarce. I'll see
> if we can improve that with something: "no suitable firmware found! You
> need iwlwifi-7260-17.ucode (<link to git>)".
That'll be great if we can have this info in the log. Maybe no need
for a full URL, the firmware name would suffice at least for me.
[...]
> I don't think we are very aggressive, we have been supporting -17 since
> v4.3:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5865f3658ba37c54e346b0fdee08a1c7a152681b
>
> And we have published the firmware about half a year ago:
>
> http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/iwlwifi-7260-17.ucode?id=f2cf4d67e8eced29c8a473d3a27057aa2df57c42
>
> I understand your concern, but if you want to be on the bleeding-edge
> kernel, you should be on the bleeding-edge linux-firmware as well. ;)
Fair enough. :-)
>
> But as I said, I'll try to improve the error message, as that should
> make it easier to figure out.
Thank you!
-- peterx
^ permalink raw reply
* Re: Intel Wireless 7260 failed to work
From: Luca Coelho @ 2016-12-28 7:27 UTC (permalink / raw)
To: Peter Xu, Kalle Valo; +Cc: Linux Kernel Mailing List, linux-wireless
In-Reply-To: <20161228035959.GB3924@pxdev.xzpeter.org>
On Wed, 2016-12-28 at 11:59 +0800, Peter Xu wrote:
> On Tue, Dec 27, 2016 at 09:46:55PM +0200, Kalle Valo wrote:
> > Peter Xu <peterx@redhat.com> writes:
> >
> > > Looks like latest Linux master (4.10-rc1, 7ce7d89f) cannot work well
> > > with my wireless card, which is:
> > >
> > > Intel Corporation Wireless 7260 (rev bb)
> > >
> > > Boot message shows that no suitable firmware found:
> > >
> > > # journalctl -kp3
> > > Dec 27 16:38:00 kernel: Error parsing PCC subspaces from PCCT
> > > Dec 27 16:38:00 kernel: mmc0: Unknown controller version (3). You may experience problems.
> > > Dec 27 16:38:02 kernel: DMAR: DRHD: handling fault status reg 2
> > > Dec 27 16:38:02 kernel: DMAR: [DMA Write] Request device [00:02.0] fault addr 7200000000 [fault reason 05] PTE Write a
> > > Dec 27 16:38:03 kernel: tpm tpm0: A TPM error (6) occurred attempting to read a pcr value
> > > Dec 27 16:38:04 kernel: iwlwifi 0000:03:00.0: no suitable firmware found!
> > >
> > > Linux stable/master (Linux 4.8-rc8, 08895a8b6b) works for me. And no
> > > further tests have been done yet.
> > >
> > > Is this a known issue? Please let me know if anyone wants more info or
> > > logs, since this error triggers easily (everytime I boot).
> >
> > The error message isn't really telling much to the user (hint hint) but
> > I suspect this is by design:
> >
> > "iwlwifi: remove support for fw older than -17 and -22
Right, we only maintain support for a certain number of firmware
versions. The FW APIs change with time and we don't want to keep all
legacy code supporting old firmwares in the driver forever.
I agree that "no suitable firmware found!" is a bit scarce. I'll see
if we can improve that with something: "no suitable firmware found! You
need iwlwifi-7260-17.ucode (<link to git>)".
> > FW versions older than -17 for 3160 and 7260 and older than -22 for
> > newer NICs are not supported anymore. Don't load these versions
> > and remove code that handles them."
> >
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4b87e5af638b6056bd6c20b0954d09a5a58633be
> >
> > Adding luca.
>
> Thanks for the triage.
>
> Larry's link for -17 firmware solved my issue. Though I still don't
> know whether it is too aggresive if we just remove the support for -16
> (which is the one I was using with the old 4.6 kernel, btw I am using
> Fedora 24, which is relatively new as well).
I don't think we are very aggressive, we have been supporting -17 since
v4.3:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5865f3658ba37c54e346b0fdee08a1c7a152681b
And we have published the firmware about half a year ago:
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/iwlwifi-7260-17.ucode?id=f2cf4d67e8eced29c8a473d3a27057aa2df57c42
I understand your concern, but if you want to be on the bleeding-edge
kernel, you should be on the bleeding-edge linux-firmware as well. ;)
But as I said, I'll try to improve the error message, as that should
make it easier to figure out.
--
Cheers,
Luca.
^ permalink raw reply
* Re: Intel Wireless 7260 failed to work
From: Peter Xu @ 2016-12-28 3:59 UTC (permalink / raw)
To: Kalle Valo; +Cc: Linux Kernel Mailing List, linux-wireless, Luca Coelho
In-Reply-To: <871swtkvdc.fsf@purkki.adurom.net>
On Tue, Dec 27, 2016 at 09:46:55PM +0200, Kalle Valo wrote:
> Peter Xu <peterx@redhat.com> writes:
>
> > Looks like latest Linux master (4.10-rc1, 7ce7d89f) cannot work well
> > with my wireless card, which is:
> >
> > Intel Corporation Wireless 7260 (rev bb)
> >
> > Boot message shows that no suitable firmware found:
> >
> > # journalctl -kp3
> > Dec 27 16:38:00 kernel: Error parsing PCC subspaces from PCCT
> > Dec 27 16:38:00 kernel: mmc0: Unknown controller version (3). You may experience problems.
> > Dec 27 16:38:02 kernel: DMAR: DRHD: handling fault status reg 2
> > Dec 27 16:38:02 kernel: DMAR: [DMA Write] Request device [00:02.0] fault addr 7200000000 [fault reason 05] PTE Write a
> > Dec 27 16:38:03 kernel: tpm tpm0: A TPM error (6) occurred attempting to read a pcr value
> > Dec 27 16:38:04 kernel: iwlwifi 0000:03:00.0: no suitable firmware found!
> >
> > Linux stable/master (Linux 4.8-rc8, 08895a8b6b) works for me. And no
> > further tests have been done yet.
> >
> > Is this a known issue? Please let me know if anyone wants more info or
> > logs, since this error triggers easily (everytime I boot).
>
> The error message isn't really telling much to the user (hint hint) but
> I suspect this is by design:
>
> "iwlwifi: remove support for fw older than -17 and -22
>
> FW versions older than -17 for 3160 and 7260 and older than -22 for
> newer NICs are not supported anymore. Don't load these versions
> and remove code that handles them."
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4b87e5af638b6056bd6c20b0954d09a5a58633be
>
> Adding luca.
Thanks for the triage.
Larry's link for -17 firmware solved my issue. Though I still don't
know whether it is too aggresive if we just remove the support for -16
(which is the one I was using with the old 4.6 kernel, btw I am using
Fedora 24, which is relatively new as well).
Regards,
-- peterx
^ permalink raw reply
* Re: Intel Wireless 7260 failed to work
From: Peter Xu @ 2016-12-28 3:50 UTC (permalink / raw)
To: Larry Finger; +Cc: Linux Kernel Mailing List, linux-wireless
In-Reply-To: <a1fbf107-24df-d9e8-1c69-78025c70a79c@lwfinger.net>
On Tue, Dec 27, 2016 at 10:41:22AM -0600, Larry Finger wrote:
> On 12/27/2016 03:17 AM, Peter Xu wrote:
> >Hello,
> >
> >Looks like latest Linux master (4.10-rc1, 7ce7d89f) cannot work well
> >with my wireless card, which is:
> >
> > Intel Corporation Wireless 7260 (rev bb)
> >
> >Boot message shows that no suitable firmware found:
> >
> > # journalctl -kp3
> > Dec 27 16:38:00 kernel: Error parsing PCC subspaces from PCCT
> > Dec 27 16:38:00 kernel: mmc0: Unknown controller version (3). You may experience problems.
> > Dec 27 16:38:02 kernel: DMAR: DRHD: handling fault status reg 2
> > Dec 27 16:38:02 kernel: DMAR: [DMA Write] Request device [00:02.0] fault addr 7200000000 [fault reason 05] PTE Write a
> > Dec 27 16:38:03 kernel: tpm tpm0: A TPM error (6) occurred attempting to read a pcr value
> > Dec 27 16:38:04 kernel: iwlwifi 0000:03:00.0: no suitable firmware found!
> >
> >Linux stable/master (Linux 4.8-rc8, 08895a8b6b) works for me. And no
> >further tests have been done yet.
> >
> >Is this a known issue? Please let me know if anyone wants more info or
> >logs, since this error triggers easily (everytime I boot).
> >
>
> The problem appears to be specific for your system. On my Toshiba Tecra
> A50A, kernel 4.10-rc1 the driver works the same as in earlier kernels. The
> dmesg log shows the following:
>
> [ 4.760600] Intel(R) Wireless WiFi driver for Linux
> [ 4.760601] Copyright(c) 2003- 2015 Intel Corporation
> [ 4.799519] iwlwifi 0000:04:00.0: loaded firmware version 17.352738.0
> op_mode iwlmvm
> [ 4.880820] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC
> 7260, REV=0x144
> [ 4.883340] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled
> [ 4.883584] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled
>
> I'm not sure if the driver would look for firmware version 16 if 17 would
> not be available, but I think it would.
>
> Check for firmware file /lib/firmware/iwlwifi-7260-17.ucode. If that is not
> present for your distro, it is in the repo at
> git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git.
This is useful. :-)
Putting iwlwifi-7260-17.ucode into /lib/firmware fixes my issue.
Thanks for the link!
-- peterx
^ permalink raw reply
* Re: Intel Wireless 7260 failed to work
From: Kalle Valo @ 2016-12-27 19:46 UTC (permalink / raw)
To: Peter Xu; +Cc: Linux Kernel Mailing List, linux-wireless, Luca Coelho
In-Reply-To: <20161227091706.GA20895@pxdev.xzpeter.org>
Peter Xu <peterx@redhat.com> writes:
> Looks like latest Linux master (4.10-rc1, 7ce7d89f) cannot work well
> with my wireless card, which is:
>
> Intel Corporation Wireless 7260 (rev bb)
>
> Boot message shows that no suitable firmware found:
>
> # journalctl -kp3
> Dec 27 16:38:00 kernel: Error parsing PCC subspaces from PCCT
> Dec 27 16:38:00 kernel: mmc0: Unknown controller version (3). You may experience problems.
> Dec 27 16:38:02 kernel: DMAR: DRHD: handling fault status reg 2
> Dec 27 16:38:02 kernel: DMAR: [DMA Write] Request device [00:02.0] fault addr 7200000000 [fault reason 05] PTE Write a
> Dec 27 16:38:03 kernel: tpm tpm0: A TPM error (6) occurred attempting to read a pcr value
> Dec 27 16:38:04 kernel: iwlwifi 0000:03:00.0: no suitable firmware found!
>
> Linux stable/master (Linux 4.8-rc8, 08895a8b6b) works for me. And no
> further tests have been done yet.
>
> Is this a known issue? Please let me know if anyone wants more info or
> logs, since this error triggers easily (everytime I boot).
The error message isn't really telling much to the user (hint hint) but
I suspect this is by design:
"iwlwifi: remove support for fw older than -17 and -22
FW versions older than -17 for 3160 and 7260 and older than -22 for
newer NICs are not supported anymore. Don't load these versions
and remove code that handles them."
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4b87e5af638b6056bd6c20b0954d09a5a58633be
Adding luca.
--
Kalle Valo
^ permalink raw reply
* [PATCH 2/2] ath9k: ar9003_mac: kill off ACCESS_ONCE()
From: Mark Rutland @ 2016-12-27 18:49 UTC (permalink / raw)
To: linux-kernel
Cc: ath9k-devel, kvalo, linux-wireless, ath9k-devel, netdev,
Mark Rutland
In-Reply-To: <1482864599-19995-1-git-send-email-mark.rutland@arm.com>
For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
preference to ACCESS_ONCE(), and new code is expected to use one of the
former. So far, there's been no reason to change most existing uses of
ACCESS_ONCE(), as these aren't currently harmful.
However, for some new features (e.g. KTSAN / Kernel Thread Sanitizer),
it is necessary to instrument reads and writes separately, which is not
possible with ACCESS_ONCE(). This distinction is critical to correct
operation.
It's possible to transform the bulk of kernel code using the Coccinelle
script below. However, for some files (including the ath9k ar9003 mac
driver), this mangles the formatting. As a preparatory step, this patch
converts the driver to use {READ,WRITE}_ONCE() without said mangling.
----
virtual patch
@ depends on patch @
expression E1, E2;
@@
- ACCESS_ONCE(E1) = E2
+ WRITE_ONCE(E1, E2)
@ depends on patch @
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
----
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: ath9k-devel@qca.qualcomm.com
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Cc: ath9k-devel@lists.ath9k.org
Cc: netdev@vger.kernel.org
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 92 ++++++++++++++---------------
1 file changed, 46 insertions(+), 46 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index da84b70..cc5bb0a 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -39,47 +39,47 @@ ar9003_set_txdesc(struct ath_hw *ah, void *ds, struct ath_tx_info *i)
(i->qcu << AR_TxQcuNum_S) | desc_len;
checksum += val;
- ACCESS_ONCE(ads->info) = val;
+ WRITE_ONCE(ads->info, val);
checksum += i->link;
- ACCESS_ONCE(ads->link) = i->link;
+ WRITE_ONCE(ads->link, i->link);
checksum += i->buf_addr[0];
- ACCESS_ONCE(ads->data0) = i->buf_addr[0];
+ WRITE_ONCE(ads->data0, i->buf_addr[0]);
checksum += i->buf_addr[1];
- ACCESS_ONCE(ads->data1) = i->buf_addr[1];
+ WRITE_ONCE(ads->data1, i->buf_addr[1]);
checksum += i->buf_addr[2];
- ACCESS_ONCE(ads->data2) = i->buf_addr[2];
+ WRITE_ONCE(ads->data2, i->buf_addr[2]);
checksum += i->buf_addr[3];
- ACCESS_ONCE(ads->data3) = i->buf_addr[3];
+ WRITE_ONCE(ads->data3, i->buf_addr[3]);
checksum += (val = (i->buf_len[0] << AR_BufLen_S) & AR_BufLen);
- ACCESS_ONCE(ads->ctl3) = val;
+ WRITE_ONCE(ads->ctl3, val);
checksum += (val = (i->buf_len[1] << AR_BufLen_S) & AR_BufLen);
- ACCESS_ONCE(ads->ctl5) = val;
+ WRITE_ONCE(ads->ctl5, val);
checksum += (val = (i->buf_len[2] << AR_BufLen_S) & AR_BufLen);
- ACCESS_ONCE(ads->ctl7) = val;
+ WRITE_ONCE(ads->ctl7, val);
checksum += (val = (i->buf_len[3] << AR_BufLen_S) & AR_BufLen);
- ACCESS_ONCE(ads->ctl9) = val;
+ WRITE_ONCE(ads->ctl9, val);
checksum = (u16) (((checksum & 0xffff) + (checksum >> 16)) & 0xffff);
- ACCESS_ONCE(ads->ctl10) = checksum;
+ WRITE_ONCE(ads->ctl10, checksum);
if (i->is_first || i->is_last) {
- ACCESS_ONCE(ads->ctl13) = set11nTries(i->rates, 0)
+ WRITE_ONCE(ads->ctl13, set11nTries(i->rates, 0)
| set11nTries(i->rates, 1)
| set11nTries(i->rates, 2)
| set11nTries(i->rates, 3)
| (i->dur_update ? AR_DurUpdateEna : 0)
- | SM(0, AR_BurstDur);
+ | SM(0, AR_BurstDur));
- ACCESS_ONCE(ads->ctl14) = set11nRate(i->rates, 0)
+ WRITE_ONCE(ads->ctl14, set11nRate(i->rates, 0)
| set11nRate(i->rates, 1)
| set11nRate(i->rates, 2)
- | set11nRate(i->rates, 3);
+ | set11nRate(i->rates, 3));
} else {
- ACCESS_ONCE(ads->ctl13) = 0;
- ACCESS_ONCE(ads->ctl14) = 0;
+ WRITE_ONCE(ads->ctl13, 0);
+ WRITE_ONCE(ads->ctl14, 0);
}
ads->ctl20 = 0;
@@ -89,17 +89,17 @@ ar9003_set_txdesc(struct ath_hw *ah, void *ds, struct ath_tx_info *i)
ctl17 = SM(i->keytype, AR_EncrType);
if (!i->is_first) {
- ACCESS_ONCE(ads->ctl11) = 0;
- ACCESS_ONCE(ads->ctl12) = i->is_last ? 0 : AR_TxMore;
- ACCESS_ONCE(ads->ctl15) = 0;
- ACCESS_ONCE(ads->ctl16) = 0;
- ACCESS_ONCE(ads->ctl17) = ctl17;
- ACCESS_ONCE(ads->ctl18) = 0;
- ACCESS_ONCE(ads->ctl19) = 0;
+ WRITE_ONCE(ads->ctl11, 0);
+ WRITE_ONCE(ads->ctl12, i->is_last ? 0 : AR_TxMore);
+ WRITE_ONCE(ads->ctl15, 0);
+ WRITE_ONCE(ads->ctl16, 0);
+ WRITE_ONCE(ads->ctl17, ctl17);
+ WRITE_ONCE(ads->ctl18, 0);
+ WRITE_ONCE(ads->ctl19, 0);
return;
}
- ACCESS_ONCE(ads->ctl11) = (i->pkt_len & AR_FrameLen)
+ WRITE_ONCE(ads->ctl11, (i->pkt_len & AR_FrameLen)
| (i->flags & ATH9K_TXDESC_VMF ? AR_VirtMoreFrag : 0)
| SM(i->txpower[0], AR_XmitPower0)
| (i->flags & ATH9K_TXDESC_VEOL ? AR_VEOL : 0)
@@ -107,7 +107,7 @@ ar9003_set_txdesc(struct ath_hw *ah, void *ds, struct ath_tx_info *i)
| (i->flags & ATH9K_TXDESC_LOWRXCHAIN ? AR_LowRxChain : 0)
| (i->flags & ATH9K_TXDESC_CLRDMASK ? AR_ClrDestMask : 0)
| (i->flags & ATH9K_TXDESC_RTSENA ? AR_RTSEnable :
- (i->flags & ATH9K_TXDESC_CTSENA ? AR_CTSEnable : 0));
+ (i->flags & ATH9K_TXDESC_CTSENA ? AR_CTSEnable : 0)));
ctl12 = (i->keyix != ATH9K_TXKEYIX_INVALID ?
SM(i->keyix, AR_DestIdx) : 0)
@@ -135,26 +135,26 @@ ar9003_set_txdesc(struct ath_hw *ah, void *ds, struct ath_tx_info *i)
val = (i->flags & ATH9K_TXDESC_PAPRD) >> ATH9K_TXDESC_PAPRD_S;
ctl12 |= SM(val, AR_PAPRDChainMask);
- ACCESS_ONCE(ads->ctl12) = ctl12;
- ACCESS_ONCE(ads->ctl17) = ctl17;
+ WRITE_ONCE(ads->ctl12, ctl12);
+ WRITE_ONCE(ads->ctl17, ctl17);
- ACCESS_ONCE(ads->ctl15) = set11nPktDurRTSCTS(i->rates, 0)
- | set11nPktDurRTSCTS(i->rates, 1);
+ WRITE_ONCE(ads->ctl15, set11nPktDurRTSCTS(i->rates, 0)
+ | set11nPktDurRTSCTS(i->rates, 1));
- ACCESS_ONCE(ads->ctl16) = set11nPktDurRTSCTS(i->rates, 2)
- | set11nPktDurRTSCTS(i->rates, 3);
+ WRITE_ONCE(ads->ctl16, set11nPktDurRTSCTS(i->rates, 2)
+ | set11nPktDurRTSCTS(i->rates, 3));
- ACCESS_ONCE(ads->ctl18) = set11nRateFlags(i->rates, 0)
+ WRITE_ONCE(ads->ctl18, set11nRateFlags(i->rates, 0)
| set11nRateFlags(i->rates, 1)
| set11nRateFlags(i->rates, 2)
| set11nRateFlags(i->rates, 3)
- | SM(i->rtscts_rate, AR_RTSCTSRate);
+ | SM(i->rtscts_rate, AR_RTSCTSRate));
- ACCESS_ONCE(ads->ctl19) = AR_Not_Sounding;
+ WRITE_ONCE(ads->ctl19, AR_Not_Sounding);
- ACCESS_ONCE(ads->ctl20) = SM(i->txpower[1], AR_XmitPower1);
- ACCESS_ONCE(ads->ctl21) = SM(i->txpower[2], AR_XmitPower2);
- ACCESS_ONCE(ads->ctl22) = SM(i->txpower[3], AR_XmitPower3);
+ WRITE_ONCE(ads->ctl20, SM(i->txpower[1], AR_XmitPower1));
+ WRITE_ONCE(ads->ctl21, SM(i->txpower[2], AR_XmitPower2));
+ WRITE_ONCE(ads->ctl22, SM(i->txpower[3], AR_XmitPower3));
}
static u16 ar9003_calc_ptr_chksum(struct ar9003_txc *ads)
@@ -359,7 +359,7 @@ static int ar9003_hw_proc_txdesc(struct ath_hw *ah, void *ds,
ads = &ah->ts_ring[ah->ts_tail];
- status = ACCESS_ONCE(ads->status8);
+ status = READ_ONCE(ads->status8);
if ((status & AR_TxDone) == 0)
return -EINPROGRESS;
@@ -385,7 +385,7 @@ static int ar9003_hw_proc_txdesc(struct ath_hw *ah, void *ds,
if (status & AR_TxOpExceeded)
ts->ts_status |= ATH9K_TXERR_XTXOP;
- status = ACCESS_ONCE(ads->status2);
+ status = READ_ONCE(ads->status2);
ts->ts_rssi_ctl0 = MS(status, AR_TxRSSIAnt00);
ts->ts_rssi_ctl1 = MS(status, AR_TxRSSIAnt01);
ts->ts_rssi_ctl2 = MS(status, AR_TxRSSIAnt02);
@@ -395,7 +395,7 @@ static int ar9003_hw_proc_txdesc(struct ath_hw *ah, void *ds,
ts->ba_high = ads->status6;
}
- status = ACCESS_ONCE(ads->status3);
+ status = READ_ONCE(ads->status3);
if (status & AR_ExcessiveRetries)
ts->ts_status |= ATH9K_TXERR_XRETRY;
if (status & AR_Filtered)
@@ -420,7 +420,7 @@ static int ar9003_hw_proc_txdesc(struct ath_hw *ah, void *ds,
ts->ts_longretry = MS(status, AR_DataFailCnt);
ts->ts_virtcol = MS(status, AR_VirtRetryCnt);
- status = ACCESS_ONCE(ads->status7);
+ status = READ_ONCE(ads->status7);
ts->ts_rssi = MS(status, AR_TxRSSICombined);
ts->ts_rssi_ext0 = MS(status, AR_TxRSSIAnt10);
ts->ts_rssi_ext1 = MS(status, AR_TxRSSIAnt11);
@@ -437,13 +437,13 @@ static int ar9003_hw_get_duration(struct ath_hw *ah, const void *ds, int index)
switch (index) {
case 0:
- return MS(ACCESS_ONCE(adc->ctl15), AR_PacketDur0);
+ return MS(READ_ONCE(adc->ctl15), AR_PacketDur0);
case 1:
- return MS(ACCESS_ONCE(adc->ctl15), AR_PacketDur1);
+ return MS(READ_ONCE(adc->ctl15), AR_PacketDur1);
case 2:
- return MS(ACCESS_ONCE(adc->ctl16), AR_PacketDur2);
+ return MS(READ_ONCE(adc->ctl16), AR_PacketDur2);
case 3:
- return MS(ACCESS_ONCE(adc->ctl16), AR_PacketDur3);
+ return MS(READ_ONCE(adc->ctl16), AR_PacketDur3);
default:
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] ath9k: ar9002_mac: kill off ACCESS_ONCE()
From: Mark Rutland @ 2016-12-27 18:49 UTC (permalink / raw)
To: linux-kernel
Cc: ath9k-devel, kvalo, linux-wireless, ath9k-devel, netdev,
Mark Rutland
In-Reply-To: <1482864599-19995-1-git-send-email-mark.rutland@arm.com>
For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
preference to ACCESS_ONCE(), and new code is expected to use one of the
former. So far, there's been no reason to change most existing uses of
ACCESS_ONCE(), as these aren't currently harmful.
However, for some new features (e.g. KTSAN / Kernel Thread Sanitizer),
it is necessary to instrument reads and writes separately, which is not
possible with ACCESS_ONCE(). This distinction is critical to correct
operation.
It's possible to transform the bulk of kernel code using the Coccinelle
script below. However, for some files (including the ath9k ar9002 mac
driver), this mangles the formatting. As a preparatory step, this patch
converts the driver to use {READ,WRITE}_ONCE() without said mangling.
----
virtual patch
@ depends on patch @
expression E1, E2;
@@
- ACCESS_ONCE(E1) = E2
+ WRITE_ONCE(E1, E2)
@ depends on patch @
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
----
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: ath9k-devel@qca.qualcomm.com
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Cc: ath9k-devel@lists.ath9k.org
Cc: netdev@vger.kernel.org
---
drivers/net/wireless/ath/ath9k/ar9002_mac.c | 64 ++++++++++++++---------------
1 file changed, 32 insertions(+), 32 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_mac.c b/drivers/net/wireless/ath/ath9k/ar9002_mac.c
index f816909..4b3c9b1 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_mac.c
@@ -220,8 +220,8 @@ ar9002_set_txdesc(struct ath_hw *ah, void *ds, struct ath_tx_info *i)
ads->ds_txstatus6 = ads->ds_txstatus7 = 0;
ads->ds_txstatus8 = ads->ds_txstatus9 = 0;
- ACCESS_ONCE(ads->ds_link) = i->link;
- ACCESS_ONCE(ads->ds_data) = i->buf_addr[0];
+ WRITE_ONCE(ads->ds_link, i->link);
+ WRITE_ONCE(ads->ds_data, i->buf_addr[0]);
ctl1 = i->buf_len[0] | (i->is_last ? 0 : AR_TxMore);
ctl6 = SM(i->keytype, AR_EncrType);
@@ -235,26 +235,26 @@ ar9002_set_txdesc(struct ath_hw *ah, void *ds, struct ath_tx_info *i)
if ((i->is_first || i->is_last) &&
i->aggr != AGGR_BUF_MIDDLE && i->aggr != AGGR_BUF_LAST) {
- ACCESS_ONCE(ads->ds_ctl2) = set11nTries(i->rates, 0)
+ WRITE_ONCE(ads->ds_ctl2, set11nTries(i->rates, 0)
| set11nTries(i->rates, 1)
| set11nTries(i->rates, 2)
| set11nTries(i->rates, 3)
| (i->dur_update ? AR_DurUpdateEna : 0)
- | SM(0, AR_BurstDur);
+ | SM(0, AR_BurstDur));
- ACCESS_ONCE(ads->ds_ctl3) = set11nRate(i->rates, 0)
+ WRITE_ONCE(ads->ds_ctl3, set11nRate(i->rates, 0)
| set11nRate(i->rates, 1)
| set11nRate(i->rates, 2)
- | set11nRate(i->rates, 3);
+ | set11nRate(i->rates, 3));
} else {
- ACCESS_ONCE(ads->ds_ctl2) = 0;
- ACCESS_ONCE(ads->ds_ctl3) = 0;
+ WRITE_ONCE(ads->ds_ctl2, 0);
+ WRITE_ONCE(ads->ds_ctl3, 0);
}
if (!i->is_first) {
- ACCESS_ONCE(ads->ds_ctl0) = 0;
- ACCESS_ONCE(ads->ds_ctl1) = ctl1;
- ACCESS_ONCE(ads->ds_ctl6) = ctl6;
+ WRITE_ONCE(ads->ds_ctl0, 0);
+ WRITE_ONCE(ads->ds_ctl1, ctl1);
+ WRITE_ONCE(ads->ds_ctl6, ctl6);
return;
}
@@ -279,7 +279,7 @@ ar9002_set_txdesc(struct ath_hw *ah, void *ds, struct ath_tx_info *i)
break;
}
- ACCESS_ONCE(ads->ds_ctl0) = (i->pkt_len & AR_FrameLen)
+ WRITE_ONCE(ads->ds_ctl0, (i->pkt_len & AR_FrameLen)
| (i->flags & ATH9K_TXDESC_VMF ? AR_VirtMoreFrag : 0)
| SM(i->txpower[0], AR_XmitPower0)
| (i->flags & ATH9K_TXDESC_VEOL ? AR_VEOL : 0)
@@ -287,29 +287,29 @@ ar9002_set_txdesc(struct ath_hw *ah, void *ds, struct ath_tx_info *i)
| (i->keyix != ATH9K_TXKEYIX_INVALID ? AR_DestIdxValid : 0)
| (i->flags & ATH9K_TXDESC_CLRDMASK ? AR_ClrDestMask : 0)
| (i->flags & ATH9K_TXDESC_RTSENA ? AR_RTSEnable :
- (i->flags & ATH9K_TXDESC_CTSENA ? AR_CTSEnable : 0));
+ (i->flags & ATH9K_TXDESC_CTSENA ? AR_CTSEnable : 0)));
- ACCESS_ONCE(ads->ds_ctl1) = ctl1;
- ACCESS_ONCE(ads->ds_ctl6) = ctl6;
+ WRITE_ONCE(ads->ds_ctl1, ctl1);
+ WRITE_ONCE(ads->ds_ctl6, ctl6);
if (i->aggr == AGGR_BUF_MIDDLE || i->aggr == AGGR_BUF_LAST)
return;
- ACCESS_ONCE(ads->ds_ctl4) = set11nPktDurRTSCTS(i->rates, 0)
- | set11nPktDurRTSCTS(i->rates, 1);
+ WRITE_ONCE(ads->ds_ctl4, set11nPktDurRTSCTS(i->rates, 0)
+ | set11nPktDurRTSCTS(i->rates, 1));
- ACCESS_ONCE(ads->ds_ctl5) = set11nPktDurRTSCTS(i->rates, 2)
- | set11nPktDurRTSCTS(i->rates, 3);
+ WRITE_ONCE(ads->ds_ctl5, set11nPktDurRTSCTS(i->rates, 2)
+ | set11nPktDurRTSCTS(i->rates, 3));
- ACCESS_ONCE(ads->ds_ctl7) = set11nRateFlags(i->rates, 0)
+ WRITE_ONCE(ads->ds_ctl7, set11nRateFlags(i->rates, 0)
| set11nRateFlags(i->rates, 1)
| set11nRateFlags(i->rates, 2)
| set11nRateFlags(i->rates, 3)
- | SM(i->rtscts_rate, AR_RTSCTSRate);
+ | SM(i->rtscts_rate, AR_RTSCTSRate));
- ACCESS_ONCE(ads->ds_ctl9) = SM(i->txpower[1], AR_XmitPower1);
- ACCESS_ONCE(ads->ds_ctl10) = SM(i->txpower[2], AR_XmitPower2);
- ACCESS_ONCE(ads->ds_ctl11) = SM(i->txpower[3], AR_XmitPower3);
+ WRITE_ONCE(ads->ds_ctl9, SM(i->txpower[1], AR_XmitPower1));
+ WRITE_ONCE(ads->ds_ctl10, SM(i->txpower[2], AR_XmitPower2));
+ WRITE_ONCE(ads->ds_ctl11, SM(i->txpower[3], AR_XmitPower3));
}
static int ar9002_hw_proc_txdesc(struct ath_hw *ah, void *ds,
@@ -318,7 +318,7 @@ static int ar9002_hw_proc_txdesc(struct ath_hw *ah, void *ds,
struct ar5416_desc *ads = AR5416DESC(ds);
u32 status;
- status = ACCESS_ONCE(ads->ds_txstatus9);
+ status = READ_ONCE(ads->ds_txstatus9);
if ((status & AR_TxDone) == 0)
return -EINPROGRESS;
@@ -332,7 +332,7 @@ static int ar9002_hw_proc_txdesc(struct ath_hw *ah, void *ds,
ts->ts_rateindex = MS(status, AR_FinalTxIdx);
ts->ts_seqnum = MS(status, AR_SeqNum);
- status = ACCESS_ONCE(ads->ds_txstatus0);
+ status = READ_ONCE(ads->ds_txstatus0);
ts->ts_rssi_ctl0 = MS(status, AR_TxRSSIAnt00);
ts->ts_rssi_ctl1 = MS(status, AR_TxRSSIAnt01);
ts->ts_rssi_ctl2 = MS(status, AR_TxRSSIAnt02);
@@ -342,7 +342,7 @@ static int ar9002_hw_proc_txdesc(struct ath_hw *ah, void *ds,
ts->ba_high = ads->AR_BaBitmapHigh;
}
- status = ACCESS_ONCE(ads->ds_txstatus1);
+ status = READ_ONCE(ads->ds_txstatus1);
if (status & AR_FrmXmitOK)
ts->ts_status |= ATH9K_TX_ACKED;
else {
@@ -371,7 +371,7 @@ static int ar9002_hw_proc_txdesc(struct ath_hw *ah, void *ds,
ts->ts_longretry = MS(status, AR_DataFailCnt);
ts->ts_virtcol = MS(status, AR_VirtRetryCnt);
- status = ACCESS_ONCE(ads->ds_txstatus5);
+ status = READ_ONCE(ads->ds_txstatus5);
ts->ts_rssi = MS(status, AR_TxRSSICombined);
ts->ts_rssi_ext0 = MS(status, AR_TxRSSIAnt10);
ts->ts_rssi_ext1 = MS(status, AR_TxRSSIAnt11);
@@ -390,13 +390,13 @@ static int ar9002_hw_get_duration(struct ath_hw *ah, const void *ds, int index)
switch (index) {
case 0:
- return MS(ACCESS_ONCE(ads->ds_ctl4), AR_PacketDur0);
+ return MS(READ_ONCE(ads->ds_ctl4), AR_PacketDur0);
case 1:
- return MS(ACCESS_ONCE(ads->ds_ctl4), AR_PacketDur1);
+ return MS(READ_ONCE(ads->ds_ctl4), AR_PacketDur1);
case 2:
- return MS(ACCESS_ONCE(ads->ds_ctl5), AR_PacketDur2);
+ return MS(READ_ONCE(ads->ds_ctl5), AR_PacketDur2);
case 3:
- return MS(ACCESS_ONCE(ads->ds_ctl5), AR_PacketDur3);
+ return MS(READ_ONCE(ads->ds_ctl5), AR_PacketDur3);
default:
return -1;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] ath9k: kill of ACCESS_ONCE() in MAC drivers
From: Mark Rutland @ 2016-12-27 18:49 UTC (permalink / raw)
To: linux-kernel
Cc: ath9k-devel, kvalo, linux-wireless, ath9k-devel, netdev,
Mark Rutland
For several reasons, it would be beneficial to kill off ACCESS_ONCE()
tree-wide, in favour of {READ,WRITE}_ONCE(). These work with aggregate
types, more obviously document their intended behaviour, and are
necessary for tools like KTSAN to work correctly (as otherwise reads and
writes cannot be instrumented separately).
While it's possible to script a tree-wide conversion using Coccinelle,
some cases such as the ath9k MAC drivers require some manual
intervention to ensure that the resulting code remains legible. This
series moves the ath9k MAC drivers over to {READ,WRITE}_ONCE(). In both
cases this is functionally equivalent to the below Coccinelle script
being applied, though the existing formatting is retained.
----
virtual patch
@ depends on patch @
expression E1, E2;
@@
- ACCESS_ONCE(E1) = E2
+ WRITE_ONCE(E1, E2)
@ depends on patch @
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
----
Thanks,
Mark.
Mark Rutland (2):
ath9k: ar9002_mac: kill off ACCESS_ONCE()
ath9k: ar9003_mac: kill off ACCESS_ONCE()
drivers/net/wireless/ath/ath9k/ar9002_mac.c | 64 ++++++++++----------
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 92 ++++++++++++++---------------
2 files changed, 78 insertions(+), 78 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: Intel Wireless 7260 failed to work
From: Larry Finger @ 2016-12-27 16:41 UTC (permalink / raw)
To: Peter Xu, Linux Kernel Mailing List, linux-wireless
In-Reply-To: <20161227091706.GA20895@pxdev.xzpeter.org>
On 12/27/2016 03:17 AM, Peter Xu wrote:
> Hello,
>
> Looks like latest Linux master (4.10-rc1, 7ce7d89f) cannot work well
> with my wireless card, which is:
>
> Intel Corporation Wireless 7260 (rev bb)
>
> Boot message shows that no suitable firmware found:
>
> # journalctl -kp3
> Dec 27 16:38:00 kernel: Error parsing PCC subspaces from PCCT
> Dec 27 16:38:00 kernel: mmc0: Unknown controller version (3). You may experience problems.
> Dec 27 16:38:02 kernel: DMAR: DRHD: handling fault status reg 2
> Dec 27 16:38:02 kernel: DMAR: [DMA Write] Request device [00:02.0] fault addr 7200000000 [fault reason 05] PTE Write a
> Dec 27 16:38:03 kernel: tpm tpm0: A TPM error (6) occurred attempting to read a pcr value
> Dec 27 16:38:04 kernel: iwlwifi 0000:03:00.0: no suitable firmware found!
>
> Linux stable/master (Linux 4.8-rc8, 08895a8b6b) works for me. And no
> further tests have been done yet.
>
> Is this a known issue? Please let me know if anyone wants more info or
> logs, since this error triggers easily (everytime I boot).
>
The problem appears to be specific for your system. On my Toshiba Tecra A50A,
kernel 4.10-rc1 the driver works the same as in earlier kernels. The dmesg log
shows the following:
[ 4.760600] Intel(R) Wireless WiFi driver for Linux
[ 4.760601] Copyright(c) 2003- 2015 Intel Corporation
[ 4.799519] iwlwifi 0000:04:00.0: loaded firmware version 17.352738.0 op_mode
iwlmvm
[ 4.880820] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC
7260, REV=0x144
[ 4.883340] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled
[ 4.883584] iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled
I'm not sure if the driver would look for firmware version 16 if 17 would not be
available, but I think it would.
Check for firmware file /lib/firmware/iwlwifi-7260-17.ucode. If that is not
present for your distro, it is in the repo at
git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git.
If that firmware is present, or if adding it does not help, my next suggestion
is to bisect between 4.8 and the current version to see where the problem was
introduced. I would not limit the bisection to the Intel wireless drivers as the
problem could be in the underlying PCIe support for your hardware. By the way,
that bisection will require about 14 steps.
Larry
^ permalink raw reply
* [PATCH] ath10k: Enable advertising support for channel 169, 5Ghz
From: Mohammed Shafi Shajakhan @ 2016-12-27 15:23 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Enable advertising support for channel 169, 5Ghz so that
based on the regulatory domain(country code) this channel
shall be active for use. For example in countries like India
this channel shall be available for use with latest regulatory updates
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drivers/net/wireless/ath/ath10k/mac.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 756e876..a19cef2 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -46,7 +46,7 @@
#define WMI_READY_TIMEOUT (5 * HZ)
#define ATH10K_FLUSH_TIMEOUT_HZ (5 * HZ)
#define ATH10K_CONNECTION_LOSS_HZ (3 * HZ)
-#define ATH10K_NUM_CHANS 39
+#define ATH10K_NUM_CHANS 40
/* Antenna noise floor */
#define ATH10K_DEFAULT_NOISE_FLOOR -95
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 481842b..7d2f0ae 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7559,6 +7559,7 @@ struct ath10k_mac_change_chanctx_arg {
CHAN5G(157, 5785, 0),
CHAN5G(161, 5805, 0),
CHAN5G(165, 5825, 0),
+ CHAN5G(169, 5845, 0),
};
struct ath10k *ath10k_mac_create(size_t priv_size)
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v3 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel
From: Geoff Lansberry @ 2016-12-27 14:18 UTC (permalink / raw)
To: Mark Greer
Cc: linux-wireless, Lauro Ramos Venancio, Aloisio Almeida Jr,
Samuel Ortiz, robh+dt, mark.rutland, netdev, devicetree,
linux-kernel, Justin Bronder, Jaret Cantu
In-Reply-To: <20161224172439.GA15103@animalcreek.com>
Mark - I will split this off soon.
In the meantime - here is some more info about how we use it.
We do use NFC structures. I did find an interesting clue in that
there are certain bottles that cause neard to segfault, I'm not sure
what is different about them. We write a string, like
"coppola_chardonnay_2015" to the bottles. Come to think of it, I
haven't done anything special to make that an ndef record, just
assumed that it would happen by default, I'll look into this further.
Also, I've been running neard with --plugin nfctype2. Just in case
the problem was happening due to cycling through other tag types. It
didn't seem to make any difference, but I have not gone back to
default.
Geoff
Geoff Lansberry
Engineering Guy
Kuv=C3=A9e, Inc
125 Kingston St., 3rd Floor
Boston, MA 02111
1-617-290-1118 (m)
geoff.lansberry (skype)
http://www.kuvee.com
On Sat, Dec 24, 2016 at 12:24 PM, Mark Greer <mgreer@animalcreek.com> wrote=
:
> On Sat, Dec 24, 2016 at 11:17:18AM -0500, Geoff Lansberry wrote:
>> Mark - I'm sorry, but I did not write this code, and therefore was not
>> able to accurately describe it. It is fixing a different issue, not
>> the neard segfault that we are still chasing. Last week Jaret Cantu
>> sent a separate email explaining the purpose of the code, which had
>> you copied, did you see that?
>
> Hm, no, I didn't. I received an email from Justin Bronder but not from
> Jaret Cantu. Justin's email did help but is still pretty high-level.
> We need a clear understanding as to what is happening in the digital
> layer and the driver to know how execution is getting into a block of
> error handling code that should never be executed. Once we understand
> that we can start thinking about what the best fix is.
>
>> Does it explain why it was done to
>> your satisfaction? I've asked him to join in on the effort to push
>> the change upstream, however he will not be available until the new
>> year.
>
> I expect that it would help if he joins. After the holidays is fine -
> I think many people are taking it easy for the next week or so, anyway.
>
>> I know you did suggest that we split off that change from the others,
>> and if now is the time to do that, let me know. If you don't have
>> the email from Jaret, also please let me know and I will forward it to
>> you.
>
> I think it would help you if you split it off because the first two patch=
es
> have a good chance of being accepted but this one doesn't (yet). If you
> separate the them, it will make it easier for Samuel to take the first tw=
o
> (or he may take the first two anyway but its always good to make it as
> easy maintainers as you can).
>
> Mark
> --
^ 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