1. 30 Oct, 2014 40 commits
    • bob picco's avatar
      sparc64: T5 PMU · a0614802
      bob picco authored
      The T5 (niagara5) has different PCR related HV fast trap values and a new
      HV API Group. This patch utilizes these and shares when possible with niagara4.
      
      We use the same sparc_pmu niagara4_pmu. Should there be new effort to
      obtain the MCU perf statistics then this would have to be changed.
      
      Cc: sparclinux@vger.kernel.org
      Signed-off-by: default avatarBob Picco <bob.picco@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a0614802
    • Allen Pais's avatar
    • Allen Pais's avatar
      sparc64: support M6 and M7 for building CPU distribution map · 6a610e72
      Allen Pais authored
      Add M6 and M7 chip type in cpumap.c to correctly build CPU distribution map that spans all online CPUs.
      Signed-off-by: default avatarAllen Pais <allen.pais@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a610e72
    • Allen Pais's avatar
      sparc64: correctly recognise M6 and M7 cpu type · 0e77996b
      Allen Pais authored
      The following patch adds support for correctly
      recognising M6 and M7 cpu type.
      Signed-off-by: default avatarAllen Pais <allen.pais@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0e77996b
    • David S. Miller's avatar
      sparc64: Fix hibernation code refrence to PAGE_OFFSET. · 0929aa34
      David S. Miller authored
      We changed PAGE_OFFSET to be a variable rather than a constant,
      but this reference here in the hibernate assembler got missed.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0929aa34
    • David S. Miller's avatar
      sparc64: Do not define thread fpregs save area as zero-length array. · edaad4aa
      David S. Miller authored
      [ Upstream commit e2653143 ]
      
      This breaks the stack end corruption detection facility.
      
      What that facility does it write a magic value to "end_of_stack()"
      and checking to see if it gets overwritten.
      
      "end_of_stack()" is "task_thread_info(p) + 1", which for sparc64 is
      the beginning of the FPU register save area.
      
      So once the user uses the FPU, the magic value is overwritten and the
      debug checks trigger.
      
      Fix this by making the size explicit.
      
      Due to the size we use for the fpsaved[], gsr[], and xfsr[] arrays we
      are limited to 7 levels of FPU state saves.  So each FPU register set
      is 256 bytes, allocate 256 * 7 for the fpregs area.
      Reported-by: default avatarMeelis Roos <mroos@linux.ee>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      edaad4aa
    • David S. Miller's avatar
      sparc64: Fix FPU register corruption with AES crypto offload. · b22e0857
      David S. Miller authored
      [ Upstream commit f4da3628 ]
      
      The AES loops in arch/sparc/crypto/aes_glue.c use a scheme where the
      key material is preloaded into the FPU registers, and then we loop
      over and over doing the crypt operation, reusing those pre-cooked key
      registers.
      
      There are intervening blkcipher*() calls between the crypt operation
      calls.  And those might perform memcpy() and thus also try to use the
      FPU.
      
      The sparc64 kernel FPU usage mechanism is designed to allow such
      recursive uses, but with a catch.
      
      There has to be a trap between the two FPU using threads of control.
      
      The mechanism works by, when the FPU is already in use by the kernel,
      allocating a slot for FPU saving at trap time.  Then if, within the
      trap handler, we try to use the FPU registers, the pre-trap FPU
      register state is saved into the slot.  Then at trap return time we
      notice this and restore the pre-trap FPU state.
      
      Over the long term there are various more involved ways we can make
      this work, but for a quick fix let's take advantage of the fact that
      the situation where this happens is very limited.
      
      All sparc64 chips that support the crypto instructiosn also are using
      the Niagara4 memcpy routine, and that routine only uses the FPU for
      large copies where we can't get the source aligned properly to a
      multiple of 8 bytes.
      
      We look to see if the FPU is already in use in this context, and if so
      we use the non-large copy path which only uses integer registers.
      
      Furthermore, we also limit this special logic to when we are doing
      kernel copy, rather than a user copy.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b22e0857
    • David S. Miller's avatar
      sparc64: Fix lockdep warnings on reboot on Ultra-5 · 67d9e5d4
      David S. Miller authored
      [ Upstream commit bdcf81b6 ]
      
      Inconsistently, the raw_* IRQ routines do not interact with and update
      the irqflags tracing and lockdep state, whereas the raw_* spinlock
      interfaces do.
      
      This causes problems in p1275_cmd_direct() because we disable hardirqs
      by hand using raw_local_irq_restore() and then do a raw_spin_lock()
      which triggers a lockdep trace because the CPU's hw IRQ state doesn't
      match IRQ tracing's internal software copy of that state.
      
      The CPU's irqs are disabled, yet current->hardirqs_enabled is true.
      
      ====================
      reboot: Restarting system
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3536 check_flags+0x7c/0x240()
      DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled)
      Modules linked in: openpromfs
      CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: G        W      3.17.0-dirty #145
      Call Trace:
       [000000000045919c] warn_slowpath_common+0x5c/0xa0
       [0000000000459210] warn_slowpath_fmt+0x30/0x40
       [000000000048f41c] check_flags+0x7c/0x240
       [0000000000493280] lock_acquire+0x20/0x1c0
       [0000000000832b70] _raw_spin_lock+0x30/0x60
       [000000000068f2fc] p1275_cmd_direct+0x1c/0x60
       [000000000068ed28] prom_reboot+0x28/0x40
       [000000000043610c] machine_restart+0x4c/0x80
       [000000000047d2d4] kernel_restart+0x54/0x80
       [000000000047d618] SyS_reboot+0x138/0x200
       [00000000004060b4] linux_sparc_syscall32+0x34/0x60
      ---[ end trace 5c439fe81c05a100 ]---
      possible reason: unannotated irqs-off.
      irq event stamp: 2010267
      hardirqs last  enabled at (2010267): [<000000000049a358>] vprintk_emit+0x4b8/0x580
      hardirqs last disabled at (2010266): [<0000000000499f08>] vprintk_emit+0x68/0x580
      softirqs last  enabled at (2010046): [<000000000045d278>] __do_softirq+0x378/0x4a0
      softirqs last disabled at (2010039): [<000000000042bf08>] do_softirq_own_stack+0x28/0x40
      Resetting ...
      ====================
      
      Use local_* variables of the hw IRQ interfaces so that IRQ tracing sees
      all of our changes.
      Reported-by: default avatarMeelis Roos <mroos@linux.ee>
      Tested-by: default avatarMeelis Roos <mroos@linux.ee>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      67d9e5d4
    • David S. Miller's avatar
      sparc64: Fix reversed start/end in flush_tlb_kernel_range() · 445fd8f9
      David S. Miller authored
      [ Upstream commit 473ad7f4 ]
      
      When we have to split up a flush request into multiple pieces
      (in order to avoid the firmware range) we don't specify the
      arguments in the right order for the second piece.
      
      Fix the order, or else we get hangs as the code tries to
      flush "a lot" of entries and we get lockups like this:
      
      [ 4422.981276] NMI watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [expect:117032]
      [ 4422.996130] Modules linked in: ipv6 loop usb_storage igb ptp sg sr_mod ehci_pci ehci_hcd pps_core n2_rng rng_core
      [ 4423.016617] CPU: 12 PID: 117032 Comm: expect Not tainted 3.17.0-rc4+ #1608
      [ 4423.030331] task: fff8003cc730e220 ti: fff8003d99d54000 task.ti: fff8003d99d54000
      [ 4423.045282] TSTATE: 0000000011001602 TPC: 00000000004521e8 TNPC: 00000000004521ec Y: 00000000    Not tainted
      [ 4423.064905] TPC: <__flush_tlb_kernel_range+0x28/0x40>
      [ 4423.074964] g0: 000000000052fd10 g1: 00000001295a8000 g2: ffffff7176ffc000 g3: 0000000000002000
      [ 4423.092324] g4: fff8003cc730e220 g5: fff8003dfedcc000 g6: fff8003d99d54000 g7: 0000000000000006
      [ 4423.109687] o0: 0000000000000000 o1: 0000000000000000 o2: 0000000000000003 o3: 00000000f0000000
      [ 4423.127058] o4: 0000000000000080 o5: 00000001295a8000 sp: fff8003d99d56d01 ret_pc: 000000000052ff54
      [ 4423.145121] RPC: <__purge_vmap_area_lazy+0x314/0x3a0>
      [ 4423.155185] l0: 0000000000000000 l1: 0000000000000000 l2: 0000000000a38040 l3: 0000000000000000
      [ 4423.172559] l4: fff8003dae8965e0 l5: ffffffffffffffff l6: 0000000000000000 l7: 00000000f7e2b138
      [ 4423.189913] i0: fff8003d99d576a0 i1: fff8003d99d576a8 i2: fff8003d99d575e8 i3: 0000000000000000
      [ 4423.207284] i4: 0000000000008008 i5: fff8003d99d575c8 i6: fff8003d99d56df1 i7: 0000000000530c24
      [ 4423.224640] I7: <free_vmap_area_noflush+0x64/0x80>
      [ 4423.234193] Call Trace:
      [ 4423.239051]  [0000000000530c24] free_vmap_area_noflush+0x64/0x80
      [ 4423.251029]  [0000000000531a7c] remove_vm_area+0x5c/0x80
      [ 4423.261628]  [0000000000531b80] __vunmap+0x20/0x120
      [ 4423.271352]  [000000000071cf18] n_tty_close+0x18/0x40
      [ 4423.281423]  [00000000007222b0] tty_ldisc_close+0x30/0x60
      [ 4423.292183]  [00000000007225a4] tty_ldisc_reinit+0x24/0xa0
      [ 4423.303120]  [0000000000722ab4] tty_ldisc_hangup+0xd4/0x1e0
      [ 4423.314232]  [0000000000719aa0] __tty_hangup+0x280/0x3c0
      [ 4423.324835]  [0000000000724cb4] pty_close+0x134/0x1a0
      [ 4423.334905]  [000000000071aa24] tty_release+0x104/0x500
      [ 4423.345316]  [00000000005511d0] __fput+0x90/0x1e0
      [ 4423.354701]  [000000000047fa54] task_work_run+0x94/0xe0
      [ 4423.365126]  [0000000000404b44] __handle_signal+0xc/0x2c
      
      Fixes: 4ca9a237 ("sparc64: Guard against flushing openfirmware mappings.")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      445fd8f9
    • Alexei Starovoitov's avatar
      sparc: bpf_jit: fix loads from negative offsets · 9cb7f1e4
      Alexei Starovoitov authored
      [ Upstream commit 35607b02 ]
      
      - fix BPF_LD|ABS|IND from negative offsets:
        make sure to sign extend lower 32 bits in 64-bit register
        before calling C helpers from JITed code, otherwise 'int k'
        argument of bpf_internal_load_pointer_neg_helper() function
        will be added as large unsigned integer, causing packet size
        check to trigger and abort the program.
      
        It's worth noting that JITed code for 'A = A op K' will affect
        upper 32 bits differently depending whether K is simm13 or not.
        Since small constants are sign extended, whereas large constants
        are stored in temp register and zero extended.
        That is ok and we don't have to pay a penalty of sign extension
        for every sethi, since all classic BPF instructions have 32-bit
        semantics and we only need to set correct upper bits when
        transitioning from JITed code into C.
      
      - though instructions 'A &= 0' and 'A *= 0' are odd, JIT compiler
        should not optimize them out
      Signed-off-by: default avatarAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9cb7f1e4
    • Alexei Starovoitov's avatar
      sparc: bpf_jit: fix support for ldx/stx mem and SKF_AD_VLAN_TAG · 6e2d91c6
      Alexei Starovoitov authored
      [ Upstream commit f6f2332d ]
      
      fix several issues in sparc BPF JIT compiler.
      
      ldx/stx related:
      . classic BPF instructions that access mem[] slots were not setting
        SEEN_MEM flag, so stack wasn't allocated. Fix that by advertising
        correct flags
      
      . LDX/STX instructions were missing SEEN_XREG, so register value
        could have leaked to user space. Fix it.
      
      . since stack for mem[] slots is allocated with 'sub %sp' instead
        of 'save %sp', use %sp as base register instead of %fp.
      
      . ldx mem[0] means first slot in classic BPF which should have
        -4 offset instead of 0.
      
      . sparc64 needs 2047 stack bias as per ABI to access stack
      
      . emit_stmem() was using LD32I macro instead of ST32I
      
      SKF_AD_VLAN_TAG* related:
      . SKF_AD_VLAN_TAG_PRESENT must return 1 or 0 instead of '> 0' or 0
        as per classic BPF de facto standard
      
      . SKF_AD_VLAN_TAG needs to mask the field correctly
      
      Fixes: 2809a208 ("net: filter: Just In Time compiler for sparc")
      Signed-off-by: default avatarAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e2d91c6
    • Andreas Larsson's avatar
      sparc: Let memset return the address argument · a068a292
      Andreas Larsson authored
      [ Upstream commit 74cad25c ]
      
      This makes memset follow the standard (instead of returning 0 on success). This
      is needed when certain versions of gcc optimizes around memset calls and assume
      that the address argument is preserved in %o0.
      Signed-off-by: default avatarAndreas Larsson <andreas@gaisler.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a068a292
    • Sowmini Varadhan's avatar
      sparc64: Move request_irq() from ldc_bind() to ldc_alloc() · 200fe7a7
      Sowmini Varadhan authored
      [ Upstream commit c21c4ab0 ]
      
      The request_irq() needs to be done from ldc_alloc()
      to avoid the following (caught by lockdep)
      
       [00000000004a0738] __might_sleep+0xf8/0x120
       [000000000058bea4] kmem_cache_alloc_trace+0x184/0x2c0
       [00000000004faf80] request_threaded_irq+0x80/0x160
       [000000000044f71c] ldc_bind+0x7c/0x220
       [0000000000452454] vio_port_up+0x54/0xe0
       [00000000101f6778] probe_disk+0x38/0x220 [sunvdc]
       [00000000101f6b8c] vdc_port_probe+0x22c/0x300 [sunvdc]
       [0000000000451a88] vio_device_probe+0x48/0x60
       [000000000074c56c] really_probe+0x6c/0x300
       [000000000074c83c] driver_probe_device+0x3c/0xa0
       [000000000074c92c] __driver_attach+0x8c/0xa0
       [000000000074a6ec] bus_for_each_dev+0x6c/0xa0
       [000000000074c1dc] driver_attach+0x1c/0x40
       [000000000074b0fc] bus_add_driver+0xbc/0x280
      Signed-off-by: default avatarSowmini Varadhan <sowmini.varadhan@oracle.com>
      Acked-by: default avatarDwight Engen <dwight.engen@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      200fe7a7
    • bob picco's avatar
      sparc64: find_node adjustment · cbc578cf
      bob picco authored
      [ Upstream commit 3dee9df5 ]
      
      We have seen an issue with guest boot into LDOM that causes early boot failures
      because of no matching rules for node identitity of the memory. I analyzed this
      on my T4 and concluded there might not be a solution. I saw the issue in
      mainline too when booting into the control/primary domain - with guests
      configured.  Note, this could be a firmware bug on some older machines.
      
      I'll provide a full explanation of the issues below. Should we not find a
      matching BEST latency group for a real address (RA) then we will assume node 0.
      On the T4-2 here with the information provided I can't see an alternative.
      
      Technically the LDOM shown below should match the MBLOCK to the
      favorable latency group. However other factors must be considered too. Were
      the memory controllers configured "fine" grained interleave or "coarse"
      grain interleaved -  T4. Also should a "group" MD node be considered a NUMA
      node?
      
      There has to be at least one Machine Description (MD) "group" and hence one
      NUMA node. The group can have one or more latency groups (lg) - more than one
      memory controller. The current code chooses the smallest latency as the most
      favorable per group. The latency and lg information is in MLGROUP below.
      MBLOCK is the base and size of the RAs for the machine as fetched from OBP
      /memory "available" property. My machine has one MBLOCK but more would be
      possible - with holes?
      
      For a T4-2 the following information has been gathered:
      with LDOM guest
      MEMBLOCK configuration:
       memory size = 0x27f870000
       memory.cnt  = 0x3
       memory[0x0]    [0x00000020400000-0x0000029fc67fff], 0x27f868000 bytes
       memory[0x1]    [0x0000029fd8a000-0x0000029fd8bfff], 0x2000 bytes
       memory[0x2]    [0x0000029fd92000-0x0000029fd97fff], 0x6000 bytes
       reserved.cnt  = 0x2
       reserved[0x0]  [0x00000020800000-0x000000216c15c0], 0xec15c1 bytes
       reserved[0x1]  [0x00000024800000-0x0000002c180c1e], 0x7980c1f bytes
      MBLOCK[0]: base[20000000] size[280000000] offset[0]
      (note: "base" and "size" reported in "MBLOCK" encompass the "memory[X]" values)
      (note: (RA + offset) & mask = val is the formula to detect a match for the
      memory controller. should there be no match for find_node node, a return
      value of -1 resulted for the node - BAD)
      
      There is one group. It has these forward links
      MLGROUP[1]: node[545] latency[1f7e8] match[200000000] mask[200000000]
      MLGROUP[2]: node[54d] latency[2de60] match[0] mask[200000000]
      NUMA NODE[0]: node[545] mask[200000000] val[200000000] (latency[1f7e8])
      (note: "val" is the best lg's (smallest latency) "match")
      
      no LDOM guest - bare metal
      MEMBLOCK configuration:
       memory size = 0xfdf2d0000
       memory.cnt  = 0x3
       memory[0x0]    [0x00000020400000-0x00000fff6adfff], 0xfdf2ae000 bytes
       memory[0x1]    [0x00000fff6d2000-0x00000fff6e7fff], 0x16000 bytes
       memory[0x2]    [0x00000fff766000-0x00000fff771fff], 0xc000 bytes
       reserved.cnt  = 0x2
       reserved[0x0]  [0x00000020800000-0x00000021a04580], 0x1204581 bytes
       reserved[0x1]  [0x00000024800000-0x0000002c7d29fc], 0x7fd29fd bytes
      MBLOCK[0]: base[20000000] size[fe0000000] offset[0]
      
      there are two groups
      group node[16d5]
      MLGROUP[0]: node[1765] latency[1f7e8] match[0] mask[200000000]
      MLGROUP[3]: node[177d] latency[2de60] match[200000000] mask[200000000]
      NUMA NODE[0]: node[1765] mask[200000000] val[0] (latency[1f7e8])
      group node[171d]
      MLGROUP[2]: node[1775] latency[2de60] match[0] mask[200000000]
      MLGROUP[1]: node[176d] latency[1f7e8] match[200000000] mask[200000000]
      NUMA NODE[1]: node[176d] mask[200000000] val[200000000] (latency[1f7e8])
      (note: for this two "group" bare metal machine, 1/2 memory is in group one's
      lg and 1/2 memory is in group two's lg).
      
      Cc: sparclinux@vger.kernel.org
      Signed-off-by: default avatarBob Picco <bob.picco@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cbc578cf
    • David S. Miller's avatar
      sparc64: Fix corrupted thread fault code. · a5fb6002
      David S. Miller authored
      [ Upstream commit 84bd6d8b ]
      
      Every path that ends up at do_sparc64_fault() must install a valid
      FAULT_CODE_* bitmask in the per-thread fault code byte.
      
      Two paths leading to the label winfix_trampoline (which expects the
      FAULT_CODE_* mask in register %g4) were not doing so:
      
      1) For pre-hypervisor TLB protection violation traps, if we took
         the 'winfix_trampoline' path we wouldn't have %g4 initialized
         with the FAULT_CODE_* value yet.  Resulting in using the
         TLB_TAG_ACCESS register address value instead.
      
      2) In the TSB miss path, when we notice that we are going to use a
         hugepage mapping, but we haven't allocated the hugepage TSB yet, we
         still have to take the window fixup case into consideration and
         in that particular path we leave %g4 not setup properly.
      
      Errors on this sort were largely invisible previously, but after
      commit 4ccb9272 ("sparc64: sun4v TLB
      error power off events") we now have a fault_code mask bit
      (FAULT_CODE_BAD_RA) that triggers due to this bug.
      
      FAULT_CODE_BAD_RA triggers because this bit is set in TLB_TAG_ACCESS
      (see #1 above) and thus we get seemingly random bus errors triggered
      for user processes.
      
      Fixes: 4ccb9272 ("sparc64: sun4v TLB error power off events")
      Reported-by: default avatarMeelis Roos <mroos@linux.ee>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a5fb6002
    • bob picco's avatar
      sparc64: sun4v TLB error power off events · ac1addf5
      bob picco authored
      [ Upstream commit 4ccb9272 ]
      
      We've witnessed a few TLB events causing the machine to power off because
      of prom_halt. In one case it was some nfs related area during rmmod. Another
      was an mmapper of /dev/mem. A more recent one is an ITLB issue with
      a bad pagesize which could be a hardware bug. Bugs happen but we should
      attempt to not power off the machine and/or hang it when possible.
      
      This is a DTLB error from an mmapper of /dev/mem:
      [root@sparcie ~]# SUN4V-DTLB: Error at TPC[fffff80100903e6c], tl 1
      SUN4V-DTLB: TPC<0xfffff80100903e6c>
      SUN4V-DTLB: O7[fffff801081979d0]
      SUN4V-DTLB: O7<0xfffff801081979d0>
      SUN4V-DTLB: vaddr[fffff80100000000] ctx[1250] pte[98000000000f0610] error[2]
      .
      
      This is recent mainline for ITLB:
      [ 3708.179864] SUN4V-ITLB: TPC<0xfffffc010071cefc>
      [ 3708.188866] SUN4V-ITLB: O7[fffffc010071cee8]
      [ 3708.197377] SUN4V-ITLB: O7<0xfffffc010071cee8>
      [ 3708.206539] SUN4V-ITLB: vaddr[e0003] ctx[1a3c] pte[2900000dcc800eeb] error[4]
      .
      
      Normally sun4v_itlb_error_report() and sun4v_dtlb_error_report() would call
      prom_halt() and drop us to OF command prompt "ok". This isn't the case for
      LDOMs and the machine powers off.
      
      For the HV reported error of HV_ENORADDR for HV HV_MMU_MAP_ADDR_TRAP we cause
      a SIGBUS error by qualifying it within do_sparc64_fault() for fault code mask
      of FAULT_CODE_BAD_RA. This is done when trap level (%tl) is less or equal
      one("1"). Otherwise, for %tl > 1,  we proceed eventually to die_if_kernel().
      
      The logic of this patch was partially inspired by David Miller's feedback.
      
      Power off of large sparc64 machines is painful. Plus die_if_kernel provides
      more context. A reset sequence isn't a brief period on large sparc64 but
      better than power-off/power-on sequence.
      
      Cc: sparclinux@vger.kernel.org
      Signed-off-by: default avatarBob Picco <bob.picco@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ac1addf5
    • Daniel Hellstrom's avatar
      sparc32: dma_alloc_coherent must honour gfp flags · 7907ea42
      Daniel Hellstrom authored
      [ Upstream commit d1105287 ]
      
      dma_zalloc_coherent() calls dma_alloc_coherent(__GFP_ZERO)
      but the sparc32 implementations sbus_alloc_coherent() and
      pci32_alloc_coherent() doesn't take the gfp flags into
      account.
      
      Tested on the SPARC32/LEON GRETH Ethernet driver which fails
      due to dma_alloc_coherent(__GFP_ZERO) returns non zeroed
      pages.
      Signed-off-by: default avatarDaniel Hellstrom <daniel@gaisler.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7907ea42
    • David S. Miller's avatar
      sparc64: Fix pcr_ops initialization and usage bugs. · e7f7dcad
      David S. Miller authored
      [ Upstream commit 8bccf5b3 ]
      
      Christopher reports that perf_event_print_debug() can crash in uniprocessor
      builds.  The crash is due to pcr_ops being NULL.
      
      This happens because pcr_arch_init() is only invoked by smp_cpus_done() which
      only executes in SMP builds.
      
      init_hw_perf_events() is closely intertwined with pcr_ops being setup properly,
      therefore:
      
      1) Call pcr_arch_init() early on from init_hw_perf_events(), instead of
         from smp_cpus_done().
      
      2) Do not hook up a PMU type if pcr_ops is NULL after pcr_arch_init().
      
      3) Move init_hw_perf_events to a later initcall so that it we will be
         sure to invoke pcr_arch_init() after all cpus are brought up.
      
      Finally, guard the one naked sequence of pcr_ops dereferences in
      __global_pmu_self() with an appropriate NULL check.
      Reported-by: default avatarChristopher Alexander Tobias Schulze <cat.schulze@alice-dsl.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e7f7dcad
    • David S. Miller's avatar
      sparc64: Do not disable interrupts in nmi_cpu_busy() · 4eed408a
      David S. Miller authored
      [ Upstream commit 58556104 ]
      
      nmi_cpu_busy() is a SMP function call that just makes sure that all of the
      cpus are spinning using cpu cycles while the NMI test runs.
      
      It does not need to disable IRQs because we just care about NMIs executing
      which will even with 'normal' IRQs disabled.
      
      It is not legal to enable hard IRQs in a SMP cross call, in fact this bug
      triggers the BUG check in irq_work_run_list():
      
      	BUG_ON(!irqs_disabled());
      
      Because now irq_work_run() is invoked from the tail of
      generic_smp_call_function_single_interrupt().
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4eed408a
    • Dave Chinner's avatar
      xfs: ensure WB_SYNC_ALL writeback handles partial pages correctly · e81cffc4
      Dave Chinner authored
      commit 0d085a52 upstream.
      
      XFS has been having trouble with stray delayed allocation extents
      beyond EOF for a long time. Recent changes to the collapse range
      code has triggered erroneous EBUSY errors on page invalidtion for
      block size smaller than page size filesystems. These
      have been caused by dirty buffers beyond EOF on a partial page which
      do not get written to disk during a sync.
      
      The issue is that write-ahead in xfs_cluster_write() finds such a
      partial page and handles it by leaving the page dirty but pushing it
      into a writeback state. This used to work just fine, as the
      write_cache_pages() code would then find the dirty partial page in
      the next mapping tree lookup as the dirty tag is still set.
      
      Unfortunately, when we moved to a mark and sweep approach to
      writeback to fix other writeback sync issues, we broken this. THe
      act of marking the page as under writeback now clears the TOWRITE
      tag in the radix tree, even though the page is still dirty. This
      causes the TOWRITE tag to be cleared, and hence the next lookup on
      the mapping tree does not find the dirty partial page and so doesn't
      try to write it again.
      
      This same writeback bug was found recently in ext4 and fixed in
      commit 1c8349a1 ("ext4: fix data integrity sync in ordered mode")
      without communication to the wider filesystem community. We can use
      exactly the same fix here so the TOWRITE flag is not cleared on
      partial page writes.
      
      cc: stable@vger.kernel.org # dependent on 1c8349a1Root-cause-found-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e81cffc4
    • Chao Yu's avatar
      ecryptfs: avoid to access NULL pointer when write metadata in xattr · 0419937b
      Chao Yu authored
      commit 35425ea2 upstream.
      
      Christopher Head 2014-06-28 05:26:20 UTC described:
      "I tried to reproduce this on 3.12.21. Instead, when I do "echo hello > foo"
      in an ecryptfs mount with ecryptfs_xattr specified, I get a kernel crash:
      
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff8110eb39>] fsstack_copy_attr_all+0x2/0x61
      PGD d7840067 PUD b2c3c067 PMD 0
      Oops: 0002 [#1] SMP
      Modules linked in: nvidia(PO)
      CPU: 3 PID: 3566 Comm: bash Tainted: P           O 3.12.21-gentoo-r1 #2
      Hardware name: ASUSTek Computer Inc. G60JX/G60JX, BIOS 206 03/15/2010
      task: ffff8801948944c0 ti: ffff8800bad70000 task.ti: ffff8800bad70000
      RIP: 0010:[<ffffffff8110eb39>]  [<ffffffff8110eb39>] fsstack_copy_attr_all+0x2/0x61
      RSP: 0018:ffff8800bad71c10  EFLAGS: 00010246
      RAX: 00000000000181a4 RBX: ffff880198648480 RCX: 0000000000000000
      RDX: 0000000000000004 RSI: ffff880172010450 RDI: 0000000000000000
      RBP: ffff880198490e40 R08: 0000000000000000 R09: 0000000000000000
      R10: ffff880172010450 R11: ffffea0002c51e80 R12: 0000000000002000
      R13: 000000000000001a R14: 0000000000000000 R15: ffff880198490e40
      FS:  00007ff224caa700(0000) GS:ffff88019fcc0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 00000000bb07f000 CR4: 00000000000007e0
      Stack:
      ffffffff811826e8 ffff8800a39d8000 0000000000000000 000000000000001a
      ffff8800a01d0000 ffff8800a39d8000 ffffffff81185fd5 ffffffff81082c2c
      00000001a39d8000 53d0abbc98490e40 0000000000000037 ffff8800a39d8220
      Call Trace:
      [<ffffffff811826e8>] ? ecryptfs_setxattr+0x40/0x52
      [<ffffffff81185fd5>] ? ecryptfs_write_metadata+0x1b3/0x223
      [<ffffffff81082c2c>] ? should_resched+0x5/0x23
      [<ffffffff8118322b>] ? ecryptfs_initialize_file+0xaf/0xd4
      [<ffffffff81183344>] ? ecryptfs_create+0xf4/0x142
      [<ffffffff810f8c0d>] ? vfs_create+0x48/0x71
      [<ffffffff810f9c86>] ? do_last.isra.68+0x559/0x952
      [<ffffffff810f7ce7>] ? link_path_walk+0xbd/0x458
      [<ffffffff810fa2a3>] ? path_openat+0x224/0x472
      [<ffffffff810fa7bd>] ? do_filp_open+0x2b/0x6f
      [<ffffffff81103606>] ? __alloc_fd+0xd6/0xe7
      [<ffffffff810ee6ab>] ? do_sys_open+0x65/0xe9
      [<ffffffff8157d022>] ? system_call_fastpath+0x16/0x1b
      RIP  [<ffffffff8110eb39>] fsstack_copy_attr_all+0x2/0x61
      RSP <ffff8800bad71c10>
      CR2: 0000000000000000
      ---[ end trace df9dba5f1ddb8565 ]---"
      
      If we create a file when we mount with ecryptfs_xattr_metadata option, we will
      encounter a crash in this path:
      ->ecryptfs_create
        ->ecryptfs_initialize_file
          ->ecryptfs_write_metadata
            ->ecryptfs_write_metadata_to_xattr
              ->ecryptfs_setxattr
                ->fsstack_copy_attr_all
      It's because our dentry->d_inode used in fsstack_copy_attr_all is NULL, and it
      will be initialized when ecryptfs_initialize_file finish.
      
      So we should skip copying attr from lower inode when the value of ->d_inode is
      invalid.
      Signed-off-by: default avatarChao Yu <chao2.yu@samsung.com>
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0419937b
    • Fabio Estevam's avatar
      ARM: dts: imx28-evk: Let i2c0 run at 100kHz · d1866800
      Fabio Estevam authored
      commit d1e61eb4 upstream.
      
      Commit 78b81f46 ("ARM: dts: imx28-evk: Run I2C0 at 400kHz") caused issues
      when doing the following sequence in loop:
      
      - Boot the kernel
      - Perform audio playback
      - Reboot the system via 'reboot' command
      
      In many times the audio card cannot be probed, which causes playback to fail.
      
      After restoring to the original i2c0 frequency of 100kHz there is no such
      problem anymore.
      
      This reverts commit 78b81f46.
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1866800
    • klightspeed@killerwolves.net's avatar
      ARM: mvebu: Netgear RN102: Use Hardware BCH ECC · 8fd17365
      klightspeed@killerwolves.net authored
      commit ace85781 upstream.
      
      The bootloader on the Netgear ReadyNAS RN102 uses Hardware BCH ECC
      (strength = 4), while the pxa3xx NAND driver by default uses
      Hamming ECC (strength = 1).
      
      This patch changes the ECC mode on these machines to match that
      of the bootloader and of the stock firmware. That way, it is
      now possible to update the kernel from userland (e.g. using
      standard tools from mtd-utils package); u-boot will happily
      load and boot it.
      
      Fixes: 92beaccd ("ARM: mvebu: Enable NAND controller in ReadyNAS 102 .dts file")
      Signed-off-by: default avatarBen Peddell <klightspeed@killerwolves.net>
      Acked-by: default avatarEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Tested-by: default avatarArnaud Ebalard <arno@natisbad.org>
      Link: https://lkml.kernel.org/r/1410339341-3372-1-git-send-email-klightspeed@killerwolves.netSigned-off-by: default avatarJason Cooper <jason@lakedaemon.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8fd17365
    • Arnaud Ebalard's avatar
      ARM: mvebu: Netgear RN2120: Use Hardware BCH ECC · fac803d6
      Arnaud Ebalard authored
      commit 500abb6c upstream.
      
      The bootloader on the Netgear ReadyNAS RN2120 uses Hardware BCH
      ECC (strength = 4), while the pxa3xx NAND driver by default uses
      Hamming ECC (strength = 1).
      
      This patch changes the ECC mode on these machines to match that
      of the bootloader and of the stock firmware. That way, it is
      now possible to update the kernel from userland (e.g. using
      standard tools from mtd-utils package); u-boot will happily
      load and boot it.
      
      The issue was initially reported and fixed by Ben Pedell for
      RN102. The RN2120 shares the same Hynix H27U1G8F2BTR NAND
      flash and setup. This patch is based on Ben's fix for RN102.
      
      Fixes: ad51eddd ("ARM: mvebu: Enable NAND controller in ReadyNAS 2120 .dts file")
      Signed-off-by: default avatarArnaud Ebalard <arno@natisbad.org>
      Link: https://lkml.kernel.org/r/61f6a1b7ad0adc57a0e201b9680bc2e5f214a317.1410035142.git.arno@natisbad.orgSigned-off-by: default avatarJason Cooper <jason@lakedaemon.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fac803d6
    • Arnaud Ebalard's avatar
      ARM: mvebu: Netgear RN104: Use Hardware BCH ECC · 98080726
      Arnaud Ebalard authored
      commit 225b94cd upstream.
      
      The bootloader on the Netgear ReadyNAS RN104 uses Hardware BCH
      ECC (strength = 4), while the pxa3xx NAND driver by default uses
      Hamming ECC (strength = 1).
      
      This patch changes the ECC mode on these machines to match that
      of the bootloader and of the stock firmware. That way, it is
      now possible to update the kernel from userland (e.g. using
      standard tools from mtd-utils package); u-boot will happily
      load and boot it.
      
      The issue was initially reported and fixed by Ben Pedell for
      RN102. The RN104 shares the same Hynix H27U1G8F2BTR NAND
      flash and setup. This patch is based on Ben's fix for RN102.
      
      Fixes: 0373a558 ("ARM: mvebu: Enable NAND controller in ReadyNAS 104 .dts file")
      Signed-off-by: default avatarArnaud Ebalard <arno@natisbad.org>
      Link: https://lkml.kernel.org/r/920c7e7169dc6aaaa3eb4bced2336d38e77b8864.1410035142.git.arno@natisbad.orgSigned-off-by: default avatarJason Cooper <jason@lakedaemon.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      98080726
    • Andrew Lunn's avatar
      ARM: Kirkwood: Fix DT based DSA. · 7f688ac4
      Andrew Lunn authored
      commit 4f5e01e9 upstream.
      
      During the conversion of boards to use DT to instantiate Distributed
      Switch Architecture, nobody volunteered to test. As to be expected,
      the conversion was flawed. Testers and access to hardware has now
      become available, and this patch hopefully fixes the problems.
      
      dsa,mii-bus must be a phandle to the top level mdio node, not the port
      specific subnode of the mdio device.
      
      dsa,ethernet must be a phandle to the port subnode within the ethernet
      DT node, not the ethernet node.
      
      Don't pinctrl hog the card detect gpio for mvsdio.
      
      Rename the .dts files to make it clearer which file is for the Z0
      stepping and which for the A0 or later stepping.
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Cc: seugene@marvell.com
      Tested-by: default avatarEugene Sanivsky <seugene@marvell.com>
      Fixes: e2eaa339: ("ARM: Kirkwood: convert rd88f6281-setup.c to DT.")
      Fixes: e7c8f380: ("ARM: kirkwood: Convert mv88f6281gtw_ge switch setup to DT")
      Link: https://lkml.kernel.org/r/1409592941-22244-1-git-send-email-andrew@lunn.chSigned-off-by: default avatarJason Cooper <jason@lakedaemon.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7f688ac4
    • Ludovic Desroches's avatar
      ARM: at91/PMC: don't forget to write PMC_PCDR register to disable clocks · 0aeee1b4
      Ludovic Desroches authored
      commit cfa1950e upstream.
      
      When introducing support for sama5d3, the write to PMC_PCDR register has
      been accidentally removed.
      Reported-by: default avatarNathalie Cyrille <nathalie.cyrille@atmel.com>
      Signed-off-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
      Signed-off-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0aeee1b4
    • Andreas Henriksson's avatar
      ARM: at91: fix at91sam9263ek DT mmc pinmuxing settings · e9720836
      Andreas Henriksson authored
      commit b65e0fb3 upstream.
      
      As discovered on a custom board similar to at91sam9263ek and basing
      its devicetree on that one apparently the pin muxing doesn't get
      set up properly. This was discovered since the custom boards u-boot
      does funky stuff with the pin muxing and leaved it set to SPI
      which made the MMC driver not work under Linux.
      The fix is simply to define the given configuration as the default.
      This probably worked by pure luck before, but it's better to
      make the muxing explicitly set.
      Signed-off-by: default avatarAndreas Henriksson <andreas.henriksson@endian.se>
      Acked-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e9720836
    • David Dueck's avatar
      ARM: at91/dt: Fix typo regarding can0_clk · e85374c7
      David Dueck authored
      commit 0a51d644 upstream.
      
      Otherwise the clock for can0 will never get enabled.
      Signed-off-by: default avatarDavid Dueck <davidcdueck@googlemail.com>
      Signed-off-by: default avatarAnthony Harivel <anthony.harivel@emtrion.de>
      Acked-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e85374c7
    • David Henningsson's avatar
      ALSA: hda - Add missing terminating entry to SND_HDA_PIN_QUIRK macro · b8758f7d
      David Henningsson authored
      commit fb54a645 upstream.
      
      Without this terminating entry, the pin matching would continue
      across random memory until a zero or a non-matching entry was found.
      
      The result being that in some cases, the pin quirk would not be
      applied correctly.
      Signed-off-by: default avatarDavid Henningsson <david.henningsson@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b8758f7d
    • Takashi Iwai's avatar
      ALSA: hda - Fix inverted LED gpio setup for Lenovo Ideapad · 0dfdfc11
      Takashi Iwai authored
      commit b1974f96 upstream.
      
      We implemented in a wrong way for mute LED on Lenovo Ideapad; the bit
      must be flipped.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16373
      Fixes: 3e887f37 ('ALSA: hda - Add mute LED support to Lenovo Ideapad')
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0dfdfc11
    • Anssi Hannula's avatar
      ALSA: hda - hdmi: Fix missing ELD change event on plug/unplug · 7c46686b
      Anssi Hannula authored
      commit 6acce400 upstream.
      
      The ELD ALSA control change event is sent by hdmi_present_sense() when
      eld_changed is true.
      
      Currently, it is only true when the ELD buffer contents have been
      modified. However, the user-visible ELD controls also change to a
      zero-length value and back when eld_valid is unset/set, and no event is
      currently sent in such cases (such as when unplugging or replugging a
      sink).
      
      Fix the code to always set eld_changed if eld_valid value is changed,
      and therefore to always send the change event when the user-visible
      value changes.
      Signed-off-by: default avatarAnssi Hannula <anssi.hannula@iki.fi>
      Cc: David Henningsson <david.henningsson@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c46686b
    • Vlad Catoi's avatar
      ALSA: usb-audio: Add support for Steinberg UR22 USB interface · a8c59334
      Vlad Catoi authored
      commit f0b127fb upstream.
      
      Adding support for Steinberg UR22 USB interface via quirks table patch
      
      See Ubuntu bug report:
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1317244
      Also see threads:
      http://linux-audio.4202.n7.nabble.com/Support-for-Steinberg-UR22-Yamaha-USB-chipset-0499-1509-tc82888.html#a82917
      http://www.steinberg.net/forums/viewtopic.php?t=62290
      
      Tested by at least 4 people judging by the threads.
      Did not test MIDI interface, but audio output and capture both are
      functional. Built 3.17 kernel with this driver on Ubuntu 14.04 & tested with mpg123
      Patch applied to 3.13 Ubuntu kernel works well enough for daily use.
      Signed-off-by: default avatarVlad Catoi <vladcatoi@gmail.com>
      Acked-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a8c59334
    • Harsha Priya's avatar
      ALSA: ALC283 codec - Avoid pop noise on headphones during suspend/resume · afc8ff20
      Harsha Priya authored
      commit b450b17c upstream.
      
      This patch sets the headphones mode to default before suspending
      which helps avoid the pop noise on headphones
      Signed-off-by: default avatarHarsha Priya <harshapriya.n@intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      afc8ff20
    • Takashi Iwai's avatar
      ALSA: emu10k1: Fix deadlock in synth voice lookup · 2ecccbd0
      Takashi Iwai authored
      commit 95926035 upstream.
      
      The emu10k1 voice allocator takes voice_lock spinlock.  When there is
      no empty stream available, it tries to release a voice used by synth,
      and calls get_synth_voice.  The callback function,
      snd_emu10k1_synth_get_voice(), however, also takes the voice_lock,
      thus it deadlocks.
      
      The fix is simply removing the voice_lock holds in
      snd_emu10k1_synth_get_voice(), as this is always called in the
      spinlock context.
      Reported-and-tested-by: default avatarArthur Marsh <arthur.marsh@internode.on.net>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2ecccbd0
    • Takashi Sakamoto's avatar
      ALSA: bebob: Fix failure to detect source of clock for Terratec Phase 88 · 9876302e
      Takashi Sakamoto authored
      commit 3f403286 upstream.
      
      This patch fixes a failure to open PCM device with -ENOSYS in
      Terratec Phase 88.
      
      Terratec Phase 88 has two Selector Function Blocks of AVC Audio subunit
      to switch source of clock. One is to switch internal/external for the
      source and another is to switch word/spdif for the external clock.
      
      The IDs for these Selector Function Blocks are 9 and 8. But in current
      implementation they're 0 and 0.
      Reported-by: default avatarAndrás Murányi <muranyia@gmail.com>
      Tested-by: default avatarAndrás Murányi <muranyia@gmail.com>
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9876302e
    • Anatol Pomozov's avatar
      ALSA: pcm: use the same dma mmap codepath both for arm and arm64 · 5d80a079
      Anatol Pomozov authored
      commit a011e213 upstream.
      
      This avoids following kernel crash when try to playback on arm64
      
      [  107.497203] [<ffffffc00046b310>] snd_pcm_mmap_data_fault+0x90/0xd4
      [  107.503405] [<ffffffc0001541ac>] __do_fault+0xb0/0x498
      [  107.508565] [<ffffffc0001576a0>] handle_mm_fault+0x224/0x7b0
      [  107.514246] [<ffffffc000092640>] do_page_fault+0x11c/0x310
      [  107.519738] [<ffffffc000081100>] do_mem_abort+0x38/0x98
      
      Tested: backported to 3.14 and tried to playback on arm64 machine
      Signed-off-by: default avatarAnatol Pomozov <anatol.pomozov@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5d80a079
    • Victor Kamensky's avatar
      arm64: compat: fix compat types affecting struct compat_elf_prpsinfo · 8ef4081b
      Victor Kamensky authored
      commit 971a5b6f upstream.
      
      The compat_elf_prpsinfo structure does not match the arch/arm struct
      elf_pspsinfo definition. As result NT_PRPSINFO note in core file
      created by arm64 kernel for aarch32 (compat) process has wrong size.
      So gdb cannot display command that caused process crash.
      
      Fix is to change size of __compat_uid_t, __compat_gid_t so it would
      match size of similar fields in arch/arm case.
      Signed-off-by: default avatarVictor Kamensky <victor.kamensky@linaro.org>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ef4081b
    • Dmitry Kasatkin's avatar
      ima: provide flag to identify new empty files · 88a111df
      Dmitry Kasatkin authored
      commit b151d6b0 upstream.
      
      On ima_file_free(), newly created empty files are not labeled with
      an initial security.ima value, because the iversion did not change.
      Commit dff6efc3 "fs: fix iversion handling" introduced a change in
      iversion behavior.  To verify this change use the shell command:
      
        $ (exec >foo)
        $ getfattr -h -e hex -d -m security foo
      
      This patch defines the IMA_NEW_FILE flag.  The flag is initially
      set, when IMA detects that a new file is created, and subsequently
      checked on the ima_file_free() hook to set the initial security.ima
      value.
      Signed-off-by: default avatarDmitry Kasatkin <d.kasatkin@samsung.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      88a111df
    • Dmitry Kasatkin's avatar
      ima: fix fallback to use new_sync_read() · b6f9e215
      Dmitry Kasatkin authored
      commit 27cd1fc3 upstream.
      
      3.16 commit aad4f8bb
      'switch simple generic_file_aio_read() users to ->read_iter()'
      replaced ->aio_read with ->read_iter in most of the file systems
      and introduced new_sync_read() as a replacement for do_sync_read().
      
      Most of file systems set '->read' and ima_kernel_read is not affected.
      When ->read is not set, this patch adopts fallback call changes from the
      vfs_read.
      Signed-off-by: default avatarDmitry Kasatkin <d.kasatkin@samsung.com>
      Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b6f9e215