* Re: [PATCH v2] mac80211: remove warning message
From: Johannes Berg @ 2019-05-14 9:12 UTC (permalink / raw)
To: Yibo Zhao; +Cc: linux-wireless, ath10k, Zhi Chen
In-Reply-To: <ccb48284f0d96e72f4c041e12c943f0a@codeaurora.org>
On Tue, 2019-05-14 at 17:10 +0800, Yibo Zhao wrote:
> On 2019-05-14 17:05, Johannes Berg wrote:
> > On Tue, 2019-05-14 at 17:01 +0800, Yibo Zhao wrote:
> > > In multiple SSID cases, it takes time to prepare every AP interface
> > > to be ready in initializing phase. If a sta already knows everything
> > > it
> > > needs to join one of the APs and sends authentication to the AP which
> > > is not fully prepared at this point of time, AP's channel context
> > > could be NULL. As a result, warning message occurs.
> > >
> >
> > Err, what was the point in sending v2 without any changes?
> >
> > johannes
>
> Hi Johannes,
>
> I was planning to use WARN_ON_ONCE() in the first place to replace
> WARN_ON() then after some discussion, we think removing it could be
> better. So the first patch was based on my first version which is sent
> incorrectly. Please check again.
Oops, I didn't pay attention to the - code.
I guess changing it to WARN_ON_ONCE() makes sense, but as per my earlier
email I'm really not sure about removing it entirely, it doesn't seem
like a valid scenario and we should take steps elsewhere to prevent it.
johannes
^ permalink raw reply
* Re: [PATCH v2] mac80211: remove warning message
From: Yibo Zhao @ 2019-05-14 9:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, ath10k, Zhi Chen
In-Reply-To: <7c92f5cf51eaec1d5449698d90f5b6c5ca6c2bea.camel@sipsolutions.net>
On 2019-05-14 17:05, Johannes Berg wrote:
> On Tue, 2019-05-14 at 17:01 +0800, Yibo Zhao wrote:
>> In multiple SSID cases, it takes time to prepare every AP interface
>> to be ready in initializing phase. If a sta already knows everything
>> it
>> needs to join one of the APs and sends authentication to the AP which
>> is not fully prepared at this point of time, AP's channel context
>> could be NULL. As a result, warning message occurs.
>>
> Err, what was the point in sending v2 without any changes?
>
> johannes
Hi Johannes,
I was planning to use WARN_ON_ONCE() in the first place to replace
WARN_ON() then after some discussion, we think removing it could be
better. So the first patch was based on my first version which is sent
incorrectly. Please check again.
Sorry for the confusing.
--
Yibo
^ permalink raw reply
* Re: [PATCH v2] mac80211: remove warning message
From: Johannes Berg @ 2019-05-14 9:05 UTC (permalink / raw)
To: Yibo Zhao, linux-wireless; +Cc: ath10k, Zhi Chen
In-Reply-To: <1557824507-17668-1-git-send-email-yiboz@codeaurora.org>
On Tue, 2019-05-14 at 17:01 +0800, Yibo Zhao wrote:
> In multiple SSID cases, it takes time to prepare every AP interface
> to be ready in initializing phase. If a sta already knows everything it
> needs to join one of the APs and sends authentication to the AP which
> is not fully prepared at this point of time, AP's channel context
> could be NULL. As a result, warning message occurs.
>
Err, what was the point in sending v2 without any changes?
johannes
^ permalink raw reply
* [PATCH] NFC: Orphan the subsystem
From: Johannes Berg @ 2019-05-14 9:02 UTC (permalink / raw)
To: linux-wireless, netdev; +Cc: Samuel Ortiz
Samuel clearly hasn't been working on this in many years and
patches getting to the wireless list are just being ignored
entirely now. Mark the subsystem as orphan to reflect the
current state and revert back to the netdev list so at least
some fixes can be picked up by Dave.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
MAINTAINERS | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index fb9f9d71f7a2..b2659312e9ed 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11028,10 +11028,8 @@ S: Supported
F: drivers/net/ethernet/qlogic/netxen/
NFC SUBSYSTEM
-M: Samuel Ortiz <sameo@linux.intel.com>
-L: linux-wireless@vger.kernel.org
-L: linux-nfc@lists.01.org (subscribers-only)
-S: Supported
+L: netdev@vger.kernel.org
+S: Orphan
F: net/nfc/
F: include/net/nfc/
F: include/uapi/linux/nfc.h
--
2.17.2
^ permalink raw reply related
* [PATCH v2] mac80211: remove warning message
From: Yibo Zhao @ 2019-05-14 9:01 UTC (permalink / raw)
To: linux-wireless; +Cc: ath10k, Yibo Zhao, Zhi Chen
In multiple SSID cases, it takes time to prepare every AP interface
to be ready in initializing phase. If a sta already knows everything it
needs to join one of the APs and sends authentication to the AP which
is not fully prepared at this point of time, AP's channel context
could be NULL. As a result, warning message occurs.
Even worse, if the AP is under attack via tools such as MDK3 and massive
authentication requests are received in a very short time, console will
be hung due to kernel warning messages.
If this case can be hit during normal functionality, there should be no
WARN_ON(). Those should be reserved to cases that are not supposed to be
hit at all or some other more specific cases like indicating obsolete
interface.
Signed-off-by: Zhi Chen <zhichen@codeaurora.org>
Signed-off-by: Yibo Zhao <yiboz@codeaurora.org>
---
net/mac80211/ieee80211_i.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 073a823..f39c289 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1435,7 +1435,7 @@ struct ieee80211_local {
rcu_read_lock();
chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
- if (WARN_ON(!chanctx_conf)) {
+ if (!chanctx_conf) {
rcu_read_unlock();
return NULL;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] mac80211: remove warning message
From: Johannes Berg @ 2019-05-14 8:44 UTC (permalink / raw)
To: Yibo Zhao, linux-wireless; +Cc: ath10k, Zhi Chen
In-Reply-To: <1557471662-1355-1-git-send-email-yiboz@codeaurora.org>
On Fri, 2019-05-10 at 15:01 +0800, Yibo Zhao wrote:
> In multiple SSID cases, it takes time to prepare every AP interface
> to be ready in initializing phase. If a sta already knows everything it
> needs to join one of the APs and sends authentication to the AP which
> is not fully prepared at this point of time, AP's channel context
> could be NULL. As a result, warning message occurs.
Please share the dump, I don't think this should be happening. I think
this warning did what it was supposed to, uncover a bug; rather than
remove the warning we should fix the bug.
> Even worse, if the AP is under attack via tools such as MDK3 and massive
> authentication requests are received in a very short time, console will
> be hung due to kernel warning messages.
I don't buy this, it's just a WARN_ON_ONCE().
> If this case can be hit during normal functionality, there should be no
> WARN_ON(). Those should be reserved to cases that are not supposed to be
> hit at all or some other more specific cases like indicating obsolete
> interface.
I agree, but right now I'm inclined to think it's a bug elsewhere rather
than normal operation.
johannes
^ permalink raw reply
* Re: [PATCH v3] {nl,mac}80211: allow 4addr AP operation on crypto controlled devices
From: Johannes Berg @ 2019-05-14 8:38 UTC (permalink / raw)
To: Manikanta Pubbisetty; +Cc: linux-wireless
In-Reply-To: <1557307533-5795-1-git-send-email-mpubbise@codeaurora.org>
On Wed, 2019-05-08 at 14:55 +0530, Manikanta Pubbisetty wrote:
>
> +++ b/net/mac80211/util.c
> @@ -3795,7 +3795,9 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata,
> }
>
> /* Always allow software iftypes */
> - if (local->hw.wiphy->software_iftypes & BIT(iftype)) {
> + if (local->hw.wiphy->software_iftypes & BIT(iftype) ||
> + (iftype == NL80211_IFTYPE_AP_VLAN &&
> + local->hw.wiphy->flags & WIPHY_FLAG_4ADDR_AP)) {
> if (radar_detect)
> return -EINVAL;
Shouldn't this check if 4addr is actually enabled too, like here:
> case NETDEV_PRE_UP:
> - if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype)))
> + if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype)) &&
> + !(wdev->iftype == NL80211_IFTYPE_AP_VLAN &&
> + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP &&
> + wdev->use_4addr))
> return notifier_from_errno(-EOPNOTSUPP);
?
Or is there some reason it doesn't matter?
> @@ -3439,6 +3438,11 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
> return err;
> }
>
> + if (!(rdev->wiphy.interface_modes & (1 << type)) &&
> + !(type == NL80211_IFTYPE_AP_VLAN && params.use_4addr &&
> + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP))
> + return -EOPNOTSUPP;
> +
I also wonder if we shouldn't go "all in" and actually make the check
something like
check_interface_allowed(iftype, 4addr):
if (iftype == AP_VLAN && 4addr)
return wiphy.flags & WIPHY_FLAG_4ADDR_AP;
else return wiphy.interface_modes & BIT(iftype);
i.e. make it "you must have WIPHY_FLAG_4ADDR_AP to use 4-addr AP_VLAN
interfaces", rather than "also allow it in this case".
That would seem like the clearer semantics to me?
johannes
^ permalink raw reply
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Sedat Dilek @ 2019-05-14 8:34 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Clément Perrochaud, Charles Gorand, linux-nfc, Samuel Ortiz,
linux-wireless, Oleg Zhurakivskyy
In-Reply-To: <20190513123751.GS9224@smile.fi.intel.com>
On Mon, May 13, 2019 at 2:37 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, May 13, 2019 at 02:18:03PM +0200, Sedat Dilek wrote:
> > On Mon, May 13, 2019 at 12:44 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > >
> > > It has been reported that some laptops, equipped with NXP NFC300, have
> > > different ID then mentioned in the driver.
> > >
> > > While at it, I found that the driver has a lot of duplication and redundant
> > > platform data. The rest of the series (11 out of 12 patches) is dedicated to
> > > clean the driver up.
> > >
> > > Sedat, would be nice if you can compile kernel with this patch series applied
> > > and test on your laptop.
> > >
> > > In v2:
> > > - added new ID patch
> > > - added new clean up patch
> > > - Cc'ed to linux-wireless@ as well, since linux-nfc@ bounces my mails
> > > - Cc'ed to the reported of the problem with T470 laptop
> > >
> > > Andy Shevchenko (12):
> > > NFC: nxp-nci: Add NXP1001 to the ACPI ID table
> > > NFC: nxp-nci: Get rid of platform data
> > > NFC: nxp-nci: Convert to use GPIO descriptor
> > > NFC: nxp-nci: Add GPIO ACPI mapping table
> > > NFC: nxp-nci: Get rid of code duplication in ->probe()
> > > NFC: nxp-nci: Get rid of useless label
> > > NFC: nxp-nci: Constify acpi_device_id
> > > NFC: nxp-nci: Drop of_match_ptr() use
> > > NFC: nxp-nci: Drop comma in terminator lines
> > > NFC: nxp-nci: Remove unused macro pr_fmt()
> > > NFC: nxp-nci: Remove 'default n' for tests
> > > NFC: nxp-nci: Convert to SPDX license tags
> > >
> > > MAINTAINERS | 1 -
> > > drivers/nfc/nxp-nci/Kconfig | 1 -
> > > drivers/nfc/nxp-nci/core.c | 15 +--
> > > drivers/nfc/nxp-nci/firmware.c | 13 +--
> > > drivers/nfc/nxp-nci/i2c.c | 147 ++++++--------------------
> > > drivers/nfc/nxp-nci/nxp-nci.h | 1 -
> > > include/linux/platform_data/nxp-nci.h | 27 -----
> > > 7 files changed, 37 insertions(+), 168 deletions(-)
> > > delete mode 100644 include/linux/platform_data/nxp-nci.h
> >
> > Can we have NPC300 listed in the Kconfg help text?
>
> Sure, it's good thing to do!
>
> Either as a separate patch or I may incorporate in the next iteration.
> Samuel, what do you prefer?
>
Am I correct that "NPC100" is "PN547" and "NPC300" is "PN548"?
- Sedat -
^ permalink raw reply
* Re: [PATCH] mac80211: fix possible deadlock in TX path
From: Johannes Berg @ 2019-05-14 8:33 UTC (permalink / raw)
To: Erik Stromdahl, davem, linux-wireless, linux-kernel
Cc: Toke Høiland-Jørgensen
In-Reply-To: <20190427204155.14211-1-erik.stromdahl@gmail.com>
On Sat, 2019-04-27 at 22:41 +0200, Erik Stromdahl wrote:
> This patch fixes a possible deadlock when updating the TX statistics
> (when calling into ieee80211_tx_stats()) from ieee80211_tx_dequeue().
>
> ieee80211_tx_dequeue() might be called from process context.
I think this really is the problem.
> [<c0cb1864>] (ieee80211_xmit_fast_finish) from [<c0cb4504>] (ieee80211_tx_dequeue+0x30c/0xb9c)
> r10:d2f1a900 r9:d2d607a4 r8:d2cf20dc r7:d330b29c r6:d2cf2000 r5:d2c342ba
> r4:d2899d3c
> [<c0cb41f8>] (ieee80211_tx_dequeue) from [<bf057f64>] (ath10k_mac_tx_push_txq+0x78/0x2a4 [ath10k_core])
> r10:d2d607cc r9:d2fe06a0 r8:00000000 r7:d2fe1e30 r6:d2fe1d38 r5:d2fe1540
> r4:d2cf20dc
> [<bf057eec>] (ath10k_mac_tx_push_txq [ath10k_core]) from [<bf058364>] (ath10k_mac_tx_push_pending+0x1d4/0x2e0 [ath10k_core])
> r10:d2cf20dc r9:bf0582b4 r8:bf0b1dba r7:00000002 r6:c1429994 r5:00000000
> r4:d2fe06a0
> [<bf058190>] (ath10k_mac_tx_push_pending [ath10k_core]) from [<bf0e25a4>] (ath10k_sdio_irq_handler+0x30c/0x4d8 [ath10k_sdio])
> r10:00005b5a r9:d2fcc040 r8:00180201 r7:d2fe6540 r6:d2fe6a7c r5:00000000
> r4:d2fe1540
It seems to be entirely ath10k's fault, and quite possibly our
documentation, but we probably should have local_bh_disable() there
rather than try to do u64_stats_update_begin_irqsave() in some path that
really doesn't need it.
This is going to be whack-a-mole otherwise - the TX path in mac80211
really expects to not be interrupted by softirqs.
johannes
^ permalink raw reply
* Re: NXP NFC version and ACPI
From: Sedat Dilek @ 2019-05-14 8:30 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Samuel Ortiz, linux-wireless, linux-nfc, oleg.zhurakivskyy,
clement.perrochaud, charles.gorand, Andy Shevchenko
In-Reply-To: <27f2ce02-8deb-384f-af10-7737b703770a@linaro.org>
On Tue, May 14, 2019 at 10:17 AM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>
> On 14/05/2019 09:49, Sedat Dilek wrote:
> > On Tue, May 14, 2019 at 8:43 AM Daniel Lezcano
> > <daniel.lezcano@linaro.org> wrote:
> > [...]
> >
> >> The nxp-nci kernel module is loaded and neard is installed.
> >
> > You have to...
> >
> > # modprobe -v nxp-nci_i2c
> >
> > # lsmod | egrep 'nfc|nci|nxp|i2c' | sort
> > i2c_algo_bit 16384 1 i915
> > i2c_dev 24576 0
> > i2c_i801 32768 0
> > nci 77824 2 nxp_nci,nxp_nci_i2c
> > nfc 131072 16 nci,nxp_nci
> > nxp_nci 16384 1 nxp_nci_i2c
> > nxp_nci_i2c 16384 0
> > rfkill 28672 10 nfc,bluetooth,thinkpad_acpi,cfg80211
>
> I have the same modules except 'rfkill'
>
> > # modinfo nxp_nci_i2c
> > filename:
> > /lib/modules/5.1.1-1-amd64-iniza/kernel/drivers/nfc/nxp-nci/nxp-nci_i2c.ko
> > author: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
> > author: Clément Perrochaud <clement.perrochaud@nxp.com>
> > description: I2C driver for NXP NCI NFC controllers
> > license: GPL
> > alias: i2c:nxp-nci_i2c
> > alias: acpi*:NXP7471:*
> > alias: acpi*:NXP1001:*
> > alias: of:N*T*Cnxp,nxp-nci-i2cC*
> > alias: of:N*T*Cnxp,nxp-nci-i2c
> > depends: nci,nxp-nci
> > retpoline: Y
> > intree: Y
> > name: nxp_nci_i2c
> > vermagic: 5.1.1-1-amd64-iniza SMP mod_unload modversions
>
> Same result for the modinfo.
>
> -----
>
> So the first time I run:
>
> [mark]
> nfctool -d nfc0 -p
> Start polling on nfc0 as initiator
>
> With an error in syslog/dmesg:
> nci: nci_ntf_packet: unknown ntf opcode 0x0
>
>
> The second time:
>
> nfctool -p -d nfc0
> Protocol error
>
> With an error in syslog/dmesg:
> nci: nci_start_poll: failed to set local general bytes
>
> Then I do:
>
> nfctool -0 -d nfc0
>
> it returns to point [mark]
>
I cannot help with (debugging) nci.
I had all I2C and GPIO debug Kconfigs enabled to see a bit more
informations in the logs.
Maybe that helps you.
- Sedat -
^ permalink raw reply
* Re: NXP NFC version and ACPI
From: Daniel Lezcano @ 2019-05-14 8:17 UTC (permalink / raw)
To: sedat.dilek
Cc: Samuel Ortiz, linux-wireless, linux-nfc, oleg.zhurakivskyy,
clement.perrochaud, charles.gorand, Andy Shevchenko
In-Reply-To: <CA+icZUXDLQKyTH-_pPi7A2=Bu5ratwab930Fcecrdr4NtMnFcw@mail.gmail.com>
On 14/05/2019 09:49, Sedat Dilek wrote:
> On Tue, May 14, 2019 at 8:43 AM Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
> [...]
>
>> The nxp-nci kernel module is loaded and neard is installed.
>
> You have to...
>
> # modprobe -v nxp-nci_i2c
>
> # lsmod | egrep 'nfc|nci|nxp|i2c' | sort
> i2c_algo_bit 16384 1 i915
> i2c_dev 24576 0
> i2c_i801 32768 0
> nci 77824 2 nxp_nci,nxp_nci_i2c
> nfc 131072 16 nci,nxp_nci
> nxp_nci 16384 1 nxp_nci_i2c
> nxp_nci_i2c 16384 0
> rfkill 28672 10 nfc,bluetooth,thinkpad_acpi,cfg80211
I have the same modules except 'rfkill'
> # modinfo nxp_nci_i2c
> filename:
> /lib/modules/5.1.1-1-amd64-iniza/kernel/drivers/nfc/nxp-nci/nxp-nci_i2c.ko
> author: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
> author: Clément Perrochaud <clement.perrochaud@nxp.com>
> description: I2C driver for NXP NCI NFC controllers
> license: GPL
> alias: i2c:nxp-nci_i2c
> alias: acpi*:NXP7471:*
> alias: acpi*:NXP1001:*
> alias: of:N*T*Cnxp,nxp-nci-i2cC*
> alias: of:N*T*Cnxp,nxp-nci-i2c
> depends: nci,nxp-nci
> retpoline: Y
> intree: Y
> name: nxp_nci_i2c
> vermagic: 5.1.1-1-amd64-iniza SMP mod_unload modversions
Same result for the modinfo.
-----
So the first time I run:
[mark]
nfctool -d nfc0 -p
Start polling on nfc0 as initiator
With an error in syslog/dmesg:
nci: nci_ntf_packet: unknown ntf opcode 0x0
The second time:
nfctool -p -d nfc0
Protocol error
With an error in syslog/dmesg:
nci: nci_start_poll: failed to set local general bytes
Then I do:
nfctool -0 -d nfc0
it returns to point [mark]
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: ath10k 5Ghz RSSI low
From: Sam Samy @ 2019-05-14 7:54 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <CAPGJ1o8NUXw2G8hxHkHHwVhqqOGN8atHeaWFZjm-Vhw6ZM8bBw@mail.gmail.com>
hi Ben:
Looks like ./sys/kernel/debug/ieee80211/phy2/ath10k/cal_data is junk
for both the 5Ghz radios even though the
pre-cal-pci-0000:01:00.0.bin/pre-cal-ahb-a800000.wifi.bin is correct.
The 2Ghz cal_data seem to be correct and match the pre-cal-ahb-a000000.wifi.bin.
Openwrt seem to do the right thing in setting the countrycode.
I am clueless. Any pointers would help.
Thanks
On Mon, May 13, 2019 at 1:14 PM Sam Samy <to.swami1@gmail.com> wrote:
>
> >I think you should write to the openwrt mailing list and/or its bug tracker
> >and see if they can help.
>
> Ok. Thanks Ben. will do. Just curious. I am not able to get the reg.
> domain codes in TPC by googling. Do you know where I can get those?
> What is the reg. domains 0x20 and 0x58 value points to?
>
> Thanks
>
> On Mon, May 13, 2019 at 11:17 AM Ben Greear <greearb@candelatech.com> wrote:
> >
> > On 5/13/19 11:10 AM, Sam Samy wrote:
> > > hi Ben,
> > >
> > > I also looked at the TPC on the stock firmware on the AP. There is a
> > > difference.
> >
> > I think you should write to the openwrt mailing list and/or its bug tracker
> > and see if they can help.
> >
> > Thanks,
> > Ben
> >
> > >
> > > Here is the snippet from stock firmware:
> > >
> > > TPC Config for channel 5765 mode 10
> > > **************************************************
> > > CTL = 0x10 Reg. Domain = 20
> > > Antenna Gain = 0 Reg. Max Antenna Gain = 12
> > > Power Limit = 63 Reg. Max Power = 60
> > > Num tx chains = 2 Num Supported Rates = 109
> > > **************************************************
> > > **************** CDD POWER TABLE ****************
> > > **************************************************
> > >
> > > Where as in openwrt it is:
> > >
> > > *************************************
> > > TPC config for channel 5765 mode 10
> > > *************************************
> > > CTL = 0x10 Reg. Domain = 58
> > > Antenna Gain = 0 Reg. Max Antenna Gain = 0
> > > Power Limit = 60 Reg. Max Power = 30
> > > Num tx chains = 2 Num supported rates = 109
> > > ********************************
> > >
> > >
> > > So looks like reg ,domain is different even though both are US.
> > > (Although I didnt set anything on stock firmware. The countrycode from
> > > iwpriv get_countrycode says its 841.)
> > >
> > > Also, the antenna gain seems different between stock and openwrt firmware..
> > >
> > >
> > > How to change the reg. domain like in stock firmware in openwrt
> > > although I set to US in the uci.
> > >
> > > root@OpenWrt:/sys# uci show | grep country
> > > uhttpd.defaults.country='ZZ'
> > > wireless.radio0.country='US'
> > > wireless.radio1.country='US'
> > > wireless.radio2.country='US'
> > > root@OpenWrt:/sys#
> > >
> > > Thanks
> > >
> > >
> > > On Mon, May 13, 2019 at 10:36 AM Sam Samy <to.swami1@gmail.com> wrote:
> > >>
> > >>> Probably it is a board-file and/or calibration data issue then.
> > >>>
> > >>> The debugfs 'ath10k/tpc_stats' file may show very low values?
> > >>
> > >> I am not sure if the values are right. Here is one of the 5Ghz radio stats:
> > >>
> > >> root@OpenWrt:/sys# cat ./kernel/debug/ieee80211/phy0/ath10k/tpc_stats
> > >>
> > >> *************************************
> > >> TPC config for channel 5320 mode 10
> > >> *************************************
> > >> CTL = 0x10 Reg. Domain = 58
> > >> Antenna Gain = 0 Reg. Max Antenna Gain = 0
> > >> Power Limit = 46 Reg. Max Power = 46
> > >> Num tx chains = 2 Num supported rates = 129
> > >> ********************************
> > >> ******************* CDD POWER TABLE ****************
> > >> ********************************
> > >> No. Preamble Rate_code tpc_value0 tpc_value1 tpc_value2 tpc_value3
> > >> 0 CCK 0x40 0 0
> > >> 1 CCK 0x41 0 0
> > >> 2 CCK 0x42 0 0
> > >> 3 CCK 0x43 0 0
> > >> 4 OFDM 0x 0 36 34
> > >> 5 OFDM 0x 1 38 34
> > >> 6 OFDM 0x 2 38 34
> > >> 7 OFDM 0x 3 38 34
> > >> 8 OFDM 0x 4 34 34
> > >> 9 OFDM 0x 5 38 34
> > >> 10 OFDM 0x 6 38 34
> > >> 11 OFDM 0x 7 38 34
> > >> 12 HT20 0x80 38 34
> > >> 13 HT20 0x81 38 34
> > >> 14 HT20 0x82 38 34
> > >> 15 HT20 0x83 38 34
> > >> 16 HT20 0x84 38 34
> > >> 17 HT20 0x85 36 34
> > >> 18 HT20 0x86 34 34
> > >> 19 HT20 0x87 32 32
> > >> 20 HT20 0x90 38 38
> > >> 21 HT20 0x91 38 38
> > >> 22 HT20 0x92 38 38
> > >> 23 HT20 0x93 38 38
> > >> 24 HT20 0x94 38 38
> > >> 25 HT20 0x95 36 36
> > >> 26 HT20 0x96 34 34
> > >> 27 HT20 0x97 32 32
> > >> 28 HT40 0x80 37 34
> > >> 29 HT40 0x81 37 34
> > >> 30 HT40 0x82 37 34
> > >> 31 HT40 0x83 37 34
> > >> 32 HT40 0x84 37 34
> > >> 33 HT40 0x85 35 34
> > >> 34 HT40 0x86 33 33
> > >> 35 HT40 0x87 31 31
> > >> 36 HT40 0x90 37 37
> > >> 37 HT40 0x91 37 37
> > >> 38 HT40 0x92 37 37
> > >> 39 HT40 0x93 37 37
> > >> 40 HT40 0x94 37 37
> > >> 41 HT40 0x95 35 35
> > >> 42 HT40 0x96 33 33
> > >> 43 HT40 0x97 31 31
> > >> 44 VHT20 0xc0 38 34
> > >> 45 VHT20 0xc1 38 34
> > >> 46 VHT20 0xc2 38 34
> > >> 47 VHT20 0xc3 38 34
> > >> 48 VHT20 0xc4 38 34
> > >> 49 VHT20 0xc5 36 34
> > >> 50 VHT20 0xc6 34 34
> > >> 51 VHT20 0xc7 32 32
> > >> 52 VHT20 0xc8 31 31
> > >> 53 VHT20 0xc9 30 30
> > >> 54 VHT20 0xd0 38 38
> > >> 55 VHT20 0xd1 38 38
> > >> 56 VHT20 0xd2 38 38
> > >> 57 VHT20 0xd3 38 38
> > >> 58 VHT20 0xd4 38 38
> > >> 59 VHT20 0xd5 36 36
> > >> 60 VHT20 0xd6 34 34
> > >> 61 VHT20 0xd7 32 32
> > >> 62 VHT20 0xd8 31 31
> > >> 63 VHT20 0xd9 30 30
> > >> 64 VHT40 0xc0 37 34
> > >> 65 VHT40 0xc1 37 34
> > >> 66 VHT40 0xc2 37 34
> > >> 67 VHT40 0xc3 37 34
> > >> 68 VHT40 0xc4 37 34
> > >> 69 VHT40 0xc5 35 34
> > >> 70 VHT40 0xc6 33 33
> > >> 71 VHT40 0xc7 31 31
> > >> 72 VHT40 0xc8 30 30
> > >> 73 VHT40 0xc9 29 29
> > >> 74 VHT40 0xd0 37 37
> > >> 75 VHT40 0xd1 37 37
> > >> 76 VHT40 0xd2 37 37
> > >> 77 VHT40 0xd3 37 37
> > >> 78 VHT40 0xd4 37 37
> > >> 79 VHT40 0xd5 35 35
> > >> 80 VHT40 0xd6 33 33
> > >> 81 VHT40 0xd7 31 31
> > >> 82 VHT40 0xd8 30 30
> > >> 83 VHT40 0xd9 29 29
> > >> 84 VHT80 0xc0 36 34
> > >> 85 VHT80 0xc1 36 34
> > >> 86 VHT80 0xc2 36 34
> > >> 87 VHT80 0xc3 36 34
> > >> 88 VHT80 0xc4 36 34
> > >> 89 VHT80 0xc5 34 34
> > >> 90 VHT80 0xc6 32 32
> > >> 91 VHT80 0xc7 30 30
> > >> 92 VHT80 0xc8 29 29
> > >> 93 VHT80 0xc9 28 28
> > >> 94 VHT80 0xd0 36 36
> > >> 95 VHT80 0xd1 36 36
> > >> 96 VHT80 0xd2 36 36
> > >> 97 VHT80 0xd3 36 36
> > >> 98 VHT80 0xd4 36 36
> > >> 99 VHT80 0xd5 34 34
> > >> 100 VHT80 0xd6 32 32
> > >> 101 VHT80 0xd7 30 30
> > >> 102 VHT80 0xd8 29 29
> > >> 103 VHT80 0xd9 28 28
> > >> 104 HTCUP 0x40 36 36
> > >> 105 HTCUP 0x 0 36 34
> > >> 106 HTCUP 0x40 36 36
> > >> 107 HTCUP 0x 0 36 34
> > >> 108 HTCUP 0x 0 36 34
> > >> 109 HTCUP 0x7a 34 34
> > >> 110 HTCUP 0x8a 32 32
> > >> 111 HTCUP 0x a 30 30
> > >> 112 HTCUP 0xee 27 27
> > >> 113 HTCUP 0xa6 26 26
> > >> 114 HTCUP 0x90 36 36
> > >> 115 HTCUP 0x1d 36 36
> > >> 116 HTCUP 0x80 36 34
> > >> 117 HTCUP 0x41 36 36
> > >> 118 HTCUP 0xd9 36 36
> > >> 119 HTCUP 0x64 34 34
> > >> 120 HTCUP 0xf9 32 32
> > >> 121 HTCUP 0x 0 30 30
> > >> 122 HTCUP 0x 0 27 27
> > >> 123 HTCUP 0x 0 26 26
> > >> 124 HTCUP 0x64 0 0
> > >> 125 HTCUP 0x 0 37 34
> > >> 126 HTCUP 0x31 0 0
> > >> 127 HTCUP 0x 4 37 34
> > >> 128 HTCUP 0x 0 38 34
> > >> ***********************************
> > >> ********************************
> > >> ******************* STBC POWER TABLE ****************
> > >> ********************************
> > >> No. Preamble Rate_code tpc_value0 tpc_value1 tpc_value2 tpc_value3
> > >> 0 CCK 0x40 0 0
> > >> 1 CCK 0x41 0 0
> > >> 2 CCK 0x42 0 0
> > >> 3 CCK 0x43 0 0
> > >> 4 OFDM 0x 0 36 36
> > >> 5 OFDM 0x 1 38 38
> > >> 6 OFDM 0x 2 38 38
> > >> 7 OFDM 0x 3 38 38
> > >> 8 OFDM 0x 4 34 34
> > >> 9 OFDM 0x 5 38 38
> > >> 10 OFDM 0x 6 38 38
> > >> 11 OFDM 0x 7 38 38
> > >> 12 HT20 0x80 38 38
> > >> 13 HT20 0x81 38 38
> > >> 14 HT20 0x82 38 38
> > >> 15 HT20 0x83 38 38
> > >> 16 HT20 0x84 38 38
> > >> 17 HT20 0x85 36 36
> > >> 18 HT20 0x86 34 34
> > >> 19 HT20 0x87 32 32
> > >> 20 HT20 0x90 38 38
> > >> 21 HT20 0x91 38 38
> > >> 22 HT20 0x92 38 38
> > >> 23 HT20 0x93 38 38
> > >> 24 HT20 0x94 38 38
> > >> 25 HT20 0x95 36 36
> > >> 26 HT20 0x96 34 34
> > >> 27 HT20 0x97 32 32
> > >> 28 HT40 0x80 37 37
> > >> 29 HT40 0x81 37 37
> > >> 30 HT40 0x82 37 37
> > >> 31 HT40 0x83 37 37
> > >> 32 HT40 0x84 37 37
> > >> 33 HT40 0x85 35 35
> > >> 34 HT40 0x86 33 33
> > >> 35 HT40 0x87 31 31
> > >> 36 HT40 0x90 37 37
> > >> 37 HT40 0x91 37 37
> > >> 38 HT40 0x92 37 37
> > >> 39 HT40 0x93 37 37
> > >> 40 HT40 0x94 37 37
> > >> 41 HT40 0x95 35 35
> > >> 42 HT40 0x96 33 33
> > >> 43 HT40 0x97 31 31
> > >> 44 VHT20 0xc0 38 38
> > >> 45 VHT20 0xc1 38 38
> > >> 46 VHT20 0xc2 38 38
> > >> 47 VHT20 0xc3 38 38
> > >> 48 VHT20 0xc4 38 38
> > >> 49 VHT20 0xc5 36 36
> > >> 50 VHT20 0xc6 34 34
> > >> 51 VHT20 0xc7 32 32
> > >> 52 VHT20 0xc8 31 31
> > >> 53 VHT20 0xc9 30 30
> > >> 54 VHT20 0xd0 38 38
> > >> 55 VHT20 0xd1 38 38
> > >> 56 VHT20 0xd2 38 38
> > >> 57 VHT20 0xd3 38 38
> > >> 58 VHT20 0xd4 38 38
> > >> 59 VHT20 0xd5 36 36
> > >> 60 VHT20 0xd6 34 34
> > >> 61 VHT20 0xd7 32 32
> > >> 62 VHT20 0xd8 31 31
> > >> 63 VHT20 0xd9 30 30
> > >> 64 VHT40 0xc0 37 37
> > >> 65 VHT40 0xc1 37 37
> > >> 66 VHT40 0xc2 37 37
> > >> 67 VHT40 0xc3 37 37
> > >> 68 VHT40 0xc4 37 37
> > >> 69 VHT40 0xc5 35 35
> > >> 70 VHT40 0xc6 33 33
> > >> 71 VHT40 0xc7 31 31
> > >> 72 VHT40 0xc8 30 30
> > >> 73 VHT40 0xc9 29 29
> > >> 74 VHT40 0xd0 37 37
> > >> 75 VHT40 0xd1 37 37
> > >> 76 VHT40 0xd2 37 37
> > >> 77 VHT40 0xd3 37 37
> > >> 78 VHT40 0xd4 37 37
> > >> 79 VHT40 0xd5 35 35
> > >> 80 VHT40 0xd6 33 33
> > >> 81 VHT40 0xd7 31 31
> > >> 82 VHT40 0xd8 30 30
> > >> 83 VHT40 0xd9 29 29
> > >> 84 VHT80 0xc0 36 36
> > >> 85 VHT80 0xc1 36 36
> > >> 86 VHT80 0xc2 36 36
> > >> 87 VHT80 0xc3 36 36
> > >> 88 VHT80 0xc4 36 36
> > >> 89 VHT80 0xc5 34 34
> > >> 90 VHT80 0xc6 32 32
> > >> 91 VHT80 0xc7 30 30
> > >> 92 VHT80 0xc8 29 29
> > >> 93 VHT80 0xc9 28 28
> > >> 94 VHT80 0xd0 36 36
> > >> 95 VHT80 0xd1 36 36
> > >> 96 VHT80 0xd2 36 36
> > >> 97 VHT80 0xd3 36 36
> > >> 98 VHT80 0xd4 36 36
> > >> 99 VHT80 0xd5 34 34
> > >> 100 VHT80 0xd6 32 32
> > >> 101 VHT80 0xd7 30 30
> > >> 102 VHT80 0xd8 29 29
> > >> 103 VHT80 0xd9 28 28
> > >> 104 HTCUP 0x40 36 36
> > >> 105 HTCUP 0x 0 36 36
> > >> 106 HTCUP 0x40 36 36
> > >> 107 HTCUP 0x 0 36 36
> > >> 108 HTCUP 0x 0 36 36
> > >> 109 HTCUP 0x7a 34 34
> > >> 110 HTCUP 0x8a 32 32
> > >> 111 HTCUP 0x a 30 30
> > >> 112 HTCUP 0xee 27 27
> > >> 113 HTCUP 0xa6 26 26
> > >> 114 HTCUP 0x90 36 36
> > >> 115 HTCUP 0x1d 36 36
> > >> 116 HTCUP 0x80 36 36
> > >> 117 HTCUP 0x41 36 36
> > >> 118 HTCUP 0xd9 36 36
> > >> 119 HTCUP 0x64 34 34
> > >> 120 HTCUP 0xf9 32 32
> > >> 121 HTCUP 0x 0 30 30
> > >> 122 HTCUP 0x 0 27 27
> > >> 123 HTCUP 0x 0 26 26
> > >> 124 HTCUP 0x64 0 0
> > >> 125 HTCUP 0x 0 37 37
> > >> 126 HTCUP 0x31 0 0
> > >> 127 HTCUP 0x 4 37 37
> > >> 128 HTCUP 0x 0 38 38
> > >> ***********************************
> > >> TXBF not supported
> > >> ***************************
> > >> root@OpenWrt:/sys#
> > >>
> > >>
> > >> Thanks
> > >>
> > >> On Mon, May 13, 2019 at 10:27 AM Ben Greear <greearb@candelatech.com> wrote:
> > >>>
> > >>> On 5/13/19 10:26 AM, Sam Samy wrote:
> > >>>> hi Ben,
> > >>>>
> > >>>>> Hello, what firmware are you using (ath10k-ct, or QCA?) If using -ct firmware,
> > >>>>> please try QCA firmware and let me know if that fixes the problem.
> > >>>>>
> > >>>> I tried both. Both have the same problem. I tried various versions
> > >>>> of the both(-ct and QCA) firmware as well. All have the same problem.
> > >>>
> > >>> Probably it is a board-file and/or calibration data issue then.
> > >>>
> > >>> The debugfs 'ath10k/tpc_stats' file may show very low values?
> > >>>
> > >>> Thanks,
> > >>> Ben
> > >>>
> > >>>>
> > >>>> Thanks
> > >>>>
> > >>>> On Mon, May 13, 2019 at 10:00 AM Ben Greear <greearb@candelatech.com> wrote:
> > >>>>>
> > >>>>> On 5/13/19 9:56 AM, Sam Samy wrote:
> > >>>>>> Hi,
> > >>>>>> I installed master branch openwrt onto Asus MAP-AC2200 AP. It has tri
> > >>>>>> band. Its based on IPQ4019 DK04 QCA reference platform. 2 radios
> > >>>>>> (2Ghz/5Ghz) on AHB bus and one 5GHZ on PCIe bus. Its generally working
> > >>>>>> fine except one problem in 5Ghz. On both the 5Ghz radios the RSSI is
> > >>>>>> pretty low on any channel I put it in. In one feet range I see -60dB
> > >>>>>> RSSI, where as the stock firmware that came with the AP gives an RSSI
> > >>>>>> of -36dB at one foot distance.The downstream transmit rates are MCS8/9
> > >>>>>> for most part. The 2Ghz is working fine. Its using the cal data from
> > >>>>>> the flash that came with the AP.
> > >>>>>>
> > >>>>>> Can you please suggest anyway to debug this or improve the RSSI?
> > >>>>>>
> > >>>>>> Thanks you!
> > >>>>>>
> > >>>>>
> > >>>>> Hello, what firmware are you using (ath10k-ct, or QCA?) If using -ct firmware,
> > >>>>> please try QCA firmware and let me know if that fixes the problem.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Ben
> > >>>>>
> > >>>>> --
> > >>>>> Ben Greear <greearb@candelatech.com>
> > >>>>> Candela Technologies Inc http://www.candelatech.com
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>> --
> > >>> Ben Greear <greearb@candelatech.com>
> > >>> Candela Technologies Inc http://www.candelatech.com
> > >>>
> > >
> >
> >
> > --
> > Ben Greear <greearb@candelatech.com>
> > Candela Technologies Inc http://www.candelatech.com
> >
^ permalink raw reply
* Re: NXP NFC version and ACPI
From: Sedat Dilek @ 2019-05-14 7:49 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Samuel Ortiz, linux-wireless, linux-nfc, robert.dolca,
oleg.zhurakivskyy, clement.perrochaud, charles.gorand,
Andy Shevchenko
In-Reply-To: <5ae87449-83a1-ecce-c72c-b4742c507497@linaro.org>
On Tue, May 14, 2019 at 8:43 AM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
[...]
> The nxp-nci kernel module is loaded and neard is installed.
You have to...
# modprobe -v nxp-nci_i2c
# lsmod | egrep 'nfc|nci|nxp|i2c' | sort
i2c_algo_bit 16384 1 i915
i2c_dev 24576 0
i2c_i801 32768 0
nci 77824 2 nxp_nci,nxp_nci_i2c
nfc 131072 16 nci,nxp_nci
nxp_nci 16384 1 nxp_nci_i2c
nxp_nci_i2c 16384 0
rfkill 28672 10 nfc,bluetooth,thinkpad_acpi,cfg80211
# modinfo nxp_nci_i2c
filename:
/lib/modules/5.1.1-1-amd64-iniza/kernel/drivers/nfc/nxp-nci/nxp-nci_i2c.ko
author: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
author: Clément Perrochaud <clement.perrochaud@nxp.com>
description: I2C driver for NXP NCI NFC controllers
license: GPL
alias: i2c:nxp-nci_i2c
alias: acpi*:NXP7471:*
alias: acpi*:NXP1001:*
alias: of:N*T*Cnxp,nxp-nci-i2cC*
alias: of:N*T*Cnxp,nxp-nci-i2c
depends: nci,nxp-nci
retpoline: Y
intree: Y
name: nxp_nci_i2c
vermagic: 5.1.1-1-amd64-iniza SMP mod_unload modversions
- Sedat -
^ permalink raw reply
* Re: NXP NFC version and ACPI
From: Sedat Dilek @ 2019-05-14 7:12 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Samuel Ortiz, linux-wireless, linux-nfc, oleg.zhurakivskyy,
clement.perrochaud, charles.gorand, Andy Shevchenko
In-Reply-To: <ecfdf017-59b0-dcb8-f684-1e4ba3d82a28@linaro.org>
On Tue, May 14, 2019 at 8:57 AM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>
> On 14/05/2019 08:52, Sedat Dilek wrote:
>
> [ ... ]
>
> >>> Please give this a try and report.
> >>
> >> My laptop is the first one I have with a NFC reader, so I'm not used to
> >> test this as it was not working yet.
> >>
> >> I booted the machine with a 5.1.1, the series applied on top, and the
> >> config options set as mentioned above.
> >>
> >> The nxp-nci kernel module is loaded and neard is installed.
> >>
> >> I used the sniffing tool with the command libnfc -d nfc0 -n but when
> >> passing my NFC devices on the laptop's NFC mark, nothing happens.
> >>
> >> Is that correct?
> >>
> >
> > Hi Daniel,
> >
> > I am new to the topic Linux NFC.
> >
> > I have installed neard (daemon) v0.16 and neard-tools from Debian/buster AMD64.
> >
> > root@iniza:~# systemctl is-active neard.service
> > active
>
> Same for me
>
> > root@iniza:~# nfctool --list
> > nfc0:
> > Tags: [ ]
> > Devices: [ ]
> > Protocols: [ Felica MIFARE Jewel ISO-DEP NFC-DEP ]
> > Powered: No
> > RF Mode: None
> > lto: 150
> > rw: 15
> > miux: 2047
>
> I have:
>
> nfc0:
> Tags: [ ]
> Devices: [ ]
> Protocols: [ Felica MIFARE Jewel ISO-DEP NFC-DEP ]
> Powered: Yes
> RF Mode: None
> lto: 150
> rw: 15
> miux: 2047
>
> The powered field is different.
>
> > root@iniza:~# nfctool --poll -d nfc0
>
> > Start polling on nfc0 as initiator
> >
>
> I have:
>
> Protocol error
>
>
> And the dmesg show me the errors related to nci:
>
> [ 343.056021] nci: nci_ntf_packet: unknown ntf opcode 0x0
> ...
> [31611.394308] nci: nci_start_poll: failed to set local general bytes
>
>
I cannot say much to this.
For the sake of completeness:
I have the patch "NFC: fix attrs checks in netlink interface" applied.
- Sedat -
[1] https://patchwork.kernel.org/patch/10339089/
^ permalink raw reply
* Re: NXP NFC version and ACPI
From: Daniel Lezcano @ 2019-05-14 6:57 UTC (permalink / raw)
To: sedat.dilek
Cc: Samuel Ortiz, linux-wireless, linux-nfc, robert.dolca,
oleg.zhurakivskyy, clement.perrochaud, charles.gorand,
Andy Shevchenko
In-Reply-To: <CA+icZUWLBjTtcFS0Fo8M5gSb90GbEUpetUgwr3fy=NxGAVqCyw@mail.gmail.com>
On 14/05/2019 08:52, Sedat Dilek wrote:
[ ... ]
>>> Please give this a try and report.
>>
>> My laptop is the first one I have with a NFC reader, so I'm not used to
>> test this as it was not working yet.
>>
>> I booted the machine with a 5.1.1, the series applied on top, and the
>> config options set as mentioned above.
>>
>> The nxp-nci kernel module is loaded and neard is installed.
>>
>> I used the sniffing tool with the command libnfc -d nfc0 -n but when
>> passing my NFC devices on the laptop's NFC mark, nothing happens.
>>
>> Is that correct?
>>
>
> Hi Daniel,
>
> I am new to the topic Linux NFC.
>
> I have installed neard (daemon) v0.16 and neard-tools from Debian/buster AMD64.
>
> root@iniza:~# systemctl is-active neard.service
> active
Same for me
> root@iniza:~# nfctool --list
> nfc0:
> Tags: [ ]
> Devices: [ ]
> Protocols: [ Felica MIFARE Jewel ISO-DEP NFC-DEP ]
> Powered: No
> RF Mode: None
> lto: 150
> rw: 15
> miux: 2047
I have:
nfc0:
Tags: [ ]
Devices: [ ]
Protocols: [ Felica MIFARE Jewel ISO-DEP NFC-DEP ]
Powered: Yes
RF Mode: None
lto: 150
rw: 15
miux: 2047
The powered field is different.
> root@iniza:~# nfctool --poll -d nfc0
> Start polling on nfc0 as initiator
>
I have:
Protocol error
And the dmesg show me the errors related to nci:
[ 343.056021] nci: nci_ntf_packet: unknown ntf opcode 0x0
...
[31611.394308] nci: nci_start_poll: failed to set local general bytes
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: NXP NFC version and ACPI
From: Sedat Dilek @ 2019-05-14 6:56 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Samuel Ortiz, linux-wireless, linux-nfc, oleg.zhurakivskyy,
clement.perrochaud, charles.gorand, Andy Shevchenko
In-Reply-To: <CA+icZUWLBjTtcFS0Fo8M5gSb90GbEUpetUgwr3fy=NxGAVqCyw@mail.gmail.com>
On Tue, May 14, 2019 at 8:52 AM Sedat Dilek <sedat.dilek@gmail.com> wrote:
>
> On Tue, May 14, 2019 at 8:43 AM Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
> >
> > On 13/05/2019 22:15, Sedat Dilek wrote:
> > > On Wed, Dec 5, 2018 at 8:38 AM Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
> > >>
> > >>
> > >> Hi,
> > >>
> > >> the discussion reference is on github [1].
> > >>
> > >> I acquired a Lenovo x280 with a NFC chip. It is unclear what chip is it
> > >> really, it is called NXP NPC300 which could be a PN7xxx chip range.
> > >>
> > >> A hacked version of an old deprecated out-of-tree module made the PN5xxx
> > >> to work with my laptop but I suspect it brought some subtle instability
> > >> on my system.
> > >>
> > >> Now it would be nice to have this correctly supported upstream.
> > >>
> > >> I dumped the ACPI DSDT table and got the id NXP1001. This one is not
> > >> listed in the match table of the nxp-nci driver.
> > >>
> > >> - is the driver missing for the so called NXP NPC300 ?
> > >> - should the NXP1001 matching string to be added to nxp-nci?
> > >> - is my firmware sending me garbage ?
> > >>
> > >> Thanks in advance for any input
> > >>
> > >
> > > [ CC Andy ]
> > >
> > > Hi Daniel,
> > >
> > > I was able to get a NXP NPC300 NFC device run on Lenovo ThinkPad T470.
> > >
> > > Look at the patchset "[PATCH v2 00/12] NFC: nxp-nci: clean up and
> > > support new ID".
> > > I have tested on top of Linux v5.1.1.
> >
> > Hi Sedat,
> >
> > yes, I have them see. Thanks for letting me know.
> >
> > > Here I have set...
> > >
> > > scripts/config -m NFC_NCI -m NFC_NXP_NCI -m NFC_NXP_NCI_I2C -e
> > > PINCTRL_SUNRISEPOINT
> > >
> > > Please give this a try and report.
> >
> > My laptop is the first one I have with a NFC reader, so I'm not used to
> > test this as it was not working yet.
> >
> > I booted the machine with a 5.1.1, the series applied on top, and the
> > config options set as mentioned above.
> >
> > The nxp-nci kernel module is loaded and neard is installed.
> >
> > I used the sniffing tool with the command libnfc -d nfc0 -n but when
> > passing my NFC devices on the laptop's NFC mark, nothing happens.
> >
> > Is that correct?
> >
>
> Hi Daniel,
>
> I am new to the topic Linux NFC.
>
> I have installed neard (daemon) v0.16 and neard-tools from Debian/buster AMD64.
>
> root@iniza:~# systemctl is-active neard.service
> active
>
> root@iniza:~# nfctool --list
> nfc0:
> Tags: [ ]
> Devices: [ ]
> Protocols: [ Felica MIFARE Jewel ISO-DEP NFC-DEP ]
> Powered: No
> RF Mode: None
> lto: 150
> rw: 15
> miux: 2047
>
> root@iniza:~# nfctool --poll -d nfc0
> Start polling on nfc0 as initiator
>
> ...
>
> Throwing my YubiKey Neo-5 NFC on my ThinkPad T470 NFC sticker shows me...
>
> Targets found for nfc0
> Tags: [ tag0 ]
> Devices: [ ]
>
> Hope that helps.
>
[ UN-CC Robert (Email is no more valid) ]
Re-invoking after YubiKey touched...
root@iniza:~# nfctool --list
nfc0:
Tags: [ tag0 ]
Devices: [ ]
Protocols: [ Felica MIFARE Jewel ISO-DEP NFC-DEP ]
Powered: Yes
RF Mode: Initiator
lto: 150
rw: 15
miux: 204
...now shows "Powered: Yes".
- Sedat -
^ permalink raw reply
* Re: NXP NFC version and ACPI
From: Sedat Dilek @ 2019-05-14 6:52 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Samuel Ortiz, linux-wireless, linux-nfc, robert.dolca,
oleg.zhurakivskyy, clement.perrochaud, charles.gorand,
Andy Shevchenko
In-Reply-To: <5ae87449-83a1-ecce-c72c-b4742c507497@linaro.org>
On Tue, May 14, 2019 at 8:43 AM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>
> On 13/05/2019 22:15, Sedat Dilek wrote:
> > On Wed, Dec 5, 2018 at 8:38 AM Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
> >>
> >>
> >> Hi,
> >>
> >> the discussion reference is on github [1].
> >>
> >> I acquired a Lenovo x280 with a NFC chip. It is unclear what chip is it
> >> really, it is called NXP NPC300 which could be a PN7xxx chip range.
> >>
> >> A hacked version of an old deprecated out-of-tree module made the PN5xxx
> >> to work with my laptop but I suspect it brought some subtle instability
> >> on my system.
> >>
> >> Now it would be nice to have this correctly supported upstream.
> >>
> >> I dumped the ACPI DSDT table and got the id NXP1001. This one is not
> >> listed in the match table of the nxp-nci driver.
> >>
> >> - is the driver missing for the so called NXP NPC300 ?
> >> - should the NXP1001 matching string to be added to nxp-nci?
> >> - is my firmware sending me garbage ?
> >>
> >> Thanks in advance for any input
> >>
> >
> > [ CC Andy ]
> >
> > Hi Daniel,
> >
> > I was able to get a NXP NPC300 NFC device run on Lenovo ThinkPad T470.
> >
> > Look at the patchset "[PATCH v2 00/12] NFC: nxp-nci: clean up and
> > support new ID".
> > I have tested on top of Linux v5.1.1.
>
> Hi Sedat,
>
> yes, I have them see. Thanks for letting me know.
>
> > Here I have set...
> >
> > scripts/config -m NFC_NCI -m NFC_NXP_NCI -m NFC_NXP_NCI_I2C -e
> > PINCTRL_SUNRISEPOINT
> >
> > Please give this a try and report.
>
> My laptop is the first one I have with a NFC reader, so I'm not used to
> test this as it was not working yet.
>
> I booted the machine with a 5.1.1, the series applied on top, and the
> config options set as mentioned above.
>
> The nxp-nci kernel module is loaded and neard is installed.
>
> I used the sniffing tool with the command libnfc -d nfc0 -n but when
> passing my NFC devices on the laptop's NFC mark, nothing happens.
>
> Is that correct?
>
Hi Daniel,
I am new to the topic Linux NFC.
I have installed neard (daemon) v0.16 and neard-tools from Debian/buster AMD64.
root@iniza:~# systemctl is-active neard.service
active
root@iniza:~# nfctool --list
nfc0:
Tags: [ ]
Devices: [ ]
Protocols: [ Felica MIFARE Jewel ISO-DEP NFC-DEP ]
Powered: No
RF Mode: None
lto: 150
rw: 15
miux: 2047
root@iniza:~# nfctool --poll -d nfc0
Start polling on nfc0 as initiator
...
Throwing my YubiKey Neo-5 NFC on my ThinkPad T470 NFC sticker shows me...
Targets found for nfc0
Tags: [ tag0 ]
Devices: [ ]
Hope that helps.
Regards,
- Sedat -
^ permalink raw reply
* Re: NXP NFC version and ACPI
From: Daniel Lezcano @ 2019-05-14 6:42 UTC (permalink / raw)
To: sedat.dilek
Cc: Samuel Ortiz, linux-wireless, linux-nfc, robert.dolca,
oleg.zhurakivskyy, clement.perrochaud, charles.gorand,
Andy Shevchenko
In-Reply-To: <CA+icZUVz7sB6hv4fhL_rqhR_D8RePBJFXk1PaUy5tMw2z4xC_Q@mail.gmail.com>
On 13/05/2019 22:15, Sedat Dilek wrote:
> On Wed, Dec 5, 2018 at 8:38 AM Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>>
>>
>> Hi,
>>
>> the discussion reference is on github [1].
>>
>> I acquired a Lenovo x280 with a NFC chip. It is unclear what chip is it
>> really, it is called NXP NPC300 which could be a PN7xxx chip range.
>>
>> A hacked version of an old deprecated out-of-tree module made the PN5xxx
>> to work with my laptop but I suspect it brought some subtle instability
>> on my system.
>>
>> Now it would be nice to have this correctly supported upstream.
>>
>> I dumped the ACPI DSDT table and got the id NXP1001. This one is not
>> listed in the match table of the nxp-nci driver.
>>
>> - is the driver missing for the so called NXP NPC300 ?
>> - should the NXP1001 matching string to be added to nxp-nci?
>> - is my firmware sending me garbage ?
>>
>> Thanks in advance for any input
>>
>
> [ CC Andy ]
>
> Hi Daniel,
>
> I was able to get a NXP NPC300 NFC device run on Lenovo ThinkPad T470.
>
> Look at the patchset "[PATCH v2 00/12] NFC: nxp-nci: clean up and
> support new ID".
> I have tested on top of Linux v5.1.1.
Hi Sedat,
yes, I have them see. Thanks for letting me know.
> Here I have set...
>
> scripts/config -m NFC_NCI -m NFC_NXP_NCI -m NFC_NXP_NCI_I2C -e
> PINCTRL_SUNRISEPOINT
>
> Please give this a try and report.
My laptop is the first one I have with a NFC reader, so I'm not used to
test this as it was not working yet.
I booted the machine with a 5.1.1, the series applied on top, and the
config options set as mentioned above.
The nxp-nci kernel module is loaded and neard is installed.
I used the sniffing tool with the command libnfc -d nfc0 -n but when
passing my NFC devices on the laptop's NFC mark, nothing happens.
Is that correct?
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH] iwlwifi: trans: fix killer series loadded incorrect firmware
From: Luca Coelho @ 2019-05-14 5:56 UTC (permalink / raw)
To: Cyrus Lien, Johannes Berg, Emmanuel Grumbach,
Intel Linux Wireless, Kalle Valo, David S. Miller,
Shahar S Matityahu, Sara Sharon, Golan Ben Ami, Lior Cohen,
Shaul Triebitz, linux-wireless, netdev, linux-kernel
Cc: Cyrus Lien
In-Reply-To: <20190513133335.14536-1-cyrus.lien@canonical.com>
On Mon, 2019-05-13 at 21:33 +0800, Cyrus Lien wrote:
> Killer series loadded IWL_22000_HR_B_FW_PRE prefixed firmware instead
> IWL_CC_A_FW_PRE prefixed firmware.
>
> Add killer series to the check logic as iwl_ax200_cfg_cc.
>
> Signed-off-by: Cyrus Lien <cyrus.lien@canonical.com>
> ---
> drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> index 79c1dc05f948..576c2186b6bf 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> @@ -3565,7 +3565,9 @@ struct iwl_trans *iwl_trans_pcie_alloc(struct
> pci_dev *pdev,
> }
> } else if (CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
> CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR) &&
> - (trans->cfg != &iwl_ax200_cfg_cc ||
> + ((trans->cfg != &iwl_ax200_cfg_cc &&
> + trans->cfg != &killer1650x_2ax_cfg &&
> + trans->cfg != &killer1650w_2ax_cfg) ||
> trans->hw_rev == CSR_HW_REV_TYPE_QNJ_B0)) {
> u32 hw_status;
>
Thanks for your patch, Cyrus! We already have an identical patch in our
internal tree and it will reach the mainline soon.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] iwlwifi: remove some unnecessary NULL checks
From: Luca Coelho @ 2019-05-14 5:39 UTC (permalink / raw)
To: Dan Carpenter, Johannes Berg
Cc: Emmanuel Grumbach, Intel Linux Wireless, Kalle Valo,
Naftali Goldstein, Sara Sharon, Shaul Triebitz,
Mordechay Goodstein, Liad Kaufman, Gregory Greenman,
linux-wireless, kernel-janitors
In-Reply-To: <20190506125409.GC13799@mwanda>
On Mon, 2019-05-06 at 15:54 +0300, Dan Carpenter wrote:
> These pointers are an offset into the "sta" struct. They're assigned
> like this:
>
> const struct ieee80211_sta_vht_cap *vht_cap = &sta->vht_cap;
>
> They're not the first member of the struct (->supp_rates[] is first) so
> they can't be NULL.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> .../net/wireless/intel/iwlwifi/mvm/rs-fw.c | 23 +++++++++----------
> 1 file changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c b/drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c
> index 659e21b2d4e7..b6fb670d249c 100644
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c
> @@ -101,7 +101,7 @@ static u8 rs_fw_sgi_cw_support(struct ieee80211_sta *sta)
> struct ieee80211_sta_he_cap *he_cap = &sta->he_cap;
> u8 supp = 0;
>
> - if (he_cap && he_cap->has_he)
> + if (he_cap->has_he)
> return 0;
>
> if (ht_cap->cap & IEEE80211_HT_CAP_SGI_20)
> @@ -123,12 +123,12 @@ static u16 rs_fw_get_config_flags(struct iwl_mvm *mvm,
> struct ieee80211_sta_ht_cap *ht_cap = &sta->ht_cap;
> struct ieee80211_sta_vht_cap *vht_cap = &sta->vht_cap;
> struct ieee80211_sta_he_cap *he_cap = &sta->he_cap;
> - bool vht_ena = vht_cap && vht_cap->vht_supported;
> + bool vht_ena = vht_cap->vht_supported;
> u16 flags = 0;
>
> if (mvm->cfg->ht_params->stbc &&
> (num_of_ant(iwl_mvm_get_valid_tx_ant(mvm)) > 1)) {
> - if (he_cap && he_cap->has_he) {
> + if (he_cap->has_he) {
> if (he_cap->he_cap_elem.phy_cap_info[2] &
> IEEE80211_HE_PHY_CAP2_STBC_RX_UNDER_80MHZ)
> flags |= IWL_TLC_MNG_CFG_FLAGS_STBC_MSK;
> @@ -136,15 +136,14 @@ static u16 rs_fw_get_config_flags(struct iwl_mvm *mvm,
> if (he_cap->he_cap_elem.phy_cap_info[7] &
> IEEE80211_HE_PHY_CAP7_STBC_RX_ABOVE_80MHZ)
> flags |= IWL_TLC_MNG_CFG_FLAGS_HE_STBC_160MHZ_MSK;
> - } else if ((ht_cap &&
> - (ht_cap->cap & IEEE80211_HT_CAP_RX_STBC)) ||
> + } else if ((ht_cap->cap & IEEE80211_HT_CAP_RX_STBC) ||
> (vht_ena &&
> (vht_cap->cap & IEEE80211_VHT_CAP_RXSTBC_MASK)))
> flags |= IWL_TLC_MNG_CFG_FLAGS_STBC_MSK;
> }
>
> if (mvm->cfg->ht_params->ldpc &&
> - ((ht_cap && (ht_cap->cap & IEEE80211_HT_CAP_LDPC_CODING)) ||
> + ((ht_cap->cap & IEEE80211_HT_CAP_LDPC_CODING) ||
> (vht_ena && (vht_cap->cap & IEEE80211_VHT_CAP_RXLDPC))))
> flags |= IWL_TLC_MNG_CFG_FLAGS_LDPC_MSK;
>
> @@ -154,7 +153,7 @@ static u16 rs_fw_get_config_flags(struct iwl_mvm *mvm,
> IEEE80211_HE_PHY_CAP1_LDPC_CODING_IN_PAYLOAD))
> flags &= ~IWL_TLC_MNG_CFG_FLAGS_LDPC_MSK;
>
> - if (he_cap && he_cap->has_he &&
> + if (he_cap->has_he &&
> (he_cap->he_cap_elem.phy_cap_info[3] &
> IEEE80211_HE_PHY_CAP3_DCM_MAX_CONST_RX_MASK))
> flags |= IWL_TLC_MNG_CFG_FLAGS_HE_DCM_NSS_1_MSK;
> @@ -293,13 +292,13 @@ static void rs_fw_set_supp_rates(struct ieee80211_sta *sta,
> cmd->mode = IWL_TLC_MNG_MODE_NON_HT;
>
> /* HT/VHT rates */
> - if (he_cap && he_cap->has_he) {
> + if (he_cap->has_he) {
> cmd->mode = IWL_TLC_MNG_MODE_HE;
> rs_fw_he_set_enabled_rates(sta, sband, cmd);
> - } else if (vht_cap && vht_cap->vht_supported) {
> + } else if (vht_cap->vht_supported) {
> cmd->mode = IWL_TLC_MNG_MODE_VHT;
> rs_fw_vht_set_enabled_rates(sta, vht_cap, cmd);
> - } else if (ht_cap && ht_cap->ht_supported) {
> + } else if (ht_cap->ht_supported) {
> cmd->mode = IWL_TLC_MNG_MODE_HT;
> cmd->ht_rates[0][0] = cpu_to_le16(ht_cap->mcs.rx_mask[0]);
> cmd->ht_rates[1][0] = cpu_to_le16(ht_cap->mcs.rx_mask[1]);
> @@ -381,7 +380,7 @@ static u16 rs_fw_get_max_amsdu_len(struct ieee80211_sta *sta)
> const struct ieee80211_sta_vht_cap *vht_cap = &sta->vht_cap;
> const struct ieee80211_sta_ht_cap *ht_cap = &sta->ht_cap;
>
> - if (vht_cap && vht_cap->vht_supported) {
> + if (vht_cap->vht_supported) {
> switch (vht_cap->cap & IEEE80211_VHT_CAP_MAX_MPDU_MASK) {
> case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454:
> return IEEE80211_MAX_MPDU_LEN_VHT_11454;
> @@ -391,7 +390,7 @@ static u16 rs_fw_get_max_amsdu_len(struct ieee80211_sta *sta)
> return IEEE80211_MAX_MPDU_LEN_VHT_3895;
> }
>
> - } else if (ht_cap && ht_cap->ht_supported) {
> + } else if (ht_cap->ht_supported) {
> if (ht_cap->cap & IEEE80211_HT_CAP_MAX_AMSDU)
> /*
> * agg is offloaded so we need to assume that agg
Thanks! Applied to our internal tree and it will reach the mainline
following our normal upstreaming process.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] net: wireless: iwlwifi: Fix double-free problems in iwl_req_fw_callback()
From: Luca Coelho @ 2019-05-14 5:33 UTC (permalink / raw)
To: Jia-Ju Bai, johannes.berg, emmanuel.grumbach, linuxwifi, kvalo,
davem
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20190504093305.19360-1-baijiaju1990@gmail.com>
On Sat, 2019-05-04 at 17:33 +0800, Jia-Ju Bai wrote:
> In the error handling code of iwl_req_fw_callback(),
> iwl_dealloc_ucode()
> is called to free data. In iwl_drv_stop(), iwl_dealloc_ucode() is
> called
> again, which can cause double-free problems.
>
> To fix this bug, the call to iwl_dealloc_ucode() in
> iwl_req_fw_callback() is deleted.
>
> This bug is found by a runtime fuzzing tool named FIZZER written by
> us.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
> ---
> drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> index 689a65b11cc3..4fd1737d768b 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> @@ -1579,7 +1579,6 @@ static void iwl_req_fw_callback(const struct
> firmware *ucode_raw, void *context)
> goto free;
>
> out_free_fw:
> - iwl_dealloc_ucode(drv);
> release_firmware(ucode_raw);
> out_unbind:
> complete(&drv->request_firmware_complete);
Thanks! Applied to our internal tree and will reach the mainline
following our normal upstreaming process.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH][next] iwlwifi: d3: Use struct_size() helper
From: Luciano Coelho @ 2019-05-14 5:16 UTC (permalink / raw)
To: Gustavo A. R. Silva, Johannes Berg, Emmanuel Grumbach,
Intel Linux Wireless, Kalle Valo, David S. Miller
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20190403160342.GA24396@embeddedor>
On Wed, 2019-04-03 at 11:03 -0500, Gustavo A. R. Silva wrote:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes, in particular in the
> context in which this code is being used.
>
> So, change the following form:
>
> sizeof(*pattern_cmd) +
> wowlan->n_patterns * sizeof(struct
> iwlagn_wowlan_pattern)
>
> to :
>
> struct_size(pattern_cmd, patterns, wowlan->n_patterns)
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
> b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
> index 83fd7f93d9f5..99589b910bce 100644
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
> @@ -398,8 +398,7 @@ static int iwl_mvm_send_patterns(struct iwl_mvm
> *mvm,
> if (!wowlan->n_patterns)
> return 0;
>
> - cmd.len[0] = sizeof(*pattern_cmd) +
> - wowlan->n_patterns * sizeof(struct iwl_wowlan_pattern);
> + cmd.len[0] = struct_size(pattern_cmd, patterns, wowlan-
> >n_patterns);
>
> pattern_cmd = kmalloc(cmd.len[0], GFP_KERNEL);
> if (!pattern_cmd)
Thanks! Applied to our internal tree and it will reach the mainline
following our normal upstreaming process.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH][next] iwlwifi: lib: Use struct_size() helper
From: Luciano Coelho @ 2019-05-14 5:16 UTC (permalink / raw)
To: Gustavo A. R. Silva, Johannes Berg, Emmanuel Grumbach,
Intel Linux Wireless, Kalle Valo, David S. Miller
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20190403155901.GA22686@embeddedor>
On Wed, 2019-04-03 at 10:59 -0500, Gustavo A. R. Silva wrote:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes, in particular in the
> context in which this code is being used.
>
> So, change the following form:
>
> sizeof(*pattern_cmd) +
> wowlan->n_patterns * sizeof(struct
> iwlagn_wowlan_pattern)
>
> to :
>
> struct_size(pattern_cmd, patterns, wowlan->n_patterns)
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> drivers/net/wireless/intel/iwlwifi/dvm/lib.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/lib.c
> b/drivers/net/wireless/intel/iwlwifi/dvm/lib.c
> index b2f172d4f78a..cae9cd438697 100644
> --- a/drivers/net/wireless/intel/iwlwifi/dvm/lib.c
> +++ b/drivers/net/wireless/intel/iwlwifi/dvm/lib.c
> @@ -1022,8 +1022,7 @@ int iwlagn_send_patterns(struct iwl_priv *priv,
> if (!wowlan->n_patterns)
> return 0;
>
> - cmd.len[0] = sizeof(*pattern_cmd) +
> - wowlan->n_patterns * sizeof(struct
> iwlagn_wowlan_pattern);
> + cmd.len[0] = struct_size(pattern_cmd, patterns, wowlan-
> >n_patterns);
>
> pattern_cmd = kmalloc(cmd.len[0], GFP_KERNEL);
> if (!pattern_cmd)
Thanks! Applied to our internal tree and it will reach the mainline
following our normal upstreaming process.
--
Cheers,
Luca.
^ permalink raw reply
* Re: NXP NFC version and ACPI
From: Sedat Dilek @ 2019-05-13 20:15 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Samuel Ortiz, linux-wireless, linux-nfc, robert.dolca,
oleg.zhurakivskyy, clement.perrochaud, charles.gorand,
Andy Shevchenko
In-Reply-To: <c2d0d19f-d814-8f41-4860-77b9cc7f9d26@linaro.org>
On Wed, Dec 5, 2018 at 8:38 AM Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>
>
> Hi,
>
> the discussion reference is on github [1].
>
> I acquired a Lenovo x280 with a NFC chip. It is unclear what chip is it
> really, it is called NXP NPC300 which could be a PN7xxx chip range.
>
> A hacked version of an old deprecated out-of-tree module made the PN5xxx
> to work with my laptop but I suspect it brought some subtle instability
> on my system.
>
> Now it would be nice to have this correctly supported upstream.
>
> I dumped the ACPI DSDT table and got the id NXP1001. This one is not
> listed in the match table of the nxp-nci driver.
>
> - is the driver missing for the so called NXP NPC300 ?
> - should the NXP1001 matching string to be added to nxp-nci?
> - is my firmware sending me garbage ?
>
> Thanks in advance for any input
>
[ CC Andy ]
Hi Daniel,
I was able to get a NXP NPC300 NFC device run on Lenovo ThinkPad T470.
Look at the patchset "[PATCH v2 00/12] NFC: nxp-nci: clean up and
support new ID".
I have tested on top of Linux v5.1.1.
Here I have set...
scripts/config -m NFC_NCI -m NFC_NXP_NCI -m NFC_NXP_NCI_I2C -e
PINCTRL_SUNRISEPOINT
Please give this a try and report.
For details see the below references.
Thanks.
Regards,
- Sedat -
[1] https://patchwork.kernel.org/project/linux-wireless/list/?submitter=33142
[2] https://marc.info/?t=155740978400003&r=1&w=2
[3] https://marc.info/?t=155774435600001&r=1&w=2
^ permalink raw reply
* Re: ath10k 5Ghz RSSI low
From: Sam Samy @ 2019-05-13 20:14 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <3ed8dd0c-47e0-16a0-082d-c60f1dabdce7@candelatech.com>
>I think you should write to the openwrt mailing list and/or its bug tracker
>and see if they can help.
Ok. Thanks Ben. will do. Just curious. I am not able to get the reg.
domain codes in TPC by googling. Do you know where I can get those?
What is the reg. domains 0x20 and 0x58 value points to?
Thanks
On Mon, May 13, 2019 at 11:17 AM Ben Greear <greearb@candelatech.com> wrote:
>
> On 5/13/19 11:10 AM, Sam Samy wrote:
> > hi Ben,
> >
> > I also looked at the TPC on the stock firmware on the AP. There is a
> > difference.
>
> I think you should write to the openwrt mailing list and/or its bug tracker
> and see if they can help.
>
> Thanks,
> Ben
>
> >
> > Here is the snippet from stock firmware:
> >
> > TPC Config for channel 5765 mode 10
> > **************************************************
> > CTL = 0x10 Reg. Domain = 20
> > Antenna Gain = 0 Reg. Max Antenna Gain = 12
> > Power Limit = 63 Reg. Max Power = 60
> > Num tx chains = 2 Num Supported Rates = 109
> > **************************************************
> > **************** CDD POWER TABLE ****************
> > **************************************************
> >
> > Where as in openwrt it is:
> >
> > *************************************
> > TPC config for channel 5765 mode 10
> > *************************************
> > CTL = 0x10 Reg. Domain = 58
> > Antenna Gain = 0 Reg. Max Antenna Gain = 0
> > Power Limit = 60 Reg. Max Power = 30
> > Num tx chains = 2 Num supported rates = 109
> > ********************************
> >
> >
> > So looks like reg ,domain is different even though both are US.
> > (Although I didnt set anything on stock firmware. The countrycode from
> > iwpriv get_countrycode says its 841.)
> >
> > Also, the antenna gain seems different between stock and openwrt firmware..
> >
> >
> > How to change the reg. domain like in stock firmware in openwrt
> > although I set to US in the uci.
> >
> > root@OpenWrt:/sys# uci show | grep country
> > uhttpd.defaults.country='ZZ'
> > wireless.radio0.country='US'
> > wireless.radio1.country='US'
> > wireless.radio2.country='US'
> > root@OpenWrt:/sys#
> >
> > Thanks
> >
> >
> > On Mon, May 13, 2019 at 10:36 AM Sam Samy <to.swami1@gmail.com> wrote:
> >>
> >>> Probably it is a board-file and/or calibration data issue then.
> >>>
> >>> The debugfs 'ath10k/tpc_stats' file may show very low values?
> >>
> >> I am not sure if the values are right. Here is one of the 5Ghz radio stats:
> >>
> >> root@OpenWrt:/sys# cat ./kernel/debug/ieee80211/phy0/ath10k/tpc_stats
> >>
> >> *************************************
> >> TPC config for channel 5320 mode 10
> >> *************************************
> >> CTL = 0x10 Reg. Domain = 58
> >> Antenna Gain = 0 Reg. Max Antenna Gain = 0
> >> Power Limit = 46 Reg. Max Power = 46
> >> Num tx chains = 2 Num supported rates = 129
> >> ********************************
> >> ******************* CDD POWER TABLE ****************
> >> ********************************
> >> No. Preamble Rate_code tpc_value0 tpc_value1 tpc_value2 tpc_value3
> >> 0 CCK 0x40 0 0
> >> 1 CCK 0x41 0 0
> >> 2 CCK 0x42 0 0
> >> 3 CCK 0x43 0 0
> >> 4 OFDM 0x 0 36 34
> >> 5 OFDM 0x 1 38 34
> >> 6 OFDM 0x 2 38 34
> >> 7 OFDM 0x 3 38 34
> >> 8 OFDM 0x 4 34 34
> >> 9 OFDM 0x 5 38 34
> >> 10 OFDM 0x 6 38 34
> >> 11 OFDM 0x 7 38 34
> >> 12 HT20 0x80 38 34
> >> 13 HT20 0x81 38 34
> >> 14 HT20 0x82 38 34
> >> 15 HT20 0x83 38 34
> >> 16 HT20 0x84 38 34
> >> 17 HT20 0x85 36 34
> >> 18 HT20 0x86 34 34
> >> 19 HT20 0x87 32 32
> >> 20 HT20 0x90 38 38
> >> 21 HT20 0x91 38 38
> >> 22 HT20 0x92 38 38
> >> 23 HT20 0x93 38 38
> >> 24 HT20 0x94 38 38
> >> 25 HT20 0x95 36 36
> >> 26 HT20 0x96 34 34
> >> 27 HT20 0x97 32 32
> >> 28 HT40 0x80 37 34
> >> 29 HT40 0x81 37 34
> >> 30 HT40 0x82 37 34
> >> 31 HT40 0x83 37 34
> >> 32 HT40 0x84 37 34
> >> 33 HT40 0x85 35 34
> >> 34 HT40 0x86 33 33
> >> 35 HT40 0x87 31 31
> >> 36 HT40 0x90 37 37
> >> 37 HT40 0x91 37 37
> >> 38 HT40 0x92 37 37
> >> 39 HT40 0x93 37 37
> >> 40 HT40 0x94 37 37
> >> 41 HT40 0x95 35 35
> >> 42 HT40 0x96 33 33
> >> 43 HT40 0x97 31 31
> >> 44 VHT20 0xc0 38 34
> >> 45 VHT20 0xc1 38 34
> >> 46 VHT20 0xc2 38 34
> >> 47 VHT20 0xc3 38 34
> >> 48 VHT20 0xc4 38 34
> >> 49 VHT20 0xc5 36 34
> >> 50 VHT20 0xc6 34 34
> >> 51 VHT20 0xc7 32 32
> >> 52 VHT20 0xc8 31 31
> >> 53 VHT20 0xc9 30 30
> >> 54 VHT20 0xd0 38 38
> >> 55 VHT20 0xd1 38 38
> >> 56 VHT20 0xd2 38 38
> >> 57 VHT20 0xd3 38 38
> >> 58 VHT20 0xd4 38 38
> >> 59 VHT20 0xd5 36 36
> >> 60 VHT20 0xd6 34 34
> >> 61 VHT20 0xd7 32 32
> >> 62 VHT20 0xd8 31 31
> >> 63 VHT20 0xd9 30 30
> >> 64 VHT40 0xc0 37 34
> >> 65 VHT40 0xc1 37 34
> >> 66 VHT40 0xc2 37 34
> >> 67 VHT40 0xc3 37 34
> >> 68 VHT40 0xc4 37 34
> >> 69 VHT40 0xc5 35 34
> >> 70 VHT40 0xc6 33 33
> >> 71 VHT40 0xc7 31 31
> >> 72 VHT40 0xc8 30 30
> >> 73 VHT40 0xc9 29 29
> >> 74 VHT40 0xd0 37 37
> >> 75 VHT40 0xd1 37 37
> >> 76 VHT40 0xd2 37 37
> >> 77 VHT40 0xd3 37 37
> >> 78 VHT40 0xd4 37 37
> >> 79 VHT40 0xd5 35 35
> >> 80 VHT40 0xd6 33 33
> >> 81 VHT40 0xd7 31 31
> >> 82 VHT40 0xd8 30 30
> >> 83 VHT40 0xd9 29 29
> >> 84 VHT80 0xc0 36 34
> >> 85 VHT80 0xc1 36 34
> >> 86 VHT80 0xc2 36 34
> >> 87 VHT80 0xc3 36 34
> >> 88 VHT80 0xc4 36 34
> >> 89 VHT80 0xc5 34 34
> >> 90 VHT80 0xc6 32 32
> >> 91 VHT80 0xc7 30 30
> >> 92 VHT80 0xc8 29 29
> >> 93 VHT80 0xc9 28 28
> >> 94 VHT80 0xd0 36 36
> >> 95 VHT80 0xd1 36 36
> >> 96 VHT80 0xd2 36 36
> >> 97 VHT80 0xd3 36 36
> >> 98 VHT80 0xd4 36 36
> >> 99 VHT80 0xd5 34 34
> >> 100 VHT80 0xd6 32 32
> >> 101 VHT80 0xd7 30 30
> >> 102 VHT80 0xd8 29 29
> >> 103 VHT80 0xd9 28 28
> >> 104 HTCUP 0x40 36 36
> >> 105 HTCUP 0x 0 36 34
> >> 106 HTCUP 0x40 36 36
> >> 107 HTCUP 0x 0 36 34
> >> 108 HTCUP 0x 0 36 34
> >> 109 HTCUP 0x7a 34 34
> >> 110 HTCUP 0x8a 32 32
> >> 111 HTCUP 0x a 30 30
> >> 112 HTCUP 0xee 27 27
> >> 113 HTCUP 0xa6 26 26
> >> 114 HTCUP 0x90 36 36
> >> 115 HTCUP 0x1d 36 36
> >> 116 HTCUP 0x80 36 34
> >> 117 HTCUP 0x41 36 36
> >> 118 HTCUP 0xd9 36 36
> >> 119 HTCUP 0x64 34 34
> >> 120 HTCUP 0xf9 32 32
> >> 121 HTCUP 0x 0 30 30
> >> 122 HTCUP 0x 0 27 27
> >> 123 HTCUP 0x 0 26 26
> >> 124 HTCUP 0x64 0 0
> >> 125 HTCUP 0x 0 37 34
> >> 126 HTCUP 0x31 0 0
> >> 127 HTCUP 0x 4 37 34
> >> 128 HTCUP 0x 0 38 34
> >> ***********************************
> >> ********************************
> >> ******************* STBC POWER TABLE ****************
> >> ********************************
> >> No. Preamble Rate_code tpc_value0 tpc_value1 tpc_value2 tpc_value3
> >> 0 CCK 0x40 0 0
> >> 1 CCK 0x41 0 0
> >> 2 CCK 0x42 0 0
> >> 3 CCK 0x43 0 0
> >> 4 OFDM 0x 0 36 36
> >> 5 OFDM 0x 1 38 38
> >> 6 OFDM 0x 2 38 38
> >> 7 OFDM 0x 3 38 38
> >> 8 OFDM 0x 4 34 34
> >> 9 OFDM 0x 5 38 38
> >> 10 OFDM 0x 6 38 38
> >> 11 OFDM 0x 7 38 38
> >> 12 HT20 0x80 38 38
> >> 13 HT20 0x81 38 38
> >> 14 HT20 0x82 38 38
> >> 15 HT20 0x83 38 38
> >> 16 HT20 0x84 38 38
> >> 17 HT20 0x85 36 36
> >> 18 HT20 0x86 34 34
> >> 19 HT20 0x87 32 32
> >> 20 HT20 0x90 38 38
> >> 21 HT20 0x91 38 38
> >> 22 HT20 0x92 38 38
> >> 23 HT20 0x93 38 38
> >> 24 HT20 0x94 38 38
> >> 25 HT20 0x95 36 36
> >> 26 HT20 0x96 34 34
> >> 27 HT20 0x97 32 32
> >> 28 HT40 0x80 37 37
> >> 29 HT40 0x81 37 37
> >> 30 HT40 0x82 37 37
> >> 31 HT40 0x83 37 37
> >> 32 HT40 0x84 37 37
> >> 33 HT40 0x85 35 35
> >> 34 HT40 0x86 33 33
> >> 35 HT40 0x87 31 31
> >> 36 HT40 0x90 37 37
> >> 37 HT40 0x91 37 37
> >> 38 HT40 0x92 37 37
> >> 39 HT40 0x93 37 37
> >> 40 HT40 0x94 37 37
> >> 41 HT40 0x95 35 35
> >> 42 HT40 0x96 33 33
> >> 43 HT40 0x97 31 31
> >> 44 VHT20 0xc0 38 38
> >> 45 VHT20 0xc1 38 38
> >> 46 VHT20 0xc2 38 38
> >> 47 VHT20 0xc3 38 38
> >> 48 VHT20 0xc4 38 38
> >> 49 VHT20 0xc5 36 36
> >> 50 VHT20 0xc6 34 34
> >> 51 VHT20 0xc7 32 32
> >> 52 VHT20 0xc8 31 31
> >> 53 VHT20 0xc9 30 30
> >> 54 VHT20 0xd0 38 38
> >> 55 VHT20 0xd1 38 38
> >> 56 VHT20 0xd2 38 38
> >> 57 VHT20 0xd3 38 38
> >> 58 VHT20 0xd4 38 38
> >> 59 VHT20 0xd5 36 36
> >> 60 VHT20 0xd6 34 34
> >> 61 VHT20 0xd7 32 32
> >> 62 VHT20 0xd8 31 31
> >> 63 VHT20 0xd9 30 30
> >> 64 VHT40 0xc0 37 37
> >> 65 VHT40 0xc1 37 37
> >> 66 VHT40 0xc2 37 37
> >> 67 VHT40 0xc3 37 37
> >> 68 VHT40 0xc4 37 37
> >> 69 VHT40 0xc5 35 35
> >> 70 VHT40 0xc6 33 33
> >> 71 VHT40 0xc7 31 31
> >> 72 VHT40 0xc8 30 30
> >> 73 VHT40 0xc9 29 29
> >> 74 VHT40 0xd0 37 37
> >> 75 VHT40 0xd1 37 37
> >> 76 VHT40 0xd2 37 37
> >> 77 VHT40 0xd3 37 37
> >> 78 VHT40 0xd4 37 37
> >> 79 VHT40 0xd5 35 35
> >> 80 VHT40 0xd6 33 33
> >> 81 VHT40 0xd7 31 31
> >> 82 VHT40 0xd8 30 30
> >> 83 VHT40 0xd9 29 29
> >> 84 VHT80 0xc0 36 36
> >> 85 VHT80 0xc1 36 36
> >> 86 VHT80 0xc2 36 36
> >> 87 VHT80 0xc3 36 36
> >> 88 VHT80 0xc4 36 36
> >> 89 VHT80 0xc5 34 34
> >> 90 VHT80 0xc6 32 32
> >> 91 VHT80 0xc7 30 30
> >> 92 VHT80 0xc8 29 29
> >> 93 VHT80 0xc9 28 28
> >> 94 VHT80 0xd0 36 36
> >> 95 VHT80 0xd1 36 36
> >> 96 VHT80 0xd2 36 36
> >> 97 VHT80 0xd3 36 36
> >> 98 VHT80 0xd4 36 36
> >> 99 VHT80 0xd5 34 34
> >> 100 VHT80 0xd6 32 32
> >> 101 VHT80 0xd7 30 30
> >> 102 VHT80 0xd8 29 29
> >> 103 VHT80 0xd9 28 28
> >> 104 HTCUP 0x40 36 36
> >> 105 HTCUP 0x 0 36 36
> >> 106 HTCUP 0x40 36 36
> >> 107 HTCUP 0x 0 36 36
> >> 108 HTCUP 0x 0 36 36
> >> 109 HTCUP 0x7a 34 34
> >> 110 HTCUP 0x8a 32 32
> >> 111 HTCUP 0x a 30 30
> >> 112 HTCUP 0xee 27 27
> >> 113 HTCUP 0xa6 26 26
> >> 114 HTCUP 0x90 36 36
> >> 115 HTCUP 0x1d 36 36
> >> 116 HTCUP 0x80 36 36
> >> 117 HTCUP 0x41 36 36
> >> 118 HTCUP 0xd9 36 36
> >> 119 HTCUP 0x64 34 34
> >> 120 HTCUP 0xf9 32 32
> >> 121 HTCUP 0x 0 30 30
> >> 122 HTCUP 0x 0 27 27
> >> 123 HTCUP 0x 0 26 26
> >> 124 HTCUP 0x64 0 0
> >> 125 HTCUP 0x 0 37 37
> >> 126 HTCUP 0x31 0 0
> >> 127 HTCUP 0x 4 37 37
> >> 128 HTCUP 0x 0 38 38
> >> ***********************************
> >> TXBF not supported
> >> ***************************
> >> root@OpenWrt:/sys#
> >>
> >>
> >> Thanks
> >>
> >> On Mon, May 13, 2019 at 10:27 AM Ben Greear <greearb@candelatech.com> wrote:
> >>>
> >>> On 5/13/19 10:26 AM, Sam Samy wrote:
> >>>> hi Ben,
> >>>>
> >>>>> Hello, what firmware are you using (ath10k-ct, or QCA?) If using -ct firmware,
> >>>>> please try QCA firmware and let me know if that fixes the problem.
> >>>>>
> >>>> I tried both. Both have the same problem. I tried various versions
> >>>> of the both(-ct and QCA) firmware as well. All have the same problem.
> >>>
> >>> Probably it is a board-file and/or calibration data issue then.
> >>>
> >>> The debugfs 'ath10k/tpc_stats' file may show very low values?
> >>>
> >>> Thanks,
> >>> Ben
> >>>
> >>>>
> >>>> Thanks
> >>>>
> >>>> On Mon, May 13, 2019 at 10:00 AM Ben Greear <greearb@candelatech.com> wrote:
> >>>>>
> >>>>> On 5/13/19 9:56 AM, Sam Samy wrote:
> >>>>>> Hi,
> >>>>>> I installed master branch openwrt onto Asus MAP-AC2200 AP. It has tri
> >>>>>> band. Its based on IPQ4019 DK04 QCA reference platform. 2 radios
> >>>>>> (2Ghz/5Ghz) on AHB bus and one 5GHZ on PCIe bus. Its generally working
> >>>>>> fine except one problem in 5Ghz. On both the 5Ghz radios the RSSI is
> >>>>>> pretty low on any channel I put it in. In one feet range I see -60dB
> >>>>>> RSSI, where as the stock firmware that came with the AP gives an RSSI
> >>>>>> of -36dB at one foot distance.The downstream transmit rates are MCS8/9
> >>>>>> for most part. The 2Ghz is working fine. Its using the cal data from
> >>>>>> the flash that came with the AP.
> >>>>>>
> >>>>>> Can you please suggest anyway to debug this or improve the RSSI?
> >>>>>>
> >>>>>> Thanks you!
> >>>>>>
> >>>>>
> >>>>> Hello, what firmware are you using (ath10k-ct, or QCA?) If using -ct firmware,
> >>>>> please try QCA firmware and let me know if that fixes the problem.
> >>>>>
> >>>>> Thanks,
> >>>>> Ben
> >>>>>
> >>>>> --
> >>>>> Ben Greear <greearb@candelatech.com>
> >>>>> Candela Technologies Inc http://www.candelatech.com
> >>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Ben Greear <greearb@candelatech.com>
> >>> Candela Technologies Inc http://www.candelatech.com
> >>>
> >
>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox