/* * 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) * * This program is free software;you can redistribute it and/or * modify it under the terms of the GNU General Public License as * published by the Free Software Foundation, version 2. * * * 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 * PC card and the "u132-hcd" module uses the API to send and receive * 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); 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); d>2017-01-09 17:09:31 -0500 committerDavid S. Miller <davem@davemloft.net>2017-01-09 17:09:31 -0500 commitbda65b4255ac983ce36a6c0ea6a7794f8e8fcc86 (patch) treead280b2ecc1266329416f043dd20cea515b3dc48 /include/trace/events/signal.h parentb369e7fd41f7cdbe2488cb736ef4f958bb94b5e2 (diff)parentf502d834950a28e02651bb7e2cc7111ddd352644 (diff)
Merge tag 'mlx5-4kuar-for-4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux
Saeed Mahameed says: ==================== mlx5 4K UAR The following series of patches optimizes the usage of the UAR area which is contained within the BAR 0-1. Previous versions of the firmware and the driver assumed each system page contains a single UAR. This patch set will query the firmware for a new capability that if published, means that the firmware can support UARs of fixed 4K regardless of system page size. In the case of powerpc, where page size equals 64KB, this means we can utilize 16 UARs per system page. Since user space processes by default consume eight UARs per context this means that with this change a process will need a single system page to fulfill that requirement and in fact make use of more UARs which is better in terms of performance. In addition to optimizing user-space processes, we introduce an allocator that can be used by kernel consumers to allocate blue flame registers (which are areas within a UAR that are used to write doorbells). This provides further optimization on using the UAR area since the Ethernet driver makes use of a single blue flame register per system page and now it will use two blue flame registers per 4K. The series also makes changes to naming conventions and now the terms used in the driver code match the terms used in the PRM (programmers reference manual). Thus, what used to be called UUAR (micro UAR) is now called BFREG (blue flame register). In order to support compatibility between different versions of library/driver/firmware, the library has now means to notify the kernel driver that it supports the new scheme and the kernel can notify the library if it supports this extension. So mixed versions of libraries can run concurrently without any issues. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'include/trace/events/signal.h')