Different controller IPs check different HW parameters for MDWIDTH.
To help with maintainability, create a helper function to consolidate
the logic in a single place.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/456329d36e8c188df5c234f3282595b630bf1470.1616892233.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Convert the usb-nop-xceiv binding to DT schema.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210327202816.545282-1-robh@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Users of the DT graph binding now should reference it for their 'port'
schemas, so add it for Mediatek MTU3 binding.

Cc: Chunfeng Yun <chunfeng.yun@mediatek.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210327191448.410795-1-robh@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use wakeup control register offset exactly, and update revision
number
Signed-off-by: NChunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/1616482975-17841-13-git-send-email-chunfeng.yun@mediatek.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since the driver only supports the devices created by the OF
core, seems no need MODULE_ALIAS() anymore.
Signed-off-by: NChunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/1616482975-17841-9-git-send-email-chunfeng.yun@mediatek.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The driver can match only the devices created by the OF core
via the DT table, so the table should be always used.
Signed-off-by: NChunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/1616482975-17841-8-git-send-email-chunfeng.yun@mediatek.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

These two HW of wakeup don't follow MediaTek internal IPM rule,
and both use a specific way, like as early revision of mt8173.

Due to the index 2 already used by many DTS, it's better to keep
it unchanged for backward compatibility, treat specific ones without
following IPM rule as revision 1.x, meanwhile reserve 3~99 for
later revision that following the IPM rule.
Signed-off-by: NChunfeng Yun <chunfeng.yun@mediatek.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/1616482975-17841-3-git-send-email-chunfeng.yun@mediatek.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

These two HW of wakeup don't follow MediaTek internal IPM rule,
both use a specific way, like as early revision of mt8173.

Due to the index 2 already used by many DTS, it's better to keep
it unchanged for backward compatibility, treat specific ones without
following IPM rule as revision 1.x, meanwhile reserve 3~99 for
later revisions with following the IPM rule.
Signed-off-by: NChunfeng Yun <chunfeng.yun@mediatek.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/1616482975-17841-2-git-send-email-chunfeng.yun@mediatek.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The newer usb_control_msg_{send|recv}() API ensures that a short read is
treated as an error, data can be used off the stack, and raw usb pipes
need not be created in the calling functions.
For this reason, instances of usb_control_msg() have been replaced with
usb_control_msg_send() appropriately.
Signed-off-by: NAnant Thazhemadam <anant.thazhemadam@gmail.com>
Link: https://lore.kernel.org/r/20210326223251.753952-4-anant.thazhemadam@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The newer usb_control_msg_{send|recv}() API ensures that a short read is
treated as an error, data can be used off the stack, and raw usb pipes need
not be created in the calling functions.
For this reason, the instance of usb_control_msg() has been replaced with
usb_control_msg_send() appropriately.
Reviewed-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NAnant Thazhemadam <anant.thazhemadam@gmail.com>
Link: https://lore.kernel.org/r/20210326223251.753952-3-anant.thazhemadam@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The newer usb_control_msg_{send|recv}() API ensures that a short read
is treated as an error, data can be used off the stack, and raw usb
pipes need not be created in the calling functions.
For this reason, instances of usb_control_msg() have been replaced with
usb_control_msg_{recv|send}() appropriately.

Now, we also test for a short device descriptor (which USB core
should already have fetched if you get to probe this driver), but which
wasn't verified again here before.
Reviewed-by: NPeter Chen <peter.chen@nxp.com>
Reviewed-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NAnant Thazhemadam <anant.thazhemadam@gmail.com>
Link: https://lore.kernel.org/r/20210326223251.753952-2-anant.thazhemadam@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The build error happens when CONFIG_POWER_SUPPLY is not enabled.

h8300-linux-ld: drivers/usb/dwc3/gadget.o: in function `.L59':
>> gadget.c:(.text+0x655): undefined reference to `power_supply_set_property'

Fixes: 99288de3 ("usb: dwc3: add an alternate path in vbus_draw callback")
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NRay Chi <raychi@google.com>
Link: https://lore.kernel.org/r/20210327182809.1814480-3-raychi@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently, vbus_draw callback used wrong scale for power_supply.
The unit of power supply should be uA.
Therefore, this patch will fix this problem.

Fixes: 99288de3 ("usb: dwc3: add an alternate path in vbus_draw callback")
Reported-by: NSebastian Reichel <sre@kernel.org>
Signed-off-by: NRay Chi <raychi@google.com>
Link: https://lore.kernel.org/r/20210327182809.1814480-2-raychi@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The driver can match only the devices created by the OF core
via the DT table, so the table should be always used.
Signed-off-by: NChunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/1616482975-17841-12-git-send-email-chunfeng.yun@mediatek.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add add support ip-sleep wakeup for MT8192, it's a specific
revision, not following IPM rule.
Signed-off-by: NChunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/1616482975-17841-11-git-send-email-chunfeng.yun@mediatek.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support ip-sleep wakeup for MT8183, it's similar to MT8173,
and it's also a specific one, but not following IPM rule.
Due to the index 2 already used by many DTS, it's better to keep
it unchanged for backward compatibility, treat specific ones without
following IPM rule as revision 1.x, meanwhile reserve 3~10 for later
revision that follows the IPM rule.
Signed-off-by: NChunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/1616482975-17841-10-git-send-email-chunfeng.yun@mediatek.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support ip-sleep wakeup for mT8192, it's a specific revision,
and not following IPM rule.
Signed-off-by: NChunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/1616482975-17841-7-git-send-email-chunfeng.yun@mediatek.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support ip-sleep wakeup for MT8183, it's similar to MT8173,
and it's also a specific one, but not following IPM rule.
Due to the index 2 already used by many DTS, it's better to keep
it unchanged for backward compatibility, treat specific ones without
following IPM rule as revision 1.x, meanwhile reserve 3~10 for
later revision that follows the IPM rule.
Signed-off-by: NChunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/1616482975-17841-6-git-send-email-chunfeng.yun@mediatek.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Unify quirks, in particular one for Intel Quark, to use driver data
and accompanying infrastructure.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210325135508.70350-4-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We don't need DMI to identify Intel Minnowboard (v1) since it has
properly set PCI sub IDs. So, drop unneeded DMI level of identification.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210325135508.70350-3-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use __maybe_unused for the suspend()/resume() hooks and get rid of
the CONFIG_PM_SLEEP ifdefery to improve the code.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210325135508.70350-2-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We have generic implementations for a reason, let's use them.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210325135508.70350-1-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A short packet indicates the end of a transfer and marks the request as
complete.

Fixes: b84a8dee ("usb: gadget: add Faraday fotg210_udc driver")
Signed-off-by: NFabian Vogt <fabian@ritter-vogt.de>
Link: https://lore.kernel.org/r/20210324141115.9384-8-fabian@ritter-vogt.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Before this, it wrote as much as available into the buffer, even if it
didn't fit.

Fixes: b84a8dee ("usb: gadget: add Faraday fotg210_udc driver")
Signed-off-by: NFabian Vogt <fabian@ritter-vogt.de>
Link: https://lore.kernel.org/r/20210324141115.9384-7-fabian@ritter-vogt.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Notify the UDC core that a bus reset occurred.
Signed-off-by: NFabian Vogt <fabian@ritter-vogt.de>
Link: https://lore.kernel.org/r/20210324141115.9384-6-fabian@ritter-vogt.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently it leaves unhandled interrupts unmasked, but those are never
acked. In the case of a "device idle" interrupt, this leads to an
effectively frozen system until plugging it in.

Fixes: b84a8dee ("usb: gadget: add Faraday fotg210_udc driver")
Signed-off-by: NFabian Vogt <fabian@ritter-vogt.de>
Link: https://lore.kernel.org/r/20210324141115.9384-5-fabian@ritter-vogt.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When the EP0 IN request was not completed but less than a packet sent,
it would complete the request successfully. That doesn't make sense
and can't really happen as fotg210_start_dma always sends
min(length, maxpkt) bytes.

Fixes: b84a8dee ("usb: gadget: add Faraday fotg210_udc driver")
Signed-off-by: NFabian Vogt <fabian@ritter-vogt.de>
Link: https://lore.kernel.org/r/20210324141115.9384-4-fabian@ritter-vogt.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For a 134 Byte packet, it sends the first two 64 Byte packets just fine,
but then notice that less than a packet is remaining and call fotg210_done
without actually sending the rest.

Fixes: b84a8dee ("usb: gadget: add Faraday fotg210_udc driver")
Signed-off-by: NFabian Vogt <fabian@ritter-vogt.de>
Link: https://lore.kernel.org/r/20210324141115.9384-3-fabian@ritter-vogt.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For a 75 Byte request, it would send the first 64 separately, then detect
that the remaining 11 Byte fit into a single DMA, but due to this bug set
the length to the original 75 Bytes. This leads to a DMA failure (which is
ignored...) and the request completes without the remaining bytes having
been sent.

Fixes: b84a8dee ("usb: gadget: add Faraday fotg210_udc driver")
Signed-off-by: NFabian Vogt <fabian@ritter-vogt.de>
Link: https://lore.kernel.org/r/20210324141115.9384-2-fabian@ritter-vogt.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add the compatible string for sc7280 SoC from Qualcomm.
Signed-off-by: NSandeep Maheswaram <sanm@codeaurora.org>
Acked-by: NRob Herring <robh@kernel.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Reviewed-by: NMatthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/1615978901-4202-2-git-send-email-sanm@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently dwc3 only prints the virtual address of a register when doing
register read/write. However, these hashed addresses are difficult to read.
Also, since we use %p, we may get some useless (___ptrval___) prints if the
address is not randomized enough. Let's include the register offset to help
read the register read and write tracepoints.
Acked-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/cb38aa7dec109a8965691b53039a8b317d026189.1616636706.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The sparse tool complains as follows:

drivers/usb/typec/tcpm/tcpci_maxim.c:55:34: warning:
 symbol 'max_tcpci_tcpci_write_table' was not declared. Should it be static?

This symbol is not used outside of tcpci_maxim.c, so this
commit marks it static.
Reported-by: NHulk Robot <hulkci@huawei.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Link: https://lore.kernel.org/r/20210324144253.1011234-1-weiyongjun1@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The option '-d/--device' was implemented in 'usbip list' but not
shown in usage. Hence this commit adds this option to usage.
Acked-by: NShuah Khan <skhan@linuxfoundation.org>
Signed-off-by: NHongren Zheng <i@zenithal.me>
Link: https://lore.kernel.org/r/YFrwq75Uyef3c9gz@SunSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit e0546fd8 ("usbip: tools: Start using VUDC backend in
usbip tools") implemented device mode for user space tools, however the
corresponding options are not documented in man page.

This commit documents the options and provides examples on device mode.
Also the command `usbip port` is documented.
Acked-by: NShuah Khan <skhan@linuxfoundation.org>
Signed-off-by: NHongren Zheng <i@zenithal.me>
Link: https://lore.kernel.org/r/YFrdyKKx1nx8bktm@SunSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In list.h, the kernel-doc for list_del() should be immediately
preceding the implementation and not separated from it by
another function implementation.

Eliminates this kernel-doc error:
list.h:1: warning: 'list_del' not found

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Valentina Manea <valentina.manea.m@gmail.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org
Acked-by: NShuah Khan <skhan@linuxfoundation.org>
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20210325174724.14447-1-rdunlap@infradead.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

s/Acknowlege/Acknowledge/
Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NBhaskar Chowdhury <unixbhaskar@gmail.com>
Link: https://lore.kernel.org/r/20210325051023.27914-1-unixbhaskar@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Intel Minnowboard (v1) uses SCH GPIO line SUS7 (i.e. 12)
for VBUS sense. Provide a DMI based quirk to have it's being used.

Fixes: e20849a8 ("usb: gadget: pch_udc: Convert to use GPIO descriptors")
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210323153626.54908-7-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

During conversion to use GPIO descriptors the device pointer,
which is applied to devm_gpiod_get(), is not yet initialized.

Move initialization in the ->probe() in order to have it set before use.

Fixes: e20849a8 ("usb: gadget: pch_udc: Convert to use GPIO descriptors")
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210323153626.54908-6-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit d3cb25a1 ("usb: gadget: udc: fix spin_lock in pch_udc")
obviously was not thought through and had made the situation even worse
than it was before. Two changes after almost reverted it. but a few
leftovers have been left as it. With this revert d3cb25a1 completely.

While at it, narrow down the scope of unlocked section to prevent
potential race when prot_stall is assigned.

Fixes: d3cb25a1 ("usb: gadget: udc: fix spin_lock in pch_udc")
Fixes: 9903b6be ("usb: gadget: pch-udc: fix lock")
Fixes: 1d23d16a ("usb: gadget: pch_udc: reorder spin_[un]lock to avoid deadlock")
Cc: Iago Abal <mail@iagoabal.eu>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210323153626.54908-5-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Kernel doc and the content described by it shouldn't be torn apart.
Otherwise validator is not happy:

.../pch_udc.c:573: warning: expecting prototype for pch_udc_reconnect(). Prototype was for pch_udc_init() instead

Fixes: 1c575d2d ("usb: gadget: pch_udc: Fix usb/gadget/pch_udc: Fix ether gadget connect/disconnect issue")
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210323153626.54908-4-andriy.shevchenko@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>