armbian/linux-cix
0
0
Fork 0
mirror of https://github.com/armbian/linux-cix.git synced 2026-01-06 12:30:45 -08:00
Code Issues Packages Projects Releases Wiki Activity

Merge tag 'usb-6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

Browse Source 
Pull USB / Thunderbolt / PHY driver updates from Greg KH:
 "Here is the big set of USB, Thunderbolt, and PHY driver updates for
  6.6-rc1. Included in here are:

   - PHY driver additions and cleanups

   - Thunderbolt minor additions and fixes

   - USB MIDI 2 gadget support added

   - dwc3 driver updates and additions

   - Removal of some old USB wireless code that was missed when that
     codebase was originally removed a few years ago, cleaning up some
     core USB code paths

   - USB core potential use-after-free fixes that syzbot from different
     people/groups keeps tripping over

   - typec updates and additions

   - gadget fixes and cleanups

   - loads of smaller USB core and driver cleanups all over the place

  Full details are in the shortlog. All of these have been in linux-next
  for a while with no reported problems"

* tag 'usb-6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (154 commits)
  platform/chrome: cros_ec_typec: Configure Retimer cable type
  tcpm: Avoid soft reset when partner does not support get_status
  usb: typec: tcpm: reset counter when enter into unattached state after try role
  usb: typec: tcpm: set initial svdm version based on pd revision
  USB: serial: option: add FOXCONN T99W368/T99W373 product
  USB: serial: option: add Quectel EM05G variant (0x030e)
  usb: dwc2: add pci_device_id driver_data parse support
  usb: gadget: remove max support speed info in bind operation
  usb: gadget: composite: cleanup function config_ep_by_speed_and_alt()
  usb: gadget: config: remove max speed check in usb_assign_descriptors()
  usb: gadget: unconditionally allocate hs/ss descriptor in bind operation
  usb: gadget: f_uvc: change endpoint allocation in uvc_function_bind()
  usb: gadget: add a inline function gether_bitrate()
  usb: gadget: use working speed to calcaulate network bitrate and qlen
  dt-bindings: usb: samsung,exynos-dwc3: Add Exynos850 support
  usb: dwc3: exynos: Add support for Exynos850 variant
  usb: gadget: udc-xilinx: fix incorrect type in assignment warning
  usb: gadget: udc-xilinx: fix cast from restricted __le16 warning
  usb: gadget: udc-xilinx: fix restricted __le16 degrades to integer warning
  USB: dwc2: hande irq on dead controller correctly
  ...
This commit is contained in:
Linus Torvalds
2023-09-01 09:23:34 -07:00
parent e2c874f999 895ed7eb26
commit 51e7accbe8
211 changed files with 7352 additions and 1890 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
CREDITS
View File

@@ -666,11 +666,6 @@ S: Tamsui town, Taipei county,
S: Taiwan 251
S: Republic of China
N: Reinette Chatre
E: reinette.chatre@intel.com
D: WiMedia Link Protocol implementation
D: UWB stack bits and pieces
N: Michael Elizabeth Chastain
E: mec@shout.net
D: Configure, Menuconfig, xconfig
@@ -3023,12 +3018,6 @@ S: Demonstratsii 8-382
S: Tula 300000
S: Russia
N: Inaky Perez-Gonzalez
E: inaky.perez-gonzalez@intel.com
D: UWB stack, HWA-RC driver and HWA-HC drivers
D: Wireless USB additions to the USB stack
D: WiMedia Link Protocol bits and pieces
N: Gordon Peters
E: GordPeters@smarttech.com
D: Isochronous receive for IEEE 1394 driver (OHCI module).

54
Documentation/ABI/testing/configfs-usb-gadget-midi2 Normal file
View File

@@ -0,0 +1,54 @@
What: /config/usb-gadget/gadget/functions/midi2.name
Date: Jul 2023
KernelVersion: 6.6
Description:
The attributes:
============ ===============================================
process_ump Flag to process UMP Stream messages (0 or 1)
static_block Flag for static blocks (0 or 1)
iface_name MIDI interface name string
============ ===============================================
What: /config/usb-gadget/gadget/functions/midi2.name/ep.number
Date: Jul 2023
KernelVersion: 6.6
Description:
This group contains a UMP Endpoint configuration.
A new Endpoint starts from 0, and can be up to 3.
The attributes:
============= ===============================================
protocol_caps MIDI protocol capabilities (1, 2 or 3 for both)
protocol Default MIDI protocol (1 or 2)
ep_name UMP Endpoint name string
product_id Product ID string
manufacturer Manufacture ID (24 bit)
family Device family ID (16 bit)
model Device model ID (16 bit)
sw_revision Software Revision (32 bit)
============= ===============================================
What: /config/usb-gadget/gadget/functions/midi2.name/ep.number/block.number
Date: Jul 2023
KernelVersion: 6.6
Description:
This group contains a UMP Function Block configuration.
A new block starts from 0, and can be up to 31.
The attributes:
================= ==============================================
name Function Block name string
direction 1: input, 2: output, 3: bidirectional
first_group The first UMP Group number (0-15)
num_groups The number of groups in this FB (1-16)
midi1_first_group The first UMP Group number for MIDI 1.0 (0-15)
midi1_num_groups The number of groups for MIDI 1.0 (0-16)
ui_hint 0: unknown, 1: receiver, 2: sender, 3: both
midi_ci_verison Supported MIDI-CI version number (8 bit)
is_midi1 Legacy MIDI 1.0 device (0, 1 or 2)
sysex8_streams Max number of SysEx8 streams (8 bit)
active Active FB flag (0 or 1)
================= ==============================================

38
Documentation/ABI/testing/sysfs-bus-thunderbolt
View File

@@ -1,7 +1,7 @@
What: /sys/bus/thunderbolt/devices/.../domainX/boot_acl
Date: Jun 2018
KernelVersion: 4.17
Contact: thunderbolt-software@lists.01.org
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: Holds a comma separated list of device unique_ids that
are allowed to be connected automatically during system
startup (e.g boot devices). The list always contains
@@ -33,7 +33,7 @@ Description: This attribute tells whether the system supports
What: /sys/bus/thunderbolt/devices/.../domainX/iommu_dma_protection
Date: Mar 2019
KernelVersion: 4.21
Contact: thunderbolt-software@lists.01.org
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute tells whether the system uses IOMMU
for DMA protection. Value of 1 means IOMMU is used 0 means
it is not (DMA protection is solely based on Thunderbolt
@@ -42,7 +42,7 @@ Description: This attribute tells whether the system uses IOMMU
What: /sys/bus/thunderbolt/devices/.../domainX/security
Date: Sep 2017
KernelVersion: 4.13
Contact: thunderbolt-software@lists.01.org
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute holds current Thunderbolt security level
set by the system BIOS. Possible values are:
@@ -64,7 +64,7 @@ Description: This attribute holds current Thunderbolt security level
What: /sys/bus/thunderbolt/devices/.../authorized
Date: Sep 2017
KernelVersion: 4.13
Contact: thunderbolt-software@lists.01.org
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute is used to authorize Thunderbolt devices
after they have been connected. If the device is not
authorized, no PCIe devices are available to the system.
@@ -98,7 +98,7 @@ Description: This attribute is used to authorize Thunderbolt devices
What: /sys/bus/thunderbolt/devices/.../boot
Date: Jun 2018
KernelVersion: 4.17
Contact: thunderbolt-software@lists.01.org
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute contains 1 if Thunderbolt device was already
authorized on boot and 0 otherwise.
@@ -113,7 +113,7 @@ Description: This attribute contains the generation of the Thunderbolt
What: /sys/bus/thunderbolt/devices/.../key
Date: Sep 2017
KernelVersion: 4.13
Contact: thunderbolt-software@lists.01.org
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: When a devices supports Thunderbolt secure connect it will
have this attribute. Writing 32 byte hex string changes
authorization to use the secure connection method instead.
@@ -123,14 +123,14 @@ Description: When a devices supports Thunderbolt secure connect it will
What: /sys/bus/thunderbolt/devices/.../device
Date: Sep 2017
KernelVersion: 4.13
Contact: thunderbolt-software@lists.01.org
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute contains id of this device extracted from
the device DROM.
What: /sys/bus/thunderbolt/devices/.../device_name
Date: Sep 2017
KernelVersion: 4.13
Contact: thunderbolt-software@lists.01.org
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute contains name of this device extracted from
the device DROM.
@@ -172,21 +172,21 @@ Description: This attribute reports number of TX lanes the device is
What: /sys/bus/thunderbolt/devices/.../vendor
Date: Sep 2017
KernelVersion: 4.13
Contact: thunderbolt-software@lists.01.org
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute contains vendor id of this device extracted
from the device DROM.
What: /sys/bus/thunderbolt/devices/.../vendor_name
Date: Sep 2017
KernelVersion: 4.13
Contact: thunderbolt-software@lists.01.org
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute contains vendor name of this device extracted
from the device DROM.
What: /sys/bus/thunderbolt/devices/.../unique_id
Date: Sep 2017
KernelVersion: 4.13
Contact: thunderbolt-software@lists.01.org
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute contains unique_id string of this device.
This is either read from hardware registers (UUID on
newer hardware) or based on UID from the device DROM.
@@ -195,7 +195,7 @@ Description: This attribute contains unique_id string of this device.
What: /sys/bus/thunderbolt/devices/.../nvm_version
Date: Sep 2017
KernelVersion: 4.13
Contact: thunderbolt-software@lists.01.org
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: If the device has upgradeable firmware the version
number is available here. Format: %x.%x, major.minor.
If the device is in safe mode reading the file returns
@@ -204,7 +204,7 @@ Description: If the device has upgradeable firmware the version
What: /sys/bus/thunderbolt/devices/.../nvm_authenticate
Date: Sep 2017
KernelVersion: 4.13
Contact: thunderbolt-software@lists.01.org
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: When new NVM image is written to the non-active NVM
area (through non_activeX NVMem device), the
authentication procedure is started by writing to
@@ -246,7 +246,7 @@ Description: For supported devices, automatically authenticate the new Thunderbo
What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/key
Date: Jan 2018
KernelVersion: 4.15
Contact: thunderbolt-software@lists.01.org
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This contains name of the property directory the XDomain
service exposes. This entry describes the protocol in
question. Following directories are already reserved by
@@ -261,35 +261,35 @@ Description: This contains name of the property directory the XDomain
What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/modalias
Date: Jan 2018
KernelVersion: 4.15
Contact: thunderbolt-software@lists.01.org
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: Stores the same MODALIAS value emitted by uevent for
the XDomain service. Format: tbtsvc:kSpNvNrN
What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/prtcid
Date: Jan 2018
KernelVersion: 4.15
Contact: thunderbolt-software@lists.01.org
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This contains XDomain protocol identifier the XDomain
service supports.
What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/prtcvers
Date: Jan 2018
KernelVersion: 4.15
Contact: thunderbolt-software@lists.01.org
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This contains XDomain protocol version the XDomain
service supports.
What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/prtcrevs
Date: Jan 2018
KernelVersion: 4.15
Contact: thunderbolt-software@lists.01.org
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This contains XDomain software version the XDomain
service supports.
What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/prtcstns
Date: Jan 2018
KernelVersion: 4.15
Contact: thunderbolt-software@lists.01.org
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This contains XDomain service specific settings as
bitmask. Format: %x

28
Documentation/ABI/testing/sysfs-bus-umc
View File

@@ -1,28 +0,0 @@
What: /sys/bus/umc/
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The Wireless Host Controller Interface (WHCI)
specification describes a PCI-based device with
multiple capabilities; the UWB Multi-interface
Controller (UMC).
The umc bus presents each of the individual
capabilities as a device.
What: /sys/bus/umc/devices/.../capability_id
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The ID of this capability, with 0 being the radio
controller capability.
What: /sys/bus/umc/devices/.../version
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The specification version this capability's hardware
interface complies with.

34
Documentation/ABI/testing/sysfs-bus-usb
View File

@@ -28,40 +28,6 @@ Description:
drivers, non-authorized one are not. By default, wired
USB devices are authorized.
Certified Wireless USB devices are not authorized
initially and should be (by writing 1) after the
device has been authenticated.
What: /sys/bus/usb/device/.../wusb_cdid
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
For Certified Wireless USB devices only.
A devices's CDID, as 16 space-separated hex octets.
What: /sys/bus/usb/device/.../wusb_ck
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
For Certified Wireless USB devices only.
Write the device's connection key (CK) to start the
authentication of the device. The CK is 16
space-separated hex octets.
What: /sys/bus/usb/device/.../wusb_disconnect
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
For Certified Wireless USB devices only.
Write a 1 to force the device to disconnect
(equivalent to unplugging a wired USB device).
What: /sys/bus/usb/drivers/.../new_id
Date: October 2011
Contact: linux-usb@vger.kernel.org

156
Documentation/ABI/testing/sysfs-class-uwb_rc
View File

@@ -1,156 +0,0 @@
What: /sys/class/uwb_rc
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
Interfaces for WiMedia Ultra Wideband Common Radio
Platform (UWB) radio controllers.
Familiarity with the ECMA-368 'High Rate Ultra
Wideband MAC and PHY Specification' is assumed.
What: /sys/class/uwb_rc/beacon_timeout_ms
Date: July 2008
KernelVersion: 2.6.27
Description:
If no beacons are received from a device for at least
this time, the device will be considered to have gone
and it will be removed. The default is 3 superframes
(~197 ms) as required by the specification.
What: /sys/class/uwb_rc/uwb<N>/
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
An individual UWB radio controller.
What: /sys/class/uwb_rc/uwb<N>/beacon
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
Write:
<channel>
to force a specific channel to be used when beaconing,
or, if <channel> is -1, to prohibit beaconing. If
<channel> is 0, then the default channel selection
algorithm will be used. Valid channels depends on the
radio controller's supported band groups.
Reading returns the currently active channel, or -1 if
the radio controller is not beaconing.
What: /sys/class/uwb_rc/uwb<N>/ASIE
Date: August 2014
KernelVersion: 3.18
Contact: linux-usb@vger.kernel.org
Description:
The application-specific information element (ASIE)
included in this device's beacon, in space separated
hex octets.
Reading returns the current ASIE. Writing replaces
the current ASIE with the one written.
What: /sys/class/uwb_rc/uwb<N>/scan
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
Write:
<channel> <type> [<bpst offset>]
to start (or stop) scanning on a channel. <type> is one of:
== =======================================
0 scan
1 scan outside BP
2 scan while inactive
3 scanning disabled
4 scan (with start time of <bpst offset>)
== =======================================
What: /sys/class/uwb_rc/uwb<N>/mac_address
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
The EUI-48, in colon-separated hex octets, for this
radio controller. A write will change the radio
controller's EUI-48 but only do so while the device is
not beaconing or scanning.
What: /sys/class/uwb_rc/uwb<N>/wusbhc
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
A symlink to the device (if any) of the WUSB Host
Controller PAL using this radio controller.
What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
A neighbour UWB device that has either been detected
as part of a scan or is a member of the radio
controllers beacon group.
What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/BPST
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
The time (using the radio controllers internal 1 ms
interval superframe timer) of the last beacon from
this device was received.
What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/DevAddr
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
The current DevAddr of this device in colon separated
hex octets.
What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/EUI_48
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
The EUI-48 of this device in colon separated hex
octets.
What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/IEs
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
The latest IEs included in this device's beacon, in
space separated hex octets with one IE per line.
What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/LQE
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
Link Quality Estimate - the Signal to Noise Ratio
(SNR) of all packets received from this device in dB.
This gives an estimate on a suitable PHY rate. Refer
to [ECMA-368] section 13.3 for more details.
What: /sys/class/uwb_rc/uwb<N>/<EUI-48>/RSSI
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
Received Signal Strength Indication - the strength of
the received signal in dB. LQE is a more useful
measure of the radio link quality.

57
Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc
View File

@@ -1,57 +0,0 @@
What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_chid
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
Write the CHID (16 space-separated hex octets) for this host controller.
This starts the host controller, allowing it to accept connection from
WUSB devices.
Set an all zero CHID to stop the host controller.
What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_trust_timeout
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
Devices that haven't sent a WUSB packet to the host
within 'wusb_trust_timeout' ms are considered to have
disconnected and are removed. The default value of
4000 ms is the value required by the WUSB
specification.
Since this relates to security (specifically, the
lifetime of PTKs and GTKs) it should not be changed
from the default.
What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_phy_rate
Date: August 2009
KernelVersion: 2.6.32
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The maximum PHY rate to use for all connected devices.
This is only of limited use for testing and
development as the hardware's automatic rate
adaptation is better then this simple control.
Refer to [ECMA-368] section 10.3.1.1 for the value to
use.
What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_dnts
Date: June 2013
KernelVersion: 3.11
Contact: Thomas Pugliese <thomas.pugliese@gmail.com>
Description:
The device notification time slot (DNTS) count and interval in
milliseconds that the WUSB host should use. This controls how
often the devices will have the opportunity to send
notifications to the host.
What: /sys/class/uwb_rc/uwb<N>/wusbhc/wusb_retry_count
Date: June 2013
KernelVersion: 3.11
Contact: Thomas Pugliese <thomas.pugliese@gmail.com>
Description:
The number of retries that the WUSB host should attempt
before reporting an error for a bus transaction. The range of
valid values is [0..15], where 0 indicates infinite retries.

101
Documentation/ABI/testing/sysfs-wusb_cbaf
View File

@@ -1,101 +0,0 @@
What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_*
Date: August 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
Various files for managing Cable Based Association of
(wireless) USB devices.
The sequence of operations should be:
1. Device is plugged in.
2. The connection manager (CM) sees a device with CBA capability.
(the wusb_chid etc. files in /sys/devices/blah/OURDEVICE).
3. The CM writes the host name, supported band groups,
and the CHID (host ID) into the wusb_host_name,
wusb_host_band_groups and wusb_chid files. These
get sent to the device and the CDID (if any) for
this host is requested.
4. The CM can verify that the device's supported band
groups (wusb_device_band_groups) are compatible
with the host.
5. The CM reads the wusb_cdid file.
6. The CM looks it up its database.
- If it has a matching CHID,CDID entry, the device
has been authorized before and nothing further
needs to be done.
- If the CDID is zero (or the CM doesn't find a
matching CDID in its database), the device is
assumed to be not known. The CM may associate
the host with device by: writing a randomly
generated CDID to wusb_cdid and then a random CK
to wusb_ck (this uploads the new CC to the
device).
CMD may choose to prompt the user before
associating with a new device.
7. Device is unplugged.
References:
[WUSB-AM]
Association Models Supplement to the
Certified Wireless Universal Serial Bus
Specification, version 1.0.
What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_chid
Date: August 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The CHID of the host formatted as 16 space-separated
hex octets.
Writes fetches device's supported band groups and the
the CDID for any existing association with this host.
What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_host_name
Date: August 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
A friendly name for the host as a UTF-8 encoded string.
What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_host_band_groups
Date: August 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The band groups supported by the host, in the format
defined in [WUSB-AM].
What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_device_band_groups
Date: August 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The band groups supported by the device, in the format
defined in [WUSB-AM].
What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_cdid
Date: August 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The device's CDID formatted as 16 space-separated hex
octets.
What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_ck
Date: August 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
Write 16 space-separated random, hex octets to
associate with the device.

2
Documentation/admin-guide/kernel-parameters.txt
View File

@@ -6719,7 +6719,7 @@
usbcore.authorized_default=
[USB] Default USB device authorization:
(default -1 = authorized except for wireless USB,
(default -1 = authorized (same as 1),
0 = not authorized, 1 = authorized, 2 = authorized
if device connected to internal port)

175
Documentation/devicetree/bindings/phy/realtek,usb2phy.yaml Normal file
View File

@@ -0,0 +1,175 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright 2023 Realtek Semiconductor Corporation
%YAML 1.2
---
$id: http://devicetree.org/schemas/phy/realtek,usb2phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Realtek DHC SoCs USB 2.0 PHY
maintainers:
- Stanley Chang <stanley_chang@realtek.com>
description: |
Realtek USB 2.0 PHY support the digital home center (DHC) RTD series SoCs.
The USB 2.0 PHY driver is designed to support the XHCI controller. The SoCs
support multiple XHCI controllers. One PHY device node maps to one XHCI
controller.
RTD1295/RTD1619 SoCs USB
The USB architecture includes three XHCI controllers.
Each XHCI maps to one USB 2.0 PHY and map one USB 3.0 PHY on some
controllers.
XHCI controller#0 -- usb2phy -- phy#0
|- usb3phy -- phy#0
XHCI controller#1 -- usb2phy -- phy#0
XHCI controller#2 -- usb2phy -- phy#0
|- usb3phy -- phy#0
RTD1395 SoCs USB
The USB architecture includes two XHCI controllers.
The controller#0 has one USB 2.0 PHY. The controller#1 includes two USB 2.0
PHY.
XHCI controller#0 -- usb2phy -- phy#0
XHCI controller#1 -- usb2phy -- phy#0
|- phy#1
RTD1319/RTD1619b SoCs USB
The USB architecture includes three XHCI controllers.
Each XHCI maps to one USB 2.0 PHY and map one USB 3.0 PHY on controllers#2.
XHCI controller#0 -- usb2phy -- phy#0
XHCI controller#1 -- usb2phy -- phy#0
XHCI controller#2 -- usb2phy -- phy#0
|- usb3phy -- phy#0
RTD1319d SoCs USB
The USB architecture includes three XHCI controllers.
Each xhci maps to one USB 2.0 PHY and map one USB 3.0 PHY on controllers#0.
XHCI controller#0 -- usb2phy -- phy#0
|- usb3phy -- phy#0
XHCI controller#1 -- usb2phy -- phy#0
XHCI controller#2 -- usb2phy -- phy#0
RTD1312c/RTD1315e SoCs USB
The USB architecture includes three XHCI controllers.
Each XHCI maps to one USB 2.0 PHY.
XHCI controller#0 -- usb2phy -- phy#0
XHCI controller#1 -- usb2phy -- phy#0
XHCI controller#2 -- usb2phy -- phy#0
properties:
compatible:
enum:
- realtek,rtd1295-usb2phy
- realtek,rtd1312c-usb2phy
- realtek,rtd1315e-usb2phy
- realtek,rtd1319-usb2phy
- realtek,rtd1319d-usb2phy
- realtek,rtd1395-usb2phy
- realtek,rtd1395-usb2phy-2port
- realtek,rtd1619-usb2phy
- realtek,rtd1619b-usb2phy
reg:
items:
- description: PHY data registers
- description: PHY control registers
"#phy-cells":
const: 0
nvmem-cells:
maxItems: 2
description:
Phandles to nvmem cell that contains the trimming data.
If unspecified, default value is used.
nvmem-cell-names:
items:
- const: usb-dc-cal
- const: usb-dc-dis
description:
The following names, which correspond to each nvmem-cells.
usb-dc-cal is the driving level for each phy specified via efuse.
usb-dc-dis is the disconnection level for each phy specified via efuse.
realtek,inverse-hstx-sync-clock:
description:
For one of the phys of RTD1619b SoC, the synchronous clock of the
high-speed tx must be inverted.
type: boolean
realtek,driving-level:
description:
Control the magnitude of High speed Dp/Dm output swing (mV).
For a different board or port, the original magnitude maybe not meet
the specification. In this situation we can adjust the value to meet
the specification.
$ref: /schemas/types.yaml#/definitions/uint32
default: 8
minimum: 0
maximum: 31
realtek,driving-level-compensate:
description:
For RTD1315e SoC, the driving level can be adjusted by reading the
efuse table. This property provides drive compensation.
If the magnitude of High speed Dp/Dm output swing still not meet the
specification, then we can set this value to meet the specification.
$ref: /schemas/types.yaml#/definitions/int32
default: 0
minimum: -8
maximum: 8
realtek,disconnection-compensate:
description:
This adjusts the disconnection level compensation for the different
boards with different disconnection level.
$ref: /schemas/types.yaml#/definitions/int32
default: 0
minimum: -8
maximum: 8
required:
- compatible
- reg
- "#phy-cells"
allOf:
- if:
not:
properties:
compatible:
contains:
enum:
- realtek,rtd1619b-usb2phy
then:
properties:
realtek,inverse-hstx-sync-clock: false
- if:
not:
properties:
compatible:
contains:
enum:
- realtek,rtd1315e-usb2phy
then:
properties:
realtek,driving-level-compensate: false
additionalProperties: false
examples:
- |
usb-phy@13214 {
compatible = "realtek,rtd1619b-usb2phy";
reg = <0x13214 0x4>, <0x28280 0x4>;
#phy-cells = <0>;
nvmem-cells = <&otp_usb_port0_dc_cal>, <&otp_usb_port0_dc_dis>;
nvmem-cell-names = "usb-dc-cal", "usb-dc-dis";
realtek,inverse-hstx-sync-clock;
realtek,driving-level = <0xa>;
realtek,disconnection-compensate = <(-1)>;
};

107
Documentation/devicetree/bindings/phy/realtek,usb3phy.yaml Normal file
View File

@@ -0,0 +1,107 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright 2023 Realtek Semiconductor Corporation
%YAML 1.2
---
$id: http://devicetree.org/schemas/phy/realtek,usb3phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Realtek DHC SoCs USB 3.0 PHY
maintainers:
- Stanley Chang <stanley_chang@realtek.com>
description: |
Realtek USB 3.0 PHY support the digital home center (DHC) RTD series SoCs.
The USB 3.0 PHY driver is designed to support the XHCI controller. The SoCs
support multiple XHCI controllers. One PHY device node maps to one XHCI
controller.
RTD1295/RTD1619 SoCs USB
The USB architecture includes three XHCI controllers.
Each XHCI maps to one USB 2.0 PHY and map one USB 3.0 PHY on some
controllers.
XHCI controller#0 -- usb2phy -- phy#0
|- usb3phy -- phy#0
XHCI controller#1 -- usb2phy -- phy#0
XHCI controller#2 -- usb2phy -- phy#0
|- usb3phy -- phy#0
RTD1319/RTD1619b SoCs USB
The USB architecture includes three XHCI controllers.
Each XHCI maps to one USB 2.0 PHY and map one USB 3.0 PHY on controllers#2.
XHCI controller#0 -- usb2phy -- phy#0
XHCI controller#1 -- usb2phy -- phy#0
XHCI controller#2 -- usb2phy -- phy#0
|- usb3phy -- phy#0
RTD1319d SoCs USB
The USB architecture includes three XHCI controllers.
Each xhci maps to one USB 2.0 PHY and map one USB 3.0 PHY on controllers#0.
XHCI controller#0 -- usb2phy -- phy#0
|- usb3phy -- phy#0
XHCI controller#1 -- usb2phy -- phy#0
XHCI controller#2 -- usb2phy -- phy#0
properties:
compatible:
enum:
- realtek,rtd1295-usb3phy
- realtek,rtd1319-usb3phy
- realtek,rtd1319d-usb3phy
- realtek,rtd1619-usb3phy
- realtek,rtd1619b-usb3phy
reg:
maxItems: 1
"#phy-cells":
const: 0
nvmem-cells:
maxItems: 1
description: A phandle to the tx lfps swing trim data provided by
a nvmem device, if unspecified, default values shall be used.
nvmem-cell-names:
items:
- const: usb_u3_tx_lfps_swing_trim
realtek,amplitude-control-coarse-tuning:
description:
This adjusts the signal amplitude for normal operation and beacon LFPS.
This value is a parameter for coarse tuning.
For different boards, if the default value is inappropriate, this
property can be assigned to adjust.
$ref: /schemas/types.yaml#/definitions/uint32
default: 255
minimum: 0
maximum: 255
realtek,amplitude-control-fine-tuning:
description:
This adjusts the signal amplitude for normal operation and beacon LFPS.
This value is used for fine-tuning parameters.
$ref: /schemas/types.yaml#/definitions/uint32
default: 65535
minimum: 0
maximum: 65535
required:
- compatible
- reg
- "#phy-cells"
additionalProperties: false
examples:
- |
usb-phy@13e10 {
compatible = "realtek,rtd1319d-usb3phy";
reg = <0x13e10 0x4>;
#phy-cells = <0>;
nvmem-cells = <&otp_usb_u3_tx_lfps_swing_trim>;
nvmem-cell-names = "usb_u3_tx_lfps_swing_trim";
realtek,amplitude-control-coarse-tuning = <0x77>;
};

17
Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
View File

@@ -34,6 +34,7 @@ properties:
- fsl,imx23-usb
- fsl,imx25-usb
- fsl,imx28-usb
- fsl,imx35-usb
- fsl,imx50-usb
- fsl,imx51-usb
- fsl,imx53-usb
@@ -76,11 +77,11 @@ properties:
clocks:
minItems: 1
maxItems: 2
maxItems: 3
clock-names:
minItems: 1
maxItems: 2
maxItems: 3
dr_mode: true
@@ -292,6 +293,18 @@ properties:
minimum: 0x0
maximum: 0xf
fsl,picophy-rise-fall-time-adjust:
description:
HS Transmitter Rise/Fall Time Adjustment. Adjust the rise/fall times
of the high-speed transmitter waveform. It has no unit. The rise/fall
time will be increased or decreased by a certain percentage relative
to design default time. (0:-10%; 1:design default; 2:+15%; 3:+20%)
Details can refer to TXRISETUNE0 bit of USBNC_n_PHY_CFG1.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3
default: 1
usb-phy:
description: phandle for the PHY device. Use "phys" instead.
$ref: /schemas/types.yaml#/definitions/phandle

77
Documentation/devicetree/bindings/usb/cypress,hx3.yaml Normal file
View File

@@ -0,0 +1,77 @@
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/usb/cypress,hx3.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Cypress HX3 USB 3.0 hub controller family
maintainers:
- Benjamin Bara <benjamin.bara@skidata.com>
allOf:
- $ref: usb-device.yaml#
properties:
compatible:
enum:
- usb4b4,6504
- usb4b4,6506
reg: true
reset-gpios:
items:
- description: GPIO specifier for RESETN pin.
vdd-supply:
description:
1V2 power supply (VDD_EFUSE, AVDD12, DVDD12).
vdd2-supply:
description:
3V3 power supply (AVDD33, VDD_IO).
peer-hub:
$ref: /schemas/types.yaml#/definitions/phandle
description:
phandle to the peer hub on the controller.
required:
- compatible
- reg
- peer-hub
- vdd-supply
- vdd2-supply
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
usb {
dr_mode = "host";
#address-cells = <1>;
#size-cells = <0>;
/* 2.0 hub on port 1 */
hub_2_0: hub@1 {
compatible = "usb4b4,6504";
reg = <1>;
peer-hub = <&hub_3_0>;
reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>;
vdd-supply = <&reg_1v2_usb>;
vdd2-supply = <&reg_3v3_usb>;
};
/* 3.0 hub on port 2 */
hub_3_0: hub@2 {
compatible = "usb4b4,6506";
reg = <2>;
peer-hub = <&hub_2_0>;
reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>;
vdd-supply = <&reg_1v2_usb>;
vdd2-supply = <&reg_3v3_usb>;
};
};

1
Documentation/devicetree/bindings/usb/generic-ehci.yaml
View File

@@ -68,6 +68,7 @@ properties:
- const: generic-ehci
- items:
- enum:
- atmel,at91sam9g45-ehci
- cavium,octeon-6335-ehci
- ibm,usb-ehci-440epx
- ibm,usb-ehci-460ex

1
Documentation/devicetree/bindings/usb/genesys,gl850g.yaml
View File

@@ -17,6 +17,7 @@ properties:
enum:
- usb5e3,608
- usb5e3,610
- usb5e3,620
reg: true

36
Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
View File

@@ -14,6 +14,7 @@ properties:
items:
- enum:
- qcom,ipq4019-dwc3
- qcom,ipq5332-dwc3
- qcom,ipq6018-dwc3
- qcom,ipq8064-dwc3
- qcom,ipq8074-dwc3
@@ -82,15 +83,6 @@ properties:
minItems: 1
maxItems: 9
assigned-clocks:
items:
- description: Phandle and clock specifier of MOCK_UTMI_CLK.
- description: Phandle and clock specifoer of MASTER_CLK.
assigned-clock-rates:
items:
- description: Must be 19.2MHz (19200000).
- description: Must be >= 60 MHz in HS mode, >= 125 MHz in SS mode.
resets:
maxItems: 1
@@ -246,6 +238,7 @@ allOf:
compatible:
contains:
enum:
- qcom,ipq5332-dwc3
- qcom,msm8994-dwc3
- qcom,qcs404-dwc3
then:
@@ -290,15 +283,23 @@ allOf:
then:
properties:
clocks:
minItems: 6
minItems: 5
maxItems: 6
clock-names:
items:
- const: cfg_noc
- const: core
- const: iface
- const: sleep
- const: mock_utmi
- const: bus
oneOf:
- items:
- const: cfg_noc
- const: core
- const: iface
- const: sleep
- const: mock_utmi
- const: bus
- items:
- const: cfg_noc
- const: core
- const: sleep
- const: mock_utmi
- const: bus
- if:
properties:
@@ -410,6 +411,7 @@ allOf:
compatible:
contains:
enum:
- qcom,ipq5332-dwc3
- qcom,sdm660-dwc3
then:
properties:

20
Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml
View File

@@ -15,6 +15,7 @@ properties:
- samsung,exynos5250-dwusb3
- samsung,exynos5433-dwusb3
- samsung,exynos7-dwusb3
- samsung,exynos850-dwusb3
'#address-cells':
const: 1
@@ -72,7 +73,7 @@ allOf:
properties:
compatible:
contains:
const: samsung,exynos54333-dwusb3
const: samsung,exynos5433-dwusb3
then:
properties:
clocks:
@@ -82,8 +83,8 @@ allOf:
items:
- const: aclk
- const: susp_clk
- const: pipe_pclk
- const: phyclk
- const: pipe_pclk
- if:
properties:
@@ -101,6 +102,21 @@ allOf:
- const: usbdrd30_susp_clk
- const: usbdrd30_axius_clk
- if:
properties:
compatible:
contains:
const: samsung,exynos850-dwusb3
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: bus_early
- const: ref
additionalProperties: false
examples:

9
Documentation/driver-api/usb/usb.rst
View File

@@ -420,6 +420,12 @@ USBDEVFS_CONNECTINFO
know the devnum value already, it's the DDD value of the device file
name.
USBDEVFS_GET_SPEED
Returns the speed of the device. The speed is returned as a
nummerical value in accordance with enum usb_device_speed
File modification time is not updated by this request.
USBDEVFS_GETDRIVER
Returns the name of the kernel driver bound to a given interface (a
string). Parameter is a pointer to this structure, which is
@@ -771,8 +777,7 @@ Speed may be:
======= ======================================================
1.5 Mbit/s for low speed USB
12 Mbit/s for full speed USB
480 Mbit/s for high speed USB (added for USB 2.0);
also used for Wireless USB, which has no fixed speed
480 Mbit/s for high speed USB (added for USB 2.0)
5000 Mbit/s for SuperSpeed USB (added for USB 3.0)
======= ======================================================

9
Documentation/usb/authorization.rst
View File

@@ -33,12 +33,9 @@ Remove the lock down::
$ echo 1 > /sys/bus/usb/devices/usbX/authorized_default
By default, Wired USB devices are authorized by default to
connect. Wireless USB hosts deauthorize by default all new connected
devices (this is so because we need to do an authentication phase
before authorizing). Writing "2" to the authorized_default attribute
causes kernel to only authorize by default devices connected to internal
USB ports.
By default, all USB devices are authorized. Writing "2" to the
authorized_default attribute causes the kernel to authorize by default
only devices connected to internal USB ports.
Example system lockdown (lame)

154
Documentation/usb/gadget-testing.rst
View File

@@ -27,6 +27,7 @@ provided by gadgets.
18. UVC function
19. PRINTER function
20. UAC1 function (new API)
21. MIDI2 function
1. ACM function
@@ -965,3 +966,156 @@ e.g.::
$ arecord -f dat -t wav -D hw:CARD=UAC1Gadget,DEV=0 | \
aplay -D default:CARD=OdroidU3
21. MIDI2 function
==================
The function is provided by usb_f_midi2.ko module.
It will create a virtual ALSA card containing a UMP rawmidi device
where the UMP packet is looped back. In addition, a legacy rawmidi
device is created. The UMP rawmidi is bound with ALSA sequencer
clients, too.
Function-specific configfs interface
------------------------------------
The function name to use when creating the function directory is "midi2".
The midi2 function provides these attributes in its function directory
as the card top-level information:
============= =================================================
process_ump Bool flag to process UMP Stream messages (0 or 1)
static_block Bool flag for static blocks (0 or 1)
iface_name Optional interface name string
============= =================================================
The directory contains a subdirectory "ep.0", and this provides the
attributes for a UMP Endpoint (which is a pair of USB MIDI Endpoints):
============= =================================================
protocol_caps MIDI protocol capabilities;
1: MIDI 1.0, 2: MIDI 2.0, or 3: both protocols
protocol Default MIDI protocol (either 1 or 2)
ep_name UMP Endpoint name string
product_id Product ID string
manufacturer Manufacture ID number (24 bit)
family Device family ID number (16 bit)
model Device model ID number (16 bit)
sw_revision Software revision (32 bit)
============= =================================================
Each Endpoint subdirectory contains a subdirectory "block.0", which
represents the Function Block for Block 0 information.
Its attributes are:
================= ===============================================
name Function Block name string
direction Direction of this FB
1: input, 2: output, or 3: bidirectional
first_group The first UMP Group number (0-15)
num_groups The number of groups in this FB (1-16)
midi1_first_group The first UMP Group number for MIDI 1.0 (0-15)
midi1_num_groups The number of groups for MIDI 1.0 (0-16)
ui_hint UI-hint of this FB
0: unknown, 1: receiver, 2: sender, 3: both
midi_ci_verison Supported MIDI-CI version number (8 bit)
is_midi1 Legacy MIDI 1.0 device (0-2)
0: MIDI 2.0 device,
1: MIDI 1.0 without restriction, or
2: MIDI 1.0 with low speed
sysex8_streams Max number of SysEx8 streams (8 bit)
active Bool flag for FB activity (0 or 1)
================= ===============================================
If multiple Function Blocks are required, you can add more Function
Blocks by creating subdirectories "block.<num>" with the corresponding
Function Block number (1, 2, ....). The FB subdirectories can be
dynamically removed, too. Note that the Function Block numbers must be
continuous.
Similarly, if you multiple UMP Endpoints are required, you can add
more Endpoints by creating subdirectories "ep.<num>". The number must
be continuous.
For emulating the old MIDI 2.0 device without UMP v1.1 support, pass 0
to `process_ump` flag. Then the whole UMP v1.1 requests are ignored.
Testing the MIDI2 function
--------------------------
On the device: run the gadget, and running::
$ cat /proc/asound/cards
will show a new sound card containing a MIDI2 device.
OTOH, on the host::
$ cat /proc/asound/cards
will show a new sound card containing either MIDI1 or MIDI2 device,
depending on the USB audio driver configuration.
On both, when ALSA sequencer is enabled on the host, you can find the
UMP MIDI client such as "MIDI 2.0 Gadget".
As the driver simply loops back the data, there is no need for a real
device just for testing.
For testing a MIDI input from the gadget to the host (e.g. emulating a
MIDI keyboard), you can send a MIDI stream like the following.
On the gadget::
$ aconnect -o
....
client 20: 'MIDI 2.0 Gadget' [type=kernel,card=1]
0 'MIDI 2.0 '
1 'Group 1 (MIDI 2.0 Gadget I/O)'
$ aplaymidi -p 20:1 to_host.mid
On the host::
$ aconnect -i
....
client 24: 'MIDI 2.0 Gadget' [type=kernel,card=2]
0 'MIDI 2.0 '
1 'Group 1 (MIDI 2.0 Gadget I/O)'
$ arecordmidi -p 24:1 from_gadget.mid
If you have a UMP-capable application, you can use the UMP port to
send/receive the raw UMP packets, too. For example, aseqdump program
with UMP support can receive from UMP port. On the host::
$ aseqdump -u 2 -p 24:1
Waiting for data. Press Ctrl+C to end.
Source Group Event Ch Data
24:1 Group 0, Program change 0, program 0, Bank select 0:0
24:1 Group 0, Channel pressure 0, value 0x80000000
For testing a MIDI output to the gadget to the host (e.g. emulating a
MIDI synth), it'll be just other way round.
On the gadget::
$ arecordmidi -p 20:1 from_host.mid
On the host::
$ aplaymidi -p 24:1 to_gadget.mid
The access to MIDI 1.0 on altset 0 on the host is supported, and it's
translated from/to UMP packets on the gadget. It's bound to only
Function Block 0.
The current operation mode can be observed in ALSA control element
"Operation Mode" for SND_CTL_IFACE_RAWMIDI. For example::
$ amixer -c1 contents
numid=1,iface=RAWMIDI,name='Operation Mode'
; type=INTEGER,access=r--v----,values=1,min=0,max=2,step=0
: values=2
where 0 = unused, 1 = MIDI 1.0 (altset 0), 2 = MIDI 2.0 (altset 1).
The example above shows it's running in 2, i.e. MIDI 2.0.

Some files were not shown because too many files have changed in this diff Show More