aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2021-09-28ipw2200: Fix a function name in print messagesCai Huoqing1-1/+1
Use dma_alloc_coherent() instead of pci_alloc_consistent(), because only dma_alloc_coherent() is called here. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210925124621.197-1-caihuoqing@baidu.com
2021-09-24rtw88: 8821c: correct 2.4G tx power for type 2/4 NICGuo-Feng Fan1-0/+3
NIC card saves calibrated TX power index in the efuse(ROM). Driver loads TX power idex when interface is up. The problem is type2/4 NICs loads 2.4G TX power index from wrong position. This patch corrects the offsets. So, driver loads real 2.4G TX power index for type 2/4 NICs. 2.4G performance increased when using correct TX power index. Signed-off-by: Guo-Feng Fan <vincent_fann@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210922023637.9357-2-pkshih@realtek.com
2021-09-24rtw88: 8821c: support RFE type4 wifi NICGuo-Feng Fan1-1/+12
RFE type4 is a new NIC which has one RF antenna shares with BT. RFE type4 HW is the same as RFE type2 but attaching antenna to aux antenna connector. RFE type2 attach antenna to main antenna connector. Load the same parameter as RFE type2 when initializing NIC. Signed-off-by: Guo-Feng Fan <vincent_fann@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210922023637.9357-1-pkshih@realtek.com
2021-09-24brcmfmac: Replace zero-length array with flexible array memberLen Baker2-2/+2
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use "flexible array members"[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Also, make use of the struct_size() helper in devm_kzalloc(). [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.14/process/deprecated.html#zero-length-and-one-element-arrays Signed-off-by: Len Baker <len.baker@gmx.com> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210904092217.2848-1-len.baker@gmx.com
2021-09-21rt2x00: remove duplicate USB device IDKrzysztof Kozlowski1-1/+0
The device 0x043e,0x7a32 is already on the list under CONFIG_RT2800USB_RT55XX. Since it is the sole Arcadyan entry in RT55xx, assume the proper chip is RT55xx, not RT53xx, although this was not confirmed by testing or 3rd party sources. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210917092108.19497-3-krzysztof.kozlowski@canonical.com
2021-09-21ar5512: remove duplicate USB device IDKrzysztof Kozlowski1-2/+1
The device 0x157e,0x3006 is already on the list. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210917092108.19497-2-krzysztof.kozlowski@canonical.com
2021-09-21zd1211rw: remove duplicate USB device IDKrzysztof Kozlowski1-1/+0
The device 0x07b8,0x6001 is already on the list as zd1211 chip. Wiki https://wireless.wiki.kernel.org/en/users/Drivers/zd1211rw/devices confirms it is also zd1211, not the zd1211b. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210917092108.19497-1-krzysztof.kozlowski@canonical.com
2021-09-21wilc1000: increase config packets response wait timeout limitAjay Singh1-1/+1
Increase the WID config packet response timeout to have extra wait time for host to receive the response message from firmware. Sometimes the WID config response was timed out because of host interrupt latency. Signed-off-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210916164902.74629-12-ajay.kathat@microchip.com
2021-09-21wilc1000: use correct write command sequence in wilc_spi_sync_ext()Ajay Singh1-1/+1
Instead of using double read for the same register, use the write register command after the read command. The correct sequence is to use the read value in write command instead of reading the same register again. Signed-off-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210916164902.74629-11-ajay.kathat@microchip.com
2021-09-21wilc1000: add 'initialized' flag check before adding an element to TX queueAjay Singh2-0/+13
Add 'initialized' variable check before adding net/mgmt packet to TX queue as safety check before passing the commands to the firmware. Signed-off-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210916164902.74629-10-ajay.kathat@microchip.com
2021-09-21wilc1000: invoke chip reset register before firmware downloadAjay Singh1-3/+19
Add the chip reset command to initialize the WILC chip before downloading the firmware. Also, put the chip in wake-up mode so it is ready to receive the firmware binary from the host. Signed-off-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210916164902.74629-9-ajay.kathat@microchip.com
2021-09-21wilc1000: ignore clockless registers status response for SPIAjay Singh1-4/+8
During WILC chip wake-up sequence, the clockless status register sometimes reports failure even when the actual status is successful. So, for the clockless register, remove the incorrect error status reporting during the read and write command API's. Signed-off-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210916164902.74629-8-ajay.kathat@microchip.com
2021-09-21wilc1000: handle read failure issue for clockless registersAjay Singh4-0/+23
For SPI bus, the register read fails after read/write to the clockless register during chip wakeup sequence. Add workaround to send CMD_RESET command during chip wake-up sequence to overcome the issue. Signed-off-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210916164902.74629-7-ajay.kathat@microchip.com
2021-09-21wilc1000: add reset/terminate/repeat command support for SPI busAjay Singh1-0/+61
Add reset/terminate/repeat command for SPI module. In case of SPI commands failure, the host should issue a RESET command to WILC chip to recover from any temporary bus error. For now, the new command support is added and later the SPI read/write API's would be modified to make use of these commands for retry mechanism Signed-off-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210916164902.74629-6-ajay.kathat@microchip.com
2021-09-21wilc1000: configure registers to handle chip wakeup sequenceAjay Singh5-55/+53
Use the correct sequence to configure clockless registers for chip wake-up. The following sequence is expected from WILC chip for wakeup: - set wakeup bit in wakeup_reg register - after setting the wakeup bit, read back the clock status bit for wakeup complete. For SDIO/SPI modules, the wakeup sequence is the same except uses different register values so refactored the code to use common function for both SDIO/SPI bus. Signed-off-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210916164902.74629-5-ajay.kathat@microchip.com
2021-09-21wilc1000: add new WID to pass wake_enable information to firmwareAjay Singh5-0/+28
Add new WID(WID_WOWLAN_TRIGGER) to send wake_enable information to firmware. In 'set_wakeup' cfg80211_ops callback, the enable information was not passed to firmware which is required to handle WOWLan trigger notification from firmware. Signed-off-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210916164902.74629-4-ajay.kathat@microchip.com
2021-09-21wilc1000: fix possible memory leak in cfg_scan_result()Ajay Singh1-2/+1
When the BSS reference holds a valid reference, it is not freed. The 'if' condition is wrong. Instead of the 'if (bss)' check, the 'if (!bss)' check is used. The issue is solved by removing the unnecessary 'if' check because cfg80211_put_bss() already performs the NULL validation. Fixes: 6cd4fa5ab691 ("staging: wilc1000: make use of cfg80211_inform_bss_frame()") Signed-off-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210916164902.74629-3-ajay.kathat@microchip.com
2021-09-21wilc1000: move 'deinit_lock' lock init/destroy inside module probeAjay Singh3-8/+2
Move initialization & deinitialization of 'deinit_lock' mutex lock inside wlan_init_locks() & wlan_deinit_locks() API's respectively alongside other locks. After the movement, the client count variable(client_count) which is used for lock init/deinit is removed. Signed-off-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210916164902.74629-2-ajay.kathat@microchip.com
2021-09-21rsi: Fix module dev_oper_mode parameter descriptionMarek Vasut3-8/+13
The module parameters are missing dev_oper_mode 12, BT classic alone, add it. Moreover, the parameters encode newlines, which ends up being printed malformed e.g. by modinfo, so fix that too. However, the module parameter string is duplicated in both USB and SDIO modules and the dev_oper_mode mode enumeration in those module parameters is a duplicate of macros used by the driver. Furthermore, the enumeration is confusing. So, deduplicate the module parameter string and use __stringify() to encode the correct mode enumeration values into the module parameter string. Finally, replace 'Wi-Fi' with 'Wi-Fi alone' and 'BT' with 'BT classic alone' to clarify what those modes really mean. Fixes: 898b255339310 ("rsi: add module parameter operating mode") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Amitkumar Karwar <amit.karwar@redpinesignals.com> Cc: Angus Ainslie <angus@akkea.ca> Cc: David S. Miller <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: Karun Eagalapati <karun256@gmail.com> Cc: Martin Fuzzey <martin.fuzzey@flowbird.group> Cc: Martin Kepplinger <martink@posteo.de> Cc: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Cc: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Cc: Siva Rebbagondla <siva8118@gmail.com> Cc: netdev@vger.kernel.org Cc: <stable@vger.kernel.org> # 4.17+ Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210916144245.10181-1-marex@denx.de
2021-09-21mwifiex: Fix copy-paste mistake when creating virtual interfaceJonas Dreßler1-1/+1
The BSS priority here for a new P2P_CLIENT device was accidentally set to an enum that's certainly not meant for this. Since MWIFIEX_BSS_ROLE_STA is 0 anyway, we can just set the bss_priority to 0 instead here. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914195909.36035-10-verdre@v0yd.nl
2021-09-21mwifiex: Properly initialize private structure on interface type changesJonas Dreßler1-3/+7
When creating a new virtual interface in mwifiex_add_virtual_intf(), we update our internal driver states like bss_type, bss_priority, bss_role and bss_mode to reflect the mode the firmware will be set to. When switching virtual interface mode using mwifiex_init_new_priv_params() though, we currently only update bss_mode and bss_role. In order for the interface mode switch to actually work, we also need to update bss_type to its proper value, so do that. This fixes a crash of the firmware (because the driver tries to execute commands that are invalid in AP mode) when switching from station mode to AP mode. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914195909.36035-9-verdre@v0yd.nl
2021-09-21mwifiex: Handle interface type changes from AP to STATIONJonas Dreßler1-0/+1
Looks like this case was simply overseen, so handle it, too. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914195909.36035-8-verdre@v0yd.nl
2021-09-21mwifiex: Allow switching interface type from P2P_CLIENT to P2P_GOJonas Dreßler1-0/+36
It's possible to change virtual interface type between P2P_CLIENT and P2P_GO, the card supports that just fine, and it happens for example when using miracast with the miraclecast software. So allow type changes between P2P_CLIENT and P2P_GO and simply call into mwifiex_change_vif_to_p2p(), which handles this just fine. We have to call mwifiex_cfg80211_deinit_p2p() before though to make sure the old p2p mode is properly uninitialized. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914195909.36035-7-verdre@v0yd.nl
2021-09-21mwifiex: Update virtual interface counters right after setting bss_typeJonas Dreßler1-11/+14
In mwifiex_init_new_priv_params() we update our private driver state to reflect the currently selected virtual interface type. Most notably we set the bss_mode to the mode we're going to put the firmware in. Now after we updated the driver state we actually start talking to the firmware and instruct it to set up the new mode. Those commands can and will sometimes fail, in which case we return with an error from mwifiex_change_vif_to_*. We currently update our virtual interface type counters after this return, which means the code is never reached when a firmware error happens and we never update the counters. Since we have updated our bss_mode earlier though, the counters now no longer reflect the actual state of the driver. This will break things on the next virtual interface change, because the virtual interface type we're switching away from didn't get its counter incremented, and we end up decrementing a 0-counter. To fix this, simply update the virtual interface type counters right after updating our driver structures, so that they are always in sync. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914195909.36035-6-verdre@v0yd.nl
2021-09-21mwifiex: Use helper function for counting interface typesJonas Dreßler1-75/+35
Use a small helper function to increment and decrement the counter of the interface types we currently manage. This makes the code that actually changes and sets up the interface type a bit less messy and also helps avoiding mistakes in case someone increments/decrements a counter wrongly. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914195909.36035-5-verdre@v0yd.nl
2021-09-21mwifiex: Run SET_BSS_MODE when changing from P2P to STATION vif-typeJonas Dreßler1-18/+4
We currently handle changing from the P2P to the STATION virtual interface type slightly different than changing from P2P to ADHOC: When changing to STATION, we don't send the SET_BSS_MODE command. We do send that command on all other type-changes though, and it probably makes sense to send the command since after all we just changed our BSS_MODE. Looking at prior changes to this part of the code, it seems that this is simply a leftover from old refactorings. Since sending the SET_BSS_MODE command is the only difference between mwifiex_change_vif_to_sta_adhoc() and the current code, we can now use mwifiex_change_vif_to_sta_adhoc() for both switching to ADHOC and STATION interface type. This does not fix any particular bug and just "looked right", so there's a small chance it might be a regression. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914195909.36035-4-verdre@v0yd.nl
2021-09-21mwifiex: Use function to check whether interface type change is allowedJonas Dreßler1-47/+92
Instead of bailing out in the function which is supposed to do the type change, detect invalid changes beforehand using a generic function and return an error if the change is not allowed. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914195909.36035-3-verdre@v0yd.nl
2021-09-21mwifiex: Small cleanup for handling virtual interface type changesJonas Dreßler1-25/+14
Handle the obvious invalid virtual interface type changes with a general check instead of looking at the individual change. For type changes from P2P_CLIENT to P2P_GO and the other way round, this changes the behavior slightly: We now still do nothing, but return -EOPNOTSUPP instead of 0. Now that behavior was incorrect before and still is, because type changes between these two types are actually possible and supported, which we'll fix in a following commit. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210914195909.36035-2-verdre@v0yd.nl
2021-09-21rtw88: move adaptivity mechanism to firmwareChin-Yen Lee5-1/+80
Current adaptivity mechanism is achieved in driver, by periodically referencing the IGI value and then updating related registers. But we find that this way may halt TX activity too long if huge and temporary energy is detected frequently. So we move the mechanism to firmware for immediately reacting this case to recover TX rapidly. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210830072014.12250-5-pkshih@realtek.com
2021-09-21rtw88: support adaptivity for ETSI/JP DFS regionZong-Zhe Yang11-2/+245
Add Energy Detected CCA (EDCCA) mechanism to detect energy on the channel. And EDCCA support adaptivity mode now. From MIC Ordinance Regulating Radio Equipment article 49.20, ETSI EN-300-328 and EN-301-893, the device should be able to dynamically pause TX activity when energy detected on the air. According to ETSI/JP DFS region, driver will set corresponding threshold and stop TX activity if the detected energy exceeds the threshold. For now, we support it on 8822b and 8822c first. By default, EDCCA mechanism is turned on. For ETSI/JP DFS region, it will turn to adaptivity mode. However, with adaptivity, if environment is too noisy, TX may often be halted. So, a debugfs for EDCCA is added. It can show what EDCCA mode is used currently. And EDCCA mechanism can be turned on/off through the debugfs while debugging. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210830072014.12250-4-pkshih@realtek.com
2021-09-21rtw88: add regulatory strategy by chip typeZong-Zhe Yang4-43/+171
Realtek chips can program a specific country domain on efuse to indicate what is the expected rtw_regulatory. For chips with a programmed country domain, we set REGULATORY_STRICT_REG to tell stack to consider follow-up regulatory_hint() as the superset of our regulatory rule. Besides, on driver side, only the request via NL80211_REGDOM_SET_BY_DRIVER, which matches programmed country domain, will be handled to keep rtw_regulatory unchanged. For worldwide roaming chips, i.e. ones without a specific programmed country domain, system of distro can set expected regulatory via NL80211_REGDOM_SET_BY_USER. With setting from it, rtw_regulatory will handle the requests only via NL80211_REGDOM_SET_BY_USER to follow setting from system of distro. REGULATORY_COUNTRY_IE_IGNORE will then be set to tell stack to ignore country IE for us. The restrictions mentioned above will remain until 00, i.e. worldwide, is set via NL80211_REGDOM_SET_BY_USER. On the other hand, for worldwide roamin chips, if there is no specific regulatory set via NL80211_REGDOM_SET_BY_USER, requests from all regulatory notifications will be handled by rtw_regulatory. And REGULATORY_COUNTRY_IE_IGNORE won't be set. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210830072014.12250-3-pkshih@realtek.com
2021-09-21rtw88: upgrade rtw_regulatory mechanism and mappingZong-Zhe Yang7-295/+371
Mapping table from country code to rtw_regulatory, which manages tx power limit according to countries, is updated. And mapping architecture is also upgraded. For more precise control on tx power limit, it allows different rtw_regulatory for different bands logically. Besides, a helper function to query rtw_regulatory for current band under current country is provided. For older chips, some newly added rtw_regulatory may not be configured. To avoid that those chips have no limit on some countries mapping to a newer rtw_regulatory after table update, a backward selection mechanism of rtw_regulatory is introduced. It can help chips use a rtw_regulatory which has been configured as an alternative of a newer one which is not configured. In addition, rtw88 actually doesn't manage channel plans by itself. Instead, it follows them from stack. So, correct some naming about chplan with regd, and remove the unnecessary channel control for now. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210830072014.12250-2-pkshih@realtek.com
2021-09-21brcmfmac: fix incorrect error printsJames Prestwood1-6/+6
An unsupported AKM would end up printing "invalid cipher group". Instead print "invalid akm suite" with the offending AKM. Signed-off-by: James Prestwood <prestwoj@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210901190641.255624-1-prestwoj@gmail.com
2021-09-21rsi: fix rate mask set leading to P2P failureMartin Fuzzey4-65/+50
P2P client mode was only working the first time. On subsequent connection attempts the group was successfully created but no data was sent (no transmitted data packets were seen with a sniffer). The reason for this was that the hardware was being configured in fixed rate mode with rate RSI_RATE_1 (1Mbps) which is not valid in the 5GHz band. In P2P mode wpa_supplicant uses NL80211_CMD_SET_TX_BITRATE_MASK to disallow the 11b rates in the 2.4GHz band which updated common->fixedrate_mask. rsi_set_min_rate() then used the fixedrate_mask to calculate the minimum allowed rate, or 0xffff = auto if none was found. However that calculation did not account for the different rate sets allowed in the different bands leading to the error. Fixing set_min_rate() would result in 6Mb/s being used all the time which is not what we want either. The reason the problem did not occur on the first connection is that rsi_mac80211_set_rate_mask() only updated the fixedrate_mask for the *current* band. When it was called that was still 2.4GHz as the switch is done later. So the when set_min_rate() was subsequently called after the switch to 5GHz it still had a mask of zero, leading to defaulting to auto mode. Fix this by differentiating the case of a single rate being requested, in which case the hardware will be used in fixed rate mode with just that rate, and multiple rates being requested, in which case we remain in auto mode but the firmware rate selection algorithm is configured with a restricted set of rates. Fixes: dad0d04fa7ba ("rsi: Add RS9113 wireless driver") Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group> CC: stable@vger.kernel.org Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1630337206-12410-4-git-send-email-martin.fuzzey@flowbird.group
2021-09-21rsi: fix key enabled check causing unwanted encryption for vap_id > 0Martin Fuzzey3-1/+4
My previous patch checked if encryption should be enabled by directly checking info->control.hw_key (like the downstream driver). However that missed that the control and driver_info members of struct ieee80211_tx_info are union fields. Due to this when rsi_core_xmit() updates fields in "tx_params" (driver_info) it can overwrite the control.hw_key, causing the result of the later test to be incorrect. With the current structure layout the first byte of control.hw_key is overlayed with the vap_id so, since we only test if control.hw_key is NULL / non NULL, a non zero vap_id will incorrectly enable encryption. In basic STA and AP modes the vap_id is always zero so it works but in P2P client mode a second VIF is created causing vap_id to be non zero and hence encryption to be enabled before keys have been set. Fix this by extracting the key presence flag to a new field in the driver private tx_params structure and populating it first. Fixes: 314538041b56 ("rsi: fix AP mode with WPA failure due to encrypted EAPOL") Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group> CC: stable@vger.kernel.org Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1630337206-12410-3-git-send-email-martin.fuzzey@flowbird.group
2021-09-21rsi: fix occasional initialisation failure with BT coexMartin Fuzzey3-3/+18
When BT coexistence is enabled (eg oper mode 13, which is the default) the initialisation on startup sometimes silently fails. In a normal initialisation we see usb 1-1.3: Product: Wireless USB Network Module usb 1-1.3: Manufacturer: Redpine Signals, Inc. usb 1-1.3: SerialNumber: 000000000001 rsi_91x: rsi_probe: Initialized os intf ops rsi_91x: rsi_load_9116_firmware: Loading chunk 0 rsi_91x: rsi_load_9116_firmware: Loading chunk 1 rsi_91x: rsi_load_9116_firmware: Loading chunk 2 rsi_91x: Max Stations Allowed = 1 But sometimes the last log is missing and the wlan net device is not created. Running a userspace loop that resets the hardware via a GPIO shows the problem occurring ~5/100 resets. The problem does not occur in oper mode 1 (wifi only). Adding logs shows that the initialisation state machine requests a MAC reset via rsi_send_reset_mac() but the firmware does not reply, leading to the initialisation sequence being incomplete. Fix this by delaying attaching the BT adapter until the wifi initialisation has completed. With this applied I have done > 300 reset loops with no errors. Fixes: 716b840c7641 ("rsi: handle BT traffic in driver") Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group> CC: stable@vger.kernel.org Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1630337206-12410-2-git-send-email-martin.fuzzey@flowbird.group
2021-09-12Linux 5.15-rc1Linus Torvalds1-2/+2
2021-09-11tools headers UAPI: Update tools's copy of drm.h headersArnaldo Carvalho de Melo1-2/+12
Picking the changes from: 17ce9c61c71cbc0d ("drm: document DRM_IOCTL_MODE_RMFB") Doesn't result in any tooling changes: $ tools/perf/trace/beauty/drm_ioctl.sh > before $ cp include/uapi/drm/drm.h tools/include/uapi/drm/drm.h $ tools/perf/trace/beauty/drm_ioctl.sh > after $ diff -u before after Silencing these perf build warnings: Warning: Kernel ABI header at 'tools/include/uapi/drm/drm.h' differs from latest version at 'include/uapi/drm/drm.h' diff -u tools/include/uapi/drm/drm.h include/uapi/drm/drm.h Cc: Simon Ser <contact@emersion.fr> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-09-11tools headers UAPI: Sync drm/i915_drm.h with the kernel sourcesArnaldo Carvalho de Melo1-81/+417
To pick the changes in: b65a9489730a2494 ("drm/i915/userptr: Probe existence of backing struct pages upon creation") ee242ca704d38699 ("drm/i915/guc: Implement GuC priority management") 81340cf3bddded4f ("drm/i915/uapi: reject set_domain for discrete") 7961c5b60f23dff5 ("drm/i915: Add TTM offset argument to mmap.") aef7b67a79564f6c ("drm/i915/uapi: convert drm_i915_gem_userptr to kernel doc") e7737b67ab46ee0e ("drm/i915/uapi: reject caching ioctls for discrete") 3aa8c57fe25a9247 ("drm/i915/uapi: convert drm_i915_gem_set_domain to kernel doc") 289f5a72009b8f67 ("drm/i915/uapi: convert drm_i915_gem_caching to kernel doc") 4a766ae40ec83301 ("drm/i915: Drop the CONTEXT_CLONE API (v2)") 6ff6d61dd2a943bd ("drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP") fe4751c3d513ff4f ("drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE") 577729533cdc4e37 ("drm/i915: Document the Virtual Engine uAPI") c649432e86ca677d ("drm/i915: Fix busy ioctl commentary") That doesn't result in any changes to tooling as no new ioctl were added (at least not perceived by tools/perf/trace/beauty/drm_ioctl.sh). Addressing this perf build warning: Warning: Kernel ABI header at 'tools/include/uapi/drm/i915_drm.h' differs from latest version at 'include/uapi/drm/i915_drm.h' diff -u tools/include/uapi/drm/i915_drm.h include/uapi/drm/i915_drm.h Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-09-11tools headers UAPI: Sync linux/fs.h with the kernel sourcesArnaldo Carvalho de Melo1-0/+1
To pick the change in: 7957d93bf32bc211 ("block: add ioctl to read the disk sequence number") It adds a new ioctl, but we are still not using that to generate tables for 'perf trace', so no changes in tooling. This silences this perf build warning: Warning: Kernel ABI header at 'tools/include/uapi/linux/fs.h' differs from latest version at 'include/uapi/linux/fs.h' diff -u tools/include/uapi/linux/fs.h include/uapi/linux/fs.h Cc: Jens Axboe <axboe@kernel.dk> Cc: Matteo Croce <mcroce@microsoft.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-09-11tools headers UAPI: Sync linux/in.h copy with the kernel sourcesArnaldo Carvalho de Melo1-10/+32
To pick the changes in: db243b796439c0ca ("net/ipv4/ipv6: Replace one-element arraya with flexible-array members") 2d3e5caf96b9449a ("net/ipv4: Replace one-element array with flexible-array member") That don't result in any change in tooling, the structs changed remains with the same layout. This addresses this build warning: Warning: Kernel ABI header at 'tools/include/uapi/linux/in.h' differs from latest version at 'include/uapi/linux/in.h' diff -u tools/include/uapi/linux/in.h include/uapi/linux/in.h Cc: David S. Miller <davem@davemloft.net> Cc: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-09-11perf tools: Add an option to build without libbfdIan Rogers1-22/+25
Some distributions, like debian, don't link perf with libbfd. Add a build flag to make this configuration buildable and testable. This was inspired by: https://lore.kernel.org/linux-perf-users/20210910102307.2055484-1-tonyg@leastfixedpoint.com/T/#u Signed-off-by: Ian Rogers <irogers@google.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: tony garnock-jones <tonyg@leastfixedpoint.com> Link: http://lore.kernel.org/lkml/20210910225756.729087-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-09-11perf tools: Allow build-id with trailing zerosNamhyung Kim1-0/+10
Currently perf saves a build-id with size but old versions assumes the size of 20. In case the build-id is less than 20 (like for MD5), it'd fill the rest with 0s. I saw a problem when old version of perf record saved a binary in the build-id cache and new version of perf reads the data. The symbols should be read from the build-id cache (as the path no longer has the same binary) but it failed due to mismatch in the build-id. symsrc__init: build id mismatch for /home/namhyung/.debug/.build-id/53/e4c2f42a4c61a2d632d92a72afa08f00000000/elf. The build-id event in the data has 20 byte build-ids, but it saw a different size (16) when it reads the build-id of the elf file in the build-id cache. $ readelf -n ~/.debug/.build-id/53/e4c2f42a4c61a2d632d92a72afa08f00000000/elf Displaying notes found in: .note.gnu.build-id Owner Data size Description GNU 0x00000010 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID: 53e4c2f42a4c61a2d632d92a72afa08f Let's fix this by allowing trailing zeros if the size is different. Fixes: 39be8d0115b321ed ("perf tools: Pass build_id object to dso__build_id_equal()") Signed-off-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Jiri Olsa <jolsa@redhat.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20210910224630.1084877-1-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-09-11perf tools: Fix hybrid config terms list corruptionAdrian Hunter2-9/+27
A config terms list was spliced twice, resulting in a never-ending loop when the list was traversed. Fix by using list_splice_init() and copying and freeing the lists as necessary. This patch also depends on patch "perf tools: Factor out copy_config_terms() and free_config_terms()" Example on ADL: Before: # perf record -e '{intel_pt//,cycles/aux-sample-size=4096/pp}' uname & # jobs [1]+ Running perf record -e "{intel_pt//,cycles/aux-sample-size=4096/pp}" uname # perf top -E 10 PerfTop: 4071 irqs/sec kernel: 6.9% exact: 100.0% lost: 0/0 drop: 0/0 [4000Hz cycles], (all, 24 CPUs) --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 97.60% perf [.] __evsel__get_config_term 0.25% [kernel] [k] kallsyms_expand_symbol.constprop.13 0.24% perf [.] kallsyms__parse 0.15% [kernel] [k] _raw_spin_lock 0.14% [kernel] [k] number 0.13% [kernel] [k] advance_transaction 0.08% [kernel] [k] format_decode 0.08% perf [.] map__process_kallsym_symbol 0.08% perf [.] rb_insert_color 0.08% [kernel] [k] vsnprintf exiting. # kill %1 After: # perf record -e '{intel_pt//,cycles/aux-sample-size=4096/pp}' uname & Linux [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.060 MB perf.data ] # perf script | head perf-exec 604 [001] 1827.312293: psb: psb offs: 0 ffffffffb8415e87 pt_config_start+0x37 ([kernel.kallsyms]) perf-exec 604 1827.312293: 1 branches: ffffffffb856a3bd event_sched_in.isra.133+0xfd ([kernel.kallsyms]) => ffffffffb856a9a0 perf_pmu_nop_void+0x0 ([kernel.kallsyms]) perf-exec 604 1827.312293: 1 branches: ffffffffb856b10e merge_sched_in+0x26e ([kernel.kallsyms]) => ffffffffb856a2c0 event_sched_in.isra.133+0x0 ([kernel.kallsyms]) perf-exec 604 1827.312293: 1 branches: ffffffffb856a45d event_sched_in.isra.133+0x19d ([kernel.kallsyms]) => ffffffffb8568b80 perf_event_set_state.part.61+0x0 ([kernel.kallsyms]) perf-exec 604 1827.312293: 1 branches: ffffffffb8568b86 perf_event_set_state.part.61+0x6 ([kernel.kallsyms]) => ffffffffb85662a0 perf_event_update_time+0x0 ([kernel.kallsyms]) perf-exec 604 1827.312293: 1 branches: ffffffffb856a35c event_sched_in.isra.133+0x9c ([kernel.kallsyms]) => ffffffffb8567610 perf_log_itrace_start+0x0 ([kernel.kallsyms]) perf-exec 604 1827.312293: 1 branches: ffffffffb856a377 event_sched_in.isra.133+0xb7 ([kernel.kallsyms]) => ffffffffb8403b40 x86_pmu_add+0x0 ([kernel.kallsyms]) perf-exec 604 1827.312293: 1 branches: ffffffffb8403b86 x86_pmu_add+0x46 ([kernel.kallsyms]) => ffffffffb8403940 collect_events+0x0 ([kernel.kallsyms]) perf-exec 604 1827.312293: 1 branches: ffffffffb8403a7b collect_events+0x13b ([kernel.kallsyms]) => ffffffffb8402cd0 collect_event+0x0 ([kernel.kallsyms]) Fixes: 30def61f64bac5 ("perf parse-events Create two hybrid cache events") Fixes: 94da591b1c7913 ("perf parse-events Create two hybrid raw events") Fixes: 9cbfa2f64c04d9 ("perf parse-events Create two hybrid hardware events") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Kan Liang <kan.liang@linux.intel.com> Link: https //lore.kernel.org/r/20210909125508.28693-3-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-09-11perf tools: Factor out copy_config_terms() and free_config_terms()Adrian Hunter3-13/+19
Factor out copy_config_terms() and free_config_terms() so that they can be reused. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Kan Liang <kan.liang@linux.intel.com> Link: https //lore.kernel.org/r/20210909125508.28693-2-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-09-11perf tools: Fix perf_event_attr__fprintf() missing/dupl. fieldsAdrian Hunter1-1/+4
Some fields are missing and text_poke is duplicated. Fix that up. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lore.kernel.org/lkml/20210911120550.12203-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-09-11perf tools: Ignore Documentation dependency fileIan Rogers1-0/+1
When building directly on the checked out repository the build process produces a file that should be ignored, so add it to .gitignore. Fixes: a81df63a5df3e195 ("perf doc: Fix doc.dep") Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ian Rogers <irogers@google.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20210910232249.739661-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-09-10riscv: Move EXCEPTION_TABLE to RO_DATA segmentJisheng Zhang2-3/+2
_ex_table section is read-only, so move it to RO_DATA. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-09-10riscv: Enable BUILDTIME_TABLE_SORTJisheng Zhang2-0/+2
Enable BUILDTIME_TABLE_SORT to sort the exception table at build time rather than during boot. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-09-10riscv: dts: microchip: mpfs-icicle: Fix serial consoleGeert Uytterhoeven1-1/+5
Currently, nothing is output on the serial console, unless "console=ttyS0,115200n8" or "earlycon" are appended to the kernel command line. Enable automatic console selection using chosen/stdout-path by adding a proper alias, and configure the expected serial rate. While at it, add aliases for the other three serial ports, which are provided on the same micro-USB connector as the first one. Fixes: 0fa6107eca4186ad ("RISC-V: Initial DTS for Microchip ICICLE board") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.