USB: Fix up terminology

USB is a HOST/DEVICE protocol, as per the specification and all
documentation.  Fix up terms that are not applicable to make things
match up with the terms used through the rest of the USB stack.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Felipe Balbi <balbi@kernel.org>
Link: https://lore.kernel.org/r/20200630174123.GA1906678@kroah.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
Greg Kroah-Hartman 2020-06-30 19:41:23 +02:00
parent 43ff98695c
commit b9b70170db
9 changed files with 29 additions and 30 deletions

View file

@ -19,9 +19,8 @@
* just a collection of helper routines that implement the
* generic USB things that the real drivers can use..
*
* Think of this as a "USB library" rather than anything else.
* It should be considered a slave, with no callbacks. Callbacks
* are evil.
* Think of this as a "USB library" rather than anything else,
* with no callbacks. Callbacks are evil.
*/
#include <linux/module.h>

View file

@ -1036,7 +1036,7 @@ struct dwc2_hregs_backup {
* @fifo_mem: Total internal RAM for FIFOs (bytes)
* @fifo_map: Each bit intend for concrete fifo. If that bit is set,
* then that fifo is used
* @gadget: Represents a usb slave device
* @gadget: Represents a usb gadget device
* @connected: Used in slave mode. True if device connected with host
* @eps_in: The IN endpoints being supplied to the gadget framework
* @eps_out: The OUT endpoints being supplied to the gadget framework

View file

@ -19,8 +19,8 @@ menuconfig USB_GADGET
select USB_COMMON
select NLS
help
USB is a master/slave protocol, organized with one master
host (such as a PC) controlling up to 127 peripheral devices.
USB is a host/device protocol, organized with one host (such as a
PC) controlling up to 127 peripheral devices.
The USB hardware is asymmetric, which makes it easier to set up:
you can't connect a "to-the-host" connector to a peripheral.

View file

@ -11,8 +11,8 @@
* can write a hardware-agnostic gadget driver running inside a USB device.
* Some hardware details are visible, but don't affect most of the driver.
*
* Use it with the Linux host/master side "usbtest" driver to get a basic
* functional test of your device-side usb stack, or with "usb-skeleton".
* Use it with the Linux host side "usbtest" driver to get a basic functional
* test of your device-side usb stack, or with "usb-skeleton".
*
* It supports two similar configurations. One sinks whatever the usb host
* writes, and in return sources zeroes. The other loops whatever the host

View file

@ -474,7 +474,7 @@ config USB_DUMMY_HCD
help
This host controller driver emulates USB, looping all data transfer
requests back to a USB "gadget driver" in the same host. The host
side is the master; the gadget side is the slave. Gadget drivers
side is the controller; the gadget side is the device. Gadget drivers
can be high, full, or low speed; and they have access to endpoints
like those from NET2280, PXA2xx, or SA1100 hardware.

View file

@ -266,8 +266,8 @@ struct bcm63xx_req {
* @pd: Platform data (board/port info).
* @usbd_clk: Clock descriptor for the USB device block.
* @usbh_clk: Clock descriptor for the USB host block.
* @gadget: USB slave device.
* @driver: Driver for USB slave devices.
* @gadget: USB device.
* @driver: Driver for USB device.
* @usbd_regs: Base address of the USBD/USB20D block.
* @iudma_regs: Base address of the USBD's associated IUDMA block.
* @bep: Array of endpoints, including ep0.
@ -1744,7 +1744,7 @@ static void bcm63xx_ep0_process(struct work_struct *w)
/**
* bcm63xx_udc_get_frame - Read current SOF frame number from the HW.
* @gadget: USB slave device.
* @gadget: USB device.
*/
static int bcm63xx_udc_get_frame(struct usb_gadget *gadget)
{
@ -1756,7 +1756,7 @@ static int bcm63xx_udc_get_frame(struct usb_gadget *gadget)
/**
* bcm63xx_udc_pullup - Enable/disable pullup on D+ line.
* @gadget: USB slave device.
* @gadget: USB device.
* @is_on: 0 to disable pullup, 1 to enable.
*
* See notes in bcm63xx_select_pullup().
@ -1805,8 +1805,8 @@ static int bcm63xx_udc_pullup(struct usb_gadget *gadget, int is_on)
/**
* bcm63xx_udc_start - Start the controller.
* @gadget: USB slave device.
* @driver: Driver for USB slave devices.
* @gadget: USB device.
* @driver: Driver for USB device.
*/
static int bcm63xx_udc_start(struct usb_gadget *gadget,
struct usb_gadget_driver *driver)
@ -1842,8 +1842,8 @@ static int bcm63xx_udc_start(struct usb_gadget *gadget,
/**
* bcm63xx_udc_stop - Shut down the controller.
* @gadget: USB slave device.
* @driver: Driver for USB slave devices.
* @gadget: USB device.
* @driver: Driver for USB device.
*/
static int bcm63xx_udc_stop(struct usb_gadget *gadget)
{

View file

@ -85,7 +85,7 @@ EXPORT_SYMBOL_GPL(usb_ep_set_maxpacket_limit);
* for interrupt transfers as well as bulk, but it likely couldn't be used
* for iso transfers or for endpoint 14. some endpoints are fully
* configurable, with more generic names like "ep-a". (remember that for
* USB, "in" means "towards the USB master".)
* USB, "in" means "towards the USB host".)
*
* This routine must be called in process context.
*

View file

@ -14,7 +14,7 @@
* Linux-USB host controller driver. USB traffic is simulated; there's
* no need for USB hardware. Use this with two other drivers:
*
* - Gadget driver, responding to requests (slave);
* - Gadget driver, responding to requests (device);
* - Host-side device driver, as already familiar in Linux.
*
* Having this all in one kernel can help some stages of development,
@ -261,7 +261,7 @@ struct dummy {
spinlock_t lock;
/*
* SLAVE/GADGET side support
* DEVICE/GADGET side support
*/
struct dummy_ep ep[DUMMY_ENDPOINTS];
int address;
@ -276,7 +276,7 @@ struct dummy {
unsigned pullup:1;
/*
* MASTER/HOST side support
* HOST side support
*/
struct dummy_hcd *hs_hcd;
struct dummy_hcd *ss_hcd;
@ -323,7 +323,7 @@ static inline struct dummy *gadget_dev_to_dummy(struct device *dev)
/*-------------------------------------------------------------------------*/
/* SLAVE/GADGET SIDE UTILITY ROUTINES */
/* DEVICE/GADGET SIDE UTILITY ROUTINES */
/* called with spinlock held */
static void nuke(struct dummy *dum, struct dummy_ep *ep)
@ -486,7 +486,7 @@ static void set_link_state(struct dummy_hcd *dum_hcd)
/*-------------------------------------------------------------------------*/
/* SLAVE/GADGET SIDE DRIVER
/* DEVICE/GADGET SIDE DRIVER
*
* This only tracks gadget state. All the work is done when the host
* side tries some (emulated) i/o operation. Real device controller
@ -957,7 +957,7 @@ static DEVICE_ATTR_RO(function);
* hardware can be built with discrete components, so the gadget API doesn't
* require that assumption.
*
* For this emulator, it might be convenient to create a usb slave device
* For this emulator, it might be convenient to create a usb device
* for each driver that registers: just add to a big root hub.
*/
@ -981,7 +981,7 @@ static int dummy_udc_start(struct usb_gadget *g,
}
/*
* SLAVE side init ... the layer above hardware, which
* DEVICE side init ... the layer above hardware, which
* can't enumerate without help from the driver we're binding.
*/
@ -1151,7 +1151,7 @@ static unsigned int dummy_get_ep_idx(const struct usb_endpoint_descriptor *desc)
return index;
}
/* MASTER/HOST SIDE DRIVER
/* HOST SIDE DRIVER
*
* this uses the hcd framework to hook up to host side drivers.
* its root hub will only have one device, otherwise it acts like
@ -2451,8 +2451,8 @@ static int dummy_start(struct usb_hcd *hcd)
struct dummy_hcd *dum_hcd = hcd_to_dummy_hcd(hcd);
/*
* MASTER side init ... we emulate a root hub that'll only ever
* talk to one device (the slave side). Also appears in sysfs,
* HOST side init ... we emulate a root hub that'll only ever
* talk to one device (the gadget side). Also appears in sysfs,
* just like more familiar pci-based HCDs.
*/
if (!usb_hcd_is_primary_hcd(hcd))

View file

@ -302,7 +302,7 @@ enum ftdi_sio_baudrate {
/*
* FTDI_SIO_GET_LATENCY_TIMER
*
* Set the timeout interval. The FTDI collects data from the slave
* Set the timeout interval. The FTDI collects data from the
* device, transmitting it to the host when either A) 62 bytes are
* received, or B) the timeout interval has elapsed and the buffer
* contains at least 1 byte. Setting this value to a small number
@ -324,7 +324,7 @@ enum ftdi_sio_baudrate {
/*
* FTDI_SIO_SET_LATENCY_TIMER
*
* Set the timeout interval. The FTDI collects data from the slave
* Set the timeout interval. The FTDI collects data from the
* device, transmitting it to the host when either A) 62 bytes are
* received, or B) the timeout interval has elapsed and the buffer
* contains at least 1 byte. Setting this value to a small number