This reverts commit 8cb339f1 as it
throws up a bunch of sparse warnings as reported by the kernel test
robot.
Reported-by: Nkernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/202209020044.CX2PfZzM-lkp@intel.com
Fixes: 8cb339f1 ("usb: gadget: udc-xilinx: replace memcpy with memcpy_toio")
Cc: stable@vger.kernel.org
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Piyush Mehta <piyush.mehta@amd.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We have to copy only selected fields from the original resource.
Because a PCI device will be removed immediately after getting
its resources, we may not use any allocated data, hence we may
not copy any pointers.

Consider the following scenario:

  1/ a caller of p2sb_bar() gets the resource;

  2/ the resource has been copied by platform_device_add_data()
     in order to create a platform device;

  3/ the platform device creation will call for the device driver's
     ->probe() as soon as a match found;

  4/ the ->probe() takes given resources (see 2/) and tries to
     access one of its field, i.e. 'name', in the
     __devm_ioremap_resource() to create a pretty looking output;

  5/ but the 'name' is a dangling pointer because p2sb_bar()
     removed a PCI device, which 'name' had been copied to
     the caller's memory.

  6/ UAF (Use-After-Free) as a result.

Kudos to Mika for the initial analisys of the issue.

Fixes: 9745fb07 ("platform/x86/intel: Add Primary to Sideband (P2SB) bridge support")
Reported-by: Nkernel test robot <oliver.sang@intel.com>
Suggested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/linux-i2c/YvPCbnKqDiL2XEKp@xsang-OptiPlex-9020/
Link: https://lore.kernel.org/linux-i2c/YtjAswDKfiuDfWYs@xsang-OptiPlex-9020/Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220901113406.65876-1-andriy.shevchenko@linux.intel.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Fix for TUF laptops returning with an -ENOSPC on calling
asus_wmi_evaluate_method_buf() when fetching default curves. The TUF method
requires at least 32 bytes space.

This also moves and changes the pr_debug() in fan_curve_check_present() to
pr_warn() in fan_curve_get_factory_default() so that there is at least some
indication in logs of why it fails.
Signed-off-by: NLuke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20220828074638.5473-1-luke@ljones.devReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

In the case of firmware-upload, an instance of struct fw_upload is
allocated in firmware_upload_register(). This data needs to be freed
in fw_dev_release(). Create a new fw_upload_free() function in
sysfs_upload.c to handle the firmware-upload specific memory frees
and incorporate the missing kfree call for the fw_upload structure.

Fixes: 97730bbb ("firmware_loader: Add firmware-upload support")
Cc: stable <stable@kernel.org>
Signed-off-by: NRuss Weight <russell.h.weight@intel.com>
Link: https://lore.kernel.org/r/20220831002518.465274-1-russell.h.weight@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In the following code within firmware_upload_unregister(), the call to
device_unregister() could result in the dev_release function freeing the
fw_upload_priv structure before it is dereferenced for the call to
module_put(). This bug was found by the kernel test robot using
CONFIG_KASAN while running the firmware selftests.

  device_unregister(&fw_sysfs->dev);
  module_put(fw_upload_priv->module);

The problem is fixed by copying fw_upload_priv->module to a local variable
for use when calling device_unregister().

Fixes: 97730bbb ("firmware_loader: Add firmware-upload support")
Cc: stable <stable@kernel.org>
Reported-by: Nkernel test robot <oliver.sang@intel.com>
Reviewed-by: NMatthew Gerlach <matthew.gerlach@linux.intel.com>
Signed-off-by: NRuss Weight <russell.h.weight@intel.com>
Link: https://lore.kernel.org/r/20220829174557.437047-1-russell.h.weight@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Architectures which do not have cacheinfo such as ARM 32-bit would spit
out the following during boot:

 Early cacheinfo failed, ret = -2

Treat -ENOENT specifically to silence this error since it means that the
platform does not support reporting its cache information.

Fixes: 3fcbf1c7 ("arch_topology: Fix cache attributes detection in the CPU hotplug path")
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Tested-by: NMichael Walle <michael@walle.cc>
Reviewed-by: NSudeep Holla <sudeep.holla@arm.com>
Reviewed-by: NConor Dooley <conor.dooley@microchip.com>
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20220805230736.1562801-1-f.fainelli@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Syzbot reported a couple issues introduced by commit 44e602b4
("binder_alloc: add missing mmap_lock calls when using the VMA"), in
which we attempt to acquire the mmap_lock when alloc->vma_vm_mm has not
been initialized yet.

This can happen if a binder_proc receives a transaction without having
previously called mmap() to setup the binder_proc->alloc space in [1].
Also, a similar issue occurs via binder_alloc_print_pages() when we try
to dump the debugfs binder stats file in [2].

Sample of syzbot's crash report:
  ==================================================================
  KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f]
  CPU: 0 PID: 3755 Comm: syz-executor229 Not tainted 6.0.0-rc1-next-20220819-syzkaller #0
  syz-executor229[3755] cmdline: ./syz-executor2294415195
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
  RIP: 0010:__lock_acquire+0xd83/0x56d0 kernel/locking/lockdep.c:4923
  [...]
  Call Trace:
   <TASK>
   lock_acquire kernel/locking/lockdep.c:5666 [inline]
   lock_acquire+0x1ab/0x570 kernel/locking/lockdep.c:5631
   down_read+0x98/0x450 kernel/locking/rwsem.c:1499
   mmap_read_lock include/linux/mmap_lock.h:117 [inline]
   binder_alloc_new_buf_locked drivers/android/binder_alloc.c:405 [inline]
   binder_alloc_new_buf+0xa5/0x19e0 drivers/android/binder_alloc.c:593
   binder_transaction+0x242e/0x9a80 drivers/android/binder.c:3199
   binder_thread_write+0x664/0x3220 drivers/android/binder.c:3986
   binder_ioctl_write_read drivers/android/binder.c:5036 [inline]
   binder_ioctl+0x3470/0x6d00 drivers/android/binder.c:5323
   vfs_ioctl fs/ioctl.c:51 [inline]
   __do_sys_ioctl fs/ioctl.c:870 [inline]
   __se_sys_ioctl fs/ioctl.c:856 [inline]
   __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856
   do_syscall_x64 arch/x86/entry/common.c:50 [inline]
   do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
   entry_SYSCALL_64_after_hwframe+0x63/0xcd
   [...]
  ==================================================================

Fix these issues by setting up alloc->vma_vm_mm pointer during open()
and caching directly from current->mm. This guarantees we have a valid
reference to take the mmap_lock during scenarios described above.

[1] https://syzkaller.appspot.com/bug?extid=f7dc54e5be28950ac459
[2] https://syzkaller.appspot.com/bug?extid=a75ebe0452711c9e56d9

Fixes: 44e602b4 ("binder_alloc: add missing mmap_lock calls when using the VMA")
Cc: <stable@vger.kernel.org> # v5.15+
Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
Reported-by: syzbot+f7dc54e5be28950ac459@syzkaller.appspotmail.com
Reported-by: syzbot+a75ebe0452711c9e56d9@syzkaller.appspotmail.com
Reviewed-by: NLiam R. Howlett <Liam.Howlett@oracle.com>
Acked-by: NTodd Kjos <tkjos@google.com>
Signed-off-by: NCarlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20220829201254.1814484-2-cmllamas@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The SC8280XP platform uses 14 sessions for the compute DSP so increment
the maximum session count.
Signed-off-by: NJohan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20220829080531.29681-4-johan+linaro@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The probe session-duplication overflow check incremented the session
count also when there were no more available sessions so that memory
beyond the fixed-size slab-allocated session array could be corrupted in
fastrpc_session_alloc() on open().

Fixes: f6f9279f ("misc: fastrpc: Add Qualcomm fastrpc basic driver model")
Cc: stable@vger.kernel.org      # 5.1
Signed-off-by: NJohan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20220829080531.29681-3-johan+linaro@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add the missing sanity check on the probed-session count to avoid
corrupting memory beyond the fixed-size slab-allocated session array
when there are more than FASTRPC_MAX_SESSIONS sessions defined in the
devicetree.

Fixes: f6f9279f ("misc: fastrpc: Add Qualcomm fastrpc basic driver model")
Cc: stable@vger.kernel.org      # 5.1
Signed-off-by: NJohan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20220829080531.29681-2-johan+linaro@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

USB external storage device(0x0b05:1932), use gnome-disk-utility tools
to test usb write  < 30MB/s.
if does not to load module of uas for this device, can increase the
write speed from 20MB/s to >40MB/s.
Suggested-by: NMatthias Kaehlcke <mka@chromium.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NHu Xiaoying <huxiaoying@kylinos.cn>
Link: https://lore.kernel.org/r/20220901045737.3438046-1-huxiaoying@kylinos.cnSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Both __device_attach_driver() and __driver_attach() check the return
code of the bus_type.match() function to see if the device needs to be
added to the deferred probe list. After adding the device to the list,
the logic attempts to bind the device to the driver anyway, as if the
device had matched with the driver, which is not correct.

If __device_attach_driver() detects that the device in question is not
ready to match with a driver on the bus, then it doesn't make sense for
the device to attempt to bind with the current driver or continue
attempting to match with any of the other drivers on the bus. So, update
the logic in __device_attach_driver() to reflect this.

If __driver_attach() detects that a driver tried to match with a device
that is not ready to match yet, then the driver should not attempt to bind
with the device. However, the driver can still attempt to match and bind
with other devices on the bus, as drivers can be bound to multiple
devices. So, update the logic in __driver_attach() to reflect this.

Fixes: 656b8035 ("ARM: 8524/1: driver cohandle -EPROBE_DEFER from bus_type.match()")
Cc: stable@vger.kernel.org
Cc: Saravana Kannan <saravanak@google.com>
Reported-by: NGuenter Roeck <linux@roeck-us.net>
Tested-by: NGuenter Roeck <linux@roeck-us.net>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NSaravana Kannan <saravanak@google.com>
Signed-off-by: NIsaac J. Manjarres <isaacmanjarres@google.com>
Link: https://lore.kernel.org/r/20220817184026.3468620-1-isaacmanjarres@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove 'NULL' check for 'data->hpdev.client' in error flow of
mlxreg_lc_probe(). It cannot be 'NULL' at this point.

Fixes: b4b830a3  ("platform/mellanox: mlxreg-lc: Fix error flow and extend verbosity")
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NVadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20220823201937.46855-5-vadimp@nvidia.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Remove redundant 'NULL' check for of if 'data->notifier'.

Replace 'return err' by 'return 0' in mlxreg_lc_probe().

Fixes: 62f9529b ("platform/mellanox: mlxreg-lc: Add initial support for Nvidia line card devices")
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NVadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20220823201937.46855-4-vadimp@nvidia.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Fix locking issues:
- mlxreg_lc_state_update() takes a lock when set or clear
  "MLXREG_LC_POWERED".
- All the devices can be deleted before MLXREG_LC_POWERED flag is cleared.

To fix it:
- Add lock() / unlock() at the beginning / end of
  mlxreg_lc_event_handler() and remove locking from
  mlxreg_lc_power_on_off() and mlxreg_lc_enable_disable()
- Add locked version of mlxreg_lc_state_update() -
  mlxreg_lc_state_update_locked() for using outside
  mlxreg_lc_event_handler().

(2) Remove redundant NULL check for of if 'data->notifier'.

Fixes: 62f9529b ("platform/mellanox: mlxreg-lc: Add initial support for Nvidia line card devices")
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NVadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20220823201937.46855-3-vadimp@nvidia.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Fix smatch warning:
drivers/platform/mellanox/mlxreg-lc.c:866 mlxreg_lc_probe() warn: passing zero to 'PTR_ERR'
by removing 'err = PTR_ERR(regmap)'.

Fixes: b4b830a3 ("platform/mellanox: mlxreg-lc: Fix error flow and extend verbosity")
Reported-by: Nkernel test robot <lkp@intel.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NVadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20220823201937.46855-2-vadimp@nvidia.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

2 keymap fixes for the Acer Aspire One AOD270 and the same hardware
rebranded as Packard Bell Dot SC:

1. The F2 key is marked with a big '?' symbol on the Packard Bell Dot SC,
this sends WMID_HOTKEY_EVENTs with a scancode of 0x27 add a mapping
for this.

2. Scancode 0x61 is KEY_SWITCHVIDEOMODE. Usually this is a duplicate
input event with the "Video Bus" input device events. But on these devices
the "Video Bus" does not send events for this key. Map 0x61 to KEY_UNKNOWN
instead of using KE_IGNORE so that udev/hwdb can override it on these devs.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220829163544.5288-1-hdegoede@redhat.com

The platform_get_irq() returns negative error codes.  It can't actually
return zero.
Signed-off-by: NYu Zhe <yuzhe@nfschina.com>
Link: https://lore.kernel.org/r/20220825011844.8536-1-yuzhe@nfschina.comSigned-off-by: NWill Deacon <will@kernel.org>

This patch updates device status array range from 11 to 12 as we will
be reading status from device number 0 to device number 11 inclusive.

Without this patch we can potentially access status array out of range
during auto-enumeration.

Fixes: aa1262ca ("soundwire: qcom: Check device status before reading devid")
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20220708104747.8722-1-srinivas.kandagatla@linaro.orgSigned-off-by: NVinod Koul <vkoul@kernel.org>

Restrict the ucode loading check to avoid frontdoor loading error.
Signed-off-by: NChengming Gui <Jack.Gui@amd.com>
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This patch adds logic to compute the MDIO period based on
the i1clk, and thereafter write the MDIO period into the YU
MDIO config register. The i1clk resource from the ACPI table
is used to provide addressing to YU bootrecord PLL registers.
The values in these registers are used to compute MDIO period.
If the i1clk resource is not present in the ACPI table, then
the current default hardcorded value of 430Mhz is used.
The i1clk clock value of 430MHz is only accurate for boards
with BF2 mid bin and main bin SoCs. The BF2 high bin SoCs
have i1clk = 500MHz, but can support a slower MDIO period.

Fixes: f92e1869 ("Add Mellanox BlueField Gigabit Ethernet driver")
Reviewed-by: NAsmaa Mnebhi <asmaa@nvidia.com>
Signed-off-by: NDavid Thompson <davthompson@nvidia.com>
Link: https://lore.kernel.org/r/20220826155916.12491-1-davthompson@nvidia.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

This reverts commit 35b0fac8. Alexander
reports that it causes boot failures on i.MX8M Plus based boards
(specifically imx8mp-tqma8mpql-mba8mpxl.dts).
Reported-by: NAlexander Stein <alexander.stein@ew.tq-group.com>
Cc: Chen-Yu Tsai <wenst@chromium.org>
Fixes: 35b0fac8 ("clk: core: Honor CLK_OPS_PARENT_ENABLE for clk gate ops")
Link: https://lore.kernel.org/r/12115951.O9o76ZdvQC@steina-wSigned-off-by: NStephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20220831175326.2523912-1-sboyd@kernel.org

At least one older CH341 appears to have the RX timer enable bit
inverted so that setting it disables the RX timer and prevents the FIFO
from emptying until it is full.

Only set the RX timer enable bit for devices with version newer than
0x27 (even though this probably affects all pre-0x30 devices).
Reported-by: NJonathan Woithe <jwoithe@just42.net>
Tested-by: NJonathan Woithe <jwoithe@just42.net>
Link: https://lore.kernel.org/r/Ys1iPTfiZRWj2gXs@marvin.atrad.com.au
Fixes: 4e46c410 ("USB: serial: ch341: reinitialize chip on reconfiguration")
Cc: stable@vger.kernel.org      # 4.10
Signed-off-by: NJohan Hovold <johan@kernel.org>

Disable LCR updates for pre-0x30 devices which use a different (unknown)
protocol for line control and where the current register write causes
the next received character to be lost.

Note that updating LCR using the INIT command has no effect on these
devices either.
Reported-by: NJonathan Woithe <jwoithe@just42.net>
Tested-by: NJonathan Woithe <jwoithe@just42.net>
Link: https://lore.kernel.org/r/Ys1iPTfiZRWj2gXs@marvin.atrad.com.au
Fixes: 4e46c410 ("USB: serial: ch341: reinitialize chip on reconfiguration")
Fixes: 55fa15b5 ("USB: serial: ch341: fix baud rate and line-control handling")
Cc: stable@vger.kernel.org      # 4.10
Signed-off-by: NJohan Hovold <johan@kernel.org>

The function neigh_timer_handler() is a timer handler that runs in an
atomic context. When used by rocker, neigh_timer_handler() calls
"kzalloc(.., GFP_KERNEL)" that may sleep. As a result, the sleep in
atomic context bug will happen. One of the processes is shown below:

ofdpa_fib4_add()
 ...
 neigh_add_timer()

(wait a timer)

neigh_timer_handler()
 neigh_release()
  neigh_destroy()
   rocker_port_neigh_destroy()
    rocker_world_port_neigh_destroy()
     ofdpa_port_neigh_destroy()
      ofdpa_port_ipv4_neigh()
       kzalloc(sizeof(.., GFP_KERNEL) //may sleep

This patch changes the gfp_t parameter of kzalloc() from GFP_KERNEL to
GFP_ATOMIC in order to mitigate the bug.

Fixes: 00fc0c51 ("rocker: Change world_ops API and implementation to be switchdev independant")
Signed-off-by: NDuoming Zhou <duoming@zju.edu.cn>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add the device id for Decagon Devices USB Cable Adapter.

Link: https://lore.kernel.org/r/trinity-819f9db2-d3e1-40e9-a669-9c245817c046-1661523546680@msvc-mesg-web108
Cc: stable@vger.kernel.org
Signed-off-by: NJohan Hovold <johan@kernel.org>

This reverts commit 3d5f7094.

The quirk does not work properly, more work is needed to determine what
should be done here.
Reported-by: NOliver Neukum <oneukum@suse.com>
Cc: Jean-Francois Le Fillatre <jflf_kernel@gmx.com>
Cc: stable <stable@kernel.org>
Fixes: 3d5f7094 ("usb: add quirks for Lenovo OneLink+ Dock")
Link: https://lore.kernel.org/r/9a17ea86-079f-510d-e919-01bc53a6d09f@gmx.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Don't just print a warning.  Clean up and return an error as well.

Fixes: c8349639 ("net: lan966x: Add FDMA functionality")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NHoratiu Vultur <horatiu.vultur@microchip.com>
Link: https://lore.kernel.org/r/YwjgDm/SVd5c1tQU@kiliSigned-off-by: NJakub Kicinski <kuba@kernel.org>

When running `ethtool -p` with the old management firmware,
the management firmware resource is not correctly released,
which causes firmware related malfunction: all the access
to management firmware hangs.

It releases the management firmware resource when set id
mode operation is not supported.

Fixes: ccb9bc1d ("nfp: add 'ethtool --identify' support")
Signed-off-by: NGao Xiao <gao.xiao@corigine.com>
Reviewed-by: NLouis Peens <louis.peens@corigine.com>
Signed-off-by: NSimon Horman <simon.horman@corigine.com>
Reviewed-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Link: https://lore.kernel.org/r/20220829101651.633840-1-simon.horman@corigine.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

The same GPIO line can be shared by multiple phys for the coma mode pin.
If that is the case then, all the other phys that share the same line
will failed to be probed because the access to the gpio line is not
non-exclusive.
Fix this by making access to the gpio line to be nonexclusive using flag
GPIOD_FLAGS_BIT_NONEXCLUSIVE. This allows all the other PHYs to be
probed.

Fixes: 738871b0 ("net: phy: micrel: add coma mode GPIO")
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NHoratiu Vultur <horatiu.vultur@microchip.com>
Link: https://lore.kernel.org/r/20220830064055.2340403-1-horatiu.vultur@microchip.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

TCP_FIN_WAIT2 and TCP_LAST_ACK were not handled, the connection is closing
so we can ignore them and avoid printing the "unhandled state"
warning message.

[ 1298.852386] nvmet_tcp: queue 2 unhandled state 5
[ 1298.879112] nvmet_tcp: queue 7 unhandled state 5
[ 1298.884253] nvmet_tcp: queue 8 unhandled state 5
[ 1298.889475] nvmet_tcp: queue 9 unhandled state 5

v2: Do not call nvmet_tcp_schedule_release_queue(), just ignore
the fin_wait2 and last_ack states.
Signed-off-by: NMaurizio Lombardi <mlombard@redhat.com>
Reviewed-by: NSagi Grimberg <sagi@grimberg.me>
Reviewed-by: NChaitanya Kulkarni <kch@nvidia.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

There's a goto missing in nvmet_setup_auth(), causing a kernel oops
when nvme_auth_extract_key() fails.
Reported-by: NTal Lossos <tallossos@gmail.com>
Signed-off-by: NHannes Reinecke <hare@suse.de>
Reviewed-by: NSagi Grimberg <sagi@grimberg.me>
Reviewed-by: NChaitanya Kulkarni <kch@nvidia.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

Lexar NM610 reports bogus eui64 values that appear to be the same across
all drives. Quirk them out so they are not marked as "non globally unique"
duplicates.
Signed-off-by: NShyamin Ayesh <me@shyamin.com>
[patch formatting]
Signed-off-by: NKeith Busch <kbusch@kernel.org>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

Not all the gfx10 variants need to integrate
global tap_delay and per se tap_delay firmwares

Only init tap_delay ucode when it does include in
rlc ucode binary so driver doesn't send a null buffer
to psp for firmware loading
Signed-off-by: NHawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: NJack Gui <Jack.Gui@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
On secondary display hotplug we switch primary
stream from ODM2to1 to ODMBypass mode. Current
logic will trigger disabling front end for this
stream.

[How]
We need to check if prev_odm_pipe is equal to NULL
in order to disable dangling planes in this scenario.
Reviewed-by: NAriel Bernstein <Eric.Bernstein@amd.com>
Acked-by: NBrian Chang <Brian.Chang@amd.com>
Signed-off-by: NVladimir Stempen <vladimir.stempen@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[WHY]
Function wasn't returning false when it had a no stream

[HOW]
Made it return false when it had no stream.
Reviewed-by: NAlvin Lee <Alvin.Lee2@amd.com>
Acked-by: NBrian Chang <Brian.Chang@amd.com>
Signed-off-by: NEthan Wellenreiter <Ethan.Wellenreiter@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why]
Pipes get merged in preparation for SubVP but if they don't get used, and
are in ODM or some other multi pipe config, it would calculate the
voltage level with a viewport of just one pipe from when they were split
resulting in too low of a voltage level.

[How]
Made it so that the viewport and other timing settings get rebuilt and re-
initialized after the pipe merge, before calculating the voltage level so it
would calculate it correctly.
Reviewed-by: NAlvin Lee <Alvin.Lee2@amd.com>
Reviewed-by: NJun Lei <Jun.Lei@amd.com>
Acked-by: NBrian Chang <Brian.Chang@amd.com>
Signed-off-by: NEthan Wellenreiter <Ethan.Wellenreiter@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why&How]
plane and stream variables used for cursor size allocation calculation
were stale from previous iteration. Redo the iteration to find the
correct cursor plane for the calculation.
Reviewed-by: NAlvin Lee <Alvin.Lee2@amd.com>
Acked-by: NBrian Chang <Brian.Chang@amd.com>
Signed-off-by: NAurabindo Pillai <aurabindo.pillai@amd.com>
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

[Why] Devices with CPU XGMI iolink do not support PCIe peer access.
Signed-off-by: NAlex Sierra <alex.sierra@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

To suppress the warning about version mismatch with
the latest 78.54.0 PMFW.
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>