* 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: Sedat Dilek @ 2019-05-14 7:49 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Samuel Ortiz, linux-wireless, linux-nfc, robert.dolca,
oleg.zhurakivskyy, clement.perrochaud, charles.gorand,
Andy Shevchenko
In-Reply-To: <5ae87449-83a1-ecce-c72c-b4742c507497@linaro.org>
On Tue, May 14, 2019 at 8:43 AM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
[...]
> The nxp-nci kernel module is loaded and neard is installed.
You have to...
# modprobe -v nxp-nci_i2c
# lsmod | egrep 'nfc|nci|nxp|i2c' | sort
i2c_algo_bit 16384 1 i915
i2c_dev 24576 0
i2c_i801 32768 0
nci 77824 2 nxp_nci,nxp_nci_i2c
nfc 131072 16 nci,nxp_nci
nxp_nci 16384 1 nxp_nci_i2c
nxp_nci_i2c 16384 0
rfkill 28672 10 nfc,bluetooth,thinkpad_acpi,cfg80211
# modinfo nxp_nci_i2c
filename:
/lib/modules/5.1.1-1-amd64-iniza/kernel/drivers/nfc/nxp-nci/nxp-nci_i2c.ko
author: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
author: Clément Perrochaud <clement.perrochaud@nxp.com>
description: I2C driver for NXP NCI NFC controllers
license: GPL
alias: i2c:nxp-nci_i2c
alias: acpi*:NXP7471:*
alias: acpi*:NXP1001:*
alias: of:N*T*Cnxp,nxp-nci-i2cC*
alias: of:N*T*Cnxp,nxp-nci-i2c
depends: nci,nxp-nci
retpoline: Y
intree: Y
name: nxp_nci_i2c
vermagic: 5.1.1-1-amd64-iniza SMP mod_unload modversions
- Sedat -
^ permalink raw reply
* Re: ath10k 5Ghz RSSI low
From: Sam Samy @ 2019-05-14 7:54 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <CAPGJ1o8NUXw2G8hxHkHHwVhqqOGN8atHeaWFZjm-Vhw6ZM8bBw@mail.gmail.com>
hi Ben:
Looks like ./sys/kernel/debug/ieee80211/phy2/ath10k/cal_data is junk
for both the 5Ghz radios even though the
pre-cal-pci-0000:01:00.0.bin/pre-cal-ahb-a800000.wifi.bin is correct.
The 2Ghz cal_data seem to be correct and match the pre-cal-ahb-a000000.wifi.bin.
Openwrt seem to do the right thing in setting the countrycode.
I am clueless. Any pointers would help.
Thanks
On Mon, May 13, 2019 at 1:14 PM Sam Samy <to.swami1@gmail.com> wrote:
>
> >I think you should write to the openwrt mailing list and/or its bug tracker
> >and see if they can help.
>
> Ok. Thanks Ben. will do. Just curious. I am not able to get the reg.
> domain codes in TPC by googling. Do you know where I can get those?
> What is the reg. domains 0x20 and 0x58 value points to?
>
> Thanks
>
> On Mon, May 13, 2019 at 11:17 AM Ben Greear <greearb@candelatech.com> wrote:
> >
> > On 5/13/19 11:10 AM, Sam Samy wrote:
> > > hi Ben,
> > >
> > > I also looked at the TPC on the stock firmware on the AP. There is a
> > > difference.
> >
> > I think you should write to the openwrt mailing list and/or its bug tracker
> > and see if they can help.
> >
> > Thanks,
> > Ben
> >
> > >
> > > Here is the snippet from stock firmware:
> > >
> > > TPC Config for channel 5765 mode 10
> > > **************************************************
> > > CTL = 0x10 Reg. Domain = 20
> > > Antenna Gain = 0 Reg. Max Antenna Gain = 12
> > > Power Limit = 63 Reg. Max Power = 60
> > > Num tx chains = 2 Num Supported Rates = 109
> > > **************************************************
> > > **************** CDD POWER TABLE ****************
> > > **************************************************
> > >
> > > Where as in openwrt it is:
> > >
> > > *************************************
> > > TPC config for channel 5765 mode 10
> > > *************************************
> > > CTL = 0x10 Reg. Domain = 58
> > > Antenna Gain = 0 Reg. Max Antenna Gain = 0
> > > Power Limit = 60 Reg. Max Power = 30
> > > Num tx chains = 2 Num supported rates = 109
> > > ********************************
> > >
> > >
> > > So looks like reg ,domain is different even though both are US.
> > > (Although I didnt set anything on stock firmware. The countrycode from
> > > iwpriv get_countrycode says its 841.)
> > >
> > > Also, the antenna gain seems different between stock and openwrt firmware..
> > >
> > >
> > > How to change the reg. domain like in stock firmware in openwrt
> > > although I set to US in the uci.
> > >
> > > root@OpenWrt:/sys# uci show | grep country
> > > uhttpd.defaults.country='ZZ'
> > > wireless.radio0.country='US'
> > > wireless.radio1.country='US'
> > > wireless.radio2.country='US'
> > > root@OpenWrt:/sys#
> > >
> > > Thanks
> > >
> > >
> > > On Mon, May 13, 2019 at 10:36 AM Sam Samy <to.swami1@gmail.com> wrote:
> > >>
> > >>> Probably it is a board-file and/or calibration data issue then.
> > >>>
> > >>> The debugfs 'ath10k/tpc_stats' file may show very low values?
> > >>
> > >> I am not sure if the values are right. Here is one of the 5Ghz radio stats:
> > >>
> > >> root@OpenWrt:/sys# cat ./kernel/debug/ieee80211/phy0/ath10k/tpc_stats
> > >>
> > >> *************************************
> > >> TPC config for channel 5320 mode 10
> > >> *************************************
> > >> CTL = 0x10 Reg. Domain = 58
> > >> Antenna Gain = 0 Reg. Max Antenna Gain = 0
> > >> Power Limit = 46 Reg. Max Power = 46
> > >> Num tx chains = 2 Num supported rates = 129
> > >> ********************************
> > >> ******************* CDD POWER TABLE ****************
> > >> ********************************
> > >> No. Preamble Rate_code tpc_value0 tpc_value1 tpc_value2 tpc_value3
> > >> 0 CCK 0x40 0 0
> > >> 1 CCK 0x41 0 0
> > >> 2 CCK 0x42 0 0
> > >> 3 CCK 0x43 0 0
> > >> 4 OFDM 0x 0 36 34
> > >> 5 OFDM 0x 1 38 34
> > >> 6 OFDM 0x 2 38 34
> > >> 7 OFDM 0x 3 38 34
> > >> 8 OFDM 0x 4 34 34
> > >> 9 OFDM 0x 5 38 34
> > >> 10 OFDM 0x 6 38 34
> > >> 11 OFDM 0x 7 38 34
> > >> 12 HT20 0x80 38 34
> > >> 13 HT20 0x81 38 34
> > >> 14 HT20 0x82 38 34
> > >> 15 HT20 0x83 38 34
> > >> 16 HT20 0x84 38 34
> > >> 17 HT20 0x85 36 34
> > >> 18 HT20 0x86 34 34
> > >> 19 HT20 0x87 32 32
> > >> 20 HT20 0x90 38 38
> > >> 21 HT20 0x91 38 38
> > >> 22 HT20 0x92 38 38
> > >> 23 HT20 0x93 38 38
> > >> 24 HT20 0x94 38 38
> > >> 25 HT20 0x95 36 36
> > >> 26 HT20 0x96 34 34
> > >> 27 HT20 0x97 32 32
> > >> 28 HT40 0x80 37 34
> > >> 29 HT40 0x81 37 34
> > >> 30 HT40 0x82 37 34
> > >> 31 HT40 0x83 37 34
> > >> 32 HT40 0x84 37 34
> > >> 33 HT40 0x85 35 34
> > >> 34 HT40 0x86 33 33
> > >> 35 HT40 0x87 31 31
> > >> 36 HT40 0x90 37 37
> > >> 37 HT40 0x91 37 37
> > >> 38 HT40 0x92 37 37
> > >> 39 HT40 0x93 37 37
> > >> 40 HT40 0x94 37 37
> > >> 41 HT40 0x95 35 35
> > >> 42 HT40 0x96 33 33
> > >> 43 HT40 0x97 31 31
> > >> 44 VHT20 0xc0 38 34
> > >> 45 VHT20 0xc1 38 34
> > >> 46 VHT20 0xc2 38 34
> > >> 47 VHT20 0xc3 38 34
> > >> 48 VHT20 0xc4 38 34
> > >> 49 VHT20 0xc5 36 34
> > >> 50 VHT20 0xc6 34 34
> > >> 51 VHT20 0xc7 32 32
> > >> 52 VHT20 0xc8 31 31
> > >> 53 VHT20 0xc9 30 30
> > >> 54 VHT20 0xd0 38 38
> > >> 55 VHT20 0xd1 38 38
> > >> 56 VHT20 0xd2 38 38
> > >> 57 VHT20 0xd3 38 38
> > >> 58 VHT20 0xd4 38 38
> > >> 59 VHT20 0xd5 36 36
> > >> 60 VHT20 0xd6 34 34
> > >> 61 VHT20 0xd7 32 32
> > >> 62 VHT20 0xd8 31 31
> > >> 63 VHT20 0xd9 30 30
> > >> 64 VHT40 0xc0 37 34
> > >> 65 VHT40 0xc1 37 34
> > >> 66 VHT40 0xc2 37 34
> > >> 67 VHT40 0xc3 37 34
> > >> 68 VHT40 0xc4 37 34
> > >> 69 VHT40 0xc5 35 34
> > >> 70 VHT40 0xc6 33 33
> > >> 71 VHT40 0xc7 31 31
> > >> 72 VHT40 0xc8 30 30
> > >> 73 VHT40 0xc9 29 29
> > >> 74 VHT40 0xd0 37 37
> > >> 75 VHT40 0xd1 37 37
> > >> 76 VHT40 0xd2 37 37
> > >> 77 VHT40 0xd3 37 37
> > >> 78 VHT40 0xd4 37 37
> > >> 79 VHT40 0xd5 35 35
> > >> 80 VHT40 0xd6 33 33
> > >> 81 VHT40 0xd7 31 31
> > >> 82 VHT40 0xd8 30 30
> > >> 83 VHT40 0xd9 29 29
> > >> 84 VHT80 0xc0 36 34
> > >> 85 VHT80 0xc1 36 34
> > >> 86 VHT80 0xc2 36 34
> > >> 87 VHT80 0xc3 36 34
> > >> 88 VHT80 0xc4 36 34
> > >> 89 VHT80 0xc5 34 34
> > >> 90 VHT80 0xc6 32 32
> > >> 91 VHT80 0xc7 30 30
> > >> 92 VHT80 0xc8 29 29
> > >> 93 VHT80 0xc9 28 28
> > >> 94 VHT80 0xd0 36 36
> > >> 95 VHT80 0xd1 36 36
> > >> 96 VHT80 0xd2 36 36
> > >> 97 VHT80 0xd3 36 36
> > >> 98 VHT80 0xd4 36 36
> > >> 99 VHT80 0xd5 34 34
> > >> 100 VHT80 0xd6 32 32
> > >> 101 VHT80 0xd7 30 30
> > >> 102 VHT80 0xd8 29 29
> > >> 103 VHT80 0xd9 28 28
> > >> 104 HTCUP 0x40 36 36
> > >> 105 HTCUP 0x 0 36 34
> > >> 106 HTCUP 0x40 36 36
> > >> 107 HTCUP 0x 0 36 34
> > >> 108 HTCUP 0x 0 36 34
> > >> 109 HTCUP 0x7a 34 34
> > >> 110 HTCUP 0x8a 32 32
> > >> 111 HTCUP 0x a 30 30
> > >> 112 HTCUP 0xee 27 27
> > >> 113 HTCUP 0xa6 26 26
> > >> 114 HTCUP 0x90 36 36
> > >> 115 HTCUP 0x1d 36 36
> > >> 116 HTCUP 0x80 36 34
> > >> 117 HTCUP 0x41 36 36
> > >> 118 HTCUP 0xd9 36 36
> > >> 119 HTCUP 0x64 34 34
> > >> 120 HTCUP 0xf9 32 32
> > >> 121 HTCUP 0x 0 30 30
> > >> 122 HTCUP 0x 0 27 27
> > >> 123 HTCUP 0x 0 26 26
> > >> 124 HTCUP 0x64 0 0
> > >> 125 HTCUP 0x 0 37 34
> > >> 126 HTCUP 0x31 0 0
> > >> 127 HTCUP 0x 4 37 34
> > >> 128 HTCUP 0x 0 38 34
> > >> ***********************************
> > >> ********************************
> > >> ******************* STBC POWER TABLE ****************
> > >> ********************************
> > >> No. Preamble Rate_code tpc_value0 tpc_value1 tpc_value2 tpc_value3
> > >> 0 CCK 0x40 0 0
> > >> 1 CCK 0x41 0 0
> > >> 2 CCK 0x42 0 0
> > >> 3 CCK 0x43 0 0
> > >> 4 OFDM 0x 0 36 36
> > >> 5 OFDM 0x 1 38 38
> > >> 6 OFDM 0x 2 38 38
> > >> 7 OFDM 0x 3 38 38
> > >> 8 OFDM 0x 4 34 34
> > >> 9 OFDM 0x 5 38 38
> > >> 10 OFDM 0x 6 38 38
> > >> 11 OFDM 0x 7 38 38
> > >> 12 HT20 0x80 38 38
> > >> 13 HT20 0x81 38 38
> > >> 14 HT20 0x82 38 38
> > >> 15 HT20 0x83 38 38
> > >> 16 HT20 0x84 38 38
> > >> 17 HT20 0x85 36 36
> > >> 18 HT20 0x86 34 34
> > >> 19 HT20 0x87 32 32
> > >> 20 HT20 0x90 38 38
> > >> 21 HT20 0x91 38 38
> > >> 22 HT20 0x92 38 38
> > >> 23 HT20 0x93 38 38
> > >> 24 HT20 0x94 38 38
> > >> 25 HT20 0x95 36 36
> > >> 26 HT20 0x96 34 34
> > >> 27 HT20 0x97 32 32
> > >> 28 HT40 0x80 37 37
> > >> 29 HT40 0x81 37 37
> > >> 30 HT40 0x82 37 37
> > >> 31 HT40 0x83 37 37
> > >> 32 HT40 0x84 37 37
> > >> 33 HT40 0x85 35 35
> > >> 34 HT40 0x86 33 33
> > >> 35 HT40 0x87 31 31
> > >> 36 HT40 0x90 37 37
> > >> 37 HT40 0x91 37 37
> > >> 38 HT40 0x92 37 37
> > >> 39 HT40 0x93 37 37
> > >> 40 HT40 0x94 37 37
> > >> 41 HT40 0x95 35 35
> > >> 42 HT40 0x96 33 33
> > >> 43 HT40 0x97 31 31
> > >> 44 VHT20 0xc0 38 38
> > >> 45 VHT20 0xc1 38 38
> > >> 46 VHT20 0xc2 38 38
> > >> 47 VHT20 0xc3 38 38
> > >> 48 VHT20 0xc4 38 38
> > >> 49 VHT20 0xc5 36 36
> > >> 50 VHT20 0xc6 34 34
> > >> 51 VHT20 0xc7 32 32
> > >> 52 VHT20 0xc8 31 31
> > >> 53 VHT20 0xc9 30 30
> > >> 54 VHT20 0xd0 38 38
> > >> 55 VHT20 0xd1 38 38
> > >> 56 VHT20 0xd2 38 38
> > >> 57 VHT20 0xd3 38 38
> > >> 58 VHT20 0xd4 38 38
> > >> 59 VHT20 0xd5 36 36
> > >> 60 VHT20 0xd6 34 34
> > >> 61 VHT20 0xd7 32 32
> > >> 62 VHT20 0xd8 31 31
> > >> 63 VHT20 0xd9 30 30
> > >> 64 VHT40 0xc0 37 37
> > >> 65 VHT40 0xc1 37 37
> > >> 66 VHT40 0xc2 37 37
> > >> 67 VHT40 0xc3 37 37
> > >> 68 VHT40 0xc4 37 37
> > >> 69 VHT40 0xc5 35 35
> > >> 70 VHT40 0xc6 33 33
> > >> 71 VHT40 0xc7 31 31
> > >> 72 VHT40 0xc8 30 30
> > >> 73 VHT40 0xc9 29 29
> > >> 74 VHT40 0xd0 37 37
> > >> 75 VHT40 0xd1 37 37
> > >> 76 VHT40 0xd2 37 37
> > >> 77 VHT40 0xd3 37 37
> > >> 78 VHT40 0xd4 37 37
> > >> 79 VHT40 0xd5 35 35
> > >> 80 VHT40 0xd6 33 33
> > >> 81 VHT40 0xd7 31 31
> > >> 82 VHT40 0xd8 30 30
> > >> 83 VHT40 0xd9 29 29
> > >> 84 VHT80 0xc0 36 36
> > >> 85 VHT80 0xc1 36 36
> > >> 86 VHT80 0xc2 36 36
> > >> 87 VHT80 0xc3 36 36
> > >> 88 VHT80 0xc4 36 36
> > >> 89 VHT80 0xc5 34 34
> > >> 90 VHT80 0xc6 32 32
> > >> 91 VHT80 0xc7 30 30
> > >> 92 VHT80 0xc8 29 29
> > >> 93 VHT80 0xc9 28 28
> > >> 94 VHT80 0xd0 36 36
> > >> 95 VHT80 0xd1 36 36
> > >> 96 VHT80 0xd2 36 36
> > >> 97 VHT80 0xd3 36 36
> > >> 98 VHT80 0xd4 36 36
> > >> 99 VHT80 0xd5 34 34
> > >> 100 VHT80 0xd6 32 32
> > >> 101 VHT80 0xd7 30 30
> > >> 102 VHT80 0xd8 29 29
> > >> 103 VHT80 0xd9 28 28
> > >> 104 HTCUP 0x40 36 36
> > >> 105 HTCUP 0x 0 36 36
> > >> 106 HTCUP 0x40 36 36
> > >> 107 HTCUP 0x 0 36 36
> > >> 108 HTCUP 0x 0 36 36
> > >> 109 HTCUP 0x7a 34 34
> > >> 110 HTCUP 0x8a 32 32
> > >> 111 HTCUP 0x a 30 30
> > >> 112 HTCUP 0xee 27 27
> > >> 113 HTCUP 0xa6 26 26
> > >> 114 HTCUP 0x90 36 36
> > >> 115 HTCUP 0x1d 36 36
> > >> 116 HTCUP 0x80 36 36
> > >> 117 HTCUP 0x41 36 36
> > >> 118 HTCUP 0xd9 36 36
> > >> 119 HTCUP 0x64 34 34
> > >> 120 HTCUP 0xf9 32 32
> > >> 121 HTCUP 0x 0 30 30
> > >> 122 HTCUP 0x 0 27 27
> > >> 123 HTCUP 0x 0 26 26
> > >> 124 HTCUP 0x64 0 0
> > >> 125 HTCUP 0x 0 37 37
> > >> 126 HTCUP 0x31 0 0
> > >> 127 HTCUP 0x 4 37 37
> > >> 128 HTCUP 0x 0 38 38
> > >> ***********************************
> > >> TXBF not supported
> > >> ***************************
> > >> root@OpenWrt:/sys#
> > >>
> > >>
> > >> Thanks
> > >>
> > >> On Mon, May 13, 2019 at 10:27 AM Ben Greear <greearb@candelatech.com> wrote:
> > >>>
> > >>> On 5/13/19 10:26 AM, Sam Samy wrote:
> > >>>> hi Ben,
> > >>>>
> > >>>>> Hello, what firmware are you using (ath10k-ct, or QCA?) If using -ct firmware,
> > >>>>> please try QCA firmware and let me know if that fixes the problem.
> > >>>>>
> > >>>> I tried both. Both have the same problem. I tried various versions
> > >>>> of the both(-ct and QCA) firmware as well. All have the same problem.
> > >>>
> > >>> Probably it is a board-file and/or calibration data issue then.
> > >>>
> > >>> The debugfs 'ath10k/tpc_stats' file may show very low values?
> > >>>
> > >>> Thanks,
> > >>> Ben
> > >>>
> > >>>>
> > >>>> Thanks
> > >>>>
> > >>>> On Mon, May 13, 2019 at 10:00 AM Ben Greear <greearb@candelatech.com> wrote:
> > >>>>>
> > >>>>> On 5/13/19 9:56 AM, Sam Samy wrote:
> > >>>>>> Hi,
> > >>>>>> I installed master branch openwrt onto Asus MAP-AC2200 AP. It has tri
> > >>>>>> band. Its based on IPQ4019 DK04 QCA reference platform. 2 radios
> > >>>>>> (2Ghz/5Ghz) on AHB bus and one 5GHZ on PCIe bus. Its generally working
> > >>>>>> fine except one problem in 5Ghz. On both the 5Ghz radios the RSSI is
> > >>>>>> pretty low on any channel I put it in. In one feet range I see -60dB
> > >>>>>> RSSI, where as the stock firmware that came with the AP gives an RSSI
> > >>>>>> of -36dB at one foot distance.The downstream transmit rates are MCS8/9
> > >>>>>> for most part. The 2Ghz is working fine. Its using the cal data from
> > >>>>>> the flash that came with the AP.
> > >>>>>>
> > >>>>>> Can you please suggest anyway to debug this or improve the RSSI?
> > >>>>>>
> > >>>>>> Thanks you!
> > >>>>>>
> > >>>>>
> > >>>>> Hello, what firmware are you using (ath10k-ct, or QCA?) If using -ct firmware,
> > >>>>> please try QCA firmware and let me know if that fixes the problem.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Ben
> > >>>>>
> > >>>>> --
> > >>>>> Ben Greear <greearb@candelatech.com>
> > >>>>> Candela Technologies Inc http://www.candelatech.com
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>> --
> > >>> Ben Greear <greearb@candelatech.com>
> > >>> Candela Technologies Inc http://www.candelatech.com
> > >>>
> > >
> >
> >
> > --
> > Ben Greear <greearb@candelatech.com>
> > Candela Technologies Inc http://www.candelatech.com
> >
^ permalink raw reply
* Re: NXP NFC version and ACPI
From: Daniel Lezcano @ 2019-05-14 8:17 UTC (permalink / raw)
To: sedat.dilek
Cc: Samuel Ortiz, linux-wireless, linux-nfc, oleg.zhurakivskyy,
clement.perrochaud, charles.gorand, Andy Shevchenko
In-Reply-To: <CA+icZUXDLQKyTH-_pPi7A2=Bu5ratwab930Fcecrdr4NtMnFcw@mail.gmail.com>
On 14/05/2019 09:49, Sedat Dilek wrote:
> On Tue, May 14, 2019 at 8:43 AM Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
> [...]
>
>> The nxp-nci kernel module is loaded and neard is installed.
>
> You have to...
>
> # modprobe -v nxp-nci_i2c
>
> # lsmod | egrep 'nfc|nci|nxp|i2c' | sort
> i2c_algo_bit 16384 1 i915
> i2c_dev 24576 0
> i2c_i801 32768 0
> nci 77824 2 nxp_nci,nxp_nci_i2c
> nfc 131072 16 nci,nxp_nci
> nxp_nci 16384 1 nxp_nci_i2c
> nxp_nci_i2c 16384 0
> rfkill 28672 10 nfc,bluetooth,thinkpad_acpi,cfg80211
I have the same modules except 'rfkill'
> # modinfo nxp_nci_i2c
> filename:
> /lib/modules/5.1.1-1-amd64-iniza/kernel/drivers/nfc/nxp-nci/nxp-nci_i2c.ko
> author: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
> author: Clément Perrochaud <clement.perrochaud@nxp.com>
> description: I2C driver for NXP NCI NFC controllers
> license: GPL
> alias: i2c:nxp-nci_i2c
> alias: acpi*:NXP7471:*
> alias: acpi*:NXP1001:*
> alias: of:N*T*Cnxp,nxp-nci-i2cC*
> alias: of:N*T*Cnxp,nxp-nci-i2c
> depends: nci,nxp-nci
> retpoline: Y
> intree: Y
> name: nxp_nci_i2c
> vermagic: 5.1.1-1-amd64-iniza SMP mod_unload modversions
Same result for the modinfo.
-----
So the first time I run:
[mark]
nfctool -d nfc0 -p
Start polling on nfc0 as initiator
With an error in syslog/dmesg:
nci: nci_ntf_packet: unknown ntf opcode 0x0
The second time:
nfctool -p -d nfc0
Protocol error
With an error in syslog/dmesg:
nci: nci_start_poll: failed to set local general bytes
Then I do:
nfctool -0 -d nfc0
it returns to point [mark]
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: NXP NFC version and ACPI
From: Sedat Dilek @ 2019-05-14 8:30 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Samuel Ortiz, linux-wireless, linux-nfc, oleg.zhurakivskyy,
clement.perrochaud, charles.gorand, Andy Shevchenko
In-Reply-To: <27f2ce02-8deb-384f-af10-7737b703770a@linaro.org>
On Tue, May 14, 2019 at 10:17 AM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>
> On 14/05/2019 09:49, Sedat Dilek wrote:
> > On Tue, May 14, 2019 at 8:43 AM Daniel Lezcano
> > <daniel.lezcano@linaro.org> wrote:
> > [...]
> >
> >> The nxp-nci kernel module is loaded and neard is installed.
> >
> > You have to...
> >
> > # modprobe -v nxp-nci_i2c
> >
> > # lsmod | egrep 'nfc|nci|nxp|i2c' | sort
> > i2c_algo_bit 16384 1 i915
> > i2c_dev 24576 0
> > i2c_i801 32768 0
> > nci 77824 2 nxp_nci,nxp_nci_i2c
> > nfc 131072 16 nci,nxp_nci
> > nxp_nci 16384 1 nxp_nci_i2c
> > nxp_nci_i2c 16384 0
> > rfkill 28672 10 nfc,bluetooth,thinkpad_acpi,cfg80211
>
> I have the same modules except 'rfkill'
>
> > # modinfo nxp_nci_i2c
> > filename:
> > /lib/modules/5.1.1-1-amd64-iniza/kernel/drivers/nfc/nxp-nci/nxp-nci_i2c.ko
> > author: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
> > author: Clément Perrochaud <clement.perrochaud@nxp.com>
> > description: I2C driver for NXP NCI NFC controllers
> > license: GPL
> > alias: i2c:nxp-nci_i2c
> > alias: acpi*:NXP7471:*
> > alias: acpi*:NXP1001:*
> > alias: of:N*T*Cnxp,nxp-nci-i2cC*
> > alias: of:N*T*Cnxp,nxp-nci-i2c
> > depends: nci,nxp-nci
> > retpoline: Y
> > intree: Y
> > name: nxp_nci_i2c
> > vermagic: 5.1.1-1-amd64-iniza SMP mod_unload modversions
>
> Same result for the modinfo.
>
> -----
>
> So the first time I run:
>
> [mark]
> nfctool -d nfc0 -p
> Start polling on nfc0 as initiator
>
> With an error in syslog/dmesg:
> nci: nci_ntf_packet: unknown ntf opcode 0x0
>
>
> The second time:
>
> nfctool -p -d nfc0
> Protocol error
>
> With an error in syslog/dmesg:
> nci: nci_start_poll: failed to set local general bytes
>
> Then I do:
>
> nfctool -0 -d nfc0
>
> it returns to point [mark]
>
I cannot help with (debugging) nci.
I had all I2C and GPIO debug Kconfigs enabled to see a bit more
informations in the logs.
Maybe that helps you.
- Sedat -
^ permalink raw reply
* Re: [PATCH] mac80211: fix possible deadlock in TX path
From: Johannes Berg @ 2019-05-14 8:33 UTC (permalink / raw)
To: Erik Stromdahl, davem, linux-wireless, linux-kernel
Cc: Toke Høiland-Jørgensen
In-Reply-To: <20190427204155.14211-1-erik.stromdahl@gmail.com>
On Sat, 2019-04-27 at 22:41 +0200, Erik Stromdahl wrote:
> This patch fixes a possible deadlock when updating the TX statistics
> (when calling into ieee80211_tx_stats()) from ieee80211_tx_dequeue().
>
> ieee80211_tx_dequeue() might be called from process context.
I think this really is the problem.
> [<c0cb1864>] (ieee80211_xmit_fast_finish) from [<c0cb4504>] (ieee80211_tx_dequeue+0x30c/0xb9c)
> r10:d2f1a900 r9:d2d607a4 r8:d2cf20dc r7:d330b29c r6:d2cf2000 r5:d2c342ba
> r4:d2899d3c
> [<c0cb41f8>] (ieee80211_tx_dequeue) from [<bf057f64>] (ath10k_mac_tx_push_txq+0x78/0x2a4 [ath10k_core])
> r10:d2d607cc r9:d2fe06a0 r8:00000000 r7:d2fe1e30 r6:d2fe1d38 r5:d2fe1540
> r4:d2cf20dc
> [<bf057eec>] (ath10k_mac_tx_push_txq [ath10k_core]) from [<bf058364>] (ath10k_mac_tx_push_pending+0x1d4/0x2e0 [ath10k_core])
> r10:d2cf20dc r9:bf0582b4 r8:bf0b1dba r7:00000002 r6:c1429994 r5:00000000
> r4:d2fe06a0
> [<bf058190>] (ath10k_mac_tx_push_pending [ath10k_core]) from [<bf0e25a4>] (ath10k_sdio_irq_handler+0x30c/0x4d8 [ath10k_sdio])
> r10:00005b5a r9:d2fcc040 r8:00180201 r7:d2fe6540 r6:d2fe6a7c r5:00000000
> r4:d2fe1540
It seems to be entirely ath10k's fault, and quite possibly our
documentation, but we probably should have local_bh_disable() there
rather than try to do u64_stats_update_begin_irqsave() in some path that
really doesn't need it.
This is going to be whack-a-mole otherwise - the TX path in mac80211
really expects to not be interrupted by softirqs.
johannes
^ permalink raw reply
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Sedat Dilek @ 2019-05-14 8:34 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Clément Perrochaud, Charles Gorand, linux-nfc, Samuel Ortiz,
linux-wireless, Oleg Zhurakivskyy
In-Reply-To: <20190513123751.GS9224@smile.fi.intel.com>
On Mon, May 13, 2019 at 2:37 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, May 13, 2019 at 02:18:03PM +0200, Sedat Dilek wrote:
> > On Mon, May 13, 2019 at 12:44 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > >
> > > It has been reported that some laptops, equipped with NXP NFC300, have
> > > different ID then mentioned in the driver.
> > >
> > > While at it, I found that the driver has a lot of duplication and redundant
> > > platform data. The rest of the series (11 out of 12 patches) is dedicated to
> > > clean the driver up.
> > >
> > > Sedat, would be nice if you can compile kernel with this patch series applied
> > > and test on your laptop.
> > >
> > > In v2:
> > > - added new ID patch
> > > - added new clean up patch
> > > - Cc'ed to linux-wireless@ as well, since linux-nfc@ bounces my mails
> > > - Cc'ed to the reported of the problem with T470 laptop
> > >
> > > Andy Shevchenko (12):
> > > NFC: nxp-nci: Add NXP1001 to the ACPI ID table
> > > NFC: nxp-nci: Get rid of platform data
> > > NFC: nxp-nci: Convert to use GPIO descriptor
> > > NFC: nxp-nci: Add GPIO ACPI mapping table
> > > NFC: nxp-nci: Get rid of code duplication in ->probe()
> > > NFC: nxp-nci: Get rid of useless label
> > > NFC: nxp-nci: Constify acpi_device_id
> > > NFC: nxp-nci: Drop of_match_ptr() use
> > > NFC: nxp-nci: Drop comma in terminator lines
> > > NFC: nxp-nci: Remove unused macro pr_fmt()
> > > NFC: nxp-nci: Remove 'default n' for tests
> > > NFC: nxp-nci: Convert to SPDX license tags
> > >
> > > MAINTAINERS | 1 -
> > > drivers/nfc/nxp-nci/Kconfig | 1 -
> > > drivers/nfc/nxp-nci/core.c | 15 +--
> > > drivers/nfc/nxp-nci/firmware.c | 13 +--
> > > drivers/nfc/nxp-nci/i2c.c | 147 ++++++--------------------
> > > drivers/nfc/nxp-nci/nxp-nci.h | 1 -
> > > include/linux/platform_data/nxp-nci.h | 27 -----
> > > 7 files changed, 37 insertions(+), 168 deletions(-)
> > > delete mode 100644 include/linux/platform_data/nxp-nci.h
> >
> > Can we have NPC300 listed in the Kconfg help text?
>
> Sure, it's good thing to do!
>
> Either as a separate patch or I may incorporate in the next iteration.
> Samuel, what do you prefer?
>
Am I correct that "NPC100" is "PN547" and "NPC300" is "PN548"?
- Sedat -
^ permalink raw reply
* Re: [PATCH v3] {nl,mac}80211: allow 4addr AP operation on crypto controlled devices
From: Johannes Berg @ 2019-05-14 8:38 UTC (permalink / raw)
To: Manikanta Pubbisetty; +Cc: linux-wireless
In-Reply-To: <1557307533-5795-1-git-send-email-mpubbise@codeaurora.org>
On Wed, 2019-05-08 at 14:55 +0530, Manikanta Pubbisetty wrote:
>
> +++ b/net/mac80211/util.c
> @@ -3795,7 +3795,9 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata,
> }
>
> /* Always allow software iftypes */
> - if (local->hw.wiphy->software_iftypes & BIT(iftype)) {
> + if (local->hw.wiphy->software_iftypes & BIT(iftype) ||
> + (iftype == NL80211_IFTYPE_AP_VLAN &&
> + local->hw.wiphy->flags & WIPHY_FLAG_4ADDR_AP)) {
> if (radar_detect)
> return -EINVAL;
Shouldn't this check if 4addr is actually enabled too, like here:
> case NETDEV_PRE_UP:
> - if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype)))
> + if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype)) &&
> + !(wdev->iftype == NL80211_IFTYPE_AP_VLAN &&
> + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP &&
> + wdev->use_4addr))
> return notifier_from_errno(-EOPNOTSUPP);
?
Or is there some reason it doesn't matter?
> @@ -3439,6 +3438,11 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
> return err;
> }
>
> + if (!(rdev->wiphy.interface_modes & (1 << type)) &&
> + !(type == NL80211_IFTYPE_AP_VLAN && params.use_4addr &&
> + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP))
> + return -EOPNOTSUPP;
> +
I also wonder if we shouldn't go "all in" and actually make the check
something like
check_interface_allowed(iftype, 4addr):
if (iftype == AP_VLAN && 4addr)
return wiphy.flags & WIPHY_FLAG_4ADDR_AP;
else return wiphy.interface_modes & BIT(iftype);
i.e. make it "you must have WIPHY_FLAG_4ADDR_AP to use 4-addr AP_VLAN
interfaces", rather than "also allow it in this case".
That would seem like the clearer semantics to me?
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: remove warning message
From: Johannes Berg @ 2019-05-14 8:44 UTC (permalink / raw)
To: Yibo Zhao, linux-wireless; +Cc: ath10k, Zhi Chen
In-Reply-To: <1557471662-1355-1-git-send-email-yiboz@codeaurora.org>
On Fri, 2019-05-10 at 15:01 +0800, Yibo Zhao wrote:
> In multiple SSID cases, it takes time to prepare every AP interface
> to be ready in initializing phase. If a sta already knows everything it
> needs to join one of the APs and sends authentication to the AP which
> is not fully prepared at this point of time, AP's channel context
> could be NULL. As a result, warning message occurs.
Please share the dump, I don't think this should be happening. I think
this warning did what it was supposed to, uncover a bug; rather than
remove the warning we should fix the bug.
> Even worse, if the AP is under attack via tools such as MDK3 and massive
> authentication requests are received in a very short time, console will
> be hung due to kernel warning messages.
I don't buy this, it's just a WARN_ON_ONCE().
> If this case can be hit during normal functionality, there should be no
> WARN_ON(). Those should be reserved to cases that are not supposed to be
> hit at all or some other more specific cases like indicating obsolete
> interface.
I agree, but right now I'm inclined to think it's a bug elsewhere rather
than normal operation.
johannes
^ permalink raw reply
* [PATCH v2] mac80211: remove warning message
From: Yibo Zhao @ 2019-05-14 9:01 UTC (permalink / raw)
To: linux-wireless; +Cc: ath10k, Yibo Zhao, Zhi Chen
In multiple SSID cases, it takes time to prepare every AP interface
to be ready in initializing phase. If a sta already knows everything it
needs to join one of the APs and sends authentication to the AP which
is not fully prepared at this point of time, AP's channel context
could be NULL. As a result, warning message occurs.
Even worse, if the AP is under attack via tools such as MDK3 and massive
authentication requests are received in a very short time, console will
be hung due to kernel warning messages.
If this case can be hit during normal functionality, there should be no
WARN_ON(). Those should be reserved to cases that are not supposed to be
hit at all or some other more specific cases like indicating obsolete
interface.
Signed-off-by: Zhi Chen <zhichen@codeaurora.org>
Signed-off-by: Yibo Zhao <yiboz@codeaurora.org>
---
net/mac80211/ieee80211_i.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 073a823..f39c289 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1435,7 +1435,7 @@ struct ieee80211_local {
rcu_read_lock();
chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
- if (WARN_ON(!chanctx_conf)) {
+ if (!chanctx_conf) {
rcu_read_unlock();
return NULL;
}
--
1.9.1
^ permalink raw reply related
* [PATCH] NFC: Orphan the subsystem
From: Johannes Berg @ 2019-05-14 9:02 UTC (permalink / raw)
To: linux-wireless, netdev; +Cc: Samuel Ortiz
Samuel clearly hasn't been working on this in many years and
patches getting to the wireless list are just being ignored
entirely now. Mark the subsystem as orphan to reflect the
current state and revert back to the netdev list so at least
some fixes can be picked up by Dave.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
MAINTAINERS | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index fb9f9d71f7a2..b2659312e9ed 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11028,10 +11028,8 @@ S: Supported
F: drivers/net/ethernet/qlogic/netxen/
NFC SUBSYSTEM
-M: Samuel Ortiz <sameo@linux.intel.com>
-L: linux-wireless@vger.kernel.org
-L: linux-nfc@lists.01.org (subscribers-only)
-S: Supported
+L: netdev@vger.kernel.org
+S: Orphan
F: net/nfc/
F: include/net/nfc/
F: include/uapi/linux/nfc.h
--
2.17.2
^ permalink raw reply related
* Re: [PATCH v2] mac80211: remove warning message
From: Johannes Berg @ 2019-05-14 9:05 UTC (permalink / raw)
To: Yibo Zhao, linux-wireless; +Cc: ath10k, Zhi Chen
In-Reply-To: <1557824507-17668-1-git-send-email-yiboz@codeaurora.org>
On Tue, 2019-05-14 at 17:01 +0800, Yibo Zhao wrote:
> In multiple SSID cases, it takes time to prepare every AP interface
> to be ready in initializing phase. If a sta already knows everything it
> needs to join one of the APs and sends authentication to the AP which
> is not fully prepared at this point of time, AP's channel context
> could be NULL. As a result, warning message occurs.
>
Err, what was the point in sending v2 without any changes?
johannes
^ permalink raw reply
* Re: [PATCH v2] mac80211: remove warning message
From: Yibo Zhao @ 2019-05-14 9:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, ath10k, Zhi Chen
In-Reply-To: <7c92f5cf51eaec1d5449698d90f5b6c5ca6c2bea.camel@sipsolutions.net>
On 2019-05-14 17:05, Johannes Berg wrote:
> On Tue, 2019-05-14 at 17:01 +0800, Yibo Zhao wrote:
>> In multiple SSID cases, it takes time to prepare every AP interface
>> to be ready in initializing phase. If a sta already knows everything
>> it
>> needs to join one of the APs and sends authentication to the AP which
>> is not fully prepared at this point of time, AP's channel context
>> could be NULL. As a result, warning message occurs.
>>
> Err, what was the point in sending v2 without any changes?
>
> johannes
Hi Johannes,
I was planning to use WARN_ON_ONCE() in the first place to replace
WARN_ON() then after some discussion, we think removing it could be
better. So the first patch was based on my first version which is sent
incorrectly. Please check again.
Sorry for the confusing.
--
Yibo
^ permalink raw reply
* Re: [PATCH v2] mac80211: remove warning message
From: Johannes Berg @ 2019-05-14 9:12 UTC (permalink / raw)
To: Yibo Zhao; +Cc: linux-wireless, ath10k, Zhi Chen
In-Reply-To: <ccb48284f0d96e72f4c041e12c943f0a@codeaurora.org>
On Tue, 2019-05-14 at 17:10 +0800, Yibo Zhao wrote:
> On 2019-05-14 17:05, Johannes Berg wrote:
> > On Tue, 2019-05-14 at 17:01 +0800, Yibo Zhao wrote:
> > > In multiple SSID cases, it takes time to prepare every AP interface
> > > to be ready in initializing phase. If a sta already knows everything
> > > it
> > > needs to join one of the APs and sends authentication to the AP which
> > > is not fully prepared at this point of time, AP's channel context
> > > could be NULL. As a result, warning message occurs.
> > >
> >
> > Err, what was the point in sending v2 without any changes?
> >
> > johannes
>
> Hi Johannes,
>
> I was planning to use WARN_ON_ONCE() in the first place to replace
> WARN_ON() then after some discussion, we think removing it could be
> better. So the first patch was based on my first version which is sent
> incorrectly. Please check again.
Oops, I didn't pay attention to the - code.
I guess changing it to WARN_ON_ONCE() makes sense, but as per my earlier
email I'm really not sure about removing it entirely, it doesn't seem
like a valid scenario and we should take steps elsewhere to prevent it.
johannes
^ permalink raw reply
* [PATCH] mt76: mt7615: do not process rx packets if the device is not initialized
From: Lorenzo Bianconi @ 2019-05-14 9:18 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
In-Reply-To: <cover.1557825294.git.lorenzo@kernel.org>
Fix following crash that occurs when the driver is processing rx packets
while the device is not initialized yet
$ rmmod mt7615e
[ 67.210261] mt7615e 0000:01:00.0: Message -239 (seq 2) timeout
$ modprobe mt7615e
[ 72.406937] bus=0x1, slot = 0x0, irq=0x16
[ 72.436590] CPU 0 Unable to handle kernel paging request at virtual address 00000004, epc == 8eec4240, ra == 8eec41e0
[ 72.450291] mt7615e 0000:01:00.0: Firmware is not ready for download
[ 72.457724] Oops[#1]:
[ 72.470494] mt7615e: probe of 0000:01:00.0 failed with error -5
[ 72.474829] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.114 #0
[ 72.498702] task: 805769e0 task.stack: 80564000
[ 72.507709] $ 0 : 00000000 00000001 00000000 00000001
[ 72.518106] $ 4 : 8f704dbc 00000000 00000000 8f7046c0
[ 72.528500] $ 8 : 00000024 8045e98c 81210008 11000000
[ 72.538895] $12 : 8fc09f60 00000008 00000019 00000033
[ 72.549289] $16 : 8f704d80 e00000ff 8f0c7800 3c182406
[ 72.559684] $20 : 00000006 8ee615a0 4e000108 00000000
[ 72.570078] $24 : 0000004c 8000cf94
[ 72.580474] $28 : 80564000 8fc09e38 00000001 8eec41e0
[ 72.590869] Hi : 00000001
[ 72.596582] Lo : 00000000
[ 72.602319] epc : 8eec4240 mt7615_mac_fill_rx+0xac/0x494 [mt7615e]
[ 72.614953] ra : 8eec41e0 mt7615_mac_fill_rx+0x4c/0x494 [mt7615e]
[ 72.627580] Status: 11008403 KERNEL EXL IE
[ 72.635899] Cause : 40800008 (ExcCode 02)
[ 72.643860] BadVA : 00000004
[ 72.649573] PrId : 0001992f (MIPS 1004Kc)
[ 72.657704] Modules linked in: mt7615e pppoe ppp_async pppox ppp_generic nf_conntrack_ipv6 mt76x2e mt76x2_common mt76x02_lib mt7603e mt76 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_mu]
[ 72.792717] Process swapper/0 (pid: 0, threadinfo=80564000, task=805769e0, tls=00000000)
[ 72.808799] Stack : 8f0c7800 00000800 8f0c7800 8032b874 00000000 40000000 8f704d80 8ee615a0
[ 72.825428] 8dc88010 00000001 8ee615e0 8eec09b0 8dc88010 8032b914 8f3aee80 80567d20
[ 72.842055] 00000000 8ee615e0 40000000 8f0c7800 00000108 8eec9944 00000000 00000000
[ 72.858682] 80508f10 80510000 00000001 80567d20 8ee615a0 00000000 00000000 8ee61c00
[ 72.875308] 8ee61c40 00000040 80610000 80580000 00000000 8ee615dc 8ee61a68 00000001
[ 72.891936] ...
[ 72.896793] Call Trace:
[ 72.901649] [<8eec4240>] mt7615_mac_fill_rx+0xac/0x494 [mt7615e]
[ 72.913602] [<8eec09b0>] mt7615_queue_rx_skb+0xe4/0x12c [mt7615e]
[ 72.925734] [<8eec9944>] mt76_dma_cleanup+0x390/0x42c [mt76]
[ 72.936988] Code: ae020018 8ea20004 24030001 <94420004> a602002a 8ea20004 90420000 14430003 a2020034
[ 72.956390]
[ 72.959676] ---[ end trace f176967739edb19f ]---
Fixes: 04b8e65922f6 ("mt76: add mac80211 driver for MT7615 PCIe-based chipsets")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt7615/mac.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
index 1d6ebea17132..1547bce561d3 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
@@ -73,6 +73,9 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct sk_buff *skb)
bool unicast, remove_pad, insert_ccmp_hdr = false;
int i, idx;
+ if (!test_bit(MT76_STATE_RUNNING, &dev->mt76.state))
+ return -EINVAL;
+
memset(status, 0, sizeof(*status));
unicast = (rxd1 & MT_RXD1_NORMAL_ADDR_TYPE) == MT_RXD1_NORMAL_U2M;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] NFC: Orphan the subsystem
From: Andy Shevchenko @ 2019-05-14 10:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev, Samuel Ortiz
In-Reply-To: <20190514090231.32414-1-johannes@sipsolutions.net>
On Tue, May 14, 2019 at 11:02:31AM +0200, Johannes Berg wrote:
> Samuel clearly hasn't been working on this in many years and
> patches getting to the wireless list are just being ignored
> entirely now. Mark the subsystem as orphan to reflect the
> current state and revert back to the netdev list so at least
> some fixes can be picked up by Dave.
Good to know.
But Samuel was active like year ago and he is still at Intel, right?
Perhaps he can appear last time here to Ack this?
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> MAINTAINERS | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fb9f9d71f7a2..b2659312e9ed 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11028,10 +11028,8 @@ S: Supported
> F: drivers/net/ethernet/qlogic/netxen/
>
> NFC SUBSYSTEM
> -M: Samuel Ortiz <sameo@linux.intel.com>
> -L: linux-wireless@vger.kernel.org
> -L: linux-nfc@lists.01.org (subscribers-only)
> -S: Supported
> +L: netdev@vger.kernel.org
> +S: Orphan
> F: net/nfc/
> F: include/net/nfc/
> F: include/uapi/linux/nfc.h
> --
> 2.17.2
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Andy Shevchenko @ 2019-05-14 10:03 UTC (permalink / raw)
To: Sedat Dilek
Cc: Clément Perrochaud, Charles Gorand, linux-nfc, Samuel Ortiz,
linux-wireless, Oleg Zhurakivskyy
In-Reply-To: <CA+icZUVn9tHQ3Zug0u2scbvGFfrLag_WYdzs9FCBJsGJ4bhuzw@mail.gmail.com>
On Mon, May 13, 2019 at 09:48:15PM +0200, Sedat Dilek wrote:
> On Mon, May 13, 2019 at 12:44 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> Is it possible to have an info in dmesg log when nxp-nci_i2c kernel
> module is loaded?
We have 'initcall_debug' for such purposes.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] NFC: Orphan the subsystem
From: Johannes Berg @ 2019-05-14 10:03 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: linux-wireless, netdev, Samuel Ortiz
In-Reply-To: <20190514100210.GA9224@smile.fi.intel.com>
On Tue, 2019-05-14 at 13:02 +0300, Andy Shevchenko wrote:
> On Tue, May 14, 2019 at 11:02:31AM +0200, Johannes Berg wrote:
> > Samuel clearly hasn't been working on this in many years and
> > patches getting to the wireless list are just being ignored
> > entirely now. Mark the subsystem as orphan to reflect the
> > current state and revert back to the netdev list so at least
> > some fixes can be picked up by Dave.
>
> Good to know.
>
> But Samuel was active like year ago and he is still at Intel, right?
Not AFAICT and yes. I guess you can reach out to him internally, you're
probably closer to him than I am, org-wise? :)
https://patchwork.kernel.org/project/linux-wireless/list/?delegate=sameo
johannes
^ permalink raw reply
* Re: pull request: iwlwifi firmware updates 2019-05-03
From: Josh Boyer @ 2019-05-14 10:54 UTC (permalink / raw)
To: Luca Coelho
Cc: linux-firmware@kernel.org, linux-wireless@vger.kernel.org,
linuxwifi, kyle@infradead.org, ben@decadent.org.uk
In-Reply-To: <76e0ec375091a0b0f16d3cd9b15abc7b1840e89d.camel@coelho.fi>
On Fri, May 3, 2019 at 1:16 PM Luca Coelho <luca@coelho.fi> wrote:
>
> Hi,
>
> This contains some new versions of firmwares for the 9000 series of
> devices and the firmware for a new device, namely 22260.
>
> Please pull or let me know if there are any issues.
>
> --
> Cheers,
> Luca.
>
>
> The following changes since commit 92e17d0dd2437140fab044ae62baf69b35d7d1fa:
>
> amdgpu: update vega20 to the latest 19.10 firmware (2019-05-02 06:24:19 -0400)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git tags/iwlwifi-fw-2019-05-03
>
> for you to fetch changes up to 95a93535b723085ff74845eb8733d01c8ff5c052:
>
> iwlwifi: update -46 firmwares for 22260 and 9000 series (2019-05-03 19:33:53 +0300)
>
> ----------------------------------------------------------------
> updates for -46.ucode for 9260, 9000 and 22260
>
> ----------------------------------------------------------------
> Luca Coelho (3):
> iwlwifi: add -46.ucode firmwares for 9000 series
> iwlwifi: add firmware for 22260 and update 9000 series -46 firmwares
> iwlwifi: update -46 firmwares for 22260 and 9000 series
>
> WHENCE | 9 +++++++++
> iwlwifi-9000-pu-b0-jf-b0-46.ucode | Bin 0 -> 1448644 bytes
> iwlwifi-9260-th-b0-jf-b0-46.ucode | Bin 0 -> 1456088 bytes
> iwlwifi-cc-a0-46.ucode | Bin 0 -> 1044072 bytes
> 4 files changed, 9 insertions(+)
> create mode 100644 iwlwifi-9000-pu-b0-jf-b0-46.ucode
> create mode 100644 iwlwifi-9260-th-b0-jf-b0-46.ucode
> create mode 100644 iwlwifi-cc-a0-46.ucode
Pulled and pushed out.
josh
^ permalink raw reply
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Oleg Zhurakivskyy @ 2019-05-14 11:44 UTC (permalink / raw)
To: sedat.dilek, Andy Shevchenko
Cc: Clément Perrochaud, Charles Gorand, linux-nfc, Samuel Ortiz,
linux-wireless
In-Reply-To: <CA+icZUUA8TfU--6b+RwXMf=ui7ww0DK=EurzdMeDUkGvwcJ_rg@mail.gmail.com>
On 5/14/19 11:34 AM, Sedat Dilek wrote:
> Am I correct that "NPC100" is "PN547" and "NPC300" is "PN548"?
Yes, NPC100 is PN547.
Don’t know on NPC300, but a quick web search reveals it’s PN548.
Might it make sense to drop NPC... and to keep just the chip names in Kconfig?
Regards,
Oleg
^ permalink raw reply
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Sedat Dilek @ 2019-05-14 12:03 UTC (permalink / raw)
To: Oleg Zhurakivskyy
Cc: Andy Shevchenko, Clément Perrochaud, Charles Gorand,
linux-nfc, Samuel Ortiz, linux-wireless
In-Reply-To: <2d39b39b-27eb-abef-747f-400433daefee@intel.com>
On Tue, May 14, 2019 at 1:45 PM Oleg Zhurakivskyy
<oleg.zhurakivskyy@intel.com> wrote:
>
>
> On 5/14/19 11:34 AM, Sedat Dilek wrote:
>
> > Am I correct that "NPC100" is "PN547" and "NPC300" is "PN548"?
>
> Yes, NPC100 is PN547.
>
> Don’t know on NPC300, but a quick web search reveals it’s PN548.
>
> Might it make sense to drop NPC... and to keep just the chip names in Kconfig?
>
Thanks for the clarification.
I found NXP NPC300 windows driver from Lenovo's support website - not
on the support websites for ThinkPad T470 but for other ThinkPads like
T480.
It's the same driver and by accident I could update via Microsoft
device-manager to version 12.0.4.0.
So if you search in the Wild Wild Web for a Linux driver and have the
information "NXP NPC300", you will find it.
It's good to keep both informations - preferable put them into the
Kconfig help text?
- Sedat -
^ permalink raw reply
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Sedat Dilek @ 2019-05-14 12:12 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Clément Perrochaud, Charles Gorand, linux-nfc, Samuel Ortiz,
linux-wireless, Oleg Zhurakivskyy
In-Reply-To: <20190514100328.GB9224@smile.fi.intel.com>
On Tue, May 14, 2019 at 12:03 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, May 13, 2019 at 09:48:15PM +0200, Sedat Dilek wrote:
> > On Mon, May 13, 2019 at 12:44 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
>
> > Is it possible to have an info in dmesg log when nxp-nci_i2c kernel
> > module is loaded?
>
> We have 'initcall_debug' for such purposes.
>
Thanks.
That's nice for retrieving helpful informations, especially the proble
line (see below).
Unload nxp_nci_i2c module...
[ 277.362813] NET: Unregistered protocol family 39
...and reload nxp_nci_i2c module...
[ 291.640491] calling nfc_init+0x0/0x8e [nfc] @ 2998
[ 291.640499] nfc: nfc_init: NFC Core ver 0.1
[ 291.640603] NET: Registered protocol family 39
[ 291.640651] initcall nfc_init+0x0/0x8e [nfc] returned 0 after 111 usecs
[ 291.653179] calling nxp_nci_i2c_driver_init+0x0/0x1000 [nxp_nci_i2c] @ 2998
[ 291.669584] probe of i2c-NXP1001:00 returned 1 after 16364 usecs
[ 291.669841] initcall nxp_nci_i2c_driver_init+0x0/0x1000
[nxp_nci_i2c] returned 0 after 16244 usecs
What I mean is (here: btrfs and vboxdrv built as modules)...
[ 21.285569] Btrfs loaded, crc32c=crc32c-intel
[ 28.823902] vboxdrv: Successfully loaded version 6.0.6_Debian
(interface 0x00290008)
- Sedat -
^ permalink raw reply
* [PATCH] mt76: mt7615: stop mcu first in mt7615_unregister_device
From: Lorenzo Bianconi @ 2019-05-14 12:20 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
In-Reply-To: <cover.1557836235.git.lorenzo@kernel.org>
Stop mcu engine and then dma one in mt7615_unregister_device
in order to avoid a mcu hang in mt7615_unregister_device
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
This patch ca be squashed with 'mt76: mt7615: rearrange cleanup operations in
mt7615_unregister_device' since it is not upstream yet
---
drivers/net/wireless/mediatek/mt76/mt7615/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index 59f604f3161f..369b9a8e07be 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -213,8 +213,8 @@ void mt7615_unregister_device(struct mt7615_dev *dev)
int id;
mt76_unregister_device(&dev->mt76);
- mt7615_dma_cleanup(dev);
mt7615_mcu_exit(dev);
+ mt7615_dma_cleanup(dev);
spin_lock_bh(&dev->token_lock);
idr_for_each_entry(&dev->token, txwi, id) {
--
2.20.1
^ permalink raw reply related
* [PATCH] rtlwifi: Fix null-pointer dereferences in error handling code of rtl_pci_probe()
From: Jia-Ju Bai @ 2019-05-14 12:34 UTC (permalink / raw)
To: pkshih, kvalo, davem; +Cc: linux-wireless, netdev, linux-kernel, Jia-Ju Bai
*BUG 1:
In rtl_pci_probe(), when rtlpriv->cfg->ops->init_sw_vars() fails,
rtl_deinit_core() in the error handling code is executed.
rtl_deinit_core() calls rtl_free_entries_from_scan_list(), which uses
rtlpriv->scan_list.list in list_for_each_entry_safe(), but it has been
initialized. Thus a null-pointer dereference occurs.
The reason is that rtlpriv->scan_list.list is initialized by
INIT_LIST_HEAD() in rtl_init_core(), which has not been called.
To fix this bug, rtl_deinit_core() should not be called when
rtlpriv->cfg->ops->init_sw_vars() fails.
*BUG 2:
In rtl_pci_probe(), rtl_init_core() can fail when rtl_regd_init() in
this function fails, and rtlpriv->scan_list.list has not been
initialized by INIT_LIST_HEAD(). Then, rtl_deinit_core() in the error
handling code of rtl_pci_probe() is executed. Finally, a null-pointer
dereference occurs due to the same reason of the above bug.
To fix this bug, the initialization of lists in rtl_init_core() are
performed before the call to rtl_regd_init().
These bugs are found by a runtime fuzzing tool named FIZZER written by
us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/net/wireless/realtek/rtlwifi/base.c | 15 ++++++++-------
drivers/net/wireless/realtek/rtlwifi/pci.c | 4 ++--
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c b/drivers/net/wireless/realtek/rtlwifi/base.c
index 217d2a7a43c7..b3f341ec3710 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -526,8 +526,14 @@ int rtl_init_core(struct ieee80211_hw *hw)
/* <2> rate control register */
hw->rate_control_algorithm = "rtl_rc";
+ /* <3> init list */
+ INIT_LIST_HEAD(&rtlpriv->entry_list);
+ INIT_LIST_HEAD(&rtlpriv->scan_list.list);
+ skb_queue_head_init(&rtlpriv->tx_report.queue);
+ skb_queue_head_init(&rtlpriv->c2hcmd_queue);
+
/*
- * <3> init CRDA must come after init
+ * <4> init CRDA must come after init
* mac80211 hw in _rtl_init_mac80211.
*/
if (rtl_regd_init(hw, rtl_reg_notifier)) {
@@ -535,7 +541,7 @@ int rtl_init_core(struct ieee80211_hw *hw)
return 1;
}
- /* <4> locks */
+ /* <5> locks */
mutex_init(&rtlpriv->locks.conf_mutex);
mutex_init(&rtlpriv->locks.ips_mutex);
mutex_init(&rtlpriv->locks.lps_mutex);
@@ -550,11 +556,6 @@ int rtl_init_core(struct ieee80211_hw *hw)
spin_lock_init(&rtlpriv->locks.cck_and_rw_pagea_lock);
spin_lock_init(&rtlpriv->locks.fw_ps_lock);
spin_lock_init(&rtlpriv->locks.iqk_lock);
- /* <5> init list */
- INIT_LIST_HEAD(&rtlpriv->entry_list);
- INIT_LIST_HEAD(&rtlpriv->scan_list.list);
- skb_queue_head_init(&rtlpriv->tx_report.queue);
- skb_queue_head_init(&rtlpriv->c2hcmd_queue);
rtlmac->link_state = MAC80211_NOLINK;
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 48ca52102cef..864cb76230c4 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -2267,7 +2267,7 @@ int rtl_pci_probe(struct pci_dev *pdev,
if (rtlpriv->cfg->ops->init_sw_vars(hw)) {
pr_err("Can't init_sw_vars\n");
err = -ENODEV;
- goto fail3;
+ goto fail2;
}
rtlpriv->cfg->ops->init_sw_leds(hw);
--
2.17.0
^ permalink raw reply related
* [PATCH] mt76: move mt76_insert_ccmp_hdr in mt76-module
From: Lorenzo Bianconi @ 2019-05-14 12:48 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
In-Reply-To: <cover.1557838049.git.lorenzo@kernel.org>
Move mt7615_insert_ccmp_hdr in mac80211.c and rename it in
mt76_insert_ccmp_hdr since it is shared between mt7603 and mt7615
drivers
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mac80211.c | 23 ++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt76.h | 1 +
.../net/wireless/mediatek/mt76/mt7603/mac.c | 26 +------------------
.../net/wireless/mediatek/mt76/mt7615/mac.c | 25 +-----------------
4 files changed, 26 insertions(+), 49 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 5b6a81ee457e..e70507a4b14d 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -820,3 +820,26 @@ mt76_set_tim(struct ieee80211_hw *hw, struct ieee80211_sta *sta, bool set)
return 0;
}
EXPORT_SYMBOL_GPL(mt76_set_tim);
+
+void mt76_insert_ccmp_hdr(struct sk_buff *skb, u8 key_id)
+{
+ struct mt76_rx_status *status = (struct mt76_rx_status *)skb->cb;
+ int hdr_len = ieee80211_get_hdrlen_from_skb(skb);
+ u8 *hdr, *pn = status->iv;
+
+ __skb_push(skb, 8);
+ memmove(skb->data, skb->data + 8, hdr_len);
+ hdr = skb->data + hdr_len;
+
+ hdr[0] = pn[5];
+ hdr[1] = pn[4];
+ hdr[2] = 0;
+ hdr[3] = 0x20 | (key_id << 6);
+ hdr[4] = pn[3];
+ hdr[5] = pn[2];
+ hdr[6] = pn[1];
+ hdr[7] = pn[0];
+
+ status->flag &= ~RX_FLAG_IV_STRIPPED;
+}
+EXPORT_SYMBOL_GPL(mt76_insert_ccmp_hdr);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index fc4169c83e76..8edf476f9f2f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -750,6 +750,7 @@ void mt76_csa_check(struct mt76_dev *dev);
void mt76_csa_finish(struct mt76_dev *dev);
int mt76_set_tim(struct ieee80211_hw *hw, struct ieee80211_sta *sta, bool set);
+void mt76_insert_ccmp_hdr(struct sk_buff *skb, u8 key_id);
/* internal */
void mt76_tx_free(struct mt76_dev *dev);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/mac.c b/drivers/net/wireless/mediatek/mt76/mt7603/mac.c
index 0ccba5926b68..5c09b2dbf3fd 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/mac.c
@@ -418,30 +418,6 @@ mt7603_rx_get_wcid(struct mt7603_dev *dev, u8 idx, bool unicast)
return &sta->vif->sta.wcid;
}
-static void
-mt7603_insert_ccmp_hdr(struct sk_buff *skb, u8 key_id)
-{
- struct mt76_rx_status *status = (struct mt76_rx_status *)skb->cb;
- int hdr_len = ieee80211_get_hdrlen_from_skb(skb);
- u8 *pn = status->iv;
- u8 *hdr;
-
- __skb_push(skb, 8);
- memmove(skb->data, skb->data + 8, hdr_len);
- hdr = skb->data + hdr_len;
-
- hdr[0] = pn[5];
- hdr[1] = pn[4];
- hdr[2] = 0;
- hdr[3] = 0x20 | (key_id << 6);
- hdr[4] = pn[3];
- hdr[5] = pn[2];
- hdr[6] = pn[1];
- hdr[7] = pn[0];
-
- status->flag &= ~RX_FLAG_IV_STRIPPED;
-}
-
int
mt7603_mac_fill_rx(struct mt7603_dev *dev, struct sk_buff *skb)
{
@@ -580,7 +556,7 @@ mt7603_mac_fill_rx(struct mt7603_dev *dev, struct sk_buff *skb)
if (insert_ccmp_hdr) {
u8 key_id = FIELD_GET(MT_RXD1_NORMAL_KEY_ID, rxd1);
- mt7603_insert_ccmp_hdr(skb, key_id);
+ mt76_insert_ccmp_hdr(skb, key_id);
}
hdr = (struct ieee80211_hdr *)skb->data;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
index b8f48d10f27a..1d6ebea17132 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
@@ -61,29 +61,6 @@ static int mt7615_get_rate(struct mt7615_dev *dev,
return 0;
}
-static void mt7615_insert_ccmp_hdr(struct sk_buff *skb, u8 key_id)
-{
- struct mt76_rx_status *status = (struct mt76_rx_status *)skb->cb;
- int hdr_len = ieee80211_get_hdrlen_from_skb(skb);
- u8 *pn = status->iv;
- u8 *hdr;
-
- __skb_push(skb, 8);
- memmove(skb->data, skb->data + 8, hdr_len);
- hdr = skb->data + hdr_len;
-
- hdr[0] = pn[5];
- hdr[1] = pn[4];
- hdr[2] = 0;
- hdr[3] = 0x20 | (key_id << 6);
- hdr[4] = pn[3];
- hdr[5] = pn[2];
- hdr[6] = pn[1];
- hdr[7] = pn[0];
-
- status->flag &= ~RX_FLAG_IV_STRIPPED;
-}
-
int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct sk_buff *skb)
{
struct mt76_rx_status *status = (struct mt76_rx_status *)skb->cb;
@@ -225,7 +202,7 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct sk_buff *skb)
if (insert_ccmp_hdr) {
u8 key_id = FIELD_GET(MT_RXD1_NORMAL_KEY_ID, rxd1);
- mt7615_insert_ccmp_hdr(skb, key_id);
+ mt76_insert_ccmp_hdr(skb, key_id);
}
hdr = (struct ieee80211_hdr *)skb->data;
--
2.20.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