- 06 Apr, 2016 40 commits
-
-
Boqun Feng authored
BugLink: http://bugs.launchpad.net/bugs/1556096 On powerpc, acquire and release semantics can be achieved with lightweight barriers("lwsync" and "ctrl+isync"), which can be used to implement __atomic_op_{acquire,release}. For release semantics, since we only need to ensure all memory accesses that issue before must take effects before the -store- part of the atomics, "lwsync" is what we only need. On the platform without "lwsync", "sync" should be used. Therefore in __atomic_op_release() we use PPC_RELEASE_BARRIER. For acquire semantics, "lwsync" is what we only need for the similar reason. However on the platform without "lwsync", we can use "isync" rather than "sync" as an acquire barrier. Therefore in __atomic_op_acquire() we use PPC_ACQUIRE_BARRIER, which is barrier() on UP, "lwsync" if available and "isync" otherwise. Implement atomic{,64}_{add,sub,inc,dec}_return_relaxed, and build other variants with these helpers. Signed-off-by:
Boqun Feng <boqun.feng@gmail.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (cherry picked from commit dc53617c) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Boqun Feng authored
BugLink: http://bugs.launchpad.net/bugs/1556096 Some architectures may have their special barriers for acquire, release and fence semantics, so that general memory barriers(smp_mb__*_atomic()) in the default __atomic_op_*() may be too strong, so allow architectures to define their own helpers which can overwrite the default helpers. Signed-off-by:
-
David Leonard authored
Fixed invocation of dh_shlibdeps when cross-compiling with do_linux_tools=true. Without being told where to find the crossdev libs, dh_shlibdeps will emit these warnings and fail the linux-tools package: Debug: binary-acm7xxx ... dh_shlibdeps -plinux-headers-4.4.0-15-generic arm-linux-gnueabihf-objdump: .../asn1_compiler: File format not recognized arm-linux-gnueabihf-objdump: .../extract-cert: File format not recognized ... For example: archtriple=arm-linux-gnueabihf flavour=generic dpkg-architecture -t $archtriple -c fakeroot \ debian/rules \ binary-$flavour binary-perarch \ AUTOBUILD=true \ abi_suffix= \ do_linux_tools=true \ do_tools=true \ do_tools_usbip=false \ do_tools_cpupower=false \ do_tools_perf=true \ do_tools_x86=false Signed-off-by:David Leonard <david.leonard@opengear.com> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1564206Signed-off-by:
-
Ming Lei authored
BugLink: http://bugs.launchpad.net/bugs/1546439 The initialization of partition's percpu_ref should have been done before sending out KOBJ_ADD, which may cause userspace to read partition table. This patch should fix this issue. Reported-by:
Naveen Kaje <nkaje@codeaurora.org> Fixes: 6c71013e(block: partition: convert percpu ref) Signed-off-by:
Ming Lei <ming.lei@canonical.com> Signed-off-by:
-
Serge Hallyn authored
BugLink: http://bugs.launchpad.net/bugs/1563921 our mountinfo output now shows 'nsroot='. If userspace like criu copy/pastes mount options from there into a new mount command, we should ignore it. Signed-off-by:
Serge Hallyn <serge.hallyn@ubuntu.com> Tested-by:
Tycho Andersen <tycho.andersen@canonical.com> Signed-off-by:
-
Tim Gardner authored
cking> so, all the ZFS tests on powerpc64 pass except one test, which is ioctl FS_IOC_GETFLAGS where the cmd is being barfed up somewhere in the ioctl 32/64 thunking. I've filed a bug upstream. Since that ioctl is not frequently used, I think we should enable powerpc64 and fix up the ioctl as a SRU later on. Signed-off-by: -
Haiyang Zhang authored
BugLink: http://bugs.launchpad.net/bugs/1563688 During hot add, vmbus_device_register() is called from vmbus_onoffer(), on the same workqueue as the subchannel offer message work-queue, so subchannel offer won't be processed until the vmbus_device_register()/... /netvsc_probe() is done. Also, vmbus_device_register() is called with channel_mutex locked, which prevents subchannel processing too. So the "waiting for sub-channel processing" will not success in hot add case. But, in usual module loading, the netvsc_probe() is called from different code path, and doesn't fail. This patch resolves the deadlock during NIC hot-add, and speeds up NIC loading time. Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit d66ab514) Signed-off-by:
-
Johannes Weiner authored
BugLink: http://bugs.launchpad.net/bugs/1547231 Commit b7643757 ("procfs: mark thread stack correctly in proc/<pid>/maps") added [stack:TID] annotation to /proc/<pid>/maps. Finding the task of a stack VMA requires walking the entire thread list, turning this into quadratic behavior: a thousand threads means a thousand stacks, so the rendering of /proc/<pid>/maps needs to look at a million combinations. The cost is not in proportion to the usefulness as described in the patch. Drop the [stack:TID] annotation to make /proc/<pid>/maps (and /proc/<pid>/numa_maps) usable again for higher thread counts. The [stack] annotation inside /proc/<pid>/task/<tid>/maps is retained, as identifying the stack VMA there is an O(1) operation. Siddesh said: "The end users needed a way to identify thread stacks programmatically and there wasn't a way to do that. I'm afraid I no longer remember (or have access to the resources that would aid my memory since I changed employers) the details of their requirement. However, I did do this on my own time because I thought it was an interesting project for me and nobody really gave any feedback then as to its utility, so as far as I am concerned you could roll back the main thread maps information since the information is available in the thread-specific files" Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Cc: "Kirill A. Shutemov" <kirill@shutemov.name> Cc: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> Cc: Shaohua Li <shli@fb.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 65376df5) Signed-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1398274 drivers/char/tpm/tpm_tis.c:838: warning: ‘tpm_tis_resume’ defined but not used Reported-by:
James Morris <jmorris@namei.org> Fixes: 00194826 ("tpm_tis: Clean up the force=1 module parameter") Signed-off-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> cc: stable@vger.kernel.org (cherry picked from commit 2cb6d646) Signed-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1398274 Wrong call order. Reported-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Fixes: 74d6b3ceSigned-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1398274 In all cases use dev_name() for the mapped resources. This is both for sake of consistency and also with some platforms resource name given by ACPI object seems to return garbage. Signed-off-by:
-
Harald Hoyer authored
BugLink: http://bugs.launchpad.net/bugs/1398274 The commit 0cc698af ("vTPM: support little endian guests") copied the event, but without the event data, did an endian conversion on the size and tried to output the event data from the copied version, which has only have one byte of the data, resulting in garbage event data. [jarkko.sakkinen@linux.intel.com: fixed minor coding style issues and renamed the local variable tempPtr as temp_ptr now that there is an excuse to do this.] Signed-off-by:
Harald Hoyer <harald@redhat.com> Fixes: 0cc698af ("vTPM: support little endian guests") Reviewed-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1398274 Call put_device() and return error code if devm_add_action() fails. Signed-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1398274 It's better to set the continueSession attribute for the unseal operation so that the session object is not removed as a side-effect when the operation is successful. Since a user process created the session, it should be also decide when the session is destroyed. Signed-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1398274 If the initialization fails before tpm_chip_register(), put_device() will be not called, which causes release callback not to be called. This patch fixes the issue by adding put_device() to devres list of the parent device. Fixes: 313d21ee ("tpm: device class for tpm") Signed-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1398274 Fixed the rollback and gave more self-documenting names for the functions. Fixes: d972b052 ("tpm: fix call order in tpm-chip.c") Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 To support the force mode in tpm_tis we need to use resource locking in tpm_crb as well, via devm_ioremap_resource. The light restructuring better aligns crb and tis and makes it easier to see the that new changes make sense. The control area and its associated buffers do not always fall in the range of the iomem resource given by the ACPI object. This patch fixes the issue by mapping the buffers if this is the case. [jarkko.sakkinen@linux.intel.com: squashed update described in the last paragraph.] Signed-off-by:
Peter Huewe <peterhuewe@gmx.de> Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 ioread32 and readl are defined to read from PCI style memory, ie little endian and return the result in host order. On platforms where a swap is required ioread32/readl do the swap internally (eg see ppc). Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 The TPM core has long assumed that every device has a driver attached, however the force path was attaching the TPM core outside of a driver context. This isn't generally reliable as the user could detatch the driver using sysfs or something, but commit b8b2c7d8 ("base/platform: assert that dev_pm_domain callbacks are called unconditionally") forced the issue by leaving the driver pointer NULL if there is no probe. Rework the TPM setup to create a platform device with resources and then allow the driver core to naturally bind and probe it through the normal mechanisms. All this structure is needed anyhow to enable TPM for OF environments. Finally, since the entire flow is changing convert the init/exit to use the modern ifdef-less coding style when possible Reported-by:
"Wilck, Martin" <martin.wilck@ts.fujitsu.com> Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 This does a request_resource under the covers which means tis holds a lock on the memory range it is using so other drivers cannot grab it. When doing probing it is important to ensure that other drivers are not using the same range before tis starts touching it. To do this flow the actual struct resource from the device right through to devm_ioremap_resource. This ensures all the proper resource meta-data is carried down. Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 If the ACPI tables do not declare a memory resource for the TPM2 then do not just fall back to the x86 default base address. Also be stricter when checking the ancillary TPM2 ACPI data and error out if any of this data is wrong rather than blindly assuming TPM1. Fixes: 399235dc ("tpm, tpm_tis: fix tpm_tis ACPI detection issue with TPM 2.0") Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 Instead of clearing the global interrupts flag when any device does not have an interrupt just pass -1 through tpm_info.irq. The only thing that asks for autoprobing is the force=1 path. Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1398274 include/acpi/actbl2.h is the proper place for these definitions and the needed TPM2 ones have been there since commit 413d4a6d ("ACPICA: Update TPM2 ACPI table") This also drops a couple of le32_to_cpu's for members of this table, the existing swapping was not done consistently, and the standard used by other Linux callers of acpi_get_table is unswapped. Signed-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1398274 In my original patch sealing with policy was done with dynamically allocated buffer that I changed later into an array so the checks in tpm2-cmd.c became invalid. This patch fixes the issue. Fixes: 5beb0c43 ("keys, trusted: seal with a TPM2 authorization policy") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Jerry Snitselaar authored
BugLink: http://bugs.launchpad.net/bugs/1398274 tpm_tis.c already gets actbl2.h via linux/acpi.h -> acpi/acpi.h -> acpi/actbl.h -> acpi/actbl2.h, so the direct include in tpm_tis.c is not needed. Signed-off-by:
Jerry Snitselaar <jsnitsel@redhat.com> Acked-by:
-
Dasaratharaman Chandramouli authored
BugLink: http://bugs.launchpad.net/bugs/1461365 Enables "Intel(R) Xeon Phi(TM) Processor x200 Product Family" support, formerly code-named KNL. It is based on modified Intel Atom Silvermont microarchitecture. Signed-off-by:
Dasaratharaman Chandramouli <dasaratharaman.chandramouli@intel.com> [micah.barany@intel.com: adjusted values of residency and latency] Signed-off-by:
Micah Barany <micah.barany@intel.com> [hubert.chrzaniuk@intel.com: removed deprecated CPUIDLE_FLAG_TIME_VALID flag] Signed-off-by:
Hubert Chrzaniuk <hubert.chrzaniuk@intel.com> Signed-off-by:
Pawel Karczewski <pawel.karczewski@intel.com> Signed-off-by:
Len Brown <len.brown@intel.com> (cherry picked from commit 281baf7a) Signed-off-by:
-
Manoj N. Kumar authored
BugLink: http://bugs.launchpad.net/bugs/1563485 While profiling the cxlflash_queuecommand() path under a heavy load it was found that number of retries to find cmd_room was fairly high. There are two problems with the current back-off: a) It starts with a udelay of 0 b) It backs-off linearly Tried several approaches (a higher multiple 10*n, 100*n, as well as n^2, 2^n) and found that the exponential back-off(2^n) approach had the least overall cost. Cost as being defined as overall time spent waiting. The fix is to change the linear back-off to an exponential back-off. This solution also takes care of the problem with the initial delay (starts with 1 usec). Signed-off-by:
Manoj N. Kumar <manoj@linux.vnet.ibm.com> Acked-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Uma Krishnan <ukrishn@linux.vnet.ibm.com> Signed-off-by:
-
Manoj N. Kumar authored
BugLink: http://bugs.launchpad.net/bugs/1563485 With the current value of cmd_per_lun at 16, the throughput over a single adapter is limited to around 150kIOPS. Increase the value of cmd_per_lun to 256 to improve throughput. With this change a single adapter is able to attain close to the maximum throughput (380kIOPS). Also change the number of RRQ entries that can be queued. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> (cherry picked from commit 83430833) Signed-off-by:
-
Manoj N. Kumar authored
BugLink: http://bugs.launchpad.net/bugs/1563485 When switching to the internal LUN defined on the IBM CXL flash adapter, there is an unnecessary scan occurring on the second port. This scan leads to the following extra lines in the log: Dec 17 10:09:00 tul83p1 kernel: [ 3708.561134] cxlflash 0008:00:00.0: cxlflash_queuecommand: (scp=c0000000fc1f0f00) 11/1/0/0 cdb=(A0000000-00000000-10000000-00000000) Dec 17 10:09:00 tul83p1 kernel: [ 3708.561147] process_cmd_err: cmd failed afu_rc=32 scsi_rc=0 fc_rc=0 afu_extra=0xE, scsi_extra=0x0, fc_extra=0x0 By definition, both of the internal LUNs are on the first port/channel. When the lun_mode is switched to internal LUN the same value for host->max_channel is retained. This causes an unnecessary scan over the second port/channel. This fix alters the host->max_channel to 0 (1 port), if internal LUNs are configured and switches it back to 1 (2 ports) while going back to external LUNs. Signed-off-by:
-
Tim Gardner authored
Ignore: yes Signed-off-by: -
Tim Gardner authored
Signed-off-by: -
Mahesh Salgaonkar authored
BugLink: http://bugs.launchpad.net/bugs/1560552 http://patchwork.ozlabs.org/patch/577193/ The kernel boot parameter 'nr_cpus=' allows one to specify number of possible cpus in the system. In the normal scenario the first cpu (cpu0) that shows up is the boot cpu and hence it gets covered under nr_cpus limit. But this assumption will be broken in kdump scenario where kdump kenrel after a crash can boot up on an non-zero boot cpu. The paca structure allocation depends on value of nr_cpus and is indexed using logical cpu ids. This definetly will be an issue if boot cpu id > nr_cpus This patch modifies allocate_pacas() and smp_setup_cpu_maps() to accommodate boot cpu for the case where boot_cpuid > nr_cpu_ids. This change would help to reduce the memory reservation requirement for kdump on ppc64. Signed-off-by:
Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
-
Guilherme G. Piccoli authored
BugLink: http://bugs.launchpad.net/bugs/1560514 https://patchwork.ozlabs.org/patch/599720/ The domain/PHB field of PCI addresses has its value obtained from a global variable, incremented each time a new domain (represented by struct pci_controller) is added on the system. The domain addition process happens during boot or due to PCI device hotplug. As recent kernels are using predictable naming for network interfaces, the network stack is more tied to PCI naming. This can be a problem in hotplug scenarios, because PCI addresses will change if devices are removed and then re-added. This situation seems unusual, but it can happen if a user wants to replace a NIC without rebooting the machine, for example. This patch changes the way PCI domain values are generated: now, we use device-tree properties to assign fixed PHB numbers to PCI addresses when available (meaning pSeries and PowerNV cases). We also use a bitmap to allow dynamic PHB numbering when device-tree properties are not used. This bitmap keeps track of used PHB numbers and if a PHB is released (by hotplug operations for example), it allows the reuse of this PHB number, avoiding PCI address to change in case of device remove and re-add soon after. No functional changes were introduced. Reviewed-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by:
Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com> Signed-off-by:
-
dann frazier authored
BugLink: http://bugs.launchpad.net/bugs/1562968 Different implementations of Cavium ThunderX use different phys for network support. Signed-off-by:
dann frazier <dann.frazier@canonical.com> Signed-off-by:
-
Andreas Färber authored
BugLink: http://bugs.launchpad.net/bugs/1562968 Drop two extra occurrences of "on" in option title and help text. Fixes: 379d7ac7 ("phy: mdio-thunder: Add driver for Cavium Thunder SoC MDIO buses.") Cc: David Daney <david.daney@cavium.com> Signed-off-by:
Andreas Färber <afaerber@suse.de> Acked-by:
David Daney <david.daney@cavium.com> Signed-off-by:
-
David Daney authored
BugLink: http://bugs.launchpad.net/bugs/1562968 Previously we selected MDIO_OCTEON, which after creating the Thunder specific MDIO bus driver is much less useful. Signed-off-by:
-
David Daney authored
BugLink: http://bugs.launchpad.net/bugs/1562968 When the code was factored out of mdio-octeon.c, the MODULE_DESCRIPTION, MODULE_AUTHOR and MODULE_LICENSE annotations were inadvertently omitted. Restore them so that we don't get kernel taint warnings upon module loading. Signed-off-by:
-
David Daney authored
BugLink: http://bugs.launchpad.net/bugs/1562968 The Cavium Thunder SoCs have multiple MIDO buses that are part of a single PCI device. To model this in the device tree we call the PCI parent device a "cavium,thunder-8890-mdio-nexus", it has several children, one for each MDIO bus. The MDIO bus hardware is identical to that found in the OCTEON SoCs, so we use that code for things that are not part of the PCI driver probe/remove Signed-off-by:
-
dann frazier authored
BugLink: http://bugs.launchpad.net/bugs/1562968Signed-off-by:
-
