The usb_get_device_descriptor() routine reads the device descriptor
from the udev device and stores it directly in udev->descriptor.  This
interface is error prone, because the USB subsystem expects in-memory
copies of a device's descriptors to be immutable once the device has
been initialized.

The interface is changed so that the device descriptor is left in a
kmalloc-ed buffer, not copied into the usb_device structure.  A
pointer to the buffer is returned to the caller, who is then
responsible for kfree-ing it.  The corresponding changes needed in the
various callers are fairly small.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/d0111bb6-56c1-4f90-adf2-6cfe152f6561@rowland.harvard.eduSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

In preparation for reworking the usb_get_device_descriptor() routine,
it is desirable to unite the two different code paths responsible for
initially determining endpoint 0's maximum packet size in a newly
discovered USB device.  Making this determination presents a
chicken-and-egg sort of problem, in that the only way to learn the
maxpacket value is to get it from the device descriptor retrieved from
the device, but communicating with the device to retrieve a descriptor
requires us to know beforehand the ep0 maxpacket size.

In practice this problem is solved in two different ways, referred to
in hub.c as the "old scheme" and the "new scheme".  The old scheme
(which is the approach recommended by the USB-2 spec) involves asking
the device to send just the first eight bytes of its device
descriptor.  Such a transfer uses packets containing no more than
eight bytes each, and every USB device must have an ep0 maxpacket size
>= 8, so this should succeed.  Since the bMaxPacketSize0 field of the
device descriptor lies within the first eight bytes, this is all we
need.

The new scheme is an imitation of the technique used in an early
Windows USB implementation, giving it the happy advantage of working
with a wide variety of devices (some of them at the time would not
work with the old scheme, although that's probably less true now).  It
involves making an initial guess of the ep0 maxpacket size, asking the
device to send up to 64 bytes worth of its device descriptor (which is
only 18 bytes long), and then resetting the device to clear any error
condition that might have resulted from the guess being wrong.  The
initial guess is determined by the connection speed; it should be
correct in all cases other than full speed, for which the allowed
values are 8, 16, 32, and 64 (in this case the initial guess is 64).

The reason for this patch is that the old- and new-scheme parts of
hub_port_init() use different code paths, one involving
usb_get_device_descriptor() and one not, for their initial reads of
the device descriptor.  Since these reads have essentially the same
purpose and are made under essentially the same circumstances, this is
illogical.  It makes more sense to have both of them use a common
subroutine.

This subroutine does basically what the new scheme's code did, because
that approach is more general than the one used by the old scheme.  It
only needs to know how many bytes to transfer and whether or not it is
being called for the first iteration of a retry loop (in case of
certain time-out errors).  There are two main differences from the
former code:

	We initialize the bDescriptorType field of the transfer buffer
	to 0 before performing the transfer, to avoid possibly
	accessing an uninitialized value afterward.

	We read the device descriptor into a temporary buffer rather
	than storing it directly into udev->descriptor, which the old
	scheme implementation used to do.

Since the whole point of this first read of the device descriptor is
to determine the bMaxPacketSize0 value, that is what the new routine
returns (or an error code).  The value is stored in a local variable
rather than in udev->descriptor.  As a side effect, this necessitates
moving a section of code that checks the bcdUSB field for SuperSpeed
devices until after the full device descriptor has been retrieved.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.eduSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

When udc_dev = NULL, it is not necessary to goto out to return, just
return NULL directly. And the out goto label can be removed.
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20230805045631.1858638-1-ruanjinjie@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Since commit 8be17483 ("usb: ftdi-elan: Delete driver") this include file
is not used anymore, so can remove it.
Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20230807141128.39092-1-yuehaibing@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 32fee1df ("usb: musb: remove unused davinci support")
removed these implementations but leave declaration.
Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20230807140928.35932-1-yuehaibing@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support for UCSI commands through the following debugfs:
  # /sys/kernel/debug/usb/ucsi/$UCSI_DEVICE/command
  # /sys/kernel/debug/usb/ucsi/$UCSI_DEVICE/response

Eg: To execute UCSI GetCapabilities:
  # echo 0x6 > /sys/kernel/debug/usb/ucsi/<ucsi device>/command
Then read the result,
  # cat /sys/kernel/debug/usb/ucsi/<ucsi device>/response
    0x02000320000000020000ff0400000445

UCSI command will be written into the command file and the
response for the command can be viewed under the response file.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Saranya Gopal <saranya.gopal@intel.com>
Co-developed-by: Rajaram Regupathy <rajaram.regupathy@intel.com>
Signed-off-by: Rajaram Regupathy <rajaram.regupathy@intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20230807105205.742819-1-saranya.gopal@intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch adds support for PPS to CDC devices. Changes to the DCD pin
are monitored and passed to the ldisc system, which is used by
pps-ldisc.
Signed-off-by: Dan Drown <dan-netdev@drown.org>
Link: https://lore.kernel.org/r/ZM8ExV6bAvJtIA1d@vps3.drown.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Assign copyright to indicate driver rewrite is done for RACOM s.r.o.
As David no longer works for Marvell (Cavium), I'm to blame for breakage.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Acked-by: David Daney <daviddaney@microsoft.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/r/ZMeAAYx6Z3hlQBNQ@lenochSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

It might be interesting to know control register value in case
clock fails to enable.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/ZMd/5OX9szEMnhQH@lenochSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Parse and verify device tree node first, then setup UCTL bridge
using verified values. This avoids needless allocations
in case DT misconfiguration was found in the middle of setup.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/ZMd/x3MHA4/QowMO@lenochSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Power gpio configuration is done from the middle of
dwc3_octeon_clocks_start leaving hardware in half-initialized
state if it fails. As that indicates dwc3_octeon_clocks_start
does more than just initialize the clocks rename it appropriately
and verify power gpio configuration in advance at the beginning
of device probe.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/ZMd/oMRx8ze22/kK@lenochSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Pass dwc3_octeon instead of just the base. It fits with the
function names and it requires less change in the future if
access to dwc3_octeon is needed.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/ZMd/gt58laSlqAAT@lenochSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

While driver is intended to run on 64bit machines, it is compile time
tested for 32bit targets as well. Here shift count overflow is reported
for bits greater than 31, so use _ULL versions of BIT and GENMASK macros
to silence these warnings.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202307260537.MROrhVNM-lkp@intel.com/Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/ZMd/aa2ncz6tJGNU@lenochSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

DWC3 as implemented in Cavium SoC is using UCTL bridge unit
between I/O interconnect and USB controller.

Currently there is no bond with dwc3 core code, so if anything goes
wrong in UCTL setup dwc3 is left in reset, which leads to bus error
while trying to read any device register. Thus any failure in UCTL
initialization ends with kernel panic.

To avoid this move Octeon DWC3 glue code from arch/mips and make it
proper glue driver which is used instead of dwc3-of-simple.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/ZMd/ReyiY7wS6DvN@lenochSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The NULL initialization of the pointers assigned by kzalloc() first is
not necessary, because if the kzalloc() failed, the pointers will be
assigned NULL, otherwise it works as usual. so remove it.
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Link: https://lore.kernel.org/r/20230804093253.91647-6-ruanjinjie@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The NULL initialization of the pointers assigned by kzalloc() first is
not necessary, because if the kzalloc() failed, the pointers will be
assigned NULL, otherwise it works as usual. so remove it.
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Link: https://lore.kernel.org/r/20230804093253.91647-5-ruanjinjie@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The NULL initialization of the pointers assigned by kzalloc() first is
not necessary, because if the kzalloc() failed, the pointers will be
assigned NULL, otherwise it works as usual. so remove it.
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Link: https://lore.kernel.org/r/20230804093253.91647-4-ruanjinjie@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The NULL initialization of the pointers assigned by kzalloc() first is
not necessary, because if the kzalloc() failed, the pointers will be
assigned NULL, otherwise it works as usual. so remove it.
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Link: https://lore.kernel.org/r/20230804093253.91647-3-ruanjinjie@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The NULL initialization of the pointers assigned by kzalloc() first is
not necessary, because if the kzalloc() failed, the pointers will be
assigned NULL, otherwise it works as usual. so remove it.
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Link: https://lore.kernel.org/r/20230804093253.91647-2-ruanjinjie@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PD3.0 Spec 6.4.1.3.1 said:
For a Sink requiring no power from the Source, the Voltage (B19-10)
shall be set to 5V and the Operational Current Shall be set to 0mA.

Therefore, we can keep sink path closed if the operational current of
the first fixed PDO is 0mA.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20230801070110.1653394-1-xu.yang_2@nxp.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There are following smatch warning:
drivers/phy/realtek/phy-rtk-usb2.c:901 get_phy_data_by_efuse()
error: 'buf' dereferencing possible ERR_PTR()
drivers/phy/realtek/phy-rtk-usb2.c:942 get_phy_data_by_efuse()
error: 'buf' dereferencing possible ERR_PTR()

drivers/phy/realtek/phy-rtk-usb3.c:460
get_phy_data_by_efuse() error: 'buf' dereferencing possible ERR_PTR()

The nvmem_cell_read may fail to read. So, driver must handle failure cases.

Fixes: 134e6d25 ("phy: realtek: usb: Add driver for the Realtek SoC USB 2.0 PHY")
Fixes: adda6e82 ("phy: realtek: usb: Add driver for the Realtek SoC USB 3.0 PHY")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/linux-phy/e7ff2870-c30c-4d8d-a7a9-d2d6a4962eb5@kadam.mountain/Signed-off-by: Stanley Chang <stanley_chang@realtek.com>
Link: https://lore.kernel.org/r/20230801071509.20096-1-stanley_chang@realtek.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

imx35.dtsi has three USB clocks. Adjust the maxItems to fix the following
schema warnings:

imx35-eukrea-mbimxsd35-baseboard.dtb: usb@53ff4400: clock-names: ['ipg', 'ahb', 'per'] is too long
Signed-off-by: Fabio Estevam  <festevam@denx.de>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230731144422.1532498-2-festevam@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The "fsl,imx35-usb" entry is missing in the supported compatible
string list.

Add it to the list.
Signed-off-by: Fabio Estevam  <festevam@denx.de>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230731144422.1532498-1-festevam@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

In current design of the PPS APDO selection, TCPM power supply only
accepts the requested voltage which is inside the range of the selected
PPS profile. To extend the flexibility and usability, remove the checks
about the voltage range in current profile. And try to search all PPS
APDOs of the Source that fit the requested voltage.

Also remove some redundant checks in tcpm_pd_build_pps_request.
Signed-off-by: Kyle Tso <kyletso@google.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20230731162159.19483-1-kyletso@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

It is not possible for platform_get_irq() to return 0. Use the
return value from platform_get_irq().
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Reviewed-by: Justin Chen <justin.chen@broadcom.com>
Link: https://lore.kernel.org/r/20230802031236.2272196-1-ruanjinjie@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a warning reported by coccinelle:

./drivers/usb/gadget/udc/renesas_usbf.c:3381:3-8:
		No need to set .owner here. The core will do it.

The module_platform_driver() will set "THIS_MODULE" to driver.owner
when register a driver for platform-level devices, so it is redundant
initialization to set driver.owner in udc_driver statement. Remove it
to silence the warning.
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Acked-by: Herve Codina <herve.codina@bootlin.com>
Link: https://lore.kernel.org/r/20230803032838.3045730-1-lizetao1@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Ther are many redundant spaces, which is not consistent with
the kernel code style, so remove it.
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Link: https://lore.kernel.org/r/20230804091713.41503-1-ruanjinjie@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

When platform_get_irq() fails, it may return -EPROBE_DEFER, which
suggested deferred probing, it is very important to propagate it
upstream. We cannot override it with other error code.

Commit ce753ad1 ("platform: finally disallow IRQ0 in
platform_get_irq() and its ilk") makes sure IRQ0 is not returned.
Signed-off-by: Zhu Wang <wangzhu9@huawei.com>
Link: https://lore.kernel.org/r/20230804110005.97061-1-wangzhu9@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

When platform_get_irq() is called, the error message has been printed,
so it need not to call dev_err_probe() to present error messages.
Signed-off-by: Zhu Wang <wangzhu9@huawei.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20230801122834.89168-1-wangzhu9@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

When platform_get_irq_byname() fails, it may return -EPROBE_DEFER,
which suggested deferred probing, it is very important to propagate it
upstream. We cannot override it with other error code.

Commit ce753ad1 ("platform: finally disallow IRQ0 in
platform_get_irq() and its ilk") makes sure IRQ0 is not returned.
Signed-off-by: Zhu Wang <wangzhu9@huawei.com>
Link: https://lore.kernel.org/r/20230804105430.95773-1-wangzhu9@huawei.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

We need the USB fixes in here for testing and for other patches to be
applied on top of.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Pull spi fixes from Mark Brown:
 "A bunch of fixes for the Qualcomm QSPI driver, fixing multiple issues
  with the newly added DMA mode - it had a number of issues exposed when
  tested in a wider range of use cases, both race condition style issues
  and issues with different inputs to those that had been used in test"

* tag 'spi-fix-v6.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
  spi: spi-qcom-qspi: Add mem_ops to avoid PIO for badly sized reads
  spi: spi-qcom-qspi: Fallback to PIO for xfers that aren't multiples of 4 bytes
  spi: spi-qcom-qspi: Add DMA_CHAIN_DONE to ALL_IRQS
  spi: spi-qcom-qspi: Call dma_wmb() after setting up descriptors
  spi: spi-qcom-qspi: Use GFP_ATOMIC flag while allocating for descriptor
  spi: spi-qcom-qspi: Ignore disabled interrupts' status in isr

Merge tag 'regulator-fix-v6.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator

Pull regulator fixes from Mark Brown:
 "A couple of small fixes for the the mt6358 driver, fixing error
  reporting and a bootstrapping issue"

* tag 'regulator-fix-v6.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
  regulator: mt6358: Fix incorrect VCN33 sync error message
  regulator: mt6358: Sync VCN33_* enable status after checking ID

Pull USB fixes from Greg KH:
 "Here are a set of USB driver fixes for 6.5-rc4. Include in here are:

   - new USB serial device ids

   - dwc3 driver fixes for reported issues

   - typec driver fixes for reported problems

   - gadget driver fixes

   - reverts of some problematic USB changes that went into -rc1

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

* tag 'usb-6.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (24 commits)
  usb: misc: ehset: fix wrong if condition
  usb: dwc3: pci: skip BYT GPIO lookup table for hardwired phy
  usb: cdns3: fix incorrect calculation of ep_buf_size when more than one config
  usb: gadget: call usb_gadget_check_config() to verify UDC capability
  usb: typec: Use sysfs_emit_at when concatenating the string
  usb: typec: Iterate pds array when showing the pd list
  usb: typec: Set port->pd before adding device for typec_port
  usb: typec: qcom: fix return value check in qcom_pmic_typec_probe()
  Revert "usb: gadget: tegra-xudc: Fix error check in tegra_xudc_powerdomain_init()"
  Revert "usb: xhci: tegra: Fix error check"
  USB: gadget: Fix the memory leak in raw_gadget driver
  usb: gadget: core: remove unbalanced mutex_unlock in usb_gadget_activate
  Revert "usb: dwc3: core: Enable AutoRetry feature in the controller"
  Revert "xhci: add quirk for host controllers that don't update endpoint DCS"
  USB: quirks: add quirk for Focusrite Scarlett
  usb: xhci-mtk: set the dma max_seg_size
  MAINTAINERS: drop invalid usb/cdns3 Reviewer e-mail
  usb: dwc3: don't reset device side if dwc3 was configured as host-only
  usb: typec: ucsi: move typec_set_mode(TYPEC_STATE_SAFE) to ucsi_unregister_partner()
  usb: ohci-at91: Fix the unhandle interrupt when resume
  ...

Pull tty/serial fixes from Greg KH:
 "Here are some small TTY and serial driver fixes for 6.5-rc4 for some
  reported problems. Included in here is:

   - TIOCSTI fix for braille readers

   - documentation fix for minor numbers

   - MAINTAINERS update for new serial files in -rc1

   - minor serial driver fixes for reported problems

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

* tag 'tty-6.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  serial: 8250_dw: Preserve original value of DLF register
  tty: serial: sh-sci: Fix sleeping in atomic context
  serial: sifive: Fix sifive_serial_console_setup() section
  Documentation: devices.txt: reconcile serial/ucc_uart minor numers
  MAINTAINERS: Update TTY layer for lists and recently added files
  tty: n_gsm: fix UAF in gsm_cleanup_mux
  TIOCSTI: always enable for CAP_SYS_ADMIN

Pull staging driver fixes from Greg KH:
 "Here are three small staging driver fixes for 6.5-rc4 that resolve
  some reported problems. These fixes are:

   - fix for an old bug in the r8712 driver

   - fbtft driver fix for a spi device

   - potential overflow fix in the ks7010 driver

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

* tag 'staging-6.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
  staging: ks7010: potential buffer overflow in ks_wlan_set_encode_ext()
  staging: fbtft: ili9341: use macro FBTFT_REGISTER_SPI_DRIVER
  staging: r8712: Fix memory leak in _r8712_init_xmit_priv()

Pull char driver and Documentation fixes from Greg KH:
 "Here is a char driver fix and some documentation updates for 6.5-rc4
  that contain the following changes:

   - sram/genalloc bugfix for reported problem

   - security-bugs.rst update based on recent discussions

   - embargoed-hardware-issues minor cleanups and then partial revert
     for the project/company lists

  All of these have been in linux-next for a while with no reported
  problems, and the documentation updates have all been reviewed by the
  relevant developers"

* tag 'char-misc-6.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  misc/genalloc: Name subpools by of_node_full_name()
  Documentation: embargoed-hardware-issues.rst: add AMD to the list
  Documentation: embargoed-hardware-issues.rst: clean out empty and unused entries
  Documentation: security-bugs.rst: clarify CVE handling
  Documentation: security-bugs.rst: update preferences when dealing with the linux-distros group

Merge tag 'probes-fixes-v6.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace

Pull probe fixes from Masami Hiramatsu:

 - probe-events: add NULL check for some BTF API calls which can return
   error code and NULL.

 - ftrace selftests: check fprobe and kprobe event correctly. This fixes
   a miss condition of the test command.

 - kprobes: do not allow probing functions that start with "__cfi_" or
   "__pfx_" since those are auto generated for kernel CFI and not
   executed.

* tag 'probes-fixes-v6.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
  kprobes: Prohibit probing on CFI preamble symbol
  selftests/ftrace: Fix to check fprobe event eneblement
  tracing/probes: Fix to add NULL check for BTF APIs

Pull kvm fixes from Paolo Bonzini:
 "x86:

   - Do not register IRQ bypass consumer if posted interrupts not
     supported

   - Fix missed device interrupt due to non-atomic update of IRR

   - Use GFP_KERNEL_ACCOUNT for pid_table in ipiv

   - Make VMREAD error path play nice with noinstr

   - x86: Acquire SRCU read lock when handling fastpath MSR writes

   - Support linking rseq tests statically against glibc 2.35+

   - Fix reference count for stats file descriptors

   - Detect userspace setting invalid CR0

  Non-KVM:

   - Remove coccinelle script that has caused multiple confusion
     ("debugfs, coccinelle: check for obsolete DEFINE_SIMPLE_ATTRIBUTE()
     usage", acked by Greg)"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (21 commits)
  KVM: selftests: Expand x86's sregs test to cover illegal CR0 values
  KVM: VMX: Don't fudge CR0 and CR4 for restricted L2 guest
  KVM: x86: Disallow KVM_SET_SREGS{2} if incoming CR0 is invalid
  Revert "debugfs, coccinelle: check for obsolete DEFINE_SIMPLE_ATTRIBUTE() usage"
  KVM: selftests: Verify stats fd is usable after VM fd has been closed
  KVM: selftests: Verify stats fd can be dup()'d and read
  KVM: selftests: Verify userspace can create "redundant" binary stats files
  KVM: selftests: Explicitly free vcpus array in binary stats test
  KVM: selftests: Clean up stats fd in common stats_test() helper
  KVM: selftests: Use pread() to read binary stats header
  KVM: Grab a reference to KVM for VM and vCPU stats file descriptors
  selftests/rseq: Play nice with binaries statically linked against glibc 2.35+
  Revert "KVM: SVM: Skip WRMSR fastpath on VM-Exit if next RIP isn't valid"
  KVM: x86: Acquire SRCU read lock when handling fastpath MSR writes
  KVM: VMX: Use vmread_error() to report VM-Fail in "goto" path
  KVM: VMX: Make VMREAD error path play nice with noinstr
  KVM: x86/irq: Conditionally register IRQ bypass consumer again
  KVM: X86: Use GFP_KERNEL_ACCOUNT for pid_table in ipiv
  KVM: x86: check the kvm_cpu_get_interrupt result before using it
  KVM: x86: VMX: set irr_pending in kvm_apic_update_irr
  ...