* 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
* Re: [linux-nfc] ThinkPad T470 and NXP PN5xx (PN547 or PN548)
From: Sedat Dilek @ 2019-05-13 20:02 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Oleg Zhurakivskyy, Samuel Ortiz, linux-wireless, linux-nfc
In-Reply-To: <CA+icZUUsutHt1NXLNFd17J3QK-LtFCuUUEw4qqp9urJ++dDaKA@mail.gmail.com>
On Mon, May 13, 2019 at 9:46 PM Sedat Dilek <sedat.dilek@gmail.com> wrote:
>
> On Mon, May 13, 2019 at 4:11 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Mon, May 13, 2019 at 03:32:52PM +0200, Sedat Dilek wrote:
> > > BTW, which Linux Kconfig setting are minimum?
> > >
> > > scripts/config -m NFC_NCI -m NFC_NXP_NCI -m NFC_NXP_NCI_I2C
> > >
> > > What about?
> > >
> > > scripts/config -m NFC_NCI_SPI -m NFC_NCI_UART -m I2C_GPIO -m SPI_GPIO
> > >
> > > Required?
> > > Not needed?
> >
> > I2C_GPIO and SPI_GPIO has nothing to do with all this. What indeed is needed is
> > the pin control of the actual Intel SoC (unfortunately I don't know what
> > exactly you have, so, you better to check yourself), something like
> > CONFIG_PINCTRL_SKYLAKE=y.
> >
>
> I played a bit with the Kconfigs...
>
> scripts/config -m NFC_NCI -m NFC_NXP_NCI -m NFC_NXP_NCI_I2C
>
> ...is sufficient.
>
> I don't know which CONFIG_PINCTRL_XXX is needed.
>
I looked at lspci output and I see a lot of "Intel Corporation Sunrise
Point-LP", especially...
00:15.0 Signal processing controller: Intel Corporation Sunrise
Point-LP Serial IO I2C Controller #0 (rev 21)
I have set...
CONFIG_PINCTRL_SUNRISEPOINT=y
From [1]:
config PINCTRL_SUNRISEPOINT
tristate "Intel Sunrisepoint pinctrl and GPIO driver"
depends on ACPI
select PINCTRL_INTEL
help
Sunrisepoint is the PCH of Intel Skylake. This pinctrl driver
provides an interface that allows configuring of PCH pins and
using them as GPIOs.
- Sedat -
[1] https://github.com/torvalds/linux/blob/master/drivers/pinctrl/intel/Kconfig#L109
^ permalink raw reply
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Sedat Dilek @ 2019-05-13 19:48 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Clément Perrochaud, Charles Gorand, linux-nfc, Samuel Ortiz,
linux-wireless, Oleg Zhurakivskyy
In-Reply-To: <20190513104358.59716-1-andriy.shevchenko@linux.intel.com>
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
>
> --
> 2.20.1
>
Is it possible to have an info in dmesg log when nxp-nci_i2c kernel
module is loaded?
- Sedat -
^ permalink raw reply
* Re: [linux-nfc] ThinkPad T470 and NXP PN5xx (PN547 or PN548)
From: Sedat Dilek @ 2019-05-13 19:46 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Oleg Zhurakivskyy, Samuel Ortiz, linux-wireless, linux-nfc
In-Reply-To: <20190513141128.GY9224@smile.fi.intel.com>
On Mon, May 13, 2019 at 4:11 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, May 13, 2019 at 03:32:52PM +0200, Sedat Dilek wrote:
> > BTW, which Linux Kconfig setting are minimum?
> >
> > scripts/config -m NFC_NCI -m NFC_NXP_NCI -m NFC_NXP_NCI_I2C
> >
> > What about?
> >
> > scripts/config -m NFC_NCI_SPI -m NFC_NCI_UART -m I2C_GPIO -m SPI_GPIO
> >
> > Required?
> > Not needed?
>
> I2C_GPIO and SPI_GPIO has nothing to do with all this. What indeed is needed is
> the pin control of the actual Intel SoC (unfortunately I don't know what
> exactly you have, so, you better to check yourself), something like
> CONFIG_PINCTRL_SKYLAKE=y.
>
I played a bit with the Kconfigs...
scripts/config -m NFC_NCI -m NFC_NXP_NCI -m NFC_NXP_NCI_I2C
...is sufficient.
I don't know which CONFIG_PINCTRL_XXX is needed.
- Sedat -
^ permalink raw reply
* Re: ath10k 5Ghz RSSI low
From: Ben Greear @ 2019-05-13 18:17 UTC (permalink / raw)
To: Sam Samy; +Cc: linux-wireless
In-Reply-To: <CAPGJ1o-i8Gy8baAf+MHcuWoF6oHuSiRYwyADCZDkYS8fmeOy8A@mail.gmail.com>
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: ath10k 5Ghz RSSI low
From: Sam Samy @ 2019-05-13 18:10 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <CAPGJ1o8k4WoK1cwBBYMge8m6n-Mm5nC7G=ku29iMRrSsJ1AMQw@mail.gmail.com>
hi Ben,
I also looked at the TPC on the stock firmware on the AP. There is a
difference.
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
> >
^ permalink raw reply
* Re: ath10k 5Ghz RSSI low
From: Sam Samy @ 2019-05-13 17:36 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <79695018-5ac9-d7c8-a386-c6dd3f9ed474@candelatech.com>
> 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
>
^ permalink raw reply
* Re: ath10k 5Ghz RSSI low
From: Ben Greear @ 2019-05-13 17:27 UTC (permalink / raw)
To: Sam Samy; +Cc: linux-wireless
In-Reply-To: <CAPGJ1o96QSfoFzFpSPbh_4TwSgAU-1FGhX6P5MVCmfZv_bugHw@mail.gmail.com>
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
^ permalink raw reply
* Re: ath10k 5Ghz RSSI low
From: Sam Samy @ 2019-05-13 17:26 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <a236cf47-556d-c515-0093-82dce6e8ad8e@candelatech.com>
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.
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
>
^ permalink raw reply
* Re: ath10k 5Ghz RSSI low
From: Ben Greear @ 2019-05-13 17:00 UTC (permalink / raw)
To: Sam Samy, linux-wireless
In-Reply-To: <CAPGJ1o9qDYPQF882cw65uysjCmUYi6kJCmL2EUa0AXbwHj59Mg@mail.gmail.com>
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
^ permalink raw reply
* ath10k 5Ghz RSSI low
From: Sam Samy @ 2019-05-13 16:56 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <CAPGJ1o_KskiCKQ8V-6U0nxWGgXXa4NWHV0EEwo41bMPSj1bbdg@mail.gmail.com>
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!
^ permalink raw reply
* Re: [PATCH] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Lorenzo Bianconi @ 2019-05-13 15:41 UTC (permalink / raw)
To: Kalle Valo; +Cc: nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <87sgtiil7n.fsf@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]
> Lorenzo Bianconi <lorenzo@kernel.org> writes:
>
> >> Lorenzo Bianconi <lorenzo@kernel.org> writes:
> >>
> >> > Introduce a knob in mt7603 debugfs in order to enable/disable
> >> > edcca processing
> >> >
> >> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> >>
> >> It's good to explain what edcca does and how the file is used supposed
> >> to be used. In other words, have a small introduction for the user.
> >
> > Hi Kalle,
> >
> > edcca is used for adjusting energy detect based on CCA thresholds.
> > The code was already there so I just reported the acronym.
>
> A lot of people read commit logs but not everyone (myself included) are
> familiar with mt76 internals so please try to explain the acronyms and
> the background of the patch. Also you should explain in the commit log
> _why_ you are adding the debugfs file, how it helps the user and how to
> use it.
sorry for not been so clear.
ED/CCA is used to control tx power according to the CCA MIB counters (e.g do not
transmit if the channel busy time is higher than 90% for given amount of time
in a row).
As already done in commit 643749d4a82b ("mt76: mt76x02: disable ED/CCA by default"),
this patch adds the possibility to enable/disable the processing according to an
entry in the debugfs. The reason behind this patch is ED/CCA caused
instability in the past so it could be useful to disable it.
Regards,
Lorenzo
>
> --
> Kalle Valo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] ath10k: enabling tx stats support over pktlog
From: Balaji Pothunoori @ 2019-05-13 14:53 UTC (permalink / raw)
To: ath10k, linux-wireless; +Cc: Balaji Pothunoori
For QCA988X target, pktlog gives details of the tx bitrate
which is used in the driver for station info.
Enabling pktlog by default will cause more interrupts
in target to host CE pipe, which can impact more CPU usage
for targets ex:WCN3990 and also not required for all other
platforms (eg: WCN3990), for getting tx bitrate.
Enable pktlog only for QCA988X based on hardware params.
Tested HW : WCN3990
Tested FW : WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
Fixes: e8123bb74c4e ("ath10k: add per peer tx stats support for 10.2.4")
Signed-off-by: Balaji Pothunoori <bpothuno@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/core.c | 15 +++++++++++++++
drivers/net/wireless/ath/ath10k/hw.h | 3 +++
drivers/net/wireless/ath/ath10k/mac.c | 3 ++-
3 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 61ef903..252e9af 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -83,6 +83,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
+ .tx_stats_over_pktlog = true,
},
{
.id = QCA988X_HW_2_0_VERSION,
@@ -117,6 +118,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
+ .tx_stats_over_pktlog = true,
},
{
.id = QCA9887_HW_1_0_VERSION,
@@ -152,6 +154,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
+ .tx_stats_over_pktlog = false,
},
{
.id = QCA6174_HW_3_2_VERSION,
@@ -179,6 +182,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.ast_skid_limit = 0x10,
.num_wds_entries = 0x20,
.uart_pin_workaround = true,
+ .tx_stats_over_pktlog = false,
},
{
.id = QCA6174_HW_2_1_VERSION,
@@ -213,6 +217,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
+ .tx_stats_over_pktlog = false,
},
{
.id = QCA6174_HW_2_1_VERSION,
@@ -247,6 +252,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
+ .tx_stats_over_pktlog = false,
},
{
.id = QCA6174_HW_3_0_VERSION,
@@ -281,6 +287,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
+ .tx_stats_over_pktlog = false,
},
{
.id = QCA6174_HW_3_2_VERSION,
@@ -318,6 +325,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = true,
+ .tx_stats_over_pktlog = false,
},
{
.id = QCA99X0_HW_2_0_DEV_VERSION,
@@ -358,6 +366,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
+ .tx_stats_over_pktlog = false,
},
{
.id = QCA9984_HW_1_0_DEV_VERSION,
@@ -405,6 +414,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
+ .tx_stats_over_pktlog = false,
},
{
.id = QCA9888_HW_2_0_DEV_VERSION,
@@ -449,6 +459,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
+ .tx_stats_over_pktlog = false,
},
{
.id = QCA9377_HW_1_0_DEV_VERSION,
@@ -483,6 +494,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
+ .tx_stats_over_pktlog = false,
},
{
.id = QCA9377_HW_1_1_DEV_VERSION,
@@ -519,6 +531,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = true,
+ .tx_stats_over_pktlog = false,
},
{
.id = QCA4019_HW_1_0_DEV_VERSION,
@@ -560,6 +573,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.rri_on_ddr = false,
.hw_filter_reset_required = true,
.fw_diag_ce_download = false,
+ .tx_stats_over_pktlog = false,
},
{
.id = WCN3990_HW_1_0_DEV_VERSION,
@@ -587,6 +601,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.rri_on_ddr = true,
.hw_filter_reset_required = false,
.fw_diag_ce_download = false,
+ .tx_stats_over_pktlog = false,
},
};
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 248cfb4..1e80beb 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -612,6 +612,9 @@ struct ath10k_hw_params {
* firmware bug
*/
bool uart_pin_workaround;
+
+ /* tx stats support over pktlog */
+ bool tx_stats_over_pktlog;
};
struct htt_rx_desc;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index b500fd4..40e7cea 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7877,7 +7877,8 @@ ath10k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw,
arvif->vdev_id, ret);
}
- if (ath10k_peer_stats_enabled(ar)) {
+ if (ath10k_peer_stats_enabled(ar) &&
+ ar->hw_params.tx_stats_over_pktlog) {
ar->pktlog_filter |= ATH10K_PKTLOG_PEER_STATS;
ret = ath10k_wmi_pdev_pktlog_enable(ar,
ar->pktlog_filter);
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/2] wil6210: Add EDMG channel support
From: Alexei Avshalom Lazar @ 2019-05-13 14:42 UTC (permalink / raw)
To: Johannes Berg; +Cc: Alexei Avshalom Lazar, linux-wireless, wil6210
In-Reply-To: <1557758554-18907-1-git-send-email-ailizaro@codeaurora.org>
Add support for Enhanced Directional Multi-Gigabit (EDMG) channels 9-11.
wil6210 reports it's EDMG capabilities (that are also based on FW
capability) to cfg80211 by filling
wiphy->bands[NL80211_BAND_60GHZ]->edmg_cap.
wil6210 handles edmg_channels and edmg_bw_config requested in connect
and start_ap operations.
Change-Id: I96a2776fe27ed2d8e922e23063e879361cfcb552
---
drivers/net/wireless/ath/wil6210/cfg80211.c | 205 +++++++++++++++++++++++++--
drivers/net/wireless/ath/wil6210/txrx_edma.c | 2 +
drivers/net/wireless/ath/wil6210/txrx_edma.h | 6 +
drivers/net/wireless/ath/wil6210/wil6210.h | 8 +-
drivers/net/wireless/ath/wil6210/wmi.c | 5 +-
drivers/net/wireless/ath/wil6210/wmi.h | 30 +++-
6 files changed, 242 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c b/drivers/net/wireless/ath/wil6210/cfg80211.c
index ce68fbc..161d271 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -25,6 +25,22 @@
#define WIL_MAX_ROC_DURATION_MS 5000
+#define WIL_EDMG_CHANNEL_9_SUBCHANNELS (BIT(0) | BIT(1))
+#define WIL_EDMG_CHANNEL_10_SUBCHANNELS (BIT(1) | BIT(2))
+#define WIL_EDMG_CHANNEL_11_SUBCHANNELS (BIT(2) | BIT(3))
+
+/* WIL_EDMG_BW_CONFIGURATION define the allowed channel bandwidth
+ * configurations as defined by IEEE 802.11 section 9.4.2.251, Table 13.
+ * The value 5 allowing CB1 and CB2 of adjacent channels.
+ */
+#define WIL_EDMG_BW_CONFIGURATION 5
+
+/* WIL_EDMG_CHANNELS is a bitmap that indicates the 2.16 GHz channel(s) that
+ * are allowed to be used for EDMG transmissions in the BSS as defined by
+ * IEEE 802.11 section 9.4.2.251.
+ */
+#define WIL_EDMG_CHANNELS (BIT(0) | BIT(1) | BIT(2) | BIT(3))
+
bool disable_ap_sme;
module_param(disable_ap_sme, bool, 0444);
MODULE_PARM_DESC(disable_ap_sme, " let user space handle AP mode SME");
@@ -51,6 +67,39 @@
CHAN60G(4, 0),
};
+/* Rx channel bonding mode */
+enum wil_rx_cb_mode {
+ WIL_RX_CB_MODE_DMG,
+ WIL_RX_CB_MODE_EDMG,
+ WIL_RX_CB_MODE_WIDE,
+};
+
+static int wil_rx_cb_mode_to_n_bonded(u8 cb_mode)
+{
+ switch (cb_mode) {
+ case WIL_RX_CB_MODE_DMG:
+ case WIL_RX_CB_MODE_EDMG:
+ return 1;
+ case WIL_RX_CB_MODE_WIDE:
+ return 2;
+ default:
+ return 1;
+ }
+}
+
+static int wil_tx_cb_mode_to_n_bonded(u8 cb_mode)
+{
+ switch (cb_mode) {
+ case WMI_TX_MODE_DMG:
+ case WMI_TX_MODE_EDMG_CB1:
+ return 1;
+ case WMI_TX_MODE_EDMG_CB2:
+ return 2;
+ default:
+ return 1;
+ }
+}
+
static void
wil_memdup_ie(u8 **pdst, size_t *pdst_len, const u8 *src, size_t src_len)
{
@@ -82,6 +131,12 @@ void update_supported_bands(struct wil6210_priv *wil)
wiphy->bands[NL80211_BAND_60GHZ]->n_channels =
wil_num_supported_channels(wil);
+
+ if (test_bit(WMI_FW_CAPABILITY_CHANNEL_BONDING, wil->fw_capabilities))
+ wiphy->bands[NL80211_BAND_60GHZ]->edmg_cap.channels =
+ WIL_EDMG_CHANNELS;
+ wiphy->bands[NL80211_BAND_60GHZ]->edmg_cap.bw_config =
+ WIL_EDMG_BW_CONFIGURATION;
}
/* Vendor id to be used in vendor specific command and events
@@ -296,6 +351,86 @@ int wil_iftype_nl2wmi(enum nl80211_iftype type)
return -EOPNOTSUPP;
}
+int wil_spec2wmi_ch(u8 spec_ch, u8 *wmi_ch)
+{
+ switch (spec_ch) {
+ case 1:
+ *wmi_ch = WMI_CHANNEL_1;
+ break;
+ case 2:
+ *wmi_ch = WMI_CHANNEL_2;
+ break;
+ case 3:
+ *wmi_ch = WMI_CHANNEL_3;
+ break;
+ case 4:
+ *wmi_ch = WMI_CHANNEL_4;
+ break;
+ case 5:
+ *wmi_ch = WMI_CHANNEL_5;
+ break;
+ case 6:
+ *wmi_ch = WMI_CHANNEL_6;
+ break;
+ case 9:
+ *wmi_ch = WMI_CHANNEL_9;
+ break;
+ case 10:
+ *wmi_ch = WMI_CHANNEL_10;
+ break;
+ case 11:
+ *wmi_ch = WMI_CHANNEL_11;
+ break;
+ case 12:
+ *wmi_ch = WMI_CHANNEL_12;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int wil_wmi2spec_ch(u8 wmi_ch, u8 *spec_ch)
+{
+ switch (wmi_ch) {
+ case WMI_CHANNEL_1:
+ *spec_ch = 1;
+ break;
+ case WMI_CHANNEL_2:
+ *spec_ch = 2;
+ break;
+ case WMI_CHANNEL_3:
+ *spec_ch = 3;
+ break;
+ case WMI_CHANNEL_4:
+ *spec_ch = 4;
+ break;
+ case WMI_CHANNEL_5:
+ *spec_ch = 5;
+ break;
+ case WMI_CHANNEL_6:
+ *spec_ch = 6;
+ break;
+ case WMI_CHANNEL_9:
+ *spec_ch = 9;
+ break;
+ case WMI_CHANNEL_10:
+ *spec_ch = 10;
+ break;
+ case WMI_CHANNEL_11:
+ *spec_ch = 11;
+ break;
+ case WMI_CHANNEL_12:
+ *spec_ch = 12;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
int wil_cid_fill_sinfo(struct wil6210_vif *vif, int cid,
struct station_info *sinfo)
{
@@ -310,6 +445,7 @@ int wil_cid_fill_sinfo(struct wil6210_vif *vif, int cid,
} __packed reply;
struct wil_net_stats *stats = &wil->sta[cid].stats;
int rc;
+ u8 txflag = RATE_INFO_FLAGS_DMG;
memset(&reply, 0, sizeof(reply));
@@ -322,7 +458,8 @@ int wil_cid_fill_sinfo(struct wil6210_vif *vif, int cid,
" MCS %d TSF 0x%016llx\n"
" BF status 0x%08x RSSI %d SQI %d%%\n"
" Tx Tpt %d goodput %d Rx goodput %d\n"
- " Sectors(rx:tx) my %d:%d peer %d:%d\n""}\n",
+ " Sectors(rx:tx) my %d:%d peer %d:%d\n"
+ " Tx mode %d}\n",
cid, vif->mid, le16_to_cpu(reply.evt.bf_mcs),
le64_to_cpu(reply.evt.tsf), reply.evt.status,
reply.evt.rssi,
@@ -333,7 +470,8 @@ int wil_cid_fill_sinfo(struct wil6210_vif *vif, int cid,
le16_to_cpu(reply.evt.my_rx_sector),
le16_to_cpu(reply.evt.my_tx_sector),
le16_to_cpu(reply.evt.other_rx_sector),
- le16_to_cpu(reply.evt.other_tx_sector));
+ le16_to_cpu(reply.evt.other_tx_sector),
+ reply.evt.tx_mode);
sinfo->generation = wil->sinfo_gen;
@@ -346,9 +484,16 @@ int wil_cid_fill_sinfo(struct wil6210_vif *vif, int cid,
BIT_ULL(NL80211_STA_INFO_RX_DROP_MISC) |
BIT_ULL(NL80211_STA_INFO_TX_FAILED);
- sinfo->txrate.flags = RATE_INFO_FLAGS_DMG;
+ if (wil->use_enhanced_dma_hw && reply.evt.tx_mode != WMI_TX_MODE_DMG)
+ txflag = RATE_INFO_FLAGS_EDMG;
+
+ sinfo->txrate.flags = txflag;
sinfo->txrate.mcs = le16_to_cpu(reply.evt.bf_mcs);
sinfo->rxrate.mcs = stats->last_mcs_rx;
+ sinfo->txrate.n_bonded_ch =
+ wil_tx_cb_mode_to_n_bonded(reply.evt.tx_mode);
+ sinfo->rxrate.n_bonded_ch =
+ wil_rx_cb_mode_to_n_bonded(stats->last_cb_mode_rx);
sinfo->rx_bytes = stats->rx_bytes;
sinfo->rx_packets = stats->rx_packets;
sinfo->rx_dropped_misc = stats->rx_dropped;
@@ -1006,6 +1151,33 @@ static int wil_ft_connect(struct wiphy *wiphy,
return rc;
}
+static int wil_get_wmi_edmg_channel(struct wil6210_priv *wil, u8 edmg_bw_config,
+ u8 edmg_channels, u8 *wmi_ch)
+{
+ if (!edmg_bw_config) {
+ *wmi_ch = 0;
+ return 0;
+ } else if (edmg_bw_config == WIL_EDMG_BW_CONFIGURATION) {
+ /* convert from edmg channel bitmap into edmg channel number */
+ switch (edmg_channels) {
+ case WIL_EDMG_CHANNEL_9_SUBCHANNELS:
+ return wil_spec2wmi_ch(9, wmi_ch);
+ case WIL_EDMG_CHANNEL_10_SUBCHANNELS:
+ return wil_spec2wmi_ch(10, wmi_ch);
+ case WIL_EDMG_CHANNEL_11_SUBCHANNELS:
+ return wil_spec2wmi_ch(11, wmi_ch);
+ default:
+ wil_err(wil, "Unsupported edmg channel bitmap 0x%x\n",
+ edmg_channels);
+ return -EINVAL;
+ }
+ } else {
+ wil_err(wil, "Unsupported EDMG BW configuration %d\n",
+ edmg_bw_config);
+ return -EINVAL;
+ }
+}
+
static int wil_cfg80211_connect(struct wiphy *wiphy,
struct net_device *ndev,
struct cfg80211_connect_params *sme)
@@ -1151,6 +1323,11 @@ static int wil_cfg80211_connect(struct wiphy *wiphy,
memcpy(conn.ssid, ssid_eid+2, conn.ssid_len);
conn.channel = ch - 1;
+ rc = wil_get_wmi_edmg_channel(wil, sme->edmg_bw_config,
+ sme->edmg_channels, &conn.edmg_channel);
+ if (rc < 0)
+ return rc;
+
ether_addr_copy(conn.bssid, bss->bssid);
ether_addr_copy(conn.dst_mac, bss->bssid);
@@ -1707,7 +1884,7 @@ static int _wil_cfg80211_set_ies(struct wil6210_vif *vif,
static int _wil_cfg80211_start_ap(struct wiphy *wiphy,
struct net_device *ndev,
const u8 *ssid, size_t ssid_len, u32 privacy,
- int bi, u8 chan,
+ int bi, u8 chan, u8 wmi_edmg_channel,
struct cfg80211_beacon_data *bcon,
u8 hidden_ssid, u32 pbss)
{
@@ -1770,6 +1947,7 @@ static int _wil_cfg80211_start_ap(struct wiphy *wiphy,
vif->privacy = privacy;
vif->channel = chan;
+ vif->wmi_edmg_channel = wmi_edmg_channel;
vif->hidden_ssid = hidden_ssid;
vif->pbss = pbss;
vif->bi = bi;
@@ -1780,7 +1958,8 @@ static int _wil_cfg80211_start_ap(struct wiphy *wiphy,
if (!wil_has_other_active_ifaces(wil, ndev, false, true))
wil6210_bus_request(wil, WIL_MAX_BUS_REQUEST_KBPS);
- rc = wmi_pcp_start(vif, bi, wmi_nettype, chan, hidden_ssid, is_go);
+ rc = wmi_pcp_start(vif, bi, wmi_nettype, chan, wmi_edmg_channel,
+ hidden_ssid, is_go);
if (rc)
goto err_pcp_start;
@@ -1832,7 +2011,8 @@ void wil_cfg80211_ap_recovery(struct wil6210_priv *wil)
rc = _wil_cfg80211_start_ap(wiphy, ndev,
vif->ssid, vif->ssid_len,
vif->privacy, vif->bi,
- vif->channel, &bcon,
+ vif->channel,
+ vif->wmi_edmg_channel, &bcon,
vif->hidden_ssid, vif->pbss);
if (rc) {
wil_err(wil, "vif %d recovery failed (%d)\n", i, rc);
@@ -1882,7 +2062,8 @@ static int wil_cfg80211_change_beacon(struct wiphy *wiphy,
rc = _wil_cfg80211_start_ap(wiphy, ndev, vif->ssid,
vif->ssid_len, privacy,
wdev->beacon_interval,
- vif->channel, bcon,
+ vif->channel,
+ vif->wmi_edmg_channel, bcon,
vif->hidden_ssid,
vif->pbss);
} else {
@@ -1901,10 +2082,17 @@ static int wil_cfg80211_start_ap(struct wiphy *wiphy,
struct ieee80211_channel *channel = info->chandef.chan;
struct cfg80211_beacon_data *bcon = &info->beacon;
struct cfg80211_crypto_settings *crypto = &info->crypto;
+ u8 wmi_edmg_channel;
u8 hidden_ssid;
wil_dbg_misc(wil, "start_ap\n");
+ rc = wil_get_wmi_edmg_channel(wil, info->chandef.edmg_bw_config,
+ info->chandef.edmg_channels,
+ &wmi_edmg_channel);
+ if (rc < 0)
+ return rc;
+
if (!channel) {
wil_err(wil, "AP: No channel???\n");
return -EINVAL;
@@ -1944,7 +2132,8 @@ static int wil_cfg80211_start_ap(struct wiphy *wiphy,
rc = _wil_cfg80211_start_ap(wiphy, ndev,
info->ssid, info->ssid_len, info->privacy,
info->beacon_interval, channel->hw_value,
- bcon, hidden_ssid, info->pbss);
+ wmi_edmg_channel, bcon, hidden_ssid,
+ info->pbss);
return rc;
}
diff --git a/drivers/net/wireless/ath/wil6210/txrx_edma.c b/drivers/net/wireless/ath/wil6210/txrx_edma.c
index c387738..0c9bb2c 100644
--- a/drivers/net/wireless/ath/wil6210/txrx_edma.c
+++ b/drivers/net/wireless/ath/wil6210/txrx_edma.c
@@ -1006,6 +1006,8 @@ static struct sk_buff *wil_sring_reap_rx_edma(struct wil6210_priv *wil,
stats->rx_per_mcs[stats->last_mcs_rx]++;
}
+ stats->last_cb_mode_rx = wil_rx_status_get_cb_mode(msg);
+
if (!wil->use_rx_hw_reordering && !wil->use_compressed_rx_status &&
wil_check_bar(wil, msg, cid, skb, stats) == -EAGAIN) {
kfree_skb(skb);
diff --git a/drivers/net/wireless/ath/wil6210/txrx_edma.h b/drivers/net/wireless/ath/wil6210/txrx_edma.h
index 343516a..2680ffc 100644
--- a/drivers/net/wireless/ath/wil6210/txrx_edma.h
+++ b/drivers/net/wireless/ath/wil6210/txrx_edma.h
@@ -366,6 +366,12 @@ static inline u8 wil_rx_status_get_mcs(void *msg)
16, 21);
}
+static inline u8 wil_rx_status_get_cb_mode(void *msg)
+{
+ return WIL_GET_BITS(((struct wil_rx_status_compressed *)msg)->d1,
+ 22, 23);
+}
+
static inline u16 wil_rx_status_get_flow_id(void *msg)
{
return WIL_GET_BITS(((struct wil_rx_status_compressed *)msg)->d0,
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h b/drivers/net/wireless/ath/wil6210/wil6210.h
index e1b1039b..d32c0bf 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -590,6 +590,7 @@ struct wil_net_stats {
unsigned long rx_amsdu_error; /* eDMA specific */
unsigned long rx_csum_err;
u16 last_mcs_rx;
+ u8 last_cb_mode_rx;
u64 rx_per_mcs[WIL_MCS_MAX + 1];
u32 ft_roams; /* relevant in STA mode */
};
@@ -851,6 +852,7 @@ struct wil6210_vif {
DECLARE_BITMAP(status, wil_vif_status_last);
u32 privacy; /* secure connection? */
u16 channel; /* relevant in AP mode */
+ u8 wmi_edmg_channel; /* relevant in AP mode */
u8 hidden_ssid; /* relevant in AP mode */
u32 ap_isolate; /* no intra-BSS communication */
bool pbss;
@@ -1313,7 +1315,7 @@ int wil_cid_fill_sinfo(struct wil6210_vif *vif, int cid,
int wmi_set_mac_address(struct wil6210_priv *wil, void *addr);
int wmi_pcp_start(struct wil6210_vif *vif, int bi, u8 wmi_nettype, u8 chan,
- u8 hidden_ssid, u8 is_go);
+ u8 edmg_chan, u8 hidden_ssid, u8 is_go);
int wmi_pcp_stop(struct wil6210_vif *vif);
int wmi_led_cfg(struct wil6210_priv *wil, bool enable);
int wmi_abort_scan(struct wil6210_vif *vif);
@@ -1389,6 +1391,10 @@ int wmi_start_sched_scan(struct wil6210_priv *wil,
int wmi_mgmt_tx_ext(struct wil6210_vif *vif, const u8 *buf, size_t len,
u8 channel, u16 duration_ms);
+int wil_wmi2spec_ch(u8 wmi_ch, u8 *spec_ch);
+int wil_spec2wmi_ch(u8 spec_ch, u8 *wmi_ch);
+void wil_update_supported_bands(struct wil6210_priv *wil);
+
int reverse_memcmp(const void *cs, const void *ct, size_t count);
/* WMI for enhanced DMA */
diff --git a/drivers/net/wireless/ath/wil6210/wmi.c b/drivers/net/wireless/ath/wil6210/wmi.c
index bda4a97..fe8530d 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.c
+++ b/drivers/net/wireless/ath/wil6210/wmi.c
@@ -2123,8 +2123,8 @@ int wmi_led_cfg(struct wil6210_priv *wil, bool enable)
return rc;
}
-int wmi_pcp_start(struct wil6210_vif *vif,
- int bi, u8 wmi_nettype, u8 chan, u8 hidden_ssid, u8 is_go)
+int wmi_pcp_start(struct wil6210_vif *vif, int bi, u8 wmi_nettype,
+ u8 chan, u8 wmi_edmg_chan, u8 hidden_ssid, u8 is_go)
{
struct wil6210_priv *wil = vif_to_wil(vif);
int rc;
@@ -2134,6 +2134,7 @@ int wmi_pcp_start(struct wil6210_vif *vif,
.network_type = wmi_nettype,
.disable_sec_offload = 1,
.channel = chan - 1,
+ .edmg_channel = wmi_edmg_chan,
.pcp_max_assoc_sta = max_assoc_sta,
.hidden_ssid = hidden_ssid,
.is_go = is_go,
diff --git a/drivers/net/wireless/ath/wil6210/wmi.h b/drivers/net/wireless/ath/wil6210/wmi.h
index b668758..1b39aeb 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.h
+++ b/drivers/net/wireless/ath/wil6210/wmi.h
@@ -95,6 +95,7 @@ enum wmi_fw_capability {
WMI_FW_CAPABILITY_SET_SILENT_RSSI_TABLE = 13,
WMI_FW_CAPABILITY_LO_POWER_CALIB_FROM_OTP = 14,
WMI_FW_CAPABILITY_PNO = 15,
+ WMI_FW_CAPABILITY_CHANNEL_BONDING = 17,
WMI_FW_CAPABILITY_REF_CLOCK_CONTROL = 18,
WMI_FW_CAPABILITY_AP_SME_OFFLOAD_NONE = 19,
WMI_FW_CAPABILITY_MULTI_VIFS = 20,
@@ -355,6 +356,19 @@ enum wmi_connect_ctrl_flag_bits {
#define WMI_MAX_SSID_LEN (32)
+enum wmi_channel {
+ WMI_CHANNEL_1 = 0x00,
+ WMI_CHANNEL_2 = 0x01,
+ WMI_CHANNEL_3 = 0x02,
+ WMI_CHANNEL_4 = 0x03,
+ WMI_CHANNEL_5 = 0x04,
+ WMI_CHANNEL_6 = 0x05,
+ WMI_CHANNEL_9 = 0x06,
+ WMI_CHANNEL_10 = 0x07,
+ WMI_CHANNEL_11 = 0x08,
+ WMI_CHANNEL_12 = 0x09,
+};
+
/* WMI_CONNECT_CMDID */
struct wmi_connect_cmd {
u8 network_type;
@@ -366,8 +380,12 @@ struct wmi_connect_cmd {
u8 group_crypto_len;
u8 ssid_len;
u8 ssid[WMI_MAX_SSID_LEN];
+ /* enum wmi_channel WMI_CHANNEL_1..WMI_CHANNEL_6; for EDMG this is
+ * the primary channel number
+ */
u8 channel;
- u8 reserved0;
+ /* enum wmi_channel WMI_CHANNEL_9..WMI_CHANNEL_12 */
+ u8 edmg_channel;
u8 bssid[WMI_MAC_LEN];
__le32 ctrl_flags;
u8 dst_mac[WMI_MAC_LEN];
@@ -2267,7 +2285,9 @@ struct wmi_notify_req_done_event {
__le32 status;
__le64 tsf;
s8 rssi;
- u8 reserved0[3];
+ /* enum wmi_edmg_tx_mode */
+ u8 tx_mode;
+ u8 reserved0[2];
__le32 tx_tpt;
__le32 tx_goodput;
__le32 rx_goodput;
@@ -2283,8 +2303,12 @@ struct wmi_notify_req_done_event {
/* WMI_CONNECT_EVENTID */
struct wmi_connect_event {
+ /* enum wmi_channel WMI_CHANNEL_1..WMI_CHANNEL_6; for EDMG this is
+ * the primary channel number
+ */
u8 channel;
- u8 reserved0;
+ /* enum wmi_channel WMI_CHANNEL_9..WMI_CHANNEL_12 */
+ u8 edmg_channel;
u8 bssid[WMI_MAC_LEN];
__le16 listen_interval;
__le16 beacon_interval;
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox