UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/drivers/usb/misc/usb_u132.h

98 lines
5.0 KiB
C
Raw Normal View History

USB: add SPDX identifiers to all remaining files in drivers/usb/ It's good to have SPDX identifiers in all files to make it easier to audit the kernel tree for correct licenses. Update the drivers/usb/ and include/linux/usb* files with the correct SPDX license identifier based on the license text in the file itself. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This work is based on a script and data from Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Kate Stewart <kstewart@linuxfoundation.org> Cc: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> Acked-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-03 18:28:30 +08:00
// SPDX-License-Identifier: GPL-2.0
USB: ftdi-elan: client driver for ELAN Uxxx adapters This "ftdi-elan" module is one half of the "driver" for ELAN's Uxxx series adapters which are USB to PCMCIA CardBus adapters. Currently only the U132 adapter is available and it's module is called "u132-hcd". When the USB hot plug subsystem detects a Uxxx series adapter it should load this module. Upon a successful device probe() the jtag device file interface is created and the status workqueue started up. The jtag device file interface exists for the purpose of updating the firmware in the Uxxx series adapter, but as yet it had never been used. The status workqueue initializes the Uxxx and then sits there polling the Uxxx until a supported PCMCIA CardBus device is detected it will start the command and respond workqueues and then load the module that handles the device. This will initially be only the u132-hcd module. The status workqueue then just polls the Uxxx looking for card ejects. The command and respond workqueues implement a command sequencer for communicating with the firmware on the other side of the FTDI chip in the Uxxx. This "ftdi-elan" module exports some functions to interface with the sequencer. Note that this module is a USB client driver. Note that the "u132-hcd" module is a (cut-down OHCI) host controller. Thus we have a topology with the parent of a host controller being a USB client! This really stresses the USB subsystem semaphore/mutex handling in the module removal. Signed-off-by: Tony Olech <tony.olech@elandigitalsystems.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-09-13 18:26:04 +08:00
/*
* Common Header File for the Elan Digital Systems U132 adapter
* this file should be included by both the "ftdi-u132" and
* the "u132-hcd" modules.
*
* Copyright(C) 2006 Elan Digital Systems Limited
*(http://www.elandigitalsystems.com)
*
* Author and Maintainer - Tony Olech - Elan Digital Systems
*(tony.olech@elandigitalsystems.com)
*
* The driver was written by Tony Olech(tony.olech@elandigitalsystems.com)
* based on various USB client drivers in the 2.6.15 linux kernel
* with constant reference to the 3rd Edition of Linux Device Drivers
* published by O'Reilly
*
* The U132 adapter is a USB to CardBus adapter specifically designed
* for PC cards that contain an OHCI host controller. Typical PC cards
* are the Orange Mobile 3G Option GlobeTrotter Fusion card.
*
* The U132 adapter will *NOT *work with PC cards that do not contain
* an OHCI controller. A simple way to test whether a PC card has an
* OHCI controller as an interface is to insert the PC card directly
* into a laptop(or desktop) with a CardBus slot and if "lspci" shows
* a new USB controller and "lsusb -v" shows a new OHCI Host Controller
* then there is a good chance that the U132 adapter will support the
* PC card.(you also need the specific client driver for the PC card)
*
* Please inform the Author and Maintainer about any PC cards that
* contain OHCI Host Controller and work when directly connected to
* an embedded CardBus slot but do not work when they are connected
* via an ELAN U132 adapter.
*
* The driver consists of two modules, the "ftdi-u132" module is
* a USB client driver that interfaces to the FTDI chip within
* the U132 adapter manufactured by Elan Digital Systems, and the
* "u132-hcd" module is a USB host controller driver that talks
* to the OHCI controller within CardBus card that are inserted
* in the U132 adapter.
*
* The "ftdi-u132" module should be loaded automatically by the
* hot plug system when the U132 adapter is plugged in. The module
* initialises the adapter which mostly consists of synchronising
* the FTDI chip, before continuously polling the adapter to detect
* PC card insertions. As soon as a PC card containing a recognised
* OHCI controller is seen the "ftdi-u132" module explicitly requests
* the kernel to load the "u132-hcd" module.
*
* The "ftdi-u132" module provides the interface to the inserted
Fix misc .c/.h comment typos Fix various .c/.h typos in comments (no code changes). Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-11-30 12:24:39 +08:00
* PC card and the "u132-hcd" module uses the API to send and receive
USB: ftdi-elan: client driver for ELAN Uxxx adapters This "ftdi-elan" module is one half of the "driver" for ELAN's Uxxx series adapters which are USB to PCMCIA CardBus adapters. Currently only the U132 adapter is available and it's module is called "u132-hcd". When the USB hot plug subsystem detects a Uxxx series adapter it should load this module. Upon a successful device probe() the jtag device file interface is created and the status workqueue started up. The jtag device file interface exists for the purpose of updating the firmware in the Uxxx series adapter, but as yet it had never been used. The status workqueue initializes the Uxxx and then sits there polling the Uxxx until a supported PCMCIA CardBus device is detected it will start the command and respond workqueues and then load the module that handles the device. This will initially be only the u132-hcd module. The status workqueue then just polls the Uxxx looking for card ejects. The command and respond workqueues implement a command sequencer for communicating with the firmware on the other side of the FTDI chip in the Uxxx. This "ftdi-elan" module exports some functions to interface with the sequencer. Note that this module is a USB client driver. Note that the "u132-hcd" module is a (cut-down OHCI) host controller. Thus we have a topology with the parent of a host controller being a USB client! This really stresses the USB subsystem semaphore/mutex handling in the module removal. Signed-off-by: Tony Olech <tony.olech@elandigitalsystems.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-09-13 18:26:04 +08:00
* data. The API features call-backs, so that part of the "u132-hcd"
* module code will run in the context of one of the kernel threads
* of the "ftdi-u132" module.
*
*/
int ftdi_elan_switch_on_diagnostics(int number);
void ftdi_elan_gone_away(struct platform_device *pdev);
void start_usb_lock_device_tracing(void);
struct u132_platform_data {
u16 vendor;
u16 device;
u8 potpg;
void (*port_power) (struct device *dev, int is_on);
void (*reset) (struct device *dev);
};
int usb_ftdi_elan_edset_single(struct platform_device *pdev, u8 ed_number,
void *endp, struct urb *urb, u8 address, u8 ep_number, u8 toggle_bits,
void (*callback) (void *endp, struct urb *urb, u8 *buf, int len,
int toggle_bits, int error_count, int condition_code, int repeat_number,
int halted, int skipped, int actual, int non_null));
int usb_ftdi_elan_edset_output(struct platform_device *pdev, u8 ed_number,
void *endp, struct urb *urb, u8 address, u8 ep_number, u8 toggle_bits,
void (*callback) (void *endp, struct urb *urb, u8 *buf, int len,
int toggle_bits, int error_count, int condition_code, int repeat_number,
int halted, int skipped, int actual, int non_null));
int usb_ftdi_elan_edset_empty(struct platform_device *pdev, u8 ed_number,
void *endp, struct urb *urb, u8 address, u8 ep_number, u8 toggle_bits,
void (*callback) (void *endp, struct urb *urb, u8 *buf, int len,
int toggle_bits, int error_count, int condition_code, int repeat_number,
int halted, int skipped, int actual, int non_null));
int usb_ftdi_elan_edset_input(struct platform_device *pdev, u8 ed_number,
void *endp, struct urb *urb, u8 address, u8 ep_number, u8 toggle_bits,
void (*callback) (void *endp, struct urb *urb, u8 *buf, int len,
int toggle_bits, int error_count, int condition_code, int repeat_number,
int halted, int skipped, int actual, int non_null));
int usb_ftdi_elan_edset_setup(struct platform_device *pdev, u8 ed_number,
void *endp, struct urb *urb, u8 address, u8 ep_number, u8 toggle_bits,
void (*callback) (void *endp, struct urb *urb, u8 *buf, int len,
int toggle_bits, int error_count, int condition_code, int repeat_number,
int halted, int skipped, int actual, int non_null));
int usb_ftdi_elan_edset_flush(struct platform_device *pdev, u8 ed_number,
void *endp);
USB: ftdi-elan.c: fixes and cleanups This patch contains the following possible cleanups: - make the needlessly global ftdi_release_platform_dev() static - remove the unused usb_ftdi_elan_read_reg() - proper prototypes for the following functions: - usb_ftdi_elan_read_pcimem() - usb_ftdi_elan_write_pcimem() Note that the misplaced prototypes for the latter ones in drivers/usb/host/u132-hcd.c were buggy. Depending on the calling convention of the architecture calling one of them could have turned your stack into garbage. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-20 10:24:44 +08:00
int usb_ftdi_elan_read_pcimem(struct platform_device *pdev, int mem_offset,
u8 width, u32 *data);
int usb_ftdi_elan_write_pcimem(struct platform_device *pdev, int mem_offset,
u8 width, u32 data);