Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 11 5月, 2011 2 次提交
    • S
      iwlegacy: fix IBSS mode crashes · eb85de3f
      由 Stanislaw Gruszka 提交于 
      We should not switch to non-IBSS channels when working in IBSS mode,
otherwise there are microcode errors, and after some time system
crashes.

This bug is only observable when software scan is used in IBSS mode,
so should be considered as regression after:

commit 0263aa45
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Tue Mar 29 11:24:21 2011 +0200

    iwl3945: disable hw scan by default

However IBSS mode check, which this patch add again, was removed by

commit b2f30e8b
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Jan 21 07:32:20 2010 -0800

    iwlwifi: remove IBSS channel sanity check

That commit claim that mac80211 will not use non-IBSS channel in IBSS
mode, what definitely is not true. Bug probably should be fixed in
mac80211, but that will require more work, so better to apply that patch
temporally, and provide proper mac80211 fix latter.

Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=34452Reported-and-tested-by: NMikko Rapeli <mikko.rapeli@iki.fi>
Cc: stable@kernel.org # 2.6.38.5+
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      eb85de3f
    • M
      ath9k: Fix a warning due to a queued work during S3 state · 99aa55b6
      由 Mohammed Shafi Shajakhan 提交于 
      during suspend/S3 state drv_flush is called from mac80211 irrespective of
interface count. In ath9k we queue a work in ath9k_flush which we expect
to be cancelled in the drv_stop call back. during suspend process mac80211
calls drv_stop only when the interface count(local->count) is non-zero.
unfortunately when the network manager is enabled, drv_flush is called
while drv_stop is not called as local->count reaches '0'.
	So fix this by simply checking for the device presence in the
drv_flush call back in the driver before queueing work or anything else.
this patch fixes the following WARNING

	Call Trace:
	[<c014c6e2>] warn_slowpath_common+0x72/0xa0
	[<fc133f99>] ? ieee80211_can_queue_work+0x39/0x50 [mac80211]
	[<fc133f99>] ? ieee80211_can_queue_work+0x39/0x50 [mac80211]
	[<c014c75b>] warn_slowpath_fmt+0x2b/0x30
	[<fc133f99>] ieee80211_can_queue_work+0x39/0x50 [mac80211]
	[<fc134ed1>] ieee80211_queue_delayed_work+0x21/0x50 [mac80211]
	[<fc1e5b22>] ath_tx_complete_poll_work+0xb2/0x100 [ath9k]
	[<c016399e>] run_workqueue+0x8e/0x150
	[<fc1e5a70>] ? ath_tx_complete_poll_work+0x0/0x100 [ath9k]
	[<c0163ae4>] worker_thread+0x84/0xe0
	[<c0167a60>] ? autoremove_wake_function+0x0/0x50
	[<c0163a60>] ? worker_thread+0x0/0xe0
	[<c01677d4>] kthread+0x74/0x80
	[<c0167760>] ? kthread+0x0/0x80
	[<c0104087>] kernel_thread_helper+0x7/0x10
---[ end trace 2aff81010df9215b ]---
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      99aa55b6
  3. 30 4月, 2011 2 次提交
  5. 29 4月, 2011 3 次提交
  7. 21 4月, 2011 2 次提交
  9. 20 4月, 2011 1 次提交
  11. 18 4月, 2011 1 次提交
  13. 14 4月, 2011 1 次提交
  15. 13 4月, 2011 2 次提交
    • S
      ath9k_htc: Fix ethtool reporting · 50f68712
      由 Sujith Manoharan 提交于 
      Pass the correct module name and device interface so that
ethtool can display the proper values.

The firmware version will be fixed later on when the FW
can actually report a version. :)
Reported-by: NRichard Farina <sidhayn@gmail.com>
Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com>
Tested-by: NRichard Farina <sidhayn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      50f68712
    • F
      ath9k_hw: fix stopping rx DMA during resets · 5882da02
      由 Felix Fietkau 提交于 
      During PHY errors, the MAC can sometimes fail to enter an idle state on older
hardware (before AR9380) after an rx stop has been requested.

This typically shows up in the kernel log with messages like these:

ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
------------[ cut here ]------------
WARNING: at drivers/net/wireless/ath/ath9k/recv.c:504 ath_stoprecv+0xcc/0xf0 [ath9k]()
Call Trace:
[<8023f0e8>] dump_stack+0x8/0x34
[<80075050>] warn_slowpath_common+0x78/0xa4
[<80075094>] warn_slowpath_null+0x18/0x24
[<80d66d60>] ath_stoprecv+0xcc/0xf0 [ath9k]
[<80d642cc>] ath_set_channel+0xbc/0x270 [ath9k]
[<80d65254>] ath_radio_disable+0x4a4/0x7fc [ath9k]

When this happens, the state that the MAC enters is easy to identify and
does not result in bogus DMA traffic, however to ensure a working state
after a channel change, the hardware should still be reset.

This patch adds detection for this specific MAC state, after which the above
warnings completely disappear in my tests.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Cc: Kyungwan Nam <Kyungwan.Nam@Atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5882da02
  17. 12 4月, 2011 1 次提交
  19. 09 4月, 2011 2 次提交
  21. 08 4月, 2011 3 次提交
  23. 05 4月, 2011 10 次提交
  25. 04 4月, 2011 1 次提交
  27. 02 4月, 2011 2 次提交
    • A
      usbnet: use eth%d name for known ethernet devices · c261344d
      由 Arnd Bergmann 提交于 
      The documentation for the USB ethernet devices suggests that
only some devices are supposed to use usb0 as the network interface
name instead of eth0. The logic used there, and documented in
Kconfig for CDC is that eth0 will be used when the mac address
is a globally assigned one, but usb0 is used for the locally
managed range that is typically used on point-to-point links.

Unfortunately, this has caused a lot of pain on the smsc95xx
device that is used on the popular pandaboard without an
EEPROM to store the MAC address, which causes the driver to
call random_ether_address().

Obviously, there should be a proper MAC addressed assigned to
the device, and discussions are ongoing about how to solve
this, but this patch at least makes sure that the default
interface naming gets a little saner and matches what the
user can expect based on the documentation, including for
new devices.

The approach taken here is to flag whether a device might be a
point-to-point link with the new FLAG_POINTTOPOINT setting in
the usbnet driver_info. A driver can set both FLAG_POINTTOPOINT
and FLAG_ETHER if it is not sure (e.g. cdc_ether), or just one
of the two.  The usbnet framework only looks at the MAC address
for device naming if both flags are set, otherwise it trusts the
flag.
Signed-off-by: NArnd Bergmann <arnd.bergmann@linaro.org>
Tested-by: NAndy Green <andy.green@linaro.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c261344d
    • F
      starfire: clean up dma_addr_t size test · 1591cb60
      由 FUJITA Tomonori 提交于 
      Now we have CONFIG_ARCH_DMA_ADDR_T_64BIT. We can fix the hacky
dma_addr_t size test cleanly.
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1591cb60
  29. 31 3月, 2011 7 次提交