| /linux/LICENSES/deprecated/ |
| H A D | CC0-1.0 | 13 CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE
18 PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM
25 exclusive Copyright and Related Rights (defined below) upon the creator
26 and subsequent owner(s) (each and all, an "owner") of an original work of
27 authorship and/or a database (each, a "Work").
30 the purpose of contributing to a commons of creative, cultural and
31 scientific works ("Commons") that the public can reliably and without fear
33 works, reuse and redistribute as freely as possible in any form whatsoever
34 and for any purposes, including without limitation commercial purposes.
36 culture and the further production of creative, cultural and scientific
[all …]
|
| H A D | GPL-1.0 | 19 Everyone is permitted to copy and distribute verbatim copies
26 License is intended to guarantee your freedom to share and change free
29 software and to any other program whose authors commit to using it.
37 programs; and that you know you can do these things.
47 source code. And you must tell them their rights.
49 We protect your rights with two steps: (1) copyright the software, and
51 distribute and/or modify the software.
53 Also, for each author's protection and ours, we want to make certain
55 software. If the software is modified by someone else and passed on, we
60 The precise terms and conditions for copying, distribution and
[all …]
|
| /linux/drivers/edac/ |
| H A D | Kconfig | 4 # Licensed and distributed under the GPL
13 tristate "EDAC (Error Detection And Correction) reporting"
40 levels are 0-4 (from low to high) and by default it is set to 2.
69 It should be noticed that keeping both GHES and a hardware-driven
81 The EDAC scrub feature is optional and is designed to control the
90 The EDAC ECS feature is optional and is designed to control on-die
99 The EDAC memory repair feature is optional and is designed to control
112 Support for error detection and correction of DRAM ECC errors on
118 AMD CPUs up to and excluding family 0x17 provide for Memory
120 module allows the operator/user to inject Uncorrectable and
[all …]
|
| /linux/Documentation/userspace-api/media/v4l/ |
| H A D | hist-v4l2.rst | 12 and began to work on documentation, example drivers and applications.
15 another four years and two stable kernel releases until the new API was
28 meaningless ``O_TRUNC`` :c:func:`open()` flag, and the
29 aliases ``O_NONCAP`` and ``O_NOIO`` were defined. Applications can set
32 identifiers are now ordinals instead of flags, and the
33 ``video_std_construct()`` helper function takes id and
40 struct ``video_standard`` and the color subcarrier fields were
53 and ``V4L2_PIX_FMT_RGB32`` changed to ``V4L2_PIX_FMT_BGR32``. Audio
55 :ref:`VIDIOC_G_CTRL <VIDIOC_G_CTRL>` and
59 module. The ``YUV422`` and ``YUV411`` planar image formats were added.
[all …]
|
| H A D | diff-v4l.rst | 7 Differences between V4L and V4L2
10 The Video For Linux API was first introduced in Linux 2.1 to unify and
11 replace various TV and radio device related interfaces, developed
17 Opening and Closing Devices
21 for V4L2 video capture, overlay, radio and raw vbi capture devices did
23 and below in :ref:`v4l-dev`.
25 The teletext devices (minor range 192-223) have been removed in V4L2 and
37 .. flat-table:: V4L Device Types, Names and Numbers
44 * - Video capture and overlay
45 - ``/dev/video`` and ``/dev/bttv0``\ [#f1]_, ``/dev/video0`` to
[all …]
|
| /linux/Documentation/scsi/ |
| H A D | ChangeLog.lpfc | 12 for fabric and nport logins out of lpfc_cmpl_els_flogi.
18 PRLI...) are errored back and scan() terminates.
28 find command in both TX and TX completion queues. Return ERROR
62 - kill struct lpfc_scsi_dma_buf and embedded the two members
67 ever used by the driver, just reported to userspace (and that in
72 32bit and 64bit defines on some archs.
82 * Revise TRANSPORT_PATCHES_V2 so that lpfc_target is removed and
84 * Changed RW attributes of scan_down, max_luns and fcp_bind_method
88 list and marked for ADISC.
102 * Use DMA_64BIT_MASK and DMA_32BIT_MASK defines instead of
[all …]
|
| /linux/LICENSES/dual/ |
| H A D | CC-BY-4.0 | 19 Creative Commons Corporation ("Creative Commons") is not a law firm and
22 other relationship. Creative Commons makes its licenses and related
25 terms and conditions, or any related information. Creative Commons
31 Creative Commons public licenses provide a standard set of terms and
32 conditions that creators and other rights holders may use to share
33 original works of authorship and other material subject to copyright
34 and certain other rights specified in the public license below. The
36 exhaustive, and do not form part of our licenses.
41 copyright and certain other rights. Our licenses are
42 irrevocable. Licensors should read and understand the terms
[all …]
|
| H A D | Apache-2.0 | 20 TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
24 "License" shall mean the terms and conditions for use, reproduction, and
30 "Legal Entity" shall mean the union of the acting entity and all other
43 and configuration files.
47 object code, generated documentation, and conversions to other media types.
55 that is based on (or derived from) the Work and for which the editorial
59 merely link (or bind by name) to the interfaces of, the Work and Derivative
63 version of the Work and any modifications or additions to that Work or
70 mailing lists, source code control systems, and issue tracking systems that
72 and improving the Work, but excluding communication that is conspicuously
[all …]
|
| /linux/Documentation/timers/ |
| H A D | hrtimers.rst | 9 back and forth trying to integrate high-resolution and high-precision
10 features into the existing timer framework, and after testing various
14 to solve this'), and spent a considerable effort trying to integrate
18 - the forced handling of low-resolution and high-resolution timers in
19 the same way leads to a lot of compromises, macro magic and #ifdef
20 mess. The timers.c code is very "tightly coded" around jiffies and
21 32-bitness assumptions, and has been honed and micro-optimized for a
23 for many years - and thus even small extensions to it easily break
25 code is very good and tight code, there's zero problems with it in its
45 error conditions in various I/O paths, such as networking and block
[all …]
|
| H A D | highres.rst | 2 High resolution timers and dynamic ticks design notes
6 and beyond". The paper is part of the OLS 2006 Proceedings Volume 1, which can
15 design of the Linux time(r) system before hrtimers and other building blocks
18 Note: the paper and the slides are talking about "clock event source", while we
24 - timeofday and clock source management
44 timeofday and clock source management
51 sources, which are registered in the framework and selected on a quality based
52 decision. The low level code provides hardware setup and readout routines and
63 The paper "We Are Not Getting Any Younger: A New Approach to Time and
75 period defined at compile time. The setup and selection of the event device
[all …]
|
| /linux/Documentation/userspace-api/ |
| H A D | dma-buf-alloc-exchange.rst | 9 support for sharing pixel-buffer allocations between processes, devices, and
11 classes; this document details how applications and kernel subsystems should
14 It is written with reference to the DRM subsystem for GPU and display devices,
15 V4L2 for media devices, and also to Vulkan, EGL and Wayland, for userspace
16 support, however any other subsystems should also follow this design and advice.
26 in one or more memory buffers. Has width and height in pixels, pixel
27 format and modifier (implicit or explicit).
41 A piece of memory for storing (parts of) pixel data. Has stride and size
42 in bytes and at least one handle in some API. May contain one or more
46 A two-dimensional array of some or all of an image's color and alpha
[all …]
|
| /linux/Documentation/fb/ |
| H A D | api.rst | 12 with frame buffer devices. In-kernel APIs between device drivers and the frame
16 behaviours differ in subtle (and not so subtle) ways. This document describes
24 Device and driver capabilities are reported in the fixed screen information
34 expect from the device and driver.
43 2. Types and visuals
50 Formats are described by frame buffer types and visuals. Some visuals require
52 bits_per_pixel, grayscale, red, green, blue and transp fields.
54 Visuals describe how color information is encoded and assembled to create
56 types and visuals are supported.
64 Padding at end of lines may be present and is then reported through the fixed
[all …]
|
| /linux/Documentation/driver-api/surface_aggregator/ |
| H A D | internal.rst | 49 and Surface Serial Hub (SSH) driver. For the API documentation, refer to:
66 the packet transport logic and handles things like packet validation, packet
67 acknowledgment (ACKing), packet (retransmission) timeouts, and relaying
72 responses of the EC to those requests, and events (sent from EC to host).
74 responses to their corresponding requests, and implements request timeouts.
76 The *controller* layer is building on top of this and essentially decides
77 how request responses and, especially, events are dealt with. It provides an
79 workqueue for event and asynchronous request completion, and also manages
86 native SSAM devices, i.e. devices that are not defined in ACPI and not
87 implemented as platform devices, via |ssam_device| and |ssam_device_driver|
[all …]
|
| /linux/tools/perf/pmu-events/arch/x86/westmereep-dp/ |
| H A D | memory.json | 11 "BriefDescription": "REQUEST = ANY_DATA read and RESPONSE = ANY_DRAM AND REMOTE_FWD",
21 "BriefDescription": "REQUEST = ANY_DATA read and RESPONSE = ANY_LLC_MISS",
31 "BriefDescription": "REQUEST = ANY_DATA read and RESPONSE = OTHER_LOCAL_DRAM",
41 "BriefDescription": "REQUEST = ANY_DATA read and RESPONSE = REMOTE_DRAM",
51 "BriefDescription": "REQUEST = ANY IFETCH and RESPONSE = ANY_DRAM AND REMOTE_FWD",
61 "BriefDescription": "REQUEST = ANY IFETCH and RESPONSE = ANY_LLC_MISS",
71 "BriefDescription": "REQUEST = ANY IFETCH and RESPONSE = OTHER_LOCAL_DRAM",
81 "BriefDescription": "REQUEST = ANY IFETCH and RESPONSE = REMOTE_DRAM",
91 "BriefDescription": "REQUEST = ANY_REQUEST and RESPONSE = ANY_DRAM AND REMOTE_FWD",
101 "BriefDescription": "REQUEST = ANY_REQUEST and RESPONSE = ANY_LLC_MISS",
[all …]
|
| /linux/Documentation/arch/x86/ |
| H A D | intel_txt.rst | 15 - Measurement and verification of launched environment
17 Intel TXT is part of the vPro(TM) brand and is also available some
19 based on the Q35, X38, Q45, and Q43 Express chipsets (e.g. Dell
20 Optiplex 755, HP dc7800, etc.) and mobile systems based on the GM45,
21 PM45, and GS45 Express chipsets.
47 uses Intel TXT to perform a measured and verified launch of an OS
55 w/ TXT support since v3.2), and now Linux kernels.
61 While there are many products and technologies that attempt to
64 Measurement Architecture (IMA) and Linux Integrity Module interface
69 starting at system reset and requires measurement of all code
[all …]
|
| /linux/tools/usb/usbip/ |
| H A D | COPYING | 6 Everyone is permitted to copy and distribute verbatim copies
12 freedom to share and change it. By contrast, the GNU General Public
13 License is intended to guarantee your freedom to share and change free
16 Foundation's software and to any other program whose authors commit to
23 have the freedom to distribute copies of free software (and charge for
26 in new free programs; and that you know you can do these things.
36 source code. And you must show them these terms so they know their
39 We protect your rights with two steps: (1) copyright the software, and
41 distribute and/or modify the software.
43 Also, for each author's protection and ours, we want to make certain
[all …]
|
| /linux/LICENSES/preferred/ |
| H A D | GPL-2.0 | 25 Everyone is permitted to copy and distribute verbatim copies
31 freedom to share and change it. By contrast, the GNU General Public
32 License is intended to guarantee your freedom to share and change free
35 Foundation's software and to any other program whose authors commit to
42 have the freedom to distribute copies of free software (and charge for
45 in new free programs; and that you know you can do these things.
55 source code. And you must show them these terms so they know their
58 We protect your rights with two steps: (1) copyright the software, and
60 distribute and/or modify the software.
62 Also, for each author's protection and ours, we want to make certain
[all …]
|
| H A D | LGPL-2.0 | 21 Everyone is permitted to copy and distribute verbatim copies of this
30 share and change it. By contrast, the GNU General Public Licenses are
31 intended to guarantee your freedom to share and change free software--to
35 designated Free Software Foundation software, and to any other libraries
40 to distribute copies of free software (and charge for this service if you
42 can change the software or use pieces of it in new free programs; and that
55 changes to the library and recompiling it. And you must show them these
59 library, and (2) offer you this license which gives you legal permission to
60 copy, distribute and/or modify the library.
64 the library is modified by someone else and passed on, we want its
[all …]
|
| H A D | LGPL-2.1 | 23 Everyone is permitted to copy and distribute verbatim copies of this
33 share and change it. By contrast, the GNU General Public Licenses are
34 intended to guarantee your freedom to share and change free software--to
39 Foundation and other authors who decide to use it. You can use it too, but
46 the freedom to distribute copies of free software (and charge for this
48 want it; that you can change the software and use pieces of it in new free
49 programs; and that you are informed that you can do these things.
61 changes to the library and recompiling it. And you must show them these
65 library, and (2) we offer you this license, which gives you legal
66 permission to copy, distribute and/or modify the library.
[all …]
|
| /linux/Documentation/driver-api/usb/ |
| H A D | gadget.rst | 12 within peripherals and other USB devices that embed Linux. It provides
13 an overview of the API structure, and shows how that fits into a system
26 and alternate interface settings.
31 - Sharing data structures and API models with the Linux-USB host side
32 API. This helps the OTG support, and looks forward to more-symmetric
33 frameworks (where the same I/O model is used by both host and device
47 driver is the master (or "client driver") and the gadget driver is the
51 queues of request objects to package I/O buffers, and those requests may
53 USB *Chapter 9* messages, structures, and constants. Also, both APIs
54 bind and unbind drivers to devices. The APIs differ in detail, since the
[all …]
|
| /linux/tools/memory-model/Documentation/ |
| H A D | explanation.txt | 13 5. ORDERING AND CYCLES
15 7. THE PROGRAM ORDER RELATION: po AND po-loc
17 9. DEPENDENCY RELATIONS: data, addr, and ctrl
18 10. THE READS-FROM RELATION: rf, rfi, and rfe
19 11. CACHE COHERENCE AND THE COHERENCE ORDER RELATION: co, coi, and coe
20 12. THE FROM-READS RELATION: fr, fri, and fre
27 19. AND THEN THERE WAS ALPHA
30 22. RCU RELATIONS: rcu-link, rcu-gp, rcu-rscsi, rcu-order, rcu-fence, and rb
33 25. PLAIN ACCESSES AND DATA RACES
34 26. ODDS AND ENDS
[all …]
|
| /linux/include/linux/ |
| H A D | zlib.h | 3 Copyright (C) 1995-2005 Jean-loup Gailly and Mark Adler
10 including commercial applications, and to alter it and redistribute it
17 2. Altered source versions must be plainly marked as such, and must not be
27 (zlib format), rfc1951.txt (deflate format) and rfc1952.txt (gzip format).
43 * Z_PACKET_FLUSH is added and used by ppp_deflate. Before returning
44 this checks there is no more input data available and the next data
48 the history window and adjusts the accoutning without calling
53 The 'zlib' compression library provides in-memory compression and
56 (deflation) but other algorithms will be added later and will have the same
62 application must provide more input and/or consume the output
[all …]
|
| /linux/Documentation/networking/ |
| H A D | af_xdp.rst | 13 This document assumes that the reader is familiar with BPF and XDP. If
24 syscall. Associated with each XSK are two rings: the RX ring and the
25 TX ring. A socket can receive packets on the RX ring and it can send
26 packets on the TX ring. These rings are registered and sized with the
27 setsockopts XDP_RX_RING and XDP_TX_RING, respectively. It is mandatory
30 UMEM. RX and TX can share the same UMEM so that a packet does not have
31 to be copied between RX and TX. Moreover, if a packet needs to be kept
33 to that packet can be changed to point to another and reused right
42 UMEM also has two rings: the FILL ring and the COMPLETION ring. The
47 kernel has transmitted completely and can now be used again by user
[all …]
|
| /linux/Documentation/bpf/libbpf/ |
| H A D | libbpf_overview.rst | 8 object files and prepares and loads them into the Linux kernel. libbpf takes the
9 heavy lifting of loading, verifying, and attaching BPF programs to various
11 correctness and performance.
15 * Provides high-level and low-level APIs for user space programs to interact
18 over the interactions between user space and BPF programs.
21 global variables and work with BPF programs.
23 and tracing helpers, allowing developers to simplify BPF code writing.
25 BPF programs that can be compiled once and run across different kernel
29 understanding of the capabilities and advantages of libbpf and how it can help
32 BPF App Lifecycle and libbpf APIs
[all …]
|
| /linux/Documentation/admin-guide/ |
| H A D | perf-security.rst | 3 Perf events and tool security
12 direct usage of perf_events system call API [2]_ and over data files
15 units (PMU) [2]_ and Perf collect and expose for performance analysis.
16 Collected system and performance data may be split into several
19 1. System hardware and software configuration data, for example: a CPU
20 model and its cache configuration, an amount of available memory and
21 its topology, used kernel and Perf versions, performance monitoring
25 2. User and kernel module paths and their load addresses with sizes,
26 process and thread names with their PIDs and TIDs, timestamps for
27 captured hardware and software events.
[all …]
|