The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230405141009.3400693-10-u.kleine-koenig@pengutronix.deSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20230405141009.3400693-9-u.kleine-koenig@pengutronix.deSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230405141009.3400693-8-u.kleine-koenig@pengutronix.deSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230405141009.3400693-7-u.kleine-koenig@pengutronix.deSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230405141009.3400693-6-u.kleine-koenig@pengutronix.deSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230405141009.3400693-5-u.kleine-koenig@pengutronix.deSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230405141009.3400693-4-u.kleine-koenig@pengutronix.deSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20230405141009.3400693-3-u.kleine-koenig@pengutronix.deSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230405141009.3400693-2-u.kleine-koenig@pengutronix.deSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The USS720 parport driver source code is in drivers/usb/misc/, the
corresponding config is defined in drivers/usb/Kconfig. Some digging in the
kernel's history revealed no good reason why it needs to be defined in
USB's top-level Kconfig file, and why the config for the USS720 parport
driver should be the first in the list of USB port drivers, while all other
configs for drivers in drivers/usb/misc are in the USB Miscellaneous driver
configuration file.

Most probably, it was simply considered a bit more special when the USB
Miscellaneous driver configuration file (drivers/usb/misc/Config.in back
then) was initially created, and this config simply survived to remain at
the top-level USB Kconfig file with all further code/Kconfig
transformations and additions later on. Users rarely notice this config
being at this position, as CONFIG_PARPORT (Parallel port support) needs to
be enabled and only few users enable that. Nowadays, this USB_USS720 driver
is probably not that special that it needs to be listed as first item of
the USB port drivers.

Move the configuration of the USS720 parport driver to the top of the USB
Miscellaneous drivers section, as the configurations does not have a lot of
specific ordering USB Miscellaneous drivers. This way, the USS720 parport
driver is moved to the comment "USB Miscellaneous drivers", fitting to the
driver's source code location, but still is at the top of the list for
those few acquainted users of Kconfig UIs that might be looking for the
config that was once at the top of the list of the USB port drivers.

Put this config definition to a more local place. No semantic change.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20230329075125.32352-1-lukas.bulwahn@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

When host sends suspend notification to the device, handle
the suspend callbacks in the function driver. Depending on
the remote wakeup capability the device can either trigger a
remote wakeup or wait for the host initiated resume to resume
data transfer.
Signed-off-by: Elson Roy Serrao <quic_eserrao@quicinc.com>
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/1679694482-16430-7-git-send-email-quic_eserrao@quicinc.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

When host sends function suspend feature selector to the device,
inspect the received packet and trigger function suspend or
function resume accordingly. Inspect the remote wakeup bit and
arm the function for remote wakeup if it is wakeup capable. Also
host queries the function wakeup capability  through a get status
request before sending function resume. Handle such requests in
composite layer.
Signed-off-by: Elson Roy Serrao <quic_eserrao@quicinc.com>
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/1679694482-16430-6-git-send-email-quic_eserrao@quicinc.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB host sends function suspend and function resume notifications to
the interface through SET_FEATURE/CLEAR_FEATURE setup packets.
Add support to handle these packets by delegating the requests to
composite layer. Also add support to handle function wake notification
requests to exit from function suspend state.
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Elson Roy Serrao <quic_eserrao@quicinc.com>
Link: https://lore.kernel.org/r/1679694482-16430-5-git-send-email-quic_eserrao@quicinc.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB3.2 spec section 9.2.5.4 quotes that a function may signal that
it wants to exit from Function Suspend by sending a Function
Wake Notification to the host if it is enabled for function
remote wakeup. Add an api in composite layer that can be used
by the function drivers to support this feature. Also expose
a gadget op so that composite layer can trigger a wakeup request
to the UDC driver.
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Elson Roy Serrao <quic_eserrao@quicinc.com>
Link: https://lore.kernel.org/r/1679694482-16430-4-git-send-email-quic_eserrao@quicinc.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

An usb device can initate a remote wakeup and bring the link out of
suspend as dictated by the DEVICE_REMOTE_WAKEUP feature selector.
Add support to handle this packet and set the remote wakeup capability.

Some hosts may take longer time to initiate the resume signaling after
device triggers a remote wakeup. So add async support to the wakeup API
by enabling link status change events.
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Elson Roy Serrao <quic_eserrao@quicinc.com>
Link: https://lore.kernel.org/r/1679694482-16430-3-git-send-email-quic_eserrao@quicinc.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The wakeup bit in the bmAttributes field indicates whether the device
is configured for remote wakeup. But this field should be allowed to
set only if the UDC supports such wakeup mechanism. So configure this
field based on UDC capability. Also inform the UDC whether the device
is configured for remote wakeup by implementing a gadget op.
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Elson Roy Serrao <quic_eserrao@quicinc.com>
Link: https://lore.kernel.org/r/1679694482-16430-2-git-send-email-quic_eserrao@quicinc.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Per binding doc, update the compatible
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20230322052504.2629429-11-peng.fan@oss.nxp.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is no SMMU in i.MX8DXL, drop #stream-id-cells which
is for SMMU-v2.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20230322052504.2629429-9-peng.fan@oss.nxp.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Update usb compatible per binding doc
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20230322052504.2629429-8-peng.fan@oss.nxp.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Update usb compatible per binding doc
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20230322052504.2629429-7-peng.fan@oss.nxp.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Update usb compatible per binding doc
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20230322052504.2629429-6-peng.fan@oss.nxp.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Update usb compatible per binding doc
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20230322052504.2629429-5-peng.fan@oss.nxp.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add power-domains optional property
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20230322052504.2629429-4-peng.fan@oss.nxp.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Convert the binding to DT schema format. To fix the dtbs_check
error, some properties were also added, such as nvidia,phy, reset-names
ulpi; missing compatibles are added.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230322052504.2629429-3-peng.fan@oss.nxp.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Convert usbmisc-imx to DT schema format, add missing compatibles
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20230322052504.2629429-2-peng.fan@oss.nxp.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Explicitly set and clear wakeup config so we don't leave anything
to chance.

Clear wakeup status on suspend so we know what caused wake up.

The LINESTATE wake up should not be enabled in device mode
if we are not connected to a USB host and in USB suspend (U2/L3)
else it will cause spurious wake up.

For now, don't enable LINESTATE. This means wake up from
USB resume will not work but at least we won't have any spurious
wake ups.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/20230324114429.21838-1-rogerq@kernel.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

According to the description of platform_get_irq()
 * Return: non-zero IRQ number on success,
 			negative error number on failure.
and the code, platform_get_irq() will return -EINVAL
instead of IRQ0.

So platform_get_irq() no longer returns 0, there is no
need to check whether the return value is 0.

Found by Smatch:
drivers/usb/dwc3/host.c:60 dwc3_host_get_irq()
	warn: platform_get_irq() does not return zero
Signed-off-by: Mingxuan Xiang <mx_xiang@hust.edu.cn>
Reviewed-by: Dan Carpenter <error27@gmail.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/20230324060934.1686859-1-mx_xiang@hust.edu.cnSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

'info' is local to the function. There is no need to zeroing it within
a spin_lock section. Moreover, there is no need to explicitly initialize
the .need_pll_quirk field.

Initialize the structure when defined and remove the now useless memset().
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/08ee42fced6af6bd56892cd14f2464380ab071fa.1679600396.git.christophe.jaillet@wanadoo.frSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a spelling mistakes in dev_warn messages. Fix them.
Signed-off-by: Deming Wang <wangdeming@inspur.com>
Link: https://lore.kernel.org/r/20230325063832.1642-1-wangdeming@inspur.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

A recent patch caused an unused-function warning in builds with
CONFIG_PM disabled, after the function became marked 'static':

drivers/usb/host/xhci-pci.c:91:13: error: 'xhci_msix_sync_irqs' defined but not used [-Werror=unused-function]
   91 | static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
      |             ^~~~~~~~~~~~~~~~~~~

This could be solved by adding another #ifdef, but as there is
a trend towards removing CONFIG_PM checks in favor of helper
macros, do the same conversion here and use pm_ptr() to get
either a function pointer or NULL but avoid the warning.

As the hidden functions reference some other symbols, make
sure those are visible at compile time, at the minimal cost of
a few extra bytes for 'struct usb_device'.

Fixes: 9abe15d5 ("xhci: Move xhci MSI sync function to to xhci-pci")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20230328131114.1296430-1-arnd@kernel.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ENTER() used to show function name which called during runtime, ftrace can
be used to get same information, let's remove it.
Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com>
Link: https://lore.kernel.org/r/1679911940-4727-1-git-send-email-quic_linyyuan@quicinc.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

For the Processing Unit and Camera Terminal descriptors defined in
the UVC Gadget we currently hard-code values into their bmControls
fields, which enumerates which controls the gadget is able to
support. This isn't appropriate since only the userspace companion
program to the kernel driver will know which controls are supported.
Make the configfs attributes that point to those fields read/write
so userspace can set them to appropriate values.

Document the new behaviour at the same time so the functionality is
clear.
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
Link: https://lore.kernel.org/r/20230309105825.216745-1-dan.scally@ideasonboard.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Some development boards don't have the interrupt line connected.

In such cases we can resort to polling the interrupt status.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20230324131853.41102-1-rogerq@kernel.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

We need the USB fixes here, and the USB gadget update for future
development patches to be based on.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Pull USB / Thunderbolt driver fixes from Greg KH:
 "Here are a small set of USB and Thunderbolt driver fixes for reported
  problems and a documentation update, for 6.3-rc4.

  Included in here are:

   - documentation update for uvc gadget driver

   - small thunderbolt driver fixes

   - cdns3 driver fixes

   - dwc3 driver fixes

   - dwc2 driver fixes

   - chipidea driver fixes

   - typec driver fixes

   - onboard_usb_hub device id updates

   - quirk updates

  All of these have been in linux-next with no reported problems"

* tag 'usb-6.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (30 commits)
  usb: dwc2: fix a race, don't power off/on phy for dual-role mode
  usb: dwc2: fix a devres leak in hw_enable upon suspend resume
  usb: chipidea: core: fix possible concurrent when switch role
  usb: chipdea: core: fix return -EINVAL if request role is the same with current role
  thunderbolt: Rename shadowed variables bit to interrupt_bit and auto_clear_bit
  thunderbolt: Disable interrupt auto clear for rings
  thunderbolt: Use const qualifier for `ring_interrupt_index`
  usb: gadget: Use correct endianness of the wLength field for WebUSB
  uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS583Gen 2
  usb: cdnsp: changes PCI Device ID to fix conflict with CNDS3 driver
  usb: cdns3: Fix issue with using incorrect PCI device function
  usb: cdnsp: Fixes issue with redundant Status Stage
  MAINTAINERS: make me a reviewer of USB/IP
  thunderbolt: Use scale field when allocating USB3 bandwidth
  thunderbolt: Limit USB3 bandwidth of certain Intel USB4 host routers
  thunderbolt: Call tb_check_quirks() after initializing adapters
  thunderbolt: Add missing UNSET_INBOUND_SBTX for retimer access
  thunderbolt: Fix memory leak in margining
  usb: dwc2: drd: fix inconsistent mode if role-switch-default-mode="host"
  docs: usb: Add documentation for the UVC Gadget
  ...

Pull scheduler fix from Borislav Petkov:

 - Fix a corner case where vruntime of a task is not being sanitized

* tag 'sched_urgent_for_v6.3_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/fair: Sanitize vruntime of entity being migrated

Pull perf fix from Borislav Petkov:

 - Properly clear perf event status tracking in the AMD perf event
   overflow handler

* tag 'perf_urgent_for_v6.3_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/x86/amd/core: Always clear status for idx

Pull core fixes from Borislav Petkov:

 - Do the delayed RCU wakeup for kthreads in the proper order so that
   former doesn't get ignored

 - A noinstr warning fix

* tag 'core_urgent_for_v6.3_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  entry/rcu: Check TIF_RESCHED _after_ delayed RCU wake-up
  entry: Fix noinstr warning in __enter_from_user_mode()

Pull x86 fixes from Borislav Petkov:

 - Add a AMX ptrace self test

 - Prevent a false-positive warning when retrieving the (invalid)
   address of dynamic FPU features in their init state which are not
   saved in init_fpstate at all

 - Randomize per-CPU entry areas only when KASLR is enabled

* tag 'x86_urgent_for_v6.3_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  selftests/x86/amx: Add a ptrace test
  x86/fpu/xstate: Prevent false-positive warning in __copy_xstate_uabi_buf()
  x86/mm: Do not shuffle CPU entry areas without KASLR