* 'for-linus' of git://git.o-hand.com/linux-rpurdie-leds:
  leds: Fix race between LED device uevent and actual attributes creation
  leds-gpio: fix default state handling on OF platforms
  leds: Add Dell Business Class Netbook LED driver
  leds: Kconfig cleanup
  leds: led-class.c - Quiet boot messages
  leds: make PCI device id constant
  leds: ALIX2: Add dependency to !GPIO_CS5335

* 'for-linus' of git://oss.sgi.com/xfs/xfs:
  xfs: don't warn about page discards on shutdown
  xfs: use scalable vmap API
  xfs: remove old vmap cache

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (39 commits)
  gigaset: fix build failure
  bridge: Make first arg to deliver_clone const.
  bridge br_multicast: Don't refer to BR_INPUT_SKB_CB(skb)->mrouters_only without IGMP snooping.
  route: Fix caught BUG_ON during rt_secret_rebuild_oneshot()
  bridge br_multicast: Fix skb leakage in error path.
  bridge br_multicast: Fix handling of Max Response Code in IGMPv3 message.
  NET: netpoll, fix potential NULL ptr dereference
  tipc: fix lockdep warning on address assignment
  l2tp: Fix UDP socket reference count bugs in the pppol2tp driver
  smsc95xx: wait for PHY to complete reset during init
  l2tp: Fix oops in pppol2tp_xmit
  smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver
  ne: Do not use slashes in irq name string
  NET: ksz884x, fix lock imbalance
  gigaset: correct range checking off by one error
  bridge: Fix br_forward crash in promiscuous mode
  bridge: Move NULL mdb check into br_mdb_ip_get
  ISDN: Add PCI ID for HFC-2S/4S Beronet Card PCIe
  net-2.6 [Bug-Fix][dccp]: fix oops caused after failed initialisation
  myri: remove dead code
  ...

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6:
  sunxvr1000: Add missing FB=y depenency.
  MAINTAINERS: Add entry for sparc serial drivers.
  drivers/serial/sunsab.c: adjust the constant used to initialize the interrupt_mask0 fields

* 'urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6:
  PCMCIA: resource, fix lock imbalance
  pcmcia: add important if statement
  pcmcia: re-route Cardbus IRQ to ISA on ti1130 bridges if necessary
  pcmcia: allow for cb_irq to differ from pci_dev's irq in yenta_socket
  pcmcia: honor saved flags in yenta_socket's I365_CSCINT register
  pcmcia: revert "irq probe can be done without risking an IRQ storm"
  pcmcia: pd6729, i82092: use parent (PCI) resources
  pcmcia/vrc4171: use local spinlock for device local lock.

Implement arch specific arch_get_memory_phys_device function and
initialize phys_device for each memory section.  That way we finally can
tell which piece of memory belongs to which physical device.

This makes s390's /sys/devices/system/memory/memoryX/phys_device display
the correct thing?
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

/sys/devices/system/memory/memoryX/phys_device is supposed to contain the
number of the physical device that the corresponding piece of memory
belongs to.

In case a physical device should be replaced or taken offline for whatever
reason it is necessary to set all corresponding memory pieces offline.
The current implementation always sets phys_device to '0' and there is no
way or hook to change that.  Seems like there was a plan to implement that
but it wasn't finished for whatever reason.

So add a weak function which architectures can override to actually set
the phys_device from within add_memory_block().
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Replace open-coded loop with for_each_set_bit().
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Cc: Clemens Ladisch <clemens@ladisch.de>
Cc: Bob Picco <bob.picco@hp.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Use bitmap_weight() instead of doing hweight32() for each u32 element in
the page.
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Cc: Anton Altaparmakov <aia21@cantab.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

jffs2 uses rb_node = NULL; to zero rb_root.

The problem with this is that 17d9ddc7 ("rbtree: Add
support for augmented rbtrees") in the linux-next tree adds a new field
to that struct which needs to be NULL as well.  This patch uses RB_ROOT
as the intializer so all of the relevant fields will be NULL'd.
Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: Eric Paris <eparis@redhat.com>
Acked-by: NDavid Woodhouse <dwmw2@infradead.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

swap_cgroup uses 2bytes data and uses cmpxchg in a new operation.  2byte
cmpxchg/xchg is not available on some archs.  This patch replaces
cmpxchg/xchg with operations under lock.
Signed-off-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Reported-by: Sachin Sant <sachinp@in.ibm.com> wrote:
Acked-by: NBalbir Singh <balbir@in.ibm.com>
Acked-by: NDaisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Cc: Li Zefan <lizf@cn.fujitsu.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Update the dummy LL interface to the LL interface change
introduced by commit daab433c03c15fd642c71c94eb51bdd3f32602c8.
This fixes the build failure occurring after that commit when
enabling ISDN_DRV_GIGASET but neither ISDN_I4L nor ISDN_CAPI.

Impact: bugfix
Signed-off-by: NTilman Schmidt <tilman@imap.cc>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Otherwise we get a warning from the call in br_forward().
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Without CONFIG_BRIDGE_IGMP_SNOOPING,
BR_INPUT_SKB_CB(skb)->mrouters_only is not appropriately
initialized, so we can see garbage.

A clear option to fix this is to set it even without that
config, but we cannot optimize out the branch.

Let's introduce a macro that returns value of mrouters_only
and let it return 0 without CONFIG_BRIDGE_IGMP_SNOOPING.
Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

route: Fix caught BUG_ON during rt_secret_rebuild_oneshot()

Call rt_secret_rebuild can cause BUG_ON(timer_pending(&net->ipv4.rt_secret_timer)) in
add_timer as there is not any synchronization for call rt_secret_rebuild_oneshot()
for the same net namespace.

Also this issue affects to rt_secret_reschedule().

Thus use mod_timer enstead.
Signed-off-by: NVitaliy Gusev <vgusev@openvz.org>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Stanse found that one error path in netpoll_setup dereferences npinfo
even though it is NULL. Avoid that by adding new label and go to that
instead.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Daniel Borkmann <danborkmann@googlemail.com>
Cc: David S. Miller <davem@davemloft.net>
Acked-by: chavey@google.com
Acked-by: NMatt Mackall <mpm@selenic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

So in the forward porting of various tipc packages, I was constantly
getting this lockdep warning everytime I used tipc-config to set a network
address for the protocol:

[ INFO: possible circular locking dependency detected ]
2.6.33 #1
tipc-config/1326 is trying to acquire lock:
(ref_table_lock){+.-...}, at: [<ffffffffa0315148>] tipc_ref_discard+0x53/0xd4 [tipc]

but task is already holding lock:
(&(&entry->lock)->rlock#2){+.-...}, at: [<ffffffffa03150d5>] tipc_ref_lock+0x43/0x63 [tipc]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&(&entry->lock)->rlock#2){+.-...}:
[<ffffffff8107b508>] __lock_acquire+0xb67/0xd0f
[<ffffffff8107b78c>] lock_acquire+0xdc/0x102
[<ffffffff8145471e>] _raw_spin_lock_bh+0x3b/0x6e
[<ffffffffa03152b1>] tipc_ref_acquire+0xe8/0x11b [tipc]
[<ffffffffa031433f>] tipc_createport_raw+0x78/0x1b9 [tipc]
[<ffffffffa031450b>] tipc_createport+0x8b/0x125 [tipc]
[<ffffffffa030f221>] tipc_subscr_start+0xce/0x126 [tipc]
[<ffffffffa0308fb2>] process_signal_queue+0x47/0x7d [tipc]
[<ffffffff81053e0c>] tasklet_action+0x8c/0xf4
[<ffffffff81054bd8>] __do_softirq+0xf8/0x1cd
[<ffffffff8100aadc>] call_softirq+0x1c/0x30
[<ffffffff810549f4>] _local_bh_enable_ip+0xb8/0xd7
[<ffffffff81054a21>] local_bh_enable_ip+0xe/0x10
[<ffffffff81454d31>] _raw_spin_unlock_bh+0x34/0x39
[<ffffffffa0308eb8>] spin_unlock_bh.clone.0+0x15/0x17 [tipc]
[<ffffffffa0308f47>] tipc_k_signal+0x8d/0xb1 [tipc]
[<ffffffffa0308dd9>] tipc_core_start+0x8a/0xad [tipc]
[<ffffffffa01b1087>] 0xffffffffa01b1087
[<ffffffff8100207d>] do_one_initcall+0x72/0x18a
[<ffffffff810872fb>] sys_init_module+0xd8/0x23a
[<ffffffff81009b42>] system_call_fastpath+0x16/0x1b

-> #0 (ref_table_lock){+.-...}:
[<ffffffff8107b3b2>] __lock_acquire+0xa11/0xd0f
[<ffffffff8107b78c>] lock_acquire+0xdc/0x102
[<ffffffff81454836>] _raw_write_lock_bh+0x3b/0x6e
[<ffffffffa0315148>] tipc_ref_discard+0x53/0xd4 [tipc]
[<ffffffffa03141ee>] tipc_deleteport+0x40/0x119 [tipc]
[<ffffffffa0316e35>] release+0xeb/0x137 [tipc]
[<ffffffff8139dbf4>] sock_release+0x1f/0x6f
[<ffffffff8139dc6b>] sock_close+0x27/0x2b
[<ffffffff811116f6>] __fput+0x12a/0x1df
[<ffffffff811117c5>] fput+0x1a/0x1c
[<ffffffff8110e49b>] filp_close+0x68/0x72
[<ffffffff8110e552>] sys_close+0xad/0xe7
[<ffffffff81009b42>] system_call_fastpath+0x16/0x1b

Finally decided I should fix this.  Its a straightforward inversion,
tipc_ref_acquire takes two locks in this order:
ref_table_lock
entry->lock

while tipc_deleteport takes them in this order:
entry->lock (via tipc_port_lock())
ref_table_lock (via tipc_ref_discard())

when the same entry is referenced, we get the above warning.  The fix is equally
straightforward.  Theres no real relation between the entry->lock and the
ref_table_lock (they just are needed at the same time), so move the entry->lock
aquisition in tipc_ref_acquire down, after we unlock ref_table_lock (this is
safe since the ref_table_lock guards changes to the reference table, and we've
already claimed a slot there.  I've tested the below fix and confirmed that it
clears up the lockdep issue
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
CC: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes UDP socket refcnt bugs in the pppol2tp driver.

A bug can cause a kernel stack trace when a tunnel socket is closed.

A way to reproduce the issue is to prepare the UDP socket for L2TP (by
opening a tunnel pppol2tp socket) and then close it before any L2TP
sessions are added to it. The sequence is

Create UDP socket
Create tunnel pppol2tp socket to prepare UDP socket for L2TP
  pppol2tp_connect: session_id=0, peer_session_id=0
L2TP SCCRP control frame received (tunnel_id==0)
  pppol2tp_recv_core: sock_hold()
  pppol2tp_recv_core: sock_put
L2TP ZLB control frame received (tunnel_id=nnn)
  pppol2tp_recv_core: sock_hold()
  pppol2tp_recv_core: sock_put
Close tunnel management socket
  pppol2tp_release: session_id=0, peer_session_id=0
Close UDP socket
  udp_lib_close: BUG

The addition of sock_hold() in pppol2tp_connect() solves the problem.

For data frames, two sock_put() calls were added to plug a refcnt leak
per received data frame. The ref that is grabbed at the top of
pppol2tp_recv_core() must always be released, but this wasn't done for
accepted data frames or data frames discarded because of bad UDP
checksums. This leak meant that any UDP socket that had passed L2TP
data traffic (i.e. L2TP data frames, not just L2TP control frames)
using pppol2tp would not be released by the kernel.

WARNING: at include/net/sock.h:435 udp_lib_unhash+0x117/0x120()
Pid: 1086, comm: openl2tpd Not tainted 2.6.33-rc1 #8
Call Trace:
 [<c119e9b7>] ? udp_lib_unhash+0x117/0x120
 [<c101b871>] ? warn_slowpath_common+0x71/0xd0
 [<c119e9b7>] ? udp_lib_unhash+0x117/0x120
 [<c101b8e3>] ? warn_slowpath_null+0x13/0x20
 [<c119e9b7>] ? udp_lib_unhash+0x117/0x120
 [<c11598a7>] ? sk_common_release+0x17/0x90
 [<c11a5e33>] ? inet_release+0x33/0x60
 [<c11577b0>] ? sock_release+0x10/0x60
 [<c115780f>] ? sock_close+0xf/0x30
 [<c106e542>] ? __fput+0x52/0x150
 [<c106b68e>] ? filp_close+0x3e/0x70
 [<c101d2e2>] ? put_files_struct+0x62/0xb0
 [<c101eaf7>] ? do_exit+0x5e7/0x650
 [<c1081623>] ? mntput_no_expire+0x13/0x70
 [<c106b68e>] ? filp_close+0x3e/0x70
 [<c101eb8a>] ? do_group_exit+0x2a/0x70
 [<c101ebe1>] ? sys_exit_group+0x11/0x20
 [<c10029b0>] ? sysenter_do_call+0x12/0x26
Signed-off-by: NJames Chapman <jchapman@katalix.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch ensures the PHY correctly completes its reset before
setting register values.
Signed-off-by: NSteve Glendinning <steve.glendinning@smsc.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When transmitting L2TP frames, we derive the outgoing interface's UDP
checksum hardware assist capabilities from the tunnel dst dev. This
can sometimes be NULL, especially when routing protocols are used and
routing changes occur. This patch just checks for NULL dst or dev
pointers when checking for netdev hardware assist features.

BUG: unable to handle kernel NULL pointer dereference at 0000000c
IP: [<f89d074c>] pppol2tp_xmit+0x341/0x4da [pppol2tp]
*pde = 00000000
Oops: 0000 [#1] SMP
last sysfs file: /sys/class/net/lo/operstate
Modules linked in: pppol2tp pppox ppp_generic slhc ipv6 dummy loop snd_hda_codec_atihdmi snd_hda_intel snd_hda_codec snd_pcm snd_timer snd soundcore snd_page_alloc evdev psmouse serio_raw processor button i2c_piix4 i2c_core ati_agp agpgart pcspkr ext3 jbd mbcache sd_mod ide_pci_generic atiixp ide_core ahci ata_generic floppy ehci_hcd ohci_hcd libata e1000e scsi_mod usbcore nls_base thermal fan thermal_sys [last unloaded: scsi_wait_scan]

Pid: 0, comm: swapper Not tainted (2.6.32.8 #1)
EIP: 0060:[<f89d074c>] EFLAGS: 00010297 CPU: 3
EIP is at pppol2tp_xmit+0x341/0x4da [pppol2tp]
EAX: 00000000 EBX: f64d1680 ECX: 000005b9 EDX: 00000000
ESI: f6b91850 EDI: f64d16ac EBP: f6a0c4c0 ESP: f70a9cac
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process swapper (pid: 0, ti=f70a8000 task=f70a31c0 task.ti=f70a8000)
Stack:
 000005a9 000005b9 f734c400 f66652c0 f7352e00 f67dc800 00000000 f6b91800
<0> 000005a3 f70ef6c4 f67dcda9 000005a3 f89b192e 00000246 000005a3 f64d1680
<0> f63633e0 f6363320 f64d1680 f65a7320 f65a7364 f65856c0 f64d1680 f679f02f
Call Trace:
 [<f89b192e>] ? ppp_push+0x459/0x50e [ppp_generic]
 [<f89b217f>] ? ppp_xmit_process+0x3b6/0x430 [ppp_generic]
 [<f89b2306>] ? ppp_start_xmit+0x10d/0x120 [ppp_generic]
 [<c11c15cb>] ? dev_hard_start_xmit+0x21f/0x2b2
 [<c11d0947>] ? sch_direct_xmit+0x48/0x10e
 [<c11c19a0>] ? dev_queue_xmit+0x263/0x3a6
 [<c11e2a9f>] ? ip_finish_output+0x1f7/0x221
 [<c11df682>] ? ip_forward_finish+0x2e/0x30
 [<c11de645>] ? ip_rcv_finish+0x295/0x2a9
 [<c11c0b19>] ? netif_receive_skb+0x3e9/0x404
 [<f814b791>] ? e1000_clean_rx_irq+0x253/0x2fc [e1000e]
 [<f814cb7a>] ? e1000_clean+0x63/0x1fc [e1000e]
 [<c1047eff>] ? sched_clock_local+0x15/0x11b
 [<c11c1095>] ? net_rx_action+0x96/0x195
 [<c1035750>] ? __do_softirq+0xaa/0x151
 [<c1035828>] ? do_softirq+0x31/0x3c
 [<c10358fe>] ? irq_exit+0x26/0x58
 [<c1004b21>] ? do_IRQ+0x78/0x89
 [<c1003729>] ? common_interrupt+0x29/0x30
 [<c101ac28>] ? native_safe_halt+0x2/0x3
 [<c1008c54>] ? default_idle+0x55/0x75
 [<c1009045>] ? c1e_idle+0xd2/0xd5
 [<c100233c>] ? cpu_idle+0x46/0x62
Code: 8d 45 08 f0 ff 45 08 89 6b 08 c7 43 68 7e fb 9c f8 8a 45 24 83 e0 0c 3c 04 75 09 80 63 64 f3 e9 b4 00 00 00 8b 43 18 8b 4c 24 04 <8b> 40 0c 8d 79 11 f6 40 44 0e 8a 43 64 75 51 6a 00 8b 4c 24 08
EIP: [<f89d074c>] pppol2tp_xmit+0x341/0x4da [pppol2tp] SS:ESP 0068:f70a9cac
CR2: 000000000000000c
Signed-off-by: NJames Chapman <jchapman@katalix.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch adds a driver for SMSC's LAN7500 family of USB 2.0
to gigabit ethernet adapters.  It's loosely based on the smsc95xx
driver but the device registers for LAN7500 are completely different.
Signed-off-by: NSteve Glendinning <steve.glendinning@smsc.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes following warning introduced by commit
12bac0d9 ("proc: warn on non-existing
proc entries"):

WARNING: at /work/mips-linux/make/linux/fs/proc/generic.c:316 __xlate_proc_name+0xe0/0xe8()
name 'RBHMA4X00/RTL8019'
Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Stanse found that one error path (when alloc_skb fails) in netdev_tx
omits to unlock hw_priv->hwlock. Fix that.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Tristram Ha <Tristram.Ha@micrel.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Correct a potential array overrun due to an off by one error in the
range check on the CAPI CONNECT_REQ CIPValue parameter.
Found and reported by Dan Carpenter using smatch.

Impact: bugfix
Signed-off-by: NTilman Schmidt <tilman@imap.cc>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If we are doing a forced shutdown, we can get lots of noise about
delalloc pages being discarded. This is happens by design during a
forced shutdown, so don't spam the logs with these messages.
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NAlex Elder <aelder@sgi.com>

Re-apply a commit that had been reverted due to regressions
that have since been fixed.

    From 95f8e302 Mon Sep 17 00:00:00 2001
    From: Nick Piggin <npiggin@suse.de>
    Date: Tue, 6 Jan 2009 14:43:09 +1100

    Implement XFS's large buffer support with the new vmap APIs. See the vmap
    rewrite (db64fe02) for some numbers. The biggest improvement that comes from
    using the new APIs is avoiding the global KVA allocation lock on every call.
Signed-off-by: NNick Piggin <npiggin@suse.de>
Reviewed-by: NChristoph Hellwig <hch@infradead.org>
Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>

Only modifications here were a minor reformat, plus making the patch
apply given the new use of xfs_buf_is_vmapped().
Modified-by: NAlex Elder <aelder@sgi.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NAlex Elder <aelder@sgi.com>

Re-apply a commit that had been reverted due to regressions
that have since been fixed.

    Original commit: d2859751
    Author: Nick Piggin <npiggin@suse.de>
    Date: Tue, 6 Jan 2009 14:40:44 +1100

    XFS's vmap batching simply defers a number (up to 64) of vunmaps,
    and keeps track of them in a list. To purge the batch, it just goes
    through the list and calls vunamp on each one. This is pretty poor:
    a global TLB flush is generally still performed on each vunmap, with
    the most expensive parts of the operation being the broadcast IPIs
    and locking involved in the SMP callouts, and the locking involved
    in the vmap management -- none of these are avoided by just batching
    up the calls. I'm actually surprised it ever made much difference.
    (Now that the lazy vmap allocator is upstream, this description is
    not quite right, but the vunmap batching still doesn't seem to do
    much).

    Rip all this logic out of XFS completely. I will improve vmap
    performance and scalability directly in subsequent patch.
Signed-off-by: NNick Piggin <npiggin@suse.de>
Reviewed-by: NChristoph Hellwig <hch@infradead.org>
Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>

The only change I made was to use the "new" xfs_buf_is_vmapped()
function in a place it had been open-coded in the original.
Modified-by: NAlex Elder <aelder@sgi.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NAlex Elder <aelder@sgi.com>

If we were to dynamically register/unregister leds and have udev or other
daemons handle the leds class uevents, we would be notified of the adding of a
new LED and if the daemon immediately tries to open one of the attributes of
the led device, it would fail with a "no such file or directory" error since
this the attributes are not yet created. Fix this by switching attributes to be
class-wide, such that the driver core will register these attributes with
device_add_attrs and then emit the kobject_uevent ADD signal.
Signed-off-by: NFainelli <ffainelli@freebox.fr>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

The driver wrongly sets default state for LEDs that don't specify
default-state property.

Currently the driver handles default state this way:

memset(&led, 0, sizeof(led));
for_each_child_of_node(np, child) {
	state = of_get_property(child, "default-state", NULL);
	if (state) {
		if (!strcmp(state, "keep"))
			led.default_state = LEDS_GPIO_DEFSTATE_KEEP;
		...
	}
	ret = create_gpio_led(&led, ...);
}

Which means that all LEDs that do not specify default-state will inherit
the last value of the default-state property, which is wrong.

This patch fixes the issue by moving LED's template initialization into
the loop body.
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

This patch adds an LED driver to support the Dell Activity LED on the
Dell Latitude 2100 netbook and future products to come. The Activity LED
is visible externally in the lid so classroom instructors can observe it
from a distance. The driver uses the sysfs led_class and provides a
standard LED interface.

Signed-off by: Bob Rodgers <Robert_Rodgers@dell.com>
Signed-off-by: NLouis Davis <Louis_Davis@dell.com>
Signed-off-by: Jim Dailey <Jim_Dailey@dell.com>, Developers
Acked-by: NMatthew Garrett <mjg@redhat.com>
Acked-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Remove the need for "depends on LEDS_CLASS" by wrapping the affected
config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS".

LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot
be selected to build as a module.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

As each led device gets registered a kernel message gets printed. In
an embedded system with a number of leds this can produce a lot
of output that just looks like noise.

Change the message type to KERN_DEBUG since it might be useful
in the dmesg output "after" booting.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

The id_table field of the struct pci_driver is constant in <linux/pci.h>
so it is worth to make pci_device_id also constant.

The semantic match that finds this kind of pattern is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r@
disable decl_init,const_decl_init;
identifier I1, I2, x;
@@
	struct I1 {
	  ...
	  const struct I2 *x;
	  ...
	};
@s@
identifier r.I1, y;
identifier r.x, E;
@@
	struct I1 y = {
	  .x = E,
	};
@c@
identifier r.I2;
identifier s.E;
@@
	const struct I2 E[] = ... ;
@depends on !c@
identifier r.I2;
identifier s.E;
@@
+	const
	struct I2 E[] = ...;
// </smpl>
Signed-off-by: NMárton Németh <nm127@freemail.hu>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

The ALIX2 LED driver and the CS5535 GPIO drivers share the same I/O
range which causes a conflict if they're both enabled. Fix this for now
by adding Kconfig dependencies. While at it, also drop the EXPERIMENTAL
flag, as the code has been around for awhile already.

Note that this is a hack. At some point, a real platform support for
this board should be added which handles the LEDs via the leds-gpio
driver.
Signed-off-by: NDaniel Mack <daniel@caiaq.de>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Stanse found that one error path (when alloc_skb fails) in netdev_tx
omits to unlock hw_priv->hwlock. Fix that by moving away from unlock in
each fail path. Unlock at one place instead.

Introduced in 94a819f8
(pcmcia: assert locking to struct pcmcia_device)
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

From: Julia Lawall <julia@diku.dk>

SAB82532_ISR0_TCD is declared in drivers/serial/subsab.h as relating to a
status register, while SAB82532_IMR0_TCD is declared in the same file as
relating to a mask register.  The latter seems more appropriate for the
interrupt_mask0 field, and follows the strategy for initializing this field
elsewhere in the same file.

Both SAB82532_ISR0_TCD and SAB82532_IMR0_TCD have the same value.
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>