* Re: [PATCH v3 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage
From: Rob Herring @ 2016-12-22 23:02 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo,
mark.rutland, netdev, devicetree, linux-kernel, mgreer, justin
In-Reply-To: <1482380314-16440-2-git-send-email-geoff@kuvee.com>
On Wed, Dec 21, 2016 at 11:18:33PM -0500, Geoff Lansberry wrote:
> The TRF7970A has configuration options for supporting hardware designs
> with 1.8 Volt or 3.3 Volt IO. This commit adds a device tree option,
> using a fixed regulator binding, for setting the io voltage to match
> the hardware configuration. If no option is supplied it defaults to
> 3.3 volt configuration.
>
> Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
> ---
> .../devicetree/bindings/net/nfc/trf7970a.txt | 2 ++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/nfc/trf7970a.c | 26 +++++++++++++++++++++-
> 2 files changed, 27 insertions(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH v3 1/3] NFC: trf7970a: add device tree option for 27MHz clock
From: Rob Herring @ 2016-12-22 23:01 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo,
mark.rutland, netdev, devicetree, linux-kernel, mgreer, justin
In-Reply-To: <1482380314-16440-1-git-send-email-geoff@kuvee.com>
On Wed, Dec 21, 2016 at 11:18:32PM -0500, Geoff Lansberry wrote:
> The TRF7970A has configuration options to support hardware designs
> which use a 27.12MHz clock. This commit adds a device tree option
> 'clock-frequency' to support configuring the this chip for default
> 13.56MHz clock or the optional 27.12MHz clock.
>
> Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
> ---
> .../devicetree/bindings/net/nfc/trf7970a.txt | 2 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/nfc/trf7970a.c | 50 +++++++++++++++++-----
> 2 files changed, 41 insertions(+), 11 deletions(-)
^ permalink raw reply
* [PATCH] ath10k: recal the txpower when removing interface
From: ryanhsu @ 2016-12-22 22:31 UTC (permalink / raw)
To: ath10k, linux-wireless; +Cc: ryanhsu
From: Ryan Hsu <ryanhsu@qca.qualcomm.com>
The txpower is being recalculated when adding interface to make sure
txpower won't overshoot the spec, and when removing the interface,
the txpower should again to be recalculated to restore the correct value
from the active interface list.
Following is one of the scenario
vdev0 is created as STA and connected: txpower:23
vdev1 is created as P2P_DEVICE for control interface: txpower:0
vdev2 is created as p2p go/gc interface: txpower is 21
So the vdev2@txpower:21 will be set to firmware when vdev2 is created.
When we tear down the vdev2, the txpower needs to be recalculated to
re-set it to vdev0@txpower:23 as vdev0/vdev1 are the active interface.
ath10k_pci mac vdev 0 peer create 8c:fd:f0:01:62:98
ath10k_pci mac vdev_id 0 txpower 23
... (adding interface)
ath10k_pci mac vdev create 2 (add interface) type 1 subtype 3
ath10k_pci mac vdev_id 2 txpower 21
ath10k_pci mac txpower 21
... (removing interface)
ath10k_pci mac vdev 2 delete (remove interface)
ath10k_pci vdev 1 txpower 0
ath10k_pci vdev 0 txpower 23
ath10k_pci mac txpower 23
Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index aa545a1..6475dc8 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5194,6 +5194,10 @@ static void ath10k_remove_interface(struct ieee80211_hw *hw,
ath10k_warn(ar, "failed to recalc monitor: %d\n", ret);
}
+ ret = ath10k_mac_txpower_recalc(ar);
+ if (ret)
+ ath10k_warn(ar, "failed to recalc tx power: %d\n", ret);
+
spin_lock_bh(&ar->htt.tx_lock);
ath10k_mac_vif_tx_unlock_all(arvif);
spin_unlock_bh(&ar->htt.tx_lock);
--
1.9.1
^ permalink raw reply related
* Re: Question: Packet drop criterion
From: Oleksij Rempel @ 2016-12-22 19:52 UTC (permalink / raw)
To: Ferran Quer i Guerrero, linux-wireless
In-Reply-To: <f4e6b348-fafb-1546-57cd-4623299b0abb@i2cat.net>
[-- Attachment #1.1: Type: text/plain, Size: 1757 bytes --]
Am 22.12.2016 um 13:34 schrieb Ferran Quer i Guerrero:
> Hello everyone,
>
> I would like to modify the retry threshold for dropping a packet using
> mesh mode. I tried with iw
>
> iw phy <phyname> set retry [short <limit>] [long <limit>]
>
> with short and long limits equal to 10 first and later 5, but I couldn't
> tell any effect. I'm checking by adding a printk in `status.c` and
> manually shutting down (ifdown) the mesh-peered interface to cause
> packet retries. It turns out that the tx report only appears when
> `retry_count` is 28 (after many continued drops, it also appears at 23,
> 24, 25 or retries).
>
> void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
> {
> /* ... */
> if (info->flags & IEEE80211_TX_STAT_TX_FILTERED) {
> ieee80211_handle_filtered_frame(local, sta, skb);
> rcu_read_unlock();
> return;
> } else {
> if (!acked)
> sta->tx_retry_failed++;
> sta->tx_retry_count += retry_count;
> /* Dirty debugging */
> printk("Packet dropped. Retry count: %d",
> retry_count);
> }
>
> rate_control_tx_status(local, sband, sta, skb);
> if (ieee80211_vif_is_mesh(&sta->sdata->vif))
> ieee80211s_update_metric(local, sta, skb);
> /* ... */
> }
>
> I'm using linux backports v3.12.8, ath9k wifi dongles, and interfaces on
> mesh point mode.
are you talking about usb dongles? If yes, then it is not ath9k
--
Regards,
Oleksij
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock
From: Rob Herring @ 2016-12-22 18:48 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, Lauro Ramos Venancio, Aloisio Almeida Jr,
Samuel Ortiz, Mark Rutland, netdev, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Mark Greer, Justin Bronder
In-Reply-To: <CAO7Z3WKmEbJCN_=srxTVKXvtz84vHGi41RS+9T7fmkmhRB6nEw@mail.gmail.com>
On Mon, Dec 19, 2016 at 5:23 PM, Geoff Lansberry <geoff@kuvee.com> wrote:
> I can make that change, however, I worry that it may be a bit
> misleading, since there are only two supported clock frequencies, but
> a number like that to me implies that it could be set to any number
> you want. I'm new at this, and so I'll go ahead and change it as you
> request, but I'd like to hear your thoughts on my concern.
Then the binding doc just needs to state what are the 2 valid frequencies.
Rob
^ permalink raw reply
* Re: [PATCH] ath10k: merge extended peer info data with existing peers info
From: Christian Lamparter @ 2016-12-22 17:58 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: linux-wireless, ath10k, Kalle Valo, michal.kazior
In-Reply-To: <20161222154801.GA16241@atheros-ThinkPad-T61>
Hello Shafi,
On Thursday, December 22, 2016 9:18:01 PM CET Mohammed Shafi Shajakhan wrote:
> > On Monday, December 19, 2016 10:19:57 PM CET Mohammed Shafi Shajakhan wrote:
> > > On Sat, Dec 17, 2016 at 06:46:34PM +0100, Christian Lamparter wrote:
> > > > The 10.4 firmware adds extended peer information to the
> > > > firmware's statistics payload. This additional info is
> > > > stored as a separate data field. During review of
> > > > "ath10k: add accounting for the extended peer statistics" [0]
> > > >
> > > > Mohammed Shafi Shajakhan commented that the extended peer statistics
> > > > lists are of little use:"... there is not much use in appending
> > > > the extended peer stats (which gets periodically updated) to the
> > > > linked list '&ar->debug.fw_stats.peers_extd)' and should we get
> > > > rid of the below (and the required cleanup as well)
> > > >
> > > > list_splice_tail_init(&stats.peers_extd,
> > > > &ar->debug.fw_stats.peers_extd);
> > > >
> > > > since rx_duration is getting updated periodically to the per sta
> > > > information."
> > > >
> > > > This patch replaces the extended peers list with a lookup and
> > > > puts the retrieved data (rx_duration) into the existing
> > > > ath10k_fw_stats_peer entry that was created earlier.
> > >
> > > [shafi] Its good to maintain the extended stats variable
> > > and retain the two different functions to update rx_duration.
> > >
> > > a) extended peer stats supported - mainly for 10.4
> > > b) extender peer stats not supported - for 10.2
> > Well, I have to ask why you want to retain the two different
> > functions to update the same arsta->rx_duration? I think a
> > little bit of code that helps to explain what's on your mind
> > (or how you would do it) would help immensely in this case.
> > Since I have the feeling that this is the problem here.
> > So please explain it in C(lang).
>
> [shafi] I see you prefer to stuff the 'rx_duration' from
> the extended stats to the existing global 'ath10k_peer_stats'
> The idea of extended stats is, ideally its not going to stop
> for 'rx_duration' . Extended stats is maintained as a seperate
> list / entry for addition of new fields as well
I'm guessing you are trying to say here:
replace:
dst->rx_duration = __le32_to_cpu(src->rx_duration);
with
dst->rx_duration += __le32_to_cpu(src->rx_duration);
in ath10k_wmi_10_4_op_pull_fw_stats()?
Is this correct? If so then can you tell me why ath10k_wmi_10_4_op_pull_fw_stats()
is using for (i = 0; i < num_peer_stats; i++) to iterate over the extended peer
stats instead of looking up the number of extended peer items. Because this does
imply that there are the "same" (and every peer stat has a matching extended
peer stat)... (This will be important for the comment below - so ***).
Of course, if this isn't true then this is a bug and should be fixed because
otherwise the ath10k_wmi_10_4_op_pull_fw_stats functions might return -EPROTO
at some point which causes a "failed to pull fw stats: -71" and unprocessed/lost
stats.
> >
> > > > [0] <https://lkml.kernel.org/r/992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
> > > > Cc: Mohammed Shafi Shajakhan <mohammed@codeaurora.org>
> > > > Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> > > > ---
> > > > drivers/net/wireless/ath/ath10k/core.h | 2 --
> > > > drivers/net/wireless/ath/ath10k/debug.c | 17 --------------
> > > > drivers/net/wireless/ath/ath10k/debugfs_sta.c | 32 ++-----------------------
> > > > drivers/net/wireless/ath/ath10k/wmi.c | 34 ++++++++++++++++++++-------
> > > > 4 files changed, 28 insertions(+), 57 deletions(-)
> > > >
> > > > diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
> > > > index 09ff8b8a6441..3fffbbb18c25 100644
> > > > --- a/drivers/net/wireless/ath/ath10k/core.h
> > > > +++ b/drivers/net/wireless/ath/ath10k/core.h
> > > > @@ -268,11 +268,9 @@ struct ath10k_fw_stats_pdev {
> > > > };
> > > >
> > > > struct ath10k_fw_stats {
> > > > - bool extended;
> > > > struct list_head pdevs;
> > > > struct list_head vdevs;
> > > > struct list_head peers;
> > > > - struct list_head peers_extd;
> > > > };
> > > >
> > > > #define ATH10K_TPC_TABLE_TYPE_FLAG 1
> > > > diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> > > > index 82a4c67f3672..89f7fde77cdf 100644
> > > > --- a/drivers/net/wireless/ath/ath10k/debug.c
> > > > +++ b/drivers/net/wireless/ath/ath10k/debug.c
> > > > @@ -315,25 +315,13 @@ static void ath10k_fw_stats_peers_free(struct list_head *head)
> > > > }
> > > > }
> > > >
> > > > -static void ath10k_fw_extd_stats_peers_free(struct list_head *head)
> > > > -{
> > > > - struct ath10k_fw_extd_stats_peer *i, *tmp;
> > > > -
> > > > - list_for_each_entry_safe(i, tmp, head, list) {
> > > > - list_del(&i->list);
> > > > - kfree(i);
> > > > - }
> > > > -}
> > > > -
> > > > static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
> > > > {
> > > > spin_lock_bh(&ar->data_lock);
> > > > ar->debug.fw_stats_done = false;
> > > > - ar->debug.fw_stats.extended = false;
> > >
> > > [shafi] this looks fine, but not removing the 'extended' variable
> > > from ath10k_fw_stats structure, I see the design for 'rx_duration'
> > > arguably some what convoluted !
> > I removed extended because it is now a write-only variable.
> > So I figured, there's no point in keeping it around? I don't have
> > access to the firmware interface documentation, so I don't know
> > if there's a reason why it would be good to have it later.
> > So please tell me, what information do we gain from it?
>
> [shafi] while parsing the stats from 'wmi' we clearly mark there whether
> the extended stats is available (or) not and if its there parse it and
> deal with it seperately
No, there's no difference between stats or extended stats (10.2.4 vs 10.4):
both ath10k_sta_update_extd_stats_rx_duration() [0]
and ath10k_sta_update_stats_rx_duration() [1] are adding the
ath10k_fw_stats_peer(_extd)->rx_duration to ath10k_sta->rx_duration.
With the merge of the peer stats and extended peer stats, this also
removed the only usage of stats->extended. And hence it becomes a
write-only variable. So there's no point in keeping it around ATM (as
all other extended peer stats entries aren't used).
> > > *We get periodic events from firmware updating 'ath10k_debug_fw_stats_process'
> > > *Fetch rx_duration from 'ath10k_wmi_pull_fw_stats(ar, skb, &stats)'
> > > {certainly 'stats' object is for this particular update only, and freed
> > > up later)
> > > *Update immediately using 'ath10k_sta_update_rx_duration'
> > >
> > > 'ath10k_wmi_pull_fw_stats' has a slightly different implementation
> > > for 10.2 and 10.4 (the later supporting extended peer stats)
> >
> > I see that 10.2.4's ath10k_wmi_10_2_4_op_pull_fw_stats()
> > passes the rx_duration as part of the wmi_10_2_4_ext_peer_stats
> > element which is basically a carbon-copy of wmi_10_2_4_peer_stats
> > (but with one extra __le32 for the rx_duration at the end.)
> > This rx_duration is then used to set the rx_duration field in the
> > generated ath10k_fw_stats_peer struct.
> >
> > 10.4's ath10k_wmi_10_4_op_pull_fw_stats() has a "fixed" wmi_10_4_peer_stats
> > element and uses an separate "fixed" wmi_10_4_peer_extd_stats element for
> > the communicating the rx_duration to the driver.
> >
> > Thing is, both function have the same signature. They produce the same
> > struct ath10k_fw_stats_peer for the given data in the sk_buff input. So
> > why does 10.4 need to have it's peer_extd infrastructure, when it can use
> > the existing rx_duration field in the *universal* ath10k_fw_stats_peer?
>
> [shafi] agreed we need to fix that, it would have been easier if 10.2.4
> and 10.4 had the same definitions.
Ok, I don't know the internals of the firmware to know what's the difference
between 10.2.4 and 10.4's rx_duration (how both firmwares define them
differently in this context) ? From what I can tell, it's just that
the entry has moved from the peer stats to extended peer stats.
Of course, this is based on the logic that both 10.2.4 and 10.4 rx_durations
end up being added to arsta->rx_duration in the same way. There's no scaling
or a comment that would indicate a difference.
> >
> > What's with the extra layers / HAL here? Because it looks like it's merged
> > back together in the same manner into the same arsta->rx_duration?
> > [ath10k_sta_update_stats_rx_duration() vs.
> > ath10k_sta_update_extd_stats_rx_duration() - they are almost carbon copies too]
> >
> > > > diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> > > > index c893314a191f..c7ec7b9e9b55 100644
> > > > --- a/drivers/net/wireless/ath/ath10k/wmi.c
> > > > +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> > > > @@ -3044,23 +3044,41 @@ static int ath10k_wmi_10_4_op_pull_fw_stats(struct ath10k *ar,
> > > > if ((stats_id & WMI_10_4_STAT_PEER_EXTD) == 0)
> > > > return 0;
> > > >
> > > > - stats->extended = true;
> > > > -
> > > > for (i = 0; i < num_peer_stats; i++) {
> > > > const struct wmi_10_4_peer_extd_stats *src;
> > > > - struct ath10k_fw_extd_stats_peer *dst;
> > > > + struct ath10k_fw_stats_peer *dst;
> > > >
> > > > src = (void *)skb->data;
> > > > if (!skb_pull(skb, sizeof(*src)))
> > > > return -EPROTO;
> > > >
> > > > - dst = kzalloc(sizeof(*dst), GFP_ATOMIC);
> > > > - if (!dst)
> > > > - continue;
> > > > + /* Because the stat data may exceed htc-wmi buffer
> > > > + * limit the firmware might split the stats data
> > > > + * and delivers it in multiple update events.
> > > > + * if we can't find the entry in the current event
> > > > + * payload, we have to look in main list as well.
> > > > + */
>
> [shafi] thanks ! sorry i might have missed this bug, did you happen
> to see this condition being hit ?
This was copied from ath10k_debug_fw_stats_process() [2]. I've added Michal
Kazior to the discussion since his patch "ath10k: fix fw stats processing"
added this in debug.c. I think he knows the firmware internals well enough
to tell if this is a problem or not. As it stands now, it is and will be
in the future.
> > > > + list_for_each_entry(dst, &stats->peers, list) {
> > > > + if (ether_addr_equal(dst->peer_macaddr,
> > > > + src->peer_macaddr.addr))
> > > > + goto found;
> > > > + }
> > > > +
>
> [shafi] Again, we can simply cache the macaddress and rx_duration
> and deal with it later, rather than doing the whole lookup here ?
> Will it be an overhead for large number of clients ?
Well, show me how you would do it more efficiently otherwise? I don't
see how you can cache the macaddress and rx_duration since you are
basically forced to process all the peer stats first and later all
the extended peer stats. They don't mix.
As for how expensive it is: From what I can tell, the 10.4 firmware
sends the stat events every few seconds. So they are not part of any
rx or tx hot-paths. The list_for_each within the for
(i = 0; i < num_peers;i++) is actually in the O(1) class as far
as both loops go. This might sound funny at first, but the number of
extended peer list is limited by TARGET_10_4_MAX_PEER_EXT_STATS to 16.
And thanks to (***) the limit of num_peers is also 16. Furthermore
we can add a if (ath10k_peer_stats_enabled(ar)) guard to skip it
entirely if the stats are disabled.
> > > > +#ifdef CONFIG_ATH10K_DEBUGFS
> > > > + list_for_each_entry(dst, &ar->debug.fw_stats.peers, list) {
> > > > + if (ether_addr_equal(dst->peer_macaddr,
> > > > + src->peer_macaddr.addr))
> > > > + goto found;
> > > > + }
> > > > +#endif
>
> [shafi] again, this could be handled seperately.
This is more expensive. As fw_stats.peers can contain more entries than 16.
However, this might be unnecessary if both peers and extended peers stats
entries in the wmi event are always for the same stations.
Note: There's an alternative way too. Instead of writing rx_duration into
ath10k_fw_stats, we could skip the middle man write it directly into
arsta->rx_duration. This would also mean that we can get rid of
ath10k_sta_update_extd_stats_rx_duration(), ath10k_sta_update_stats_rx_duration()
and ath10k_sta_update_rx_duration(). This has the benifit that we can
remove even more.
> > > > +
> > > > + ath10k_dbg(ar, ATH10K_DBG_WMI,
> > > > + "Orphaned extended stats entry for station %pM.\n",
> > > > + src->peer_macaddr.addr);
> > > > + continue;
> > > >
> > > > - ether_addr_copy(dst->peer_macaddr, src->peer_macaddr.addr);
> > > > +found:
> > > > dst->rx_duration = __le32_to_cpu(src->rx_duration);
> > > > - list_add_tail(&dst->list, &stats->peers_extd);
> > > > }
> > > >
> > > > return 0;
> > >
> > > [shafi] Yes i am bit concerned about this change making 10.4 to update
> > > over the existing peer_stats structure, the idea is to maintain uniformity
> > > between the structures shared between ath10k and its corresponding to avoid
> > > confusion/ bugs in the future. Kindly let me know your thoughts, feel free
> > > to correct me if any of my analysis is incorrect. thank you !
> > Isn't the point of the ath10k_wmi_10_*_op_pull_fw_stats() functions to make
> > a "universal" statistic (in your case a unified ath10k_fw_stats_peer structure)
> > that other functions can use, without caring about if the FW was 10.4
> > or 10.2.4?
> >
> > There's no indication that the rx_duration field in wmi_10_2_4_ext_peer_stats
> > conveys any different information than the rx_duration in
> > wmi_10_4_peer_extd_stats. So, what's going on here? Can't you just make
> > wmi_10_4_peer_extd_stats's rx_duration use the existing field in
> > ath10k_fw_stats_peer? And if not: why exactly?
> >
> [shafi] I will soon test your change and keep you posted. We will also
> get Kalle's take/view on this.
Ok. That said, I added him to the CC from the beginning and so far
he silently agreed.
Regards,
Christian
[0] <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath10k/debugfs_sta.c#L21>
[1] <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath10k/debugfs_sta.c#L40>
[2] <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath10k/debug.c#L360>
^ permalink raw reply
* Re: pull-request: wireless-drivers 2016-12-22
From: David Miller @ 2016-12-22 16:16 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <8760mcrobk.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Thu, 22 Dec 2016 17:11:27 +0200
> before the holidays a really small pull request for 4.10. I just want to
> have the regressions in rtlwifi and ath9k fixed quickly so I send this
> earlier than I normally would.
>
> Please let me know if there are any problems.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH] ath10k: merge extended peer info data with existing peers info
From: Mohammed Shafi Shajakhan @ 2016-12-22 15:48 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, ath10k, Kalle Valo
In-Reply-To: <2696316.Ugl5Pim1oL@debian64>
Hi Christian,
once again sorry for the delay
>
> On Monday, December 19, 2016 10:19:57 PM CET Mohammed Shafi Shajakhan wrote:
> > On Sat, Dec 17, 2016 at 06:46:34PM +0100, Christian Lamparter wrote:
> > > The 10.4 firmware adds extended peer information to the
> > > firmware's statistics payload. This additional info is
> > > stored as a separate data field. During review of
> > > "ath10k: add accounting for the extended peer statistics" [0]
> > >
> > > Mohammed Shafi Shajakhan commented that the extended peer statistics
> > > lists are of little use:"... there is not much use in appending
> > > the extended peer stats (which gets periodically updated) to the
> > > linked list '&ar->debug.fw_stats.peers_extd)' and should we get
> > > rid of the below (and the required cleanup as well)
> > >
> > > list_splice_tail_init(&stats.peers_extd,
> > > &ar->debug.fw_stats.peers_extd);
> > >
> > > since rx_duration is getting updated periodically to the per sta
> > > information."
> > >
> > > This patch replaces the extended peers list with a lookup and
> > > puts the retrieved data (rx_duration) into the existing
> > > ath10k_fw_stats_peer entry that was created earlier.
> >
> > [shafi] Its good to maintain the extended stats variable
> > and retain the two different functions to update rx_duration.
> >
> > a) extended peer stats supported - mainly for 10.4
> > b) extender peer stats not supported - for 10.2
> Well, I have to ask why you want to retain the two different
> functions to update the same arsta->rx_duration? I think a
> little bit of code that helps to explain what's on your mind
> (or how you would do it) would help immensely in this case.
> Since I have the feeling that this is the problem here.
> So please explain it in C(lang).
[shafi] I see you prefer to stuff the 'rx_duration' from
the extended stats to the existing global 'ath10k_peer_stats'
The idea of extended stats is, ideally its not going to stop
for 'rx_duration' . Extended stats is maintained as a seperate
list / entry for addition of new fields as well
>
> > > [0] <https://lkml.kernel.org/r/992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
> > > Cc: Mohammed Shafi Shajakhan <mohammed@codeaurora.org>
> > > Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> > > ---
> > > drivers/net/wireless/ath/ath10k/core.h | 2 --
> > > drivers/net/wireless/ath/ath10k/debug.c | 17 --------------
> > > drivers/net/wireless/ath/ath10k/debugfs_sta.c | 32 ++-----------------------
> > > drivers/net/wireless/ath/ath10k/wmi.c | 34 ++++++++++++++++++++-------
> > > 4 files changed, 28 insertions(+), 57 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
> > > index 09ff8b8a6441..3fffbbb18c25 100644
> > > --- a/drivers/net/wireless/ath/ath10k/core.h
> > > +++ b/drivers/net/wireless/ath/ath10k/core.h
> > > @@ -268,11 +268,9 @@ struct ath10k_fw_stats_pdev {
> > > };
> > >
> > > struct ath10k_fw_stats {
> > > - bool extended;
> > > struct list_head pdevs;
> > > struct list_head vdevs;
> > > struct list_head peers;
> > > - struct list_head peers_extd;
> > > };
> > >
> > > #define ATH10K_TPC_TABLE_TYPE_FLAG 1
> > > diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> > > index 82a4c67f3672..89f7fde77cdf 100644
> > > --- a/drivers/net/wireless/ath/ath10k/debug.c
> > > +++ b/drivers/net/wireless/ath/ath10k/debug.c
> > > @@ -315,25 +315,13 @@ static void ath10k_fw_stats_peers_free(struct list_head *head)
> > > }
> > > }
> > >
> > > -static void ath10k_fw_extd_stats_peers_free(struct list_head *head)
> > > -{
> > > - struct ath10k_fw_extd_stats_peer *i, *tmp;
> > > -
> > > - list_for_each_entry_safe(i, tmp, head, list) {
> > > - list_del(&i->list);
> > > - kfree(i);
> > > - }
> > > -}
> > > -
> > > static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
> > > {
> > > spin_lock_bh(&ar->data_lock);
> > > ar->debug.fw_stats_done = false;
> > > - ar->debug.fw_stats.extended = false;
> >
> > [shafi] this looks fine, but not removing the 'extended' variable
> > from ath10k_fw_stats structure, I see the design for 'rx_duration'
> > arguably some what convoluted !
> I removed extended because it is now a write-only variable.
> So I figured, there's no point in keeping it around? I don't have
> access to the firmware interface documentation, so I don't know
> if there's a reason why it would be good to have it later.
> So please tell me, what information do we gain from it?
[shafi] while parsing the stats from 'wmi' we clearly mark there whether
the extended stats is available (or) not and if its there parse it and
deal with it seperately
>
> > *We get periodic events from firmware updating 'ath10k_debug_fw_stats_process'
> > *Fetch rx_duration from 'ath10k_wmi_pull_fw_stats(ar, skb, &stats)'
> > {certainly 'stats' object is for this particular update only, and freed
> > up later)
> > *Update immediately using 'ath10k_sta_update_rx_duration'
> >
> > 'ath10k_wmi_pull_fw_stats' has a slightly different implementation
> > for 10.2 and 10.4 (the later supporting extended peer stats)
>
> I see that 10.2.4's ath10k_wmi_10_2_4_op_pull_fw_stats()
> passes the rx_duration as part of the wmi_10_2_4_ext_peer_stats
> element which is basically a carbon-copy of wmi_10_2_4_peer_stats
> (but with one extra __le32 for the rx_duration at the end.)
> This rx_duration is then used to set the rx_duration field in the
> generated ath10k_fw_stats_peer struct.
>
> 10.4's ath10k_wmi_10_4_op_pull_fw_stats() has a "fixed" wmi_10_4_peer_stats
> element and uses an separate "fixed" wmi_10_4_peer_extd_stats element for
> the communicating the rx_duration to the driver.
>
> Thing is, both function have the same signature. They produce the same
> struct ath10k_fw_stats_peer for the given data in the sk_buff input. So
> why does 10.4 need to have it's peer_extd infrastructure, when it can use
> the existing rx_duration field in the *universal* ath10k_fw_stats_peer?
[shafi] agreed we need to fix that, it would have been easier if 10.2.4
and 10.4 had the same definitions.
>
> What's with the extra layers / HAL here? Because it looks like it's merged
> back together in the same manner into the same arsta->rx_duration?
> [ath10k_sta_update_stats_rx_duration() vs.
> ath10k_sta_update_extd_stats_rx_duration() - they are almost carbon copies too]
>
> > > diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> > > index c893314a191f..c7ec7b9e9b55 100644
> > > --- a/drivers/net/wireless/ath/ath10k/wmi.c
> > > +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> > > @@ -3044,23 +3044,41 @@ static int ath10k_wmi_10_4_op_pull_fw_stats(struct ath10k *ar,
> > > if ((stats_id & WMI_10_4_STAT_PEER_EXTD) == 0)
> > > return 0;
> > >
> > > - stats->extended = true;
> > > -
> > > for (i = 0; i < num_peer_stats; i++) {
> > > const struct wmi_10_4_peer_extd_stats *src;
> > > - struct ath10k_fw_extd_stats_peer *dst;
> > > + struct ath10k_fw_stats_peer *dst;
> > >
> > > src = (void *)skb->data;
> > > if (!skb_pull(skb, sizeof(*src)))
> > > return -EPROTO;
> > >
> > > - dst = kzalloc(sizeof(*dst), GFP_ATOMIC);
> > > - if (!dst)
> > > - continue;
> > > + /* Because the stat data may exceed htc-wmi buffer
> > > + * limit the firmware might split the stats data
> > > + * and delivers it in multiple update events.
> > > + * if we can't find the entry in the current event
> > > + * payload, we have to look in main list as well.
> > > + */
[shafi] thanks ! sorry i might have missed this bug, did you happen
to see this condition being hit ?
> > > + list_for_each_entry(dst, &stats->peers, list) {
> > > + if (ether_addr_equal(dst->peer_macaddr,
> > > + src->peer_macaddr.addr))
> > > + goto found;
> > > + }
> > > +
[shafi] Again, we can simply cache the macaddress and rx_duration
and deal with it later, rather than doing the whole lookup here ?
Will it be an overhead for large number of clients ?
> > > +#ifdef CONFIG_ATH10K_DEBUGFS
> > > + list_for_each_entry(dst, &ar->debug.fw_stats.peers, list) {
> > > + if (ether_addr_equal(dst->peer_macaddr,
> > > + src->peer_macaddr.addr))
> > > + goto found;
> > > + }
> > > +#endif
[shafi] again, this could be handled seperately.
> > > +
> > > + ath10k_dbg(ar, ATH10K_DBG_WMI,
> > > + "Orphaned extended stats entry for station %pM.\n",
> > > + src->peer_macaddr.addr);
> > > + continue;
> > >
> > > - ether_addr_copy(dst->peer_macaddr, src->peer_macaddr.addr);
> > > +found:
> > > dst->rx_duration = __le32_to_cpu(src->rx_duration);
> > > - list_add_tail(&dst->list, &stats->peers_extd);
> > > }
> > >
> > > return 0;
> >
> > [shafi] Yes i am bit concerned about this change making 10.4 to update
> > over the existing peer_stats structure, the idea is to maintain uniformity
> > between the structures shared between ath10k and its corresponding to avoid
> > confusion/ bugs in the future. Kindly let me know your thoughts, feel free
> > to correct me if any of my analysis is incorrect. thank you !
> Isn't the point of the ath10k_wmi_10_*_op_pull_fw_stats() functions to make
> a "universal" statistic (in your case a unified ath10k_fw_stats_peer structure)
> that other functions can use, without caring about if the FW was 10.4
> or 10.2.4?
>
> There's no indication that the rx_duration field in wmi_10_2_4_ext_peer_stats
> conveys any different information than the rx_duration in
> wmi_10_4_peer_extd_stats. So, what's going on here? Can't you just make
> wmi_10_4_peer_extd_stats's rx_duration use the existing field in
> ath10k_fw_stats_peer? And if not: why exactly?
>
[shafi] I will soon test your change and keep you posted. We will also
get Kalle's take/view on this.
regards,
shafi
^ permalink raw reply
* pull-request: wireless-drivers 2016-12-22
From: Kalle Valo @ 2016-12-22 15:11 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
before the holidays a really small pull request for 4.10. I just want to
have the regressions in rtlwifi and ath9k fixed quickly so I send this
earlier than I normally would.
Please let me know if there are any problems.
Kalle
The following changes since commit ad688cdbb076833ba17fc65591cd0fe01900a5cf:
stmmac: fix memory barriers (2016-12-19 11:05:02 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2016-12-22
for you to fetch changes up to 22b68b93ae2506bd56ee3bf232a51bc8ab955b56:
rtlwifi: Fix kernel oops introduced with commit e49656147359 (2016-12-21 16:34:16 +0200)
----------------------------------------------------------------
wireless-drivers fixes for 4.10
All small fixes this time, especially important are the regression
fixes for rtlwifi and ath9k.
----------------------------------------------------------------
Arend Van Spriel (2):
brcmfmac: fix memory leak in brcmf_cfg80211_attach()
brcmfmac: fix uninitialized field in scheduled scan ssid configuration
Ben Greear (1):
ath10k: free host-mem with DMA_BIRECTIONAL flag
Larry Finger (1):
rtlwifi: Fix kernel oops introduced with commit e49656147359
Tobias Klausmann (1):
ath9k: do not return early to fix rcu unlocking
drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 7 +++++--
.../net/wireless/broadcom/brcm80211/brcmfmac/pno.c | 1 +
drivers/net/wireless/realtek/rtlwifi/core.c | 3 ++-
5 files changed, 10 insertions(+), 5 deletions(-)
^ permalink raw reply
* Question: Packet drop criterion
From: Ferran Quer i Guerrero @ 2016-12-22 12:34 UTC (permalink / raw)
To: linux-wireless
Hello everyone,
I would like to modify the retry threshold for dropping a packet using
mesh mode. I tried with iw
iw phy <phyname> set retry [short <limit>] [long <limit>]
with short and long limits equal to 10 first and later 5, but I couldn't
tell any effect. I'm checking by adding a printk in `status.c` and
manually shutting down (ifdown) the mesh-peered interface to cause
packet retries. It turns out that the tx report only appears when
`retry_count` is 28 (after many continued drops, it also appears at 23,
24, 25 or retries).=20
void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb=
)
{
/* ... */
if (info->flags & IEEE80211_TX_STAT_TX_FILTERED) {
ieee80211_handle_filtered_frame(local, sta, skb);=
rcu_read_unlock();
return;
} else {
if (!acked)
sta->tx_retry_failed++;
sta->tx_retry_count +=3D retry_count;
/* Dirty debugging */
printk("Packet dropped. Retry count: %d",
retry_count);
}
rate_control_tx_status(local, sband, sta, skb);
if (ieee80211_vif_is_mesh(&sta->sdata->vif))
ieee80211s_update_metric(local, sta, skb);
/* ... */
}
I'm using linux backports v3.12.8, ath9k wifi dongles, and interfaces on
mesh point mode.
Did I get wrong the iw command?
Is it Minstrel who decides the retry trheshold?
Is it Atheros driver?
Does it have anything to do with mesh mode?
I'm trying to find the responsible at the source code, but haven't
succeeded yet, so I decided to write to yo.
Thank you very much
Ferran Quer
^ permalink raw reply
* Re: [PATCH 2/2] net: wireless: fix to uses struct
From: Arend Van Spriel @ 2016-12-22 9:37 UTC (permalink / raw)
To: Ozgur Karatas, johannes, David Miller
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <608881482358981@web17g.yandex.ru>
On 21-12-2016 23:23, Ozgur Karatas wrote:
>
> The patch fixed to struct uses in reg.c, I think doesn't need to be use to "struct".
> There is dataype not have to logical link and each is different definitons.
>
> I'm undecided on this patch. I compiled and didn't to errors.
There must be something wrong in the way you build stuff, but still just
looking at your patch it is fundamentally wrong, which is what makes
people say "do a basic C course". Let me try and explain below.
> Signed-off-by: Ozgur Karatas <okaratas@member.fsf.org>
> ---
> net/wireless/reg.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index 5dbac37..5b70970 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -490,7 +490,7 @@ static int reg_query_builtin(const char *alpha2)
> if (!regdom)
> return -ENODATA;
>
> - request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
> + request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
Making it more abstract to explain what you are doing:
x = foo(sizeof(T), GFP_KERNEL); where T is "struct Y".
which you change to:
x = foo(sizeof(*Y), GFP_KERNEL);
Y has no meaning for the sizeof operator and the compiler will yell at
it being an unknown identifier. In a lot of kernel code you will find:
x = foo(sizeof(*x), GFP_KERNEL);
which is probably the coding style fix you are attempting to make, but
miserably fail to do so. There is nothing linux kernel specific about
this. It is really fundamental knowledge of the C language. The correct
change for this instance is:
- request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*request), GFP_KERNEL);
Hope this helps to come up with a working V2 of this patch.
Regards,
Arend
^ permalink raw reply
* RE: [PATCH v4 1/2] mmc: API for accessing host supported maximum segment count and size
From: Amitkumar Karwar @ 2016-12-22 9:09 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, Ulf Hansson
Cc: Nishant Sarmukadam, Wei-Ning Huang, linux-mmc@vger.kernel.org,
Cathy Luo, Xinming Hu
In-Reply-To: <1466069006-10757-1-git-send-email-akarwar@marvell.com>
Hi Ulf,
> From: Amitkumar Karwar [mailto:akarwar@marvell.com]
> Sent: Thursday, June 16, 2016 2:53 PM
> To: linux-wireless@vger.kernel.org
> Cc: Nishant Sarmukadam; Wei-Ning Huang; linux-mmc@vger.kernel.org;
> Cathy Luo; Xinming Hu; Amitkumar Karwar
> Subject: [PATCH v4 1/2] mmc: API for accessing host supported maximum
> segment count and size
>
> From: Xinming Hu <huxm@marvell.com>
>
> sdio device drivers need be able to get the host supported max_segs and
> max_seg_size, so that they know the buffer size to allocate while
> utilizing the scatter/gather DMA buffer list.
>
> This patch provides API for this purpose.
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> ---
> v2: v2 was submitted with minor improvement like replacing BUG_ON()
> with WARN_ON()
> v3: Addressed below review comments from Ulf Hansson
> a) In v3, patch has been split into two separate patches.
> b) Patch 1/2 introduces an API to fetch max_seg_size and max_segs
> c) Replaced WARN_ON() with proper error code when sg_ptr->length is
> invalid
> d) Instead of duplicating the code in mmc_io_rw_extended(), extra
> bool parameter
> has been added to this function and used it in new APIs for SG.
> v4: Removed WARN_ON() calls in newly added APIs. It's gets called in
> probe handler.
> Caller already takes care of it(Shawn Lin).
> ---
> drivers/mmc/core/sdio_io.c | 21
> +++++++++++++++++++++
> .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 6 +++---
> include/linux/mmc/sdio_func.h | 3 +++
> 3 files changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
> index 78cb4d5..b1ecacc 100644
> --- a/drivers/mmc/core/sdio_io.c
> +++ b/drivers/mmc/core/sdio_io.c
> @@ -720,3 +720,24 @@ int sdio_set_host_pm_flags(struct sdio_func *func,
> mmc_pm_flag_t flags)
> return 0;
> }
> EXPORT_SYMBOL_GPL(sdio_set_host_pm_flags);
> +
> +/**
> + * sdio_get_host_max_seg_size - get host maximum segment size
> + * @func: SDIO function attached to host
> + */
> +unsigned int sdio_get_host_max_seg_size(struct sdio_func *func) {
> + return func->card->host->max_seg_size; }
> +EXPORT_SYMBOL_GPL(sdio_get_host_max_seg_size);
> +
> +/**
> + * sdio_get_host_max_seg_count - get host maximum segment count
> + * @func: SDIO function attached to host
> + */
> +unsigned short sdio_get_host_max_seg_count(struct sdio_func *func) {
> + return func->card->host->max_segs;
> +}
> +EXPORT_SYMBOL_GPL(sdio_get_host_max_seg_count);
> +
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> index c4b89d2..ba579f4 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> @@ -896,9 +896,9 @@ void brcmf_sdiod_sgtable_alloc(struct
> brcmf_sdio_dev *sdiodev)
> max_blocks = min_t(uint, host->max_blk_count, 511u);
> sdiodev->max_request_size = min_t(uint, host->max_req_size,
> max_blocks * func->cur_blksize);
> - sdiodev->max_segment_count = min_t(uint, host->max_segs,
> - SG_MAX_SINGLE_ALLOC);
> - sdiodev->max_segment_size = host->max_seg_size;
> + sdiodev->max_segment_count = min_t(uint, SG_MAX_SINGLE_ALLOC,
> + sdio_get_host_max_seg_count(func));
> + sdiodev->max_segment_size = sdio_get_host_max_seg_size(func);
>
> if (!sdiodev->sg_support)
> return;
> diff --git a/include/linux/mmc/sdio_func.h
> b/include/linux/mmc/sdio_func.h index aab032a..b2b91df 100644
> --- a/include/linux/mmc/sdio_func.h
> +++ b/include/linux/mmc/sdio_func.h
> @@ -159,4 +159,7 @@ extern void sdio_f0_writeb(struct sdio_func *func,
> unsigned char b, extern mmc_pm_flag_t sdio_get_host_pm_caps(struct
> sdio_func *func); extern int sdio_set_host_pm_flags(struct sdio_func
> *func, mmc_pm_flag_t flags);
>
> +unsigned short sdio_get_host_max_seg_count(struct sdio_func *func);
> +unsigned int sdio_get_host_max_seg_size(struct sdio_func *func);
> +
> #endif /* LINUX_MMC_SDIO_FUNC_H */
This has been pending for a while.
Any further review comments on this v4 patch series?
Regards,
Amitkumar Karwar
^ permalink raw reply
* RE: ATH9 driver issues on ARM64
From: Bharat Kumar Gogada @ 2016-12-22 7:19 UTC (permalink / raw)
To: Bharat Kumar Gogada, Bjorn Helgaas
Cc: Tobias Klausmann, Kalle Valo, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, Marc Zyngier,
Janusz.Dziedzic@tieto.com, rmanohar@qti.qualcomm.com,
ath9k-devel@qca.qualcomm.com, linux-wireless@vger.kernel.org
In-Reply-To: <8520D5D51A55D047800579B094147198263AADCA@XAP-PVEXMBX02.xlnx.xilinx.com>
Hi All,
After further debugging we know the place it hangs.
In function:
static int ath_reset_internal (struct ath_softc *sc, struct ath9k_channel *=
hchan)
{
disable_irq(sc->irq);
tasklet_disable(&sc->intr_tq);
tasklet_disable(&sc->bcon_tasklet);
spin_lock_bh(&sc->sc_pcu_lock);
....
....
....
if (!ath_complete_reset(sc, true)) -> This function enables hardwar=
e interrupts
r =3D -EIO;
out:
enable_irq(sc->irq); -> Here IRQ line state is changed to enable =
state
spin_unlock_bh(&sc->sc_pcu_lock);
tasklet_enable(&sc->bcon_tasklet);
tasklet_enable(&sc->intr_tq);
=09
}
static bool ath_complete_reset(struct ath_softc *sc, bool start)
{
struct ath_hw *ah =3D sc->sc_ah;
struct ath_common *common =3D ath9k_hw_common(ah);
unsigned long flags;
ath9k_calculate_summary_state(sc, sc->cur_chan);
ath_startrecv(sc);
....
....
=20
sc->gtt_cnt =3D 0;
ath9k_hw_set_interrupts(ah); -> Here hardware interrupts are being=
enabled
ath9k_hw_enable_interrupts(ah); -> We see hang after this line
ieee80211_wake_queues(sc->hw);
ath9k_p2p_ps_timer(sc);
return true;
}
Before changing IRQ line to to enabled state, hardware interrupts are being=
enabled.=20
Wont this cause a race condition where within this period of hardware raise=
s an interrupt, but IRQ line state is disabled state, this will=20
reach the following condition making EP handler not being invoked.
void handle_simple_irq(struct irq_desc *desc)
{
raw_spin_lock(&desc->lock);
...=20
if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data))) =
{ // This condition is reaching and becoming true.
desc->istate |=3D IRQS_PENDING;
goto out_unlock;
} =20
kstat_incr_irqs_this_cpu(desc);
handle_irq_event(desc);
out_unlock:
raw_spin_unlock(&desc->lock);
}
We see hang at that statement, without reaching back enable_irq, looks like=
by this time CPU is in stall.
Can any tell why hardware interrupts are being enabled before kernel changi=
ng IRQ line state?
Regards,
Bharat
>=20
> > On Sat, Dec 10, 2016 at 02:40:48PM +0000, Bharat Kumar Gogada wrote:
> > > Hi,
> > >
> > > After taking some more lecroy traces, we see that after 2nd ASSERT
> > > from EP
> > on ARM64 we see continuous data movement of 32 dwords or 12 dwords and
> > never sign of DEASSERT.
> > > Comparatively on working traces (x86) after 2nd assert there are
> > > only BAR
> > register reads and writes and then DEASSERT, for almost most of the
> > interrupts and we haven't seen 12 or 32 dwords data movement on this tr=
ace.
> > >
> > > I did not work on EP wifi/network drivers, any help why EP needs
> > > those many
> > number of data at scan time ?
> >
> > The device doesn't know whether it's in an x86 or an arm64 system. If
> > it works differently, it must be because the PCI core or the driver is
> > programming the device differently.
> >
> > You should be able to match up Memory transactions from the host in
> > the trace with things the driver does. For example, if you see an
> > Assert_INTx message from the device, you should eventually see a
> > Memory Read from the host to get the ISR, i.e., some read done in the b=
owels
> of ath9k_hw_getisr().
> >
> > I don't know how the ath9k device works, but there must be some Memory
> > Read or Write done by the driver that tells the device "we've handled t=
his
> interrupt".
> > The device should then send a Deassert_INTx; of course, if the device
> > still requires service, e.g., because it has received more packets, it
> > might leave the INTx asserted.
> >
> > I doubt you'd see exactly the same traces on x86 and arm64 because
> > they aren't seeing the same network packets and the driver is executing=
at
> different rates.
> > But you should at least be able to identify interrupt assertion and
> > the actions of the driver's interrupt service routine.
>=20
>=20
> Thanks Bjorn.
>=20
> As you mentioned we did try to debug in that path. After we start scan af=
ter 2nd
> ASSERT we see lots of 32 and 12 dword data, and in function void
> ath9k_hw_enable_interrupts(struct ath_hw *ah) {
> ...
> ..
> REG_WRITE(ah, AR_IER, AR_IER_ENABLE);
> // EP driver hangs at this
> position after 2nd ASSERT
> // The following writes are not
> happening
> if (!AR_SREV_9100(ah)) {
> REG_WRITE(ah, AR_INTR_ASYNC_ENABLE, async_mask);
> REG_WRITE(ah, AR_INTR_ASYNC_MASK, async_mask);
>=20
> REG_WRITE(ah, AR_INTR_SYNC_ENABLE, sync_default);
> REG_WRITE(ah, AR_INTR_SYNC_MASK, sync_default);
> }
> ath_dbg(common, INTERRUPT, "AR_IMR 0x%x IER 0x%x\n",
> REG_READ(ah, AR_IMR), REG_READ(ah, AR_IER)); } The above =
funtion
> is invoked from tasklet.
> I tried several boots every it stops here. The condition (!AR_SREV_9100(a=
h)) is
> true as per before 1st ASSERT handling.
>=20
> Regards,
> Bharat
>=20
> >
> > > > Hello there,
> > > >
> > > > as this is a thread about ath9k and ARM64, i'm not sure if i
> > > > should answer here or not, but i have similar "stalls" with ath9k
> > > > on x86_64 (starting with 4.9rc), stack trace is posted down below
> > > > where the original
> > ARM64 stall traces are.
> > > >
> > > > Greetings,
> > > >
> > > > Tobias
> > > >
> > > >
> > > > On 08.12.2016 18:36, Kalle Valo wrote:
> > > > > Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> writes:
> > > > >
> > > > >> > [+cc Kalle, ath9k list]
> > > > > Thanks, but please also CC linux-wireless. Full thread below for
> > > > > the folks there.
> > > > >
> > > > >>> On Thu, Dec 08, 2016 at 01:49:42PM +0000, Bharat Kumar Gogada
> > wrote:
> > > > >>>> Hi,
> > > > >>>>
> > > > >>>> Did anyone test Atheros ATH9
> > > > >>>> driver(drivers/net/wireless/ath/ath9k/)
> > > > >>>> on ARM64. The end point is TP link wifi card with which
> > > > >>>> supports only legacy interrupts.
> > > > >>> If it works on other arches and the arm64 PCI enumeration
> > > > >>> works, my first guess would be an INTx issue, e.g., maybe the
> > > > >>> driver is waiting for an interrupt that never arrives.
> > > > >> We are not sure for now.
> > > > >>>> We are trying to test it on ARM64 with
> > > > >>>> (drivers/pci/host/pcie-xilinx-nwl.c) as root port.
> > > > >>>>
> > > > >>>> EP is getting enumerated and able to link up.
> > > > >>>>
> > > > >>>> But when we start scan system gets hanged.
> > > > >>> When you say the system hangs when you start a scan, I assume
> > > > >>> you mean a wifi scan, not the PCI enumeration. A problem with
> > > > >>> a wifi scan might cause a *process* to hang, but it shouldn't
> > > > >>> hang the entire system.
> > > > >>>
> > > > >> Yes wifi scan.
> > > > >>>> When we took trace we see that after we start scan assert
> > > > >>>> message is sent but there is no de assert from end point.
> > > > >>> Are you talking about a trace from a PCIe analyzer? Do you
> > > > >>> see an Assert_INTx PCIe message on the link?
> > > > >>>
> > > > >> Yes lecroy trace, yes we do see Assert_INTx and Deassert_INTx
> > > > >> happening
> > > > when we do interface link up.
> > > > >> When we have less debug prints in Atheros driver, and do wifi
> > > > >> scan we see Assert_INTx but never Deassert_INTx,
> > > > >>>> What might cause end point not sending de assert ?
> > > > >>> If the endpoint doesn't send a Deassert_INTx message, I expect
> > > > >>> that would mean the driver didn't service the interrupt and
> > > > >>> remove the condition that caused the device to assert the
> > > > >>> interrupt in the first place.
> > > > >>>
> > > > >>> If the driver didn't receive the interrupt, it couldn't
> > > > >>> service it, of course. You could add a printk in the ath9k
> > > > >>> interrupt service routine to see if you ever get there.
> > > > >>>
> > > > >> The interrupt behavior is changing w.r.t amount of debug prints
> > > > >> we add. (I kept many prints to aid debug)
> > > > >> root@Xilinx-ZCU102-2016_3:~# iw dev
> > > > wlan0 scan
> > > > >> [ 83.064675] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.069486] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.074257] ath9k_hw_kill_interrupts 793
> > > > >> [ 83.078260] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.083107] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.087882] ath9k_hw_kill_interrupts 793
> > > > >> [ 83.095450] ath9k_hw_enable_interrupts 821
> > > > >> [ 83.099557] ath9k_hw_enable_interrupts 825
> > > > >> [ 83.103721] ath9k_hw_enable_interrupts 832
> > > > >> [ 83.107887] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.112748] AR_SREV_9100 0
> > > > >> [ 83.115438] ath9k_hw_enable_interrupts 848
> > > > >> [ 83.119607] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.124389] ath9k_hw_intrpend 762
> > > > >> [ 83.127761] (AR_SREV_9340(ah) val 0
> > > > >> [ 83.131234] ath9k_hw_intrpend 767
> > > > >> [ 83.134628] ath_isr 603
> > > > >> [ 83.137134] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.141995] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.146771] ath9k_hw_kill_interrupts 793
> > > > >> [ 83.150864] ath9k_hw_enable_interrupts 821
> > > > >> [ 83.154971] ath9k_hw_enable_interrupts 825
> > > > >> [ 83.159135] ath9k_hw_enable_interrupts 832
> > > > >> [ 83.163300] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.168161] AR_SREV_9100 0
> > > > >> [ 83.170852] ath9k_hw_enable_interrupts 848
> > > > >> [ 83.170855] ath9k_hw_intrpend 762
> > > > >> [ 83.178398] (AR_SREV_9340(ah) val 0
> > > > >> [ 83.181873] ath9k_hw_intrpend 767
> > > > >> [ 83.185265] ath_isr 603
> > > > >> [ 83.187773] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.192635] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.197411] ath9k_hw_kill_interrupts 793
> > > > >> [ 83.201414] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.206258] ath9k_hw_enable_interrupts 821
> > > > >> [ 83.210368] ath9k_hw_enable_interrupts 825
> > > > >> [ 83.214531] ath9k_hw_enable_interrupts 832
> > > > >> [ 83.218698] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.223558] AR_SREV_9100 0
> > > > >> [ 83.226243] ath9k_hw_enable_interrupts 848
> > > > >> [ 83.226246] ath9k_hw_intrpend 762
> > > > >> [ 83.233794] (AR_SREV_9340(ah) val 0
> > > > >> [ 83.237268] ath9k_hw_intrpend 767
> > > > >> [ 83.240661] ath_isr 603
> > > > >> [ 83.243169] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.248030] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.252806] ath9k_hw_kill_interrupts 793
> > > > >> [ 83.256811] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.261651] ath9k_hw_enable_interrupts 821
> > > > >> [ 83.265753] ath9k_hw_enable_interrupts 825
> > > > >> [ 83.269919] ath9k_hw_enable_interrupts 832
> > > > >> [ 83.274083] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.278945] AR_SREV_9100 0
> > > > >> [ 83.281630] ath9k_hw_enable_interrupts 848
> > > > >> [ 83.281633] ath9k_hw_intrpend 762
> > > > >> [ 83.281634] (AR_SREV_9340(ah) val 0
> > > > >> [ 83.281637] ath9k_hw_intrpend 767
> > > > >> [ 83.281648] ath_isr 603
> > > > >> [ 83.281649] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.281651] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.281654] ath9k_hw_kill_interrupts 793
> > > > >> [ 83.312192] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.317030] ath9k_hw_enable_interrupts 821
> > > > >> [ 83.321132] ath9k_hw_enable_interrupts 825
> > > > >> [ 83.325297] ath9k_hw_enable_interrupts 832
> > > > >> [ 83.329463] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.334324] AR_SREV_9100 0
> > > > >> [ 83.337014] ath9k_hw_enable_interrupts 848
> > > > >> ..
> > > > >> ..
> > > > >> This log continues until I turn off board without obtaining scan=
ning
> result.
> > > > >>
> > > > >> In between I get following cpu stall outputs :
> > > > >> 230.457179] INFO: rcu_sched self-detected stall on CPU
> > > > >> [ 230.457185] 2-...: (31314 ticks this GP)
> > > > idle=3D2d1/140000000000001/0 softirq=3D1400/1400 fqs=3D36713
> > > > >> [ 230.457189] (t=3D36756 jiffies g=3D161 c=3D160 q=3D16169)
> > > > >> [ 230.457191] Task dump for CPU 2:
> > > > >> [ 230.457196] kworker/u8:4 R running task 0 1342 =
2
> > 0x00000002
> > > > >> [ 230.457207] Workqueue: phy0 ieee80211_scan_work [
> > > > >> 230.457208] Call trace:
> > > > >> [ 230.457214] [<ffffff8008089860>] dump_backtrace+0x0/0x198 [
> > > > >> 230.457219] [<ffffff8008089a0c>] show_stack+0x14/0x20 [
> > > > >> 230.457224] [<ffffff80080c0930>] sched_show_task+0x98/0xf8 [
> > > > >> 230.457228] [<ffffff80080c2628>] dump_cpu_task+0x40/0x50 [
> > > > >> 230.457233] [<ffffff80080e14a8>] rcu_dump_cpu_stacks+0xa0/0xf0
> > > > >> [ 230.457239] [<ffffff80080e4cd8>]
> > > > >> rcu_check_callbacks+0x468/0x748 [ 230.457243]
> > > > >> [<ffffff80080e7cfc>]
> > > > >> update_process_times+0x3c/0x68 [ 230.457249]
> > > > >> [<ffffff80080f6dfc>] tick_sched_handle.isra.5+0x3c/0x50
> > > > >> [ 230.457253] [<ffffff80080f6e54>] tick_sched_timer+0x44/0x90
> > > > >> [ 230.457257] [<ffffff80080e86b0>]
> > > > >> __hrtimer_run_queues+0xf0/0x178
> > > > >> ** 10 printk messages dropped ** [ 230.457302] f8c0:
> > > > >> 0000000000000000 0000000005f5e0ff 000000000001379a
> > > > 3866666666666620 [
> > > > >> 230.457306] f8e0: ffffff800a1b4065 0000000000000006
> > > > >> ffffff800a129000
> > > > >> ffffffc87b8010a8 [ 230.457310] f900: ffffff808a1b4057
> > > > >> ffffff800a1c3000 ffffff800a1b3000 ffffff800a13b000 [
> > > > >> 230.457314]
> > > > >> f920: 0000000000000140 0000000000000006 ffffff800a1b3b10
> > > > >> ffffff800a1c39e8 [ 230.457318] f940: 000000000000002f
> > > > >> ffffff800a1b8a98 ffffff800a1b3ae8 ffffffc87b07f990 [
> > > > >> 230.457322]
> > > > >> f960: ffffff80080d6230 ffffffc87b07f990 ffffff80080d6234
> > > > >> 0000000060000145
> > > > >> ** 1 printk messages dropped ** [ 230.457329]
> > > > >> [<ffffff8008085720>]
> > > > >> el1_irq+0xa0/0x100
> > > > >> ** 9 printk messages dropped ** [ 230.457373]
> > > > >> [<ffffff800885ad60>]
> > > > >> ieee80211_hw_config+0x50/0x290 [ 230.457377]
> > > > >> [<ffffff8008863690>]
> > > > >> ieee80211_scan_work+0x1f8/0x480 [ 230.457383]
> > > > >> [<ffffff80080b15d0>]
> > > > >> process_one_work+0x120/0x378 [ 230.457386]
> > > > >> [<ffffff80080b1870>]
> > > > >> worker_thread+0x48/0x4b0 [ 230.457391] [<ffffff80080b7108>]
> > > > >> kthread+0xd0/0xe8 [ 230.457395] [<ffffff8008085dd0>]
> > > > ret_from_fork+0x10/0x40
> > > > >> [ 230.480389] ath9k_hw_intrpend 762
> > > > >>
> > > > >>
> > > > >> [ 545.487987] ath9k: ath9k_ioread32 ffffff800a400024 [
> > > > >> 545.526189]
> > > > >> INFO: rcu_sched self-detected stall on CPU
> > > > >> [ 545.526195] 2-...: (97636 ticks this GP)
> > > > idle=3D2d1/140000000000001/0 softirq=3D1400/1400 fqs=3D115374
> > > > >> [ 545.526199] (t=3D115523 jiffies g=3D161 c=3D160 q=3D51066)
> > > > >> [ 545.526201] Task dump for CPU 2:
> > > > >> [ 545.526206] kworker/u8:4 R running task 0 1342 =
2
> > 0x00000002
> > > > >> ** 3 printk messages dropped ** [ 545.526231]
> > > > >> [<ffffff8008089a0c>]
> > > > >> show_stack+0x14/0x20
> > > > >> ** 9 printk messages dropped ** [ 545.526280]
> > > > >> [<ffffff80086a71e8>]
> > > > >> arch_timer_handler_phys+0x30/0x40 [ 545.526284]
> > > > >> [<ffffff80080dbe18>]
> > > > >> handle_percpu_devid_irq+0x78/0xa0 [ 545.526291]
> > > > >> [<ffffff80080d760c>]
> > > > >> generic_handle_irq+0x24/0x38 [ 545.526296]
> > > > >> [<ffffff80080d7944>]
> > > > >> __handle_domain_irq+0x5c/0xb8 [ 545.526299]
> > > > >> [<ffffff80080824bc>]
> > > > >> gic_handle_irq+0x64/0xc0 [ 545.526302] Exception
> > > > >> stack(0xffffffc87b07f870
> > > > to 0xffffffc87b07f990)
> > > > >> [ 545.526306] f860: 000000000=
0009732
> > ffffff800a1eaaa8
> > > > >> ** 8 printk messages dropped ** [ 545.526341] f980:
> > > > >> ffffff800a1c39e8
> > > > >> 0000000000000036 [ 545.526345] [<ffffff8008085720>]
> > > > >> el1_irq+0xa0/0x100 [ 545.526349] [<ffffff80080d6234>]
> > > > >> console_unlock+0x384/0x5b0 [ 545.526353] [<ffffff80080d673c>]
> > > > >> vprintk_emit+0x2dc/0x4b0 [ 545.526357] [<ffffff80080d6a50>]
> > > > >> vprintk_default+0x38/0x40 [ 545.526362] [<ffffff8008129704>]
> > > > >> printk+0x58/0x60 [ 545.526366] [<ffffff800859e3e4>]
> > > > >> ath9k_iowrite32+0x9c/0xa8 [ 545.526372] [<ffffff80085c7ca8>]
> > > > >> ath9k_hw_kill_interrupts+0x28/0xf0
> > > > >> [ 545.526376] [<ffffff80085a18ec>] ath_reset+0x24/0x68
> > > > >> ** 2 printk messages dropped ** [ 545.526391]
> > > > >> [<ffffff800885ad60>]
> > > > ieee80211_hw_config+0x50/0x290
> > > > >> ** 11 printk messages dropped ** [ 545.532834]
> > > > >> ath9k_hw_kill_interrupts
> > > > 793
> > > > >> [ 545.532890] ath9k_hw_enable_interrupts 821
> > > >
> > > > [ 81.876902] INFO: rcu_preempt detected stalls on CPUs/tasks:
> > > > [ 81.876912] Tasks blocked on level-0 rcu_node (CPUs 0-7): P0
> > > > [ 81.876932] (detected by 4, t=3D60002 jiffies, g=3D1873, c=
=3D1872, q=3D4967)
> > > > [ 81.876936] swapper/4 R running task 0 0 =
1
> > > > 0x00000000
> > > > [ 81.876941] 0000000000000001 ffffffff810725f6 ffff88017edbc240
> > > > ffffffff81a3dc40
> > > > [ 81.876945] ffffffff81101e46 ffff88025ef173c0 ffffffff81a3dc40
> > > > ffffffff81a3dc40
> > > > [ 81.876948] 00000000ffffffff ffffffff810a7333 ffff88017ecee698
> > > > ffff88017edbc240
> > > > [ 81.876951] Call Trace:
> > > > [ 81.876970] <IRQ>
> > > > [ 81.876979] [<ffffffff810725f6>] ? sched_show_task+0xd6/0x140
> > > > [ 81.876983] [<ffffffff81101e46>] ?
> > > > rcu_print_detail_task_stall_rnp+0x40/0x61
> > > > [ 81.876989] [<ffffffff810a7333>] ? rcu_check_callbacks+0x6b3/0x=
8c0
> > > > [ 81.876993] [<ffffffff810b8350>] ?
> tick_sched_handle.isra.14+0x40/0x40
> > > > [ 81.876996] [<ffffffff810aa4c3>] ? update_process_times+0x23/0x=
50
> > > > [ 81.876999] [<ffffffff810b8383>] ? tick_sched_timer+0x33/0x60
> > > > [ 81.877002] [<ffffffff810aaf09>] ? __hrtimer_run_queues+0xb9/0x=
150
> > > > [ 81.877004] [<ffffffff810ab198>] ? hrtimer_interrupt+0x98/0x1a0
> > > > [ 81.877008] [<ffffffff81031b1e>] ?
> > > > smp_trace_apic_timer_interrupt+0x5e/0x90
> > > > [ 81.877012] [<ffffffff815b31bf>] ? apic_timer_interrupt+0x7f/0x=
90
> > > > [ 81.877013] <EOI>
> > > > [ 81.877017] [<ffffffff8147f28d>] ? cpuidle_enter_state+0x13d/0x=
1f0
> > > > [ 81.877019] [<ffffffff8147f289>] ? cpuidle_enter_state+0x139/0x=
1f0
> > > > [ 81.877021] [<ffffffff81088c19>] ? cpu_startup_entry+0x139/0x21=
0
> > > > [ 81.877027] [<ffffffff8102fc9e>] ? start_secondary+0x13e/0x170
> > > > [ 81.877029] swapper/4 R running task 0 0 =
1
> > > > 0x00000000
> > > > [ 81.877032] 0000000000000001 ffffffff810725f6 ffff88017edbc240
> > > > ffffffff81a3dc40
> > > > [ 81.877035] ffffffff81101e46 ffff88025ef173c0 ffffffff81a3dc40
> > > > ffffffff81a3dc40
> > > > [ 81.877038] 00000000ffffffff ffffffff810a7368 ffff88017ecee698
> > > > ffff88017edbc240
> > > > [ 81.877041] Call Trace:
> > > > [ 81.877045] <IRQ>
> > > > [ 81.877049] [<ffffffff810725f6>] ? sched_show_task+0xd6/0x140
> > > > [ 81.877051] [<ffffffff81101e46>] ?
> > > > rcu_print_detail_task_stall_rnp+0x40/0x61
> > > > [ 81.877055] [<ffffffff810a7368>] ? rcu_check_callbacks+0x6e8/0x=
8c0
> > > > [ 81.877058] [<ffffffff810b8350>] ?
> tick_sched_handle.isra.14+0x40/0x40
> > > > [ 81.877060] [<ffffffff810aa4c3>] ? update_process_times+0x23/0x=
50
> > > > [ 81.877063] [<ffffffff810b8383>] ? tick_sched_timer+0x33/0x60
> > > > [ 81.877065] [<ffffffff810aaf09>] ? __hrtimer_run_queues+0xb9/0x=
150
> > > > [ 81.877068] [<ffffffff810ab198>] ? hrtimer_interrupt+0x98/0x1a0
> > > > [ 81.877070] [<ffffffff81031b1e>] ?
> > > > smp_trace_apic_timer_interrupt+0x5e/0x90
> > > > [ 81.877073] [<ffffffff815b31bf>] ? apic_timer_interrupt+0x7f/0x=
90
> > > > [ 81.877074] <EOI>
> > > > [ 81.877076] [<ffffffff8147f28d>] ? cpuidle_enter_state+0x13d/0x=
1f0
> > > > [ 81.877078] [<ffffffff8147f289>] ? cpuidle_enter_state+0x139/0x=
1f0
> > > > [ 81.877080] [<ffffffff81088c19>] ? cpu_startup_entry+0x139/0x21=
0
> > > > [ 81.877084] [<ffffffff8102fc9e>] ? start_secondary+0x13e/0x170
> > > > [ 91.132787] INFO: rcu_preempt detected expedited stalls on
> > > > CPUs/tasks: { P0 } 63785 jiffies s: 505 root: 0x0/T
> > > > [ 91.132796] blocking rcu_node structures:
> > > >
> > > > >>
> > > > >>
> > > > >> But if we have less debug prints it does not reach EP handler
> > > > >> sometimes, due to following Condition in "kernel/irq/chip.c" in
> > > > >> function handle_simple_irq
> > > > >>
> > > > >> if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data)=
)) {
> > > > >> desc->istate |=3D IRQS_PENDING;
> > > > >> goto out_unlock;
> > > > >> }
> > > > >> Here irqd_irq_disabled is being set to 1.
> > > > >>
> > > > >> With lesser debug prints it stops after following prints:
> > > > >> root@Xilinx-ZCU102-2016_3:~# iw dev wlan0 scan
> > > > >> [ 54.781045] ath9k_hw_kill_interrupts 793
> > > > >> [ 54.785007] ath9k_hw_kill_interrupts 793
> > > > >> [ 54.792535] ath9k_hw_enable_interrupts 821
> > > > >> [ 54.796642] ath9k_hw_enable_interrupts 825
> > > > >> [ 54.800807] ath9k_hw_enable_interrupts 832
> > > > >> [ 54.804973] AR_SREV_9100 0
> > > > >> [ 54.807663] ath9k_hw_enable_interrupts 848
> > > > >> [ 54.811843] ath9k_hw_intrpend 762
> > > > >> [ 54.815211] (AR_SREV_9340(ah) val 0
> > > > >> [ 54.818684] ath9k_hw_intrpend 767
> > > > >> [ 54.822078] ath_isr 603
> > > > >> [ 54.824587] ath9k_hw_kill_interrupts 793
> > > > >> [ 54.828601] ath9k_hw_enable_interrupts 821
> > > > >> [ 54.832750] ath9k_hw_enable_interrupts 825
> > > > >> [ 54.836916] ath9k_hw_enable_interrupts 832
> > > > >> [ 54.841082] AR_SREV_9100 0
> > > > >> [ 54.843772] ath9k_hw_enable_interrupts 848
> > > > >> [ 54.843775] ath9k_hw_intrpend 762
> > > > >> [ 54.851319] (AR_SREV_9340(ah) val 0
> > > > >> [ 54.854793] ath9k_hw_intrpend 767
> > > > >> [ 54.858185] ath_isr 603
> > > > >> [ 54.860696] ath9k_hw_kill_interrupts 793
> > > > >> [ 54.864776] ath9k_hw_enable_interrupts 821
> > > > >> [ 54.867061] ath9k_hw_kill_interrupts 793
> > > > >> [ 54.872870] ath9k_hw_enable_interrupts 825
> > > > >> [ 54.877036] ath9k_hw_enable_interrupts 832
> > > > >> [ 54.881202] AR_SREV_9100 0
> > > > >> [ 54.883892] ath9k_hw_enable_interrupts 848
> > > > >> [ 75.963129] INFO: rcu_sched detected stalls on CPUs/tasks:
> > > > >> [ 75.968602] 0-...: (2 GPs behind) idle=3D9d5/140000000000001=
/0
> > > > softirq=3D1103/1109 fqs=3D519
> > > > >> [ 75.976675] (detected by 2, t=3D5274 jiffies, g=3D64, c=3D63=
, q=3D11)
> > > > >> [ 75.982485] Task dump for CPU 0:
> > > > >> [ 75.985696] ksoftirqd/0 R running task 0 3 =
2 0x00000002
> > > > >> [ 75.992726] Call trace:
> > > > >> [ 75.995165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0
> > > > >> [ 76.000281] [<ffffffc87b830500>] 0xffffffc87b830500
> > > > >> [ 139.059027] INFO: rcu_sched detected stalls on CPUs/tasks:
> > > > >> [ 139.064430] 0-...: (2 GPs behind) idle=3D9d5/140000000000001=
/0
> > > > softirq=3D1103/1109 fqs=3D2097
> > > > >> [ 139.072593] (detected by 2, t=3D21049 jiffies, g=3D64, c=3D6=
3, q=3D11)
> > > > >> [ 139.078489] Task dump for CPU 0:
> > > > >> [ 139.081700] ksoftirqd/0 R running task 0 3 =
2 0x00000002
> > > > >> [ 139.088731] Call trace:
> > > > >> [ 139.091165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0 [
> > > > >> 139.096285] [<ffffffc87b830500>] 0xffffffc87b830500
> > > > >>
> > > > >>
> > > > >>>> We are not seeing any issues on 32-bit ARM platform and X86
> > > > >>>> platform.
> > > > >>> Can you collect a dmesg log (or, if the system hang means you
> > > > >>> can't collect that, a console log with "ignore_loglevel"), and =
"lspci -vv"
> > > > >>> output as root? That should have clues about whether the INTx
> > > > >>> got routed correctly. /proc/interrupts should also show
> > > > >>> whether we're receiving interrupts from the device.
> > > > >> Here is the lspci output:
> > > > >> 00:00.0 PCI bridge: Xilinx Corporation Device d022 (prog-if 00
> > > > >> [Normal
> > > > decode])
> > > > >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV-
> VGASnoop-
> > > > ParErr- Stepping- SERR- FastB2B- DisINTx-
> > > > >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast
> >TAbort-
> > > > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > > > >> Latency: 0
> > > > >> Interrupt: pin A routed to IRQ 224
> > > > >> Bus: primary=3D00, secondary=3D01, subordinate=3D0c, sec-latenc=
y=3D0
> > > > >> I/O behind bridge: 00000000-00000fff
> > > > >> Memory behind bridge: e0000000-e00fffff
> > > > >> Prefetchable memory behind bridge: 00000000fff00000-
> > > > 00000000000fffff
> > > > >> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=3Dfast
> >TAbort-
> > > > <TAbort- <MAbort- <SERR- <PERR-
> > > > >> BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
> > > > >> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> > > > >> Capabilities: [40] Power Management version 3
> > > > >> Flags: PMEClk- DSI- D1- D2- AuxCurrent=3D0mA
> > > > PME(D0+,D1+,D2+,D3hot+,D3cold-)
> > > > >> Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0
> PME-
> > > > >> Capabilities: [60] Express (v2) Root Port (Slot-), MSI 00
> > > > >> DevCap: MaxPayload 256 bytes, PhantFunc 0
> > > > >> ExtTag- RBE+
> > > > >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> > > > Unsupported-
> > > > >> RlxdOrd+ ExtTag- PhantFunc- AuxPwr-
> NoSnoop+
> > > > >> MaxPayload 128 bytes, MaxReadReq 512 bytes
> > > > >> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq-
> AuxPwr-
> > > > TransPend+
> > > > >> LnkCap: Port #0, Speed 5GT/s, Width x2, ASPM not
> supported,
> > > > Exit Latency L0s unlimited, L1 unlimited
> > > > >> ClockPM- Surprise- LLActRep- BwNot+
> ASPMOptComp+
> > > > >> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled-
> CommClk-
> > > > >> ExtSynch- ClockPM- AutWidDis- BWInt-
> AutBWInt-
> > > > >> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> > > > DLActive- BWMgmt- ABWMgmt-
> > > > >> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal-
> PMEIntEna-
> > > > CRSVisible+
> > > > >> RootCap: CRSVisible+
> > > > >> RootSta: PME ReqID 0000, PMEStatus- PMEPending-
> > > > >> DevCap2: Completion Timeout: Range B, TimeoutDis+,
> LTR-,
> > > > OBFF Not Supported ARIFwd-
> > > > >> DevCtl2: Completion Timeout: 50us to 50ms,
> TimeoutDis-, LTR-,
> > > > OBFF Disabled ARIFwd-
> > > > >> LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance-
> SpeedDis-
> > > > >> Transmit Margin: Normal Operating Range,
> > > > EnterModifiedCompliance- ComplianceSOS-
> > > > >> Compliance De-emphasis: -6dB
> > > > >> LnkSta2: Current De-emphasis Level: -3.5dB,
> > > > EqualizationComplete-, EqualizationPhase1-
> > > > >> EqualizationPhase2-, EqualizationPhase3-,
> > > > LinkEqualizationRequest-
> > > > >> Capabilities: [100 v1] Device Serial Number 00-00-00-00-00-00-
> 00-00
> > > > >> Capabilities: [10c v1] Virtual Channel
> > > > >> Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
> > > > >> Arb: Fixed- WRR32- WRR64- WRR128-
> > > > >> Ctrl: ArbSelect=3DFixed
> > > > >> Status: InProgress-
> > > > >> VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1
> RejSnoopTrans-
> > > > >> Arb: Fixed- WRR32- WRR64- WRR128-
> TWRR128-
> > > > WRR256-
> > > > >> Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
> > > > >> Status: NegoPending- InProgress-
> > > > >> Capabilities: [128 v1] Vendor Specific Information: ID=3D1234
> > > > >> Rev=3D1
> > > > >> Len=3D018 <?>
> > > > >>
> > > > >> 01:00.0 Network controller: Qualcomm Atheros AR93xx Wireless
> > > > >> Network
> > > > Adapter (rev 01)
> > > > >> Subsystem: Qualcomm Atheros Device 3112
> > > > >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV-
> VGASnoop-
> > > > ParErr- Stepping- SERR- FastB2B- DisINTx-
> > > > >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast
> >TAbort-
> > > > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > > > >> Latency: 0, Cache Line Size: 128 bytes
> > > > >> Interrupt: pin A routed to IRQ 224
> > > > >> Region 0: Memory at e0000000 (64-bit, non-prefetchable)
> [size=3D128K]
> > > > >> [virtual] Expansion ROM at e0020000 [disabled] [size=3D64K]
> > > > >> Capabilities: [40] Power Management version 3
> > > > >> Flags: PMEClk- DSI- D1+ D2- AuxCurrent=3D375mA
> > > > PME(D0+,D1+,D2-,D3hot+,D3cold-)
> > > > >> Status: D0 NoSoftRst- PME-Enable- DSel=3D0 DScale=3D0
> PME-
> > > > >> Capabilities: [50] MSI: Enable- Count=3D1/4 Maskable+ 64bit+
> > > > >> Address: 0000000000000000 Data: 0000
> > > > >> Masking: 00000000 Pending: 00000000
> > > > >> Capabilities: [70] Express (v2) Endpoint, MSI 00
> > > > >> DevCap: MaxPayload 128 bytes, PhantFunc 0,
> Latency
> > > > L0s <1us, L1 <8us
> > > > >> ExtTag- AttnBtn- AttnInd- PwrInd- RBE+
> FLReset-
> > > > SlotPowerLimit 0.000W
> > > > >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> > > > Unsupported-
> > > > >> RlxdOrd+ ExtTag- PhantFunc- AuxPwr-
> NoSnoop-
> > > > >> MaxPayload 128 bytes, MaxReadReq 512 bytes
> > > > >> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq-
> AuxPwr-
> > > > TransPend-
> > > > >> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
> Exit
> > > > Latency L0s <2us, L1 <64us
> > > > >> ClockPM- Surprise- LLActRep- BwNot-
> ASPMOptComp-
> > > > >> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled-
> CommClk-
> > > > >> ExtSynch- ClockPM- AutWidDis- BWInt-
> AutBWInt-
> > > > >> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> > > > DLActive- BWMgmt- ABWMgmt-
> > > > >> DevCap2: Completion Timeout: Not Supported,
> TimeoutDis+,
> > > > LTR-, OBFF Not Supported
> > > > >> DevCtl2: Completion Timeout: 50us to 50ms,
> TimeoutDis-, LTR-,
> > > > OBFF Disabled
> > > > >> LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
> > > > SpeedDis-
> > > > >> Transmit Margin: Normal Operating Range,
> > > > EnterModifiedCompliance- ComplianceSOS-
> > > > >> Compliance De-emphasis: -6dB
> > > > >> LnkSta2: Current De-emphasis Level: -6dB,
> > > > EqualizationComplete-, EqualizationPhase1-
> > > > >> EqualizationPhase2-, EqualizationPhase3-,
> > > > LinkEqualizationRequest-
> > > > >> Capabilities: [100 v1] Advanced Error Reporting
> > > > >> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
> UnxCmplt-
> > > > RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> > > > >> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
> UnxCmplt-
> > > > RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> > > > >> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
> UnxCmplt-
> > > > RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> > > > >> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> > > > NonFatalErr-
> > > > >> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> > > > NonFatalErr+
> > > > >> AERCap: First Error Pointer: 00, GenCap-
> CGenEn-
> > > > ChkCap- ChkEn-
> > > > >> Capabilities: [140 v1] Virtual Channel
> > > > >> Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
> > > > >> Arb: Fixed- WRR32- WRR64- WRR128-
> > > > >> Ctrl: ArbSelect=3DFixed
> > > > >> Status: InProgress-
> > > > >> VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1
> RejSnoopTrans-
> > > > >> Arb: Fixed- WRR32- WRR64- WRR128-
> TWRR128-
> > > > WRR256-
> > > > >> Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
> > > > >> Status: NegoPending- InProgress-
> > > > >> Capabilities: [300 v1] Device Serial Number 00-00-00-00-00-00-
> 00-00
> > > > >> Kernel driver in use: ath9k
> > > > >>
> > > > >> Here is the cat /proc/interrupts (after we do interface up):
> > > > >>
> > > > >> root@:~# ifconfig wlan0 up
> > > > >> [ 1548.926601] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not
> > > > >> ready root@Xilinx-ZCU102-2016_3:~# cat /proc/interrupts
> > > > >> CPU0 CPU1 CPU2 CPU3
> > > > >> 1: 0 0 0 0 GICv2 29 =
Edge arch_timer
> > > > >> 2: 19873 20058 19089 17435 GICv2 30 =
Edge
> arch_timer
> > > > >> 12: 0 0 0 0 GICv2 156 =
Level zynqmp-dma
> > > > >> 13: 0 0 0 0 GICv2 157 =
Level zynqmp-dma
> > > > >> 14: 0 0 0 0 GICv2 158 =
Level zynqmp-dma
> > > > >> 15: 0 0 0 0 GICv2 159 =
Level zynqmp-dma
> > > > >> 16: 0 0 0 0 GICv2 160 =
Level zynqmp-dma
> > > > >> 17: 0 0 0 0 GICv2 161 =
Level zynqmp-dma
> > > > >> 18: 0 0 0 0 GICv2 162 =
Level zynqmp-dma
> > > > >> 19: 0 0 0 0 GICv2 163 =
Level zynqmp-dma
> > > > >> 20: 0 0 0 0 GICv2 164 =
Level Mali_GP_MMU,
> > > > Mali_GP, Mali_PP0_MMU, Mali_PP0, Mali_PP1_MMU, Mali_PP1
> > > > >> 30: 0 0 0 0 GICv2 95 =
Level eth0, eth0
> > > > >> 206: 314 0 0 0 GICv2 49 L=
evel cdns-i2c
> > > > >> 207: 40 0 0 0 GICv2 50 L=
evel cdns-i2c
> > > > >> 209: 0 0 0 0 GICv2 150 L=
evel nwl_pcie:misc
> > > > >> 214: 12 0 0 0 GICv2 47 L=
evel ff0f0000.spi
> > > > >> 215: 0 0 0 0 GICv2 58 L=
evel ffa60000.rtc
> > > > >> 216: 0 0 0 0 GICv2 59 L=
evel ffa60000.rtc
> > > > >> 217: 0 0 0 0 GICv2 165 L=
evel ahci-
> > > > ceva[fd0c0000.ahci]
> > > > >> 218: 61 0 0 0 GICv2 81 L=
evel mmc0
> > > > >> 219: 0 0 0 0 GICv2 187 L=
evel arm-smmu global
> > fault
> > > > >> 220: 471 0 0 0 GICv2 53 L=
evel xuartps
> > > > >> 223: 0 0 0 0 GICv2 154 L=
evel fd4c0000.dma
> > > > >> 224: 3 0 0 0 dummy 1 E=
dge ath9k
> > > > >> 225: 0 0 0 0 GICv2 97 L=
evel xhci-hcd:usb1
> > > > >>
> > > > >> Regards,
> > > > >> Bharat
> > >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in t=
he 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 2/2] net: wireless: fix to uses struct
From: kbuild test robot @ 2016-12-22 7:05 UTC (permalink / raw)
To: Ozgur Karatas
Cc: kbuild-all, johannes, David Miller, linux-wireless, netdev,
linux-kernel
In-Reply-To: <608881482358981@web17g.yandex.ru>
[-- Attachment #1: Type: text/plain, Size: 2282 bytes --]
Hi Ozgur,
[auto build test ERROR on mac80211-next/master]
[also build test ERROR on v4.9 next-20161221]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ozgur-Karatas/net-wireless-fixed-to-checkpatch-errors/20161222-125128
base: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git master
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
net/wireless/reg.c: In function 'reg_query_builtin':
>> net/wireless/reg.c:493:28: error: 'reg_regdb_apply_request' undeclared (first use in this function)
request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~~~~~~
net/wireless/reg.c:493:28: note: each undeclared identifier is reported only once for each function it appears in
net/wireless/reg.c: In function 'regulatory_hint_core':
net/wireless/reg.c:2294:28: error: 'regulatory_request' undeclared (first use in this function)
request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~
net/wireless/reg.c: In function 'regulatory_hint_user':
net/wireless/reg.c:2316:28: error: 'regulatory_request' undeclared (first use in this function)
request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~
net/wireless/reg.c: In function 'regulatory_hint':
net/wireless/reg.c:2388:28: error: 'regulatory_request' undeclared (first use in this function)
request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~
vim +/reg_regdb_apply_request +493 net/wireless/reg.c
487 }
488 }
489
490 if (!regdom)
491 return -ENODATA;
492
> 493 request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
494 if (!request)
495 return -ENOMEM;
496
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 57000 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] net: wireless: fix to uses struct
From: kbuild test robot @ 2016-12-22 5:18 UTC (permalink / raw)
To: Ozgur Karatas
Cc: kbuild-all, johannes, David Miller, linux-wireless, netdev,
linux-kernel
In-Reply-To: <608881482358981@web17g.yandex.ru>
[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]
Hi Ozgur,
[auto build test ERROR on mac80211-next/master]
[also build test ERROR on v4.9 next-20161221]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ozgur-Karatas/net-wireless-fixed-to-checkpatch-errors/20161222-125128
base: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git master
config: i386-randconfig-x006-201651 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
net/wireless/reg.c: In function 'regulatory_hint_core':
>> net/wireless/reg.c:2294:28: error: 'regulatory_request' undeclared (first use in this function)
request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~
net/wireless/reg.c:2294:28: note: each undeclared identifier is reported only once for each function it appears in
net/wireless/reg.c: In function 'regulatory_hint_user':
net/wireless/reg.c:2316:28: error: 'regulatory_request' undeclared (first use in this function)
request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~
net/wireless/reg.c: In function 'regulatory_hint':
net/wireless/reg.c:2388:28: error: 'regulatory_request' undeclared (first use in this function)
request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~
vim +/regulatory_request +2294 net/wireless/reg.c
2288 * and when we restore regulatory settings.
2289 */
2290 static int regulatory_hint_core(const char *alpha2)
2291 {
2292 struct regulatory_request *request;
2293
> 2294 request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
2295 if (!request)
2296 return -ENOMEM;
2297
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 23376 bytes --]
^ permalink raw reply
* [PATCH v3 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel
From: Geoff Lansberry @ 2016-12-22 4:18 UTC (permalink / raw)
To: linux-wireless
Cc: lauro.venancio, aloisio.almeida, sameo, robh+dt, mark.rutland,
netdev, devicetree, linux-kernel, mgreer, justin, Jaret Cantu,
Geoff Lansberry
In-Reply-To: <1482380314-16440-1-git-send-email-geoff@kuvee.com>
From: Jaret Cantu <jaret.cantu@timesys.com>
Repeated polling attempts cause a NULL dereference error to occur.
This is because the state of the trf7970a is currently reading but
another request has been made to send a command before it has finished.
The solution is to properly kill the waiting reading (workqueue)
before failing on the send.
Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
---
drivers/nfc/trf7970a.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index e3c72c6..ba5f9b8 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -1496,6 +1496,10 @@ static int trf7970a_send_cmd(struct nfc_digital_dev *ddev,
(trf->state != TRF7970A_ST_IDLE_RX_BLOCKED)) {
dev_err(trf->dev, "%s - Bogus state: %d\n", __func__,
trf->state);
+ if (trf->state == TRF7970A_ST_WAIT_FOR_RX_DATA ||
+ trf->state == TRF7970A_ST_WAIT_FOR_RX_DATA_CONT)
+ trf->ignore_timeout =
+ !cancel_delayed_work(&trf->timeout_work);
ret = -EIO;
goto out_err;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage
From: Geoff Lansberry @ 2016-12-22 4:18 UTC (permalink / raw)
To: linux-wireless
Cc: lauro.venancio, aloisio.almeida, sameo, robh+dt, mark.rutland,
netdev, devicetree, linux-kernel, mgreer, justin, Geoff Lansberry
In-Reply-To: <1482380314-16440-1-git-send-email-geoff@kuvee.com>
The TRF7970A has configuration options for supporting hardware designs
with 1.8 Volt or 3.3 Volt IO. This commit adds a device tree option,
using a fixed regulator binding, for setting the io voltage to match
the hardware configuration. If no option is supplied it defaults to
3.3 volt configuration.
Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
---
.../devicetree/bindings/net/nfc/trf7970a.txt | 2 ++
drivers/nfc/trf7970a.c | 26 +++++++++++++++++++++-
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 8b01fc81..b5777d8 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -21,6 +21,7 @@ Optional SoC Specific Properties:
- t5t-rmb-extra-byte-quirk: Specify that the trf7970a has the erratum
where an extra byte is returned by Read Multiple Block commands issued
to Type 5 tags.
+- vdd-io-supply: Regulator specifying voltage for vdd-io
- clock-frequency: Set to specify that the input frequency to the trf7970a is 13560000Hz or 27120000Hz
Example (for ARM-based BeagleBone with TRF7970A on SPI1):
@@ -40,6 +41,7 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1):
<&gpio2 5 GPIO_ACTIVE_LOW>;
vin-supply = <&ldo3_reg>;
vin-voltage-override = <5000000>;
+ vdd-io-supply = <&ldo2_reg>;
autosuspend-delay = <30000>;
irq-status-read-quirk;
en2-rf-quirk;
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index b1cd4ef..e3c72c6 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -444,6 +444,7 @@ struct trf7970a {
u8 iso_ctrl_tech;
u8 modulator_sys_clk_ctrl;
u8 special_fcn_reg1;
+ u8 io_ctrl;
unsigned int guard_time;
int technology;
int framing;
@@ -1051,6 +1052,11 @@ static int trf7970a_init(struct trf7970a *trf)
if (ret)
goto err_out;
+ ret = trf7970a_write(trf, TRF7970A_REG_IO_CTRL,
+ trf->io_ctrl | TRF7970A_REG_IO_CTRL_VRS(0x1));
+ if (ret)
+ goto err_out;
+
ret = trf7970a_write(trf, TRF7970A_NFC_TARGET_LEVEL, 0);
if (ret)
goto err_out;
@@ -1767,7 +1773,7 @@ static int _trf7970a_tg_listen(struct nfc_digital_dev *ddev, u16 timeout,
goto out_err;
ret = trf7970a_write(trf, TRF7970A_REG_IO_CTRL,
- TRF7970A_REG_IO_CTRL_VRS(0x1));
+ trf->io_ctrl | TRF7970A_REG_IO_CTRL_VRS(0x1));
if (ret)
goto out_err;
@@ -2105,6 +2111,24 @@ static int trf7970a_probe(struct spi_device *spi)
if (uvolts > 4000000)
trf->chip_status_ctrl = TRF7970A_CHIP_STATUS_VRS5_3;
+ trf->regulator = devm_regulator_get(&spi->dev, "vdd-io");
+ if (IS_ERR(trf->regulator)) {
+ ret = PTR_ERR(trf->regulator);
+ dev_err(trf->dev, "Can't get VDD_IO regulator: %d\n", ret);
+ goto err_destroy_lock;
+ }
+
+ ret = regulator_enable(trf->regulator);
+ if (ret) {
+ dev_err(trf->dev, "Can't enable VDD_IO: %d\n", ret);
+ goto err_destroy_lock;
+ }
+
+ if (regulator_get_voltage(trf->regulator) == 1800000) {
+ trf->io_ctrl = TRF7970A_REG_IO_CTRL_IO_LOW;
+ dev_dbg(trf->dev, "trf7970a config vdd_io to 1.8V\n");
+ }
+
trf->ddev = nfc_digital_allocate_device(&trf7970a_nfc_ops,
TRF7970A_SUPPORTED_PROTOCOLS,
NFC_DIGITAL_DRV_CAPS_IN_CRC |
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/3] NFC: trf7970a: add device tree option for 27MHz clock
From: Geoff Lansberry @ 2016-12-22 4:18 UTC (permalink / raw)
To: linux-wireless
Cc: lauro.venancio, aloisio.almeida, sameo, robh+dt, mark.rutland,
netdev, devicetree, linux-kernel, mgreer, justin, Geoff Lansberry
The TRF7970A has configuration options to support hardware designs
which use a 27.12MHz clock. This commit adds a device tree option
'clock-frequency' to support configuring the this chip for default
13.56MHz clock or the optional 27.12MHz clock.
Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
---
.../devicetree/bindings/net/nfc/trf7970a.txt | 2 +
drivers/nfc/trf7970a.c | 50 +++++++++++++++++-----
2 files changed, 41 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 32b35a0..8b01fc81 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -21,6 +21,7 @@ Optional SoC Specific Properties:
- t5t-rmb-extra-byte-quirk: Specify that the trf7970a has the erratum
where an extra byte is returned by Read Multiple Block commands issued
to Type 5 tags.
+- clock-frequency: Set to specify that the input frequency to the trf7970a is 13560000Hz or 27120000Hz
Example (for ARM-based BeagleBone with TRF7970A on SPI1):
@@ -43,6 +44,7 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1):
irq-status-read-quirk;
en2-rf-quirk;
t5t-rmb-extra-byte-quirk;
+ clock-frequency = <27120000>;
status = "okay";
};
};
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index 26c9dbb..b1cd4ef 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -124,6 +124,9 @@
NFC_PROTO_ISO15693_MASK | NFC_PROTO_NFC_DEP_MASK)
#define TRF7970A_AUTOSUSPEND_DELAY 30000 /* 30 seconds */
+#define TRF7970A_13MHZ_CLOCK_FREQUENCY 13560000
+#define TRF7970A_27MHZ_CLOCK_FREQUENCY 27120000
+
#define TRF7970A_RX_SKB_ALLOC_SIZE 256
@@ -1056,12 +1059,11 @@ static int trf7970a_init(struct trf7970a *trf)
trf->chip_status_ctrl &= ~TRF7970A_CHIP_STATUS_RF_ON;
- ret = trf7970a_write(trf, TRF7970A_MODULATOR_SYS_CLK_CTRL, 0);
+ ret = trf7970a_write(trf, TRF7970A_MODULATOR_SYS_CLK_CTRL,
+ trf->modulator_sys_clk_ctrl);
if (ret)
goto err_out;
- trf->modulator_sys_clk_ctrl = 0;
-
ret = trf7970a_write(trf, TRF7970A_ADJUTABLE_FIFO_IRQ_LEVELS,
TRF7970A_ADJUTABLE_FIFO_IRQ_LEVELS_WLH_96 |
TRF7970A_ADJUTABLE_FIFO_IRQ_LEVELS_WLL_32);
@@ -1181,27 +1183,37 @@ static int trf7970a_in_config_rf_tech(struct trf7970a *trf, int tech)
switch (tech) {
case NFC_DIGITAL_RF_TECH_106A:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_14443A_106;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_OOK;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xf8) |
+ TRF7970A_MODULATOR_DEPTH_OOK;
trf->guard_time = TRF7970A_GUARD_TIME_NFCA;
break;
case NFC_DIGITAL_RF_TECH_106B:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_14443B_106;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xf8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
trf->guard_time = TRF7970A_GUARD_TIME_NFCB;
break;
case NFC_DIGITAL_RF_TECH_212F:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_FELICA_212;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xf8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
trf->guard_time = TRF7970A_GUARD_TIME_NFCF;
break;
case NFC_DIGITAL_RF_TECH_424F:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_FELICA_424;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xf8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
trf->guard_time = TRF7970A_GUARD_TIME_NFCF;
break;
case NFC_DIGITAL_RF_TECH_ISO15693:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_15693_SGL_1OF4_2648;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_OOK;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xf8) |
+ TRF7970A_MODULATOR_DEPTH_OOK;
trf->guard_time = TRF7970A_GUARD_TIME_15693;
break;
default:
@@ -1571,17 +1583,23 @@ static int trf7970a_tg_config_rf_tech(struct trf7970a *trf, int tech)
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_NFC_NFC_CE_MODE |
TRF7970A_ISO_CTRL_NFC_CE |
TRF7970A_ISO_CTRL_NFC_CE_14443A;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_OOK;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xf8) |
+ TRF7970A_MODULATOR_DEPTH_OOK;
break;
case NFC_DIGITAL_RF_TECH_212F:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_NFC_NFC_CE_MODE |
TRF7970A_ISO_CTRL_NFC_NFCF_212;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xf8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
break;
case NFC_DIGITAL_RF_TECH_424F:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_NFC_NFC_CE_MODE |
TRF7970A_ISO_CTRL_NFC_NFCF_424;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xf8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
break;
default:
dev_dbg(trf->dev, "Unsupported rf technology: %d\n", tech);
@@ -1987,6 +2005,7 @@ static int trf7970a_probe(struct spi_device *spi)
struct device_node *np = spi->dev.of_node;
struct trf7970a *trf;
int uvolts, autosuspend_delay, ret;
+ u32 clk_freq = TRF7970A_13MHZ_CLOCK_FREQUENCY;
if (!np) {
dev_err(&spi->dev, "No Device Tree entry\n");
@@ -2043,6 +2062,15 @@ static int trf7970a_probe(struct spi_device *spi)
return ret;
}
+ of_property_read_u32(np, "clock-frequency", &clk_freq);
+ if ((clk_freq != TRF7970A_27MHZ_CLOCK_FREQUENCY) ||
+ (clk_freq != TRF7970A_13MHZ_CLOCK_FREQUENCY)) {
+ dev_err(trf->dev,
+ "clock-frequency (%u Hz) unsupported\n",
+ clk_freq);
+ return -EINVAL;
+ }
+
if (of_property_read_bool(np, "en2-rf-quirk"))
trf->quirks |= TRF7970A_QUIRK_EN2_MUST_STAY_LOW;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/2] net: wireless: fix to uses struct
From: Ozgur Karatas @ 2016-12-21 23:01 UTC (permalink / raw)
To: Paul Bolle, johannes, David Miller
Cc: Thomas Gleixner, linux-wireless, netdev, linux-kernel
In-Reply-To: <601101482360611@web25o.yandex.ru>
My previous patch is invalid, I'm sorry.
The last patc will be fellow because "regulatory_request" is defined as a "static struct".
Signed-off-by: Ozgur Karatas <okaratas@member.fsf.org>
---
net/wireless/reg.c | 10 +++++-----
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..5b70970 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -490,7 +490,7 @@ static int reg_query_builtin(const char *alpha2)
if (!regdom)
return -ENODATA;
- request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2661,7 +2661,7 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
if (processing)
return 0;
- reg_beacon = kzalloc(sizeof(struct reg_beacon), gfp);
+ reg_beacon = kzalloc(sizeof(*reg_beacon), gfp);
if (!reg_beacon)
return -ENOMEM;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 2/2] net: wireless: fix to uses struct
From: Ozgur Karatas @ 2016-12-21 23:16 UTC (permalink / raw)
To: Paul Bolle, johannes, David Miller
Cc: Thomas Gleixner, linux-wireless, netdev, linux-kernel
In-Reply-To: <1482361572.28171.8.camel@tiscali.nl>
22.12.2016, 01:06, "Paul Bolle" <pebolle@tiscali.nl>:
> On Thu, 2016-12-22 at 01:50 +0300, Ozgur Karatas wrote:
>> I don't have a problem with C programming
>
> I'm sorry, but you do need to learn C, at a basic level, first.
Hmm, I don't like to discussion but I'm an assertive on C/C++.
So, I'm not into the Linux kernel, I writing code with C/C++ for many years.
I'm having trouble using Linux tools and trying to learn git/diff/format-patch/etc.
Also, I'm reading over 600 e-mails per day and I'm reading to Documentation (kernel). I learn :)
I don't have to problem with C, you can see my early codes and software (github).
I need to get a good sense of the coding style and Documentation.
And thank you.
Regards
> Paul Bolle
~Ozgur
^ permalink raw reply
* Re: [PATCH 2/2] net: wireless: fix to uses struct
From: Paul Bolle @ 2016-12-21 23:06 UTC (permalink / raw)
To: Ozgur Karatas, johannes, David Miller
Cc: Thomas Gleixner, linux-wireless, netdev, linux-kernel
In-Reply-To: <601101482360611@web25o.yandex.ru>
On Thu, 2016-12-22 at 01:50 +0300, Ozgur Karatas wrote:
> I don't have a problem with C programming
I'm sorry, but you do need to learn C, at a basic level, first.
Paul Bolle
^ permalink raw reply
* Re: [PATCH 2/2] net: wireless: fix to uses struct
From: Ozgur Karatas @ 2016-12-21 22:50 UTC (permalink / raw)
To: Paul Bolle, johannes, David Miller
Cc: Thomas Gleixner, linux-wireless, netdev, linux-kernel
In-Reply-To: <1482359625.28171.2.camel@tiscali.nl>
22.12.2016, 00:34, "Paul Bolle" <pebolle@tiscali.nl>:
> On Thu, 2016-12-22 at 00:23 +0200, Ozgur Karatas wrote:
>> I compiled and didn't to errors.
>
> Really?
I'm very sorry. The "regulatory_request" is defined a static struct. I missed.
line: static struct regulatory_request core_request_world = {
I send to wrong line please can ignore last message and should be fix to as follows:
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..5b70970 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -490,7 +490,7 @@ static int reg_query_builtin(const char *alpha2)
if (!regdom)
return -ENODATA;
- request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2291,7 +2291,7 @@ static int regulatory_hint_core(const char *alpha2)
{
struct regulatory_request *request;
- request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2313,7 +2313,7 @@ int regulatory_hint_user(const char *alpha2,
if (WARN_ON(!alpha2))
return -EINVAL;
- request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2385,7 +2385,7 @@ int regulatory_hint(struct wiphy *wiphy, const char *alpha2)
wiphy->regulatory_flags &= ~REGULATORY_CUSTOM_REG;
- request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2661,7 +2661,7 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
if (processing)
return 0;
- reg_beacon = kzalloc(sizeof(struct reg_beacon), gfp);
+ reg_beacon = kzalloc(sizeof(*reg_beacon), gfp);
if (!reg_beacon)
return -ENOMEM;
--
2.1.4
> $ make net/wireless/reg.o
> CHK include/config/kernel.release
> CHK include/generated/uapi/linux/version.h
> CHK include/generated/utsrelease.h
> CHK include/generated/bounds.h
> CHK include/generated/timeconst.h
> CHK include/generated/asm-offsets.h
> CALL scripts/checksyscalls.sh
> CC net/wireless/reg.o
> net/wireless/reg.c: In function ‘regulatory_hint_core’:
> net/wireless/reg.c:2294:28: error: ‘regulatory_request’ undeclared (first use in this function)
> request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
> ^~~~~~~~~~~~~~~~~~
> net/wireless/reg.c:2294:28: note: each undeclared identifier is reported only once for each function it appears in
> net/wireless/reg.c: In function ‘regulatory_hint_user’:
> net/wireless/reg.c:2316:28: error: ‘regulatory_request’ undeclared (first use in this function)
> request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
> ^~~~~~~~~~~~~~~~~~
> net/wireless/reg.c: In function ‘regulatory_hint’:
> net/wireless/reg.c:2388:28: error: ‘regulatory_request’ undeclared (first use in this function)
> request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
> ^~~~~~~~~~~~~~~~~~
> scripts/Makefile.build:293: recipe for target 'net/wireless/reg.o' failed
> make[1]: *** [net/wireless/reg.o] Error 1
> Makefile:1640: recipe for target 'net/wireless/reg.o' failed
> make: *** [net/wireless/reg.o] Error 2
$ make M=net/wireless/
CC net/wireless//core.o
CC net/wireless//sysfs.o
CC net/wireless//radiotap.o
CC net/wireless//util.o
CC net/wireless//reg.o
CC net/wireless//scan.o
CC net/wireless//nl80211.o
CC net/wireless//mlme.o
CC net/wireless//ibss.o
CC net/wireless//sme.o
CC net/wireless//chan.o
CC net/wireless//ethtool.o
CC net/wireless//mesh.o
CC net/wireless//ap.o
CC net/wireless//trace.o
CC net/wireless//ocb.o
LD net/wireless//cfg80211.o
LD net/wireless//built-in.o
Building modules, stage 2.
MODPOST 0 modules
$ make net/wireless/reg.o
scripts/kconfig/conf --silentoldconfig Kconfig
*
* Restart config...
*
*
* Memory power savings
*
> Didn't Thomas Gleixner suggest that you do a basic C course just yesterday?
I don't have a problem with C programming, So only I'm learning the kernel.
Also, this is a lie if say "I'm expert to C".
I think be re-learned every day. wrong?
> Paul Bolle
Regards,
~ Ozgur
^ permalink raw reply related
* Re: [PATCH 2/2] net: wireless: fix to uses struct
From: Paul Bolle @ 2016-12-21 22:33 UTC (permalink / raw)
To: Ozgur Karatas, johannes, David Miller
Cc: Thomas Gleixner, linux-wireless, netdev, linux-kernel
In-Reply-To: <608881482358981@web17g.yandex.ru>
On Thu, 2016-12-22 at 00:23 +0200, Ozgur Karatas wrote:
> I compiled and didn't to errors.
Really?
$ make net/wireless/reg.o
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK include/generated/bounds.h
CHK include/generated/timeconst.h
CHK include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
CC net/wireless/reg.o
net/wireless/reg.c: In function ‘regulatory_hint_core’:
net/wireless/reg.c:2294:28: error: ‘regulatory_request’ undeclared (first use in this function)
request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~
net/wireless/reg.c:2294:28: note: each undeclared identifier is reported only once for each function it appears in
net/wireless/reg.c: In function ‘regulatory_hint_user’:
net/wireless/reg.c:2316:28: error: ‘regulatory_request’ undeclared (first use in this function)
request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~
net/wireless/reg.c: In function ‘regulatory_hint’:
net/wireless/reg.c:2388:28: error: ‘regulatory_request’ undeclared (first use in this function)
request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~
scripts/Makefile.build:293: recipe for target 'net/wireless/reg.o' failed
make[1]: *** [net/wireless/reg.o] Error 1
Makefile:1640: recipe for target 'net/wireless/reg.o' failed
make: *** [net/wireless/reg.o] Error 2
Didn't Thomas Gleixner suggest that you do a basic C course just yesterday?
Paul Bolle
^ permalink raw reply
* [PATCH 2/2] net: wireless: fix to uses struct
From: Ozgur Karatas @ 2016-12-21 22:23 UTC (permalink / raw)
To: johannes, David Miller; +Cc: linux-wireless, netdev, linux-kernel
The patch fixed to struct uses in reg.c, I think doesn't need to be use to "struct".
There is dataype not have to logical link and each is different definitons.
I'm undecided on this patch. I compiled and didn't to errors.
Signed-off-by: Ozgur Karatas <okaratas@member.fsf.org>
---
net/wireless/reg.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..5b70970 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -490,7 +490,7 @@ static int reg_query_builtin(const char *alpha2)
if (!regdom)
return -ENODATA;
- request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2291,7 +2291,7 @@ static int regulatory_hint_core(const char *alpha2)
{
struct regulatory_request *request;
- request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2313,7 +2313,7 @@ int regulatory_hint_user(const char *alpha2,
if (WARN_ON(!alpha2))
return -EINVAL;
- request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2385,7 +2385,7 @@ int regulatory_hint(struct wiphy *wiphy, const char *alpha2)
wiphy->regulatory_flags &= ~REGULATORY_CUSTOM_REG;
- request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2661,7 +2661,7 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
if (processing)
return 0;
- reg_beacon = kzalloc(sizeof(struct reg_beacon), gfp);
+ reg_beacon = kzalloc(sizeof(*reg_beacon), gfp);
if (!reg_beacon)
return -ENOMEM;
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2] net: wireless: fixed to checkpatch errors
From: Ozgur Karatas @ 2016-12-21 22:13 UTC (permalink / raw)
To: johannes, David Miller; +Cc: linux-wireless, netdev, linux-kernel
Fixed to checkpatch errors, Normally, comment's */ had to be finish on the next line.
The patch fix to readability and Coding Style.
Sİgned-off-by: Ozgur Karatas <okaratas@member.fsf.org>
---
net/wireless/chan.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 5497d022..8c7ac7f 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -891,7 +891,8 @@ cfg80211_get_chan_state(struct wireless_dev *wdev,
: CHAN_MODE_EXCLUSIVE;
/* consider worst-case - IBSS can try to return to the
- * original user-specified channel as creator */
+ * original user-specified channel as creator
+ */
if (wdev->ibss_dfs_possible)
*radar_detect |= BIT(wdev->chandef.width);
return;
--
2.1.4
^ 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