- 06 Apr, 2016 40 commits
-
-
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 <jgunthorpe@obsidianresearch.com> Tested-by:
Wilck, Martin <martin.wilck@ts.fujitsu.com> Tested-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Reviewed-by:
Peter Huewe <peterhuewe@gmx.de> (cherry picked from commit 51dd43df) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
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 S. Miller <davem@davemloft.net> (cherry picked from commit e2ad1f97) 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:
-
David Daney authored
BugLink: http://bugs.launchpad.net/bugs/1562968 A follow-on patch uses PCI probing to find the Thunder MDIO hardware. In preparation for this, split out the common code into a new file mdio-cavium.c, which will be used by both the existing OCTEON driver, and the new Thunder PCI based driver. As part of the refactoring simplify the struct cavium_mdiobus by removing fields that are only ever used in the probe function and can just as well be local variables. Use readq/writeq in preference to readq_relaxed/writeq_relaxed as the relaxed form was an optimization for an early chip revision, and the MDIO drivers are not performance bottlenecks that need optimization in the first place. Signed-off-by:
-
dann frazier authored
BugLink: http://bugs.launchpad.net/bugs/1562968Signed-off-by:
-
David Daney authored
BugLink: http://bugs.launchpad.net/bugs/1562968 Remove the call to force the octeon-mdio driver to be loaded. Allow the standard driver loading mechanisms to load the PHY drivers, and use -EPROBE_DEFER to cause the BGX driver to be probed only after the PHY drivers are available. Reorder the setting of MAC addresses and PHY probing to allow BGX LMACs with no attached PHY to still be assigned a MAC address. Signed-off-by:
-
Dan Williams authored
BugLink: http://bugs.launchpad.net/bugs/1563293 ZONE_DEVICE (merged in 4.3) and ZONE_CMA (proposed) are examples of new mm zones that are bumping up against the current maximum limit of 4 zones, i.e. 2 bits in page->flags for the GFP_ZONE_TABLE. The GFP_ZONE_TABLE poses an interesting constraint since include/linux/gfp.h gets included by the 32-bit portion of a 64-bit build. We need to be careful to only build the table for zones that have a corresponding gfp_t flag. GFP_ZONES_SHIFT is introduced for this purpose. This patch does not attempt to solve the problem of adding a new zone that also has a corresponding GFP_ flag. Vlastimil points out that ZONE_DEVICE, by depending on x86_64 and SPARSEMEM_VMEMMAP implies that SECTIONS_WIDTH is zero. In other words even though ZONE_DEVICE does not fit in GFP_ZONE_TABLE it is free to consume another bit in page->flags (expand ZONES_WIDTH) with room to spare. Link: https://bugzilla.kernel.org/show_bug.cgi?id=110931 Fixes: 033fbae9 ("mm: ZONE_DEVICE for "device memory"") Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Reported-by:
Mark <markk@clara.co.uk> Reported-by:
Vlastimil Babka <vbabka@suse.cz> Cc: Mel Gorman <mgorman@suse.de> Cc: Rik van Riel <riel@redhat.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit b11a7b94) Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1563293 This reverts commit f671c3e6. This patch never made it upstream. Instead, commit b11a7b94 ('mm: exclude ZONE_DEVICE from GFP_ZONE_TABLE') replaced it. Signed-off-by:
-
Sergey Senozhatsky authored
BugLink: http://bugs.launchpad.net/bugs/1534216 console_unlock() allows to cond_resched() if its caller has set `console_may_schedule' to 1, since 8d91f8b1 ("printk: do cond_resched() between lines while outputting to consoles"). The rules are: -- console_lock() always sets `console_may_schedule' to 1 -- console_trylock() always sets `console_may_schedule' to 0 However, console_trylock() callers (among them is printk()) do not always call printk() from atomic contexts, and some of them can cond_resched() in console_unlock(), so console_trylock() can set `console_may_schedule' to 1 for such processes. For !CONFIG_PREEMPT_COUNT kernels, however, console_trylock() always sets `console_may_schedule' to 0. It's possible to drop explicit preempt_disable()/preempt_enable() in vprintk_emit(), because console_unlock() and console_trylock() are now smart enough: a) console_unlock() does not cond_resched() when it's unsafe (console_trylock() takes care of that) b) console_unlock() does can_use_console() check. Signed-off-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Reviewed-by:
Petr Mladek <pmladek@suse.com> Cc: Jan Kara <jack@suse.com> Cc: Tejun Heo <tj@kernel.org> Cc: Kyle McMartin <kyle@kernel.org> Cc: Dave Jones <davej@codemonkey.org.uk> Cc: Calvin Owens <calvinowens@fb.com> Signed-off-by:
-
Thierry Reding authored
BugLink: http://bugs.launchpad.net/bugs/1560395 Provide subsystem-level suspend and resume helpers that can be used to implement suspend/resume on atomic mode-setting enabled drivers. v2: simplify locking, enhance kerneldoc comments v3: pass lock acquisition context by parameter, improve kerneldoc v4: - remove redundant code (already provided by atomic helpers) (Maarten Lankhorst) - move backoff dance from drm_modeset_lock_all_ctx() into suspend helper (Daniel Vetter) v5: handle potential EDEADLK from drm_atomic_helper_duplicate_state() and drm_atomic_helper_disable_all() (Daniel Vetter) Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449075005-13937-2-git-send-email-thierry.reding@gmail.comSigned-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 14942760) Signed-off-by:
Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by:
-
Maarten Lankhorst authored
BugLink: http://bugs.launchpad.net/bugs/1560395 This is similar to the other drm_for_each_*_mask functions. Changes since v1: - Use for_each_if Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
-
Rafael J. Wysocki authored
BugLink: http://bugs.launchpad.net/bugs/1560395 Introduce a new runtime PM function, pm_runtime_get_if_in_use(), that will increment the device's runtime PM usage counter and return 1 if its status is RPM_ACTIVE and its usage counter is greater than 0 at the same time (0 will be returned otherwise). This is useful for things that should only be done if the device is active (from the runtime PM perspective) and used by somebody (as indicated by the usage counter) already and they are not worth bothering otherwise. Requested-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit a436b6a1) Signed-off-by:
-
Timo Aaltonen authored
BugLink: http://bugs.launchpad.net/bugs/1560395Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1541585 Starting with Windows 2012 R2, message inteerupts can be delivered on any VCPU in the guest. Support this functionality. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit d81274aa) Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1541585 This reverts commit 6e97c2369f18d020c1384bf0716aec6009e8128a.
-
Alex Ng authored
BugLink: http://bugs.launchpad.net/bugs/1541585 If util transport fails to initialize for any reason, the list of transport handlers may become corrupted due to freeing the transport handler without removing it from the list. Fix this by cleaning it up from the list. Signed-off-by:
Alex Ng <alexng@microsoft.com> Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1541585 Pass the channel information to the util drivers that need to defer reading the channel while they are processing a request. This would address the following issue reported by Vitaly: Commit 3cace4a6 ("Drivers: hv: utils: run polling callback always in interrupt context") removed direct *_transaction.state = HVUTIL_READY assignments from *_handle_handshake() functions introducing the following race: if a userspace daemon connects before we get first non-negotiation request from the server hv_poll_channel() won't set transaction state to HVUTIL_READY as (!channel) condition will fail, we set it to non-NULL on the first real request from the server. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1541585 Message header is modified by the hypervisor and we read it in a loop, we need to prevent compilers from optimizing accesses. There are no such optimizations at this moment, this is just a future proof. Suggested-by:
Radim Krcmar <rkrcmar@redhat.com> Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1541585 We have 3 functions dealing with messages and they all implement the same logic to finalize reads, move it to vmbus_signal_eom(). Suggested-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1541585 wait_for_completion() may sleep, it enables interrupts and this is something we really want to avoid on crashes because interrupt handlers can cause other crashes. Switch to the recently introduced vmbus_wait_for_unload() doing busy wait instead. Reported-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1541585 We must handle HVMSG_TIMER_EXPIRED messages in the interrupt context and we offload all the rest to vmbus_on_msg_dpc() tasklet. This functions loops to see if there are new messages pending. In case we'll ever see HVMSG_TIMER_EXPIRED message there we're going to lose it as we can't handle it from there. Avoid looping in vmbus_on_msg_dpc(), we're OK with handling one message per interrupt. Signed-off-by:
-
Andrey Smetanin authored
BugLink: http://bugs.launchpad.net/bugs/1541585 VMBus hypercall codes inside Hyper-V UAPI header will be used by QEMU to implement VMBus host devices support. Signed-off-by:
Andrey Smetanin <asmetanin@virtuozzo.com> Acked-by:
Roman Kagan <rkagan@virtuozzo.com> CC: Gleb Natapov <gleb@kernel.org> CC: Paolo Bonzini <pbonzini@redhat.com> CC: Joerg Roedel <joro@8bytes.org> CC: "K. Y. Srinivasan" <kys@microsoft.com> CC: Haiyang Zhang <haiyangz@microsoft.com> CC: Roman Kagan <rkagan@virtuozzo.com> CC: Denis V. Lunev <den@openvz.org> CC: qemu-devel@nongnu.org [Do not rename the constant at the same time as moving it, as that would cause semantic conflicts with the Hyper-V tree. - Paolo] Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> (back ported from commit 18f09861) Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1541585 On the channel send side, many of the VMBUS device drivers explicity serialize access to the outgoing ring buffer. Give more control to the VMBUS device drivers in terms how to serialize accesss to the outgoing ring buffer. The default behavior will be to aquire the ring lock to preserve the current behavior. Signed-off-by:
-
