| /openbmc/linux/Documentation/usb/ |
| H A D | gadget_configfs.rst | 15 be connected to a USB Host to extend it with additional functions like a serial
20 functions, each function representing e.g. a serial connection or a SCSI disk.
22 Linux provides a number of functions for gadgets to use.
25 and which functions each configuration will provide.
39 In order for this to work configfs must be available, so CONFIGFS_FS must be
40 'y' or 'm' in .config. As of this writing USB_LIBCOMPOSITE selects CONFIGFS_FS.
50 http://www.spinics.net/lists/linux-usb/msg76388.html)
55 $ mount none $CONFIGFS_HOME -t configfs
60 -----------------------
82 In order to have a place to store them, a strings subdirectory must be created
[all …]
|
| H A D | functionfs.rst | 9 that kernel level composite functions provide when they are added to
12 This in particular means that the composite initialisation functions
13 may not be in init section (ie. may not use the __init tag).
22 them as needed also handling situation when numbers differ in
35 What I also want to mention is that the FunctionFS is designed in such
36 a way that it is possible to mount it several times so in the end
37 a gadget could use several FunctionFS functions. The idea is that
45 $ insmod g_ffs.ko idVendor=<ID> iSerialNumber=<string> functions=mtp,hid
46 $ mkdir /dev/ffs-mtp && mount -t functionfs mtp /dev/ffs-mtp
47 $ ( cd /dev/ffs-mtp && mtp-daemon ) &
[all …]
|
| /openbmc/linux/Documentation/core-api/ |
| H A D | genalloc.rst | 4 There are a number of memory-allocation subsystems in the kernel, each
6 implement a new allocator for a specific range of special-purpose memory;
10 tested allocators. Back in 2005, Jes Sorensen lifted one of those
20 .. kernel-doc:: lib/genalloc.c
21 :functions: gen_pool_create
23 .. kernel-doc:: lib/genalloc.c
24 :functions: devm_gen_pool_create
27 allocations is set with min_alloc_order; it is a log-base-2 number like
31 required to track the memory in the pool. The nid parameter specifies
33 structures; it can be -1 if the caller doesn't care.
[all …]
|
| H A D | asm-annotations.rst | 4 Copyright (c) 2017-2019 Jiri Slaby
6 This document describes the new macros for annotation of data and code in
7 assembly. In particular, it contains information about ``SYM_FUNC_START``,
11 ---------
12 Some code like entries, trampolines, or boot code needs to be written in
13 assembly. The same as in C, such code is grouped into functions and
18 some functions as *global* in order to be visible outside of their translation
24 annotations in assembly. Due to the lack of their documentation, the macros
25 are used in rather wrong contexts at some locations. Clearly, ``ENTRY`` was
27 ``END`` used to mark the end of data or end of special functions with
[all …]
|
| /openbmc/linux/Documentation/livepatch/ |
| H A D | livepatch.rst | 17 heavy load during peak usage. In addition to keeping systems up and running,
20 functions without a system reboot.
26 There are multiple mechanisms in the Linux kernel that are directly related
30 - The kernel probes are the most generic. The code can be redirected by
33 - The function tracer calls the code from a predefined location that is
35 compiler using the '-pg' gcc option.
37 - Livepatching typically needs to redirect the code at the very beginning
39 are in any way modified.
53 Functions are there for a reason. They take some input parameters, get or
54 release locks, read, process, and even write some data in a defined way,
[all …]
|
| /openbmc/linux/lib/ |
| H A D | Kconfig | 1 # SPDX-License-Identifier: GPL-2.0-only
15 bool "Automatically choose fastest RAID6 PQ functions"
19 Benchmark all available RAID6 PQ functions on init and choose the
31 converting bitfields between a CPU-usable representation and a
33 - Is little endian (bytes are reversed within a 32-bit group)
34 - The least-significant 32-bit word comes first (within a 64-bit
36 - The most significant bit of a byte is at its right (bit 0 of a
39 in the data sheets of the peripherals they are in control of.
41 When in doubt, say N.
50 This option enables the use of hardware bit-reversal instructions on
[all …]
|
| /openbmc/u-boot/doc/device-tree-bindings/pinctrl/ |
| H A D | marvell,armada-37xx-pinctrl.txt | 7 ------------------------
11 Refer to pinctrl-bindings.txt in this directory for details of the
17 - compatible: "marvell,armada3710-sb-pinctrl", "syscon, "simple-mfd"
19 "marvell,armada3710-nb-pinctrl", "syscon, "simple-mfd"
21 - reg: The first set of registers is for pinctrl/GPIO and the second
23 - interrupts: list of interrupts used by the GPIO
25 Available groups and functions for the North Bridge:
28 - pins 20-24
29 - functions jtag, gpio
32 - pins 8-10
[all …]
|
| /openbmc/phosphor-logging/ |
| H A D | extensions.hpp | 16 * @param[in] internal::Manager& - A reference to the Manager class.
27 * @param[in] const std::string& - The Message property
28 * @param[in] uin32_t - The event log ID
29 * @param[in] uint64_t - The event log timestamp
30 * @param[in] Level - The event level
31 * @param[in] const AdditionalDataArg&) - the additional data
32 * @param[in] const AssociationEndpoints& - Association endpoints (callouts)
33 * @param[in] const FFDCArg& - A vector of FFDC file info.
41 * @param[in] uint32_t - The event log ID
52 * @param[in] uint32_t - The event log ID
[all …]
|
| /openbmc/linux/Documentation/power/ |
| H A D | opp.rst | 5 (C) 2009-2010 Nishanth Menon <nm@ti.com>, Texas Instruments Incorporated
11 3. OPP Search Functions
12 4. OPP Availability Control Functions
13 5. OPP Data Retrieval Functions
20 -------------------------------------------------
22 Complex SoCs of today consists of a multiple sub-modules working in conjunction.
23 In an operational system executing varied use cases, not all modules in the SoC
25 facilitate this, sub-modules in a SoC are grouped into domains, allowing some
41 - {300000000, 1000000}
42 - {800000000, 1200000}
[all …]
|
| /openbmc/linux/Documentation/devicetree/bindings/pinctrl/ |
| H A D | marvell,armada-37xx-pinctrl.txt | 12 ------------------------
16 Refer to pinctrl-bindings.txt in this directory for details of the
22 - compatible: "marvell,armada3710-sb-pinctrl", "syscon, "simple-mfd"
24 "marvell,armada3710-nb-pinctrl", "syscon, "simple-mfd"
26 - reg: The first set of register are for pinctrl/gpio and the second
28 - interrupts: list of the interrupt use by the gpio
30 Available groups and functions for the North bridge:
33 - pins 20-24
34 - functions jtag, gpio
37 - pins 8-10
[all …]
|
| /openbmc/linux/tools/perf/Documentation/ |
| H A D | perf-script-perl.txt | 1 perf-script-perl(1)
5 ----
6 perf-script-perl - Process trace data with a Perl script
9 --------
11 'perf script' [-s [Perl]:script[.pl] ]
14 -----------
17 built-in Perl interpreter. It reads and processes the input file and
18 displays the results of the trace analysis implemented in the given
22 ---------------
25 -g perl' in the same directory as an existing perf.data trace file.
[all …]
|
| /openbmc/qemu/include/qemu/ |
| H A D | coroutine-core.h | 11 * See the COPYING.LIB file in the top-level directory.
20 * cooperative userspace threading. These functions provide a simple but
25 * These functions are re-entrant and may be used outside the BQL.
27 * Functions that execute in coroutine context cannot be called
28 * directly from normal functions. Use @coroutine_fn to mark such
29 * functions. For example:
35 * In the future it would be nice to have the compiler or a static
36 * checker catch misuse of such functions. This annotation might make
37 * it possible and in the meantime it serves as documentation.
41 * Mark a function that executes in coroutine context
[all …]
|
| /openbmc/u-boot/doc/driver-model/ |
| H A D | livetree.txt | 6 ------------
8 Traditionally U-Boot has used a 'flat' device tree. This means that it
11 hierarchy detected by tags in the format.
13 This document describes U-Boot's support for a 'live' device tree, meaning
14 that the tree is loaded into a hierarchical data structure within U-Boot.
18 ----------
22 - it is the format produced by the device tree compiler, so no translation
25 - it is fairly compact (e.g. there is no need for pointers)
27 - it is accessed by the libfdt library, which is well tested and stable
33 rebuilt in a new location to create more space. Even if not adding new
[all …]
|
| /openbmc/linux/Documentation/trace/ |
| H A D | ftrace-uses.rst | 2 Using ftrace to hook to functions
16 beginning of functions in order to record and trace the flow of the kernel.
33 There are helper functions to help against recursion, and making sure
48 .. code-block:: c
77 no longer being called by functions after the unregister_ftrace_function()
87 .. code-block:: c
106 flags are set in the ftrace_ops structure, then this will be pointing
114 As functions can be called from anywhere, and it is possible that a function
116 recursion protection must be used. There are two helper functions that
117 can help in this regard. If you start your code with:
[all …]
|
| /openbmc/linux/Documentation/PCI/endpoint/ |
| H A D | pci-vntb-howto.rst | 1 .. SPDX-License-Identifier: GPL-2.0
4 PCI Non-Transparent Bridge (NTB) Endpoint Function (EPF) User Guide
9 This document is a guide to help users use pci-epf-vntb function driver
11 be followed in the host side and EP side is given below. For the hardware
13 Documentation/PCI/endpoint/pci-vntb-function.rst
19 ---------------------------
21 To find the list of endpoint controller devices in the system::
32 -------------------------
34 To find the list of endpoint function drivers in the system::
36 # ls /sys/bus/pci-epf/drivers
[all …]
|
| H A D | pci-ntb-howto.rst | 1 .. SPDX-License-Identifier: GPL-2.0
4 PCI Non-Transparent Bridge (NTB) Endpoint Function (EPF) User Guide
9 This document is a guide to help users use pci-epf-ntb function driver
11 be followed in the host side and EP side is given below. For the hardware
13 Documentation/PCI/endpoint/pci-ntb-function.rst
19 ---------------------------
24 To find the list of endpoint controller devices in the system::
27 2900000.pcie-ep 2910000.pcie-ep
32 2900000.pcie-ep 2910000.pcie-ep
36 -------------------------
[all …]
|
| /openbmc/openbmc/poky/bitbake/doc/bitbake-user-manual/ |
| H A D | bitbake-user-manual-metadata.rst | 1 .. SPDX-License-Identifier: CC-BY-2.5
20 ----------------------
45 VARIABLE = 'I have a " in my value'
49 Unlike in Bourne shells, single quotes work identically to double
50 quotes in all other ways. They do not suppress variable expansions.
53 ----------------------------
58 - Customize a recipe that uses the variable.
60 - Change a variable's default value used in a ``*.bbclass`` file.
62 - Change the variable in a ``*.bbappend`` file to override the variable
63 in the original recipe.
[all …]
|
| /openbmc/linux/Documentation/sound/designs/ |
| H A D | midi-2.0.rst | 12 - Support of Universal MIDI Packet (UMP)
13 - Support of MIDI 2.0 protocol messages
14 - Transparent conversions between UMP and legacy MIDI 1.0 byte stream
15 - MIDI-CI for property and profile configurations
19 aligned, and each message can be put in a single packet. UMP can send
26 MIDI-CI is a high-level protocol that can talk with the MIDI device
27 for the flexible profiles and configurations. It's represented in the
31 the encoding/decoding of MIDI protocols on UMP, while MIDI-CI is
32 supported in user-space over the standard SysEx.
39 The access to UMP devices are provided in two ways: the access via
[all …]
|
| /openbmc/linux/Documentation/ABI/testing/ |
| H A D | configfs-usb-gadget-uvc | 1 What: /config/usb-gadget/gadget/functions/uvc.name
13 What: /config/usb-gadget/gadget/functions/uvc.name/control
27 What: /config/usb-gadget/gadget/functions/uvc.name/control/class
32 What: /config/usb-gadget/gadget/functions/uvc.name/control/class/ss
37 What: /config/usb-gadget/gadget/functions/uvc.name/control/class/fs
42 What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal
47 What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal/output
52 What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal/output/default
66 bTerminalID a non-zero id of this terminal
69 What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal/camera
[all …]
|
| /openbmc/linux/Documentation/driver-api/media/ |
| H A D | dtv-demux.rst | 1 .. SPDX-License-Identifier: GPL-2.0
4 ---------------------
9 The Kernel Digital TV Demux kABI defines a driver-internal interface for
10 registering low-level, hardware specific driver to a hardware independent
12 The header file for this kABI is named ``demux.h`` and located in
15 The demux kABI should be implemented for each demux in the system. It is
20 Each demux receives its TS input from a DVB front-end or from memory, as
21 set via this demux kABI. In a system with more than one front-end, the kABI
22 can be used to select one of the DVB front-ends as a TS source for a demux,
23 unless this is fixed in the HW platform.
[all …]
|
| /openbmc/linux/Documentation/driver-api/fpga/ |
| H A D | fpga-mgr.rst | 5 --------
7 The FPGA manager core exports a set of functions for programming an FPGA with
9 hidden away in a low level driver which registers a set of ops with the core.
13 The FPGA image to be programmed can be in a scatter gather list, a single
18 The particulars for programming the image are presented in a structure (struct
20 FPGA image as well as image-specific particulars such as whether the image was
24 --------------------------------
39 struct device *dev = &pdev->dev;
46 return -ENOMEM;
50 * them in priv
[all …]
|
| /openbmc/qemu/scripts/performance/ |
| H A D | topN_perf.py | 3 # Print the top N most executed functions in QEMU using perf.
5 # topN_perf.py [-h] [-n] <number of displayed top functions> -- \
9 # [-h] - Print the script arguments help message.
10 # [-n] - Specify the number of top functions to print.
11 # - If this flag is not specified, the tool defaults to 25.
14 # topN_perf.py -n 20 -- qemu-arm coulomb_double-arm
26 # This program is distributed in the hope that it will be useful,
42 usage='topN_perf.py [-h] [-n] <number of displayed top functions > -- '
46 parser.add_argument('-n', dest='top', type=int, default=25,
47 help='Specify the number of top functions to print.')
[all …]
|
| /openbmc/linux/Documentation/bpf/ |
| H A D | bpf_licensing.rst | 10 "BPF" was originally introduced as BSD Packet Filter in
11 http://www.tcpdump.org/papers/bpf-usenix93.pdf. The corresponding instruction
15 However an instruction set is a specification for machine-language interaction,
17 application of a BSD license may be misleading in a certain context, as the
22 In 2014, the classic BPF instruction set was significantly extended. We
29 Using the eBPF instruction set requires implementing code in both kernel space
32 In Linux Kernel
33 ---------------
35 The reference implementations of the eBPF interpreter and various just-in-time
37 eBPF helper functions is also GPLv2 licensed. Interpreters, JITs, helpers,
[all …]
|
| /openbmc/linux/Documentation/arch/arm/omap/ |
| H A D | omap_pm.rst | 6 authors use these functions to communicate minimum latency or
13 - support the range of power management parameters present in the TI SRF;
15 - separate the drivers from the underlying PM parameter
19 - specify PM parameters in terms of fundamental units, such as
23 - allow drivers which are shared with other architectures (e.g.,
24 DaVinci) to add these constraints in a way which won't affect non-OMAP
27 - can be implemented immediately with minimal disruption of other
32 five power management functions for driver code:
36 (*pdata->set_max_mpu_wakeup_lat)(struct device *dev, unsigned long t)
40 (*pdata->set_max_dev_wakeup_lat)(struct device *dev, unsigned long t)
[all …]
|
| /openbmc/linux/rust/ |
| H A D | build_error.rs | 1 // SPDX-License-Identifier: GPL-2.0
3 //! Build-time error.
5 //! This crate provides a [const function][const-functions] `build_error`, which will panic in
6 //! compile-time if executed in [const context][const-context], and will cause a build error
9 //! It is used by `build_assert!` in the kernel crate, allowing checking of
10 //! conditions that could be checked statically, but could not be enforced in
11 //! Rust yet (e.g. perform some checks in [const functions][const-functions], but those
12 //! functions could still be called in the runtime).
14 //! For details on constant evaluation in Rust, please see the [Reference][const-eval].
16 //! [const-eval]: https://doc.rust-lang.org/reference/const_eval.html
[all …]
|