Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 21 8月, 2015 2 次提交
  3. 19 8月, 2015 2 次提交
  5. 14 8月, 2015 1 次提交
  7. 13 8月, 2015 1 次提交
  9. 03 8月, 2015 1 次提交
  11. 31 7月, 2015 5 次提交
    • K
      Revert "ath9k: export HW random number generator" · 360d9bb5
      由 Kalle Valo 提交于 
      This reverts commit 6301566e. Oleksij Rempel
noticed that the randomness doesn't look to be good enough and Stephan Mueller
commented:

"I would say that the discussed RNG does not seem fit for hooking it up with the
hwrandom framework."

http://lkml.kernel.org/g/3945775.m5HblJPgiO@tauon.atsec.com

So let's the revert the patch until we are sure that we can trust this random
generator.
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      360d9bb5
    • L
      rtlwifi: Fix NULL dereference when PCI driver used as an AP · 7c629401
      由 Luis Felipe Dominguez Vega 提交于 
      In commit 33511b15 ("rtlwifi: add support to
send beacon frame"), the mechanism for sending beacons was established. That
patch works correctly for rtl8192cu, but there is a possibility of getting
the following warnings in the PCI drivers:

WARNING: CPU: 1 PID: 2439 at net/mac80211/driver-ops.h:12
ieee80211_bss_info_change_notify+0x179/0x1d0 [mac80211]()
wlp5s0:  Failed check-sdata-in-driver check, flags: 0x0

The warning is followed by a NULL pointer dereference as follows:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000006
IP: [<ffffffffc073998e>] rtl_get_tcb_desc+0x5e/0x760 [rtlwifi]

This problem was reported at http://thread.gmane.org/gmane.linux.kernel.wireless.general/138645,
but no solution was found at that time.

The problem was also reported at https://bugzilla.kernel.org/show_bug.cgi?id=9744
and this solution was developed and tested there.

The USB driver works with a NULL final argument in the adapter_tx() callback;
however, the PCI drivers need a struct rtl_tcb_desc in that position.

Fixes: 33511b15 ("rtlwifi: add support to send beacon frame.")
Signed-off-by: NLuis Felipe Dominguez Vega <lfdominguez@nauta.cu>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> [3.19+]
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      7c629401
    • H
      b43: fix extpa_gain check for 2GHz · 098697db
      由 Hauke Mehrtens 提交于 
      On the 2GHz and and on the 5GHZ band only the extpa_gain setting from
the 5GHz band was checked. this patch makes it check the property from
the correct band.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      098697db
    • M
      rsi: Fix failure to load firmware after memory leak fix and fix the leak · 5d5cd85f
      由 Mike Looijmans 提交于 
      Fixes commit eae79b4f ("rsi: fix memory leak in rsi_load_ta_instructions()")
which stopped the driver from functioning.

Firmware data has been allocated using vmalloc(), resulting in memory
that cannot be used for DMA. Hence the firmware was first copied to a
buffer allocated with kmalloc() in the original code. This patch reverts
the commit and only calls "kfree()" to release the buffer after sending
the data. This fixes the memory leak without breaking the driver.

Add a comment to the kmemdup() calls to explain why this is done, and abort
if memory allocation fails.

Tested on a Topic Miami-Florida board which contains the rsi SDIO chip.

Also added the same kfree() call to the USB glue driver. This was not
tested on actual hardware though, as I only have the SDIO version.

Fixes: eae79b4f ("rsi: fix memory leak in rsi_load_ta_instructions()")
Signed-off-by: NMike Looijmans <mike.looijmans@topic.nl>
Cc: stable@vger.kernel.org
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      5d5cd85f
    • E
      iwlwifi: pcie: fix stuck queue detection for sleeping clients · aecdc63d
      由 Emmanuel Grumbach 提交于 
      The stuck queue detection mechanism allows to detect queues
that are stuck. For sleeping clients, a queue may rightfully
be stuck: if a poor client implementation stays asleep for
more than 10s, then we don't want to trigger recovery flows
because of that client.
In order to cope with this, I added a mechanism that
monitors the state of the client: when a client goes to
sleep, the timer of his queues is frozen. When he wakes up,
the timer is reset to the right value so that if a client
was awake for more than 10s and the queues are stuck, only
then, the recovery flow will kick in.
This is valid only on non-shared queues: A-MPDU queues.

There was a bug in case we Tx to a sleeping client that has
an empty A-MPDU queue: the timer was armed to now + 10s.
This is bad, but pretty harmless.
The problem is that when the client wakes up, the timer is
modified to be now + remainder. But remainder is 0 since the
queue was empty when that client went to sleep...

Fix this by checking the state of the client before playing
with the timer when we add a packet to an empty queue.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      aecdc63d
  13. 28 7月, 2015 2 次提交
    • A
      iwlwifi: mvm: Fix regular scan priority · dc9f69b9
      由 Avraham Stern 提交于 
      The code checks the total number of iterations to differentiate
between regular scan and scheduled scan. However, regular scan has
a total of one iteration, not zero. As a result, regular scan will
have lower priority than it should have, and in case scheduled
scan is already running when regular scan is requested, regular scan
will be delayed until scheduled scan is aborted.
Fix that by checking for total iterations number of one as an
identifier for regular scan.

Fixes: 133c8259 ("iwlwifi: mvm: rename generic_scan_cmd functions to dwell")
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      dc9f69b9
    • E
      iwlwifi: pcie: fix prepare card flow · c9fdec9f
      由 Emmanuel Grumbach 提交于 
      When the card is not owned by the PCIe bus, we need to
acquire ownership first. This flow is implemented in
iwl_pcie_prepare_card_hw. Because of a hardware bug, we
need to disable link power management before we can
request ownership otherwise the other user of the device
won't get notified that we are requesting the device which
will prevent us from acquire ownership.

Same holds for the down flow where we need to make sure
that any other potential user is notified that the driver
is going down.

CC: <stable@vger.kernel.org> [4.1]
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      c9fdec9f
  15. 21 7月, 2015 26 次提交