Re: [PATCH] brcmsmac: allocate ucode with GFP_KERNEL

On 3/16/2018 4:41 PM, Takashi Iwai wrote: The brcms_ucode_init_buf() duplicates the ucode chunks via kmemdup() with GFP_ATOMIC as a precondition of wl->lock acquired. This caused allocation failures sometimes as reported in the bugzilla below. When looking at the the real usage, one can find

Re: [PATCH] brcmfmac: Add support for getting nvram contents from EFI variables

On 3/14/2018 9:43 AM, Hans de Goede wrote: Hi, On 13-03-18 21:19, Arend van Spriel wrote: On 3/12/2018 10:45 AM, Hans de Goede wrote: Actually had a Sony device with nvram in EFI. Why not just drop this optimization. Ok, do you know if that variable had the same name and guid though ?

[PATCH] ath10k: fix vdev stats for 10.4 firmware

Currently vdev stats displayed in fw_stats are applicable only for TLV based firmware and fix it for 10.4 firmware as of now. The vdev stats in 10.4 firmware is split into two parts (vdev_stats, vdev_stats_extended). The actual stats are captured only in extended vdev stats. In order to enable

[PATCH] brcmsmac: allocate ucode with GFP_KERNEL

The brcms_ucode_init_buf() duplicates the ucode chunks via kmemdup() with GFP_ATOMIC as a precondition of wl->lock acquired. This caused allocation failures sometimes as reported in the bugzilla below. When looking at the the real usage, one can find that it's called solely from

Re: Query on queues in mesh mode

Thanks Thomas. I will try to hack the code and let you know. Best Regards Phani On Thu, Mar 15, 2018 at 5:31 PM, Thomas Pedersen wrote: > On Wed, Mar 7, 2018 at 8:39 AM, Phani Siriki wrote: >> Hi Thomas >> >> Thank you for your reply. >> >> Could you

[PATCH] mt76: enable MAC80211_LEDS by default

Select mac80211 led support by default in order to fix the following compilation error that occurs when CONFIG_LEDS_CLASS/CONFIG_MAC80211_LEDS options are not enabled on the system ERROR: "devm_of_led_classdev_register" undefined! Fixes: 17f1de56df05 ("mt76: add common code shared between

Re: [PATCH 6/6] Update license for brcm firmware

On 03/16/2018 6:17, Arend van Spriel wrote: On 3/16/2018 11:06 AM, Chi-Hsien Lin wrote: Upload a Cypress version of below firmware and hence update the license: brcm/brcmfmac43340-sdio.bin brcm/brcmfmac43362-sdio.bin brcm/brcmfmac43430-sdio.bin brcm/brcmfmac4354-sdio.bin

[PATCH V3 0/5] Update brcm firmware files

Update brcm firmware files and WHENCE accordingly. Chi-Hsien Lin (5): brcm: update firmware for bcm43430 brcm: update firmware for bcm43340 brcm: update firmware for bcm43362 brcm: update firmware for bcm4354 brcm: update firmware for bcm4356 pcie WHENCE | 10

Re: pull-request: iwlwifi 2018-03-16

On Fri, 2018-03-16 at 14:41 +0200, Kalle Valo wrote: > Luca Coelho writes: > > > Here is my third set of fixes for 4.16. More details in the tag > > description. > > > > I have sent this out before and kbuildbot didn't find any issues. > > Please let me know if there are any

Re: [PATCH 4/5] iwlwifi: mvm: fix array out of bounds reference

Hi Kalle, On Fri, 2018-03-16 at 14:38 +0200, Kalle Valo wrote: > Luca Coelho writes: > > > From: Avraham Stern > > > > When starting aggregation, the code checks the status of the queue > > allocated to the aggregation tid, which might not yet be

Re: [V2] brcmfmac: drop Inter-Access Point Protocol packets by default

Rafał Miłecki wrote: > From: Rafał Miłecki > > Testing brcmfmac with more recent firmwares resulted in AP interfaces > not working in some specific setups. Debugging resulted in discovering > support for IAPP in Broadcom's firmwares. > > Older firmwares were only generating

Re: pull-request: iwlwifi 2018-03-16

Luca Coelho writes: > Here is my third set of fixes for 4.16. More details in the tag > description. > > I have sent this out before and kbuildbot didn't find any issues. > Please let me know if there are any issues. > > Cheers, > Luca. > > > The following changes since commit

Re: [PATCH 4/5] iwlwifi: mvm: fix array out of bounds reference

Luca Coelho writes: > From: Avraham Stern > > When starting aggregation, the code checks the status of the queue > allocated to the aggregation tid, which might not yet be allocated > and thus the queue index may be invalid. > Fix this by reserving a new

[PATCH 0/5] iwlwifi: fixes intended for 4.16 2018-03-16

From: Luca Coelho Hi, This is my fourth batch of fixes inteded for 4.16. These are the fixes: * a couple of fixes for channel-switch; * a few fixes for the aggregation handling code; As usual, I'm pushing this to a pending branch, for kbuild bot, and will send a

[PATCH 2/5] iwlwifi: mvm: clear tx queue id when unreserving aggregation queue

From: Avraham Stern When a queue is reserved for aggregation, the queue id is assigned to the tid_data. This is fine since iwl_mvm_sta_tx_agg_oper() takes care of allocating the queue before actual tx starts. When the reservation is cancelled (e.g. when the AP declined

[PATCH 4/5] iwlwifi: mvm: fix array out of bounds reference

From: Avraham Stern When starting aggregation, the code checks the status of the queue allocated to the aggregation tid, which might not yet be allocated and thus the queue index may be invalid. Fix this by reserving a new queue in case the queue id is invalid. While at

[PATCH 1/5] iwlwifi: mvm: Increase session protection time after CS

From: Andrei Otcheretianski After switching to a new channel, driver schedules session protection time event in order to hear the beacon on the new channel. The duration of the protection is two beacon intervals. However, since we start to switch slightly before

[PATCH 5/5] iwlwifi: mvm: Move unused phy's to a default channel

From: Andrei Otcheretianski When immediate quiet bit is set in CSA, the entire channel is blocked by the firmware. It is expected that all the MACs will evacuate the channel and the phy will be eventually either moved or removed. Currently, the phy context is

[PATCH 3/5] iwlwifi: mvm: make sure internal station has a valid id

From: Avraham Stern If the driver failed to resume from D3, it is possible that it has no valid aux station. In such case, fw restart will end up in sending station related commands with an invalid station id, which will result in an assert. Fix this by allocating a new

Re: [PATCH] wcn36xx: dequeue all pending indicator messages

On Friday, March 16, 2018 11:22 AM, Kalle Valo wrote: > Daniel Mack writes: > >> Hi, >> >> On Friday, March 16, 2018 10:09 AM, Ramon Fried wrote: >>> On 3/16/2018 12:37 AM, Daniel Mack wrote: In case wcn36xx_smd_rsp_process() is called more than once before

pull-request: iwlwifi 2018-03-16

Hi Kalle, Here is my third set of fixes for 4.16. More details in the tag description. I have sent this out before and kbuildbot didn't find any issues. Please let me know if there are any issues. Cheers, Luca. The following changes since commit 87de1201ddaa39d4f3fafa9f35ac143e582517e6:

Re: [PATCH] wcn36xx: dequeue all pending indicator messages

Daniel Mack writes: > Hi, > > On Friday, March 16, 2018 10:09 AM, Ramon Fried wrote: >> On 3/16/2018 12:37 AM, Daniel Mack wrote: >>> In case wcn36xx_smd_rsp_process() is called more than once before >>> hal_ind_work was dispatched, the messages will end up in hal_ind_queue,

[PATCH V2 6/6] Update license for brcm firmware

Upload a Cypress version of below firmware and hence update the license: brcm/brcmfmac43340-sdio.bin brcm/brcmfmac43362-sdio.bin brcm/brcmfmac43430-sdio.bin brcm/brcmfmac4354-sdio.bin brcm/brcmfmac4356-pcie.bin Signed-off-by: Chi-Hsien Lin --- WHENCE | 10 +-

[PATCH V2 0/6] Update brcm firmware files

Update brcm firmware files and WHENCE accordingly. Chi-Hsien Lin (6): brcm: update firmware for bcm43340 brcm: update firmware for bcm43362 brcm: update firmware for bcm43430 brcm: update firmware for bcm4354 brcm: update firmware for bcm4356 pcie Update license for brcm firmware

Re: [PATCH 6/6] Update license for brcm firmware

On 3/16/2018 11:06 AM, Chi-Hsien Lin wrote: Upload a Cypress version of below firmware and hence update the license: brcm/brcmfmac43340-sdio.bin brcm/brcmfmac43362-sdio.bin brcm/brcmfmac43430-sdio.bin brcm/brcmfmac4354-sdio.bin brcm/brcmfmac4356-pcie.bin Hi Chi-Hsien, It would be better to

RE: [PATCH 0/6] Update brcm firmware files

The linux-firmware email is wrong for this submission. I'll send another one with the correct address. Sorry for the spam. Regards, Chi-hsien Lin > -Original Message- > From: Chi-Hsien Lin > Sent: 16 March 2018 6:07 > To: linux-firmw...@vger.kernel.org > Cc:

[PATCH 01/12] brcmfmac: do not convert linux error to firmware error string

In case of a linux error brcmf_fil_cmd_data() blurts an error message in which the error code is translated to an error string. However, it maps it to a firmware error string which should not happen. Simply print only the numeric error code and be done with it. Reviewed-by: Hante Meuleman

[PATCH 08/12] brcmfmac: introduce brcmf_fw_alloc_request() function

The function brcmf_fw_alloc_request() takes a list of required files and allocated the struct brcmf_fw_request instance accordingly. The request can be modified by the caller before being passed to the brcmf_fw_request_firmwares() function. Reviewed-by: Hante Meuleman

[PATCH 04/12] brcmfmac: allocate struct brcmf_pub instance using wiphy_new()

Rework the driver so the wiphy instance holds the main driver information in its private buffer. Previously it held struct brcmf_cfg80211_info instance so a bit of reorg was needed. This was done so that the wiphy name or its parent device can be shown in debug output. Reviewed-by: Hante Meuleman

[PATCH 00/12] brcmfmac: data structure and firmware loading rework

This patch series is intended for 4.17 containing the following: * use wiphy_priv() for storing main driver instance. * add driver debugfs entries under wiphy debugfsdir. * rework firmware loading module. * rework clm_blob loading. The patches apply to the master branch of the

[PATCH 05/12] brcmfmac: use wiphy debugfs dir entry

The driver used to create a brcmfmac dir entry at the top level debugfs mount point. This moves the debugfs entries into the wiphy debugfs dir entry. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by:

[PATCH 11/12] brcmfmac: get rid of brcmf_fw_get_full_name()

The function was pretty minimal and now it is called only from one place so just get rid of it. Signed-off-by: Arend van Spriel --- .../net/wireless/broadcom/brcm80211/brcmfmac/firmware.c| 14 -- 1 file changed, 4 insertions(+), 10 deletions(-)

[PATCH 10/12] brcmfmac: get rid of brcmf_fw_map_chip_to_name()

The function is no longer used so removing it. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin Signed-off-by: Arend van Spriel ---

[PATCH 02/12] brcmfmac: use brcmf_chip_name() to store name in revinfo

The chip id can either be four or five digits. For the chip name either the hexadecimal value needs to be taken (four digits) or the decimal value (five digits). The function brcmf_chip_name() does this conversion so use it to store the name in driver revision info. Reviewed-by: Hante Meuleman

[PATCH 03/12] brcmfmac: use brcmf_chip_name() for consistency

When logging the chip id/revision information make use of brcmf_chip_name() so it is always the same. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin Signed-off-by:

[PATCH 06/12] brcmfmac: derive firmware filenames from basename mapping

Instead of defining individual filenames for firmware and nvram use a basename and derive the names from that. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin

[PATCH 09/12] brcmfmac: add extension to .get_fwname() callbacks

This changes the bus layer api by having the caller provide an extension. With this the callback can use brcmf_fw_alloc_request() to get the needed firmware name. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts

[PATCH 12/12] brcmfmac: add kerneldoc for struct brcmf_bus::msgbuf

This field did not have kerneldoc description so adding it now. Signed-off-by: Arend van Spriel --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h

[PATCH 07/12] brcmfmac: pass struct in brcmf_fw_get_firmwares()

Make the function brcmf_fw_get_firmwares() a bit more easy to extend using a structure to pass the request parameters. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin

[PATCH 0/6] Update brcm firmware files

Update brcm firmware files and WHENCE accordingly. Chi-Hsien Lin (6): brcm: update firmware for bcm43340 brcm: update firmware for bcm43362 brcm: update firmware for bcm43430 brcm: update firmware for bcm4354 brcm: update firmware for bcm4356 pcie Update license for brcm firmware

[PATCH 6/6] Update license for brcm firmware

Upload a Cypress version of below firmware and hence update the license: brcm/brcmfmac43340-sdio.bin brcm/brcmfmac43362-sdio.bin brcm/brcmfmac43430-sdio.bin brcm/brcmfmac4354-sdio.bin brcm/brcmfmac4356-pcie.bin Signed-off-by: Chi-Hsien Lin --- WHENCE | 10 +-

Re: [PATCH 7/7] staging: wilc1000: use kmemdup to replace kmalloc/memcpy

://github.com/0day-ci/linux/commits/hariprasath-elango-gmail-com/staging-wilc1000-Fix-code-block-alignment/20180316-104440 coccinelle warnings: (new ones prefixed by >>) >> drivers/staging/wilc1000/host_interface.c:943:2-29: alloc with no test, >> possible model on line 995 driver

Re: [PATCH] wcn36xx: dequeue all pending indicator messages

Hi, On Friday, March 16, 2018 10:09 AM, Ramon Fried wrote: > On 3/16/2018 12:37 AM, Daniel Mack wrote: >> In case wcn36xx_smd_rsp_process() is called more than once before >> hal_ind_work was dispatched, the messages will end up in hal_ind_queue, >> but wcn36xx_ind_smd_work() will only look at

Re: [PATCH] wcn36xx: dequeue all pending indicator messages

On 3/16/2018 12:37 AM, Daniel Mack wrote: In case wcn36xx_smd_rsp_process() is called more than once before hal_ind_work was dispatched, the messages will end up in hal_ind_queue, but wcn36xx_ind_smd_work() will only look at the first message in that list. Fix this by dequeing the messages

[PATCH 1/2] ath10k: enable QCA6174/QCA9377 to read the chip temperature

From: Ryan Hsu The firmware of QCA6174/QCA9377 already support the feature, just enable it to be able to handle the get_temperature command and process the event. You can read the temperature by using the hwmon interface, cat

[PATCH 2/2] ath10k: add FW API 6 firmware image for QCA9377

From: Ryan Hsu Firmware WLAN.TF.2.1-00014-QCARMSWP-1 now supports reading the board ID information and also required 9 IRAM bank, which older ath10k version don't have the support will fail to be enabled, so in order to maintain the backward compatibility, we need to