Create a constant array with the values of the "phy->signal" for every
rate. Remove all "phy->signal" assignments inside the switch statement
and replace these with a single reading from the new vnt_phy_signal
array.
The constant array can be of one dimension because the OR mask with
BIT(3) or BIT(4) allow obtain a second value according to the rate,
the preamble_type and the pkt_type.
Signed-off-by: Oscar Carter <oscar.carter@gmx.com>
Link: https://lore.kernel.org/r/20200414153849.5785-5-oscar.carter@gmx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use the error code returned by the vnt_control_out function as the
returned value of the vnt_rf_write_embedded function instead of a
boolean value.
Then, fix all vnt_rf_write_embedded calls removing the "and" operations
and replace with a direct assignment to the ret variable and add a check
condition after every call.
Also replace the boolean values true or false in the vnt_rf_set_txpower
function to 0 or error code EINVAL to follow the coding style guide.
The vnt_rf_set_txpower function is called only in the vnt_rf_setpower
function that already returns error codes. The calls to this function
(vnt_rf_set_txpower) not use the returned values, so they not need to be
fixed.
Signed-off-by: Oscar Carter <oscar.carter@gmx.com>
Link: https://lore.kernel.org/r/20200414153849.5785-2-oscar.carter@gmx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently, wfx_update_filtering() apply the value of wvif->filter_mcast
to the hardware. But an attentive reader will note that
wfx_update_filtering() is always called after set wvif->filter_mcast.
Thus, it not necessary to store filter_mcast in the struct wfx_vif. We
can just pass it as parameter.
Also rename wfx_update_filtering() in wfx_filter_mcast() to reflect this
change.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200415161147.69738-20-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently, wfx_update_filtering() is sometime called only to apply the
value of wvif->filter_beacon to the hardware. It is nicer to have a
specific function for beacon filtering.
In add, an attentive reader would note that wfx_update_filtering() is
always called after change of wvif->filter_beacon. Thus, it not
necessary to store filter_beacon in the struct wfx_vif. We can just pass
it as parameter.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200415161147.69738-18-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Device is able to automatically reply to probe request (therefore, the
probe requests are not forwarded to host). This feature is enabled by
wfx_start_ap(). However, further calls to wfx_configure_filter() can
disable it.
So, relocate the handling of probe request filtering in
wfx_configure_filter().
Note that wfx_configure_filter() is always called by mac80211 when an AP
start.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200415161147.69738-11-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When the device joins an AP, beacon are forwarded to the host. Once has
retrieved all necessary parameters, we can start to filter the beacon
(and only beacon with changed/new data will be forwarded).
Currently, the driver detect beacons in data Rx process. It is far more
easier to just wait for the BSS_CHANGED_BEACON_INFO event.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200415161147.69738-5-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently, filtering are not update if the device is not connected.
There is no obvious rationale for that. Updating filtering while it is
not necessary is harmless. On the other hand, it is difficult to ensure
that the filtering rule has been correctly sent to the firmware.
Just drop this useless condition.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20200415161147.69738-2-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Four tables can be extracted from RSPINF_A_* based on BB_TYPE_11A or
else being GB rates.
Preamble short or long tables from fixed size len of 14 for RSPINF_B rates.
Remove function vnt_calculate_ofdm_rate and replace with the tables
calling RSPINF_A and RSPINF_B separately.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Link: https://lore.kernel.org/r/addca9e1-9ea2-59ee-dec9-3afb3c731c2e@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
MT7621 has three assigned interrupts for the pcie. This
interrupts should properly being mapped taking into account
which devices are finally connected in which bus according
to link status. So the irq mappings should be as follows
according to link status (three bits indicating which devices
are link up):
* For PCIe Bus 1 slot 0:
- status = 0x2 || status = 0x6 => IRQ = pcie1_irq (24).
- status = 0x4 => IRQ = pcie2_irq (25).
- default => IRQ = pcie0_irq (23).
* For PCIe Bus 2 slot 0:
- status = 0x5 || status = 0x6 => IRQ = pcie2_irq (25).
- default => IRQ = pcie1_irq (24).
* For PCIe Bus 2 slot 1:
- status = 0x5 || status = 0x6 => IRQ = pcie2_irq (25).
- default => IRQ = pcie1_irq (24).
* For PCIe Bus 3 any slot:
- default => IRQ = pcie2_irq (25).
Because of this, the function 'of_irq_parse_and_map_pci' cannot
be used and we need to change device tree information from using
the 'interrupt-map' and 'interrupt-map-mask' properties into an
'interrupts' property to be able to get irq information from the
ports using the 'platform_get_irq' and storing an 'irq-map' into
the pcie driver data node to properly map correct irq using a
new 'mt7621_map_irq' function where this map will be read and the
correct irq returned.
Fixes: 46d093124d ("staging: mt7621-pci: improve interrupt mapping")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200413055942.2714-1-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pcie phy for pcie0 and pcie1 is shared using a dual ported
one. Current code was assuming that if nothing is connected
in pcie0 it won't be also nothing connected in pcie1. This
assumtion is wrong for some devices such us 'Mikrotik rbm33g'
and 'ZyXEL LTE3301-PLUS' where only connecting a card to the
second bus on the phy is possible. For such devices kernel
hangs in the same point because of the wrong poweroff of the
phy getting the following trace:
mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual port = 1)
mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual port = 0)
mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz
mt7621-pci 1e140000.pcie: pcie0 no card, disable it (RST & CLK)
[hangs]
The wrong assumption is located in the 'mt7621_pcie_init_ports'
function where we are just making a power off of the phy for
slots 0 and 2 if nothing is connected in them. Hence, only
poweroff the phy if nothing is connected in both slot 0 and
slot 1 avoiding the kernel to hang.
Fixes: 5737cfe87a ("staging: mt7621-pci: avoid to poweroff the phy for slot one")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200409111652.30964-1-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
