Skip to content
  1. Jan 31, 2017
  2. Jan 30, 2017
    • Alistair Popple's avatar
      powerpc/powernv: Use OPAL call for TCE kill on NVLink2 · 616badd2
      Alistair Popple authored
      
      
      Add detection of NPU2 PHBs. NPU2/NVLink2 has a different register
      layout for the TCE kill register therefore TCE invalidation should be
      done via the OPAL call rather than using the register directly as it
      is for PHB3 and NVLink1. This changes TCE invalidation to use the OPAL
      call in the case of a NPU2 PHB model.
      
      Signed-off-by: default avatarAlistair Popple <alistair@popple.id.au>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      616badd2
    • Alistair Popple's avatar
      powerpc/powernv: Initialise nest mmu · 1d0761d2
      Alistair Popple authored
      
      
      POWER9 contains an off core mmu called the nest mmu (NMMU). This is
      used by other hardware units on the chip to translate virtual
      addresses into real addresses. The unit attempting an address
      translation provides the majority of the context required for the
      translation request except for the base address of the partition table
      (ie. the PTCR) which needs to be programmed into the NMMU.
      
      This patch adds a call to OPAL to set the PTCR for the nest mmu in
      opal_init().
      
      Signed-off-by: default avatarAlistair Popple <alistair@popple.id.au>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      1d0761d2
    • Reza Arbab's avatar
      powerpc/mm: Allow memory hotplug into an offline node · 2a8628d4
      Reza Arbab authored
      Relax the check preventing us from hotplugging into an offline node.
      
      This limitation was added in commit 482ec7c4
      
       ("[PATCH] powerpc numa:
      Support sparse online node map") to prevent adding resources to an
      uninitialized node.
      
      These days, there is no harm in doing so. The addition will actually
      cause the node to be initialized and onlined; add_memory_resource()
      calls hotadd_new_pgdat() (if necessary) and node_set_online().
      
      Signed-off-by: default avatarReza Arbab <arbab@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      2a8628d4
    • Reza Arbab's avatar
      powerpc/mm: Simplify loop control in parse_numa_properties() · 7656cd8e
      Reza Arbab authored
      
      
      The flow of the main loop in parse_numa_properties() is overly
      complicated. Simplify it to be less confusing and easier to read.
      No functional change.
      
      The end of the main loop in parse_numa_properties() looks like this:
      
      	for_each_node_by_type(...) {
      		...
      		if (!condition) {
      			if (--ranges)
      				goto new_range;
      			else
      				continue;
      		}
      
      		statement();
      
      		if (--ranges)
      			goto new_range;
      		/* else
      		 *	continue; <- implicit, this is the end of the loop
      		 */
      	}
      
      The only effect of !condition is to skip execution of statement(). This
      can be rewritten in a simpler way:
      
      	for_each_node_by_type(...) {
      		...
      		if (condition)
      			statement();
      
      		if (--ranges)
      			goto new_range;
      	}
      
      Signed-off-by: default avatarReza Arbab <arbab@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      7656cd8e
    • Mahesh Salgaonkar's avatar
      powerpc/fadump: Fix the race in crash_fadump(). · f2a5e8f0
      Mahesh Salgaonkar authored
      
      
      There are chances that multiple CPUs can call crash_fadump() simultaneously
      and would start duplicating same info to vmcoreinfo ELF note section. This
      causes makedumpfile to fail during kdump capture. One example is,
      triggering dumprestart from HMC which sends system reset to all the CPUs at
      once.
      
      makedumpfile --dump-dmesg /proc/vmcore
      read_vmcoreinfo_basic_info: Invalid data in /tmp/vmcoreinfoyjgxlL: CRASHTIME=1475605971CRASHTIME=1475605971CRASHTIME=1475605971CRASHTIME=1475605971CRASHTIME=1475605971CRASHTIME=1475605971CRASHTIME=1475605971CRASHTIME=1475605971
      makedumpfile Failed.
      Running makedumpfile --dump-dmesg /proc/vmcore failed (1).
      
      makedumpfile  -d 31 -l /proc/vmcore
      read_vmcoreinfo_basic_info: Invalid data in /tmp/vmcoreinfo1mmVdO: CRASHTIME=1475605971CRASHTIME=1475605971CRASHTIME=1475605971CRASHTIME=1475605971CRASHTIME=1475605971CRASHTIME=1475605971CRASHTIME=1475605971CRASHTIME=1475605971
      makedumpfile Failed.
      Running makedumpfile  -d 31 -l /proc/vmcore failed (1).
      
      Signed-off-by: default avatarMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      f2a5e8f0
    • Aneesh Kumar K.V's avatar
      powerpc/mm/hash: Properly mask the ESID bits when building proto VSID · 79270e0a
      Aneesh Kumar K.V authored
      
      
      The proto VSID is built using both the MMU context id and effective
      segment ID (ESID). We should not have overlapping bits between those.
      That could result in us having a VSID collision. With the current code
      we missed masking the top bits of the ESID. This implies for kernel
      address we ended up using the top 4 bits of the ESID as part of the
      proto VSID, which is wrong.
      
      The current code use the top 4 context values (0x7fffc - 0x7ffff) for
      the kernel. With those context IDs used for the kernel, we don't run
      into VSID collisions because we get the same proto VSID irrespective of
      whether we mask the ESID bits or not. eg:
      
        ea         = 0xf000000000000000
        context    = 0x7ffff
      
        w/out masking:
        proto_vsid = (0x7ffff << 6 | 0xf000000000000000 >> 40)
      	     = (0x1ffffc0 | 0xf00000)
      	     =  0x1ffffc0
      
        with masking:
        proto_vsid = (0x7ffff << 6 | ((0xf000000000000000 >> 40) & 0x3f))
      	     = (0x1ffffc0 | (0xf00000 & 0x3f))
      	     =  0x1ffffc0 | 0)
      	     =  0x1ffffc0
      
      So although there is no bug, the code is still overly subtle, so fix it
      to save ourselves pain in future.
      
      Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      79270e0a
  3. Jan 25, 2017
  4. Jan 23, 2017
  5. Jan 22, 2017
    • Linus Torvalds's avatar
      Merge tag 'usb-4.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb · c497f8d1
      Linus Torvalds authored
      Pull USB fixes from Greg KH:
       "Here are a few small USB fixes for 4.10-rc5.
      
        Most of these are gadget/dwc2 fixes for reported issues, all of these
        have been in linux-next for a while. The last one is a single xhci
        WARN_ON removal to handle an issue that the dwc3 driver is hitting in
        the 4.10-rc tree. The warning is harmless and needs to be removed, and
        a "real" fix that is more complex will show up in 4.11-rc1 for this
        device.
      
        That last patch hasn't been in linux-next yet due to the weekend
        timing, but it's a "simple" WARN_ON() removal so what could go wrong?
        :)"
      
      Famous last words.
      
      * tag 'usb-4.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
        xhci: remove WARN_ON if dma mask is not set for platform devices
        usb: dwc2: host: fix Wmaybe-uninitialized warning
        usb: dwc2: gadget: Fix GUSBCFG.USBTRDTIM value
        usb: gadget: udc: atmel: remove memory leak
        usb: dwc3: exynos fix axius clock error path to do cleanup
        usb: dwc2: Avoid suspending if we're in gadget mode
        usb: dwc2: use u32 for DT binding parameters
        usb: gadget: f_fs: Fix iterations on endpoints.
        usb: dwc2: gadget: Fix DMA memory freeing
        usb: gadget: composite: Fix function used to free memory
      c497f8d1