Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 22 7月, 2014 1 次提交
  3. 16 7月, 2014 1 次提交
    • T
      net: set name_assign_type in alloc_netdev() · c835a677
      由 Tom Gundersen 提交于 
      Extend alloc_netdev{,_mq{,s}}() to take name_assign_type as argument, and convert
all users to pass NET_NAME_UNKNOWN.

Coccinelle patch:

@@
expression sizeof_priv, name, setup, txqs, rxqs, count;
@@

(
-alloc_netdev_mqs(sizeof_priv, name, setup, txqs, rxqs)
+alloc_netdev_mqs(sizeof_priv, name, NET_NAME_UNKNOWN, setup, txqs, rxqs)
|
-alloc_netdev_mq(sizeof_priv, name, setup, count)
+alloc_netdev_mq(sizeof_priv, name, NET_NAME_UNKNOWN, setup, count)
|
-alloc_netdev(sizeof_priv, name, setup)
+alloc_netdev(sizeof_priv, name, NET_NAME_UNKNOWN, setup)
)

v9: move comments here from the wrong commit
Signed-off-by: NTom Gundersen <teg@jklm.no>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c835a677
  5. 16 6月, 2014 5 次提交
  7. 11 6月, 2014 1 次提交
  9. 10 6月, 2014 6 次提交
    • S
      s390/airq: silence lockdep warning · 0eb69a0c
      由 Sebastian Ott 提交于 
      airq_iv_(alloc|free) is called by some users with interrupts enabled
and by some with interrupts disabled which leads to the following
lockdep warning:

[ INFO: possible irq lock inversion dependency detected ]
3.14.0-15249-gbf29b7b-dirty #25 Not tainted
---------------------------------------------------------
insmod/2108 just changed the state of lock:
 (&(&iv->lock)->rlock){+.....}, at: [<000000000046ee3e>] airq_iv_alloc+0x62/0x228
but this lock was taken by another, HARDIRQ-READ-safe lock in the past:
 (&info->lock){.-.-..}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
 Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&(&iv->lock)->rlock);
                               local_irq_disable();
                               lock(&info->lock);
                               lock(&(&iv->lock)->rlock);
  <Interrupt>
    lock(&info->lock);

 *** DEADLOCK ***

Although this is a false alarm (since each airq user consistently
calls these functions from the same context) fix this by ensuring
that interrupts are disabled when the airq lock is held.
Reported-by: NFrank Blaschka <frank.blaschka@de.ibm.com>
Signed-off-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      0eb69a0c
    • P
      s390/watchdog: use watchdog API · f7a94db4
      由 Philipp Hachtmann 提交于 
      Converted the vmwatchdog driver to use the kernel's watchdog API.
Signed-off-by: NPhilipp Hachtmann <phacht@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      f7a94db4
    • P
      s390/sclp_vt220: Enable ASCII console per default · f2485f5d
      由 Peter Oberparleiter 提交于 
      When you want to use the HMC's ASCII console as console device for
a z/VM guest you have to specify console=ttyS1 on the kernel command
line. But it won't work until you specify conmode=sclp as well.

This behavior is inconsistent with the use of the ASCII console as
TTY device which works on z/VM without the need to specify a conmode.

Fix this inconsistency by removing the check for conmode=sclp in the
ASCII console registration function.
Signed-off-by: NPeter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      f2485f5d
    • F
      s390/qdio: replace shift loop by ilog2 · 92bdae5d
      由 Fabian Frederick 提交于 
      account_sbals is called by get_inbound_buffer_frontier and
get_outbound_buffer_frontier with 'count' value > 0 so we can safely
convert shift loop to ilog2.

Cc: Joe Perches <joe@perches.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NFabian Frederick <fabf@skynet.be>
Signed-off-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      92bdae5d
    • S
      s390/cio: silence lockdep warning · dbe33fc9
      由 Sebastian Ott 提交于 
      On systems where a ccw based console device is used a lockdep false alarm
could be triggered when a device driver calls printk while holding a
subchannels lock (e.g. in it's irq handler). Since this is valid behavior
fix this by introducing a separate lock class for the console subchannels
lock.

The lockdep warning was revealed by "printk: enable interrupts before calling
console_trylock_for_printk()" which changed console_unlock() to be called with
lockdep enabled.

[ INFO: possible recursive locking detected ]
3.15.0-rc5-next-20140520 #1 Not tainted
---------------------------------------------
ccwgroup/2239 is trying to acquire lock:
(&(sch->lock)->rlock){-.-...}, at: [<0000000000642a52>] raw3215_write+0x52/0x200

but task is already holding lock:
(&(sch->lock)->rlock){-.-...}, at: [<00000000005fd160>] do_cio_interrupt+0x60/0x108

other info that might help us debug this:
Possible unsafe locking scenario:

CPU0
----
lock(&(sch->lock)->rlock);
lock(&(sch->lock)->rlock);

*** DEADLOCK ***

May be due to missing lock nesting notation

8 locks held by ccwgroup/2239:

stack backtrace:
CPU: 3 PID: 2239 Comm: ccwgroup Not tainted 3.15.0-rc5-next-20140520 #1
0000000036fab518 0000000036fab528 0000000000000002 0000000000000000
0000000036fab5b8 0000000036fab530 0000000036fab530 00000000001116e8
0000000000000000 0000000000986ec4 00000000009701b6 000000000000000b
0000000036fab578 0000000036fab518 0000000000000000 0000000000000000
0000000000000000 00000000001116e8 0000000036fab518 0000000036fab578
Call Trace:
([<0000000000111626>] show_trace+0x14e/0x158)
[<000000000011169a>] show_stack+0x6a/0xe8
[<00000000007c6e72>] dump_stack+0x82/0xb0
[<00000000001a95f2>] validate_chain.isra.37+0xa4a/0xbb0
[<00000000001acaca>] __lock_acquire+0x4da/0xcd0
[<00000000001ada1a>] lock_acquire+0xba/0x218
[<00000000007cd634>] _raw_spin_lock_irqsave+0x6c/0xb8
[<0000000000642a52>] raw3215_write+0x52/0x200
[<0000000000643d16>] con3215_write+0x76/0xf8
[<00000000001bd87a>] call_console_drivers.constprop.25+0xfa/0x210
[<00000000001be0b0>] console_unlock+0x3e0/0x4e8
[<00000000001be450>] vprintk_emit+0x298/0x6e0
[<00000000005aa210>] dev_vprintk_emit+0xe0/0x1a8
[<00000000005aa320>] dev_printk_emit+0x48/0x50
[<00000000005aa390>] __dev_printk+0x68/0xb0
[<00000000005aa7c2>] _dev_info+0x62/0x70
[<0000000000657bf0>] qeth_l2_send_setmac_cb+0xd0/0x190
[<0000000000651a1e>] qeth_send_control_data_cb+0x3a6/0x6a8
[<0000000000655546>] qeth_irq+0x1a6/0xac0
[<000000000060a0ac>] ccw_device_call_handler+0xa4/0xc0
[<0000000000608b62>] ccw_device_irq+0x5a/0x190
[<00000000005fd1ca>] do_cio_interrupt+0xca/0x108
[<00000000001c0a2e>] handle_irq_event_percpu+0x5e/0x378
[<00000000001c46fc>] handle_percpu_irq+0x6c/0x98
[<00000000001c0066>] generic_handle_irq+0x46/0x68
[<000000000010b5b6>] do_IRQ+0x5e/0x88
[<00000000007cf304>] io_call+0x6/0x20
[<000000000064c63a>] qeth_send_control_data+0x322/0x570
([<000000000064c50e>] qeth_send_control_data+0x1f6/0x570)
[<0000000000651db2>] qeth_send_ipa_cmd+0x92/0x120
[<000000000065b310>] __qeth_l2_set_online+0x170/0xaa8
[<000000000060ebb6>] ccwgroup_set_online+0x56/0x90
[<000000000060ef96>] ccwgroup_online_store+0xd6/0xe0
[<000000000033d11a>] kernfs_fop_write+0x10a/0x188
[<00000000002bbd00>] vfs_write+0x98/0x1c0
[<00000000002bc8a0>] SyS_write+0x60/0xd0
[<00000000007cee3a>] sysc_nr_ok+0x22/0x28
[<000003fffd0c3f28>] 0x3fffd0c3f28
Reported-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      dbe33fc9
    • M
      s390/ap_bus: Make modules parameters visible in sysfs · c1a42f49
      由 Michael Veigel 提交于 
      Change the visibility of the module parameters ap_domain_index and
ap_thread_flag for the owner and the members of the owners group in
sysfs.

Previously the parameters where invisible due to a value of zero
as permissions parameter in the module_param_named macro.
Signed-off-by: NMichael Veigel <veigel@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      c1a42f49
  11. 07 6月, 2014 1 次提交
  13. 31 5月, 2014 2 次提交
  15. 28 5月, 2014 1 次提交
  17. 27 5月, 2014 1 次提交
  19. 20 5月, 2014 3 次提交
  21. 16 5月, 2014 1 次提交
  23. 14 5月, 2014 1 次提交
  25. 13 5月, 2014 1 次提交
  27. 29 4月, 2014 7 次提交
  29. 28 4月, 2014 1 次提交
  31. 22 4月, 2014 1 次提交
  33. 18 4月, 2014 1 次提交
  35. 17 4月, 2014 1 次提交
  37. 11 4月, 2014 3 次提交
  39. 03 4月, 2014 1 次提交