The isa_bus_init function must be called before drivers which utilize
the ISA bus driver are registered. A race condition for initilization
exists if device_initcall is used (the isa_bus_init callback is placed
in the same initcall level as dependent drivers which use module_init).
This patch ensures that isa_bus_init is called first by utilizing
postcore_initcall in favor of device_initcall.

Fixes: a5117ba7 ("[PATCH] Driver model: add ISA bus")
Cc: Rene Herman <rene.herman@keyaccess.nl>
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Several modern devices, such as PC/104 cards, are expected to run on
modern systems via an ISA bus interface. Since ISA is a legacy interface
for most modern architectures, ISA support should remain disabled in
general. Support for ISA-style drivers should be enabled on a per driver
basis.

To allow ISA-style drivers on modern systems, this patch introduces the
ISA_BUS_API and ISA_BUS Kconfig options. The ISA bus driver will now
build conditionally on the ISA_BUS_API Kconfig option, which defaults to
the legacy ISA Kconfig option. The ISA_BUS Kconfig option allows the
ISA_BUS_API Kconfig option to be selected on architectures which do not
enable ISA (e.g. X86_64).

The ISA_BUS Kconfig option is currently only implemented for X86
architectures. Other architectures may have their own ISA_BUS Kconfig
options added as required.
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

dev_pm_opp_get_sharing_cpus() returns 0 even in the case when the OPP
core doesn't know whether or not the table is shared. It works on the
majority of platforms, where the OPP table is never created before
invoking the function and then -ENODEV is returned by it.

But in the case of one platform (Jetson TK1) at least, the situation
is a bit different. The OPP table has been created (somehow) before
dev_pm_opp_get_sharing_cpus() is called and it returns 0. Its caller
treats that as 'the CPUs don't share OPPs' and that leads to degraded
performance.

Fix this by converting 'shared_opp' in struct opp_table to an enum
and making dev_pm_opp_get_sharing_cpus() return -EINVAL in case when
the value of that field is "access unknown", so that the caller can
handle it accordingly (cpufreq-dt considers that as 'all CPUs share
the table', for example).

Fixes: 6f707daa "PM / OPP: Add dev_pm_opp_get_sharing_cpus()"
Reported-and-tested-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
[ rjw : Subject & changelog ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Modules which register drivers via standard path (driver_register) in
parallel can cause a warning:
WARNING: CPU: 2 PID: 3492 at ../fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80
sysfs: cannot create duplicate filename '/module/saa7146/drivers'
Modules linked in: hexium_gemini(+) mxb(+) ...
...
Call Trace:
...
 [<ffffffff812e63a2>] sysfs_warn_dup+0x62/0x80
 [<ffffffff812e6487>] sysfs_create_dir_ns+0x77/0x90
 [<ffffffff8140f2c4>] kobject_add_internal+0xb4/0x340
 [<ffffffff8140f5b8>] kobject_add+0x68/0xb0
 [<ffffffff8140f631>] kobject_create_and_add+0x31/0x70
 [<ffffffff8157a703>] module_add_driver+0xc3/0xd0
 [<ffffffff8155e5d4>] bus_add_driver+0x154/0x280
 [<ffffffff815604c0>] driver_register+0x60/0xe0
 [<ffffffff8145bed0>] __pci_register_driver+0x60/0x70
 [<ffffffffa0273e14>] saa7146_register_extension+0x64/0x90 [saa7146]
 [<ffffffffa0033011>] hexium_init_module+0x11/0x1000 [hexium_gemini]
...

As can be (mostly) seen, driver_register causes this call sequence:
  -> bus_add_driver
    -> module_add_driver
      -> module_create_drivers_dir
The last one creates "drivers" directory in /sys/module/<...>. When
this is done in parallel, the directory is attempted to be created
twice at the same time.

This can be easily reproduced by loading mxb and hexium_gemini in
parallel:
while :; do
  modprobe mxb &
  modprobe hexium_gemini
  wait
  rmmod mxb hexium_gemini saa7146_vv saa7146
done

saa7146 calls pci_register_driver for both mxb and hexium_gemini,
which means /sys/module/saa7146/drivers is to be created for both of
them.

Fix this by a new mutex in module_create_drivers_dir which makes the
test-and-create "drivers" dir atomic.

I inverted the condition and removed 'return' to avoid multiple
unlocks or a goto.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Fixes: fe480a26 (Modules: only add drivers/ direcory if needed)
Cc: v2.6.21+ <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Grygorii Strashko reports:

 The PM runtime will be left disabled for the device if its
 .suspend_late() callback fails and async suspend is not allowed
 for this device. In this case device will not be added in
 dpm_late_early_list and dpm_resume_early() will ignore this
 device, as result PM runtime will be disabled for it forever
 (side effect: after 8 subsequent failures for the same device
 the PM runtime will be reenabled due to disable_depth overflow).

To fix this problem, add devices to dpm_late_early_list regardless
of whether or not device_suspend_late() returns errors for them.

That will ensure failures in there to be handled consistently for
all devices regardless of their async suspend/resume status.
Reported-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Tested-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: All applicable <stable@vger.kernel.org>

Recently, a few issues were noticed in the code where CONFIG_OF wasn't
consistently used for many routines. The core file is big enough now and
ifdef hackery makes it less readable.

Move OF-specific code to another file and compile that only if CONFIG_OF
is enabled.

Compile-tested:
- For ARM (exynos) with CONFIG_OF enabled
- For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately)

No functional changes.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Tested-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.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>

Functions dev_pm_opp_of_{cpumask_,}remove_table removes/frees all the
static OPP entries associated with the device and/or all cpus(in case
of cpumask) that are created from DT.

However the OPP entries are populated reading from the firmware or some
different method using dev_pm_opp_add are marked dynamic and can't be
removed using above functions.

This patch adds non DT/OF versions of dev_pm_opp_{cpumask_,}remove_table
to support the above mentioned usecase.

This is in preparation to make use of the same in scpi-cpufreq.c
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Acked-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>

The new use of dev_pm_opp_set_sharing_cpus resulted in a harmless compiler
warning with CONFIG_CPUMASK_OFFSTACK=y:

drivers/cpufreq/mvebu-cpufreq.c: In function 'armada_xp_pmsu_cpufreq_init':
include/linux/cpumask.h:550:25: error: passing argument 2 of 'dev_pm_opp_set_sharing_cpus' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]

The problem here is that cpumask_var_t gets passed by reference, but
by declaring a 'const cpumask_var_t' argument, only the pointer is
constant, not the actual mask. This is harmless because the function
does not actually modify the mask.

This patch changes the function prototypes for all of the related functions
to pass a 'struct cpumask *' instead of 'cpumask_var_t', matching what
most other such functions do in the kernel. This lets us mark all the
other similar functions as taking a 'const' mask where possible,
and it avoids the warning without any change in object code.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 947bd567 (mvebu: Use dev_pm_opp_set_sharing_cpus() to mark OPP tables as shared)
Acked-by: NPavel Machek <pavel@ucw.cz>
Acked-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>

This reverts commit ded9db38.

Thierry Reding writes:
	This causes a boot regression on at least one board, caused by
	one of the drivers looking at driver data to check whether or
	not the driver has properly loaded. If the code encounters a
	non-NULL pointer it tries to dereference it, but because it's
	already been freed there is no memory backing it and things
	crash.

	I don't think keeping stale pointers around is a good idea. The
	whole point of setting this to NULL in the core is so that probe
	failures result in the same starting conditions no matter what.

	Can we please get this reverted?
Reported-by: NThierry Reding <thierry.reding@gmail.com>
Cc: Yi Zhang <yizhang_hust@163.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The introduction of the ISA_BUS option blocks the compilation of ISA
drivers on non-x86 platforms. The ISA_BUS configuration option should
not be necessary if the X86_32 dependency can be decoupled from the ISA
configuration option. This patch both removes the ISA_BUS configuration
option entirely and removes the X86_32 dependency from the ISA
configuration option.
Acked-by: NIngo Molnar <mingo@kernel.org>
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

the driver_data may be used for sanity check, it fails the
probe() if driver_data is NULL after it is re-triggered.
for example, soc_probe() in sound/soc/soc-core.c
Signed-off-by: NYi Zhang <yizhang_hust@163.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

OPP core allows a platform to mark OPP table as shared, when the
platform isn't using operating-points-v2 bindings.

And, so there should be a non DT way of finding out if the OPP table is
shared or not.

This patch adds dev_pm_opp_get_sharing_cpus(), which first tries to get
OPP sharing information from the opp-table (in case it is already marked
as shared), otherwise it uses the existing DT way of finding sharing
information.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

dev_pm_opp_set_sharing_cpus() isn't supposed to update the cpumask
passed as its parameter, and so it should always have been marked
'const'.

Do it now.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit 32e8d689 (PM / sleep: trace_device_pm_callback coverage in
dpm_prepare/complete) removed all users of this variable but forgot to
remove the variable itself.
Signed-off-by: NThierry Reding <treding@nvidia.com>
[ rjw: Subject ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Since fwnode may hold ERR_PTR(-ENODEV) or it may be NULL,
the fwnode type checks is_of_node(), is_acpi_node() and is
is_pset_node() need to consider it. Using IS_ERR_OR_NULL()
to check it.

Fixes: 0d67e0fa (device property: fix for a case of use-after-free)
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
[ rjw: Subject & changelog ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

As the PM core already have wakeup management during the system PM phase,
it seems reasonable that genpd and its users should be able to rely on
that. Therefore let's remove this from pm_genpd_prepare().
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The PM core increases and decreases the runtime PM usage count in the
system PM prepare phase. This makes some of the pm_runtime_get|put*()
calls in pm_genpd_prepare() redundant, so let's remove them.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

It is entirely possible for of_count_phandle_wit_args to
return a -ve error return value so we need to check for this
otherwise we end up allocating a negative number of clk objects.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

opp core allows OPPs to be explicitly marked as shared from platform
code, in case of operating-point v1 bindings.

Though we do everything fine in that case, we don't set the flag in the
opp-table to indicate that the OPPs are shared. It works fine today as
the flag isn't used anywhere else in the core, but we should be doing
the right thing by marking it set.
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>

Move dev_pm_opp_set_sharing_cpus() towards the end of the file. This
is required for better readability after the next patch is applied,
which adds dev_pm_opp_get_sharing_cpus().
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>

Few of the routines in cpu.c were missing these, add them.
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>

Don't send -EINVAL and propagate what's received from _find_opp_table().
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>

As a part of the ongoing consolidation of genpd, it's become questionable
whether clients actually needs to be able to assign their own set of
->save|restore_state() callbacks. Currently all users copes fine with the
default callbacks, so let's remove the configuration option and stick to
the default ones.

This enables further clarifications of the related code and let's also
rename pm_genpd_default_save|restore_state() into
__genpd_runtime_suspend|resume() to apply the rule of static functionnames
in genpd.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Follow genpd's rule for names of static functions, by renaming
pm_genpd_runtime_suspend|resume() to genpd_runtime_suspend|resume().
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The genpd governor validates the latency constraints to find out whether
it's acceptable to runtime suspend a device. Earlier this validation was
made to know whether it was okay to invoke the ->stop() callback for the
device, hence the governor used the name "stop_ok" for the related
variables.

To clarify the code around this, let's rename these variables from
"stop_ok" to "suspend_ok".
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

As pm_runtime_set_active() may fail because the device's parent isn't
active, we can end up executing the ->runtime_resume() callback for the
device when it isn't allowed.

Fix this by invoking pm_runtime_set_active() before running the callback
and let's also deal with the error code.

Fixes: 37f20416 (PM: Add pm_runtime_suspend|resume_force functions)
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add scatterlist support (dev_coredumpsg) to allow drivers to avoid
vmalloc() like dev_coredumpm(), while also avoiding the module
reference that the latter function requires.

This internally uses dev_coredumpm() with function inside the
devcoredump module, requiring removing the const
(which touches the driver using it.)
Signed-off-by: NAviya Erenfeld <aviya.erenfeld@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Specifically for the case of reads that use the Extended Register
Read Long command, a multi-byte read operation is broken up into
8-byte chunks.  However the call to spmi_ext_register_readl() is
incorrectly passing 'val_size', which if greater than 8 will
always fail.  The argument should instead be 'len'.

Fixes: c9afbb05 ("regmap: spmi: support base and extended register spaces")
Signed-off-by: NJack Pham <jackp@codeaurora.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

Since device_add_property_set() now always takes a copy of
the property_set, and also since the fwnode type is always
hard coded to be FWNODE_PDATA, there is no need for the
drivers to deliver the entire struct property_set. The
function can just create the instance of it on its own and
bind the properties from the drivers to it on the spot.

This renames device_add_property_set() to
device_add_properties(). The function now takes struct
property_entry as its parameter instead of struct
property_set.
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Now wakeirq stops working for device if wakeup option for
this device will be reconfigured through sysfs, like:

echo disabled > /sys/devices/platform/extcon_usb1/power/wakeup
echo enabled > /sys/devices/platform/extcon_usb1/power/wakeup

Once above set of commands is executed the device's wakeup_source
opject will be recreated and dev->power.wakeup->wakeirq field will
contain NULL. As result, device_wakeup_arm_wake_irqs() will not arm
wakeirq for the affected device.

Hece, lets try to fix it in the following way:
  check for dev->wakeirq field when device_wakeup_attach() is called
  and if !NULL re-attach wakeirq to the device
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Otherwise the DT parsing will default to big endian if nothing is
specified.
Reported-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Since we changed to do formatting in the bus we now skip all the format
parsing that the core does for its data marshalling code.  This means
that we skip the DT parsing it does which breaks some systems, we need
to add an explict call in the MMIO code to do this.
Reported-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

internal.h is using dev_name() but doesn't include device.h which
defines it.  Add an explicit include to avoid build problems due to
this.
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Many motherboards utilize a LPC to ISA bridge in order to decode
ISA-style port-mapped I/O addresses. This is particularly true for
embedded motherboards supporting the PC/104 bus (a bus specification
derived from ISA).

These motherboards are now commonly running 64-bit x86 processors. The
X86_32 dependency should be removed from the ISA bus configuration
option in order to support these newer motherboards.

A new config option, CONFIG_ISA_BUS, is introduced to allow for the
compilation of the ISA bus driver independent of the CONFIG_ISA option.
Devices which communicate via ISA-compatible buses can now be supported
independent of the dependencies of the CONFIG_ISA option.
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If max_register is unset, regcache_flat_get_index will return 0 and only
memory for 1 unsigned int will be allocated, resulting in writing out
of bounds.
Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Setting the flag 'cache_bypass' will bypass the cache not the hardware.
Fix this comment here.

Fixes: 0eef6b04 ("regmap: Fix doc comment")
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Currently when selecting value endianness we check the register
endiannes, not the value endianness.
Reported-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Tested-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Use memset_io() for DMA_MEMORY_IO mappings which are mapped as I/O
memory, and regular memset() for DMA_MEMORY_MAP mappings.

This fixes the below alignment fault on arm64 for DMA_MEMORY_IO
mappings, where memset() uses the DC ZVA instruction which is invalid on
device memory.

   Unhandled fault: alignment fault (0x96000061) at 0xffffff8000380000
   Internal error: : 96000061 [#1] PREEMPT SMP
   Modules linked in: hdlcd(+) clk_scpi
   CPU: 4 PID: 1355 Comm: systemd-udevd Not tainted 4.4.0-rc1+ #5
   Hardware name: ARM Juno development board (r0) (DT)
   task: ffffffc9763eee00 ti: ffffffc9758c4000 task.ti: ffffffc9758c4000
   PC is at __efistub_memset+0x1ac/0x200
   LR is at dma_alloc_from_coherent+0xb0/0x120
   pc : [<ffffffc00030ff2c>] lr : [<ffffffc00042a918>] pstate: 400001c5
   sp : ffffffc9758c79a0
   x29: ffffffc9758c79a0 x28: ffffffc000635cd0
   x27: 0000000000000124 x26: ffffffc000119ef4
   x25: 0000000000010000 x24: 0000000000000140
   x23: ffffffc07e9ac3a8 x22: ffffffc9758c7a58
   x21: ffffffc9758c7a68 x20: 0000000000000004
   x19: ffffffc07e9ac380 x18: 0000000000000001
   x17: 0000007fae1bbba8 x16: ffffffc0001b2d1c
   x15: ffffffffffffffff x14: 0ffffffffffffffe
   x13: 0000000000000010 x12: ffffff800837ffff
   x11: ffffff800837ffff x10: 0000000040000000
   x9 : 0000000000000000 x8 : ffffff8000380000
   x7 : 0000000000000000 x6 : 000000000000003f
   x5 : 0000000000000040 x4 : 0000000000000000
   x3 : 0000000000000004 x2 : 000000000000ffc0
   x1 : 0000000000000000 x0 : ffffff8000380000
Signed-off-by: NBrian Starkey <brian.starkey@arm.com>
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When the DMA_MEMORY_MAP flag is used, memory which can be accessed
directly should be returned, so use memremap(..., MEMREMAP_WC) to
provide a writecombine mapping.
Signed-off-by: NBrian Starkey <brian.starkey@arm.com>
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>