1. 06 Aug, 2018 36 commits
  2. 28 Jul, 2018 4 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.145 · ac15b2b2
      Greg Kroah-Hartman authored
      ac15b2b2
    • Arnd Bergmann's avatar
      ARM: fix put_user() for gcc-8 · 0ca85fc3
      Arnd Bergmann authored
      Building kernels before linux-4.7 with gcc-8 results in many build failures
      when gcc triggers a check that was meant to catch broken compilers:
      
      /tmp/ccCGMQmS.s:648: Error: .err encountered
      
      According to the discussion in the gcc bugzilla, a local "register
      asm()" variable is still supposed to be the correct way to force an
      inline assembly to use a particular register, but marking it 'const'
      lets the compiler do optimizations that break that, i.e the compiler is
      free to treat the variable as either 'const' or 'register' in that case.
      
      Upstream commit 9f73bd8b ("ARM: uaccess: remove put_user() code
      duplication") fixed this problem in linux-4.8 as part of a larger change,
      but seems a little too big to be backported to 4.4.
      
      Let's take the simplest fix and change only the one broken line in the
      same way as newer kernels.
      Suggested-by: default avatarBernd Edlinger <bernd.edlinger@hotmail.de>
      Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85745
      Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86673Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ca85fc3
    • Arnd Bergmann's avatar
      turn off -Wattribute-alias · d41d0fe3
      Arnd Bergmann authored
      Starting with gcc-8.1, we get a warning about all system call definitions,
      which use an alias between functions with incompatible prototypes, e.g.:
      
      In file included from ../mm/process_vm_access.c:19:
      ../include/linux/syscalls.h:211:18: warning: 'sys_process_vm_readv' alias between functions of incompatible types 'long int(pid_t,  const struct iovec *, long unsigned int,  const struct iovec *, long unsigned int,  long unsigned int)' {aka 'long int(int,  const struct iovec *, long unsigned int,  const struct iovec *, long unsigned int,  long unsigned int)'} and 'long int(long int,  long int,  long int,  long int,  long int,  long int)' [-Wattribute-alias]
        asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
                        ^~~
      ../include/linux/syscalls.h:207:2: note: in expansion of macro '__SYSCALL_DEFINEx'
        __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
        ^~~~~~~~~~~~~~~~~
      ../include/linux/syscalls.h:201:36: note: in expansion of macro 'SYSCALL_DEFINEx'
       #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
                                          ^~~~~~~~~~~~~~~
      ../mm/process_vm_access.c:300:1: note: in expansion of macro 'SYSCALL_DEFINE6'
       SYSCALL_DEFINE6(process_vm_readv, pid_t, pid, const struct iovec __user *, lvec,
       ^~~~~~~~~~~~~~~
      ../include/linux/syscalls.h:215:18: note: aliased declaration here
        asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
                        ^~~
      ../include/linux/syscalls.h:207:2: note: in expansion of macro '__SYSCALL_DEFINEx'
        __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
        ^~~~~~~~~~~~~~~~~
      ../include/linux/syscalls.h:201:36: note: in expansion of macro 'SYSCALL_DEFINEx'
       #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
                                          ^~~~~~~~~~~~~~~
      ../mm/process_vm_access.c:300:1: note: in expansion of macro 'SYSCALL_DEFINE6'
       SYSCALL_DEFINE6(process_vm_readv, pid_t, pid, const struct iovec __user *, lvec,
      
      This is really noisy and does not indicate a real problem. In the latest
      mainline kernel, this was addressed by commit bee20031 ("disable
      -Wattribute-alias warning for SYSCALL_DEFINEx()"), which seems too invasive
      to backport.
      
      This takes a much simpler approach and just disables the warning across the
      kernel.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d41d0fe3
    • Anssi Hannula's avatar
      can: xilinx_can: fix RX overflow interrupt not being enabled · 264dc158
      Anssi Hannula authored
      commit 83997997 upstream.
      
      RX overflow interrupt (RXOFLW) is disabled even though xcan_interrupt()
      processes it. This means that an RX overflow interrupt will only be
      processed when another interrupt gets asserted (e.g. for RX/TX).
      
      Fix that by enabling the RXOFLW interrupt.
      
      Fixes: b1201e44 ("can: xilinx CAN controller support")
      Signed-off-by: default avatarAnssi Hannula <anssi.hannula@bitwise.fi>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      264dc158