Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Apr 22, 2011
  1. Merge branch 'configs-2.6.38' into pf-2.6.38

    Oleksandr Natalenko authored
  2. configs-2.6.38: update config for Dell Inspiron 1525 laptop

    Oleksandr Natalenko authored
  3. Merge branch 'version-2.6.38' into pf-2.6.38

    Oleksandr Natalenko authored
  4. version-2.6.38: bump version to 2.6.38-pf6

    Oleksandr Natalenko authored
  5. fix merge conflict

    Oleksandr Natalenko authored
  6. @NigelCunningham
Commits on Apr 21, 2011
  1. @gregkh

    Linux 2.6.38.4

    gregkh authored
  2. @gregkh

    ip: ip_options_compile() resilient to NULL skb route

    Eric Dumazet authored gregkh committed
    commit c65353d upstream.
    
    Scot Doyle demonstrated ip_options_compile() could be called with an skb
    without an attached route, using a setup involving a bridge, netfilter,
    and forged IP packets.
    
    Let's make ip_options_compile() and ip_options_rcv_srr() a bit more
    robust, instead of changing bridge/netfilter code.
    
    With help from Hiroaki SHIMODA.
    
    Reported-by: Scot Doyle <lkml@scotdoyle.com>
    Tested-by: Scot Doyle <lkml@scotdoyle.com>
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Stephen Hemminger <shemminger@vyatta.com>
    Acked-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @gregkh

    bridge: reset IPCB in br_parse_ip_options

    Eric Dumazet authored gregkh committed
    commit f8e9881 upstream.
    
    Commit 462fb2a (bridge : Sanitize skb before it enters the IP
    stack), missed one IPCB init before calling ip_options_compile()
    
    Thanks to Scot Doyle for his tests and bug reports.
    
    Reported-by: Scot Doyle <lkml@scotdoyle.com>
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
    Acked-by: Bandan Das <bandan.das@stratus.com>
    Acked-by: Stephen Hemminger <shemminger@vyatta.com>
    Cc: Jan Lübbe <jluebbe@debian.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @jkkm @gregkh

    perf tool: Fix gcc 4.6.0 issues

    jkkm authored gregkh committed
    commit fb7d0b3 upstream.
    
    GCC 4.6.0 in Fedora rawhide turned up some compile errors in tools/perf
    due to the -Werror=unused-but-set-variable flag.
    
    I've gone through and annotated some of the assignments that had side
    effects (ie: return value from a function) with the __used annotation,
    and in some cases, just removed unused code.
    
    In a few cases, we were assigning something useful, but not using it in
    later parts of the function.
    
    kyle@dreadnought:~/src% gcc --version
    gcc (GCC) 4.6.0 20110122 (Red Hat 4.6.0-0.3)
    
    Cc: Ingo Molnar <mingo@redhat.com>
    LKML-Reference: <20110124161304.GK27353@bombadil.infradead.org>
    Signed-off-by: Kyle McMartin <kyle@redhat.com>
    [ committer note: Fixed up the annotation fixes, as that code moved recently ]
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    [Backported to 2.6.38.2 by deleting unused but set variables]
    Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @gregkh

    Bluetooth: Fix HCI_RESET command synchronization

    Gustavo F. Padovan authored gregkh committed
    commit f630cf0 upstream.
    
    We can't send new commands before a cmd_complete for the HCI_RESET command
    shows up.
    
    Reported-by: Mikko Vinni <mmvinni@yahoo.com>
    Reported-by: Justin P. Mattock <justinmattock@gmail.com>
    Reported-by: Ed Tomlinson <edt@aei.ca>
    Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
    Tested-by: Justin P. Mattock <justinmattock@gmail.com>
    Tested-by: Mikko Vinni <mmvinni@yahoo.com>
    Tested-by: Ed Tomlinson <edt@aei.ca>
  6. @gregkh

    radeon: Fix KMS CP writeback on big endian machines.

    Michel Dänzer authored gregkh committed
    commit dc66b32 upstream.
    
    This is necessary even with PCI(e) GART, and it makes writeback work even with
    AGP on my PowerBook. Might still be unreliable with older revisions of UniNorth
    and other AGP bridges though.
    
    Signed-off-by: Michel Dänzer <daenzer@vmware.com>
    Reviewed-by: Alex Deucher <alex.deucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. @gregkh

    USB: Fix unplug of device with active streams

    Matthew Wilcox authored gregkh committed
    commit b214f19 upstream.
    
    If I unplug a device while the UAS driver is loaded, I get an oops
    in usb_free_streams().  This is because usb_unbind_interface() calls
    usb_disable_interface() which calls usb_disable_endpoint() which sets
    ep_out and ep_in to NULL.  Then the UAS driver calls usb_pipe_endpoint()
    which returns a NULL pointer and passes an array of NULL pointers to
    usb_free_streams().
    
    I think the correct fix for this is to check for the NULL pointer
    in usb_free_streams() rather than making the driver check for this
    situation.  My original patch for this checked for dev->state ==
    USB_STATE_NOTATTACHED, but the call to usb_disable_interface() is
    conditional, so not all drivers would want this check.
    
    Note from Sarah Sharp: This patch does avoid a potential dereference,
    but the real fix (which will be implemented later) is to set the
    .soft_unbind flag in the usb_driver structure for the UAS driver, and
    all drivers that allocate streams.  The driver should free any streams
    when it is unbound from the interface.  This avoids leaking stream rings
    in the xHCI driver when usb_disable_interface() is called.
    
    This should be queued for stable trees back to 2.6.35.
    
    Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  8. @gregkh

    USB: xhci - also free streams when resetting devices

    Dmitry Torokhov authored gregkh committed
    commit 2dea75d upstream.
    
    Currently, when resetting a device, xHCI driver disables all but one
    endpoints and frees their rings, but leaves alone any streams that
    might have been allocated. Later, when users try to free allocated
    streams, we oops in xhci_setup_no_streams_ep_input_ctx() because
    ep->ring is NULL.
    
    Let's free not only rings but also stream data as well, so that
    calling free_streams() on a device that was reset will be safe.
    
    This should be queued for stable trees back to 2.6.35.
    
    Reviewed-by: Micah Elizabeth Scott <micah@vmware.com>
    Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @gregkh

    USB: xhci - fix math in xhci_get_endpoint_interval()

    Dmitry Torokhov authored gregkh committed
    commit dfa49c4 upstream.
    
    When parsing exponent-expressed intervals we subtract 1 from the
    value and then expect it to match with original + 1, which is
    highly unlikely, and we end with frequent spew:
    
    	usb 3-4: ep 0x83 - rounding interval to 512 microframes
    
    Also, parsing interval for fullspeed isochronous endpoints was
    incorrect - according to USB spec they use exponent-based
    intervals (but xHCI spec claims frame-based intervals). I trust
    USB spec more, especially since USB core agrees with it.
    
    This should be queued for stable kernels back to 2.6.31.
    
    Reviewed-by: Micah Elizabeth Scott <micah@vmware.com>
    Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @gregkh

    USB: xhci - fix unsafe macro definitions

    Dmitry Torokhov authored gregkh committed
    commit 5a6c2f3 upstream.
    
    Macro arguments used in expressions need to be enclosed in parenthesis
    to avoid unpleasant surprises.
    
    This should be queued for kernels back to 2.6.31
    
    Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. @gregkh

    USB: fix formatting of SuperSpeed endpoints in /proc/bus/usb/devices

    Dmitry Torokhov authored gregkh committed
    commit 2868a2b upstream.
    
    Isochronous and interrupt SuperSpeed endpoints use the same mechanisms
    for decoding bInterval values as HighSpeed ones so adjust the code
    accordingly.
    
    Also bandwidth reservation for SuperSpeed matches highspeed, not
    low/full speed.
    
    Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @gregkh

    USB: EHCI: unlink unused QHs when the controller is stopped

    Alan Stern authored gregkh committed
    commit 94ae497 upstream.
    
    This patch (as1458) fixes a problem affecting ultra-reliable systems:
    When hardware failover of an EHCI controller occurs, the data
    structures do not get released correctly.  This is because the routine
    responsible for removing unused QHs from the async schedule assumes
    the controller is running properly (the frame counter is used in
    determining how long the QH has been idle) -- but when a failover
    causes the controller to be electronically disconnected from the PCI
    bus, obviously it stops running.
    
    The solution is simple: Allow scan_async() to remove a QH from the
    async schedule if it has been idle for long enough _or_ if the
    controller is stopped.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-Tested-by: Dan Duval <dan.duval@stratus.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @hardys @gregkh

    usb: qcserial add missing errorpath kfrees

    hardys authored gregkh committed
    commit cb62d65 upstream.
    
    There are two -ENODEV error paths in qcprobe where the allocated private
    data is not freed, this patch adds the two missing kfrees to avoid
    leaking memory on the error path
    
    Signed-off-by: Steven Hardy <shardy@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. @hardys @gregkh

    usb: qcserial avoid pointing to freed memory

    hardys authored gregkh committed
    commit 99ab3f9 upstream.
    
    Rework the qcprobe logic such that serial->private is not set when
    qcprobe exits with -ENODEV, otherwise serial->private will point to freed
    memory on -ENODEV
    
    Signed-off-by: Steven Hardy <shardy@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. @hardys @gregkh

    usb: Fix qcserial memory leak on rmmod

    hardys authored gregkh committed
    commit 10c9ab1 upstream.
    
    qcprobe function allocates serial->private but this is never freed, this
    patch adds a new function qc_release() which frees serial->private, after
    calling usb_wwan_release
    
    Signed-off-by: Steven Hardy <shardy@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. @khers @gregkh

    powerpc/perf_event: Skip updating kernel counters if register value s…

    khers authored gregkh committed
    …hrinks
    
    commit 86c74ab upstream.
    
    Because of speculative event roll back, it is possible for some event coutners
    to decrease between reads on POWER7.  This causes a problem with the way that
    counters are updated.  Delta calues are calculated in a 64 bit value and the
    top 32 bits are masked.  If the register value has decreased, this leaves us
    with a very large positive value added to the kernel counters.  This patch
    protects against this by skipping the update if the delta would be negative.
    This can lead to a lack of precision in the coutner values, but from my testing
    the value is typcially fewer than 10 samples at a time.
    
    Signed-off-by: Eric B Munson <emunson@mgebm.net>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  17. @antonblanchard @gregkh

    powerpc: Fix oops if scan_dispatch_log is called too early

    antonblanchard authored gregkh committed
    commit 84ffae5 upstream.
    
    We currently enable interrupts before the dispatch log for the boot
    cpu is setup. If a timer interrupt comes in early enough we oops in
    scan_dispatch_log:
    
    Unable to handle kernel paging request for data at address 0x00000010
    
    ...
    
    .scan_dispatch_log+0xb0/0x170
    .account_system_vtime+0xa0/0x220
    .irq_enter+0x88/0xc0
    .do_IRQ+0x48/0x230
    
    The patch below adds a check to scan_dispatch_log to ensure the
    dispatch log has been allocated.
    
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  18. @torvalds @gregkh

    proc: do proper range check on readdir offset

    torvalds authored gregkh committed
    commit d8bdc59 upstream.
    
    Rather than pass in some random truncated offset to the pid-related
    functions, check that the offset is in range up-front.
    
    This is just cleanup, the previous commit fixed the real problem.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  19. @torvalds @gregkh

    next_pidmap: fix overflow condition

    torvalds authored gregkh committed
    commit c78193e upstream.
    
    next_pidmap() just quietly accepted whatever 'last' pid that was passed
    in, which is not all that safe when one of the users is /proc.
    
    Admittedly the proc code should do some sanity checking on the range
    (and that will be the next commit), but that doesn't mean that the
    helper functions should just do that pidmap pointer arithmetic without
    checking the range of its arguments.
    
    So clamp 'last' to PID_MAX_LIMIT.  The fact that we then do "last+1"
    doesn't really matter, the for-loop does check against the end of the
    pidmap array properly (it's only the actual pointer arithmetic overflow
    case we need to worry about, and going one bit beyond isn't going to
    overflow).
    
    [ Use PID_MAX_LIMIT rather than pid_max as per Eric Biederman ]
    
    Reported-by: Tavis Ormandy <taviso@cmpxchg8b.com>
    Analyzed-by: Robert Święcki <robert@swiecki.net>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Cc: Pavel Emelyanov <xemul@openvz.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  20. @mkotsbak @gregkh

    USB: option: Added support for Samsung GT-B3730/GT-B3710 LTE USB modem.

    mkotsbak authored gregkh committed
    commit 80f9df3 upstream.
    
    Bind only modem AT command endpoint to option.
    
    Signed-off-by: Marius B. Kotsbak <marius@kotsbak.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  21. @gregkh

    USB: ftdi_sio: add ids for Hameg HO720 and HO730

    Paul Friedrich authored gregkh committed
    commit c53c2fa upstream.
    
    usb serial: ftdi_sio: add two missing USB ID's for Hameg interfaces HO720
    and HO730
    
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  22. @jhovold @gregkh

    USB: ftdi_sio: add PID for OCT DK201 docking station

    jhovold authored gregkh committed
    commit 11a31d8 upstream.
    
    Add PID 0x0103 for serial port of the OCT DK201 docking station.
    
    Reported-by: Jan Hoogenraad <jan@hoogenraad.net>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  23. @simonswine @gregkh

    USB: ftdi_sio: Added IDs for CTI USB Serial Devices

    simonswine authored gregkh committed
    commit 5a9443f upstream.
    
    I added new ProdutIds for two devices from CTI GmbH Leipzig.
    
    Signed-off-by: Christian Simon <simon@swine.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  24. @gregkh

    usb: musb: temporarily make it bool

    Felipe Balbi authored gregkh committed
    commit 7a180e7 upstream.
    
    Due to the recent changes to musb's glue layers,
    we can't compile musb-hdrc as a module - compilation
    will break due to undefined symbol musb_debug. In
    order to fix that, we need a big re-work of the
    debug support on the MUSB driver.
    
    Because that would mean a lot of new code coming
    into the -rc series, it's best to defer that to
    next merge window and for now just disable module
    support for MUSB.
    
    Once we get the refactor of the debugging support
    done, we can simply revert this patch and things
    will go back to normal again.
    
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  25. @gregkh

    brk: COMPAT_BRK: fix detection of randomized brk

    Jiri Kosina authored gregkh committed
    commit 4471a67 upstream.
    
    5520e89 ("brk: fix min_brk lower bound computation for COMPAT_BRK")
    tried to get the whole logic of brk randomization for legacy
    (libc5-based) applications finally right.
    
    It turns out that the way to detect whether brk has actually been
    randomized in the end or not introduced by that patch still doesn't work
    for those binaries, as reported by Geert:
    
    : /sbin/init from my old m68k ramdisk exists prematurely.
    :
    : Before the patch:
    :
    : | brk(0x80005c8e)                         = 0x80006000
    :
    : After the patch:
    :
    : | brk(0x80005c8e)                         = 0x80005c8e
    :
    : Old libc5 considers brk() to have failed if the return value is not
    : identical to the requested value.
    
    I don't like it, but currently see no better option than a bit flag in
    task_struct to catch the CONFIG_COMPAT_BRK && randomize_va_space == 2
    case.
    
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  26. @kosaki @gregkh

    vmscan: all_unreclaimable() use zone->all_unreclaimable as a name

    kosaki authored gregkh committed
    commit 929bea7 upstream.
    
    all_unreclaimable check in direct reclaim has been introduced at 2.6.19
    by following commit.
    
    	2006 Sep 25; commit 408d854; oom: use unreclaimable info
    
    And it went through strange history. firstly, following commit broke
    the logic unintentionally.
    
    	2008 Apr 29; commit a41f24e; page allocator: smarter retry of
    				      costly-order allocations
    
    Two years later, I've found obvious meaningless code fragment and
    restored original intention by following commit.
    
    	2010 Jun 04; commit bb21c7c; vmscan: fix do_try_to_free_pages()
    				      return value when priority==0
    
    But, the logic didn't works when 32bit highmem system goes hibernation
    and Minchan slightly changed the algorithm and fixed it .
    
    	2010 Sep 22: commit d190836: vmscan: check all_unreclaimable
    				      in direct reclaim path
    
    But, recently, Andrey Vagin found the new corner case. Look,
    
    	struct zone {
    	  ..
    	        int                     all_unreclaimable;
    	  ..
    	        unsigned long           pages_scanned;
    	  ..
    	}
    
    zone->all_unreclaimable and zone->pages_scanned are neigher atomic
    variables nor protected by lock.  Therefore zones can become a state of
    zone->page_scanned=0 and zone->all_unreclaimable=1.  In this case, current
    all_unreclaimable() return false even though zone->all_unreclaimabe=1.
    
    This resulted in the kernel hanging up when executing a loop of the form
    
    1. fork
    2. mmap
    3. touch memory
    4. read memory
    5. munmmap
    
    as described in
    http://www.gossamer-threads.com/lists/linux/kernel/1348725#1348725
    
    Is this ignorable minor issue?  No.  Unfortunately, x86 has very small dma
    zone and it become zone->all_unreclamble=1 easily.  and if it become
    all_unreclaimable=1, it never restore all_unreclaimable=0.  Why?  if
    all_unreclaimable=1, vmscan only try DEF_PRIORITY reclaim and
    a-few-lru-pages>>DEF_PRIORITY always makes 0.  that mean no page scan at
    all!
    
    Eventually, oom-killer never works on such systems.  That said, we can't
    use zone->pages_scanned for this purpose.  This patch restore
    all_unreclaimable() use zone->all_unreclaimable as old.  and in addition,
    to add oom_killer_disabled check to avoid reintroduce the issue of commit
    d190836 ("vmscan: check all_unreclaimable in direct reclaim path").
    
    Reported-by: Andrey Vagin <avagin@openvz.org>
    Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Nick Piggin <npiggin@kernel.dk>
    Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
    Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  27. @gregkh

    sched: Fix erroneous all_pinned logic

    Ken Chen authored gregkh committed
    commit b30aef1 upstream.
    
    The scheduler load balancer has specific code to deal with cases of
    unbalanced system due to lots of unmovable tasks (for example because of
    hard CPU affinity). In those situation, it excludes the busiest CPU that
    has pinned tasks for load balance consideration such that it can perform
    second 2nd load balance pass on the rest of the system.
    
    This all works as designed if there is only one cgroup in the system.
    
    However, when we have multiple cgroups, this logic has false positives and
    triggers multiple load balance passes despite there are actually no pinned
    tasks at all.
    
    The reason it has false positives is that the all pinned logic is deep in
    the lowest function of can_migrate_task() and is too low level:
    
    load_balance_fair() iterates each task group and calls balance_tasks() to
    migrate target load. Along the way, balance_tasks() will also set a
    all_pinned variable. Given that task-groups are iterated, this all_pinned
    variable is essentially the status of last group in the scanning process.
    Task group can have number of reasons that no load being migrated, none
    due to cpu affinity. However, this status bit is being propagated back up
    to the higher level load_balance(), which incorrectly think that no tasks
    were moved.  It kick off the all pinned logic and start multiple passes
    attempt to move load onto puller CPU.
    
    To fix this, move the all_pinned aggregation up at the iterator level.
    This ensures that the status is aggregated over all task-groups, not just
    last one in the list.
    
    Signed-off-by: Ken Chen <kenchen@google.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/BANLkTi=ernzNawaR5tJZEsV_QVnfxqXmsQ@mail.gmail.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  28. @vapier @gregkh

    RTC: add missing "return 0" in new alarm func for rtc-bfin.c

    vapier authored gregkh committed
    commit 8c122b9 upstream.
    
    The new bfin_rtc_alarm_irq_enable function forgot to add a "return 0" to
    the end leading to the build warning:
    	drivers/rtc/rtc-bfin.c: In function 'bfin_rtc_alarm_irq_enable':
    	drivers/rtc/rtc-bfin.c:253: warning: control reaches end of non-void function
    
    CC: Thomas Gleixner <tglx@linutronix.de>
    CC: Alessandro Zummo <a.zummo@towertech.it>
    Signed-off-by: Mike Frysinger <vapier@gentoo.org>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Something went wrong with that request. Please try again.