Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 3 年多

通知 13
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 18 7月, 2011 8 次提交
  3. 17 7月, 2011 4 次提交
    • R
      watchdog: hpwdt depends on PCI · f71d26bb
      由 Randy Dunlap 提交于 
      hpwdt is a PCI driver so it should depend on PCI.
Fixes these build errors:

drivers/watchdog/hpwdt.c:762: error: implicit declaration of function 'pci_iomap'
drivers/watchdog/hpwdt.c:762: warning: assignment makes pointer from integer without a cast
drivers/watchdog/hpwdt.c:797: error: implicit declaration of function 'pci_iounmap'
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
Cc: Thomas Mingarelli <thomas.mingarelli@hp.com>
      f71d26bb
    • W
      sparc: sun4m SMP: fix wrong shift instruction in IPI handler · 1ef48593
      由 Will Simoneau 提交于 
      This shift instruction appears to be shifting in the wrong direction.
Without this change, my SparcStation-20MP hangs just after bringing up
the second CPU:

Entering SMP Mode...
Starting CPU 2 at f02b4e90
Brought up 2 CPUs
Total of 2 processors activated (99.52 BogoMIPS).
   *** stuck ***
Signed-off-by: NWill Simoneau <simoneau@ele.uri.edu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1ef48593
    • I
      Bluetooth: Fix crash with incoming L2CAP connections · 05e9a2f6
      由 Ilia Kolomisnky 提交于 
      Another regression fix considering incomming l2cap connections with
defer_setup enabled. In situations when incomming connection is
extracted with l2cap_sock_accept, it's bt_sock info will have
'parent' member zerroed, but 'parent' may be used unconditionally
in l2cap_conn_start() and l2cap_security_cfm() when defer_setup
is enabled.

Backtrace:
[<bf02d5ac>] (l2cap_security_cfm+0x0/0x2ac [bluetooth]) from [<bf01f01c>] (hci_event_pac
ket+0xc2c/0x4aa4 [bluetooth])
[<bf01e3f0>] (hci_event_packet+0x0/0x4aa4 [bluetooth]) from [<bf01a844>] (hci_rx_task+0x
cc/0x27c [bluetooth])
[<bf01a778>] (hci_rx_task+0x0/0x27c [bluetooth]) from [<c008eee4>] (tasklet_action+0xa0/
0x15c)
[<c008ee44>] (tasklet_action+0x0/0x15c) from [<c008f38c>] (__do_softirq+0x98/0x130)
 r7:00000101 r6:00000018 r5:00000001 r4:efc46000
[<c008f2f4>] (__do_softirq+0x0/0x130) from [<c008f524>] (do_softirq+0x4c/0x58)
[<c008f4d8>] (do_softirq+0x0/0x58) from [<c008f5e0>] (run_ksoftirqd+0xb0/0x1b4)
 r4:efc46000 r3:00000001
[<c008f530>] (run_ksoftirqd+0x0/0x1b4) from [<c009f2a8>] (kthread+0x84/0x8c)
 r7:00000000 r6:c008f530 r5:efc47fc4 r4:efc41f08
[<c009f224>] (kthread+0x0/0x8c) from [<c008cc84>] (do_exit+0x0/0x5f0)
Signed-off-by: NIlia Kolomisnky <iliak@ti.com>
Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      05e9a2f6
    • G
      Bluetooth: Fix regression in L2CAP connection procedure · 9191e6ad
      由 Gustavo F. Padovan 提交于 
      Caused by the following commit, partially revert it.

commit 9fa7e4f7
Author: Gustavo F. Padovan <padovan@profusion.mobi>
Date:   Thu Jun 30 16:11:30 2011 -0300

    Bluetooth: Fix regression with incoming L2CAP connections

    PTS test A2DP/SRC/SRC_SET/TC_SRC_SET_BV_02_I revealed that
    ( probably after the df3c3931 commit ) the l2cap connection
    could not be established in case when the "Auth Complete" HCI
    event does not arive before the initiator send "Configuration
    request", in which case l2cap replies with "Command rejected"
    since the channel is still in BT_CONNECT2 state.
Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9191e6ad
  5. 16 7月, 2011 14 次提交
  7. 15 7月, 2011 7 次提交
  9. 14 7月, 2011 7 次提交
    • S
      GFS2: Resolve inode eviction and ail list interaction bug · 380f7c65
      由 Steven Whitehouse 提交于 
      This patch contains a few misc fixes which resolve a recently
reported issue. This patch has been a real team effort and has
received a lot of testing.

The first issue is that the ail lock needs to be held over a few
more operations. The lock thats added into gfs2_releasepage() may
possibly be a candidate for replacing with RCU at some future
point, but at this stage we've gone for the obvious fix.

The second issue is that gfs2_write_inode() can end up calling
a glock recursively when called from gfs2_evict_inode() via the
syncing code, so it needs a guard added.

The third issue is that we either need to not truncate the metadata
pages of inodes which have zero link count, but which we cannot
deallocate due to them still being in use by other nodes, or we need
to ensure that those pages have all made it through the journal and
ail lists first. This patch takes the former approach, but the
latter has also been tested and there is nothing to choose between
them performance-wise. So again, we could revise that decision
in the future.

Also, the inode eviction process is now better documented.
Signed-off-by: NSteven Whitehouse <swhiteho@redhat.com>
Tested-by: NBob Peterson <rpeterso@redhat.com>
Tested-by: NAbhijith Das <adas@redhat.com>
Reported-by: NBarry J. Marson <bmarson@redhat.com>
Reported-by: NDavid Teigland <teigland@redhat.com>
      380f7c65
    • L
      Merge branches 'd3cold', 'bugzilla-37412' and 'bugzilla-38152' into release · 7fb574a9
      由 Len Brown 提交于
      7fb574a9
    • L
      ACPI: Fixes device power states array overflow · b4a03b9a
      由 Lin Ming 提交于 
      Commit 28c2103d added new state ACPI_STATE_D3_COLD, so the device power
states array must be expanded by one also.

v2: Use ACPI_D_STATE_COUNT instead of number 5 for the array size.
Reported-by: NDan Carpenter <error27@gmail.com>
Suggested-by: NOldřich Jedlička <oldium.pro@seznam.cz>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>
      b4a03b9a
    • H
      ACPI, APEI, HEST, Detect duplicated hardware error source ID · 4d2b2956
      由 Huang Ying 提交于 
      The firmware on some machine will report duplicated hardware error
source ID in HEST.  This is considered a firmware bug.  To provide
better warning message, this patch adds duplicated hardware error
source ID detecting and corresponding printk.

This patch fixes #37412 on kernel bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=37412

Reported-by: marconifabio@ubuntu-it.org
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Tested-by: NMathias <janedo.spam@gmail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>
      4d2b2956
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc · 51414d41
      由 Linus Torvalds 提交于 
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc:
  mmc: core: Bus width testing needs to handle suspend/resume
      51414d41
    • M
      [media] tuner-core: fix a 2.6.39 regression with mt20xx · a1ad5ec7
      由 Mauro Carvalho Chehab 提交于 
      As Simon reported, digital TV broke with mt20xx tuner due to
commit ad020dc2.

The mt20xx tuner passes V4L2_TUNER_DIGITAL_TV to tuner core. However, the
check_mode code now doesn't handle it well. Change the logic there to
avoid the breakage, and fix a test for analog-only at g_tuner.
Reported-by: NSimon Arlott <simon@fire.lp0.eu>
Tested-by: NSimon Arlott <simon@fire.lp0.eu>
Cc: stable@kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      a1ad5ec7
    • D
      [media] dvb_frontend: fix race condition in stopping/starting frontend · 2d196931
      由 Devin Heitmueller 提交于 
      Attached is a patch which addresses a race condition in the DVB core
related to closing/reopening the DVB frontend device in quick
succession.  This is the reason that devices such as the HVR-1300,
HVR-3000, and HVR-4000 have been failing to scan properly under MythTV
and w_scan.

The gory details of the race are described in the patch.

Devin

There is a race condition exhibited when channel scanners such as w_scan and
MythTV quickly close and then reopen the frontend device node.

Under normal conditions, the behavior is as follows:

1.  Application closes the device node
2.  DVB frontend ioctl calls dvb_frontend_release which sets
    fepriv->release_jiffies
3.  DVB frontend thread *eventually* calls dvb_frontend_is_exiting() which
    compares fepriv->release_jiffies, and shuts down the thread if timeout has
    expired
4.  Thread goes away
5.  Application opens frontend device
6.  DVB frontend ioctl() calls ts_bus_ctrl(1)
7.  DVB frontend ioctl() creates new frontend thread, which calls
    dvb_frontend_init(), which has demod driver init() routine setup initial
    register state for demod chip.
8.  Tuning request is issued.

The race occurs when the application in step 5 performs the new open() call
before the frontend thread is shutdown.  In this case the ts_bus_ctrl() call
is made, which strobes the RESET pin on the demodulator, but the
dvb_frontend_init() function never gets called because the frontend thread
hasn't gone away yet.  As a result, the initial register config for the demod
is *never* setup, causing subsequent tuning requests to fail.

If there is time between the close and open (enough for the dvb frontend
thread to be torn down), then in that case the new frontend thread is created
and thus the dvb_frontend_init() function does get called.

The fix is to set the flag which forces reinitialization if we did in fact
call ts_bus_ctrl().

This problem has been seen on the HVR-1300, HVR-3000, and HVR-4000, and is
likely occuring on other designs as well where ts_bus_ctrl() actually strobes
the reset pin on the demodulator.

Note that this patch should supercede any patches submitted for the
1300/3000/4000 which remove the code that removes GPIO code in
cx8802_dvb_advise_acquire(), which have been circulating by users for some
time now...

Canonical tracking this issue in Launchpad 439163:

Thanks to Jon Sayers from Hauppauge and Florent Audebert from Anevia S.A. for
providing hardware to test/debug with.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Cc: Jon Sayers <j.sayers@hauppauge.co.uk>
Cc: Florent Audebert <florent.audebert@anevia.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      2d196931