Now that we know exactly which page sizes our caller wants to use in the
given domain, we can restrict higher-order allocation attempts to just
those sizes, if any, and avoid wasting any time or effort on other sizes
which offer no benefit. In the same vein, this also lets us accommodate
a minimum order greater than 0 for special cases.
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Acked-by: NWill Deacon <will.deacon@arm.com>
Tested-by: NYong Wu <yong.wu@mediatek.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

Many IOMMUs support multiple page table formats, meaning that any given
domain may only support a subset of the hardware page sizes presented in
iommu_ops->pgsize_bitmap. There are also certain use-cases where the
creator of a domain may want to control which page sizes are used, for
example to force the use of hugepage mappings to reduce pagetable walk
depth.

To this end, add a per-domain pgsize_bitmap to represent the subset of
page sizes actually in use, to make it possible for domains with
different requirements to coexist.
Signed-off-by: NWill Deacon <will.deacon@arm.com>
[rm: hijacked and rebased original patch with new commit message]
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Acked-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

As a set of driver-provided callbacks and static data, there is no
compelling reason for struct iommu_ops to be mutable in core code, so
enforce const-ness throughout.
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Acked-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

Stop wasting IOVA space by over-aligning scatterlist segments for a
theoretical worst-case segment boundary mask, and instead take the real
limits into account to merge consecutive segments wherever appropriate,
so our callers can benefit from getting back nicely simplified lists.

This also represents the last piece of functionality wanted by users of
the current arch/arm implementation, thus brings us a small step closer
to converting that over to the common code.
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

Fix problems in uapi definitions reported by Gabriel Laskar: (see
https://lkml.org/lkml/2016/4/5/205 for details)

 - move public header file rio_mport_cdev.h to include/uapi/linux directory
 - change types in data structures passed as IOCTL parameters
 - improve parameter checking in some IOCTL service routines
Signed-off-by: NAlexandre Bounine <alexandre.bounine@idt.com>
Reported-by: NGabriel Laskar <gabriel@lse.epita.fr>
Tested-by: NBarry Wood <barry.wood@idt.com>
Cc: Gabriel Laskar <gabriel@lse.epita.fr>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
Cc: Andre van Herk <andre.van.herk@prodrive-technologies.com>
Cc: Barry Wood <barry.wood@idt.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

iSER currently has a couple places that set max_sectors in either the host
template or SCSI host, and all of them get it wrong.

This patch instead uses a single assignment that (hopefully) gets it right:
the max_sectors value must be derived from the number of segments in the
FR or FMR structure, but actually be one lower than the page size multiplied
by the number of sectors, as it has to handle the case of non-aligned I/O.

Without this I get trivial to reproduce hangs when running xfstests
(on XFS) over iSER to Linux targets.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NMax Gurtovoy <maxg@mellanox.com>
Acked-by: NSagi Grimberg <sagi@grimberg.me>
Signed-off-by: NDoug Ledford <dledford@redhat.com>

Just checking ifdef CONFIG_USB is not enough, if the USB is compiled
as module. The same applies to PCI.

Tested with the following .config alternatives:

CONFIG_USB=m
CONFIG_MEDIA_CONTROLLER=y
CONFIG_MEDIA_SUPPORT=m
CONFIG_VIDEO_AU0828=m

CONFIG_USB=m
CONFIG_MEDIA_CONTROLLER=y
CONFIG_MEDIA_SUPPORT=y
CONFIG_VIDEO_AU0828=m

CONFIG_USB=y
CONFIG_MEDIA_CONTROLLER=y
CONFIG_MEDIA_SUPPORT=y
CONFIG_VIDEO_AU0828=m

CONFIG_USB=y
CONFIG_MEDIA_CONTROLLER=y
CONFIG_MEDIA_SUPPORT=y
CONFIG_VIDEO_AU0828=y
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

If of_node is set before calling platform_device_add, the driver core
will try to use of: modalias matching, which fails because the device
tree nodes don't have a compatible property set. This patch fixes
imx-ipuv3-crtc module autoloading by setting the of_node property only
after the platform modalias is set.

Fixes: 304e6be6 ("gpu: ipu-v3: Assign of_node of child platform devices to corresponding ports")
Reported-by: NDennis Gilmore <dennis@ausil.us>
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Tested-By: NDennis Gilmore <dennis@ausil.us>
Cc: stable@vger.kernel.org # 4.4+
Signed-off-by: NDave Airlie <airlied@redhat.com>

Regulators are optional for devices using OPPs and the OPP core
shouldn't be printing any errors for such missing regulators.

It was fine before the commit 0c717d0f, but that failed to update
this part of the code to remove an 'always true' check and an extra
unwanted print message.

Fix that now.

Fixes: 0c717d0f (PM / OPP: Initialize regulator pointer to an error value)
Reported-by: NMarc Gonzalez <marc_gonzalez@sigmadesigns.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPICA commit 7a3bd2d962f221809f25ddb826c9e551b916eb25

Set the mutex owner thread ID.
Original patch from: Prarit Bhargava <prarit@redhat.com>

Link: https://bugzilla.kernel.org/show_bug.cgi?id=115121
Link: https://github.com/acpica/acpica/commit/7a3bd2d9Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Tested-by: Andy Lutomirski <luto@kernel.org> # On a Dell XPS 13 9350
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The copying of ring data was wrong for two cases: For a full ring
nothing got copied at all (as in that case the canonicalized producer
and consumer indexes are identical). And in case one or both of the
canonicalized (after the resize) indexes would point into the second
half of the buffer, the copied data ended up in the wrong (free) part
of the new buffer. In both cases uninitialized data would get passed
back to the caller.

Fix this by simply copying the old ring contents twice: Once to the
low half of the new buffer, and a second time to the high half.

This addresses the inability to boot a HVM guest with 64 or more
vCPUs.  This regression was caused by 86200154 (xen/evtchn:
dynamically grow pending event channel ring).
Reported-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Cc: <stable@vger.kernel.org> # 4.4+
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>

After commit 8fa520af "intel_pstate: Remove freq calculation from
intel_pstate_calc_busy()" intel_pstate_get() calls get_avg_frequency()
to compute the average frequency, which is problematic for two reasons.

First, intel_pstate_get() may be invoked before the driver reads the
CPU feedback registers for the first time and if that happens,
get_avg_frequency() will attempt to divide by zero.

Second, the get_avg_frequency() call in intel_pstate_get() is racy
with respect to intel_pstate_sample() and it may end up returning
completely meaningless values for this reason.

Moreover, after commit 7349ec04 "intel_pstate: Move
intel_pstate_calc_busy() into get_target_pstate_use_performance()"
sample.core_pct_busy is never computed on Atom, but it is used in
intel_pstate_adjust_busy_pstate() in that case too.

To address those problems notice that if sample.core_pct_busy
was used in the average frequency computation carried out by
get_avg_frequency(), both the divide by zero problem and the
race with respect to intel_pstate_sample() would be avoided.

Accordingly, move the invocation of intel_pstate_calc_busy() from
get_target_pstate_use_performance() to intel_pstate_update_util(),
which also will take care of the uninitialized sample.core_pct_busy
on Atom, and modify get_avg_frequency() to use sample.core_pct_busy
as per the above.
Reported-by: Nkernel test robot <ying.huang@linux.intel.com>
Link: http://marc.info/?l=linux-kernel&m=146226437623173&w=4
Fixes: 8fa520af "intel_pstate: Remove freq calculation from intel_pstate_calc_busy()"
Fixes: 7349ec04 "intel_pstate: Move intel_pstate_calc_busy() into get_target_pstate_use_performance()"
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

When using ACPI, id is NULL and the current code automatically
defaults name to NULL and chip id to 0. We should instead use
the data provided in the ACPI device table.

Fixes: c816d9e7 ("iio: imu: mpu6050: fix possible NULL dereferences")
Signed-off-by: NDaniel Baluta <daniel.baluta@intel.com>
Reviewed-By: NMatt Ranostay <matt.ranostay@intel.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

Fix possible null dereferencing of i2c and spi driver data.
Signed-off-by: NMatt Ranostay <matt.ranostay@intel.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

The current sequence makes us register for a network device prior to
registering and probing the MDIO bus which could lead to some unwanted
consequences, like a thread of execution calling into ndo_open before
register_netdev() returns, while the MDIO bus is not ready yet.

Rework the sequence to register for the MDIO bus, and therefore attach
to a PHY prior to calling register_netdev(), which implies reworking the
error path a bit.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Since commit 3b9d6da6 ("cpu/hotplug: Fix rollback during error-out
in __cpu_disable()") it is ensured that callbacks of CPU_ONLINE and
CPU_DOWN_PREPARE are processed on the hotplugged CPU. Due to this SMP
function calls are no longer required.

Replace smp_call_function_single() with a direct call to
mvneta_percpu_enable() or mvneta_percpu_disable(). The functions do
not require to be called with interrupts disabled, therefore the
smp_call_function_single() calling convention is not preserved.

Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: netdev@vger.kernel.org
Signed-off-by: NAnna-Maria Gleixner <anna-maria@linutronix.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Now mdiobus_scan() returns ERR_PTR(-ENODEV) instead of NULL if the PHY
device ID was read as all ones. As this was not  an error before, this
value  should be filtered out now in this driver.

Fixes: b74766a0 ("phylib: don't return NULL from get_phy_device()")
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Since mdiobus_scan() returns either an error code or NULL on error, the
driver should check  for both,  not only for NULL, otherwise a crash is
imminent...
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

hw doesn't like a 0 value.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

hw doesn't like a 0 value.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The vxlan add/delete port NDOs are called under rcu lock.
The current mlx5e implementation can potentially block in these
calls, which is not allowed.  Move to using the mlx5e workqueue
to handle these NDOs.

Fixes: b3f63c3d ('net/mlx5e: Add netdev support for VXLAN tunneling')
Signed-off-by: NMatthew Finlay <matt@mellanox.com>
Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Implement a mlx5e workqueue to handle all mlx5e specific tasks.  Move
all tasks currently using the system workqueue to the new workqueue.
This is in preparation for vxlan using the mlx5e workqueue in order to
schedule port add/remove operations.
Signed-off-by: NMatthew Finlay <matt@mellanox.com>
Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When MLX5_EN=y MLX5_CORE=y and VXLAN=m there is a linker error for
vxlan_get_rx_port() due to the fact that VXLAN is a module. Change Kconfig
to select VXLAN when MLX5_CORE=y. When MLX5_CORE=m there is no dependency
on the value of VXLAN.

Fixes: b3f63c3d ('net/mlx5e: Add netdev support for VXLAN tunneling')
Signed-off-by: NMatthew Finlay <matt@mellanox.com>
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When freeing UAR the driver tries to unmap uar->map and uar->bf_map
which are mutually exclusive thus always unmapping a NULL pointer.
Make sure we only call iounmap() once, for the actual mapping.

Fixes: 0ba42241 ('net/mlx5: Fix global UAR mapping')
Signed-off-by: NGal Pressman <galp@mellanox.com>
Reported-by: NDoron Tsur <doront@mellanox.com>
Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

According MMU-500r2 TRM, section 3.7.1 Auxiliary Control registers,
You can modify ACTLR only when the ACR.CACHE_LOCK bit is 0.

So before clearing ARM_MMU500_ACTLR_CPRE of each context bank,
need clear CACHE_LOCK bit of ACR register first.

Since CACHE_LOCK bit is only present in MMU-500r2 onwards,
need to check the major number of IDR7.
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NPeng Fan <van.freenix@gmail.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

The 64KB Translation Granule Supplement to the SMMUv1 architecture
allows an SMMUv1 implementation to support 64KB pages for stage 2
translations, using a constrained VMSAv8 descriptor format limited
to 40-bit addresses. Now that we can freely mix and match context
formats, we can actually handle having 4KB pages via an AArch32
context but 64KB pages via an AArch64 context, so plumb it in.

It is assumed that any implementations will have hardware capabilities
matching the format constraints, thus obviating the need for excessive
sanity-checking; this is the case for MMU-401, the only ARM Ltd.
implementation.

CC: Eric Auger <eric.auger@linaro.org>
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

The way the driver currently forces an AArch32 or AArch64 context format
based on the kernel config and SMMU architecture version is suboptimal,
in that it makes it very hard to support oddball mix-and-match cases
like the SMMUv1 64KB supplement, or situations where the reduced table
depth of an AArch32 short descriptor context may be desirable under an
AArch64 kernel. It also only happens to work on current implementations
which do support all the relevant formats.

Introduce an explicit notion of context format, so we can manage that
independently and get rid of the inflexible #ifdeffery.
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

With {read,write}q_relaxed now able to fall back to the common
nonatomic-hi-lo helper, make use of that so that we don't have to
open-code our own. In the process, also convert the other remaining
split accesses, and repurpose the custom accessor to smooth out the
couple of troublesome instances where we really want to avoid
nonatomic writes (and a 64-bit access is unnecessary in the 32-bit
context formats we would use on a 32-bit CPU).

This paves the way for getting rid of some of the assumptions currently
baked into the driver which make it really awkward to use 32-bit context
formats with SMMUv2 under a 64-bit kernel.
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

MMU-500 erratum #841119 is tickled by a particular set of circumstances
interacting with the next-page prefetcher. Since said prefetcher is
quite dumb and actually detrimental to performance in some cases (by
causing unwanted TLB evictions for non-sequential access patterns), we
lose very little by turning it off, and what we gain is a guarantee that
the erratum is never hit.

As a bonus, the same workaround will also prevent erratum #826419 once
v7 short descriptor support is implemented.

CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Will Deacon <will.deacon@arm.com>
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

With a framework for implementation-specific funtionality in place, the
currently-FDT-dependent ThunderX workaround gets to be the first user.
Acked-by: NTirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

As the inevitable reality of implementation-specific errata workarounds
begin to accrue alongside our integration quirk handling, it's about
time the driver had a decent way of keeping track. Extend the per-SMMU
data so we can identify specific implementations in an efficient and
firmware-agnostic manner.
Acked-by: NTirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

Due to erratum #27704, the CN88xx SMMUv2 implementation supports only
shared ASID and VMID numberspaces.

This patch ensures that ASID and VMIDs are unique across all SMMU
instances on affected Cavium systems.
Signed-off-by: NTirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
Signed-off-by: NAkula Geethasowjanya <Geethasowjanya.Akula@caviumnetworks.com>
[will: commit message, comments and formatting]
Signed-off-by: NWill Deacon <will.deacon@arm.com>

This patch adds support for 16-bit VMIDs on implementations of SMMUv2
that support it.
Signed-off-by: NTirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
[will: commit messsage and comments]
Signed-off-by: NWill Deacon <will.deacon@arm.com>

Without this there was a double free of the metadata,
which ended up freeing the fd table for me here, and taking
out the machine more often than not.

I reproduced with X.org + modesetting DDX + latest llvm/mesa,
also required using dri3.

Cc: stable@vger.kernel.org
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Commit 7e129783 ("HID: wacom: break out wacom_intuos_get_tool_type") by accident
removed stylus_in_proximity flag for Intuos series while shuffling the code
around.

Fix that by reintroducing that flag setting in wacom_intuos_inout(), where
it originally was.

Fixes: 7e129783 ("HID: wacom: break out wacom_intuos_get_tool_type")
Signed-off-by: NPing Cheng <pingc@wacom.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When transportation of the command completes successfully, it indicates
that the 'status' result is valid.  Fix the missed checking and
translation of the status field at the end of acpi_nfit_ctl().
Otherwise, we fail to handle reported errors and assume commands
complete successfully.
Reported-by: NLinda Knippers <linda.knippers@hpe.com>
Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

This reverts commit e3345db8, which
broke system resume for a large class of devices.

Devices that after having been reset during resume need to be rebound
due to a missing reset_resume callback, are now left in a suspended
state. This specifically broke resume of common USB-serial devices,
which are now unusable after system suspend (until disconnected and
reconnected) when USB persist is enabled.

During resume, usb_resume_interface will set the needs_binding flag for
such interfaces, but unlike system resume, run-time resume does not
honour it.

Cc: stable <stable@vger.kernel.org>	# 4.5
Signed-off-by: NJohan Hovold <johan@kernel.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch fixes the issue where the mxs_ocotp_read is reading
the ocotp in reg_size steps but decrements the remaining size
by 1. The number of iterations is thus four times higher,
overwriting the area behind the output buffer.

Fixes: c01e9a11 ("nvmem: add driver for ocotp in i.MX23 and i.MX28")
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NStanislav Meduna <stano@meduna.org>
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 0c426c47 ("[media] media: Always
keep a graph walk large enough around") changed
media_device_register_entity() function to take mdev->graph_mutex. This
causes deadlock in driver probe, which calls (indirectly) this function
with ->graph_mutex taken. This patch removes taking ->graph_mutex in
driver probe to avoid deadlock. Other drivers don't take ->graph_mutex
for entity registration, so this change should be safe.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Commit 0c426c47 ("[media] media: Always
keep a graph walk large enough around") changed
media_device_register_entity() function to take mdev->graph_mutex. This
causes deadlock in driver probe, which calls (indirectly) this function
with ->graph_mutex taken. This patch removes taking ->graph_mutex in
driver probe to avoid deadlock. Other drivers don't take ->graph_mutex
for entity registration, so this change should be safe.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Acked-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Tested-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>