1. 16 Jun, 2016 1 commit
    • Arnd Bergmann's avatar
      isdn: eicon: fix old-style declarations · ac565065
      Arnd Bergmann authored
      Modern C standards expect the '__inline__' keyword to come before the return
      type in a declaration, and we get many warnings for this with "make W=1"
      because the eicon driver has this in a header file:
      eicon/divasmain.c:448:1: error: '__inline__' is not at beginning of declaration [-Werror=old-style-declaration]
      eicon/divasmain.c:453:1: error: '__inline__' is not at beginning of declaration [-Werror=old-style-declaration]
      eicon/divasmain.c:458:1: error: '__inline__' is not at beginning of declaration [-Werror=old-style-declaration]
      eicon/divasmain.c:463:1: error: '__inline__' is not at beginning of declaration [-Werror=old-style-declaration]
      eicon/divasmain.c:468:1: error: '__inline__' is not at beginning of declaration [-Werror=old-style-declaration]
      eicon/divasmain.c:473:1: error: '__inline__' is not at beginning of declaration [-Werror=old-style-declaration]
      eicon/platform.h:274:1: error: '__inline__' is not at beginning of declaration [-Werror=old-style-declaration]
      eicon/platform.h:280:1: error: '__inline__' is not at beginning of declaration [-Werror=old-style-declaration]
      A similar warning gets printed for the diva_os_register_io_port()
      declaration, because 'register' is interpreted as a keyword instead
      of a variable name:
      In file included from eicon/diva_didd.c:21:0:
      eicon/platform.h:206:1: error: 'register' is not at beginning of declaration [-Werror=old-style-declaration]
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  2. 08 May, 2016 1 commit
  3. 14 Mar, 2016 2 commits
  4. 18 Feb, 2016 2 commits
    • Anton Protopopov's avatar
      mISDN: prevent possible NULL pointer dereference · e60b13e4
      Anton Protopopov authored
      A return value of the bchannel_get_rxbuf() function is compared with the
      positive ENOMEM value instead of the negative -ENOMEM value to detect a
      memory allocation problem. Thus, after a possible memory allocation
      failure the bc->bch.rx_skb will be NULL which will lead to a NULL
      pointer dereference.
      Signed-off-by: default avatarAnton Protopopov <a.s.protopopov@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Alison Schofield's avatar
      isdn: divamnt: use y2038-safe ktime_get_ts64() for trace data timestamps · 096f6262
      Alison Schofield authored
      divamnt stores a start_time at module init and uses it to calculate
      elapsed time. The elapsed time, stored in secs and usecs, is part of
      the trace data the driver maintains for the DIVA Server ISDN cards.
      No change to the format of that time data is required.
      To avoid overflow on 32-bit systems use ktime_get_ts64() to return
      the elapsed monotonic time since system boot.
      This is a change from real to monotonic time. Since the driver only
      stores elapsed time, monotonic time is sufficient and more robust
      against real time clock changes. These new monotonic values can be
      more useful for debugging because they can be easily compared to
      other monotonic timestamps.
      Note elaspsed time values will now start at system boot time rather
      than module load time, so they will differ slightly from previously
      reported values.
      Remove declaration and init of previously unused time constants:
      start_sec, start_usec.
      Signed-off-by: default avatarAlison Schofield <amsfield22@gmail.com>
      Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  5. 15 Dec, 2015 1 commit
  6. 06 Mar, 2015 1 commit
  7. 22 Feb, 2015 1 commit
  8. 02 Feb, 2015 1 commit
  9. 13 Jan, 2015 1 commit
    • Arnd Bergmann's avatar
      mISDN: avoid arch specific __builtin_return_address call · 3e7a8716
      Arnd Bergmann authored
      Not all architectures are able to call __builtin_return_address().
      On ARM, the mISDN code produces this warning:
      hardware/mISDN/w6692.c: In function 'w6692_dctrl':
      hardware/mISDN/w6692.c:1181:75: warning: unsupported argument to '__builtin_return_address'
        pr_debug("%s: %s dev(%d) open from %p\n", card->name, __func__,
      hardware/mISDN/mISDNipac.c: In function 'open_dchannel':
      hardware/mISDN/mISDNipac.c:759:75: warning: unsupported argument to '__builtin_return_address'
        pr_debug("%s: %s dev(%d) open from %p\n", isac->name, __func__,
      In a lot of cases, this is relatively easy to work around by
      passing the value of __builtin_return_address(0) from the
      callers into the functions that want it. One exception is
      the indirect 'open' function call in struct isac_hw. While it
      would be possible to fix this as well, this patch only addresses
      the other callers properly and lets this one return the direct
      parent function, which should be good enough.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  10. 12 Jan, 2015 1 commit
  11. 07 Jan, 2015 1 commit
  12. 22 Aug, 2014 1 commit
  13. 17 Oct, 2013 1 commit
  14. 02 Oct, 2013 1 commit
  15. 15 Sep, 2013 1 commit
  16. 19 Jul, 2013 1 commit
  17. 09 Apr, 2013 1 commit
    • Al Viro's avatar
      procfs: new helper - PDE_DATA(inode) · d9dda78b
      Al Viro authored
      The only part of proc_dir_entry the code outside of fs/proc
      really cares about is PDE(inode)->data.  Provide a helper
      for that; static inline for now, eventually will be moved
      to fs/proc, along with the knowledge of struct proc_dir_entry
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  18. 15 Mar, 2013 1 commit
  19. 10 Mar, 2013 2 commits
  20. 22 Feb, 2013 1 commit
  21. 18 Jan, 2013 1 commit
    • Joe Millenbach's avatar
      tty: Added a CONFIG_TTY option to allow removal of TTY · 4f73bc4d
      Joe Millenbach authored
      The option allows you to remove TTY and compile without errors. This
      saves space on systems that won't support TTY interfaces anyway.
      bloat-o-meter output is below.
      The bulk of this patch consists of Kconfig changes adding "depends on
      TTY" to various serial devices and similar drivers that require the TTY
      layer.  Ideally, these dependencies would occur on a common intermediate
      symbol such as SERIO, but most drivers "select SERIO" rather than
      "depends on SERIO", and "select" does not respect dependencies.
      bloat-o-meter output comparing our previous minimal to new minimal by
      removing TTY.  The list is filtered to not show removed entries with awk
      '$3 != "-"' as the list was very long.
      add/remove: 0/226 grow/shrink: 2/14 up/down: 6/-35356 (-35350)
      function                                     old     new   delta
      chr_dev_init                                 166     170      +4
      allow_signal                                  80      82      +2
      static.__warned                              143     142      -1
      disallow_signal                               63      62      -1
      __set_special_pids                            95      94      -1
      unregister_console                           126     121      -5
      start_kernel                                 546     541      -5
      register_console                             593     588      -5
      copy_from_user                                45      40      -5
      sys_setsid                                   128     120      -8
      sys_vhangup                                   32      19     -13
      do_exit                                     1543    1526     -17
      bitmap_zero                                   60      40     -20
      arch_local_irq_save                          137     117     -20
      release_task                                 674     652     -22
      static.spin_unlock_irqrestore                308     260     -48
      Signed-off-by: default avatarJoe Millenbach <jmillenbach@gmail.com>
      Reviewed-by: default avatarJamey Sharp <jamey@minilop.net>
      Reviewed-by: default avatarJosh Triplett <josh@joshtriplett.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  22. 03 Jan, 2013 2 commits
  23. 19 Nov, 2012 1 commit
  24. 09 Nov, 2012 1 commit
  25. 26 Oct, 2012 1 commit
  26. 13 Sep, 2012 1 commit
  27. 03 Sep, 2012 1 commit
  28. 30 Jul, 2012 1 commit
  29. 18 Jul, 2012 1 commit
  30. 22 May, 2012 1 commit
  31. 18 May, 2012 1 commit
    • Sarah Sharp's avatar
      USB: Disable hub-initiated LPM for comms devices. · e1f12eb6
      Sarah Sharp authored
      Hub-initiated LPM is not good for USB communications devices.  Comms
      devices should be able to tell when their link can go into a lower power
      state, because they know when an incoming transmission is finished.
      Ideally, these devices would slam their links into a lower power state,
      using the device-initiated LPM, after finishing the last packet of their
      data transfer.
      If we enable the idle timeouts for the parent hubs to enable
      hub-initiated LPM, we will get a lot of useless LPM packets on the bus
      as the devices reject LPM transitions when they're in the middle of
      receiving data.  Worse, some devices might blindly accept the
      hub-initiated LPM and power down their radios while they're in the
      middle of receiving a transmission.
      The Intel Windows folks are disabling hub-initiated LPM for all USB
      communications devices under a xHCI USB 3.0 host.  In order to keep
      the Linux behavior as close as possible to Windows, we need to do the
      same in Linux.
      Set the disable_hub_initiated_lpm flag for for all USB communications
      drivers.  I know there aren't currently any USB 3.0 devices that
      implement these class specifications, but we should be ready if they do.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: Gustavo Padovan <gustavo@padovan.org>
      Cc: Johan Hedberg <johan.hedberg@gmail.com>
      Cc: Hansjoerg Lipp <hjlipp@web.de>
      Cc: Tilman Schmidt <tilman@imap.cc>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Cc: Peter Korsgaard <jacmet@sunsite.dk>
      Cc: Jan Dumon <j.dumon@option.com>
      Cc: Petko Manolov <petkan@users.sourceforge.net>
      Cc: Steve Glendinning <steve.glendinning@smsc.com>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
      Cc: Jouni Malinen <jouni@qca.qualcomm.com>
      Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
      Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
      Cc: Christian Lamparter <chunkeey@googlemail.com>
      Cc: Brett Rudley <brudley@broadcom.com>
      Cc: Roland Vossen <rvossen@broadcom.com>
      Cc: Arend van Spriel <arend@broadcom.com>
      Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
      Cc: Kan Yan <kanyan@broadcom.com>
      Cc: Dan Williams <dcbw@redhat.com>
      Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Cc: Ivo van Doorn <IvDoorn@gmail.com>
      Cc: Gertjan van Wingerde <gwingerde@gmail.com>
      Cc: Helmut Schaa <helmut.schaa@googlemail.com>
      Cc: Herton Ronaldo Krzesinski <herton@canonical.com>
      Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
      Cc: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Chaoming Li <chaoming_li@realsil.com.cn>
      Cc: Daniel Drake <dsd@gentoo.org>
      Cc: Ulrich Kunitz <kune@deine-taler.de>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
  32. 16 May, 2012 5 commits