If DbC is already in use, then the allocated memory for the xhci_dbc struct
doesn't get freed before returning NULL, which leads to a memleak.

Fixes: 53467594 ("xhci: dbc: refactor xhci_dbc_init()")
Cc: stable@vger.kernel.org
Signed-off-by: Rafael Mendonca <rafaelmendsr@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20220921123450.671459-3-mathias.nyman@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci_alloc_stream_info() allocates stream context array for stream_info
->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs,
stream_info->stream_ctx_array is not released, which will lead to a
memory leak.

We can fix it by releasing the stream_info->stream_ctx_array with
xhci_free_stream_ctx() on the error path to avoid the potential memory
leak.
Signed-off-by: Jianglei Nie <niejianglei2021@163.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20220921123450.671459-2-mathias.nyman@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'usb-serial-6.1-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next

Johan writes:
  "USB-serial updates for 6.1-rc1

   Here are the USB-serial updates for 6.1-rc1, including:
    - a fix for a very long-standing FTDI SIO regression
    - a long-overdue cleanup of the FTDI type handling
    - support for new FTDI HP and HA devices

   Included are also various clean ups.

   All have been in linux-next with no reported issues."

* tag 'usb-serial-6.1-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
  USB: serial: ftdi_sio: clean up driver prefix
  USB: serial: ftdi_sio: move driver structure
  USB: serial: ftdi_sio: clean up attribute visibility logic
  USB: serial: console: move mutex_unlock() before usb_serial_put()
  USB: serial: ftdi_sio: convert to use dev_groups
  USB: serial: ftdi_sio: add support for HP and HA devices
  USB: serial: ftdi_sio: simplify divisor handling
  USB: serial: ftdi_sio: assume hi-speed type
  USB: serial: ftdi_sio: clean up baudrate request
  USB: serial: ftdi_sio: clean up attribute handling
  USB: serial: ftdi_sio: clean up modem-status handling
  USB: serial: ftdi_sio: tighten device-type detection
  USB: serial: ftdi_sio: rename channel index
  USB: serial: ftdi_sio: include FT2232D in type string
  USB: serial: ftdi_sio: rename chip types
  USB: serial: ftdi_sio: drop redundant chip type comments
  USB: serial: ftdi_sio: clean up chip type enum
  USB: serial: ftdi_sio: fix 300 bps rate for SIO

Drop the "sio" infix from the few remaining definitions and symbol names
that still had it.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>

Move the definition of the USB serial driver structure to the end of the
file where it is used and drop the now redundant forward declarations.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>

Clean up the attribute visibility logic by defaulting to attributes
being visible and explicitly listing the exceptions.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>

While in current version there is no use-after-free as USB serial
core holds another reference when the console is registered, we
should better unlock before dropping the reference in
usb_console_setup().

Fixes: 7bd032dc ("USB serial: update the console driver")
Signed-off-by: Liang He <windhl@126.com>
Signed-off-by: Johan Hovold <johan@kernel.org>

The driver core supports the ability to handle the creation and removal
of device-specific sysfs files in a race-free manner.
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
[ johan: rebase on type rework, make groups static, clean up, amend
         commit message ]
Signed-off-by: Johan Hovold <johan@kernel.org>

Add the product IDs for the USB-to-Serial devices FT2233HP, FT2232HP,
FT4233HP, FT4232HP, FT233HP, FT232HP, and FT4232HA.
Also include BCD values so that the chip type can be determined.
Signed-off-by: Amireddy mallikarjuna reddy <mallikarjuna.reddy@ftdichip.com>
Link: https://lore.kernel.org/r/ac28f2c5eba23a645b3b9299c224f2755a233eef.1658385786.git.mallikarjuna.reddy@ftdichip.com
[ johan: rebase on type-handling rework, drop "Q" from automotive type
         name ]
Signed-off-by: Johan Hovold <johan@kernel.org>

In preparation for adding further Hi-Speed types, assume the device type
is Hi-Speed unless it's an explicitly listed legacy type when
determining divisors.
Signed-off-by: Johan Hovold <johan@kernel.org>

In preparation for adding further Hi-Speed types, assume a 120 MHz clock
and set the channel index by default and instead override these values
as needed for legacy types.
Signed-off-by: Johan Hovold <johan@kernel.org>

Multi-channel devices need to encode the channel selector in their
control requests and newer single-channel chip types use the same
request format.

Set the channel index also for these single-channel types so that the
index can be used to determine the baudrate request format instead of
listing types explicitly.

Note that FT232H and FTX accept either 0 or 1 as selector for their
single channel, presumably for backward compatibility reasons.
Signed-off-by: Johan Hovold <johan@kernel.org>

The driver exposes two attributes for all chip types but FT232A, which
doesn't have a configurable latency timer, and SIO, which (probably)
doesn't support the event-char mechanism either.

Explicitly test for the exceptions rather than list each and every
supported device type in the attribute helpers.
Signed-off-by: Johan Hovold <johan@kernel.org>

All chip types but the original SIO (FT8U100AX) return a two-byte modem
status and there's no need to explicitly list every other type in the
handler.
Signed-off-by: Johan Hovold <johan@kernel.org>

Clean up and tighten the device-type detection, which is based on
bcdDevice.

Don't make assumptions about unknown (future) types (currently assumed
to be either FT2232C or FT-X depending on bNumInterfaces) and instead
log an error and refuse to bind so that we can add proper support when
needed.

Note that the bcdDevice values have been provided by FTDI.
Signed-off-by: Johan Hovold <johan@kernel.org>

Multi-channel devices require a channel selector to be included in
control requests.

Replace "interface" with the less ambiguous "channel", which is the
terminology used for newer devices, in the corresponding defines and
variables.
Signed-off-by: Johan Hovold <johan@kernel.org>

Include the updated D-version in the type string for the FT2232C type.
Signed-off-by: Johan Hovold <johan@kernel.org>

Shorten the chip type enum and string representation for A, B and R chip
types so that they don't include the IC package type in the name.
Signed-off-by: Johan Hovold <johan@kernel.org>

Drop redundant chip type comments.
Signed-off-by: Johan Hovold <johan@kernel.org>

Clean up the chip type enum by dropping the explicit values and moving
the definition to the implementation to make it easier to add further
types.
Signed-off-by: Johan Hovold <johan@kernel.org>

The 300 bps rate of SIO devices has been mapped to 9600 bps since
2003... Let's fix the regression.

Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>

Smatch reports the following warning:

drivers/usb/misc/usb3503.c:267 usb3503_probe() warn: 'hub->clk'
from clk_prepare_enable() not released on lines: 240,246,252

Fix this by adding a flag to indicate if hub->clk is prepared or not
and invoke clk_disable_unprepare in the error handling.
Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
Link: https://lore.kernel.org/r/20220908055903.3550723-1-dzm91@hust.edu.cnSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch is changing the simple workqueue in the gadget driver to be
allocated as async_wq with a higher priority. The pump worker, that is
filling the usb requests, will have a higher priority and will not be
scheduled away so often while the video stream is handled. This will
lead to fewer streaming underruns.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20220907215818.2670097-1-m.grzeschik@pengutronix.deSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 6a108a14 ("kconfig: rename CONFIG_EMBEDDED to CONFIG_EXPERT")
introduces CONFIG_EXPERT to carry the previous intent of CONFIG_EMBEDDED
and just gives that intent a much better name. That has been clearly a good
and long overdue renaming, and it is clearly an improvement to the kernel
build configuration that has shown to help managing the kernel build
configuration in the last decade.

However, rather than bravely and radically just deleting CONFIG_EMBEDDED,
this commit gives CONFIG_EMBEDDED a new intended semantics, but keeps it
open for future contributors to implement that intended semantics:

    A new CONFIG_EMBEDDED option is added that automatically selects
    CONFIG_EXPERT when enabled and can be used in the future to isolate
    options that should only be considered for embedded systems (RISC
    architectures, SLOB, etc).

Since then, this CONFIG_EMBEDDED implicitly had two purposes:

  - It can make even more options visible beyond what CONFIG_EXPERT makes
    visible. In other words, it may introduce another level of enabling the
    visibility of configuration options: always visible, visible with
    CONFIG_EXPERT and visible with CONFIG_EMBEDDED.

  - Set certain default values of some configurations differently,
    following the assumption that configuring a kernel build for an
    embedded system generally starts with a different set of default values
    compared to kernel builds for all other kind of systems.

Considering the first purpose, at the point in time where CONFIG_EMBEDDED
was renamed to CONFIG_EXPERT, CONFIG_EXPERT already made 130 more options
become visible throughout all different menus for the kernel configuration.
Over the last decade, this has gradually increased, so that currently, with
CONFIG_EXPERT, roughly 170 more options become visible throughout all
different menus for the kernel configuration. In comparison, currently with
CONFIG_EMBEDDED enabled, just seven more options are visible, one in x86,
one in arm, and five for the ChipIdea Highspeed Dual Role Controller.

As the numbers suggest, these two levels of enabling the visibility of even
more configuration options---beyond what CONFIG_EXPERT enables---never
evolved to a good solution in the last decade. In other words, this
additional level of visibility of configuration option with CONFIG_EMBEDDED
compared to CONFIG_EXPERT has since its introduction never become really
valuable. It requires quite some investigation to actually understand what
is additionally visible and it does not differ significantly in complexity
compared to just enabling CONFIG_EXPERT. This CONFIG_EMBEDDED---or any
other config to show more detailed options beyond CONFIG_EXPERT---is
unlikely to be valuable unless somebody puts significant effort in
identifying how such visibility options can be properly split and creating
clear criteria, when some config option is visible with CONFIG_EXPERT and
when some config option is visible only with some further option enabled
beyond CONFIG_EXPERT, such as CONFIG_EMBEDDED attempted to do. For now, it
is much more reasonable to simply make those additional seven options that
visible with CONFIG_EMBEDDED, visible with CONFIG_EXPERT, and then remove
CONFIG_EMBEDDED. If anyone spends significant effort in structuring the
visibility of config options, they may re-introduce suitable new config
options simply as they see fit.

Make the configs for usb chipidea glue drivers visible when CONFIG_EXPERT
is enabled.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20220908104337.11940-5-lukas.bulwahn@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

During a cable disconnect sequence, if ep0state is not in the SETUP phase,
then nothing will trigger any pending end transfer commands.  Force
stopping of any pending SETUP transaction, and move back to the SETUP
phase.
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220901193625.8727-6-quic_wcheng@quicinc.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

For endxfer commands that do not require an endpoint complete interrupt,
avoid having to wait for the command active bit to clear.  This allows for
EP0 events to continue to be handled, which allows for the controller to
complete it.  Otherwise, it is known that the endxfer command will fail if
there is a pending SETUP token that needs to be read.
Suggested-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220901193625.8727-5-quic_wcheng@quicinc.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Since EP0 transactions need to be completed before the controller halt
sequence is finished, this may take some time depending on the host and the
enabled functions.  Increase the controller halt timeout, so that we give
the controller sufficient time to handle EP0 transfers.
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220901193625.8727-4-quic_wcheng@quicinc.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove the need for making dwc3_gadget_suspend() and dwc3_gadget_resume()
to be called in a spinlock, as dwc3_gadget_run_stop() could potentially
take some time to complete.
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220901193625.8727-3-quic_wcheng@quicinc.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

If DWC3_EP_DELAYED_STOP is set during stop active transfers, then do not
continue attempting to unmap request buffers during dwc3_remove_requests().
This can lead to SMMU faults, as the controller has not stopped the
processing of the TRB.  Defer this sequence to the EP0 out start, which
ensures that there are no pending SETUP transactions before issuing the
endxfer.
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220901193625.8727-2-quic_wcheng@quicinc.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This converts the S3C2410 UDC USB device controller to use
GPIO descriptor tables and modern GPIO.

Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Alim Akhtar <alim.akhtar@samsung.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220901081649.564348-1-linus.walleij@linaro.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Smatch reports the following error: uninitialized symbol 'rlen'

drivers/usb/misc/uss720.c:514 parport_uss720_epp_write_data() error
drivers/usb/misc/uss720.c:575 parport_uss720_ecp_write_data() error
drivers/usb/misc/uss720.c:593 parport_uss720_ecp_read_data() error
drivers/usb/misc/uss720.c:626 parport_uss720_write_compat() error

The root cause is, the failure of usb_bulk_msg leads to the
uninitialized variable rlen in printk function.

Fix this by initializing rlen with zero.
Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
Link: https://lore.kernel.org/r/20220903100004.2874741-1-dzm91@hust.edu.cnSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This from static analysis.  The vla_item() takes a size and adds it to
the total.  It has a built in integer overflow check so if it encounters
an integer overflow anywhere then it records the total as SIZE_MAX.

However there is an issue here because the "lang_count*(needed_count+1)"
multiplication can overflow.  Technically the "lang_count + 1" addition
could overflow too, but that would be detected and is harmless.  Fix
both using the new size_add() and size_mul() functions.

Fixes: e6f3862f ("usb: gadget: FunctionFS: Remove VLAIS usage from gadget code")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/YxDI3lMYomE7WCjn@kiliSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Drop another couple of pointless pr_info() calls, and drop a number of
instances of hcd_name variables that are no longer referenced now that
they are no longer printed to the log at driver registration time.

Fixes: 10174220 ("usb: reduce kernel log spam on driver registration")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20220905111740.352348-1-ardb@kernel.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

I would like to stop exporting OF-specific gpiod_get_from_of_node()
so that gpiolib can be cleaned a bit, so let's switch to the generic
fwnode property API.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Link: https://lore.kernel.org/r/20220903-gpiod_get_from_of_node-remove-v1-5-b29adfb27a6c@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

I would like to stop exporting OF-specific devm_gpiod_get_from_of_node()
so that gpiolib can be cleaned a bit, so let's switch to the generic
device property API.

I believe that the only reason the driver, instead of the standard
devm_gpiod_get(), used devm_gpiod_get_from_of_node() is because it
wanted to set up a pretty consumer name for the GPIO, and we now have
a special API for that.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Link: https://lore.kernel.org/r/20220903-gpiod_get_from_of_node-remove-v1-4-b29adfb27a6c@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This is only called in the xhci.c file, so make the symbol static.

Cc: Mathias Nyman <mathias.nyman@intel.com>
Link: https://lore.kernel.org/r/20220901134744.2039891-1-gregkh@linuxfoundation.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The ohci retaining bogus hardware states cause usb disconnect devices
connected before hibernation(s4), this issue occur when ohci-platform
driver build as a module and the built-in ohci-platform driver will
re probe and re enumerate the devices, so there will be no such problem.

Avoid retaining bogus hardware states during resume-from-hibernation.
Previously we had reset the hardware as part of preparing to reinstate
the snapshot image. But we can do better now with the new PM framework,
since we know exactly which resume operations are from hibernation.

According to the commit 'cd1965db ("USB: ohci: move ohci_pci_{
suspend,resume} to ohci-hcd.c")' and commit '6ec4beb5 ("USB: new
flag for resume-from-hibernation")', the flag "hibernated" is for
resume-from-hibernation and it should be true when usb resume from disk.

When this flag "hibernated" is set, the drivers will reset the hardware
to get rid of any existing state and make sure resume from hibernation
re-enumerates everything for ohci.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Yinbo Zhu <zhuyinbo@loongson.cn>
Link: https://lore.kernel.org/r/20220902063639.17875-1-zhuyinbo@loongson.cnSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

We need the USB fixes in here and this resolves the merge issue in:
	drivers/usb/dwc3/gadget.c
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Pull powerpc fixes from Michael Ellerman:

 - Fix handling of PCI domains in /proc on 32-bit systems using the
   recently added support for numbering buses from zero for each domain.

 - A fix and a revert for some changes to use READ/WRITE_ONCE() which
   caused problems with KASAN enabled due to sanitisation calls being
   introduced in low-level paths that can't cope with it.

 - Fix build errors on 32-bit caused by the syscall table being
   misaligned sometimes.

 - Two fixes to get IBM Cell native machines booting again, which had
   bit-rotted while my QS22 was temporarily out of action.

 - Fix the papr_scm driver to not assume the order of events returned by
   the hypervisor is stable, and a related compile fix.

Thanks to Aneesh Kumar K.V, Christophe Leroy, Jordan Niethe, Kajol Jain,
Masahiro Yamada, Nathan Chancellor, Pali Rohár, Vaibhav Jain, and Zhouyi
Zhou.

* tag 'powerpc-6.0-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/papr_scm: Ensure rc is always initialized in papr_scm_pmu_register()
  Revert "powerpc/irq: Don't open code irq_soft_mask helpers"
  powerpc: Fix hard_irq_disable() with sanitizer
  powerpc/rtas: Fix RTAS MSR[HV] handling for Cell
  Revert "powerpc: Remove unused FW_FEATURE_NATIVE references"
  powerpc: align syscall table for ppc32
  powerpc/pci: Enable PCI domains in /proc when PCI bus numbers are not unique
  powerpc/papr_scm: Fix nvdimm event mappings