On older Apple systems there is currently a PCI quirk in place to block
resume of tunneled PCIe ports until NHI (Thunderbolt controller) is
resumed. This makes sure the PCIe tunnels are re-established before PCI
core notices it.

With device links the same thing can be done without quirks. The driver
core will make sure the supplier (NHI) is resumed before consumers (PCIe
downstream ports).

For this reason switch the Thunderbolt driver to use device links and
remove the PCI quirk.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>

In order for the router and the whole domain to wake up from system
suspend states we need to enable wakes for the connected routers. For
device routers we enable wakes from PCIe and USB 3.x. This allows
devices such as keyboards connected to USB 3.x hub that is tunneled to
wake the system up as expected. For all routers we enabled wake on USB4
for each connected ports. This is used to propagate the wake from router
to another.

Do the same for legacy routers through link controller vendor specific
registers as documented in USB4 spec chapter 13.

While there correct kernel-doc of usb4_switch_set_sleep() -- it does not
enable wakes instead there is a separate function (usb4_switch_set_wake())
that does.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

USB4 spec mandates that the lane 1 should be disabled if lanes are not
bonded. For host-to-host connections (XDomain) we don't support lane
bonding so in order to be compatible with the spec, disable lane 1 when
another host is connected.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

When the port is connected to another host it should be marked as such
in the USB4 port capability. This information is used by the router
during sleep and wakeup.

Also do the same for legacy switches via link controller vendor specific
registers.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Both ends of the link needs to have this set. Otherwise the link is not
re-established properly after sleep. Now since it is possible to have
mixed USB4 and Thunderbolt 1, 2 and 3 devices we need to split the link
configuration functionality to happen per port so we can pick the
correct implementation.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

During testing it was noticed that the link is not properly restored
after the domain exits sleep if the link configured bits are set before
lane bonding is enabled. The USB4 spec does not say in which order these
need to be set but setting link configured afterwards makes the link
restoration work so we do that instead.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Some early stage USB4 devices do not like that any of the enumerating
router config space fields (ROUTER_CS_1 - ROUTER_CS_4) are written after
the initial enumeration for example when entering sleep states. The
default timeout by the USB4 spec is 10 ms which should be fine for the
driver to handle.

For this reason do not change the notification timeout from the default
10 ms for USB4 routers.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

The TMU will be reset after router exits sleep so in order to
re-configure it upon resume make sure the structure is initialized again
based on the current hardware state.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

DP tunnels do not need the same kind of treatment as others because they
are created based on hot-plug events on DP adapter ports, and the
display stack does not need the tunnels to be enabled when resuming from
suspend. Also Tiger Lake Thunderbolt controller sends unplug event on D3
exit so this avoids that as well.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

First generation routers may need the reset command upon resume but it
is not supported by newer generations.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

The function already logs an error if it fails so get rid of the
duplication.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

USB4 spec says that NFC buffers field is not used for protocol adapters,
only for lane adapters so make tb_port_add_nfc_credits() skip non-lane
adapters in order to follow the spec.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

In Tiger Lake the Firmware CM is always enabled (so bit 0 is always set)
but it may be in "pass through" mode which means it requires Software CM
instead. This can be determined by checking bit 31 instead.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

When Software CM is running it should not send any NHI mailbox command
during PM flows. Only force power bit needs to be set and cleared so
change Tiger Lake (well and Ice Lake) nhi_ops to take this into account.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Currently the Ice Lake and Tiger Lake NHI (host controller) LC (link
controller) mailbox command processing checks for the completion of
command every 100 msecs. These controllers are found to complete this in
the order of 1 ms or so. Since this delay is in suspend path, surplus
delay is effectively affecting runtime PM suspend flows.

Optimize this so that we do the wait for 1 ms after reading the mailbox
register. This should make Ice Lake and Tiger Lake runtime suspend take
less time to complete.
Reported-by: NDana Alkattan <dana.alkattan@intel.com>
Signed-off-by: NRajmohan Mani <rajmohan.mani@intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Currently the "Force Power" logic uses 10 retries, each with a delay of
250 ms. Thunderbolt controllers in Ice Lake and Tiger Lake platforms are
found to complete this in the order of 3 ms or so. Since this delay
is in resume path, surplus delay is effectively affecting runtime PM
resume flows.

Decrease the granularity of the delay to 3 ms and increase the number of
retries so we wait maximum of ~1 s which is the recommended timeout.
This should make runtime resume a bit faster.
Reported-by: NDana Alkattan <dana.alkattan@intel.com>
Signed-off-by: NRajmohan Mani <rajmohan.mani@intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Doesn't really matter for an individual driver, but it may
get coppied to lots more. I consider it's a little tidy up.
Signed-off-by: NTian Tao <tiantao6@hisilicon.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Commit ef91bb19 ("kernel.h: Silence sparse warning in
lower_32_bits") caused new warnings to show in the fsldma driver, but
that commit was not to blame: it only exposed some very incorrect code
that tried to take the low 32 bits of an address.

That made no sense for multiple reasons, the most notable one being that
that code was intentionally limited to only 32-bit ppc builds, so "only
low 32 bits of an address" was completely nonsensical.  There were no
high bits to mask off to begin with.

But even more importantly fropm a correctness standpoint, turning the
address into an integer then caused the subsequent address arithmetic to
be completely wrong too, and the "+1" actually incremented the address
by one, rather than by four.

Which again was incorrect, since the code was reading two 32-bit values
and trying to make a 64-bit end result of it all.  Surprisingly, the
iowrite64() did not suffer from the same odd and incorrect model.

This code has never worked, but it's questionable whether anybody cared:
of the two users that actually read the 64-bit value (by way of some C
preprocessor hackery and eventually the 'get_cdar()' inline function),
one of them explicitly ignored the value, and the other one might just
happen to work despite the incorrect value being read.

This patch at least makes it not fail the build any more, and makes the
logic superficially sane.  Whether it makes any difference to the code
_working_ or not shall remain a mystery.
Compile-tested-by: NGuenter Roeck <linux@roeck-us.net>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit e49aa9a9bd22 ("mfd: core: Make a best effort attempt to match
devices with the correct of_nodes") changed the semantics for disabled
devices in mfd_add_device().  Instead of silently ignoring a disabled
child device, an error was returned.  On receipt of the error
mfd_add_devices() the precedes to remove *all* child devices and
returns an all-failed error to the caller, which will inevitably fail
the parent device as well.

This patch reverts back to the old semantics and ignores child devices
which are disabled in Device Tree.

Fixes: e49aa9a9bd22 ("mfd: core: Make a best effort attempt to match devices with the correct of_nodes")
Reported-by: NIcenowy Zheng <icenowy@aosc.io>
Tested-by: NIcenowy Zheng <icenowy@aosc.io>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The PSZ-HA* family of USB disk drives from Sony can't handle the
REPORT OPCODES command when using the UAS protocol.  This patch adds
an appropriate quirks entry.
Reported-and-tested-by: NTill Dörges <doerges@pre-sense.de>
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200826143229.GB400430@rowland.harvard.eduSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 3b5408b9 ("md/raid5: support config stripe_size by sysfs
entry") make stripe_size as a configurable value. It just requires
stripe_size as multiple of 4KB.

In fact, we should make sure stripe_size as power of two. Otherwise,
stripe_shift which is the result of ilog2 can not represent the real
stripe_size. Then, stripe_hash() and stripe_hash_locks_hash() may
get unexpected value.

Fixes: 3b5408b9 ("md/raid5: support config stripe_size by sysfs entry")
Signed-off-by: NYufen Yu <yuyufen@huawei.com>
Signed-off-by: NSong Liu <songliubraving@fb.com>

Fix identation issues.

Fixes: 5e9c85d9 ("[media] dib8096: enhancement")
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>

The GSC registers report temperature in decidegrees celcius so we
need to scale it to represent the hwmon sysfs API of millidegrees.

Cc: stable@vger.kernel.org
Fixes: 3bce5377 ("hwmon: Add Gateworks System Controller support")
Signed-off-by: NTim Harvey <tharvey@gateworks.com>
Link: https://lore.kernel.org/r/1598548824-16898-1-git-send-email-tharvey@gateworks.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

After

  b9cae277 ("EDAC/ghes: Scan the system once on driver init")

and with CONFIG_DEBUG_TEST_DRIVER_REMOVE enabled, ghes_hw.dimms becomes
a NULL pointer after the second ->probe() (aka ghes_edac_register())
which the config option causes to be called.

This happens because the static variable which holds down whether
the system has been scanned already, doesn't get reset in
ghes_edac_unregister(). Then, on the second probe, ghes_scan_system()
doesn't get to enumerate the DIMMs, leading to ghes_hw.dimms remaining
NULL.

Clear the variable and rename it to something more descriptive so that a
second probe succeeds.

 [ bp: Rewrite commit message. ]

Fixes: b9cae277 ("EDAC/ghes: Scan the system once on driver init")
Suggested-by: NBorislav Petkov <bp@suse.de>
Signed-off-by: NShiju Jose <shiju.jose@huawei.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20200827140450.1620-1-shiju.jose@huawei.com

"cpufreq_driver" is guaranteed to be valid here, no need to check it
here.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The build is currently broken, if COMPILE_TEST=y and PPC_PMAC=n:

  linux/drivers/video/fbdev/controlfb.c: In function ‘control_set_hardware’:
  linux/drivers/video/fbdev/controlfb.c:276:2: error: implicit declaration of function ‘btext_update_display’
    276 |  btext_update_display(p->frame_buffer_phys + CTRLFB_OFF,
        |  ^~~~~~~~~~~~~~~~~~~~

Fix it by including btext.h whenever CONFIG_BOOTX_TEXT is enabled.

Fixes: a07a63b0 ("video: fbdev: controlfb: add COMPILE_TEST support")
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
Acked-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://lore.kernel.org/r/20200821104910.3363818-1-mpe@ellerman.id.au

This device does not support UAS properly and a similar entry already
exists in drivers/usb/storage/unusual_uas.h. Without this patch,
storage_probe() defers the handling of this device to UAS, which cannot
handle it either.
Tested-by: NBrice Goglin <brice.goglin@gmail.com>
Fixes: bc3bdb12 ("usb-storage: Disable UAS on JMicron SATA enclosure")
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Signed-off-by: NCyril Roelandt <tipecaml@gmail.com>
Link: https://lore.kernel.org/r/20200825212231.46309-1-tipecaml@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If the function platform_get_irq() failed, the negative value
returned will not be detected here. So fix error handling in
exynos_ohci_probe(). And when get irq failed, the function
platform_get_irq() logs an error message, so remove redundant
message here.

Fixes: 62194244 ("USB: Add Samsung Exynos OHCI diver")
Signed-off-by: NZhang Shengju <zhangshengju@cmss.chinamobile.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NTang Bin <tangbin@cmss.chinamobile.com>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200826144931.1828-1-tangbin@cmss.chinamobile.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Inadvertently the commit b1cd1b65 ("USB: gadget: u_f: add overflow checks
to VLA macros") makes VLA macros to always return 0 due to different scope of
two variables of the same name. Obviously we need to have only one.

Fixes: b1cd1b65 ("USB: gadget: u_f: add overflow checks to VLA macros")
Reported-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Brooke Basile <brookebasile@gmail.com>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20200826192119.56450-1-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The Sound Devices MixPre-D audio card suffers from the same defect
as the Sound Devices USBPre2: an endpoint shared between a normal
audio interface and a vendor-specific interface, in violation of the
USB spec.  Since the USB core now treats duplicated endpoints as bugs
and ignores them, the audio endpoint isn't available and the card
can't be used for audio capture.

Along the same lines as commit bdd1b147 ("USB: quirks: blacklist
duplicate ep on Sound Devices USBPre2"), this patch adds a quirks
entry saying to ignore ep5in for interface 1, leaving it available for
use with standard audio interface 2.
Reported-and-tested-by: NJean-Christophe Barnoud <jcbarnoud@gmail.com>
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Fixes: 3e4f8e21 ("USB: core: fix check for duplicate endpoints")
Link: https://lore.kernel.org/r/20200826194624.GA412633@rowland.harvard.eduSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

On some architectures (like ARM), virt_to_gfn cannot be used for
vmalloc'd memory because of its reliance on virt_to_phys. This patch
introduces a check for vmalloc'd addresses and obtains the PFN using
vmalloc_to_pfn in that case.
Signed-off-by: NSimon Leiner <simon@leiner.me>
Reviewed-by: NStefano Stabellini <sstabellini@kernel.org>
Link: https://lore.kernel.org/r/20200825093153.35500-1-simon@leiner.meSigned-off-by: NJuergen Gross <jgross@suse.com>

XEN data pointer which contains XEN specific information.

handler data is meant for interrupt handlers and not for storing irq chip
specific information as some devices require handler data to store internal
per interrupt information, e.g. pinctrl/GPIO chained interrupt handlers.

This obviously creates a conflict of interests and crashes the machine
because the XEN pointer is overwritten by the driver pointer.

As the XEN data is not handler specific it should be stored in
irqdesc::irq_data::chip_data instead.

A simple sed s/irq_[sg]et_handler_data/irq_[sg]et_chip_data/ cures that.

Cc: stable@vger.kernel.org
Reported-by: NRoman Shaposhnik <roman@zededa.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NRoman Shaposhnik <roman@zededa.com>
Reviewed-by: NJuergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/87lfi2yckt.fsf@nanos.tec.linutronix.deSigned-off-by: NJuergen Gross <jgross@suse.com>

When amdgpu_display_modeset_create_props() fails, state and
state->context should be freed to prevent memleak. It's the
same when amdgpu_dm_audio_init() fails.
Signed-off-by: NDinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Disable runtime pm for navy_flounder temporarily.
Signed-off-by: NJiansong Chen <Jiansong.Chen@amd.com>
Reviewed-by: NTao Zhou <tao.zhou1@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
In dm_dp_aux_transfer() now, we forget to handle AUX_WR fail cases. We
suppose every write wil get done successfully and hence some AUX
commands might not sent out indeed.

[How]
Check if AUX_WR success. If not, retry it.
Signed-off-by: NWayne Lin <Wayne.Lin@amd.com>
Reviewed-by: NHersen Wu <hersenxs.wu@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The values for "se_num" and "sh_num" come from the user in the ioctl.
They can be in the 0-255 range but if they're more than
AMDGPU_GFX_MAX_SE (4) or AMDGPU_GFX_MAX_SH_PER_SE (2) then it results in
an out of bounds read.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

[Why]
DC uses these to raise the voltage as needed for higher dispclk/dppclk
and to ensure that we have enough bandwidth to drive the displays.

There's a bug preventing these from actuially sending messages since
it's checking the actual clock (which is 0) instead of the incoming
clock (which shouldn't be 0) when deciding to send the hardmin.

[How]
Check the clocks != 0 instead of the actual clocks.

Fixes: 9ed9203c ("drm/amd/powerplay: rv dal-pplib interface refactor powerplay part")
Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Switch default gpu reset method to MODE1 for navy_flounder.
Signed-off-by: NJiansong Chen <Jiansong.Chen@amd.com>
Reviewed-by: NTao Zhou <tao.zhou1@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Do the maths in celsius degree. This can fix the issues caused
by the changes below:

drm/amd/pm: correct Vega20 swctf limit setting
drm/amd/pm: correct Vega12 swctf limit setting
drm/amd/pm: correct Vega10 swctf limit setting
Signed-off-by: NEvan Quan <evan.quan@amd.com>
Reviewed-by: NKenneth Feng <kenneth.feng@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

asd is not ready for some ASICs in early stage, and psp->asd_fw is more generic than ASIC name in the check.
Signed-off-by: NTao Zhou <tao.zhou1@amd.com>
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: NJiansong Chen <Jiansong.Chen@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>