In all call sites of dwc3_send_gadget_ep_cmd() we
already had a valid dep pointer, so instead of
passing dwc and dep->number, which would be used to
fetch the same pointer we already had, just pass dep
directly.

In other words, we're changing:

	struct dwc3_ep *dep = dwc[dep->number];

to just passing struct dwc3_ep *dep as argument.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Instead of using burst size to configure NUMP, we
should be using RxFIFO Size instead. DWC3 is smart
enough to know that it shouldn't burst in case burst
size is 0.
Reported-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

To aid code readability, we're gonna split
__dwc3_gadget_kick_transfer() into its constituent
parts: scatter gather and linear buffers.

That way, it's easier to follow the code and focus
debug effort when one or the other fails.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Instead of returning -EINVAL when someone calls
__dwc3_gadget_wakeup() in speeds > highspeed, let's
return 0. There are no problems for the driver for
calling it in superspeed as we cleanly just return.

This avoids an annoying WARN_ONCE() always
triggering during superspeed enumeration with LPM
enabled.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

When we send an endpoint command, we want that to
complete as soon as possible, so let's remove the
unnecessary udelay(1) call.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

sg_is_last() and list_is_last() will encode the
required information for the driver to make
decisions WRT CHN and LST bits.

While at that, also replace '1' with 'true' for
consistency.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

as it turns out, we don't need the extra 'start_new'
argument as that can be inferred from DWC3_EP_BUSY
flag.

Because of that, we can simplify
__dwc3_gadget_kick_transfer() by quite a bit, even
allowing us to prepare more TRBs unconditionally.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

If we're updating transfers, we can also prepare as
many TRBs as we can fit in the ring. Let's start
doing that.

This patch 'solves' a limitation of how many TRBs we
can prepare when we're getting close the end of the
ring. Instead driver to prepare only up to end of
the ring, we check if we have space to wrap around
the ring properly.

Note that this only happens when our enqueue and
dequeue pointers are equal (which is the case for
bulk endpoints after an XferComplete event).
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

that macro is unnecessary and just adds pointless
obfuscation. Let's remove it.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Instead of trying hard to stay connected to the
host, it's best (and far easier) to disconnect from
the host already.

Anything relying on KEEP_CONNECT will just have that
ignored, but we don't have proper hibernation
implementation yet, so there are no regressions.

In any case, hibernation is only useful for runtime
PM, not system sleep.

While at that, also remove dwc3.dcfg which has been
rendered unnecessary.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

we will be re-using it for suspend/resume, so
instead of duplicating code, let's just re-factor
the functions so they can be re-used.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The PLX USB2380 is a PCIe version of the NET2280 and behaves more like the
USB338x but without the USB3.0 superspeed support.

This was tested with g_ether, g_serial, g_mass_storage on a Gateworks
Ventana GW2383.

Cc: Justin DeFields <justindefields@gmail.com>
Signed-off-by: NTim Harvey <tharvey@gateworks.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

With a default size of 16kiB and with maximum of 32
buffers, we can transfer up to 512kiB, however Linux
can transfer up to 1MiB in a single mass storage
block transfer to USB3 storage devices.

Because of this, 1MiB block transfers end up being
slower than 512kiB block transfers. Let's increase
maximum number of storage buffers to a ridiculous
amount (256) so that anybody wanting to test maximum
achievable throughput can do so.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

valid range for storage buffers is encoded in
Kconfig already. Instead of checking again, let's
drop fsg_num_buffers_validate() altogether.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

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>

With the introduction of the ISA_BUS_API Kconfig option, ISA-style
drivers may be built for X86_64 architectures. This patch changes the
ISA Kconfig option dependency of the WinSystems EBC-C384 watchdog timer
driver to ISA_BUS_API, thus allowing it to build for X86_64 as it is
expected to.

Cc: Wim Van Sebroeck <wim@iguana.be>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

With the introduction of the ISA_BUS_API Kconfig option, ISA-style
drivers may be built for X86_64 architectures. This patch changes the
ISA Kconfig option dependency of the Apex Embedded Systems STX104 DAC
driver to ISA_BUS_API, thus allowing it to build for X86_64 as it is
expected to.

Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

With the introduction of the ISA_BUS_API Kconfig option, ISA-style
drivers may be built for X86_64 architectures. This patch changes the
ISA Kconfig option dependency of the PC/104 drivers to ISA_BUS_API, thus
allowing them to build for X86_64 as they are expected to.

Cc: Alexandre Courbot <gnurou@gmail.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NWilliam Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
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>

It's annoying to constantly see the same "Not yet implemented" message
over and over with nothing able to be done about it, so rate limit it
for now to keep user's logs "clean".
Reported-by: NLars Täuber <lars.taeuber@web.de>
Tested-by: NLars Täuber <lars.taeuber@web.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit b5e12ec3 ("Staging: rtl8188eu: rtw_efuse: Use
sizeof type *pointer instead of sizeof type.").

This commit is wrong, the rtw_malloc2d helper function takes the size of
the array elements as its 3th argument, whereas sizeof(*eFuseWord)
gives the size of a pointer instead of the size of a u16.

Since sizeof(void *) > sizeof(u16) this has no adverse effects, but it
is still wrong.

Cc: Sandhya Bankar <bankarsandhya512@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 99aded71 ("Staging: drivers: rtl8188eu: use
sizeof(*ptr) instead of sizeof(struct)").

This commit is wrong, as adapt->HalData has a type of "void *", so
now we are allocating a much to small struct, which causes the driver
to overwrite random memory which leads to a non working driver and
various system crashes.

Cc: Jacky Boen <aqiank@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This seems to be required on some X58 chipsets on systems
with more than one IOMMU. QI does not work until it is
enabled on all IOMMUs in the system.
Reported-by: NDheeraj CVR <cvr.dheeraj@gmail.com>
Tested-by: NDheeraj CVR <cvr.dheeraj@gmail.com>
Fixes: 5f0a7f76 ('iommu/vt-d: Make root entry visible for hardware right after allocation')
Cc: stable@vger.kernel.org
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

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>

In the omap gpmc driver it can be noticed that GPMC_CONFIG4_OEEXTRADELAY
is overwritten by the WEEXTRADELAY value from the device tree and
GPMC_CONFIG4_WEEXTRADELAY is not updated by the value from the device
tree.

As a consequence, the memory accesses cannot be configured properly when
the extra delay are needed for OE and WE.

Fix the update of GPMC_CONFIG4_WEEXTRADELAY with the value from the
device tree file and prevents GPMC_CONFIG4_OEXTRADELAY
being overwritten by the WEXTRADELAY value from the device tree.

Cc: stable@vger.kernel.org
Signed-off-by: NOcquidant, Sebastien <sebastienocquidant@eaton.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>

Enabling a component via sysfs (echo 1 > enable_source), would
trigger building a path from the enabled sources to the sink.
If there is an error in the process (e.g, sink not enabled or
the device (CPU corresponding to ETM) is not online), we never report
failure, except for leaving a message in the dmesg.

Do proper error checking for the build path and return the error.

Before:
 $ echo 0 > /sys/devices/system/cpu/cpu2/online
 $ echo 1 > /sys/devices/cs_etm/cpu2/enable_source
 $ echo $?
 0

After:
 $ echo 0 > /sys/devices/system/cpu/cpu2/online
 $ echo 1 > /sys/devices/cs_etm/cpu2/enable_source
 -bash: echo: write error: No such device or address
Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
Acked-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

At the end of a trace collection, we try to clear the entire buffer
and enable the ETR back if it was already enabled. But, we would have
adjusted the drvdata->buf to point to the beginning of the trace data
in the trace buffer @drvdata->vaddr. So, the following code which
clears the buffer is dangerous and can cause crashes, like below :

	memset(drvdata->buf, 0, drvdata->size);

 Unable to handle kernel paging request at virtual address ffffff800a145000
 pgd = ffffffc974726000
 *pgd=00000009f3e91003, *pud=00000009f3e91003, *pmd=0000000000000000
 PREEMPT SMP
 Modules linked in:
 CPU: 4 PID: 1692 Comm: dd Not tainted 4.7.0-rc2+ #1721
 Hardware name: ARM Juno development board (r0) (DT)
 task: ffffffc9734a0080 ti: ffffffc974460000 task.ti: ffffffc974460000
 PC is at __memset+0x1ac/0x200
 LR is at tmc_read_unprepare_etr+0x144/0x1bc
 pc : [<ffffff80083a05ac>] lr : [<ffffff800859c984>] pstate: 200001c5
 ...
 [<ffffff80083a05ac>] __memset+0x1ac/0x200
 [<ffffff800859b2e4>] tmc_release+0x90/0x94
 [<ffffff8008202f58>] __fput+0xa8/0x1ec
 [<ffffff80082030f4>] ____fput+0xc/0x14
 [<ffffff80080c3ef8>] task_work_run+0xb0/0xe4
 [<ffffff8008088bf4>] do_notify_resume+0x64/0x6c
 [<ffffff8008084d5c>] work_pending+0x10/0x14
 Code: 91010108 54ffff4a 8b040108 cb050042 (d50b7428)

Since we clear the buffer anyway in the following call to
tmc_etr_enable_hw(), remove the erroneous memset().

Fixes: commit de546197 ("coresight: tmc: allocating memory when needed")
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

At the end of the trace capture, we free the allocated memory,
resetting the drvdata->buf to NULL, to indicate that trace data
was collected and the next trace session should allocate the
memory in tmc_enable_etr_sink_sysfs.

The tmc_enable_etr_sink_sysfs, we only allocate memory if drvdata->vaddr
is not NULL (which is not performed at the end of previous session).
This can cause, drvdata->vaddr getting assigned NULL and later we do
memset() which causes a crash as below :

Unable to handle kernel NULL pointer dereference at virtual
 address  00000000
pgd = ffffffc9747f0000
[00000000] *pgd=00000009f402e003, *pud=00000009f402e003,
 *pmd=0000000000000000
Internal error: Oops: 96000046 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 1592 Comm: bash Not tainted 4.7.0-rc1+ #1712
Hardware name: ARM Juno development board (r0) (DT)
task: ffffffc078fe0080 ti: ffffffc974178000 task.ti: ffffffc974178000
PC is at __memset+0x1ac/0x200
LR is at tmc_enable_etr_sink+0xf8/0x304
pc : [<ffffff80083a002c>] lr : [<ffffff800859be44>] pstate: 400001c5
sp : ffffffc97417bc00
x29: ffffffc97417bc00 x28: ffffffc974178000

Call trace:
Exception stack(0xffffffc97417ba40 to 0xffffffc97417bb60)
ba40: 0000000000000001 ffffffc974a5d098 ffffffc97417bc00 ffffff80083a002c
ba60: ffffffc974a5d118 0000000000000000 0000000000000000 0000000000000000
ba80: 0000000000000001 0000000000000000 ffffff800859bdec 0000000000000040
baa0: ffffff8008b45b58 00000000000001c0 ffffffc97417baf0 ffffff80080eddb4
bac0: 0000000000000003 ffffffc078fe0080 ffffffc078fe0960 ffffffc078fe0940
bae0: 0000000000000000 0000000000000000 00000000007fffc0 0000000000000004
bb00: 0000000000000000 0000000000000040 000000000000003f 0000000000000000
bb20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
bb40: ffffffc078fe0960 0000000000000018 ffffffffffffffff 0008669628000000
[<ffffff80083a002c>] __memset+0x1ac/0x200
[<ffffff8008599814>] coresight_enable_path+0xa8/0x1dc
[<ffffff8008599b10>] coresight_enable+0x88/0x1b8
[<ffffff8008599d88>] enable_source_store+0x3c/0x6c
[<ffffff800845eaf4>] dev_attr_store+0x18/0x28
[<ffffff80082829e8>] sysfs_kf_write+0x54/0x64
[<ffffff8008281c30>] kernfs_fop_write+0x148/0x1d8
[<ffffff8008200128>] __vfs_write+0x28/0x110
[<ffffff8008200e88>] vfs_write+0xa0/0x198
[<ffffff80082021b0>] SyS_write+0x44/0xa0
[<ffffff8008084e70>] el0_svc_naked+0x24/0x28
Code: 91010108 54ffff4a 8b040108 cb050042 (d50b7428)

This patch fixes the issue by clearing the drvdata->vaddr while we free
the allocated buffer at the end of a session, so that we allocate the
memory again.

Cc: mathieu.poirier@linaro.org
Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

_coresight_build_path assumes that all the connections of a csdev
has the child_dev initialised. This may not be true if the particular
component is not supported by the kernel config(e.g TPIU) but is
present in the DT. In which case, building a path can cause a crash like this :

  Unable to handle kernel NULL pointer dereference at virtual address 00000010
  pgd = ffffffc9750dd000
  [00000010] *pgd=00000009f5e90003, *pud=00000009f5e90003, *pmd=0000000000000000
  Internal error: Oops: 96000006 [#1] PREEMPT SMP
  Modules linked in:
  CPU: 4 PID: 1348 Comm: bash Not tainted 4.6.0-next-20160517 #1646
  Hardware name: ARM Juno development board (r0) (DT)
  task: ffffffc97517a280 ti: ffffffc9762c4000 task.ti: ffffffc9762c4000
  PC is at _coresight_build_path+0x18/0xe4
  LR is at _coresight_build_path+0xc0/0xe4
  pc : [<ffffff80083d5130>] lr : [<ffffff80083d51d8>] pstate: 20000145
  sp : ffffffc9762c7ba0

  [<ffffff80083d5130>] _coresight_build_path+0x18/0xe4
  [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4
  [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4
  [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4
  [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4
  [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4
  [<ffffff80083d5cdc>] coresight_build_path+0x40/0x68
  [<ffffff80083d5e14>] coresight_enable+0x74/0x1bc
  [<ffffff80083d60a0>] enable_source_store+0x3c/0x6c
  [<ffffff800830b17c>] dev_attr_store+0x18/0x28
  [<ffffff80081ca9c4>] sysfs_kf_write+0x40/0x50
  [<ffffff80081c9e38>] kernfs_fop_write+0x140/0x1cc
  [<ffffff8008163ec8>] __vfs_write+0x28/0x110
  [<ffffff8008164bf0>] vfs_write+0xa0/0x174
  [<ffffff8008165d18>] SyS_write+0x44/0xa0
  [<ffffff8008084e70>] el0_svc_naked+0x24/0x28

Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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>

For the third time in three years, I'm changing my e-mail at Samsung.
That's bad, as it may stop communications with me for a while.  So, this
time, I'll also add the mchehab@kernel.org e-mail, as it remains stable
since ever.

Cc: stable@vger.kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

rk_iommu_command() takes a struct rk_iommu and iterates over the slave
MMUs, so this is doubly wrong in that we're passing in the wrong pointer
and talking to MMUs that we shouldn't be.

Fixes: cd6438c5 ("iommu/rockchip: Reconstruct to support multi slaves")
Cc: stable@vger.kernel.org
Signed-off-by: NJohn Keeping <john@metanate.com>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

Since d16e0faa (iommu: Allow selecting page sizes per domain) the
iommu core demands the page size to be set per domain, otherwise any
mapping attempts will be dropped. Make sure to set a valid page size
for the etnaviv iommu.
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>

There is a problem in the non-devicetree PMU probing where some
probe functions may get the number of supported events through
smp_call_function_any() using the arm_pmu supported_cpus mask.
But at the time the probe function is called, the supported_cpus
mask is empty so the call fails. This patch makes sure the mask
is set before calling the init function rather than after.
Signed-off-by: NMark Salter <msalter@redhat.com>
Signed-off-by: NJeremy Linton <jeremy.linton@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

If USB cable is connected prior to boot, we don't get any interrupts
so we must manually check the VBUS state and report it during probe.
If we don't do it then USB controller will never know that peripheral
cable was connected till the user unplugs and replugs the cable.

Fixes: b7aad8e2 ("extcon: palmas: Add the support for VBUS detection by using GPIO")
Cc: stable@vger.kernel.org
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This reverts commit 1733a2ad.

There is apparently something amiss with the way the TTM code handles
DMA buffers, which the above commit was attempting to work around for
arm64 systems with non-coherent PCI. Unfortunately, this completely
breaks systems *with* coherent PCI (which appear to be the majority).

Booting a plain arm64 defconfig + CONFIG_DRM + CONFIG_DRM_NOUVEAU on
a machine with a PCI GPU having coherent dma_map_ops (in this case a
7600GT card plugged into an ARM Juno board) results in a fatal crash:

[    2.803438] nouveau 0000:06:00.0: DRM: allocated 1024x768 fb: 0x9000, bo ffffffc976141c00
[    2.897662] Unable to handle kernel NULL pointer dereference at virtual address 000001ac
[    2.897666] pgd = ffffff8008e00000
[    2.897675] [000001ac] *pgd=00000009ffffe003, *pud=00000009ffffe003, *pmd=0000000000000000
[    2.897680] Internal error: Oops: 96000045 [#1] PREEMPT SMP
[    2.897685] Modules linked in:
[    2.897692] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc5+ #543
[    2.897694] Hardware name: ARM Juno development board (r1) (DT)
[    2.897699] task: ffffffc9768a0000 ti: ffffffc9768a8000 task.ti: ffffffc9768a8000
[    2.897711] PC is at __memcpy+0x7c/0x180
[    2.897719] LR is at OUT_RINGp+0x34/0x70
[    2.897724] pc : [<ffffff80083465fc>] lr : [<ffffff800854248c>] pstate: 80000045
[    2.897726] sp : ffffffc9768ab360
[    2.897732] x29: ffffffc9768ab360 x28: 0000000000000001
[    2.897738] x27: ffffffc97624c000 x26: 0000000000000000
[    2.897744] x25: 0000000000000080 x24: 0000000000006c00
[    2.897749] x23: 0000000000000005 x22: ffffffc97624c010
[    2.897755] x21: 0000000000000004 x20: 0000000000000004
[    2.897761] x19: ffffffc9763da000 x18: ffffffc976b2491c
[    2.897766] x17: 0000000000000007 x16: 0000000000000006
[    2.897771] x15: 0000000000000001 x14: 0000000000000001
[    2.897777] x13: 0000000000e31b70 x12: ffffffc9768a0080
[    2.897783] x11: 0000000000000000 x10: fffffffffffffb00
[    2.897788] x9 : 0000000000000000 x8 : 0000000000000000
[    2.897793] x7 : 0000000000000000 x6 : 00000000000001ac
[    2.897799] x5 : 00000000ffffffff x4 : 0000000000000000
[    2.897804] x3 : 0000000000000010 x2 : 0000000000000010
[    2.897810] x1 : ffffffc97624c010 x0 : 00000000000001ac
...
[    2.898494] Call trace:
[    2.898499] Exception stack(0xffffffc9768ab1a0 to 0xffffffc9768ab2c0)
[    2.898506] b1a0: ffffffc9763da000 0000000000000004 ffffffc9768ab360 ffffff80083465fc
[    2.898513] b1c0: ffffffc976801e00 ffffffc9762b8000 ffffffc9768ab1f0 ffffff80080ec158
[    2.898520] b1e0: ffffffc9768ab230 ffffff8008496d04 ffffffc975ce6d80 ffffffc9768ab36e
[    2.898527] b200: ffffffc9768ab36f ffffffc9768ab29d ffffffc9768ab29e ffffffc9768a0000
[    2.898533] b220: ffffffc9768ab250 ffffff80080e70c0 ffffffc9768ab270 ffffff8008496e44
[    2.898540] b240: 00000000000001ac ffffffc97624c010 0000000000000010 0000000000000010
[    2.898546] b260: 0000000000000000 00000000ffffffff 00000000000001ac 0000000000000000
[    2.898552] b280: 0000000000000000 0000000000000000 fffffffffffffb00 0000000000000000
[    2.898558] b2a0: ffffffc9768a0080 0000000000e31b70 0000000000000001 0000000000000001
[    2.898566] [<ffffff80083465fc>] __memcpy+0x7c/0x180
[    2.898574] [<ffffff800853e164>] nv04_fbcon_imageblit+0x1d4/0x2e8
[    2.898582] [<ffffff800853d6d0>] nouveau_fbcon_imageblit+0xd8/0xe0
[    2.898591] [<ffffff80083c4db4>] soft_cursor+0x154/0x1d8
[    2.898598] [<ffffff80083c47b4>] bit_cursor+0x4fc/0x538
[    2.898605] [<ffffff80083c0cfc>] fbcon_cursor+0x134/0x1a8
[    2.898613] [<ffffff800841c280>] hide_cursor+0x38/0xa0
[    2.898620] [<ffffff800841d420>] redraw_screen+0x120/0x228
[    2.898628] [<ffffff80083bf268>] fbcon_prepare_logo+0x370/0x3f8
[    2.898635] [<ffffff80083bf640>] fbcon_init+0x350/0x560
[    2.898641] [<ffffff800841c634>] visual_init+0xac/0x108
[    2.898648] [<ffffff800841df14>] do_bind_con_driver+0x1c4/0x3a8
[    2.898655] [<ffffff800841e4f4>] do_take_over_console+0x174/0x1e8
[    2.898662] [<ffffff80083bf8c4>] do_fbcon_takeover+0x74/0x100
[    2.898669] [<ffffff80083c3e44>] fbcon_event_notify+0x8cc/0x920
[    2.898680] [<ffffff80080d7e38>] notifier_call_chain+0x50/0x90
[    2.898685] [<ffffff80080d8214>] __blocking_notifier_call_chain+0x4c/0x90
[    2.898691] [<ffffff80080d826c>] blocking_notifier_call_chain+0x14/0x20
[    2.898696] [<ffffff80083c5e1c>] fb_notifier_call_chain+0x1c/0x28
[    2.898703] [<ffffff80083c81ac>] register_framebuffer+0x1cc/0x2e0
[    2.898712] [<ffffff800845da80>] drm_fb_helper_initial_config+0x288/0x3e8
[    2.898719] [<ffffff800853da20>] nouveau_fbcon_init+0xe0/0x118
[    2.898727] [<ffffff800852d2f8>] nouveau_drm_load+0x268/0x890
[    2.898734] [<ffffff8008466e24>] drm_dev_register+0xbc/0xc8
[    2.898740] [<ffffff8008468a88>] drm_get_pci_dev+0xa0/0x180
[    2.898747] [<ffffff800852cb28>] nouveau_drm_probe+0x1a0/0x1e0
[    2.898755] [<ffffff80083a32e0>] pci_device_probe+0x98/0x110
[    2.898763] [<ffffff800858e434>] driver_probe_device+0x204/0x2b0
[    2.898770] [<ffffff800858e58c>] __driver_attach+0xac/0xb0
[    2.898777] [<ffffff800858c3e0>] bus_for_each_dev+0x60/0xa0
[    2.898783] [<ffffff800858dbc0>] driver_attach+0x20/0x28
[    2.898789] [<ffffff800858d7b0>] bus_add_driver+0x1d0/0x238
[    2.898796] [<ffffff800858ed50>] driver_register+0x60/0xf8
[    2.898802] [<ffffff80083a20dc>] __pci_register_driver+0x3c/0x48
[    2.898809] [<ffffff8008468eb4>] drm_pci_init+0xf4/0x120
[    2.898818] [<ffffff8008c56fc0>] nouveau_drm_init+0x21c/0x230
[    2.898825] [<ffffff80080829d4>] do_one_initcall+0x8c/0x190
[    2.898832] [<ffffff8008c31af4>] kernel_init_freeable+0x14c/0x1f0
[    2.898839] [<ffffff80088a0c20>] kernel_init+0x10/0x100
[    2.898845] [<ffffff8008085e10>] ret_from_fork+0x10/0x40
[    2.898853] Code: a88120c7 a8c12027 a88120c7 a8c12027 (a88120c7)
[    2.898871] ---[ end trace d5713dcad023ee04 ]---
[    2.898888] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

In a toss-up between the GPU seeing stale data artefacts on some systems
vs. catastrophic kernel crashes on other systems, the latter would seem
to take precedence, so revert this change until the real underlying
problem can be fixed.
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
[acourbot@nvidia.com: port to Nouveau tree, remove bits in lib/]
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

to handle pptable format change on Polaris boards
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Not clearing mst manager's proposed vcpis table for destroyed connectors when the manager is stopped leaves it pointing to unrefernced memory, this causes pagefault when the manager is restarted when plugging back a branch.

Fixes: 91a25e46 ("drm/dp/mst: deallocate payload on port destruction")
Signed-off-by: NAndrey Grodzovsky <Andrey.Grodzovsky@amd.com>
Reviewed-by: NLyude <cpaul@redhat.com>
Cc: stable@vger.kernel.org
Cc: Mykola Lysenko <Mykola.Lysenko@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>