Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 26 4月, 2012 1 次提交
  3. 24 4月, 2012 2 次提交
    • A
      net/davinci_emac: fix failing PHY connect attempts · 1ab8be4a
      由 Anatolij Gustschin 提交于 
      PHY connect attempts fail if no PHY id is specified in the emac platform
data and another mdio bus has been registered before 'davinci_mdio' bus. In
this case when configuring the interface, there will be an attempt to
connect to already attached PHY on the previously registered mdio bus:

net eth1: PHY already attached
net eth1: could not connect to phy smsc911x-0:01
IP-Config: Failed to open eth1
IP-Config: Device `eth1' not found

Fix this by modifying match_first_device() to match first PHY device
on 'davinci_mdio' bus.
Signed-off-by: NAnatolij Gustschin <agust@denx.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1ab8be4a
    • T
      ehea: only register irq after setting up ports · c2f1244b
      由 Thadeu Lima de Souza Cascardo 提交于 
      If we receive an interrupt too early before we set up ports in the probe
function, there won't be any port ready to handle it.

Only registering the irq after the ports are setup fixes the problem,
and works fine without losing any interrupts.

This causes crashes in some situations:

[c000000f7ff7fd60] d000000008e223f0 .ehea_neq_tasklet+0x78/0x148 [ehea]
[c000000f7ff7fe00] c0000000000b6cac .tasklet_hi_action+0xdc/0x210
[c000000f7ff7fea0] c0000000000b7cc8 .__do_softirq+0x178/0x300
[c000000f7ff7ff90] c000000000022694 .call_do_softirq+0x14/0x24
[c000000f68ee7900] c000000000010e04 .do_softirq+0xec/0x110
[c000000f68ee79a0] c0000000000b789c .irq_exit+0xac/0xe0
[c000000f68ee7a20] c0000000000110bc .do_IRQ+0x114/0x2a8
[c000000f68ee7ae0] c00000000000553c hardware_interrupt_entry+0x18/0x1c
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c2f1244b
  5. 22 4月, 2012 3 次提交
    • L
      drivers/net: Do not free an IRQ if its request failed · 163faf31
      由 Lee Jones 提交于 
      Refrain from attempting to free an interrupt line if the request
fails and hence, there is no IRQ to free.

CC: netdev@vger.kernel.org
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      163faf31
    • M
      ks8851: Fix request_irq/free_irq mismatch · e8195b24
      由 Matt Renzelmann 提交于 
      The dev_id parameter passed to free_irq needs to match the one passed
to the corresponding request_irq.
Signed-off-by: NMatt Renzelmann <mjr@cs.wisc.edu>
Acked-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e8195b24
    • S
      ks8851: Fix mutex deadlock in ks8851_net_stop() · c5a99937
      由 Stephen Boyd 提交于 
      There is a potential deadlock scenario when the ks8851 driver
is removed. The interrupt handler schedules a workqueue which
acquires a mutex that ks8851_net_stop() also acquires before
flushing the workqueue. Previously lockdep wouldn't be able
to find this problem but now that it has the support we can
trigger this lockdep warning by rmmoding the driver after
an ifconfig up.

Fix the possible deadlock by disabling the interrupts in
the chip and then release the lock across the workqueue
flushing. The mutex is only there to proect the registers
anyway so this should be ok.

=======================================================
[ INFO: possible circular locking dependency detected ]
3.0.21-00021-g8b33780-dirty #2911
-------------------------------------------------------
rmmod/125 is trying to acquire lock:
 ((&ks->irq_work)){+.+...}, at: [<c019e0b8>] flush_work+0x0/0xac

but task is already holding lock:
 (&ks->lock){+.+...}, at: [<bf00b850>] ks8851_net_stop+0x64/0x138 [ks8851]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&ks->lock){+.+...}:
       [<c01b89c8>] __lock_acquire+0x940/0x9f8
       [<c01b9058>] lock_acquire+0x10c/0x130
       [<c083dbec>] mutex_lock_nested+0x68/0x3dc
       [<bf00bd48>] ks8851_irq_work+0x24/0x46c [ks8851]
       [<c019c580>] process_one_work+0x2d8/0x518
       [<c019cb98>] worker_thread+0x220/0x3a0
       [<c01a2ad4>] kthread+0x88/0x94
       [<c0107008>] kernel_thread_exit+0x0/0x8

-> #0 ((&ks->irq_work)){+.+...}:
       [<c01b7984>] validate_chain+0x914/0x1018
       [<c01b89c8>] __lock_acquire+0x940/0x9f8
       [<c01b9058>] lock_acquire+0x10c/0x130
       [<c019e104>] flush_work+0x4c/0xac
       [<bf00b858>] ks8851_net_stop+0x6c/0x138 [ks8851]
       [<c06b209c>] __dev_close_many+0x98/0xcc
       [<c06b2174>] dev_close_many+0x68/0xd0
       [<c06b22ec>] rollback_registered_many+0xcc/0x2b8
       [<c06b2554>] rollback_registered+0x28/0x34
       [<c06b25b8>] unregister_netdevice_queue+0x58/0x7c
       [<c06b25f4>] unregister_netdev+0x18/0x20
       [<bf00c1f4>] ks8851_remove+0x64/0xb4 [ks8851]
       [<c049ddf0>] spi_drv_remove+0x18/0x1c
       [<c0468e98>] __device_release_driver+0x7c/0xbc
       [<c0468f64>] driver_detach+0x8c/0xb4
       [<c0467f00>] bus_remove_driver+0xb8/0xe8
       [<c01c1d20>] sys_delete_module+0x1e8/0x27c
       [<c0105ec0>] ret_fast_syscall+0x0/0x3c

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&ks->lock);
                               lock((&ks->irq_work));
                               lock(&ks->lock);
  lock((&ks->irq_work));

 *** DEADLOCK ***

4 locks held by rmmod/125:
 #0:  (&__lockdep_no_validate__){+.+.+.}, at: [<c0468f44>] driver_detach+0x6c/0xb4
 #1:  (&__lockdep_no_validate__){+.+.+.}, at: [<c0468f50>] driver_detach+0x78/0xb4
 #2:  (rtnl_mutex){+.+.+.}, at: [<c06b25e8>] unregister_netdev+0xc/0x20
 #3:  (&ks->lock){+.+...}, at: [<bf00b850>] ks8851_net_stop+0x64/0x138 [ks8851]

Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c5a99937
  7. 20 4月, 2012 2 次提交
  9. 18 4月, 2012 3 次提交
  11. 15 4月, 2012 1 次提交
    • D
      net/ethernet: ks8851_mll fix rx frame buffer overflow · 8a9a0ea6
      由 Davide Ciminaghi 提交于 
      At the beginning of ks_rcv(), a for loop retrieves the
header information relevant to all the frames stored
in the mac's internal buffers. The number of pending
frames is stored as an 8 bits field in KS_RXFCTR.
If interrupts are disabled long enough to allow for more than
32 frames to accumulate in the MAC's internal buffers, a buffer
overflow occurs.
This patch fixes the problem by making the
driver's frame_head_info buffer big enough.
Well actually, since the chip appears to have 12K of
internal rx buffers and the shortest ethernet frame should
be 64 bytes long, maybe the limit could be set to
12*1024/64 = 192 frames, but 255 should be safer.
Signed-off-by: NDavide Ciminaghi <ciminaghi@gnudd.com>
Signed-off-by: NRaffaele Recalcati <raffaele.recalcati@bticino.it>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a9a0ea6
  13. 14 4月, 2012 7 次提交
  15. 06 4月, 2012 1 次提交
    • S
      simple_open: automatically convert to simple_open() · 234e3405
      由 Stephen Boyd 提交于 
      Many users of debugfs copy the implementation of default_open() when
they want to support a custom read/write function op.  This leads to a
proliferation of the default_open() implementation across the entire
tree.

Now that the common implementation has been consolidated into libfs we
can replace all the users of this function with simple_open().

This replacement was done with the following semantic patch:

<smpl>
@ open @
identifier open_f != simple_open;
identifier i, f;
@@
-int open_f(struct inode *i, struct file *f)
-{
(
-if (i->i_private)
-f->private_data = i->i_private;
|
-f->private_data = i->i_private;
)
-return 0;
-}

@ has_open depends on open @
identifier fops;
identifier open.open_f;
@@
struct file_operations fops = {
...
-.open = open_f,
+.open = simple_open,
...
};
</smpl>

[akpm@linux-foundation.org: checkpatch fixes]
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      234e3405
  17. 05 4月, 2012 13 次提交
  19. 04 4月, 2012 5 次提交
  21. 03 4月, 2012 2 次提交